Looks interesting. Linux ABI compatibility is a herculean task though. Probably on the order of writing a web browser or a MS Word compatible word processor.

Well that just sounds insane. Isn’t the whole point of an abstracted API that you can write code for it once and it works with all of the implementations?

submitting a merge request with changes that don’t compile is an absolute no-go.

Right but unless the tests for all 50 filesystems are excellent (I’d be surprised; does Linux even have a CI system?) then the fact that you’ve broken some of them isn’t going to cause a compile error. That’s what the linked presentation was about! Rust encodes more semantic information into the type system so it can detect breakages at compile time. With C you’re relying entirely on tests.

Ask the Rust maintainers to fix it presumably? The antagonist in the video above claimed there are 50 filesystems in Linux. Do they really fix all 50 filesystems themselves when they change the semantics of the filesystem API? I would be very surprised. I suspect what actually happens currently is either

1. They actually don’t change the semantics very often at all. It should surely be stable by now?
2. They change the semantics and silently break a load of niche filesystems.

I mean, the best answer is “just learn Rust”. If you are incapable of learning Rust you shouldn’t be writing filesystems in C, because that is way harder. And if you don’t want to learn Rust because you can’t be bothered to keep up with the state of the art then you should probably find a different hobby.

These “ooo they’re trying to force us to learn Rust” people are like my mum complaining you have to do everything online these days “they’re going to take away our cheque books!” 🙄

Operating system interfaces use the C ABI, but they don’t require you to use C.

Actually that’s true on most OSes, but not Linux - that uses syscalls as its interface not function calls to a shared library, so it’s the syscall ABI.

I still feel like designing and bootstrapping your own higher level language is going to be less painful overall than writing a Rust compiler in C. And probably more fun.

This, of course, only works on little-endian machines. On big-endian machines, c has to be bytereversed.

Interesting advantage of little endian!

Not really because RefCell has performance implications and also adds noise to the code.

But I would not be a fan of implicitely allowing multiple mutable borrows without any clue for that in the code.

Nobody is suggesting breaking Rust’s multiple mutable borrow restriction. The macro solution simply doesn’t do that, and the “make the borrow checker smarter” solution just releases the mutable borrows when they aren’t being used so they don’t overlap.

The benefits are that you don’t have to pass out and similar captured variables into the closures/functions.

Yeah that’s pretty unreadable IMO. I think your second link isn’t what you intended?

I dunno, does it even need a new feature? Kind of feels like Rust should be able to figure it out as long as the lambdas aren’t moved/stored/etc?

Sorry that example was a bit too limited to demonstrate the problem actually. Add a second lambda and you hit the issue:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=eb99d3d670bdd9d92006f4672444d611

Still totally fine from a safety point of view, but the borrow checker can’t figure that out.

I disagree. It’s a sign your code isn’t structured in a way that the borrow checker understands, but that is a subset of well-structured code.

In other words, if your code nicely fits with the borrow checker then it’s likely well structured, but the inverse is not necessarily true.

One thing I always run into is using lambdas to reduce code duplication within a function. For example writing a RLE encoder:

fn encode(data: &[u8]) -> Vec<u8> {
  let mut out = Vec::new();

  let mut repeat_count = 0;

  let mut output_repeat = || {
     out.push(... repeat_count ...);
  };

  for d in data {
      output_repeat();
      ...
  }
  output_repeat();
  out
}

This is a pretty common pattern where you have a “pending” thing and need to resolve it in the loop and after the loop. In C++ you can easily use lambdas like this to avoid duplication.

Doesn’t work in Rust though even though it’s totally fine, because the borrow checker isn’t smart enough. Instead I always end up defining inline functions and explicitly passing the parameters (&mut out) in. It’s much less ergonomic.

(If anyone has any better ideas how to solve this problem btw I’m all ears - I’ve never heard anyone even mention this issue in Rust.)

Ha they literally said about 5 times in this page that people often say “it’s just a skill issue”… and here you are.

I love Rust but the author’s points are 100% valid.

What would you use instead?