Not used Rust yet, used a lot of C++; isn't a weakness that it also is extremely slow in compiling? Not sure about others but to me that's a big weakness (if it still applies, but as far as I can find on Google it does).

Might be better than whatever C++ does though.

Then most organizations have staging areas where you can share binaries across the company.

And the two package managers that have been growing community support, conan and vcpkg, support caching and distribution of binary dependencies.

No doubt cargo will eventually get something similar, it just isn't there today.

But just like anything else given enough time, money and harddisk space anything is possible :)

If I was to nuke my target directory _(the compile cache)_, it would take minutes. Not sure how many honestly, because when I do it, I rarely wait for it.

So the compiles are definitely slow, but for me it's only bad when dependencies are needing to be compiled. Which is rare.

If you don't cache your dependencies well, like in a poorly written CI pipeline, things will suck though. 20 minute builds at work (slow build machines) are common for us due to some poorly done caching.

Deliberately inflammatory, and also false.

1. Rust has limited abstraction features to make it more approachable and implementable, but make it unable to express libraries that are easy in C++. This will not change soon, although Rust will accrete features at a steady rate. But the gap in feature sets will widen, not narrow with time.

2. The total number of people using Rust in production is easily less than the number who pick up C++ in any given week. It will be ten years before Rust is a mature industrial language, if it gets there. (It has made a good start in that direction, which is better than can be said for any other newish language.)

3. C++ and Rust will coexist for decades. The most ambitious work will continue to be done in C++, while Rust will be more than adequate for what might otherwise have been done in (the much less capable) C, Go, or Java.

4. D fizzled because it is too similar to C++, and therefore unnecessary. Rust found a ready audience in people intimidated by C++, frustrated with the limitations of C, Java, and Go, and ready to try something wholly new. Its designers have threaded the gap deftly, uniquely adopting C++'s greatest strength, the destructor (which it calls the "Drop trait"), and avoided weighing it down with garbage-collection. It has a bright future if it can multiply its adoption rate by two orders of magnitude.

As Stroustrup said, there are only two kinds of language: the ones people complain about, and the ones nobody uses.

With enough luck, by the time Rust is mature, it will have gained plenty to complain about. Rust will have got somewhere when you read more complaints about it than brags about having made it do something already done in a mature language.

OP is right, unfortunately. C++ is a dying language. Mozilla, Microsoft and Google are all looking at Rust. Why? Because it's probably makes more sense to rewrite a buggy C++ component in Rust instead of updating it to use modern C++ (where admittedly, you have to go out of your way to get things wrong). The damage has been done.

I'm also concerned about our ability to hire in the future. C++ devs will either be too expensive, or just not there since it's not an attractive language any more.

I'm not a Rustafarian either, I've actually never used it but it would be negligent of me to not look at it. One concern I have with it is that the eco-system may be full of poor-quality ports of C/C++ libs, because that's how people work when they learn a new language.

It's far too premature to declare its death. The pace of development of C++ is decently fast and there's many stakeholders with millions of lines of C++ who are interested in C++ not dying. C++ is taught in universities around the world so the chance of C++ developers becoming expensive is low.

To suggest C++ is a dying, slowing, or stagnant language is objectively delusional. The language is healthier than ever, and going gangbusters.

React Native, the new Games SDK for Android, WinUI 3.0 release, lifetime analysis support for Visual C++ and clang and lets not forget they are two major contributors to ISO C++.

While the Rust/WinRT efforts from Kenny Kerr are welcomed, that it is just yet another option alongside C#/WinRT, C++/WinRT, Python/WinRT and JavaScript/WinRT.

P.S. I'm not a COBOL programmer nor have I ever been a COBOL programmer.

Other than that it's nonsense to say that X is dying.

Sure, it'll stick around for some years yet but all those jobs will become maintenance jobs. Very little greenfield projects will elect to use it outside of niche areas (games and maybe embedded - UK salaries for embedded dev are terrible). Both C++ and Rust can use LLVM, so the generated code is likely to be the same.

If you were starting a greenfield project today why would you choose to do it in C++?

I forgot to mention Go too.

To suggest C++ usage is in decline is, objectively, nothing short of delusional. For Rust, C++ will the one to beat in ten and twenty years, provided not too many have already skipped onto some new hotness.

Rust is an objectively better design than anything else that has arisen in 30+ years. That doesn't guarantee success.

I used to hope a better language would displace C++, and for a time thought Rust might be it, but that better language turned out to be C++ itself. Nothing else is even on the horizon.

Oh and by the way, LLVM is 100% c++.

Saying it is too dangerous and complicated is absurd. It is easy to write safe code in C++, having been doing it for almost 30 years.

You are throwing around lots of assertions - challenge you to back them up with real data.

2. True, but growth curves are rarely linear. Here’s a rough proxy on users - the number of subscribers to /r/rust - https://subredditstats.com/r/Rust. Look at the growth between 2014-18 and 2018-2020. You’re extrapolating on current growth rate, but that may increase in future.

3. “Ambitious”. Nothing I’ve seen precludes using Rust for ambitious projects. In fact, seeing the experience of Dropbox, Mozilla, Facebook and others, there are some ambitious projects that could only have been done in Rust. I’m gonna say [citation needed].

I agree with Stroustrup and look forward to the day people complain about Rust :)

I'm guessing, but I think that something like Armadillo[1] would not be possible on stable Rust. Something like Catch[2] might also difficult to make ergonomic.

I don't program in C++ anymore and I would personally live with the lack of expression/abstraction for a safer language though.

[1] http://arma.sourceforge.net/speed.html [2] https://github.com/catchorg/Catch2/blob/master/docs/tutorial...

Also, how is it ergonomic? I'd agree if you say that it's (one of?) the best for C++, and it's also my go-to option, but ergonomic?

Type-aware macros might not be the best way to implement the features needed to match C++.

What about people not intimidated by C++ and want to switch to Rust anyway? Why have you discounted them? Do such people exist in your world view? Do you think there might be a good reason for those people to choose Rust?

There are kludgy workarounds for everything, more or less, but why switch to a limited language with immature tooling and practically nonexistent immediate prospects, when C++ demand is going up, up, and up?

Memory safety is just not an issue at the level where coders of modern C++ work. I have had exactly one lifetime error in five years, caught in initial testing. My bugs are overwhelmingly specification omissions and logic mistakes that Rust suffers from exactly as much.

My day-to-day experience is to write 2000 lines and, when it compiles, it works correctly, modulo a "!" short or extra. Then, I spend a few days refining the design, which often means deleting code. Things Rust promises to help with consume only trivial attention. Library features not expressible in Rust prevent many more and bigger problems.

Rust has some nice qualities I would rather C++ had--pattern match support, simple iterators, default const and default pass-by-move, sane conversions, sane initialization--but they are all low-level conveniences, not anything I am willing to trade away architectura-level capabilities for.

Rust is going interesting places, is taking full advantage of starting from scratch, and is miles ahead of C, Java, and Go on every axis. But if Rust could get to where C++ was in 2011 by 2025, that would be amazing. Meanwhile, C++ has already shipped C++14, C++17, and C++20, will have done C++23, and will be firming up C++26.

Assume Rust could match C++20, just five years later, in 2030, which would be more amazing. C++29 will be out.

The language is messy and filled with undefined behaviors and unsafe methods by default. Where there are rules you can mostly ignore them whenever you want. People complain about JavaScript being messy but C++ is way worse.

Though the language itself isn't all that bad, I don't understand why there so many build systems? And the top build system CMake isn't so much a build system as it is a build system for build systems that exists because no one can seem to agree on one.

Many of these systems seem bloated and over designed by comparison when I can install libraries or cross compile in one line in go. I couldn't help but think there had to be a better way and it seems like rust is that way. I expect C++ will eventually go the way of Cobol and eventually be used to maintain legacy systems.

p.s. thank God for vcpkg because I had nearly thrown in the towel while trying to integrate simple libraries until I discovered it.

Unfortunately for many people technology is still an emotional rather than a professional topic.

Nah, I mean maybe in the way that Fortran coexist with C/C++ for decades, but it's not equal coexistence.

I would rather say that new languages arise, replaces old ones for most scenarios and in the cases where they can't, due to various reasons, they push the old language into zombie state like cobol.

It's the same BS like NoSql will kill all R-D's.

You just don't invest millions just to rewrite programs that work's perfectly (and that's often the case with old battle-hardened software)

And especially Mozilla's intense passion for open-sourcing everything. I think it was a good catalyst to get it into the hands of as many people as possible.

I feel that people can learn rust faster if they know c++ beforehand.

c++'s syntax is scary too. But there are different levels of c++. You don't need to use the scary part to make things work.

Ding ding ding! However I do think that the combination of syntax with the brand new concepts just adds that extra layer of complexity. A similar thing is Optionals in Swift -- the syntax is so baked into the language that even if you really understand how optionals work, the syntactic sugar keeps piling up in different situations. (i.e., first the ? operator, then implicitly unwrapped optionals, then if lets, guards, guard lets...)

I’m curious about what you find scary about Rust’s syntax. I always found it to be a fairly natural extension of the syntax from C and other ALGOL-derived languages.

Its semantics, on the other hand, took quite a while to wrap my head around. I am reasonably productive in Rust these days, and I still sometimes can’t predict whether or not the compiler will allow something.

The borrowing model was actually my favorite part because it not only was interesting, but made sense! And the syntax was relatively clean :)

Well, almost. I'm not sure I like unsafe FFI and other bits.

> Personally, at some point Rust was just clearly better and after a while - I lost interest in D. I don't have time to keep track of D catching up

Yup. Better to use Rust if it's the one introducing the features.

Industry has had Ada since 1983, Modula-2 since 1980, Object Pascal since 1990, and a couple of other ones, not counting all those Algol and PL/I variants that precede C for about 10 years.

Unfortunely the industry will only take security seriouly when security exploits are severly punishable by law.

The community lives in a bubble and is out of touch with mainstream software development.

The industry has needed good alternatives for a long time. Finally, they're coming, and not nearly soon enough to suit me! :-)

I consider Rust more pragmatic at this point. Perhaps it's because I code in C++ as my dayjob and have to deal with the consequences.

In theory, C++ is perfect given perfect developers. In practice, it's more sensible and realistic to write tricky, like multithreaded, code in Rust.

One rarely mentioned important factor: fear. It's much less scary to modify something written in Rust than in C++. Doubly so for less experienced developers.

Rust, culturally, comes from the web. That's why it has the most traction in the web server/WASM space for now. It's starting to poke its head into Systems use-cases because of the sheer weight of its memory safety benefits there. Maybe in a few years it'll get some real use in the games industry (real industry; not just enthusiasts), though Unreal remains a bastion of C++ that isn't going anywhere anytime soon. But then there are some dark corners of C/C++'s territory that move even more slowly, and where the cultural shift will take a long time. I think to a great extent, embedded falls into that category.

WASM as a target is actually a great indication that it's a system language -- performance is a primary consideration.

Which is very different than "web people", which in my mind implies webdev -- html/css/js + API server/db/caching backend.

Which also further explains why WASM is so far along (sandbox, security), much better than any association with webdev itself; but not kernel-level system development. (But if the web browser is an userspace OS... then it's probably not that far from it)

https://www.redox-os.org/

Few "want" C++, but for robotics a non garbage-collected language is necessary so latency is predictable. There are few mature languages besides C/C++ in that category.

Rust is an improvement, but I'm hopeful something like Julia (Julia Robotics, https://juliarobotics.org/) or Scala Native (https://scala-native.readthedocs.io/en/v0.3.9-docs/) becomes mainstream, the productivity gains would be substantial.

But perceived "comfort" isn't entirely reality. (The comfort of smart GC languages is immense in a different way.)

For 99% of realtime work, the Rust or Scala Native approach is just fine. No GC required. Julia users can just use the pre-allocation approach.

The important thing is avoiding language patterns that encourage needless allocation.

GC languages still support stack allocation, you don't have to pre-allocate anything you can stack allocate. (That's where .NET Core has been especially burning rubber in recent releases. Span<T> is a stack allocated, GC-safe "pointer", for instance, that is doing all sorts of heavy lifting in .NET Core performance-critical work these days. It's still early too, as not everything has moved to Span<T> that can move to Span<T> and family.)

But also, not everything needs to be pre-allocated for the "best approach". There's some work to get used to the feel of any specific GC, but most modern "VM" GCs (.NET and today's Java, not yesterday's) are multi-generational and there's a lot you can do in strategies such as "focus on the nursery and the LOH" (using only [potentially many] small short-lived objects and a few, mostly stable "very large" objects, avoiding the intermediate generations).

> why carry the overhead of the GC at all?

Safety. (Why wear seatbelts?) Rust's borrow checker is great but it still requires a lot of manual adjustment and it's still possible to miss something (it's not easy, certainly, but it is possible); a GC gives you safety by default, with no manual intervention required to guarantee safety, and requires manual effort to write unsafe code.

> The important thing is avoiding language patterns that encourage needless allocation.

That's where we agree and why I'm very adamant that though some of the tools ("knobs") look scarily different in performance optimization for GC versus non-GC languages, the vast majority of the tools are the same: know the O(memory) of your algorithms, and make smart trade-offs regarding that O(memory), avoid allocating what you don't need, know your trade-offs between pre-allocation and allocation only when necessary, etc.

Could you elaborate?

It is a great choice to prototype the ideas

Previously, the code base was primarily Python with some C++. Now there is a significant chunk of code, particularly related to safety, written in Rust.

Firstly, because 75% of all that knowledge is easily transferrable.

Secondly, because you want to take 50% of your bug count.

It doesn’t work well for embedded programming.

It very much does not fix all bugs, especially given lack of static type checking.

I actually worked in Automotive, and the software higher level up the stack there is usually god damn awful piece of s*, often done by people who have almost no clue what they are doing, with plenty of misconceptions about how C/C++ even really works (using `volatile` for concurrency/atomicity and stuff like that). They are just beating their spaghetti code from segfault to segfault for decades.

This and slow delivery process easily explains why entertainment, navigation and other software-driven part of mainstream cars are so buggy, slow and generally terrible, and why Tesla could have so easily deliver way better experience.

So it doesn't matter that some people can't "get into Rust". The business that hire them will be replaced if they can't up their game, that's all.

Building ecosystem just takes time.

C++11 is a really good language. Also there are tons of libraries and things people have already built in it that you can leverage to reduce development time.

For example, is there a way in rust to get a runtime error when there's an int overflow?

Or better yet, the Rust standard library exposes all the relevant LLVM intrinsics for the primitives, so you have the {Integer}::checked_, {Integer}::saturating_, {Integer}::wrapping_, {Integer}::overflowing_ (inlined) functions to do all your integer math in an error-free fashion.

I guess what I meant is "vast-majority of devs out there".

I did ~10 years of kernel/embedded myself. Generally people use C++ only when they really have to (like: they work in one of this niches, or want to get a job there). I've experienced myself many times when people would go with anything but C++ because of all it's faults, weaknesses and general infamy. And I also have seen some people that gave Rust a try and it went smoothly. They deliver a proper C++-level performance and resource control, without any of the problems and were happy about the experience.

AAA-game/kernel/embedded are all lucrative (except games, lol), important and not tiny but they are still niche.