I’m not convinced he really believes that OpenAI is going to roll out AGI in the next ten years, but I’m completely sure he’s determined that it’s a good marketing strategy to make people believe that he believes it.

OP really needs to heed this advice. Modifying things in the cache will cause breakages that will confuse the hell out of you.

Speaking as an annoying Rust user, you’re being bigoted. I’m annoying, but the vast majority of Rust users are normal people who you wouldn’t even know are using Rust.

Don’t lump all the others in with me, they don’t deserve that.

Best practice when using .unwrap() in production code is to put a line of documentation immediately above the use of .unwrap() that describes the safety invariants which allow the unwrap to be safe.

Since code churn could eventually cause those safety invariants to be violated, I think it’s not a bad thing for a blunt audit of .unwrap() to bring your attention to those cases and prompt to reevaluate if the invariants are still satisfied.

But only if pattern matching were included, otherwise they would be as unpleasant as C++'s std::variant.

This makes a lot of sense, but the functions were Rust bindings for plain C functions, they weren’t function pointers. Granted I could have put pointers to the function bindings into fields in a struct and stored that struct in the mutex, but the ability to anyhow call the bindings would still exist.

It’s a massive win, and I would question the credibility of any systems programmer that doesn’t recognize that as soon as they understand the wrapper arrangement. I would have to assume that such people are going around making egregious errors in how they’re using mutexes in their C-like code, and are the reason Rust is such an important language to roll out everywhere.

The only time I’ve ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.

I think the point is that Republicans detest the idea of being weird no matter what, so they would rage at the suggestion of being a good weird anyway. To them “good weird” is an oxymoron, even though they are actually very weird and not in any kind of good way.

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.

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.

The only way to fix C++ is if you’re willing to break backwards compatibility and invent C++2.0.

But that already exists, and it’s called Rust.

The way I often describe it is “Rust makes functional programming feel as intuitive as object oriented programming”.

Pedantically, Rust does offer a subset of object oriented programming paradigms so one could argue that it counts as an object oriented language, but the design patterns that work the best with the language are all coming from functional programming, all without feeling too alien to someone coming from a strictly object oriented background (… which was my own path into Rust).

Maybe Rust isn’t a good tool for massively concurrent, userspace software.

This conclusion is a very weak one.

The only argument the article successfully makes is that using the raw async/await mechanisms of the Rust language leads to situations where it’s tricky to figure out how to structure your code, and that the raw async mechanisms of some other languages don’t have that friction.

But why would we only consider the strengths of the pure out-of-the-box Rust language and forget that it has an enormous robust ecosystem of crates? For any given use case there will be suitable frameworks that make async Rust programming both natural and performant. Or if such a framework doesn’t exist it is possible to develop one on top of the async mechanisms of the raw language because those mechanisms are so unopionated by design.

My colleagues struggle with async Rust as-is. I did too for quite a while. But that’s why I’m developing two different async Rust frameworks for two different software architecture paradigms (one that fits nicely into an ECS and one that fits nicely into a deterministic scheduled worker pool) each of which we have different use cases for. If the Rust async design was more opinionated and imposing (which is what this article is recommending) then I likely wouldn’t be able to produce frameworks that are as effective for each of these use cases… one or the other would have suffered, likely both.

When it comes to certifying your own software, the evidence is the key thing needed by the certifying bodies.

If I’m someone who wants to get my Rust software safety certified, it’s not enough for me to tell the certifier “I compiled my software with this compiler from a project called Ferocene and they have a blog post saying that they’re safety certified. Give me a certification please.”

Instead you need to show the certifier all the evidence that went into the safety case that achieved certification for Ferocene and then make a case that the evidence is relevant to your own safety case. This evidence from Ferocene is what you pay them for.