6 ms·

> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. Those three things are actually just dif

> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. Those three things are actually just different facets of the same thing: ownership. The bad news is that you must learn Rust's ownership model to use Rust idiomatically. The good news is that you can do a lot without learning Rust ownership model at all. Just clone all your values. Not advisable for production code, but great for getting over the ownership model hump.

charcircuit 4y ago
And it's not an entirely new idea. C++ has ownership too.
- arcticbull 4y ago
  C++ doesn't have a Rust-like ownership/borrow system.
  - barakm 4y ago
    I think you meant “borrow checker” because sure it does. It’s called a const reference. Want a mut borrow? That’s a pointer. That Rust can check these somewhat more explicitly (rather than via good coding style) and that C++ also allows you to do arbitrary permutations (a la non-const references) is what you’re talking about. But ownership is very very real in C++! Just look at the craziness that is move semantics!
    - synergy20 4y ago
      and its unique pointers
    - deleted 4y ago
      [deleted]
    - arcticbull 4y ago
      > I think you meant “borrow checker” because sure it does. It’s called a const reference. Want a mut borrow? That’s a pointer. These have very different semantics. Lexically you can only have either 1 mutable reference or N immutable references at a time to a given object. This is the foundation for a lot of the safety and aliasing [2] guarantees. Just because they both use an '&' doesn't make them equivalent! :) Don't get my started on `std::move` which doesn't really move, and continues to allow you to use the source object - in whatever condition it may be in. These are also not the same. C++ move semantics are sort of the 'ruined fresco' [1] of Rust move semantics. [1] https://www.npr.org/sections/thetwo-way/2012/09/20/161466361/woman-who-ruined-fresco-of-jesus-now-wants-to-be-paid https://www.npr.org/sections/thetwo-way/2012/09/20/161466361... [2] https://doc.rust-lang.org/nomicon/aliasing.html https://doc.rust-lang.org/nomicon/aliasing.html
jeffparsons 4y ago
And once you've learnt those things and got some experience writing real world software in Rust, you may well find yourself more productive in Rust than, say Ruby on Rails. Context matters a lot, and you shouldn't be making tech choices based on the way the wind is blowing ("tech radars", what's hot in the blogosphere, etc.). If hiring teams to work on your mostly-CRUD app easily is a high priority, then Rust probably isn't a good choice. If you have a team that already knows Rust, and you need to add some web app / service, then Rust is a perfectly fine choice, on the grounds that support for web stuff is "good enough" now, and the best tool for the job is often the one you already know well and are already supporting. If I'm building stuff for _myself_ and it's getting too fiddly for a bash script, then I'll always default to Rust just because _personally_ I'm way more productive in it than anything else. Context, context, context.
zozbot234 4y ago
> Not advisable for production code If your alternative is Python or Ruby, then cloning your values is perfectly OK for production code. It will still run very fast.

charcircuit 4y ago

And it's not an entirely new idea. C++ has ownership too.

arcticbull 4y ago
C++ doesn't have a Rust-like ownership/borrow system.
- barakm 4y ago
  I think you meant “borrow checker” because sure it does. It’s called a const reference. Want a mut borrow? That’s a pointer. That Rust can check these somewhat more explicitly (rather than via good coding style) and that C++ also allows you to do arbitrary permutations (a la non-const references) is what you’re talking about. But ownership is very very real in C++! Just look at the craziness that is move semantics!
  - synergy20 4y ago
    and its unique pointers
  - deleted 4y ago
    [deleted]
  - arcticbull 4y ago
    > I think you meant “borrow checker” because sure it does. It’s called a const reference. Want a mut borrow? That’s a pointer. These have very different semantics. Lexically you can only have either 1 mutable reference or N immutable references at a time to a given object. This is the foundation for a lot of the safety and aliasing [2] guarantees. Just because they both use an '&' doesn't make them equivalent! :) Don't get my started on `std::move` which doesn't really move, and continues to allow you to use the source object - in whatever condition it may be in. These are also not the same. C++ move semantics are sort of the 'ruined fresco' [1] of Rust move semantics. [1] https://www.npr.org/sections/thetwo-way/2012/09/20/161466361/woman-who-ruined-fresco-of-jesus-now-wants-to-be-paid https://www.npr.org/sections/thetwo-way/2012/09/20/161466361... [2] https://doc.rust-lang.org/nomicon/aliasing.html https://doc.rust-lang.org/nomicon/aliasing.html

jeffparsons 4y ago

And once you've learnt those things and got some experience writing real world software in Rust, you may well find yourself more productive in Rust than, say Ruby on Rails. Context matters a lot, and you shouldn't be making tech choices based on the way the wind is blowing ("tech radars", what's hot in the blogosphere, etc.). If hiring teams to work on your mostly-CRUD app easily is a high priority, then Rust probably isn't a good choice. If you have a team that already knows Rust, and you need to add some web app / service, then Rust is a perfectly fine choice, on the grounds that support for web stuff is "good enough" now, and the best tool for the job is often the one you already know well and are already supporting. If I'm building stuff for _myself_ and it's getting too fiddly for a bash script, then I'll always default to Rust just because _personally_ I'm way more productive in it than anything else. Context, context, context.

zozbot234 4y ago

> Not advisable for production code If your alternative is Python or Ruby, then cloning your values is perfectly OK for production code. It will still run very fast.