3 ms·

This comment echoes a common sentiment of Rust and Go somehow being in the same category (maybe because of the "systems programming language" buzzphrase) but th

by jhugo 6y ago

This comment echoes a common sentiment of Rust and Go somehow being in the same category (maybe because of the "systems programming language" buzzphrase) but they're really not. Comparing a language with a fairly significant runtime and garbage collection to a language with basically no runtime and strict (albeit largely automated) compile-time memory management is comparing chalk and cheese. You might as well say "I tried C++ but ended up going with Python because it was quicker to code" -- of course it was!

davidkunz 6y ago
I don't think we should dismiss these comments so eagerly. Take a look at Nim - it's fast, efficient and elegant without the huge syntax overhead of Rust.
- duckerude 6y ago
  Isn't Nim's niche closer to Go's than to Rust's? It has garbage collection, at least by default.
  - davidkunz 6y ago
    I'm not an expert in Nim, so it would be great if others could jump in. But to my understanding, Nim's ORC "garbage collector" (I'd rather call it memory strategy) is very similar to Rust's approach, it's based on reference counting (RC). It can also handle cyclic references. See here for more details: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...
    - withoutboats2 6y ago
      It is not at all like Rust; it is a garbage collection system based on reference counting, pretty similar to Swift. This is obscured by the documentation for each using similar terminology (like "move semantics" and "ownership") to refer to systems with different characteristics.
      - davidkunz 6y ago
        Thanks for clarification withoutboats2! It's really confusing as Nim's move semantics "feel" very similar to Rust's (except that Nim is more relaxed regarding "use after move" - it simply performs a copy). I'll need to learn a lot more about the different concepts.
edflsafoiewq 6y ago
If the desideratum is "I want a decently fast language that compiles to standalone binaries", which would be normal for CLI tools, then they certainly are in the running against each other. Having a runtime or a GC isn't that important of a consideration for most software I would think.
- cle 6y ago
  To me, the sentiment seems to be that Rust is explicitly tailored for code that cares about no runtime overhead. If you don't have those requirements, then don't use Rust. This is why I reach for Go by default when writing CLI tools. You will get your job done faster, and it will be much easier to understand and maintain. You will be trading off many of the static guarantees that Rust gives, but it's worth it for CLI tools, most of the time. If you are writing code with strict performance requirements, then consider Rust. Otherwise you'll likely be adding a whole bunch of complexity for not much gain, and your code will require much more cognitive overhead to understand and contribute to.

by jhugo 6y ago

davidkunz 6y ago

I don't think we should dismiss these comments so eagerly. Take a look at Nim - it's fast, efficient and elegant without the huge syntax overhead of Rust.

duckerude 6y ago
Isn't Nim's niche closer to Go's than to Rust's? It has garbage collection, at least by default.
- davidkunz 6y ago
  I'm not an expert in Nim, so it would be great if others could jump in. But to my understanding, Nim's ORC "garbage collector" (I'd rather call it memory strategy) is very similar to Rust's approach, it's based on reference counting (RC). It can also handle cyclic references. See here for more details: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...
  - withoutboats2 6y ago
    It is not at all like Rust; it is a garbage collection system based on reference counting, pretty similar to Swift. This is obscured by the documentation for each using similar terminology (like "move semantics" and "ownership") to refer to systems with different characteristics.
    - davidkunz 6y ago
      Thanks for clarification withoutboats2! It's really confusing as Nim's move semantics "feel" very similar to Rust's (except that Nim is more relaxed regarding "use after move" - it simply performs a copy). I'll need to learn a lot more about the different concepts.

edflsafoiewq 6y ago

If the desideratum is "I want a decently fast language that compiles to standalone binaries", which would be normal for CLI tools, then they certainly are in the running against each other. Having a runtime or a GC isn't that important of a consideration for most software I would think.

cle 6y ago
To me, the sentiment seems to be that Rust is explicitly tailored for code that cares about no runtime overhead. If you don't have those requirements, then don't use Rust. This is why I reach for Go by default when writing CLI tools. You will get your job done faster, and it will be much easier to understand and maintain. You will be trading off many of the static guarantees that Rust gives, but it's worth it for CLI tools, most of the time. If you are writing code with strict performance requirements, then consider Rust. Otherwise you'll likely be adding a whole bunch of complexity for not much gain, and your code will require much more cognitive overhead to understand and contribute to.