Hacker News Reader

Comment by jfkebwjsbx | Hacker News Reader

Rust (and others like D, Ada, Zig...) won't be ubiquitous because it is a systems programming language intended to replace C and C++. This kind of languages are specialized and more costly to develop in them.

Everything else (the world of Java, C#, Go, Python, JavaScript, Swift, etc.), which is the majority of the programming done nowadays, will stay the same.

View on HN

I don't think "more costly" is true across the board. I think it might be more a matter of taste, in terms of which costs you prefer. Rust is often higher-cost in terms of up front design and development time to get something working. But the resulting program might have lower costs in terms of debugging and downtime afterwards. This distinction is especially strong when the program is multithreaded.

Not really. Many other mainstream languages give you memory safety, strict type systems and overall robustness without having to deal with memory management or low-level details.

Even for parallelism this holds true. I would say it is even more pronounced there, in fact. Some high-level languages even come with simple, effective ways of doing parallelism without multithreading, which simplifies problems a lot.

Of course, they may not reach the top performance that C++ or Rust might, but that is the trade off. Performance vs. development cost.

I'm surprised that you put Go in the latter group and not in the same group as Rust and C/C++.

What features of Go disqualify it as a systems programming language?

It’s not that fantastic for low level systems programming due to garbage collection and the runtime. If you’re working with C et al, you’re generally doing something that requires extreme control, and Go is too high level to do that nicely - you can use it of course, but it’s just... weird.

C++ is not really a low level systems language because, very broadly speaking, low level stuff doesn’t benefit as much from the extreme flexibility and abstraction capabilities of C++. It’s used more as a high-performance application programming language for large, complex stuff. Go doesn’t fit that niche because it’s just not a very powerful language.

The niche where a simple language like Go is applicable for systems stuff without being too slow or high-level is extremely small. It’s a fantastic language for working on business-logic type stuff, web backends, etc, and excels when working with less experienced developers or larger teams. It’s as easy as python et al but actually has reasonable performance. But it’s not really a systems language for serious systems stuff.

Automatic heap allocation and garbage collection are big ones. People debate this endlessly, and it's true that undeniably-systems-ish software projects like Docker and CockroachDB are written in Go. But at the end of the day there will always be some systems that cannot be written in Go because of how it manages memory, which is not the case with C, C++, or Rust.

Well thats just like how one might say numpy is written in python, so portion of it certainly is but all the heavy lifing is done by C, the same goes for Docker. Docker is "just" an cli around cgroups which is a kernel feature written in again C.

That's a good point. Maybe you could argue that most of the heavy lifting in CockroachDB is actually done by RocksDB.

It's not, not at all. We've actually gone as far as replacing RocksDB with https://github.com/cockroachdb/pebble/ by default now (and it's written in Go).

Oh very cool. What was the main motivation for moving away from RocksDB?

Go is not systems programming language because it has mandatory garbage collector.

Reply on news.ycombinator.com