I recently spent 15 minutes going over a Rust futures tutorial and was then able to get a Rust program streaming live bitcoin futures (coincidence!) over websocket connections from multiple exchanges working in less than an hour.
I then then attempted to port some Python code to use Python's new async/await and was unsuccessful. I managed to get a bunch of async workers running, but only the first one would process jobs from the queue or the entire program would just hang indefinitely. Couldn't figure it out after two hours and just gave up on it.
Nice work, Rust team. This is a game changer for me.
Looking at the code, it's a nightmare to parse. There are so many details to deal with that should never bother you under normal circumstances (the core problem of using Rust where it's not necessary). It's admirable that you have such an easy time with it. However, for most people, using Rust for these purposes is absolutely not recommended.
Java/Kotlin paired with reactive streams makes these tasks super easy to read, once you get the hang of reactive streams. Also there are complexities in there, you just simply can't brush all the intricacies of network programming and multi-threading under the rug, but at least you are dealing only with the complexities that are necessary for your problem.
With Rust you are dealing with tons of additional complexity that doesn't matter to 99% of people & problems. I love that Rust exists and it has its uses (browsers, hypervisors, drivers, kernels, etc). I just find it very alienating when people compare this to Python and do everyday tasks with it.
No, you really don't want to deal with borrowing, memory management and life-times, unless it is part of the problem you are trying to solve (and there aren't too many for which that applies).
Yes, this is usually how it turns out in practice. You don't need to understand what's going on under the hood, you just string some libraries together and call it a day ;).
> However, for most people, using Rust for these purposes is absolutely not recommended.
Who are these "most people"? Can you get more specific here?
> Java/Kotlin paired with reactive streams makes these tasks super easy to read, once you get the hang of reactive streams. Also there are complexities in there, you just simply can't brush all the intricacies of network programming and multi-threading under the rug, but at least you are dealing only with the complexities that are necessary for your problem.
The text goes pretty much into detail. I do not understand where Rusts streams are more complicated than the Java/Kotlin/Scala ones? Did you
ever write an application with reactive streams and got problems with the thread pool, people unknowingly blocking in combinators, etc..?
I'd dare to say that these things also add complexity that is not necessary to the kind of problems you defined as "99% of ..."
> With Rust you are dealing with tons of additional complexity that doesn't matter to 99% of people & problems.
Where did you get that number from? What are "tons of additional complexity"?
> I just find it very alienating when people compare this to Python and do everyday tasks with it.
Maybe you just have not yet recognized that you can do everyday tasks with it?
This article is explaining how Futures work by showing you what's under the covers. You don't actually have to write this code yourself, you can just use one of many wonderful libraries that handle it all for you.
As it says in the second paragraph: "Going into the level of detail I do in this book is not needed to use futures or async/await in Rust. It's for the curious out there that want to know how it all works."
I then then attempted to port some Python code to use Python's new async/await and was unsuccessful. I managed to get a bunch of async workers running, but only the first one would process jobs from the queue or the entire program would just hang indefinitely. Couldn't figure it out after two hours and just gave up on it.
Nice work, Rust team. This is a game changer for me.