(I also think Rust could benefit massively from either UFCS or a pipeline operator because the distinction between member functions and freestanding functions is largely arbitrary and leads to stupid workarounds like extension traits that contribute nothing but a band-aid fix and confusion.)

@xcodesucks I think they call the pattern railway programming, routing a number of exit cases into the same codepath while transforming a value in the long path via operations that aren't otherwise related to each other is a useful pattern, and that's what Rust does, or tries to, with chaining and the ? operator. For it to be perfect we would need FromResidual to be stabilized, but even now it's very often the perfect abstraction, in the sense that if it didn't exist I would write the exact same code with no additional information but just less direct syntax.

@12bitfloat I feel so dumb now

@BordedDev I'm completely certain that the compiler will inline both the map and the unwrap_or_default, recognize that we're immediately branching on the result, remove the construction of the short-lived Option<bool>, and finally produce the same exact assembly for both lines. This is the exact kind of thing LLVM was made for.

@BordedDev well, the collection in this case is literally 1 byte larger than its potential element, so mapping it is pretty fast actually. But there's also Option::is_some_and and Option::is_none_or which are a lot more descriptive.

Fun! No input limits though :)

@BordedDev Yeah, option (maybe in Haskell parlance, nullable elsewhere) is a 0..1 arity collection. Rust consistently calls this function `map`; It isn't part of a trait, but it actually corresponds to Haskell's fmap which is defined by Functor. It's used to transform (map) all of the values in a collection without affecting its structure.

@BordedDev that "map" is probably Option::map or Result::map, the original collection is only being queried here.

idk maybe I'm smartassing over what's really a pretty trivial line by Rust standards. I write, edit, and work around way worse lines than your original every minute and they are not an arbiter of productivity. It's all fine.

You may prefer to think of the entire expression under the negation as a unit with a distinct semantic meaning corresponding to a positive statement ("$name is a mine"), which would make top-level negation preferable, but I think in that case it's also a good idea to pull it out into a variable. Generally speaking, an expression should represent one concept. Sometimes that concept is inherently complicated to express with the tools available so it gets long, this is especially often the case with iterators, but if it has sub-concepts you want to keep intact, those should be extracted if possible.

So apparently I instinctively added the top-level negation without noticing that it's actually there, but I think it demonstrates another advantage of the form with an explicit boolean value that I wrote; you can lower the negation into the expression to avoid negating a boolean that you created right here (whether as a literal or via Default). The resulting statement would look something like this:

if rooms.get(&name).map_or(true, |turf| !matches!(turf, Turf::Mine))

@12bitfloat I didn't notice the damn !

@jestdotty If there's no room, your example should evaluate to the default value of bool which is false.

Before let chains, I'd've done something like this:

if !rooms.get(&name).map_or(false, |turf| matches!(turf, Turf::Mine))

ah, a fellow programmer with low resolution eyes

I also can't tan, but I have never ever burned through glass. It triggers my learned flight reflex from the sun, but I'm pretty sure that's because the reflex is tied to IR which I can feel and which can pass through glass, while UV can't be felt directly until it's too late and it reflects off glass.

There's an old socialist joke:

"Why is the Soviet Union our brother and not our friend? Because you choose your friends whereas your brothers are dropped beside you."

for what it's worth, my adblocker flags the link

In critical infrastructure, they usually perform recovery tests in a dedicated environment. This is also useful because in case of a failure it's the only useful pointer you can have to project an estimated downtime.

Tony Hoare is an absolute legend.

LinkedIn is somehow a really beautiful small-scale replica of capitalism's tendency to incorporate its own criticism. Sickening, but in a way beautiful. Capitalism can produce everything, including tiny pet capitalism with the same social dynamics compressed into a narrow layer of its universe.

Actually, it'll probably be easier to do it on paper, and this is exactly why I chose Rust. I shudder to think what this would be like if I was also dealing with segfaults emerging from incorrect in-process memory management alongside the panics, errors and leaks emerging from incorrect interprocess resource dependency tracking.

God damn it, I need to write a fucking log aggregator script to figure out where the refcount math is going wrong. I didn't choose Rust for this.

@12bitfloat A very very very important Drop callback is not being called

I gave up on this particular refactoring angle because I noticed a much faster way to solve the immediate problem I was having, but I do actually want to return to it and figure out how much of a performance impact it has, because it would be really neat to speed up compilation and also to be able to separate out the client's and server's distinct implementations of certain shared concerns while retaining the shared interface.

Ideally, a debug build should be massively parallel, almost file-by-file, with no type's structure depending on the fields of any other, and a release build should be fully static, with virtual calls exclusive to heterogenous containers (of which at runtime there are like 3 in the whole system). I know C++ could do this, but Rust doesn't provide as much type information to LLVM so it benefits significantly less from these high level optimizations specifically.

@jestdotty MPSC queues are a big help.

The other side of this coin is that my barrier for something that's too complex to be serviced by a shell script is quite low. If you need xargs, you're probably past it. If you (semantically) need a conditional inside xargs, you're _definitely_ past it. If you need to edit it often, if more than one person needs to edit it, if it stores anything more than plain-value tables (either nested structure or references across tables), if it might be used by people who can't read it, or otherwise requires error handling besides basic argument validation.

The only use case on which Rust and shell scripts overlap is build automation. I love my xtask binary because it's exactly as portable as the project itself; every target is a dev target. But the same applies for any other language; your language has to have supremely shitty abstraction capabilities for it to be a bad idea to use it for build automation.

@antigermanist My testicles are the ideal size for riding the village bicycle that is your mum

Also, check your size. I'm no expert but I have three guesses, either your seat is pitched wrong causing you to slide off, or the frame is too big causing you to stretch too far forward to reach the handlebar. It took me visiting the bike shop at closing time for the repair man to see me get on the bike and point out that the piece securing the handlebar to the steering column is too long and I would be a lot more comfortable if I replaced it with a shorter or possibly an inverted one, which is far cheaper than a new smaller frame.

You're literally busting your balls to prove your masculinity when you can just ride a "women's" bike. I ride a men's because I think the straight simple truss structure is pretty. Is that a masculine reason? Do I give a fuck?

@12bitfloat well, for one, you aren't obligated to directly await the Send future, you can put it inside a higher structure like a join or a select. High performance async code does this a lot, they do as much stuff synchronously as they possibly can and parallelize the rest aggressively. This leads to really weird incentives where you don't actually want to use async closures because you would miss the opportunity to execute synchronous code before returning the future that ultimately gets nested into a weird user-side scheduling primitive tree.

Nonetheless, both language design and convention dictates that you follow thee terminology of the physical stack and only mention details like this after the simpler concepts have been established.