14 ms·

> 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

• 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.
  • Ygg2 4y ago
    > 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. At this point, I have to say RC is a primitive form of GC and it would mostly work. Not high performance but it would work. > To be clear, I hate programming language development driven by memes. I don’t think that was the case with Rust async First, most programming is driven by fads. Second, my point was that if Rust waited more people would pan it for not having async. Rust async was "rushed". It took years, but we still didn't get smooth experience out of it. Many pieces were missing. It was rushed because many people wanted it, many developers were sick of having it in limbo, etc. > Today, in safe rust, it is impossible to allocate a structure larger than the stack. Placement new is always just around the bend. I don't follow Rust development too detailed nowadays, but if you are experiencing hardships, have you considered providing support to it? Either via money or time donations? I understand complaining that some closed source company is prohibiting you from doing something, but this is an OSS project. https://www.youtube.com/watch?v=9E_rtUgUF58 https://www.youtube.com/watch?v=9E_rtUgUF58