Hacker News new | ask | show | jobs
by jchw 2656 days ago
That is not the only legitimate reason, at all; adoption of new technology takes time for good reasons. Rust is still pretty new, a lot of things are still only in nightly, and while impressive the ecosystem has a long way to go in terms of robust libraries.

Open source software is only one facet; there are plenty of companies with millions of lines of C++ internally, some of which making up parts of their infrastructure.

I'm being intentionally very non exhaustive for two reasons:

1, I don't feel I should have to explain this. It's self explanatory that these two extremely complicated things can't be compared like integers

2, because it's very much subjective. If you are starting a completely greenfield project Rust might be a good idea. I am a huge fan of what Rust has to offer. But it has it's kludges and kinks to work out, whereas companies have had decades to work out and improve their usage of C++. In particular, linting and coding standards for modern C++ projects generally go very far in improving memory safety even if they don't provide strong guarantees like Rust can. With enforced coding standards you can virtually eliminate risks like buffer overflow and discourage risks like data races. In addition to the ecosystem of libraries, there's a lot of excellent tooling for C++, for static analysis and debugging.

I fear now that I have elaborated the first instinct you will have is to poke holes in individual points. Please don't. All I'm trying to illustrate is that switching to Rust costs time+effort, and it is seriously not better than C++ in every way, in the same way that Go isn't.

2 comments

There are also frameworks for C++ like Qt that mitigate data races by using an internal event loop and function scheduler to give concurrency guarantees.
Then we generally agree. Like I said, the one use case for C++ is if you're already using it, or require a library that is only available in C++.

My general point is that people should make a commitment to upgrade, and set a course in that direction. The opposite approach is the wait and see mentality, which leads companies waiting in perpetuity because they collectively never adopt better languages due to the sunk cost fallacy.

It's exactly the big companies that need to commit, because they have the resources to invest in sanding down the kludges and kinks and making Rust really better than C++ in every way, and it's in the early stages of Rust's development were senior C++ talent could really help set the direction of Rust based on what we've learned from C++.

C++ is updated every 3 years as an ISO standard. Rust is updated at the whim of the developers. C++ templates blow Rust's generics out of the water in terms of writing smaller code.
(Rust is updated every six weeks, and we have a consensus based process, it’s at nobody’s whim.)
Thanks for correcting my ignorance! Definitely a stupid statement on my part. The process looks pretty solid. What is confusing is who the Rust Team is and how the project is sponsored. Is it all volunteer like C++ or is there some sponsorship involved?
It’s cool!

The team is largely volunteers, though several companies sponsor people as well. Some people who are sponsored are only part time, or only on the bits relevant to that company. Mozilla sponsors the most full-time people at the moment. We’re working on getting more full-time people, there are some challenges there.