I do think that specific point is catering too much to sloppy get-it-done-fast-and-don’t-think developers. It’s true that they are Rust’s most untapped demographic, and the language won’t reach the pinnacle of mainstream usage without getting buy-in from that group, but I really think they’ll be won over eventually by everything else the language and ecosystem offers, and .unwrap() won’t be such an unreasonable price for them to pay in the long run.

The ideas in the article are great, I’m just a little confused by some aspects of the author’s tone where it sounds like there’s an assumption that the Rust community isn’t interested in expanding the scope of the language to every conceivable use case domain and height.

For the 4 years that I’ve been paying attention the Rust language is advancing faster than I ever thought a language is able to, but more importantly that advancement has been sound and sensible. So far I haven’t seen a language feature make it into Rust stable and thought “Oh no that was a mistake”, even as features roll in at an incredible rate.

Compare that to the C++ ecosystem where I feel like almost every new language feature is arriving very slowly while also being poorly executed (not that I think the ISO committee is doing their job badly; I just think it’s effectively impossible to make new language features in C++ without gross problems so long as you demand backwards compatibility).

I fully expect everything in this very sensible list to make it into the language at a reasonable pace. I don’t object to the “bikeshedding” as much as the author here seems to because I’d appreciate if Rust can avoid painting itself into a corner with bad language design choices the way C++ has. If we’re talking about language ergonomics, I’d rather suffer some tedium now while waiting for a feature to be polished than be stuck in a corner forever in the future because a bad decision was made.

One example I can think of is I’m not convinced that his proposal around kwargs for function arguments is a good thing, at least not without some serious thinking. For example should it support the ability to reduce foo(a, b, x: x) to just foo(a, b, x) like what’s done for struct construction? If so then the optional arguments start to look too much like positional arguments and the syntax starts to get questionable to me. On the other hand if that simplification isn’t supported then that becomes inconsistent with other parts of the language. So this is something that I believe requires a lot of serious thought, and maybe the better answer is to have built-in macros for generating builder structs

That being said, the edition system of Rust could afford us some leeway on not being forever trapped with a bad language design choice, but I don’t think we want to rely too much on that.

Considering most JIT compilers for JavaScript are written in C++, I can’t conceive of a reason you couldn’t implement one in Rust.

Is part of your requirement that unsafe doesn’t get used anywhere in the dependency tree? If so you’d have to take away most of the Rust std library since many implementations in there have small strategic uses of unsafe under the hood.

In my entire software engineering career, which spans embedded systems to CAD applications, I’ve never encountered a case where GOTO is actually needed (but maybe some places where it can be used as a dirty shortcut to save you some lines of code).

As for arbitrary function pointers, if those function pointers are written in Rust then they’ll come with all the safety assurances afforded to Rust code. I suppose if you’re worried about the danger of running ussr-code with unsafe in it, you could probably have your JIT refuse to compile the unsafe keyword specifically.

I really don’t think that there is any perfect programming language.

You’d be wrong 🦀🦀🦀🦀🦀

Disclaimer that I have no experience with writing compilers myself, but conceptually I don’t see any obvious reason that someone couldn’t create a JIT compiler for Rust so that it can be treated like a scripting language and do rapid iteration…

Still much better than C++ templates, and I say that as someone who used to genuinely love C++ template metaprogramming. Admittedly Rust traits+generics are far more limited than C++ templates, but very often I find that to be a positive. The list of things that I feel traits+generics are missing is small and rapidly shrinking.

A good enough compiler would prevent them from happening 🦀

Sorry to be pedantic but Rust only guarantees no data races can happen. It does not prevent race conditions more generally.

Don’t get me wrong, I absolutely love the language for sparing me from the hell that is data races, but the language alone won’t solve race conditions for you.

🦀🦀🦀🦀🦀🦀🦀🦀

I’m not familiar enough with what you’re trying to do to offer any specific advice. I’ve spent very little time with writing dockerfiles, and have never needed to set up a Rust toolchain in a dockerfile.

I think the first step is figuring out if nightly is really needed. If there aren’t any nightly features needed then the latest stable toolchain should work fine, and worrying about what version of the toolchain to use is a red herring.

Nightly is for language features of Rust that are still being tested or experimented with. It should only be used by developers who are eager for the latest bleeding edge capabilities and are willing to adapt if those capabilities change or get dropped entirely. Or you might use nightly if you’re a good citizen and testing out the experimental capabilities so that you can give feedback on them.

A later version of nightly could potentially change or drop the features of an earlier version of nightly in ways that are not backwards compatible. That’s why you might have to specify which version of nightly you need (potentially an older version), if you’re building something that depended on nightly features.

I use thread sanitizer and address sanitizer in my CI, and they have certainly helped in some cases, but they don’t catch everything. In fact it’s the cases that they miss which are by far the most subtle instances of undefined behavior of all.

They also slow down execution so severely that I can’t use them when trying to recreate issues that occur in production.

I’m not sure if you’re genuinely asking what a test suite is or if this is a sarcistic joke about how no one bothers to test their C++ code.

And even if you do get to use pure modern C++ you’ll still get burned by subtle cases of undefined behavior (e.g. you probably haven’t memorized every iterator invalidation rule for every container type) that force you to spend weeks debugging an inexplicable crash that happened in production but can only be recreated in 1/10000 runs of your test suite, but vanishes entirely if you compile in debug mode and try to use gdb.

And don’t even get me started on multi-threading and concurrency.

There’s a difference between “You have to decide when to synchronize your state” and “If you make any very small mistake that appears to be perfectly fine in the absence of extremely rigorous scrutiny then this code block will cause a crash or some other incomprehensible undefined behavior 1/10000 times that it gets run, leaving you with no indication of what went wrong or where the problem is.”

I’m not saying you can’t do multi-threading or concurrency in C++. The problem is that it’s far too easy to get data races or deadlocks by making subtle syntactical mistakes that the compiler doesn’t catch. pthreads does nothing to help with that.

If you don’t need to share any data across threads then sure, everything is easy, but I’ve never seen such a simple use case in my entire professional career.

All these people talking about “C++ is easy, just don’t use pointers!” must be writing the easiest applications of all time and also producing code that’s so inefficient they’d probably get performance gains by switching to Python.

Your graph also cuts out early. Eventually you want to get performance gains with multi-threading and concurrency, and then the line drops all the way into hell.

Yeah that’s my big takeaway here: If the people who are rolling out this technology cannot make these assurances then the technology has no right to exist.

“Instantly” on a geological scale 🙃

I imagine the number goes up considerably when you account for showering, washing clothes and dishes, and water used while cooking. It would go up even more if you account for the water used to produce the food consumed by the individual.