Hacker News Reader

Comment by hn_reader_75 | Hacker News Reader

Off topic. Asking seriously, will there be any point learning some language other than rust in coming days? Will rust be ubiquitous in future?

View on HN

It's important to understand that hackernews, reddit or stackoverflow are very small parts of the software universe. At my workplace less then 10% of the devs are hanging around at hackernews or reddit. Some don't even visit stackoverflow but just read the Java docs!

Rust is extremly popular here at hackernews and at reddit. It's a brilliant language. I learned it and actually wanted to use it for some services at work, but the team chose Go.

The impression of the spread of Rust one might get following hackenews or reddit is far off. In the industry Rust is not even at 0.1%. Probably less. The amount of Java, C and C++ projects is immense. That's at least what I can tell from my almost 20 years of experience as dev.

Rust is 10 years old. It's not new. There must be reasons why it's not already ubiquitous. And it's not the lack of language features or the lack of promotion :-).

The reason is simple: The choice of the programming language itself is not that important. How else can the world be full of extremly successful projects written in PHP, Python, Ruby, Java, C#, C, C++, Go, JS, ...

I don't like to write code without algebraic types and pattern matching. I don't want to check for null. But with Java or Go I have to and to be honest: It doesn't matter. A good development process is essential for successful projects. Language and tools ergonomics, matureness and stability come second.

That's why so many large projects are still on Java 8. They get the job done. The same can be said from C++ and C. If C++ was so harmful, why did Mozilla not port all of Firefox to Rust?

Rust could be a greater success in the industry. They just have to look at Go. Go gets a lot right: Standard lib and stability. Generics don't really matter if you want to build a successful product. I want it but I don't need it. A large and stable standard lib does matter. The xml package in Go's standard lib is embarrassing slow. But you can rely on it.

Rust needs a large company as patreon. It needs a more comprehensive standard lib. It needs one async runtime in the standard lib and a http server and client, crypto, etc.

> Rust is 10 years old.

Rust didn't have any pick up in adoption (understandably) until 1.0 in May 2015, as a consequence of breakneck speed changes before then as the developers understandably wanted freedom to break things until then. Also, 1.0 wasn't a "feature complete" release, it was a "we promise not to break your current code" release. It was an MVP. I would say it took a few releases before it was useful enough without having to rely on nightly features. All this to say is that saying that it is 10 years old, when code from 6 years ago would be completely alien and not compilable today, is misleading by omission.

> It needs a more comprehensive standard lib.

Reasonable people can disagree. There's a difference between having a fat stdlib that has the same cadence as the compiler, and having a "blessed" crate ecosystem that can evolve on its own. Doing it that way can let people update either their compiler or their dependencies independently of each other (modulo minimum version bumps on libraries) and opens the door to more aggressive deprecation schedules that the stdlib can never consider.

Your points about the actual popularity of the language are very true: Rust is niche now and will likely continue to be so for a while, but I don't think it will remain niche.

> deprecation schedules that the stdlib can never consider.

This is utter fantasy.

You can have a standard library that doesn't get deprecated often, or no "standard" libraries at all.

Oh, I mean, sure, you can call it a "blessed crate ecosystem", but that's just a label. A name. You can call it Bob's Best Bits, or the Stevens Standard Set, or whatever you want, but inevitably it'll be either:

a) Difficult to change because so many other libraries depend on it, because it is the established standard.

b) Easy to change because it's not the established standard and hence nobody cares if it breaks the handful of things that depend on it.

Everyone wants option (c), where an established standard is magically easy to change. But there's no such thing. Putting libraries outside the "std" namespace doesn't help in any way.

In Rust you can have multiple versions of the same crate in your project. This let's you update you your dependencies almost whenever you want, even if their transitive dependencies require different versions of the same crate. You can't have multiple versions of the stdlib (the way that things are set up today).

Some crates re-export typed from their dependencies, and to use those you have to match in the right crate version. This is an anti-pattern, but it happens.

For any other language in the past few decades, the answer to that would have been "of course there is a point in learning other languages" (since none single language has taken over). I don't see why Rust that much more special.

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.

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.

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.

Just an opinion. Rust will never be ubiquitous in the future. It could aim to be as ubiquitous as C++ is, but I think those systems will be split among Rust and other languages whenever they’re rewritten and someone decides C++ should be eliminated. It requires some additional upfront effort that many practical projects may not have the luxury for (people/management types think it’s ok to fight random bugs in the future). Rust may not have the rich and mature library ecosystem like certain other languages either. But learning Rust will likely help in being a better programmer.

I think yes. But than I am a Rust fanboy so take this as you wish. The way I see it is: In the future, we'll have 64-128 cores per processors (maybe in a few years) and parallel programming will be the norm rather than the exception. The second point, Rust abstractions are very powerful, and they can allow for higher-level programming that you are used to in Python/JavaScript.

Also if you think Wasm is the future for front-end programming, it suddenly makes sense to jump all-in in Rust.

Do you think Swift has a future for WASM? Rust is faster and Swift is easier, and I genuinely wonder how that particular tradeoff will shake out for web.

Are you talking about the memory management model or the syntax. For the syntax, it's a matter of getting used to. For memory management, Rust has alloc::rc, so Rust gives you Swift + more options.

Swift is backed by Apple, but whether they are willing to invest in a Swift WASM platform is another deal. The bull case for Rust is getting capital (whether money or dev time) from Microsoft and Facebook as both these companies don't have an equivalent and have use cases for Rust.

Seriously? Ok, well the day when it starts making web apps. The day when you can't find a job unless you know how to write Rust.

A better question: how is it ever going to topple JS? I haven't written any other language in the last 8 years.

There will be a point when you type: "./configure; make" and the system you are trying to build turns out to be partially written in Rust. At that point, it can be useful to have at least some Rust under your belt.

This exact thing happened to me with 389-ds.

This is already the case if the system you’re trying to build is Firefox.

Reply on news.ycombinator.com