Hacker News Reader

Comment by loeg | Hacker News Reader

Sure. Go is a garbage-collected language with an immature and unsophisticated compiler toolchain, compared to the big free C compilers like GCC or Clang. The compiler limitations are solvable but GC is a core part of the language. Interoperability with C libraries is possible but not great.

Rust is built on LLVM, much like Clang. C integration is relatively easy. I think this is more viable than Go. Unfortunately, Rust is only portable to platforms LLVM supports. While that covers the majority of commonly used hardware today, it is not comprehensive. Also, Rust compile times are pretty bad, especially for optimized builds.

At the end of the day the author gets to write code in a language of their choice to scratch their own itch. End users don't care at all what language a web framework is written in.

View on HN

Rust is no more a garbage collected language than C is. Just as one can implement reference counting in C, one can do the same in Rust, but it is not forced on you just like it is not forced on you in C.

I consider the standard libraries part of the language. C stdlib does not include ref counting, nor is there any refcounting construct available without building it yourself. Rust obviously has Rc<> and Arc<>.

> Rust obviously has Rc<> and Arc<> and uses it widely in the standard library.

No, it's not. None of the core data structures (String, Vec, HashMap, BTreeMap, VecDeque), for example, use it.

Rust is not a garbage collected language in any meaningful sense of the word. Its runtime is approximately the same size as C's, and the vast majority of all memory management in the Rust ecosystem is done with traditional malloc/free calls. The only difference between Rust and C at this level is that Rust inserts those calls for you automatically. In exchange, the space of programs accepted by the Rust compiler is smaller than what is accepted by a C compiler.

> At the moment it is a garbage-collected language but IIRC they are trying to move away from that as a requirement.

No, we're not. Because no such requirement exists and the vast majority of Rust code doesn't use reference counting at all. If anything, there are some folks that have looked into adding tracing garbage collection to Rust as a library.

> In exchange, the space of programs accepted by the Rust compiler is smaller than what is accepted by a C compiler.

The space of safe programs accepted by Rust is indeed smaller, but you can use the `unsafe` keyword if that is an issue. There are even automated transpilers from C to `unsafe` Rust.

As far as I know rust isn't garbage collected

Reference counting is a form of GC.

https://words.steveklabnik.com/borrow-checking-escape-analys...

Rust doesn't do runtime garbage collection. It "garbage collects" at compile time, in a highly optimized way, the same way a human would by manually writing "free". My understanding is that Rust does this well enough that there isn't really a performance cost compared to C.

Edit: I see your other comment about the use of Arc and Rc in the stdlib, that is a good point. However, how much does that actually matter? I'm genuinely curious, my guess is that it is not significant, but I'm not well informed. For example, would that affect embedded use cases?

Reply on news.ycombinator.com