5 ms·

The difference between C++ and Rust here is that Rust has a large variety of easily-accessible third-party libraries you can drop in with a one-line change to y

The difference between C++ and Rust here is that Rust has a large variety of easily-accessible third-party libraries you can drop in with a one-line change to your Cargo.toml. I think the assessment is no longer that straight-forward. There's some solid crates for building these types of endpoints now, but an honest self-assessment is required to see if it really meets your needs from a staffing perspective. I'm a Rust-stan for sure, but I probably wouldn't use it for this task either as it'll be hard to find other people who know how to use it - and also for this task. Here's hoping that changes, though. [edit] I might also add it's not a good fit for making these types of endpoints at a startup as the goal of a startup isn't really to write perfect/correct/safe code, but rather to ship a product as fast as you can so you can iterate on the product-market fit. Quick and dirty in another language is probably a better fit for the business case. Rewrite it later.

ilyt 4y ago
Right, but you're company that needs to hire people to write that. It's entirely fine if you're already a team that knows Rust, but if you have a need for an app you need to hire more devs to build, picking the "obvious" stack usually comes with benefit of being able to recruit people more easily.
KingLancelot 4y ago
marsven_422 4y ago
3a2d29 4y ago
You can find a GC language that does all those things that rust does but without: 1. The risk of future unsafety (a GC language will always safer than rust) 2. Faster development that's easier to change on a dime. 3. No risk of memory leaks (which can happen in safe rust)
- arcticbull 4y ago
  > 1. The risk of future unsafety (a GC language will always safer than rust) [citation needed] > 2. Faster development that's easier to change on a dime. Yes, development can be faster at the expense of safety, which is a trade-off that favors the use of other languages at early company stages. Agreed here. > 3. No risk of memory leaks (which can happen in safe rust) ... at the expense of making collection non-deterministic and significantly more resource intensive. Not to mention that the non-determinism means you generally end up grafting your own resource management scheme on top. I've never seen a company that hasn't at some point had someone crying over GC tuning. Leaks are safe (which is why they're allowed in safe Rust) and generally speaking both a non-issue - and very easy to track down. Rust has been my daily driver at home since like 2015, and I have to say, I've never once gone "man you know what this thing needs? Shenandoah." I write a bunch of Kotlin too, for what it's worth. These trade-offs are well known and there are pros and cons to both.
  - 3a2d29 4y ago
    1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe. 2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it. 3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.
    - arcticbull 4y ago
      > 1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe. That's not what you originally claimed though. You made some claims about 'risk of future unsafety' and I'm not sure what that means? For the second half of your claim, Rust's safety guarantees extend well past memory safety - and a collector doesn't guarantee memory safety at all. Yes, most GC'd languages are memory safe too. However, you can just strap the Boehm GC to C or C++ [2] and that doesn't suddenly, magically, make it memory safe. > 2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it. Safety means a lot of different things. GC isn't a replacement for safe Rust. Rust offers many kinds of safety, memory safety is just one. And yeah, unsafe is a tool for implementing certain things that cannot be expressed in safe Rust, but it's extremely rare that you would dip into it in production code. It's more for library authors who wrap unsafe APIs in safe ones. If you're curious what 'safe' rust really means and why the GC doesn't subsume all its features - and the difference between safe and unsafe Rust - I'd recommend [1]. > 3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them. Sure in embedded it can be hard, but on a PC you can just use valgrind or the leaks tool. If you're writing embedded code in Rust just don't use Rc or Arc boxes and you can't form a cycle. Remember there's no reference counting in Rust at runtime unless you opt into it with a shared-ownership reference-counting box. All Rust's reference counting happens in the compiler and once the compiler determines your object is no longer referenced, it drops it. If it cannot make that determination statically your build will fail. Reference counting is generally how resources are managed in GC'd languages since you're explicitly not to rely on the finalizer ever being called. Files, sockets, etc. It's just trading off one kind of problem for another. [edit] Note that you can also leak memory in a GC'd language by keeping a reference to objects you no longer need - for instance, in some long-lived dictionary or array, or in a static. [3] [1] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html [2] https://hboehm.info/gc/ https://hboehm.info/gc/ [3] https://www.lucidchart.com/techblog/2017/10/30/the-dangers-of-garbage-collected-languages/ https://www.lucidchart.com/techblog/2017/10/30/the-dangers-o...
pjmlp 4y ago
C++ already has that problem sorted out with Conan and vcpkg.
- arcticbull 4y ago
  Sure package managers exist, but there isn't really one that everyone has aligned on. That's a huge benefit of Cargo, and also of npm. Like a lot of C++ things there's a big theme of "can we have X? we have X at home. X at home: o_O"
  - pjmlp 4y ago
    The amount of packages don't matter, as long as the key ones are available, and they are there on both. No need to compete against npm. They also have an advantage over cargo, specially Conan, binary repos, no need to recompile the world for 3rd party dependencies after each git clone.

ilyt 4y ago

Right, but you're company that needs to hire people to write that. It's entirely fine if you're already a team that knows Rust, but if you have a need for an app you need to hire more devs to build, picking the "obvious" stack usually comes with benefit of being able to recruit people more easily.

KingLancelot 4y ago

marsven_422 4y ago

3a2d29 4y ago

You can find a GC language that does all those things that rust does but without: 1. The risk of future unsafety (a GC language will always safer than rust) 2. Faster development that's easier to change on a dime. 3. No risk of memory leaks (which can happen in safe rust)

arcticbull 4y ago
> 1. The risk of future unsafety (a GC language will always safer than rust) [citation needed] > 2. Faster development that's easier to change on a dime. Yes, development can be faster at the expense of safety, which is a trade-off that favors the use of other languages at early company stages. Agreed here. > 3. No risk of memory leaks (which can happen in safe rust) ... at the expense of making collection non-deterministic and significantly more resource intensive. Not to mention that the non-determinism means you generally end up grafting your own resource management scheme on top. I've never seen a company that hasn't at some point had someone crying over GC tuning. Leaks are safe (which is why they're allowed in safe Rust) and generally speaking both a non-issue - and very easy to track down. Rust has been my daily driver at home since like 2015, and I have to say, I've never once gone "man you know what this thing needs? Shenandoah." I write a bunch of Kotlin too, for what it's worth. These trade-offs are well known and there are pros and cons to both.
- 3a2d29 4y ago
  1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe. 2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it. 3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.
  - arcticbull 4y ago
    > 1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe. That's not what you originally claimed though. You made some claims about 'risk of future unsafety' and I'm not sure what that means? For the second half of your claim, Rust's safety guarantees extend well past memory safety - and a collector doesn't guarantee memory safety at all. Yes, most GC'd languages are memory safe too. However, you can just strap the Boehm GC to C or C++ [2] and that doesn't suddenly, magically, make it memory safe. > 2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it. Safety means a lot of different things. GC isn't a replacement for safe Rust. Rust offers many kinds of safety, memory safety is just one. And yeah, unsafe is a tool for implementing certain things that cannot be expressed in safe Rust, but it's extremely rare that you would dip into it in production code. It's more for library authors who wrap unsafe APIs in safe ones. If you're curious what 'safe' rust really means and why the GC doesn't subsume all its features - and the difference between safe and unsafe Rust - I'd recommend [1]. > 3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them. Sure in embedded it can be hard, but on a PC you can just use valgrind or the leaks tool. If you're writing embedded code in Rust just don't use Rc or Arc boxes and you can't form a cycle. Remember there's no reference counting in Rust at runtime unless you opt into it with a shared-ownership reference-counting box. All Rust's reference counting happens in the compiler and once the compiler determines your object is no longer referenced, it drops it. If it cannot make that determination statically your build will fail. Reference counting is generally how resources are managed in GC'd languages since you're explicitly not to rely on the finalizer ever being called. Files, sockets, etc. It's just trading off one kind of problem for another. [edit] Note that you can also leak memory in a GC'd language by keeping a reference to objects you no longer need - for instance, in some long-lived dictionary or array, or in a static. [3] [1] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html [2] https://hboehm.info/gc/ https://hboehm.info/gc/ [3] https://www.lucidchart.com/techblog/2017/10/30/the-dangers-of-garbage-collected-languages/ https://www.lucidchart.com/techblog/2017/10/30/the-dangers-o...

pjmlp 4y ago

C++ already has that problem sorted out with Conan and vcpkg.

arcticbull 4y ago
Sure package managers exist, but there isn't really one that everyone has aligned on. That's a huge benefit of Cargo, and also of npm. Like a lot of C++ things there's a big theme of "can we have X? we have X at home. X at home: o_O"
- pjmlp 4y ago
  The amount of packages don't matter, as long as the key ones are available, and they are there on both. No need to compete against npm. They also have an advantage over cargo, specially Conan, binary repos, no need to recompile the world for 3rd party dependencies after each git clone.