3 ms·

Yes there is much more mental load you pay upfront during development but once you get code working and satisfy the borrow checker you now have significantly st

Yes there is much more mental load you pay upfront during development but once you get code working and satisfy the borrow checker you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency. This is the trade off.

rhodysurf 8y ago
I understand that, I posted my response becasue the OC was presenting Rust as a replacement for Go but they are very different languages with different tradeoffs
- ilovecaching 8y ago
  Actually, the Go team even bills Go as a systems language. I think if you're going to consider Go, you should also consider what you could get with Rust. Sure the upfront investment in Rust higher, Go is almost too small, but the upfront cost of Rust is amortized via the hours you save with all the abstractions and performance you get right out of the box.
  - steveklabnik 8y ago
    They’ve moved away from “systems” as a moniker, and Rust slowly is too. It’s just too confusing of a term these days, and nobody knows what it actually means, so it’s not useful.
    - pjmlp 8y ago
      I would say if one can write OSes, device drivers, debuggers, compilers, target bare metal deployments on language X, then it is a systems language, regardless of what label people put on it.
      - pvg 8y ago
        The problem with that is it's a narrowing of the 'historical' use of the term and just confuses things further. The Go (and now Rust, it seems) people are right to move away from it.
      - kjeetgill 8y ago
        Even when Go started and used the term I don't think this is what they meant by it.
        pjmlp 8y ago
        Well given its use in Fucshia TCP/IP stack, file system management tooling, Android GPU debugger, not everyone at Google thinks like that. Likewise those universities doing OS research in Go, submitting their findings to USENIX.
zbentley 8y ago
> you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency. I agree, but I think many people assume that this is the only benefit achieved. The presence of the borrow checker and rigorous memory safety requirements allows the compiler to take substantially more advantageous paths in allocation/deallocation compared to e.g. C. The benefit attained is similar to the benefit of switching from C to very well memory-managed C++, except it comes by default. This is a significant advantage even in code that is not concurrent at all. I feel like it's a shortcoming of Rust's marketing, if anything, that the safety restrictions are often pitched only in context of thread-safety rather than memory-usage-optimization.
- deckarep 8y ago
  Yes I agree with those points as well...because Rust is now able to statically have such guarantees, this additional knowledge allows for some great optimizations under the good.

rhodysurf 8y ago

I understand that, I posted my response becasue the OC was presenting Rust as a replacement for Go but they are very different languages with different tradeoffs

ilovecaching 8y ago
Actually, the Go team even bills Go as a systems language. I think if you're going to consider Go, you should also consider what you could get with Rust. Sure the upfront investment in Rust higher, Go is almost too small, but the upfront cost of Rust is amortized via the hours you save with all the abstractions and performance you get right out of the box.
- steveklabnik 8y ago
  They’ve moved away from “systems” as a moniker, and Rust slowly is too. It’s just too confusing of a term these days, and nobody knows what it actually means, so it’s not useful.
  - pjmlp 8y ago
    I would say if one can write OSes, device drivers, debuggers, compilers, target bare metal deployments on language X, then it is a systems language, regardless of what label people put on it.
    - pvg 8y ago
      The problem with that is it's a narrowing of the 'historical' use of the term and just confuses things further. The Go (and now Rust, it seems) people are right to move away from it.
    - kjeetgill 8y ago
      Even when Go started and used the term I don't think this is what they meant by it.
      - pjmlp 8y ago
        Well given its use in Fucshia TCP/IP stack, file system management tooling, Android GPU debugger, not everyone at Google thinks like that. Likewise those universities doing OS research in Go, submitting their findings to USENIX.

zbentley 8y ago

> you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency. I agree, but I think many people assume that this is the only benefit achieved. The presence of the borrow checker and rigorous memory safety requirements allows the compiler to take substantially more advantageous paths in allocation/deallocation compared to e.g. C. The benefit attained is similar to the benefit of switching from C to very well memory-managed C++, except it comes by default. This is a significant advantage even in code that is not concurrent at all. I feel like it's a shortcoming of Rust's marketing, if anything, that the safety restrictions are often pitched only in context of thread-safety rather than memory-usage-optimization.

deckarep 8y ago
Yes I agree with those points as well...because Rust is now able to statically have such guarantees, this additional knowledge allows for some great optimizations under the good.