[nick_]

If Rust is the language that finally overwhelms the resistance to memory safe languages, that's good.

I think it's also important not to centre Rust alone. In the larger picture, Rust has a combo of A) good timing, and B) the best evangelism. It stands on decades of memory safe language & runtime development, as well as the efforts of their many advocates.

[jandrewrogers]

This statement seems imprecise. We've had memory-safe languages for decades and they are the primary programming languages used today e.g. Java and Python. There is no meaningful resistance to them.

If you look at what unsafe languages are used for, it mostly falls into two camps (ignoring embedded). You have legacy code e.g. browsers, UNIX utilities, etc which are too expensive to rewrite except on an opportunistic basis even though they could be in principle. You have new high-performance data infrastructure e.g. database kernels, performance-engineered algorithms, etc where there are still significant performance and architectural advantages to using languages like C++ that are not negotiable, again for economic reasons.

Most of the "resistance" is economic reality impinging on wishful thinking. We still don't have a practical off-ramp for a lot of memory-unsafe code. To the extent a lot of evangelism targets these cases it isn't helpful. It is like telling people living in the American suburbs that they should sell their cars and take the bus instead.

[odyssey7]

I don’t buy the economic argument favoring memory-unsafe languages. There are fast memory-safe options. Legacy codebases can eventually become more expensive to maintain than to rewrite. What is the economic cost of an Achilles’ heel when critical systems are destroyed?

There are critical systems today that are essentially Prince Rupert’s drops. Mightily impressive, but with catastrophic weaknesses in the details.

[wglb]

> Legacy codebases can eventually become more expensive to maintain than to rewrite

I'm wondering what the cost would be of rewriting Chrome, at 20 to 30 million lines of code, in Rust?

I suspect that despite the memory unsafety, the cost of maintaining it in its current form is vastly lower than this.

Plus, any rewrite will certainly introduce new bugs, some of them temporarily serious. Did you see the post years back about a Rust program that exhibited the Heartbleed bug?

These new bugs need to be taken into account when estimating the cost of rewrite.

[odyssey7]

Here is the compatibility table for ECMAScript 6 features by vendor.

https://compat-table.github.io/compat-table/es6/

Chrome is currently unable to support a feature that was added to JavaScript in 2015 for ECMAScript 6.

The reason given was something about proper tail calls being beyond the technical capabilities of the teams involved.

If the code in or surrounding Chrome and its underlying V8 engine are currently so unmaintainable that the teams cannot incorporate a JavaScript feature from 10 years ago, then the cost of merely maintaining the C++ codebase is too high.

The all-or-nothing, now-or-never framing makes the change feel more intimidating than it would be in practice. Mozilla's strategy is to incrementally use Rust more and more in their C++ codebase. I don't know what Chrome's plan is, but the fact that Mozilla is able to make progress is an indication that it isn't impossibly expensive to do better. Mozilla is a non-profit, while Google's Q1 2025 revenue was $77.3 billion.

> Did you see the post years back about a Rust program that exhibited the Heartbleed bug?

Do you remember the actual Heartbleed bug?

> 20 to 30 million lines

In my own experience, seasoned engineers often remind me that every line of code is a liability. Tens of millions of lines of C++ that work closely with the internet sounds like quite the surface area.

[wglb]

> Do you remember the actual Heartbleed bug?

Vividly. I spent a full week on remediation, even though the risk we had was traced to a single linux box exposed to the internet that had tens of kb of traffic over the last year.

Being proactive, we reissued all certificates for all of our internally deployed ssl points.

> In my own experience, seasoned engineers often remind me that every line of code is a liability. Tens of millions of lines of C++ that work closely with the internet sounds like quite the surface area.

No question. I don't question the wisdom of rewriting all of it in Rust. Having spent 60 years in the software business, I have a feeling for the size of the effort. And for what it is worth, I don't have any doubt about the competency of the teams involved.

[tptacek]

I think it's important to keep the scope of the debate well-defined, because memory-safe languages completely stomped out memory-unsafe languages more than 20 years ago; almost all new code is written in languages that are unshowily memory safe (like Java and Python).

We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

[olarm]

> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

And control systems, c++ (along with PLCs ofcourse) dominates in my experience from developing maritime software and there doesnt appear to be much inclination towards change.

[tuveson]

> browsers and operating systems

And the VMs for the two languages that you mentioned above (edit: though to be fair to your comment, I suppose those were initially written 20+ years ago).

[zahlman]

To be fair, there's a pretty clear difference between achieving memory safety with a garbage collector and run-time type information, versus achieving it through static analysis.

[fiddlerwoaroof]

Static analysis is worse and limits the programs you can write in annoying ways?

[zahlman]

I like dynamic typing, but the point wasn't about holy warring. The point is simply that it's different.

[chubot]

There’s also google, yandex, baidu, and bing, which are incredible amounts of c++ code

And probably lots of robotics, defense, and other industries

Granted, those aren’t consumer problems, but I would push back on the “last redoubts”.

We should absolutely move toward memory safe languages, but I also think there are still things to be tried and learned

[npalli]

> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

.. and other performance critical areas like Financial applications (HFT), High Performance Computing (incl. AI/ML), embedded, IoT, Gaming/Engines, Databases, Compilers etc.. Browsers and OS are highly visible, but there is a gigantic ton of new C++ code written everyday in spite of the availability of memory safe languages.

[tptacek]

People keep coming up with all these examples of things still written in C/C++. Sure. So are most AAA games. But so far nothing that's been identified --- maybe excepting databases, but vulnerabilities there are still rare --- that is a meaningful component of insecurity, which is what "memory safety" addresses.

[spacechild1]

> that is a meaningful component of insecurity, which is what "memory safety" addresses.

There are plenty of people, though, who argue that everything must be memory safe (and therefore rewritten in Rust :) I personally don't agree with that sentiment and it seems like you don't agree either.

[tptacek]

It would be better for everyone if everything on a forwardgoing basis was written in a memory-safe language.

[spacechild1]

What difference does it make for a video editor or DAW?

[Ar-Curunir]

and cryptographic code.

[wglb]

My favorite crypto bug was not a memory safety issue: https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squ...

Was a fascinating detective story to illustrate it.

[noelwelsh]

Rust also didn't give up, whereas earlier languages like Cyclone did. This is a problem with the different incentives in research; once you've shown it works there is no funding for further development.

[jekwoooooe]

Go is fast and memory safe. It has some data race protections built in but doesn’t go as far as rust. This has its benefits like not having to deal with borrow checker insanity (or rust syntax for that matter)

Unlike python or java, it’s both compiled and fast

[haimez]

Java is both compiled (first to bytecode, then to machine code by the JIT) and fast (once JIT compiled).

[jandrewrogers]

It depends on what you are using it for, “fast” is relative. Java can be fast for applications where performance and scalability are not a primary features. If performance and scalability are core objectives, even performance-engineered Java isn’t really competitive with a systems language. You can bend Java to make it perform better than most people believe, especially today, but the gap is still pretty large in practice.

I wrote performance-engineered Java for years. Even getting it to within 2x worse than performance-engineered C++ took heroic efforts and ugly Java code.

[Raidion]

Java is "fast" but not fast. Most of the time if performance is a true concern, you are not writing code in Java.

[frollogaston]

I have yet to run a Java program that I haven't had to later kill due to RAM exhaustion. I don't know why. Yeah an Integer takes 160 bits and that's without the JVM overhead, but still. Somehow it feels like Java uses even more memory than Python. Logically you'd point the finger at whoever wrote the software rather than the language/runtime itself, but somehow it's always Java. It's like the Prius of languages.

Ok, just glanced at my corp workstation and some Java build analysis server is using 25GB RES, 50GB VIRT when I have no builds going. The hell is it doing.

[cherrycherry98]

GC usually only runs when the process wants to allocate an object but there's no space left on the heap. It's entirely possible that it did a bunch of work previously which created a bunch of garbage now waiting to be cleaned up. See the G1PeriodicGCInterval flag to enable idle collections (assuming G1).

Java is also fairly greedy with memory by default. It likes to grow the heap and then hold onto that memory unless 70% of the heap is free after a collection. The ratios used to grow and shrink the heap can be tuned with MinHeapFreeRatio and MaxHeapFreeRatio.

[_w1tm]

Why do Java developers still have to tune stuff like that?

[lmm]

> Ok, just glanced at my corp workstation and some Java build analysis server is using 25GB RES, 50GB VIRT when I have no builds going. The hell is it doing.

Allocating a heap of the size it was configured to use, probably.

[frollogaston]

That's a max size, not a preset allocation. The process normally starts out using 1GB.

[adgjlsfhk1]

don't slander the Prius! it's an incredibly efficient and robust machine. Java is a Chevy Colerado. surprisingly common for how unreliable it is

[frollogaston]

That's what I mean, surely the Prius can reach 100mph, but you rarely see it go past 55. Usually in the fast lane. It's a paradox.

[AlotOfReading]

More of a historical footnote than a serious example, but you've never had to kill the Java applications running on your SIM card (or eSIM).

[frollogaston]

I don't know about that, my flip phone used to crash quite often. And it displayed a lot of Java logos.

[lmm]

Java is fast for long-running server processes. Even HFT shops competing for milliseconds use it. But yeah every user-facing interactive Java application manages to feel clunky.

[symbolicAGI]

Learned from an NYC exchange 10 years ago that Java can be written so as to not use garbage collection. Fast and no pause for GC.

1. Resource and reuse objects that otherwise are garbage collected. Use `new` sparingly.

2. Avoid Java idioms that create garbage, e.g. for (String s : strings) {...}, substitute with (int i = 0, strings_len = strings.length(), i < strings_len) { String s = strings[i]; ...}