Hacker News Reader

Comment by ilovecaching | Hacker News Reader

I’ve never seen a community put so much effort into building an ecosystem as Rust. They have working groups for everything, they’ve slowly won over some extremely high profile programmers, and they’re taking on the areas of computing that are the hardest to solve as a manually memory managed systems language. Hats off the team, and I’m excited for all the game changers that are still in the pipe like the faster debug compiler.

After a lot of languages that are just rehashes of what we’ve already seen, or just a different subset of features, Rust is a languages that actually feels like it’s from the future that's finally going to start moving us forward after a lot of stagnation in industry while PL theory has continued to move forward.

If you haven’t given Rust a shot yet now is the time. You can get rust up into the top ten. :}

View on HN

Me neither, but that effort's not visible in their rankings, because it's not even in the top 20, nevermind top 10.

At the end the day it's platforms that move languages, not posting on HN and reddit.

They quite brutally damned Rust with faint praise in the article: "It’s also worth noting that even if Rust never gets much beyond where it is today, it’s still ranking higher than well known languages such as the aforementioned Clojure and Groovy, as well as CoffeeScript, Dart or Visual Basic. Not bad for a systems language."

Ranking higher than VB...

VB6 is still going strong. As answers to most vb6 questions are available on the web since forever, people rarely ask vb questions on stackoverflow. If you look at vbforums.com you can still have 500+ people at any time viewing the "vb6 and earlier" forum. And that's just one of many vb forums.

We should define "going strong"?

MS basically killed it, in 200x when the VB.NET snafu happened. I assume 100% of the VB work is legacy at this point and since solid architecture or design principles were never this language's strong points, it can't be particularly exciting legacy work either.

It's basically a career and technological dead-end.

You could say the same about COBOL. Just because it's "dead" doesn't mean that businesses don't have tens to hundreds of thousands to even millions of lines of code hanging around in these "dead" languages.

While it may not be exciting work, not every programmer is looking to do the latest and greatest thing that will appear at the top of HN. They make good money because the business knows paying someone well to maintain it is better that paying a team to rewrite it. That's why one of the issues with COBAL programmers is retiring and passing on, not leaving to go to a NodeJS shop.

Yes, and if they'd said Rust was more popular than COBOL, that would also have been damning with faint praise.

These ranking aren’t something to take very seriously. They are ballpark estimated at best, and a better measure is growth of the community and adoption in larger open source projects that people actually use.

Comparison with VB is a mark of respect everywhere except HN echo chamber.

I can only assume you're joking. VB was never respected, it had a reputation back in the day of being the tool of choice for shoddy drag & drop Windows GUI apps.

On Windows C++ was the tool of choice and Delphi was kind of a secret weapon for GUI development. Then C# happened, and MS unceremoniously flushed VB down the drain. The VB community was outraged about VB.NET...

I use Rust almost exclusively for my side-projects now, and it has given me (as a guy who spends 2 days to find the Right Way to do a thing because this one hand-waved line in a tutorial just gives a bad smell) much joy and taught me a lot, but as professional, slow adoption in the industry makes me nervous. I have decent experience and background in my current tech stack to easily find a well-paying job, but if something happens to it, or to particular industry it's relevant to, I want something to fall back on; I've seen too many developers drift into a comfortable numbness of stagnation (ActionScript, anyone?). And yet, Rust jobs are extremely rare, and each one attracts a lot of VERY motivated and skilled candidates eager to start writing Rust full-time; and quite frankly, while I think that I'm a decent developer, I don't consider myself among this 1%.

So, I'm curious: how does HN see this situation going forward? Where will Rust find widespread industry adoption, and what can Rust community do to bring this forward?

The thing about getting comfortable is rust is that even if the entire ecosystem burns up in ashes, you can still get a decent job switching to C++. Learning and using rust makes you a good systems programmer in general, not just at Rust.

Having said that, I don't think the rust ecosystem is going to go up in flames anytime soon, but lack of professional application at the moment doesn't bother me too much.

I'm not so sure that it will find widespread industry adoption. I've been eyeing job boards for 1-2 years now, looking at what kind of Rust jobs are available: there's few of them, mostly start-ups. Furthermore, as you mentioned, there are many very motivated candidates competing for those jobs.

Some bigger companies are supposedly using Rust (Amazon, Google, MS) on some projects, but these companies have so many things going that they are likely to use most languages in some kind of project. I've also heard that there are several "invisible" Rust jobs, only available through connections - but these are irrelevant IMO. And then there are the jobs where one is obviously not using Rust, but they mention it to score points or dangle it as a possibility.

Until I see a strong market for Rust skills, or my own employer offers interesting Rust projects, it doesn't make sense for me to invest beyond learning the basics. Funnily enough I'm looking into Go now - its job market is one-sided and quite anaemic, but it offers some nice technical benefits and is a piece of cake to learn.

Also some of the companies adopting Rust, like Microsoft and Google, are also the companies with a couple of key people seating at ISO C++, and pushing for adopting Rust ideas into C++.

The lifetime profile is basically nothing more than a few lints. There are systematic reasons why C++ can never get the memory safety features of Rust without breaking compatibility so much that it won't be C++ anymore.

Really, I do like Rust, but you should adopt another strategy to win the hearts of C++ devs than throwing such jabs.

Show them to create a secure COM component to integrate in .NET can be easier than writing it in C++/WinRT | C++/CLI, using the same VS/debugger integration while being safer, for example.

C++/WinRT and C++/CLI are not memory safe. Rust is. I don't see how Visual Studio, debugger integration, COM, and .NET are relevant: one is safe and the other is not.

As stated, "you should adopt another strategy to win the hearts of C++ devs".

Repeating ad infinitum in every HN thread about C++ improvements regarding safety, that the only path to enlightenment is rewriting the world from scratch, without any regard for the loss of productivity, tooling and libraries in doing so, always hand waving them as minor inconveniences, is trying to catch flies with vinegar, but I guess I am wasting my Latin as we say back home.

I'm simply saying that modern C++ is not safe (and it will probably never be). If you write C++ at scale, you need to accept that you're going to ship memory safety bugs.

I've said many times there is a legitimate reason to write C++. If you understand you will be shipping memory safety issues, but the advantages of C++ outweigh the memory safety issues that you will ship to production, then I can't argue with that. I've seen game developers argue as much, and that's legitimate! Maybe, for your use case, memory safety problems really don't matter (or don't matter enough to outweigh C++'s other features). But it doesn't do anyone any good to sugarcoat the fact that C++ at scale virtually always ends up with memory safety problems, and while there have been many mitigations there has been no effective solution so far.

Agreed, but until Rust actually provides good coverage for many C++ uses cases, like COM/UWP on Windows for .NET apps with Visual Studio mixed debugging and GUI designers, sounding the safety trumpet without anything else to offer won't do it.

Maybe it will change after the HoloLens/FF project, however today is not appealing to many Windows teams.

The challenge for Rust is that most of the people that are proficient at systems programming are already proficient in modern C++. For those developers, any advantages of Rust do not outweigh its disadvantages in practice, so there is little incentive to invest in changing languages.

Rust can best grow its developer base by growing the number of new systems programmers, as they would have less to lose by using Rust and would be less likely to notice its limitations. The challenge here is that becoming a competent systems programmer is much more difficult than learning a new programming language, and there is a chronic shortage of developers interested in systems programming.

If we were still using classic C++ (i.e. C++03 and earlier) then I think Rust would have a real chance. The rapid evolution and adoption of modern C++ has fixed many (most?) of its major weaknesses.

Personally, I use Rust for things that are very far from systems programming - web apps, game development and small utilities for now (although I'm eager to at least try app development on it, when it gains at least minimum amount of support). That's the beauty of Rust for me: perfomance and correctness of a system programming language that is actually usable for product development.

Yea but nobody (no company/org) is going with that direction except a few...

Majority goes to Rust for what it is developed for: system programming.

Just like I won't use Go for web app dev (ugh.. what a PITA)

I don't know where you'd get the idea that everyone who knows modern C++ prefers Rust. I'm not the only one who knows how to use modern C++ and usually goes with Rust instead. In my opinion, modern C++ is less safe than classic C++, because it adds more ways to get use after free (e.g. lambdas).

Modern C++ is not memory safe, and there is no way for it to achieve memory safety without either significant runtime overhead or breaking compatibility so much it won't be C++ anymore. The features in modern C++ are nice, but they don't solve my problems.

The relevant question is the degree to which memory errors remain a significant source of bugs in modern C++ code. Are they now of mainly theoretical importance? I can't answer that definitively, but I can say it has been many years since I had a bug in C++ code that using Rust, instead, would have prevented. My bugs are specification bugs. Memory bugs just are not on the radar. But coding Rust takes me enough longer than C++ that I can't justify it.

Perhaps the driving force demanding memory safety isn't for one's own use, but rather the hope that the code one depends upon, written by other people, will get better. I.e., I write good code, and you write good code, but God forbid we have to rely on Microsoft, Google, Mozilla, and Red Hat monkeys to write good code! That's a legitimate desire, but it doesn't drive much personal adoption. Meanwhile, the PITA factor -- borrow checker not happy! "&" required! "&" forbidden! -- interferes with personal adoption of Rust.

And C++ keeps adding features. Not to fall increasingly behind, Rust needs to multiply its adoption rate. I don't see how that could happen. C++ is already good enough, so Rust can't cannibalize significantly from C++ coders. Rust is enough better than Go, Java, and C# to be worth a significant effort to switch, if users of those languages could perceive it. The greatest benefit to the world derives from driving people off C -- to Rust or modern C++, it matters little which.

> The relevant question is the degree to which memory errors remain a significant source of bugs in modern C++ code.

That's easy to answer. They do. Any look at a CVE list for a browser will confirm this. These browser engines are, by and large, written in a modern style.

> Are they now of mainly theoretical importance?

No.

Why would someone use Rust over Java/Kotlin/Scala/C#/F#? Macros would be a small improvement, but at the price of reflection (JVM has Clojure for this). If I was using one of those languages, I don't really think the performance gain from moving to Rust would outweigh the added mental overhead, cost of learning new libraries, or developer scarcity.

I would use Rust in place of C++ or C in a heartbeat (and I would probably pick it over Go until they have generics), but I wouldn't use it in place of those other languages for the same reason I wouldn't use C++ in place of them. They're already managed, and I wouldn't have used them in the first place if I needed Rust's performance.

I have many years of experience with large-scale C++ projects at multiple companies, and have written >100kLoC of modern C++ personally. I've seen thousands of bugs come and go. Memory safety bugs are vanishingly rare in the code bases I've worked on, and in all those years the handful that I recall were created by people new to C++ (usually cross-trained Java programmers). It is difficult to create memory safety bugs in idiomatic modern C++, and achieving this has no meaningful overhead. Memory safety is important but Rust proponents have constructed a bit of a straw man with respect to modern C++. Use that argument against C or classic C++, where it has more relevance.

At the same time, modern C++ also has advanced and valuable safety features that Rust does not have e.g. the enormous amount of compile-time verification and complex type construction that is possible. I find these to be far more valuable because the kind of bugs these catch are more common in practice. None of this is automatic but it is trivially enforceable as coding style, and many companies do.

The idea that C++ code bases are necessarily littered with memory safety bugs is nonsense. For people that have been writing this kind of code for a long time, avoiding those bugs is largely automatic and effortless. And you don't have to do violence to your data structures to achieve it. I can see an argument for someone coming into C++ from a language like Java but for experienced C++ programmers the value is dubious in practice.

There may be compelling technical reasons to use Rust over modern C++ but you'll have to do better than automatic memory safety, particularly given the safety and capabilities that would be sacrificed.

I also have many years of experience with large-scale C++, and my experience is very different from yours. The difference, I suspect, is that browsers are actively attacked, via fuzzers and so forth. When you have contests like Pwn2Own targeting you, it's very eye-opening how many memory safety bugs you are shipping, even in fancy modern C++.

(I also disagree that modern C++ is safer than classic C++. Modern C++ adds more invisible ways to get use-after-free, which is pernicious.)

is there a chronic shortage of developers interested in systems programming? I believe most programmers prefer to do systems programming instead of business apps.

Developers may have the interest but they don't have the necessary skills nor invest the time to obtain them. Systems programming requires a deep understanding of how real-world hardware works and interacts with code. This seems to be rare expertise these days, even among nominal systems programmers.

Until it gets a platform to come along with the language, it will keep this slow adoption.

Most mainstream languages being used today took around 20+ years to get here, Rust will need as much for long term survival.

I wonder how this would look like taking into account language-specific user forums. I do not know about other languages but the Rust users forum is very active. The popularity on StackOverflow is probably dragged down by this, although I do not know to which degree.

For us the GUI story, support for COM/UMP and binary libs still need to improve.

I didn't know this was a contest. Can we bet money?

People keep forgeting programming languages are software products just like anything else.

> PL theory has continued to move forward.

It did? Can you link me to the new stuff?

Reply on news.ycombinator.com