The idea is that instead of controlling memory layout and referencing directly, you communicate your intent: do you care about this value's identity or not? Do you need atomicity or not? Do you need nullability or not? Once the intent is clear, the compiler is free to choose the most appropriate and efficient layout for the particular value at the particular use site. In other words, you say what semantics you're interested in rather than how to implement them at the lowest level.

This opens up optimisation opportunities that are lost when the programmer directly controls the representation rather than the intent. E.g. in other languages you may say whether you want to pass some value by reference or by value. Here the compiler is free to say, well, if identity and nullability are not needed here, I can either pass by value or by reference, and I'll do whichever is more efficient.

And by the way, your point about early misdesign (whether it applies here or not) also inverts the desired state. Every language makes decisions that will be suboptimal in the environment some time later, and Java certainly has its share (its mutability and nullability default; how it treats serialisation). Rust, for example, was first designed twenty years ago, and some of its fundamental decisions reflect the state of the world at that time (it went all-in on some C++ premises that seemed fine 20 years ago). But since important codebases often outlast the outdatendness of early language decisions (your OS and your browser are running some >30yo code and/or affected by >30yo design decisions), one of the things most important in a language isn't the decisions it makes early on - some will prove "wrong" while your codebase is still alive and kicking - but how well it adapts and evolves. So when you pick a language for an important project today, the language's current state will end up mattering less than how the language evolves in the future. The question asked isn't "will I like this decision today?" but "will I regret this decision ten years from now?" Java is one of the languages with the lowest "regret factor", possibly lowest of them all.

It will be significantly worse than Java, at least in some important situations (don't know about C#). I've been programming in C++ for many, many years, and I find it increasingly hard to even match Java's performance, even when writing unsafe code, especially when programs get larger and/or more concurrent (very broadly speaking, Java's performance is about that of C++ - in some situations it's worse and in others is better, but the same general vicinity; after all, the JVM was designed to address some of the performance issues that certain classes of C++ programs suffer from).

Performance is not the reason to use a low-level language in many domains, and in those domains, if you want super-high performance and safety, there are better and more popular alternatives already. You use a low-level language when you need the things low-level languages do best, but you also expect performance that is more-or-less the same as the high-performance safe alternatives.

But even aside from the fact that writing the code is only a very small portion of the effort in this particular project (you can see that the volume of code making its way into the JDK is very small compared to the number of people involved), I'm often amazed by the gap between how well a frontier model (GPT 5.6 Sol in my case) can comprehend code and investigate a bug, and how badly it writes code and documentation, even when it understands things well. So not only is writing the code not a large portion of the effort in this project, it also happens to be one of the things current models don't do as well as other things.

We're talking about one of the biggest and most critical open source projects in the world, and unless there's some immediate urgency, it's okay to wait before taking on some risk.

I should add that the potential loss here isn't big. For any fix, enhancement, or feature in the JDK, the cost of writing the code is rarely more than 10% of the total cost (which is easy to see if you compare the number of people involved in the project to the rate of code being added or changed), and the interim policy explicitly does allow the use of AI where it helps the most.

Sure, but memory safety by itself is not the reason to pick Rust because other languages do memory safety even better.

> What exactly is the low level subset you feel like you can't use?

The things that make me want to use a low-level language in the first place, such as controlling exactly when memory is allocated and freed and where exactly objects are placed in memory.

When I don't need to do these things and all I want is memory safety and performance, then I already have better options.

I don't think that, but I don't think that "the borrow checker is a good idea independent of memory safety" in an unqualified way. I don't doubt its general utility for one second, but I resist adding a lot of useful constructs to the language I have some influence over because I think that every feature hurts the language a bit by adding complexity. So for every feature the tough question isn't "is it useful" but "is it worth the price?" I don't have an answer for the borrow checker (and the answer also depends on the language's intended audience) but I don't think it's an obvious yes.

> The painfully constricting flexibility so reminiscent of C that everyone else clings to is not where I want to go back to.

That's not what I was talking about. When I use a low-level language, I use it not for what I would call flexibility, but for what I would call control. If Rust could give me safety in the parts I'm less interested in for "free", I wouldn't care about using unsafe Rust. The safe part would be pure bonus; not worth a whole lot, but I'll gladly take it. But that's not what's happening. To support safety in the safe subset, Rust is so complicated that I pay the price whether I get to enjoy that safety or not.

I think that for the safe parts, Rust would have been better off using some flavour of non-moving GC because interop between full-control low-level code and non-moving GC isn't too hard (whether tracing or refcounting; it doesn't matter all that much), which would have kept the safe part simpler. Maybe it would have looked more like Swift.

Of course you can, but the reason you don't is that their performance would be quite bad. I guess you could call that "an optimisation", but good performance for these data structures is a requirement. I am well aware that you can do a lot in safe Rust, but the result is such that you wouldn't want to use Rust at all.

> That Rust allows you to define your own safe interfaces to unsafe constructs is a strength of Rust, and necessary for any language that wants to challenge C and C++ on the basis of runtime performance.

Every language with unsafe constructs allows you to do that! The problem is that with Rust you need to do it quite a bit (of course, if you want acceptable performance, that is). That's not an upside of Rust compared to other safe languages, it's a downside.

> Turns out, things that people take as obvious can also be wrong.

They can, but this one isn't. Safe Rust is Turing complete and in the functional sense you could do anything with it. But the same is true for Python. So does that mean safe Rust and Python are interchangeable because by your measure they can do the same things? Of course not.

But those pointers would not interoperate easily with code that does not expect them. Of course you could effectively "host" a moving GC world inside Rust (or C++, or C), just as you could host the entire JVM in a Rust program (or vice-versa, host a Rust program in a Java program), but the effectiveness and attractiveness of that depends on interoperability with existing libraries.

Java's FFM also lets you bring your own memory management strategies, but the interop with existing types is not transparent (i.e. while you can put a manually-managed object that implements a Map or a List interface in the manually-managed portion, you cannot let that Map or List store arbitrary Java objects).

So there can be interfaces that connect a world of moving pointers and a world of non-moving ones (that's what FFM is), but then the interop between them is pretty much the same as FFM, i.e. the interface between Java and C. That's not really "in the same language".

> Given that in Java everything is under indirection anyway,

I don't know what that means. References in Java are implemented as pointers (some GCs use free bits for some stuff). Maybe you mean that Java doesn't yet have types that are flattened into their container, but it will soon: https://openjdk.org/jeps/401 (this is only the first step). Indeed, that was the last gap that could still allow me to match or beat Java's performance even in some large programs (provided they matched a domain where this was important, and there are certainly some). With that gap closing, the number of large programs where I, an experienced C++ programmer, could even match Java's performance without extraordinary effort is getting very, very, very small.

And that's exactly my point. The safe subset of Rust doesn't sufficiently cover the very things that I choose a low-level language for in the first place, and the parts it does cover I can do at least as well in even safer high-level languages.

Now, I'm not saying there aren't programs where Rust's precise mix of safety and unsafety is better than the alternatives. For example, I've never written a browser rendering engine, and it's possible that I would find Rust to be the best fit for that task. I don't know that I would, but I also have no experience with that domain to suggest that I wouldn't.

No, it isn't. First of all, data races in Java are memory-safe, as guaranteed by the Java memory model. Second, even if that were safer in some sense it is only by dint of restricting the capabilities of the safe subset further, thus requiring more unsafe code, not less (e.g. because of that data race restriction in Rust, benign races, which are rather common in concurrent code and are not only safe but also deterministically correct, also require unsafe code).

The major challenge with safety is how to offer it without complicating the language much and not restricting the safe subset. It becomes much easier if you do one or both, and Rust compromises heavily on both, which comes at a price (correctness may suffer if the language is complicated, and safety and/or performance suffer when the safe subset is restricted). Some may find that tradeoff attractive, but it should be clear why others don't.

> Also note that Java has unsafe, but doesn't have the culture of plainly stating safety invariants like Rust. The unsafe features of Java are less widely used, but when they are you rarely know if a Java library has unsafe internals for performance, and if they do, it may be hard to audit

Quite the opposite. First, Unsafe is being removed altogether (https://openjdk.org/jeps/498), and overall, the remaining unsafe operations are now restricted to a very narrow, well-defined set of APIs (basically FFM, the FFI API). Second, Java's integrity guarantees (you can think about integrity as generalised memory safety) - as well as requesting exceptions to them (e.g. permissions to use FFM) - are handled in a more centralised, well-integrated, and auditable way than in any other well-known language: https://openjdk.org/jeps/8305968

It won't be anywhere near Java's. Those GCs are mark-and-sweep collectors. Java uses moving collectors. Moving collectors are used to avoid the high overheads of malloc/free in the C runtime (or of any free-list-based mechanism). They're a performance optimisation. Heap allocations in Java behave more like arenas than like heap allocations in languages with non-moving memory management, whether it's C, Rust, Python, or Go. Other runtimes that use moving collectors are Google's V8 and Microsoft's .NET, except that Java's ZGC has no GC pauses.

No, you're missing the point, which is that you cannot write some common data structures in safe Rust (whether they're implemented in the standard library or in the compiler), but you can in Java (inside or outside the standard library). In other words, the point is that safe Rust is quite restricted.

> Java's own data structures are implemented with the support of an extensive runtime written in C++, which forms their own trusted computing base that every user of Java relies upon, and demands just as much careful auditing as any data structure in the Rust standard library.

No, because these data structures are not part of the trusted computing base, which is fixed and closed. In Rust, that base has to be extended to any third-party code that uses unsafe, which is needed in many more situations. In fact, the need for unsafe code in Java has been so reduced that we're currently in the process of removing Unsafe altogether, making it inaccessible to third party code, which would still be able to write the data structures that would be unsafe in Rust in safe Java (the only unsafe thing remaining would be the FFM API, used for FFI, and the legacy JNI, used for that same purpose).

It isn't controversial that the amount of stuff you can do in safe Java is significantly higher than the amount of stuff you can do in safe Rust. That's just obvious.

But to answer your question, I reach for a low-level language when I need the one and only thing low-level languages are designed to do best, which is give me full and precise control over the hardware. In those situations, Rust offers little safety in the interesting/subtle/critical code, and for me it even makes things worse. It helps with the simple uninteresting code. So it's not a matter of quantity but of quality.

Of course, if the tricky parts of the program don't require precise control over the hardware, I don't use a low-level language in the first place. For example, if I'm going to let the language manage memory for me, why suffer the high overhead of heap memory management in the Rust/C runtime when the Java runtime offers me lower overhead?

And that brings me back to the universality point, that you're actually repeating, so let me explain it again. All programming languages bring a certain aesthetic that appeals to some and repels others within their intended domain. For example, I prefer Java to C# and Kotlin because I place a value on language simplicity, but I'm well aware that some other people like a lot of convenience features and they have the opposite preferences. I don't expect everyone to like Java even among those who work in the domains in which it is intended. For the same reason, I prefer Haskell over Scala and Clojure to Common Lisp, yet I fully recognise there are those who have the opposite preference.

Yet when people say they don't like Rust, the reaction among those who do is often one of: you don't want it to work, you don't care about correctness, your situation is special, or you just don't get it. I.e. they expect Rust to be universally liked unless there's a some good exceptional reason not to. But this is not the case for any language, let alone a language as complicated and as rich as Rust, which is certain to evoke a strong aesthetic reaction either for or against. So I have a long, long record of working with low level languages, I have a long record of working with formal methods and studying software correctness in general, I've worked extensively on safety-critical and mission critical systems, and I find Rust unappealing. There is nothing that should be surprising about that, there is nothing special about Rust or any other language that should lead anyone to expect it to be universally liked among those in the domains for which it is intended, and indeed, it is not the case for Rust as it is not the case for any other language. This amazement that quite a few people, even those with the relevant expertise, don't like your favourite language is exactly this sense of universality that I find annoying.

That some people get it yet don't want to choose a language is the case for Java, it's the case for Haskell, it's the case for Zig, and it's the case for Rust. Some people who really care about writing correct low-level code will have good reasons to choose Rust over other languages, while others who really care about writing correct low-level code will have equally good reasons to choose other languages over Rust. It's not because our programs are special, but it's because we think we can do it better with other languages. That's just the reality of all programming languages ever made, and that's what I mean by no universality. There is no external, objective requirement for any program that makes any (general purpose) language objectively best for that program. Choices always involve some kind of personal aesthetic preference.

That your favourite language isn't "objectively best" and isn't universally preferred even among those who care about the things you care about isn't something that should bother you, and pointing out this simple fact isn't trolling. It's something you should expect, because it's always true.