4 ms·

In my experience it has elements of both, but stuff like managing lifetimes means that (IMO) it's more trouble than it's worth when you're creating a web backen

by untog 7y ago

In my experience it has elements of both, but stuff like managing lifetimes means that (IMO) it's more trouble than it's worth when you're creating a web backend. Any more established garbage collected language is absolutely fine. Unless it needs to, say, run in a very resource constrained environment, in which case it's a pretty interesting possibility.

james-mcelwain 7y ago
It's certainly a less mature ecosystem, but once you get over the hump of understanding lifetimes, there's nothing preventing you from using lots of owned values and clone in a way that makes it really easy to ignore annoying lifetime problems. And, the benefit being if you ever need to get more performance out of a hot part of your code, you can always optimize to get that zero copy goodness.
- Matthias247 7y ago
  There is however a downside to the „clone everything“ approach: The performance might get worse than what it would be in an optimized GCed language that doesn’t require cloning (eg C#/Java). At least I would only reach out for Rust at the moment for performance critical code, and then don’t leave easy optimizations on the table due to lifetimes.
  - james-mcelwain 7y ago
    There are other solutions (like Rc<RefCell<T>>) that allow you to avoid cloning as well if you still don't want to deal with lifetimes.
antisemiotic 7y ago
Rust's lifetimes make it about the only language that gets shared-memory concurrency right. And I don't like the trend of pushing for message passing just because historically it was hard to do shared memory. The only thing I've found more convenient than that was software transactional memory in Haskell (monads and do notation working with it barely different than regular mutable memory), maybe by the next 10 years or so we'll get that in a mainstream language.
- whateveracct 7y ago
  To add to the STM conversation, the stm-containers libraries is insanely cool (& performing with high concurrent access!)
the_duke 7y ago
Lifetime issues are not really relevant in a classic web backend context, since you generally just pull data out of a DB and return it to a web request, or the other way around. You generally don't have to share you data structures. I do agree though that the tooling is very immature compared to other ecosystems, and Rust is generally quite boilerplate heavy and slower to develop. It can still be a good choice if you need really high performance/low resource consumption - or you are going for high correctness and robust error handling. But for most web backends Rust won't make much sense. (I say this as someone who even writes web frontends with Rust via wasm, where it is even less optimal - mainly due to the high compile times)
- bpye 7y ago
  Do you have any examples of the sort of front end work your doing with Rust? I've been toying with an idea using Rust but I haven't started really working on it.
EugeneOZ 7y ago
Not any language have such smart compiler, perfect errors handling system, "cargo" crates system. Not in every language refactoring is so nice that you can do it absolutely without fear.

by untog 7y ago

james-mcelwain 7y ago

It's certainly a less mature ecosystem, but once you get over the hump of understanding lifetimes, there's nothing preventing you from using lots of owned values and clone in a way that makes it really easy to ignore annoying lifetime problems. And, the benefit being if you ever need to get more performance out of a hot part of your code, you can always optimize to get that zero copy goodness.

Matthias247 7y ago
There is however a downside to the „clone everything“ approach: The performance might get worse than what it would be in an optimized GCed language that doesn’t require cloning (eg C#/Java). At least I would only reach out for Rust at the moment for performance critical code, and then don’t leave easy optimizations on the table due to lifetimes.
- james-mcelwain 7y ago
  There are other solutions (like Rc<RefCell<T>>) that allow you to avoid cloning as well if you still don't want to deal with lifetimes.

antisemiotic 7y ago

Rust's lifetimes make it about the only language that gets shared-memory concurrency right. And I don't like the trend of pushing for message passing just because historically it was hard to do shared memory. The only thing I've found more convenient than that was software transactional memory in Haskell (monads and do notation working with it barely different than regular mutable memory), maybe by the next 10 years or so we'll get that in a mainstream language.

whateveracct 7y ago
To add to the STM conversation, the stm-containers libraries is insanely cool (& performing with high concurrent access!)

the_duke 7y ago

Lifetime issues are not really relevant in a classic web backend context, since you generally just pull data out of a DB and return it to a web request, or the other way around. You generally don't have to share you data structures. I do agree though that the tooling is very immature compared to other ecosystems, and Rust is generally quite boilerplate heavy and slower to develop. It can still be a good choice if you need really high performance/low resource consumption - or you are going for high correctness and robust error handling. But for most web backends Rust won't make much sense. (I say this as someone who even writes web frontends with Rust via wasm, where it is even less optimal - mainly due to the high compile times)

bpye 7y ago
Do you have any examples of the sort of front end work your doing with Rust? I've been toying with an idea using Rust but I haven't started really working on it.

EugeneOZ 7y ago

Not any language have such smart compiler, perfect errors handling system, "cargo" crates system. Not in every language refactoring is so nice that you can do it absolutely without fear.