4 ms·

> I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I don't

> I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I don't think one can care about speed and correctness without caring about lifetimes and ownership. Even if you do not care about memory ownership and use garbage collection, there are plethora of other things that you take care of. For example, if you've juts sent an RPC/HTTP request, and a user closed a particular window, should you abort the request or not? What if the user have closed all windows except one? Can they actually close window X without doing something in window Y first? What should happen if you forgot to abort the request and now the callback is called, but the original caller is gone?

taneq 4y ago
I feel this fact is grossly underappreciated. Caring about speed and correctness but not ownership and lifetimes (and thread safety and race conditions and...) is like caring about road safety but not caring about headlights. You're not avoiding ownership and lifetime problems, you're just avoiding looking at them.
- preseinger 4y ago
  Thread safety, and memory model safety, and all this important stuff, is important! But ownership and lifetimes are models of reality that Rust asserts as part of its domain language, which, like all models, are approximations of reality, not reality itself. They're useful to the extent that they help to solve a given problem. And not all problems fit into the assumptions that they assert.
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 ago
    I 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 ago
  You 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 ago
    How then people write high-performance servers in JVM?

taneq 4y ago

I feel this fact is grossly underappreciated. Caring about speed and correctness but not ownership and lifetimes (and thread safety and race conditions and...) is like caring about road safety but not caring about headlights. You're not avoiding ownership and lifetime problems, you're just avoiding looking at them.

preseinger 4y ago
Thread safety, and memory model safety, and all this important stuff, is important! But ownership and lifetimes are models of reality that Rust asserts as part of its domain language, which, like all models, are approximations of reality, not reality itself. They're useful to the extent that they help to solve a given problem. And not all problems fit into the assumptions that they assert.

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 ago
  I 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 ago
You 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 ago
  How then people write high-performance servers in JVM?