This probably isn't revelatory for many people but I think there's an entire class of expressiveness people in high level languages like TS are interested in that Rust just does... better.
72 comments · 92% upvoted · source · other discussions
Bro is discovering functional programming and monads as we speak.
Jokes aside, this is something fairly common in functional programming languages. If you think this is cool, may I recommend you learn Haskell? 😁
monads
Functor should be enough here, I think
Yeah you’re right. The monadic operations are and_then (the equivalent of >>=)/flatten (the equivalent of join) and of course Some (for return).
But if you learn Haskell you might get yelled at.
made my day <3
What's the point of going through all that pain? My OOP code does the same thing anyway right? What am I missing? Other than it being cool as hell ofc
Also what's a monad?
what’s a monad?
Why, a monoid in the category of endofunctors of course ;)
The actual answer: before defining a monad it’s probably helpful to define a functor because a monad is a specific kind of functor.
Without getting into the formal category theory definition, think of a functor as a container that you can apply a function “inside of”. Some examples
Vec<_> is a functor because given a Vec<T> and a function from T -> U, i can produce a Vec<U>. You do this via .map(f).collect()
Option<_> is a functor because given a Option<T> and a function from T -> U I can produce an Option<U>. Again the method on options that does this is .map
for any E, Result<_, E> is a functor… for the same reason as above
impl Iterator<Item=_> is a functor, similarly .map is the operation.
Futures also have such an operation, I’ll leave it as an exercise
In general, in pseudo rust syntax, a functor is something for which you could implement the following trait (if this syntax were allowed)
trait Functor {
fn fmap<T,U>(f: Fn*(T) -> U, t: Self<T>) -> Self<U>;
}
etc
A monad is a functor, where you also have some additional operations. There’s a couple equivalent ways to phrase the operations that define a monad, but I’ll give one of them. First, there’s an operation (usually called return) that puts a value into a container. So something like T -> M<T>. Think Some and Ok for result, std::iter::once, for iterator, vec![x] for vec, etc. But then there’s also a “bind” operation that is a bit more complicated.
Basically if you have a function A -> M<B> and an M<A>, bind produces an M<B>. Some examples of bind operations:
.flat_map. Given a vector of Ts and a function that takes Ts and produces a vector of Us, I can produce a vector of Us by using flat_map`. .and_then method. Why are monads useful? In general you can think of them as types of computations that have side effects and can be “chained together” and as it turns out that paradigm comes up a lot.
For example sometimes you’re writing a function where you have a bunch of steps each of which can fail (you can think of each individual step as something of the form e.g. A -> Option<B>, B -> Option<C>, C -> Option<D>, and because Option is a monad, it’s possible to chain all these together into an A -> Option<D>). Rust introduces special syntax (the ? operator) to make this ergonomic in order to make exploiting the monadic structure of Option/Result easy to use. Python has yield from when writing generators to make the monadic structure of iterators easy to exploit (and I’m sure rust will have something similar when generators land). Rust has .await to make the monadic structure of Futures easy to exploit.
Because haskell can talk about monads in general rather than on a case-by-case basis, it has a single unified syntax (do notation) that works for all monads (including ones you write yourself), which is easily one of its coolest features. Instead of having to have bespoke syntax in the language itself. Monads would be useful even without this, but it’s a good example of why the abstraction is useful.
Thank you. This was perfect.
As a native German speaker, these videos are incredibly difficult to watch.
The disconnect between trying to read and hearing is really mind-bending.
"Why don't you pattern-match my fist all over your faces?" LOL.
OMG I lost it when he named dropped Bartosz Milewski.
Ending was perfect too: "thank God you haven't discovered Prolog."
Haskell is the coolest language. I wish I had an excuse to use it but I never do.
Does Haskell even exist in production?
I had the pleasure of maintaining several Haskell services for a European e-commerce company for about a year, before ditching it for contemporary languages.
What did they need that only existed in Haskell at the time?
Nothing lol. I guess they liked the vibes and all. It was the first time I learned about STM's and I/O monads.
But that particular team also used Scala and cats ecosystem extensively as well so it was more or less an FP shop to begin with.
Yes, it's not even that uncommon. We use it for some internal tooling (agency working on games and simulations) because of how easy it makes defining DSLs and traits, and I have colleagues who use it at a large European neobank. It requires some initial investment and learning how to navigate the ecosystem, but it's a lovely choice when you need your logic to be robust, such as in finance. Although Rust is looking quite attractive as well at this point.
Everyone should learn a wide range of languages. Not necessarily to a professional level. Learning many languages definitely makes you a better developer.
My experience coming from Typescript / webdev is not so much "how do I shoehorn in functional concepts to my workflow" and more about just trying to understand specific idioms which are valuable to DX especially to "your average dev" who has never heard of Haskell. Rust might not be the sub for this because pretty much everyone already understands the advantages here, but for certain f.ex Typescript devs something like this or scope-based lifetimes might be revolutionary - not for any optimization or performance reason, but purely because the code reads and encapsulates so much better.
It actually changes how you abstract and write things at a fundamental level. Using the example from my blog: before knowing how to use .map you might write a discrete function like disconnect_client, but now because you can do it in essentially 1 line, without leaking scope, you can do so much more inline. A reason to have functions was to not muck up higher level control flow, but because Rust is so expressive it kind of gives you the best of all worlds. (Of course you would abstract the function for other actual reasons, like having a SSOT for a disconnect behavior - just an example.)
I got into functional programming thanks to typescript. Once I got used to map and filter and flatMap, and using anonymous functions to perform operations element by element it made understanding functional programming way easier.
Rust is definite a nice progression from TypeScript.
I cut my teeth on FP-TS. It's great, but the error messages are hell. A result of fitting the square FP peg into the round hole of TS.
I think TS is only a few ergonomic improvements away from handling FP much better: improved type inference for nested higher-order functions, first-class HKTs, and more customizable or expandable error messages. This hasn't been the focus for the past year, especially with all the work that goes into the port, but the last point is actually being worked on, at least for expandable hovers.
Now that I think of it, we are also missing good pattern matching, which has to be solved on the ECMAScript level, but the current proposals have been stuck for years.
I only dealt with FP during my courses but I dont see why OP needs fmap here?
map is very cool indeed. and_then is also cool. In fact and_then and map are very similar. They both take a function which you intuitively can think of as “lifting” into some data structure to perform the function on the insides. The only difference is that the and_then function also returns said data structure! But instead of ending up with data structure inside data structure, and_then flattens the nested structure so you end up with just one layer of it - like what you end up with map!
another name for the and_then function is flat_map which describes what you mentioned here, a map which flattens its type
to be a bit more specific, flat_map is the superset of and_then. it takes a function with an output of any iterator, while and_then takes a function which outputs an Option specifically (and Option is an iterator over 0 or 1 element)
They are both monadic binds. For any monadic type M it's a function that takes a value M<T>, a function Fn(T) -> M<T> and gives you a new M<T> back. Or something close to that - with Option it would be FnOnce, with Iterator you get IntoIterator somewhere in the middle, but it's the same operation.
? for Option/Result is also a monadic bind. And .await too.
thats more of a design decision of the rust std library, they are the same function
Yeah, they could be named the same and collected in a Monad trait (or possibly some other name if "Monad" is too scary). (The original name can of course be left as an alias so we don't have to deal with lots of code suddenly breaking.)
There's the Try trait to consider for that as well—they're essentially monadic do blocks.
Using map with a unit function is considered unidiomatic/hard to read
You should prefer using if let instead:
if let Some(client) = self.clients.get_mut(&user_id) {
client.status = ClientStatus::Disconnected;
}
Would inspect be considered idiomatic (if no mutation was required, of course)?
I think it would be odd unless the value being inspected is used afterwards. That is if you have a processing / extraction pipeline then inspect makes sense, but if inspect is used as the final operation (then the value is dropped) then not really.
That is
// yes
thing = foo.bar().inspect(baz)
// less yes
foo.bar().inspect(baz)
No since inspect gives you a &T so no mutation allowed
You're definitely right but I can't help feel that the procedural version mucks up the containing scope DX more. Maybe I just like fluent chains better than if blocks.
I like the syntax because it's a low-mental-overhead way to indicate that conditional computation is happening. If you scan just the shape of the code quickly, a straight-line fluent chain could mean anything from a boring straight line of statements to building and iterating a large data structure, and the only way to know is to read and recall what each method means because all of the control flow is hidden.
xxxx.xxxxxxx.xxx_xxx(&xxxx_xx).xxx(|xxxxxx| {
// ...
});
That code is shaped like a lot of potential things.
if let Xxxx(xxxxxx) = xxxx.xxxxxxx.xxx_xxx(&xxxx_xx) {
// ...
}
I already know some self-evident facts about this code. Especially the fact that the block is going to be executed exactly zero or one times.
It works out the same, as in you'll get the same error for
foo.map(|bar| …);
baz(bar);
and
if let Some(bar) = foo { … }
baz(bar);
because bar is only accessible in the if block. To actually get bar into the containing scope you need to use some unwrapping method or let Some(bar) = foo else { … return quux; };
Thing with map is that it also signifies that it's producing some value; Option<()> is borderline nonsense (it can be useful as a bool stand-in for a filter_map function where you want access to ?, but I haven't really used that outside /r/AdventOfCode-type challenges).
For iterators there's the .for_each method that also results in the unit type, but I think xs.for_each(f) is almost never used compared to for x in xs { f(x); }.
Exactly this
I prefer the following:
if let Some(client) = self.clients.get_mut(&user_id) {
client.status = ClientStatus::Disconnected;
}
Agreed. Map should be reserved for pure computations without side-effects, and if let for cases like this. It makes the intent of the code clearer.
Me too. I find it too "abrupt" when you use `map` and discard the output. It is like reading a phrase that is missing the verb. I tend to use `map` when the returned value is the star of the show. When the point is the side effect itself, the procedural style reads more natural.
I also tend to prefer if let, while let, and let ... else over closures and combinators, especially since let-chains are stable now. I find them easier to read, and I like being able to do early returns and ? handling in the loop body.
Yeah handling Result in those iterator functions feels so clunky and usually makes you jump through hoops. I prefer it this way too so I can propagate better. Same thing with handling async on them.
.filter_map and .into_iter().enumerate() are also fun
I love using iterators: map, filter, etc in Rust. The sad part is they don't work with async code. If I need to add async to some function called in `map`, I end having to rewrite it as a loop anyways.
Also dealing with `Result` in a chain of iterators is really annoying. Having to `.collect::<Result<..>>()?` feels worse than just `?` from inside a loop. I wish there was less friction around these.
I really feel this! Both Result and async become unnecessarily burdensome in iterator chains and then an otherwise amazing abstraction into a clunky pain.
I see you haven't met Effect.map 😁
Assuming self.clients is a HashMap or similar I'd prefer
self.clients.entry(&user_id).and_modify(|client| {
client.status = ClientStatus::Disconnected;
});
as I think it conveys intent much better.
You’ll LOVE Haskell
The situation in which you used it (first example) i entirely avoid using map in there.
When i think of map i think of X -> Y transformation without any side effects.
Ok but there is only one client supposedly so why are you iterating through just one item ?
Iterators are cool in Rust 😎
That's very poor in readability.
You only use .flatMap/.map, if it's in a sensible convenient short expression.
It's very recognizable if let Some(x) = { } pattern, and seldom you need the else {}, which .map just ignored it to remain nil.
It's very similar to array.map and for-loop, you tend to appreciate the syntax highlighted for when you read and optimize.
https://doc.rust-lang.org/std/option/enum.Option.html
All methods are very useful.
Please try to enjoy each method equally, and not show preference for any over the others.
why use map in this:
and not?:
It's mutating not transforming the value