4 ms·

> And worse, async in Rust is viral So just like in Java, C#, Python, ... In other words asynchrony is viral.

by Ygg2 4y ago

jchw 4y ago
I feel like I should respond here. Yes. The async mechanism is similar to Java, C# and Python. However, all of those languages you listed are JIT’d languages with automatic memory management. In Rust, the mantra is very much “zero (runtime) cost abstraction” much like C++, and unlike Java, unlike C#, unlike JavaScript, unlike Python, unlike Ruby, etc. And being a language that deals with performance critical, possibly latency sensitive applications, running on potentially very strapped embedded devices, Rust libraries very much do try to provide you with the absolute best case performance. With JS, everything being async is completely reasonable because control flow always returns to the event loop anyways. With JS, Java and C#, the runtime performance is plenty fast to do some harder compute tasks, but most of the compute is spent in large abstractions and the applications are still largely I/O bound. With Python, all of that applies except the runtime performance is a fair bit worse, too. At the bottom of all of these languages is a runtime written in low level code and often times third-party modules using C++. Rust is different. Firstly, Rust is the language at the bottom. Given all of that, almost any library has to support sync and async for ideal characteristics; there’s no good way to use sync libraries in async and visa versa. But because of the differences Rust has to other higher level language, it’s much harder to accomplish this without thoroughly duplicating code. While it might never matter if you insist on never writing stuff you’d consider library code, it’s still a design issue, it still impacts the ecosystem, and indirectly, it still will impact you. I hold that I believe the ecosystem is already strained to try to make fully idiomatic, zero-compromises libraries, and the additional pressure of async bends the story until it breaks. It’s true that Rust’s design for async is not terribly unique, but I feel it is in a uniquely poor position, for unfortunate reasons that are not necessarily the fault of the Rust developers or designers.
- Ygg2 4y ago
  > However, all of those languages you listed are JIT’d languages with automatic memory management. Granted. However, if you mix and match sync with async code in Java, C#. You're going to have a very bad time™. At runtime. Article https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... Predates stable Rust. Rust didn't somehow add virality to async. It was viral from the start. And using Rust async with Arc/Box/Pin/etc. works more or less like in GC-land. > I hold that I believe the ecosystem is already strained Strained? Not really. Async imo is a bit overblown. Most libs I am contributing don't use async at all. My opinion is that async was rushed. Pin needed for Async was a well-spring of unsoundness issues, probably still is. Async fn in traits is missing. GATs, etc. Features that would remove some issues mentioned in the article are being worked on. But then people would be it's 2022 and no async in Rust, joke lang amirite. Damned if you do, damned if you don't.
  - jchw 4y ago
    Yes, async is viral in those other languages; but the solution is usually, just use async everywhere. That’s not the solution in Rust. It simply won’t work for the same reason that Rust isn’t GC’d. > Features that would remove some issues mentioned in the article are being worked on. But then people would be it's 2022 and no async in Rust, joke lang amirite. To be clear, I hate programming language development driven by memes. I don’t think that was the case with Rust async; I think Rust async was released because it was hotly anticipated. It was definitely, at least in my opinion, the reason why Go implemented generics (at least ahead of other potentially more useful changes…) And yes, it is true: they can technically fix many of these pain points. But I flatly disagree with your notion that the ecosystem is not having difficulty with this, and I also don’t think there is good reason to be optimistic about the timelines for fixing some of these harder problems. On the ecosystem. I could point to numerous examples, though I really don’t want to single any out. The NATS client library for Rust is an example where I found myself surprised: outwardly, everything looks like it’s in good shape, but internally, it is using Unblock to mash sync code into an async world, which apparently uses a thread pool limited to 500 threads. Now I don’t know how many libraries inappropriately use this strategy, but the fact that it exists and has found use in decently popular production software is not a good sign. Again, I don’t want to start crapping on a bunch of projects, so I’m leaving it at this. On optimism for fixing the problem: I think that Rust has made immense progress on resolving issues that have come up and building features around painpoints. However, when it comes to issues around memory management, pinning, etc. there’s been a lot of nearly-intractable issues: technically, they can be solved, but they aren’t being solved. Today, in safe rust, it is impossible to allocate a structure larger than the stack. Placement new is always just around the bend. Rust genuinely delivers on many of its promises W.R.T. safety, so it is immensely disappointing to me how often I’ve run into this problem. I know structures that are bigger than the stack may seem niche, but the stack really isn’t that big, and as far as I know there’s not even a guaranteed size, so if you test on Linux your app may very well work just fine, but then you run it on Windows and it all explodes. To me this is a worst case scenario of failure cases… and I think this is the easiest and most basic conundrum out of all of them. That doesn’t mean it’s easy to fix, of course, but still. Maybe what they’ve released now is better than nothing, but I do believe the ecosystem suffers for all of the added complexity and duplication. Writing good Rust library code is not easy.

> And worse, async in Rust is viral So just like in Java, C#, Python, ... In other words asynchrony is viral.

by Ygg2 4y ago

> And worse, async in Rust is viral So just like in Java, C#, Python, ... In other words asynchrony is viral.

jchw 4y ago

I feel like I should respond here. Yes. The async mechanism is similar to Java, C# and Python. However, all of those languages you listed are JIT’d languages with automatic memory management. In Rust, the mantra is very much “zero (runtime) cost abstraction” much like C++, and unlike Java, unlike C#, unlike JavaScript, unlike Python, unlike Ruby, etc. And being a language that deals with performance critical, possibly latency sensitive applications, running on potentially very strapped embedded devices, Rust libraries very much do try to provide you with the absolute best case performance. With JS, everything being async is completely reasonable because control flow always returns to the event loop anyways. With JS, Java and C#, the runtime performance is plenty fast to do some harder compute tasks, but most of the compute is spent in large abstractions and the applications are still largely I/O bound. With Python, all of that applies except the runtime performance is a fair bit worse, too. At the bottom of all of these languages is a runtime written in low level code and often times third-party modules using C++. Rust is different. Firstly, Rust is the language at the bottom. Given all of that, almost any library has to support sync and async for ideal characteristics; there’s no good way to use sync libraries in async and visa versa. But because of the differences Rust has to other higher level language, it’s much harder to accomplish this without thoroughly duplicating code. While it might never matter if you insist on never writing stuff you’d consider library code, it’s still a design issue, it still impacts the ecosystem, and indirectly, it still will impact you. I hold that I believe the ecosystem is already strained to try to make fully idiomatic, zero-compromises libraries, and the additional pressure of async bends the story until it breaks. It’s true that Rust’s design for async is not terribly unique, but I feel it is in a uniquely poor position, for unfortunate reasons that are not necessarily the fault of the Rust developers or designers.

Ygg2 4y ago
> However, all of those languages you listed are JIT’d languages with automatic memory management. Granted. However, if you mix and match sync with async code in Java, C#. You're going to have a very bad time™. At runtime. Article https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... Predates stable Rust. Rust didn't somehow add virality to async. It was viral from the start. And using Rust async with Arc/Box/Pin/etc. works more or less like in GC-land. > I hold that I believe the ecosystem is already strained Strained? Not really. Async imo is a bit overblown. Most libs I am contributing don't use async at all. My opinion is that async was rushed. Pin needed for Async was a well-spring of unsoundness issues, probably still is. Async fn in traits is missing. GATs, etc. Features that would remove some issues mentioned in the article are being worked on. But then people would be it's 2022 and no async in Rust, joke lang amirite. Damned if you do, damned if you don't.
- jchw 4y ago
  Yes, async is viral in those other languages; but the solution is usually, just use async everywhere. That’s not the solution in Rust. It simply won’t work for the same reason that Rust isn’t GC’d. > Features that would remove some issues mentioned in the article are being worked on. But then people would be it's 2022 and no async in Rust, joke lang amirite. To be clear, I hate programming language development driven by memes. I don’t think that was the case with Rust async; I think Rust async was released because it was hotly anticipated. It was definitely, at least in my opinion, the reason why Go implemented generics (at least ahead of other potentially more useful changes…) And yes, it is true: they can technically fix many of these pain points. But I flatly disagree with your notion that the ecosystem is not having difficulty with this, and I also don’t think there is good reason to be optimistic about the timelines for fixing some of these harder problems. On the ecosystem. I could point to numerous examples, though I really don’t want to single any out. The NATS client library for Rust is an example where I found myself surprised: outwardly, everything looks like it’s in good shape, but internally, it is using Unblock to mash sync code into an async world, which apparently uses a thread pool limited to 500 threads. Now I don’t know how many libraries inappropriately use this strategy, but the fact that it exists and has found use in decently popular production software is not a good sign. Again, I don’t want to start crapping on a bunch of projects, so I’m leaving it at this. On optimism for fixing the problem: I think that Rust has made immense progress on resolving issues that have come up and building features around painpoints. However, when it comes to issues around memory management, pinning, etc. there’s been a lot of nearly-intractable issues: technically, they can be solved, but they aren’t being solved. Today, in safe rust, it is impossible to allocate a structure larger than the stack. Placement new is always just around the bend. Rust genuinely delivers on many of its promises W.R.T. safety, so it is immensely disappointing to me how often I’ve run into this problem. I know structures that are bigger than the stack may seem niche, but the stack really isn’t that big, and as far as I know there’s not even a guaranteed size, so if you test on Linux your app may very well work just fine, but then you run it on Windows and it all explodes. To me this is a worst case scenario of failure cases… and I think this is the easiest and most basic conundrum out of all of them. That doesn’t mean it’s easy to fix, of course, but still. Maybe what they’ve released now is better than nothing, but I do believe the ecosystem suffers for all of the added complexity and duplication. Writing good Rust library code is not easy.