And why are you imagining things would go down like that

Because I am familiar with human behaviour.

Rust is disabled by default

I’m not too familiar with Linux’s CI system but I assume they at least test that it compiles, even if it is disabled by default.

or the kernel releases with broken Rust

This is what I don’t believe. I think what will actually happen (or could at least), is:

C dev that refuses the learn Rust: “Hi, here’s a change to the DMA API.”

Linus: “Can you fix the Rust code before I merge this?”

C dev: “Ok, Rust devs it’s your job - can you fix it?”

Rust devs: “”

C dev: “Hello? Where are you?”

…

C dev: “Can we just merge it now?”

Linus: “No we need to fix the Rust.”

Again, to be 100% clear, I think that this shouldn’t block Rust. We should just expect the C devs to learn a bit of Rust (seriously if they’re writing Linux DMA systems they are easily bright enough to do it). But pretending that they won’t have to to keep them happy seems disingenuous.

To be clear I fully support Rust in Linux. I just think it’s going to rapidly be impractical to work on Linux without learning Rust.

The solution isn’t to pretend that isn’t the case; it’s to learn Rust!

I do understand that that’s what they claim. I just don’t believe them. Because it requires either

1. magical Rust maintainers who are always on call to help, or
2. people to be on with the Rust code breaking all the time.

Neither seems likely.

Sometimes I prefer video… But usually not.

E.g. this channel has fantastic videos: https://youtube.com/@therustybits

I don’t know I think the argument about forcing maintainers to learn Rust is probably true - sure the Rust code might not touch the DMA code, but Linux doesn’t have stable APIs so in theory you’re supposed to be able to change an API as long as you fix all the drivers that use it.

That now involves fixing Rust drivers, so you’re going to need to know Rust.

However I don’t think that’s a good reason not to do it. In my opinion Linus should just be honest and say that the Rust experiment has been successful, Rust is going to be part of the kernel moving forwards, and you will probably have to get off your arse and learn it.

All this “you won’t have to learn Rust” talk is thin reassurance to keep people happy. I don’t think anyone really believes it.

Reminds me of when WASM was introduced and everyone was saying “the goal isn’t to replace JavaScript” to keep the JavaScript folk happy, despite everyone knowing that that was exactly the goal.

So glad they made the sane move and fixed std::env::home_dir(). The previous situation of having it deprecated due to fairly insignificant reasons, while recommending an abandoned crate instead was just silly.

Well COBOL hasn’t completely gone away… I don’t think anyone expects C to become completely extinct; just very legacy.

D missed its chance. Zig is clearly going to be the successor to C, for people who don’t want to use Rust.

Yes, but be warned, formal software verification is proper hardcore. Complicated computer science theories, scant documentations - much of which assumes you have a PhD in the field, and in my experience it’s quite a leaky abstraction. You’ll end up needing to know a lot about the actual implementation of Lean to figure out why some things work and others don’t, in a way that you don’t need to in “normal” languages.

It’s quite satisfying when it works though. Like a puzzle.

I highly recommend this fun “game”: https://adam.math.hhu.de/#/g/leanprover-community/nng4

You can transform any recursive algorithm into iterative pretty easily though; just create a manual stack.

The rule definitely makes sense in the context of C code running in space. Unbounded recursion always risks stack overflow, and they probably don’t have any tooling to prove stack depth bounds (you totally can do that, but presumably these standards were written in the 1500s).

There isn’t one. It’s still a shit show.

The most reliable way to distribute software on Linux is still to make a statically linked binary (linking with a very old glibc is fine) and use curl | bash. But that isn’t always possible depending on the language used and the app.

Seems like OBS Studio is C++/Qt, so it shouldn’t be too difficult though. I’ve done it before in the distant past. But looking at their releases they only provide .deb for Linux, so I can understand why people would want something else.

200?! I can pretty confidently say approximately nobody is anything like you 😄

Yeah… I suspect in 20 years this defence of C will seem just as incomprehensible.

Yeah they probably should have tried that. On the other hand this isn’t the first time, and Linus didn’t do anything then either.

I assume he meant Linux on x86 laptops, where I can confirm battery life is atrocious and support for random display things is also pretty bad. My laptop still wont do more than 30 Hz over HDMI (works fine with DisplayPort though).

The classic “I had it hard so you should too” mentality. I think it fundamentally comes from an animal desire for fairness - it isn’t fair that these old geezers had to put up with C shooting them in the feet at the drop of a bracket, while the new kids on the block get friendly (usually) compiler errors instead.

But I think if you don’t recognise that instinct in yourself and overcome it then you have failed as a human.

I’ll always remember the pushback to making xfree86 easier to configure (yes I’m old). Back in the day you had to edit a stupid text file to tell X that your screen could display 1024x768 and your mouse had three buttons. Then some upstarts came along and make it automatically detect that. The absolute cheek! Our ancestors have been practicing xfree86config since before you were a wee bebe! Etc. etc.

It’s a human condition.

I do also agree with Linus that immediately running to social media to drum up drama is not the correct solution to getting it fixed.

So what is the correct solution?

Yeah the main reason is performance. In some languages if you use a value “linearly” (i.e. there’s only ever one copy) then functional style updates can get transformed to mutable in-place updates under the hood, but usually it’s seen as a performance optimisation, whereas you often want a performance guarantee.

Koka is kind of an exception, but even there they say:

Note. FBIP is still active research. In particular we’d like to add ways to add annotations to ensure reuse is taking place.

From that point of view it’s quite similar to tail recursion. It’s often viewed as an optional optimisation but often you want it to be guaranteed so some languages have a keyword like become to do that.

Also it’s sometimes easier to write code that uses mutation. It doesn’t always make code icky and hard to debug. I’d say it’s more of a very mild code smell. A code musk, if you like.

He definitely improved it… but there’s still plenty of material for r/linusrants.

He may not directly call people names anymore but he’s still extremely rude and unprofessional. He would have been fired long ago from any company I work for, and I live in the UK where it’s practically impossible to get fired.

Probably what all the horse people said when cars were invented.