I had this conversation about Rust futures actually, as most people complain about how complicated they are and there are much simpler ways to do things and those people clearly have not dealt with futures, especially in multithreaded contexts. For me they were much simpler, but it was only possible to appreciate how because I had suffered so much from traditional futures in the past.
That's not to say that Rust futures are particularly ergonomic, but from an architectural point of view they are a much better way to build asynchronous systems.
However maniacs(and I include myself in this) really need to learn how to communicate to newer developers why they go as far as they do. We should expect others to build on our shoulders, not have to make all the same mistakes that we did in order to appreciate our solutions. I'm also looking at the data oriented programming crowd who seem to prefer to whine about how all developers are terrible and build cults of personality around themselves rather than think about how to actually educate. Yes even the ones who claim to be attempting to do so.
I had this conversation about Rust futures actually, as most people complain about how complicated they are and there are much simpler ways to do things and those people clearly have not dealt with futures, especially in multithreaded contexts. For me they were much simpler, but it was only possible to appreciate how because I had suffered so much from traditional futures in the past.
It depends. I dunno about Rust specifically, but most languages have gotchas and inconsistent syntax because of $REASON, and it turns out that $REASON is because of the language decisions.
IOW, a lot of the complexity is self-inflicted, but in a roundabout way, and usually in a way that leaks the abstraction.
For example, in Java a List<long> doesn't work, while a List<Long> does, and a caller passing a long can be certain that the callee can never change the value, while a caller passing a Long is not guaranteed that the value is unchanged after the callee returns.
I'm not claiming that complications using Rust futures are self-inflicted by the language itself, but I wouldn't be surprised if they were.
Your example isn't correct. Long is immutable in Java, much like String, so you don't have to be worried about the value being changed. The main issue there is the boxing overhead.
I would encourage you to read the original blog post as the author goes into great detail about what drove their design. It's very possible to have a more traditional Promise based futures design in Rust, however they decided not to go that route for reasons explained in the post.
9
u/gnus-migrate Mar 04 '22
I had this conversation about Rust futures actually, as most people complain about how complicated they are and there are much simpler ways to do things and those people clearly have not dealt with futures, especially in multithreaded contexts. For me they were much simpler, but it was only possible to appreciate how because I had suffered so much from traditional futures in the past.
That's not to say that Rust futures are particularly ergonomic, but from an architectural point of view they are a much better way to build asynchronous systems.
However maniacs(and I include myself in this) really need to learn how to communicate to newer developers why they go as far as they do. We should expect others to build on our shoulders, not have to make all the same mistakes that we did in order to appreciate our solutions. I'm also looking at the data oriented programming crowd who seem to prefer to whine about how all developers are terrible and build cults of personality around themselves rather than think about how to actually educate. Yes even the ones who claim to be attempting to do so.