[BiteCode_dev]

Given how those discussions usually go, and the scale of the change, I find that discussion extraordinarily civil.

I disagree with the negative tone of this thread, I'm quite optimistic given how clearly the parties involved were able to communicate the pain points with zero BS.

[nickparker]

I found myself reading this more for the excellent notetaking than for the content.

I suspect the discussion was about as charged, meandering, and nitpicky as we all expect a PL debate among deeply opinionated geeks to be, and Jake Edge (who wrote this summary) is exceptionally good at removing all that and writing down substance.

[BiteCode_dev]

Certainly.

We are talking about extremely competent people who worked on a critical piece of software for years and invested a lot of their lives in it, with all pain, effort, experience, and responsibilities that come with that.

That this debate is inscribed is a process that is still ongoing, and in fact, progressing, is a testament to how healthy the situation is.

I was expecting the whole Rust thing to be shut down 10 times, in a flow of distasteful remarks, already.

This means that not only Rust is vindicated as promising for the job, but both teams are willing and up to the task of working on the integration.

Those projects are exhausting, highly under-pressure situations, and they last a long time.

I still find that the report is showing a positive outcome. What do people expect? Move fast and break things?

A barrage of "no" is how it's supposed to go.

[0cf8612b2e1e]

I am definitely of the opinion we need to rush away from C. Rust, Go, Zig, etc does not matter, but anything which can catch some of the repeated mistakes that squishy humans keep repeating.

That being said, the file system is one of those infrastructure bits where you cannot make a mistake. Introduce a memory corruption bug leading to crashes every Thursday? Whatever. Total loss of data for 0.1% of users during a leap year at a total eclipse? Apocalypse.

There is no amount of being too careful when interfacing with storage. C may have a lot of foibles, but it is the devil we know.

[structural]

I agree. And ideally, every time you raise the question and get the "no" response, you learn something about the system you're modifying or the reviewer learns something about your solution. Then you improve your solution, and come back.

Eventually consensus is built - either the solution becomes good enough, or both the developers and the reviewers agree that it's not going to work out and the line of development gets abandoned.

Large-scale change in production is hard, and messy, and involves a lot of imperfect humans that we hope are mostly well-intentioned.

[emporas]

Moving using a 70's technology breaks things. Rust is tested already on other OSes like Windows, Mac (or iOS) and Android and solves several pitfalls of C and C++. Some quotes from the Android team [1]:

"To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code."

"Safety measures make memory-unsafe languages slow"

Not saying Rust is the perfect solution to every problem, but it is definitely not an outlandish proposition to use it where it makes sense.

[1] https://security.googleblog.com/2022/12/memory-safe-language...