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.
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
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!
I’d switch course to RISC-V
And give up their only advantage? That would be insane. RISC-V isn’t quite mature enough to replace x86 anyway.
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:
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.)
Why? I agree with him. CoCs are either a short redundant statement of implicit decent behaviour (do you really need to write down that people should be respectful?) or long lists of ambiguous rules that are used to pretend mod decisions are less arbitrary than they really are. Pointless in both cases.
If he had really done all these terrible things then would they really have not suspended him just because they didn’t have a CoC?
I reckon you could put useful things in a CoC, like stuff about enforcement procedures, and in fact PSF does have that… but then they go and:
the Python community Code of Conduct team may take any action they deem appropriate
And the list of inappropriate behaviour is so extensive (“Excessive swearing”?) that they basically have unchecked power anyway.
I wouldn’t be surprised if having an explicit CoC enforcement team is also likely to attract just the kind of people you don’t really want.
Is that even desirable? There are other runtimes for specific things, e.g. for embedded, WASM, Fuchsia, etc. Doesn’t seem like there’s a one-size-fits-all runtime.
I guess the proper answer is some kind of minimum standard async interface, but presumably there’s a reason they haven’t done that.
I dunno really, I’ve avoided async Rust as much as possible due to the number of footguns it has.
Ah yeah that works. Very silly. Phones can zoom!
Looks nice. Well as far as I can tell anyway. Maybe next time you’re showing off a GUI don’t make the screenshots 320x240?
Anyone know what toolkit they are using? As far as I know none of the Rust GUI toolkits are close to mature.
Edit: it’s iced.
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?
I’d like to know which specific projects they funded. It’s there a list anywhere?