• 0 Posts
  • 44 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle








  • It’s what C is for, too.

    The point is that there may be cases already where the type system that rust provides its guarantees off the back of is insufficiently expressive. (I say “may be” because there are ingenious qays to use what it does provide, although nonobvious and not necessarily without cost.) If you’re using unsafe then it’s just an uglier C. I don’t think anyone considers the current state of Rust’s type system to be the be-all and end-all of expressivity.


  • That’s an interesting notion (although it underestimates the effort, I think). Honestly, having machinery to write down contract semantics in a fashion amenable to automated proofs (meaning, does it type-check?) is massively promising; and I’m a dyed-in-the-wool C hacker. I would hope that the public exposure of this bad behaviour causes a few moments of self-reflection.

    I suspect that attempting to chase a moving target of describing C apis with rust is just an avenue for burnout, unless there really is a mechanism for getting fixes back in the other direction, and professional respect flowing in both directions. That would be a massive shame, and an incredible missed opportunity.



  • There are some situations where I can see Rust’s type-ststem potentially being counterproductive. For instance, it may be valid to invert lock order in a chain of operations under some circumstances, and rust might prevent you from expressing that. I grew up with C (from the pre-ANSI days) and while lifetimes and ownership are things that good C devs care about, they are tacit - and the ability to play fast and loose when necessary is great.

    The linux kernel is built on a foundation of these implicit semantics. Some of it is written down, some of it isn’t. I can see why asking “but what does this mean?” can lead to frustrating conversations and overly-qualified answers, but not everyone in that video was hostile to the prospect.


  • The thing here is that (even with things like the vfs interface), linux doesn’t have internal SPIs.

    The friction here is that the rust devs want to write down the semantics in a formal fashion, and the C devs are used to a world where the semantics are implicit in the C code.

    I thought the engagement in the video was the kind of useful feedback that was needed and asked for: “I’m not sure the semantics of this specific interface are precisely that,” which might have been out of place, but getting detail-focused feedback to an example is what you are going to have to expect from people who fit the role of VFS experts.

    Ted was being an unconscionably rude fucker, but - diatribe aside - his process question is a reasonable one, although his solution “well you’re SOL” was poor, undiplomatic, and unhelpful.







  • That’s a cracking article.

    My own use of jvm errors tends to follow the same kinds of patterns: I think the major fault with that model is having RuntimeException as a subclass of Exception, because it’s really intended for abandonment-style errors. (The problem is that lots of people use it instead as an exception system in order to cut down on boilerplate.)

    I find it eye-opening that the author prefers callsite annotation with try (although I’m not going to argue with their experience at the time). I can see this being either “no big deal” or even “a good thing” to Rust users in particular - mutability and borrowing annotations at both callsite and definition aren’t required to make the language work afaict (your ide will instantly carp if you miss 'em out) but the increased programmer visibility is typically seen as a good thing. (Perhaps this is down to people largely reviewing PRs in a browser, I dunno.) Certainly there’s tons of good food for thought there.