Tbh I think most governments seem to think it’s useful because someone is making money. Which goes back to why are governments asleep at the wheel on climate change. Which goes back to…they probably think the problems won’t apply to them personally.

At Cloudflare we have lots of people learning Rust, and it’s working great for us. They do get stuck initially, but on simple problems that more experienced devs can help with.

But the great thing is that novice Rust users are not dangerous. The worst thing they do is cloning objects more often than necessary. You can have noobs writing Rust with less experience than what is required to let anyone anywhere near a secure C++ codebase.

but I don’t think I’ve ever seen any concrete proposals to fix it.

• Polonius borrow checker to handle more cases than NLL, which was already a big improvement over 1.0 scope-based borrow checker (BTW, when people think borrow checking could be done with some metaprogramming in C++, they don’t even realize the depth of the problem).
• View types, especially if they could be applied automatically to make getters/setters not annoying.
• Async in traits (and async itself is dodging a lot of pains that used to exist with closures used for callbacks)
• Generators

Major improvements have already landed:

• “match ergonomics” means you can get far without knowing the ref keyword and randomly inserting & Into match until it compiles.
• 2018 modules syntax that is closer to what people expect
• cargo fix
• huge investment in high quality error messages and clippy lints (option.unwrap() used to get people stuck, now the compiler tells you where you need as_ref()).
• const generics made arrays not broken for >32 elements.

Rust isn’t easy, but has improved a great deal since 1.0, and it has been a conscious effort to flatten the learning curve.

how compile times factor into this energy sustainability argument

Surely even with the (sometimes maybe somewhat excessive) “test every push” CI culture that we have these days, production server infrastructure is orders of magnitude larger than the dev infrastructure… any efficiency in prod is multiplied by the size of prod.

And with C++ being one of the incumbents, it’s not like everything has fast compile times before switching to Rust ;)

As to “getting over the hump”, I just recently finally did it. Coming from advanced-level Go and advanced background in C++ before that, I see three key reasons to my breakthrough: (1) “Programming in Rust, 2nd ed.” from O’Reilly; (2) Rust got better enough recently, finally overcoming some issues that annoyed me super much before, esp. thanks to anyhow and thiserror (and a few other things, like async, and NLL before that); (3) me realizing that in a triangle of language design priorities of: “performance - simplicity - security”, when in an irreconcilable conflict, Go chooses simplicity, Rust chooses performance AND security (which is crazy enough IMO that there’s an AND, not OR).

Mind me, I’m still sadly writing tons of non-idiomatic Rust for now, and not everyone in my new workplace seems patient with that; yet let me tell you, I’ve seen way too many “advanced” Go programmers writing FAR-from-idiomatic Go (oh, the pain…). Google not adopting Rust now instead of C++, if you say it is so, in my opinion is a huge “yellow flag” for them, and will be seen as a costly (though probably not critical, with their deep pockets) blunder, probably resulting from a critical mass of C++ devs in house, who subconsciously fear having to admit to themselves their skills are becoming obsolete, and also fear the effort and risk required to learn new tech stack. Personally, I currently think of C++ in context of Rust already as having become “a COBOL” - for a new company to choose it, there can be reasons, but IMO all of them de facto legacy; at best because their target microcontroller doesn’t support Rust. Technically IMO “doesn’t yet”, but where “yet” will sadly probably mean some 15 years (or even more), given how hardware companies seem to think of software.

Please note I by no means claim Rust is perfect. Notably, I’d certainly wish there was less of “as_ref()” etc. noise in the code, compile times are a downgrade from Go (though again, with incremental compilation it’s not that bad recently), and certainly I can prototype faster in Go. But when comparing with C++ specifically… I strongly believe the line is clearly crossed and I just can’t see how Rust could not overtake C++ in the long-term scale. If I met someone young who’d ask me whether to learn C++ or Rust, for their future advantage I could only recommend Rust. Maybe C too if they are of the kind whom I could recommend Assembly as well, i.e. for understanding the low-level and navigating critical legacy (like Linux codebase) - but only as a later extra.

Having made the awful awful mistake of learning C++ as a first language as a child, even beyond the “lifetimes prevent you from writing wrong code!!!” stuff, I feel like C++ has soooooo many obtuse rules and weirdness going on, that if you’re thinking about the rules and complexity, whether Rust or C++ is more complex feels like a wash? Stuff like lvalues/rvalues, specialization…. Rust doesn’t even have inheritence on its end!

And like…. god forbid you would have to use something like Scala (with its mix of OOP/FP and magic action at a distance with implicits, inline operators….).

I do feel like there’s a lot of discounting doable in Rust where the most-cited complex bits are caught by the compiler, rather than runtime surprises.

But even beyond that I feel like C++/Rust/Scala has always been that category of languages that are liked by people who like to play Magic The Gathering: you are writing programs, but also interacting with the language rules and doing a bunch of stuff there.

As to the “poor code” thing… I definitely agree that there’s a uniqueness to Rust where making the wrong data structure decision ends up infecting every related type signature because of lifetimes and the like, it feels like you would need very good initial codebases to get things running.

We’ve always had the Gates’ law offsetting the Moore’s law. That’s why computers don’t boot in a millisecond, and keyboard to screen latency is often worse than it was in the ‘80s.

But the silver lining is that with a more efficient language we can get more useful work done for the same energy. We will use all of the energy, maybe even more (Jevon’s Paradox), but at least it will be spent on something else than garbage collection or dynamic type checks.

I can tell you that I was part of an effort to rewrite a decent chunk of code from Python to C++, then to CUDA, to extract more performance when porting software from a high-power x86 device to a low-power ARM one. So the use case exists. This was definitely not in the server space though, I would love to hear the answer to this in a more general way.

I’m not going to try to extrapolate Rust’s performance into population dynamics, but I agree with the starting point that AWS seems unlikely to encourage anything that results in them selling fewer products. But on the flip side if they keep the same number of physical servers but can sell more VM’s because those VM’s are more lightly loaded running Rust services than Python ones, then everyone wins.

I’ve spent a big portion of the last 3+ years of my career working on cloud cost efficiency. Any time we cut cloud costs, we are increasing the business margins, and when we do that, the business wants to monitor and ensure we hold into those savings and increased margins.

If you make your application more energy efficient, by what ever means, it’s also probably going to be more cost efficient. And the finance team is really going to want to hold onto those savings. So that is the counter balance against the induced demand that you’re worried about.