3 ms·
I think after the (correct) first sentence you are a bit mistaken here. The example you describe can be solved correctly and also with good performance in garba
by valenterry 4y ago
I think after the (correct) first sentence you are a bit mistaken here. The example you describe can be solved correctly and also with good performance in garbage collected languages such as Haskell or Scala. I would even say that those languages make a correct solution easier than in Rust, but they trade in a bit of performance for it (e.g. by using immutable datastructures instead of an ownership model). But for async stuff, I think this is actually simpler.
However, when performance is key, then Rust is by far the easiest solution to get it performant and still correct.
- shultays 4y ago"good performance" is a relative term. You may consider Haskell or Scala having "good performance" but for others having garbage collection itself is a big no. So you are either left with Rust's approach where you limit the programmer, or C++'s approach where you leave memory management mostly to the programmer
- valenterry 4y agoI think you missed the point here. My response was focussed on the part of the challenges of async logic. And what OP essentially said is that Rust does not only help performance because of the ownership model (vs. garbage collection), but also because it makes it easy to come up with correct and performant solution to async-related problems. My point was that, when ignoring the performance benefits of ownership model vs. garbage collection, a language like Haskell or Scala makes a performant and correct solution for async problems easier than Rust does - at least at the current point in time. I hope it's more clear now.
- NoGravitas 4y agoYou can get great performance from garbage collected languages, to be honest. I guess what you can't get is perfectly predictable latency — but that only matters for a pretty narrow class of applications.
- Hirrolot 4y agoHow then people write high-performance servers in JVM?