Then you’re blogging for the wrong reasons. I would continue writing blog posts even if nobody read them, because to me, the value of blogging is to write things down, to concretize thoughts and let them take form, to develop my worldview, to research, to keep a record of when I thought what and to help me remember prior events and trains of thought. If other people enjoy the blog posts, that’s all the better, but that does not determine the value of the activity by any means.
I daily drove WezTerm for a bit, and now use Ghostty. I think they’re both very similar in that they’re terminal emulators that both aim to be fast while having a lot of features, and either is very good to use if you don’t care about the details too much. The main differences IME are:
WezTerm doesn’t aim to be “truly” native and integrate with the host OS as much. My favourite example of this is that Ghostty uses macOS’s native tabs, while WezTerm draws its own tab bar.
WezTerm is configured with lua, so you can go wild and have a truly dynamic configuration. Ghostty’s config file is just key/value and doesn’t have as many knobs to turn. The flipside is that Ghostty is planning on having a GUI configurator, something I don’t think WezTerm can easily do.
That was basically what I was coming here to post. I’m a current WezTerm user, and the main advantage I see of Ghostty over it is native (GTK, for me) tabs, splits, &c, rather than the cross-platform non-native tabs and TUI menus that WezTerm has.
I’ve used both a lot. Ghostty is my daily driver now. WezTerm would be my go to if not for Ghostty, then it would be a tossup between Terminal.app and Kitty.
WezTerm has a feel like emacs or nvim-as-blogged-about-on-internet – you are kind of expected to do a lot of coding as configuration to turn it into a tool carefully crafted around the nuances of what you want. If you do that, it is great.
Ghostty is more opinionated and gives you fewer knobs, but the knobs are well chosen. Analogizes to OS X whereas WezTerm is a crunchy Linux (Arch or such).
In my personal journey, well, I declared .emacs bankruptcy a few years ago and wiped my accumulated configs from over two decades and moved to using defaults everywhere as much as I can bring myself to, as I don’t have the cycles to spend hand customizing all my tools and keeping everything up to date and so on :-/ YMMV
In terms of font weight, Wezterm renders thinner text than iTerm or Terminal.app does, enough to keep bothering me. I tried to tweak the configuration, but nothing helped enough.
To be fair, I faced the same problem with Kitty and Alacritty too.
Interesting, I just tried Cascadia Code and it looks like the rendering is the same in iterm2 and wezrerm, maybe we have different font versions or something.
Sure, here is wezterm config: https://pastebin.com/KChBQ2yW
I tested on Sonoma on MacBook Pro M2, wezterm version is ‘wezterm 20240922-151228-2b76c63b’ and the latest version of Cascadia Code (2404.23).
I think there are some global Fontconfig settings you can apply that will get you exactly the rendering you want. Unfortunately, I’m not at any of my Linux machines right now to share it here.
It’s such a small issue but makes applications unusable for me, there’s just something wrong with Linux-style rendering. It’s especially noticeable with “anything and everything” near the top of my first screenshot, the “y” is clearly rendered incorrectly.
I see. I wasn’t aware of that. So if ghostty uses CoreText instead of harfbuzz on macOS, only then its font rendering will be comparable to that of iTerm.
I had the same annoyance with WezTerm and at least IME Ghostty looks functionally identical to iTerm. I did manage to get WezTerm to behave better by using the WebGpu frontend with a medium font weight, so you can try that if you haven’t already.
It’s really good! Ironically, I’d call Wezterm vs Ghostty to be emacs vs neovim despite wezterm being the one with Lua. Wezterm is far more flexible, one of if not the only terminal who’s config is a programming language. The sky is the limit with Wezterm, letting you even customize the UI.
Ghostty on the other hand is much more streamlined. It has less potential for ricing, but feels much lighter while still keeping the important stuff. Imagine alacritty, but with a 10% speed nerf, but with 90% of the features of wezterm, and all the ones anyone could ever want.
Recently got invited to the beta, making the switch from Wezterm. I mostly use CLIs and Helix / Vim though, so I don’t know if I’m as qualified to answer as, say, a power user would be.
it weighs about 200MB to deliver this with pyinstaller and at this point I’d rather use Qt (and I wish I understood this earlier without wasting time on “lighter” options which really aren’t and have various issues)
That’s surprising (although I haven’t looked at tk for decades so perhaps it shouldn’t be). Is any significant proportion of that 200M specific to the python bindings/bundle?
i have no idea. i just ran pyinstaller on a file with a single use of tkinter and observed the 200MB output (very slow to unzip in part due to lots of small files looking like they are language specific data?..)
I am sure you could make it smaller by getting clever, but when the pitch is “the simplest way to make a GUI” getting clever detracts from the pitch and makes you look at all the other things in the package except for simplicity
I have little Python experience, but I suspect you could get a smaller package than that. Last time I tested Python, I was able to get a self-contained “hello world” down to ~7 MB (on Windows, if I recall correctly), and the Tcl/Tk runtime is pretty small, so it shouldn’t add too much on top.
The last time I looked at cross-platform GUI toolkits with Common Lisp bindings, everything was bad, but Tk was significantly less bad than any of the other options.
Yeah, I was annoyed that the tag proposal for weekly posts failed, seemingly based on ad hominem arguments about the proposer rather than on the merits of the tag itself.
Good note for future language developers: If you’re on the fence about implementation language for compilers, not that picking a language like C, C++, Rust or Zig will allow you to distribute your compiler as a WASM module that you can run in the browser.
This way you can host an interactive language playground at $0 cost.
Plus TIC-80 can run games written in lua, ruby, js, moonscript, fennel, scheme, squirrel, wren, janet or python in the browser: https://tic80.com/learn
Running all this stuff server-side probably made sense when Exercism was started, but if you were building something like that today it would not be my first choice.
I once helped maintain a commercially successful code base that contained a lot of unused code. We all spent too much time trying to understand how it worked only to realise we were wasting our time.
I managed to delete lots of it with a few unsophisticated uses of grep and gave a quick lightning talk about doing so in my limited spare time.
Nice lightning talk. I felt disproportionally pleased by you mentioning that you included the code snippets used to find stuff in the resulting commit message. As a git log enjoyer myself it is so helpful for future work.
I watched the video linked in the email and there’s definitely a degree of completely unwarranted hostility that would’ve prompted me to make a similar decision. I can imagine this wasn’t remotely close to the first time someone from the RustForLinux project has had to field aggressive questions arising from made up ideas about what bringing Rust into the kernel entails.
I wrote large chunks of RFD 26, the document describing our thought process and our choice at Oxide to go with illumos rather than, say, Linux, for our host operating system. I recall wringing my hands for months on the subject of how likely it would be that we could work towards use of Rust in the core upstream repository of the OS, for both kernel and user mode components. Basically everybody is familiar with the stereotypes about what it’s like to work in the Linux kernel community and participate in their project spaces, and with widely shouted (if not shared!) opinions about whether it’s good to have debugging tools and safer languages. In the end I tried to give credit or at least open mindedness to the idea that perhaps the Linux folks were coming around in 2020 and 2021 and that they would have seen the light by now.
In hindsight it increasingly seems to have been a waste of good hand wringing.
Not just hostility but an incredible degree of ignorance. Saying something like “we’ve learned from Java that methods are bad” (barely paraphrasing) is such a hilarious misunderstanding of so many concepts in programming.
I don’t usually get angry with people on the internet. But this level of hostility and assumption of bad intent is next level. (Also, wow, looks like my corner of the internet is more friendly than I thought).
Yeah that part shocked me as well, at the very least someone should have offered to continue the discussion offline/sidebar to allow others a chance ask questions before time. Anytime emotions start to become visible it’s passed time to step in. The speakers held their composure quite well, and I can’t imagine what kind of stress that adds on top of an already stressful event for most people (public speaking about controversial topics).
There was absolutely zero reason for the hostility of that audience member and the conference organisers should have stepped in.
I would consider this to be tyrannical organizational behavior. If this actually happened I would absolutely have supported counter-organizers stepping in in order to allow Ted Ts’o to continue talking, and if that failed organizing and promoting a completely different conference run by different people in order to allow Ted Tso’ to continue making this point.
The result of such approach is that arguments are won by those who shout the loudest and have the most power, not on the merits of their arguments.
We have a prime example how an organisation loses contributors by defending asshole behavior. Assholes tolerate assholes, but others don’t.
I’m an experienced Rust developer with expertise in C<>Rust interoperability, and in position where I could have been working on it professionally. There’s no way I’m going to contribute to Linux when it’s run this way.
I don’t contribute to any OS at the moment, but I’m considering seeing how I can help out Redox purely out of protest to this kind of circumstance. I don’t think Linux should have it’s place in the market anymore.
I agree the other replies, but I think this hasn’t been said clearly enough: the issue is not what Ted is saying, but how. The question is valid, though it has been rehashed a lot, but the tone and aggressiveness is not a valid way to ask a question in any context. That’s toxic behavior, plain and simple, so yes it falls within an organizer’s duty to rein in.
I meant in general it’s a valid question, I agree it sucks to bring it up then again, and shows Ted was more in it to rant than ask a good question.
The “though it has been rehashed a lot” was meant to hint at that, but it wasn’t really the point of my comment.
Have you ever been to any sort of professional conference? Talks are organised into thematic sessions, sessions have chairs, chairs keep the Q&A on track and stop things devolving like they did here, or at least encourage people not to shout over each other, like Ts’o was doing. It’s not tyranical in the least and it’s not CeNSoRsHIp!!1 either.
Accusations of abuse are often a form of abuse, precisely because they offer an excuse for an organization to shut down something they claim is flagrant nonsense. I wouldn’t want to work with anyone who thinks that Ted Ts’o should’ve been prevented by some outside power from communicating the way he did here.
What in the actual… what kind of conferences do people here go to!? Like, for me, it’s been years, and the ones I’ve attended were primarily academic conferences, but the religion comment + shouting would’ve been more than enough to make the session chair step in. Abuse or not, that kind of thing just derails the whole presentation.
To be more clear, I don’t question whether a conference organizer could kick out a high Linux maintainer if the organizer so chose but rather whether the organizers would find it worthwhile to begin a conflict with someone who presumably has influence in the Linux dev community with which to make continued participation in that community unpleasant for the organizers (assuming the organizers are, and want to continue to be, participants in that community).
I don’t like to wear it as a badge of honor, but “I stood next to a lieutenant while Linus yelled at them during kernel summit” is definitely the closest I’ve ever been to the kernel development process, and it was standard practice back then whenever something new was coming to Linux. At that time, it was Kernel Mode-Setting (KMS) for GPUs.
It’s interesting that he mentions if this breaks the function of a bunch of critical file systems that users depend on, it’s not his problem.
I’m pretty sure that would be considered breaking userspace?
What’s the first rule of Linux kernel development?
And then his suggestion “Lets just see what happens if we don’t give a crap about the semantic interfaces in a year.”
Like he doesn’t know that it’s just going to be a total disaster and blow the fuck up; and claim that is evidence of the unworkability of the solution, rather than evidence of the unwillingness to even make minor changes for compatibility sake.
Also the comparison to Java… They are certainly suffering a lot with people just fundamentally misunderstanding what Rust is.
The semantic definitions I would imagine would be useful even to C programmers using C interfaces in the Linux Kernel.
This is a truly unfortunate development. I really hope the Rust ecosystem in the Linux Kernel continues to grow.
As a long time Linux kernel module developer, and current Rust developer, I’ve been following this project closely.
It’s interesting that he mentions if this breaks the function of a bunch of critical file systems that users depend on, it’s not his problem.
I’m pretty sure that would be considered breaking userspace?
It’s not breaking user space, it’s breaking kernel space. He didn’t say that he would break file systems that end-users depend on, but rather break APIs which in-kernel users depend on.
This would mean breaking file systems among other things, but those breakages would be fixed before the kernel with that change is released; because Linux does not break userspace. The question is who’s responsible for fixing that, the person who made the breaking change in the API or the users of the API.
The presenters were pretty clear that they do not expect maintainers to learn rust and that they will maintain the rust API. So that is not the question.
The presentation was about describing the state of their patch and clarifying how the C API actually is meant to be used. My impression was that the maintainers do not really know either:-)
The Asahi graphics driver dev said pretty much the same thing about the DRM layer they need to interface with… the only crashes she sees are in that layer – due to unclear and undocumented lifetime issues.
IMHO it would be nice to have rust wrappers for those layers: Lifetimes are clearly documented there.
Oh I agree completely, tho Ted did problematise the “we can’t fix your Rust code when we break APIs” thing even though it was in bad faith. However I was mainly trying to delineate between “driver developer breaks their users, namely the end user, user has to adapt” and “core infrastructure breaks their users, namely drivers, driver developers have to adapt”. The former is breaking userspace, the latter is not,
Good Lord yes, what a troubled audience member. I felt like we were about three seconds away from him shouting about a ‘goddamn WOKE AGENDA’. It must be exhausting to deal with such deep confusion combined with fearful hostility.
he worked in MIT’s Information Systems (IS) department until 1999. During this time he was project leader of the Kerberos team.
That’s an interesting piece of history. Kerberos remains one of the worst technologies I am forced to use on regular basis especially on non-Windows hosts.
I am not sure where you’re getting the “woke agenda” thing … that seems to be inflaming an already inflamed situation without reason. It’s a non-sequitir
I watched the video, and I can definitely sympathize with the author, and why an interaction like that it would prompt him to leave the project.
At the same time, I think the technical disagreement is fairly clear, and the social / project management disagreement is fairly clear:
The Rust for Linux project wants to encode semantics of file system interfaces statically, in the Rust type system
At least this particular maintainer wants to make it very clear that they are going to change the semantics of the C interfaces over time (decades), and they are not willing to fix the Rust code when he does so. And he does not think it’s realistic for every file system contributor to learn Rust.
He says it’s a “pain allocation” problem
And he actually offers a path forward – keep doing what you’re doing, but know that we’re going to break you, and it’s up to YOU to fix that, not US.
He also says we will find out OVER TIME if this idea is good or not. He is not REJECTING the idea, but merely saying he refuses to do any work (and maybe even learning) to accommodate an idea that he views as experimental (or maybe even unpromising).
Now I have no idea if this is the right thing, because I am not involved in the kernel, and I also don’t write Rust.
But to me if the maintainer of a piece of code is saying this, it is actually crystal clear what the disagreement is.
He wants to put the burden on you to do the work, because he doesn’t see the benefit right now.
The Rust for Linux is making what seems like a reasonable request for more information on the semantics, so that they can encode it statically in the type system.
I am not sure, but I suspect the answer is “you have to figure that out yourself because there’s 30 years of history there” … or “that is a misguided way of looking at the problem – the solution does not match reality” [1]
I have been involved in such migrations professionally, and this is a very typical disagreement between the “old team” and a “new team”.
A new team assumes they are going rewrite everything and make the world better.
The old team has been down in the trenches for years. They have intimate knowledge of the code and the painful debugging necessary to get the system into its current state (a very successful state in this case, as Linux file systems store approximately ALL the data in the cloud, when it comes down to it)
The old team feels disrepected by the oversimplifications in the new way of thinking. (The perceived disrespect is probably why you’re getting this aggressive tone.)
A new team is genuinely optimistic and wants to improve things
The results are usually a mix, which is unsurprising. It’s never what the old team thinks it was, or a new team thinks it will be. It is a very typical conflict.
(And note it’s also possible that there are multiple new teams, and that one or more new teams is abandoned. But that doesn’t mean it’s not worth trying.)
It has nothing to do with any “woke agenda”. Do you agree? If so, I suggest retracting this comment, because it’s unhelpful and inaccurate
To me, the issue with what he said has nothing to do with the technical content and everything to do with the hostility. It sounded like he was seething with hatred toward the language and the Linux Rust project. Hell, he even described the speaker as pushing a religion!
It was not a comment from someone trying to productively discuss technical challenges.
To me, the issue with what he said has nothing to do with the technical content and everything to do with the hostility. It sounded like he was seething with hatred toward the language and the Linux Rust project. Hell, he even described the speaker as pushing a religion!
The discussion was about power, really, disguised as technical one. It’s about establishing who is subservient to whom: the Rust interfaces to C ones, or vice versa.
Yes, in the context of the Linux project. The people who have power are the ones who have made things work for users, and Linux has a track record of making things work.
Are there Rust devs interested in contributing to GNU Hurd, and converting it to Rust? (honest question)
If Rust devs make the kernel better, and I hope they do, then they will naturally have more power. But so far it looks like it’s still the early days.
Rust developers can fork Linux and do whatever they want with it – that is the beauty of open source. There can be parallel development among people who disagree.
Users can vote with their feet
I actually suspect that is the best solution here – as I would personally like a memory safe kernel, but I’m not sure if Rust is on the path to it. It would let both projects move faster.
Ted Tso is a long time maintainer and he’s basically saying he refuses to merge stuff which is going to make his job harder later.
That’s not what I heard. Ted said that he isn’t interested in learning anything about Rust, even if it makes his job easier later. It’s about anti-intellectualism and machismo, not about maintenance burdens.
Ted clearly isn’t listening to what the presenter is saying. Ted says “I don’t want to fix Rust code when it breaks because we change the C API” and the presenter says “that’s fine, I’ll fix the Rust code, but please tell me what the current semantics of the C API are”, to which Ted says “I don’t want to learn Rust!”.
Are there Rust devs interested in contributing to GNU Hurd, and converting it to Rust? (honest question)
Not really. I’ve answered a few questions like this on the Phoronix Forums, but basically:
HURD is dead, has no usecase or userbase.
Porting Rust to it would be significantly more difficult than simply starting from scratch.
Linux is a very special case because it’s used everywhere, it’s the standard OS of the world, even MS has given up on Windows and is just letting everyone use Linux now (through WSL or Azure Linux). There are a lot of reasons to use Rust, but the primary benefits are a more secure kernel and it will bring in new developers, as there are a lot less new C developers than there used to be.
I’ve considered the implications of making a separate fork of Linux just for Rust, but I don’t think it’s feasible. I can’t see a bunch of people just going over to some random fork that has no funding, and the split would be detrimental for both projects, but especially the fork as they’ll slowly lose the ability to merge patches as they fundamentally change how Linux is architected.
I actually suspect that is the best solution here – as I would personally like a memory safe kernel
It’s a side-note but I wish people would stop using “memory safe” in reference to programs to mean “written in a memory-safe language” and not “free of memory errors”, which is what it is (or at least was) actually supposed to mean (of course the first implies the second, but the reverse is not true). The use of unsafe as an actual keyword in Rust hasn’t helped the situation; “unsafe Rust” can mean so many things depending on the context (an unsafe language subset superset, or a piece of code that is only valid in that subset, or a piece of code written in that subset that also has a memory safety issue, or code within an unsafe block regardless of whether it uses unsafe language constructs) and it causes so much confusion in discussions about memory safety.
I think what you are saying is that you like the idea of a kernel written in a memory-safe language, not just that you want a kernel free of memory safety errors, which should really be a given.
I think this might be where the ‘religion’ word came from. I don’t see other languages aggressively pushing rewrites for everything. Video said “Rust has ADTs” which weren’t invented in Rust, nor exclusive to Rust, nor popularized by Rust. Same applies to memory safety, and other arguments used in the ‘why Rust’—but also in the Venn diagram of the languages that are suitable for systems programming is Rust not alone or particularly remarkable.
Other languages with Rust’s features aren’t suitable for integration into the Linux codebase.
OCaml, Haskell, etc compile to native code, but have large runtimes and need a lot of tooling for even basic C interop. It’s difficult for a human to predict the machine code emitted by their compilers.
Go is memory-safe but is missing a lot of features that are considered useful for writing highly-reliable code, and its development roadmap isn’t easily changed by outside contributors. Support for compilation to non-hosted targets is via a third-party project (TinyGo).
Zig, Odin, Carbon, etc aren’t mature enough yet.
Ada, D, Vala, and various other languages over the years have had their chance and have largely failed to gain mindshare outside of a few niche areas.
Rust is the first successful attempt to write a language that solves the same problems as C and also has the sort of nice features that application programmers have had for twenty years. Of course people would be excited about it.
Go is memory-safe but is missing a lot of features that are considered useful for writing highly-reliable code, and its development roadmap isn’t easily changed by outside contributors. Support for compilation to non-hosted targets is via a third-party project (TinyGo).
Go is not memory safe in the presence of multiple threads.
Zig, Odin, Carbon, etc aren’t mature enough yet.
None of these are memory safe, nor will they ever be.
Go is not memory safe in the presence of multiple threads.
Yep. Started a Go job recently after five years of rust. My heart sank the first time I saw “make sure not to call this without holding a mutex!” in some function’s comments.
Thats not traditionally what memory safety means. Traditionally memory safety means something more like free from memory errors that would lead to control of the instruction pointer which removes a massive class of never ending security vulns. Go achieves this.
Crashing from threads racing to overwrite a variable could definitely be considered a safety issue in some domains of course.But, If you redefine memory safety this way, doesn’t that exclude all languages but rust?
In Go, stores to slice-type variables are not atomic. You can create three goroutines that all have access to a struct that has a slice as one of its fields:
Goroutine one stores a small slice to the field, in a loop.
Goroutine two stores a large slice to the field, in a loop.
Goroutine three reads the field until it gets the base of the small slice and the length of the last one. From there, you can build type confusion, use-after-free, and all other categories of memory safety bugs. You can overwrite a function pointer (or interface type) with a value that you control and cause control flow to transition to n arbitrary point.
Crashing from threads racing to overwrite a variable could definitely be considered a safety issue in some domains of course.But, If you redefine memory safety this way, doesn’t that exclude all languages but rust?
No, this is something that doesn’t happen in any memory-safe language. Nothing in the JVM or CLR has this problem, neither do Haskell, ML, Lisp, JavaScript, Erlang, and so on.
Memory safe means that every memory access must be via a valid pointer that is derived from a pointer to a valid object (global, heap, or stack allocation), is within the bounds of that object, and is within the lifetime of that object. Any access that does not follow these rules must either trap at run time or be disallowed at compile time. It is a subset of type safety, which additionally imposes rules on the operations within an object.
No, it would be an ABI change and Go doesn’t guarantee a stable ABI. It would be a perf hit though. Almost no CPUs can do atomic three-word stores, so you’d need to either hold a lock while updating slices or do what .NET did and make slices heap-allocated things. This places more strain on the GC.
But, I still argue that Go is considered a memory-safe language by normal definitions. I have never seen a single real-world Go bug of this nature that could be used as a security vuln which brings it out of the class of languages like C/C++ for which large code bases seem to have a never ending problem of bugs and security vulns from being memory-unsafe.
Crashing from threads racing to overwrite a variable could definitely be considered a safety issue in some domains of course.But, If you redefine memory safety this way, doesn’t that exclude all languages but rust?
I think at the very least it would also exclude BEAM languages, where nothing is shared?
OCaml, Haskell, etc compile to native code, but have large runtimes and need a lot of tooling for even basic C interop. It’s difficult for a human to predict the machine code emitted by their compilers.
OCaml has a moderate runtime. I wouldn’t call it ‘large’. The MirageOS unikernel is written in OCaml and Mirage programs are very small and start up in a handful of milliseconds. Also I wouldn’t say it needs ‘a lot of tooling’ for basic C interop, it supports C FFI out of the box. Finally, OCaml is widely recognized as generating quite predictable Assembly.
I think all your points do hold for Haskell, though.
Yes, because the cheapest processor nodes are not getting any smaller, so the silicon cost savings of 32 bit over 64 bit will continue to make sense forever. Linux will only lose 32 bit support if people decide to just stop using Linux for small systems.
If the cost savings are substantial enough then I’m sure someone will step up and pay to maintain OCaml 32-bit support. It shouldn’t be that difficult since the support already exists in the 4.14.x series, the last series before 5.x (multicore) 🤷♂️
“First successful” implies other attempts didn’t reach that goal & they have, but community uptake & such are a fickle bit that can get a “aren’t mature enough yet” aren’t despite having sound fundamentals, but even some are quite old/mature/stable, just not a lot of users even if they, say, have a more robust type system than Rust’s affine types which has limitations (such as linear types). One other difference is unless exposing externs for C binding, Rust’s ABI isn’t stable or particularly usable/portable outside of Rust which continues to fuel the rewrite it all in Rust with Rust libs situation as opposed to the C libs that back so many projects regardless of language. If Rust was as easy to use/link from every language as C, then I would be more enthusiastic about it as a step in the right direction even with type system limitations, but as the post above me mentioned, it is not the only language that could be a solution to this problem.
Which non-Rust language do you think should be used for writing memory-safe code in the Linux kernel?
One other difference is unless exposing externs for C binding, Rust’s ABI isn’t stable or particularly usable/portable outside of Rust
I think you’re mixing up a couple issues.
The C ABI is widely used because any language with the concepts of function calls and memory access can use it. It’s common ground for any language that compiles to native code, but that also means it’s not idiomatic in any of the languages that are using it for FFI. Even in C++, which has the smoothest possible upgrade path from C, you’ll need an extern "C" layer of plain functions wrapping your classes and templates.
Whether or not Rust has a stable ABI for its own semantics doesn’t matter for cross-language use cases. The reason to want a stable ABI is better support for pre-compiled object code archives, which is pretty niche in the use cases that Rust is focused on.
Rust’s ABI isn’t stable or particularly usable/portable outside of Rust which continues to fuel the rewrite it all in Rust with Rust libs situation
The push to rewrite existing code in a memory-safe language is because people are tired of having their programs and computers crash, or get taken over by botnets, or get all their tax documents encrypted.
It’s not about Rust. Rust is probably the least-popular memory-safe language in common use today. All the Rust code in the world is a fraction of a percent of the C#, Swift, Java, and JavaScript code out there – and that code has almost entirely displaced C/C++ for the development of applications.
The reason people object to Rust isn’t because of anything about Rust, it’s because because they want to use C forever, and they hate the idea of seeing the last remnants of the PDP-11 era get scoured away down the drain.
If Rust was as easy to use/link from every language as C, then I would be more enthusiastic about it as a step in the right direction
Rust is as easy to use/link from every language as C – easier in some ways, because you don’t have to worry about dynamic symbol compatibility in libc. The rustc output is a regular object file that can be passed into the regular build toolchain, and a shared library written in Rust can be a drop-in replacement for one in C.
Which non-Rust language do you think should be used for writing memory-safe code in the Linux kernel?
If it were gun to my head (meaning developer ecosystem/community isn’t there even if it is an old language), I would pick ATS as a ‘C generator’ for supporting linear types for tracking resources over Rust’s affine types–along with having refinement + dependent types & a proof system you could actually start asserting things in the type system beyond Rust’s type system & language features capabilities (including tail call optimization as jumps) while having all the low-level resource allocations + tracking (memory alloc, shared memory, locks, pointers, etc.). The type system asserts + zero-cost abstractions can eliminate most run time checking, and being from the ML family tree (which technically Rust came from OCaml explaining many of its features), you have a syntax, if unfamiliar to the C programmer, that is more ergonomic for doing ADTs/pattern matching & recursion. The compiler is built around abstracting over & even outputting C code to be linked via C code so it doesn’t disrupt those still wanting to use C or where C is easier.
But this would likely never happen & be even less popular of an option even if I think it is neat & crosses all the boxes.
You may be interested in the proposed crABI ABI, which has as a goal the ability to interop with other languages in a richer way than simply exposing C types.
but as the post above me mentioned, it is not the only language that could be a solution to this problem.
There are languages in development that could do the job of Rust here, none of which I think have been mentioned in this thread, but they’re all way less mature than Rust. All languages in existence that may be mature enough are simply inadequate.
I think this might be where the ‘religion’ word came from. I don’t see other languages aggressively pushing rewrites for everything.
All popular languages with a young and enthusiastic user base ask for projects to be rewritten in their language of choice.
The C++ crowd famously nagged Linus to use C++ in the kernel till he told them very explicitly he does not want to. And evenntoday youbget people arguing for C++ in the kernel in addition to or instead of rust. The kernel got by pretty well as there are not too many languages that fit its niche, applications get this a lot more.
I was going to say that the user base was the only truly exceptional bit, but being non-technical & might be just zeitgeist (we will see) I left it out :)
I want a memory-safe kernel, which definitionally means a kernel written primarily in a memory-safe language.
There do exist kernels written in memory-unsafe languages that, when compiled to a binary artifact with a specific toolchain, can be proven to contain no memory safety errors. But those kernels have extremely high development overhead due to all the extra manual verification. Consequently they do not, and likely never will, have the breadth of hardware and software support needed to supplant Windows / macOS / Linux as the foundation layer of all general-purpose computing.
“unsafe Rust” can mean so many things depending on the context (an unsafe language subset superset, or a piece of code that is only valid in that subset, or a piece of code written in that subset that also has a memory safety issue, or code within an unsafe block regardless of whether it uses unsafe language constructs)
I think you’ve got this wrong – “unsafe Rust” has a single definition[0]. When discussing code that contains memory safety errors, Rust programmers use terms such as “unsound” (or “incorrect”, “buggy”, “fucking broken bullshit”, etc depending on mood) to describe code that contains memory safety errors.
Being unsafe doesn’t mean that the code contains memory safety errors, it means that the code can’t be proven memory-safe by the compiler.
[0] To the extent that any programming language name does. It’s true that programming language names are usually used for both the language itself and code written in that language (e.g. “a new version of Java was released” and “I don’t want to read ten thousand lines of Java”), but that’s not Rust-specific.
I want a memory-safe kernel, which definitionally means a kernel written primarily in a memory-safe language.
It doesn’t though, that was the whole point I was making.
I think you’ve got this wrong – “unsafe Rust” has a single definition
It might have a single formal definition (where?), but it is “casually” used in all the ways I pointed out.
When discussing code that contains memory safety errors, Rust programmers use terms such as […]
Yes, that’s the problem. They can’t call it “unsafe”, which is what would’ve been said prior to the existence of Rust, because it has become ambiguous.
Being unsafe doesn’t mean that the code contains memory safety errors
I spoke of programs, not of smaller pieces of code, for which I don’t think there’s necessarily any prevalent definition of “unsafe”. But for programs, being unsafe definitely does or at least did mean that the program (code) contains a memory safety error. It’s only since the emergence of Rust (and its growing popularity) that this definition has become muddied.
You’re unintentionally reinforcing my point - that the use of “unsafe” as a keyword in Rust has led to confusion about what a “memory-unsafe program” actually is.
But for programs, being unsafe definitely does or at least did mean that the program (code) contains a memory safety error. It’s only since the emergence of Rust (and its growing popularity) that this definition has become muddied.
I disagree with both assertions. The term “unsafe” in programming has always described code that may contain errors, because if the code is known to contain an error then it’s simply incorrect.
I know from personal experience that the use of “unsafe” to describe programming languages without memory-safety guarantees dates to at least the mid ‘90s (when it featured prominently in arguments about Sun’s Java applets vs Microsoft’s ActiveX vs Macromedia’s Flash), and would not be surprised if more experienced devs could cite examples from the Usenet era.
Rust introduced the concept of memory safety to a generation of systems programmers who grew up after C had conclusively trounced all of its competitors, but that doesn’t mean Rust originated the idea.
I disagree with both assertions. The term “unsafe” in programming has always described code that may contain errors, because if the code is known to contain an error then it’s simply incorrect.
Here’s a 2009 paper discussing memory safety as a property of a C program: safe if it contains no memory errors, unsafe otherwise:
An important research question is thus the following:
Given a program written in an unsafe programming language like C, how
can one guarantee that any execution of this program is memory-safe?
Here it’s talking about specific executions being safe or unsafe, and here:
For instance, CCured [7] uses pointer annotations and analyzes the source of
the program, trying to prove it memory safe
It’s talking about proving the memory safety of a program (though it’s not written in a memory-safe language).
This spells it out very clearly:
This paper makes a first step towards bridging this gap, by introducing a formal definition of memory safety for programs written in a non-memory safe programming language and execution platform
So, it’s certainly not true that:
“unsafe” in programming has always described code that may contain errors
At least this one paper is an exception to that claim. I’m sure there are plenty of others, if you are willing to search.
Here’s a 2014 blog post by Michael Hicks, a professor of Computer Science at the University of Maryland:
For the purposes of this post, we are generally considering whether a program execution is memory safe or not. From this notion, we deem a program to be memory safe if it all of its possible executions are memory safe, and a language to be memory safe if all possible programs in the language are memory safe.
That’s a pretty clear definition, in line with what I’ve stated and not equivalent to your own definition. A memory-safe language can only be used to write memory-safe programs, but that doesn’t mean that all memory-safe programs are written in memory-safe languages.
I know from personal experience that the use of “unsafe” to describe programming languages without memory-safety guarantees dates to at least the mid ‘90s
The use of “safe” or “unsafe” to describe programming languages isn’t at question.
Everyone agrees that for languages, the natural definition of being “memory safe” is that no program has memory errors. (In practice we use a more complex, less natural definition, closer to “a language that pushes you towards writing programs mostly with this property and with clear social contracts about the exceptions”) Same with programs, a program is “memory safe” if no run of the program has a memory error. This is consistent with Mike Hicks’ terminology, which is fairly clear.
Obviously “not safe” is the negation of “safe”, so a language is “not memory-safe” if some of its programs have memory errors, and a program is “not memory-safe” if some of its runs/executions have memory errors.
We probably want “unsafe” to mean the same thing as “not safe” because doing something different would be confusing. (But not unheard of.) So we want to define an “unsafe” program as a program that has some runs that have memory errors, which is consistent with what davmac claims but appears contradictory to what jmillikin’s claim.
But note that jmillikin is talking about what “unsafe” means in Rust, and unsafe is first a qualifier of program fragments, not whole programs. A natural definition of “memory safe” for a program fragment is something like: for any usage of this fragment in a program that “has no other source of unsafety”, the program is memory safe. (This is a bit tricky and not obvious to define formally, but programming language researchers are good at this.) Say a function, for example (but it also works for language constructs, etc.), is memory-safe in this sense if there isn’t a way to get a memory error by calling it.
I believe that this notion of safety of a program fragment is consistent with the established use of “memory safe” in industry and academia. It is compatible with the claims of jmillikin, and also with the formal statements of Mike Hicks cited by davmac. In OCaml, we have a function Array.unsafe_get : 'a array -> int -> 'a, which is not memory-safe as it does not perform bound-checking on the array access; this is “unsafe” precisely in this sense – and has been around well before Rust was introduced.
Now one thing that is a bit confusing is that there are several reasonable but incompatible definitions of what it means for a program to be “unsafe”. The academic citations from davmac write that a program is unsafe if some of its executions contain memory errors. Another usage that exists in the wild (I believe well before Rust, but maybe Rust popularized it) is to say that a program is “unsafe” if it contains “unsafe” fragments. I believe that the first definition makes more sense if we think of the program extensionally, as an abstract object that runs, and that the second definition makes sense if we think of the program intentionally, mostly as source code (that can be executed).
I appreciate that you’re trying to engage in this discussion in good faith. I do need to point out though:
But note that jmillikin is talking about what “unsafe” means in Rust
That is exactly the issue I was raising right off the bat - the terminology introduced by Rust has muddied the more general, previously-existing terminology about memory-safe programs. jmilkin rejected that assertion, though; so, if their ongoing argument was actually about a different “unsafe” that is specific to Rust, then that would accord with my point, that the terminology has become confused.
And also:
The academic citations from davmac write that a program is unsafe if some of its executions contain memory errors.
Indeed, but the only reason that I only cited academic sources because those were the ones that I could find that could easily be dated to a pre-Rust-prevalance period. There are plenty of non-academic uses of “memory safe” entailing the exact same definition. I won’t point them out because I’m not a personal assistant and people should be able to do their own Google searches. After pointing out the academic cases, jmilkin shifted the goalposts by dismissing them as being only relevant to an “academic bubble”. Their response was so arrogant and condescending that I posted a snarky reply (that I partially regret, but which frankly was deserved) designed to close off the conversation. The fact is that uses of those definitions can easily be found, today, outside of any “academic bubble”, but it’s not my job to provide counterexamples to every bad argument that is made against something I’ve said. People can believe what they want, even if it’s wrong, or do a tiny bit of groundwork and find out for themselves.
Now one thing that is a bit confusing is that there are several reasonable but incompatible definitions of what it means for a program to be “unsafe” […] Another usage that exists in the wild (I believe well before Rust, but maybe Rust popularized it) is to say that a program is “unsafe” if it contains “unsafe” fragments.
The way I understood it was clear enough, and the quotes I did provide illustrate some nice concise definitions which matched that understanding. While indeed these don’t prove that other definitions weren’t used, they do clearly disprove jmilkin’s sweeping statement:
“unsafe” in programming has always described code that may contain errors
I think, if there’s going to be any argument about what definitions were around and when, they need to be based on more than just bold assertions that are clearly contradicted by available evidence. Your observation about Array.unsafe_get is at least a starting point in that regard (although it doesn’t prove anything by itself, of course).
It’s possible that some areas of academia use non-standard terminology, in the same way that astrophysics describes all elements heavier than helium as “metallic”. I don’t think that matters to anyone outside that specific academic bubble.
It’s possible that some areas of academia use non-standard terminology
It’s also possible that terminology originates in some area of academia, and is used somewhat consistently outside of that area until some popular phenomenon - say, the emergence of a new programming language - leads to it entering the lexicon of a broader population, and beginning to be misused by a segment of that population who don’t realise that they are overloading the term by using it a slightly different context, for example.
I don’t know if that’s how it actually happened, but it’s certainly possible, and since we’re just apparently throwing possibilities out there now, may as well throw that one out too right?
That you don’t think it matters to anyone isn’t of any concern to me or anyone else that it does matter to, sorry.
I feel like your definition of unsafe in Rust is a bit nebulous. I have a better one: Rust guarantees that it will have no undefined behavior (there’s one or two places it doesn’t, but those are known bugs.) Rust also has a few built-in APIs to perform actions which can lead to undefined behavior (operations outside of the purview of the compiler), these APIs are manually marked as unsafe so that they can only be used in other unsafe (allows UB) scopes.
This is what people mean when they say Rust is safer than C because C is basically Rust in an entire unsafe context, because C itself allows UB, whereas Rust doesn’t. It’s a matter of UB.
The question being discussed in this thread isn’t the exact types of behavior that are forbidden outside of unsafe { ... } blocks, it’s the definition of “unsafe” itself.
davmac wants “unsafe” to refer to a property of the program as a whole. In this definition if a program can reach a state that permits it to execute instructions that violate the safety guarantees of the language, then the program is “unsafe”. In this model it doesn’t make sense to describe a function (or module, or library) as safe or unsafe – safety can only be verified given a full execution graph. And if someone says a program is unsafe, they’re not saying it might contain an error, they’re claiming that it does contain an error.
Furthermore, he wants to define “memory-safe language” to mean a language that can only express memory-safe programs. In other words, if it’s possible to write a program that can violate memory-safety guarantees, then he would say that the language that program is written in is not memory-safe.
Thus he claims that Rust is not a memory-safe language – and presumably none of Java, C#, Haskell, Python, Ada, or JavaScript are either. I’m honestly not sure whether there are any languages he would consider memory-safe. It strikes me as the conversational equivalent of setting off a fart bomb in a theater.
davmac wants “unsafe” to refer to a property of the program as a whole. In this definition if a program can reach a state that permits it to execute instructions that violate the safety guarantees of the language, then the program is “unsafe”
I’m sorry, but you’re confused. It’s not that I want “unsafe” to mean anything in particular, it’s that I believe it does mean something in particular. But not what you are claiming here; in the previously established meaning, “unsafe” has meaning outside of languages that don’t provide any safety guarantees.
Thus he claims that Rust is not a memory-safe language
What? I didn’t claim that. (Unless perhaps… if you mean “Rust including unsafe Rust” then … well, if you want to argue that “Rust including unsafe Rust is a memory safe language”, go at it, I won’t try to stop you).
It strikes me as the conversational equivalent of setting off a fart bomb in a theater.
I don’t see how, though that seems like almost an appropriate response to the ridiculous claims you’re making here now.
Thus he claims that Rust is not a memory-safe language
What? I didn’t claim that.
Using the definition “memory-safe language” as a language for which all valid programs obey the language’s memory safety guarantees, then a language cannot be memory safe if it (1) has some concept of memory mutability or visibility, (2) supports Linux as an execution platform, and (3) is able to perform file I/O on arbitrary paths.
Rust distinguishes mutable and immutable memory regions, supports Linux as a target platform, and is able to perform file I/O. Therefore, it’s possible to define a program entirely in safe Rust that modifies its own memory via /proc/self/mem, and therefore the program is unsafe, and (per the claimed definition) safe Rust is unsafe.
I don’t see the value in such a definition, since all of the languages of interest to industry would be excluded from the “safe” category, so I follow the standard definition of memory-safety as applied to both source code (not programs) and programming languages.
Using the definition “memory-safe language” as a language for which all valid programs obey the language’s memory safety guarantees
That wasn’t the definition, read it again. It’s not about violating or not violating the “language’s memory safety guarantees” (if it was, it would be meaningless for languages which don’t provide such guarantees).
And for that matter, I wish that people would stop calling any old language which bolts memory-safe constructs onto conventional pointer arithmetic but leaves the latter exposed to unskilled programmers “memory safe”.
Interestingly, to me it sounded like a disagreement between experience and inexperience. I have conflated experience with hostility and/or authority many times in the past.
And he actually offers a path forward – keep doing what you’re doing, but know that we’re going to break you, and it’s up to YOU to fix that, not US.
?? The Rust guy kept saying over and over that no one is going to force any C dev to fix Rust interfaces. They already offered that path forward! The audience member was strawmanning hard.
The Rust for Linux is making what seems like a reasonable request for more information on the semantics, so that they can encode it statically in the type system.
I am not sure, but I suspect the answer is “you have to figure that out yourself because there’s 30 years of history there” … or “that is a misguided way of looking at the problem – the solution does not match reality” [1]
What you’re saying here is equivalent to saying that it’s impossible for new C code to use the interface correctly because no one actually knows how it’s supposed to work. Asahi Lina actually pointed out something similar about the DRM subsystem here:
The lifetime requirements were undocumented and boiled down to “design your driver like amdgpu to make it work, or else”.
My driver is not like amdgpu, it fundamentally can’t work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do “what other drivers do”.
Even when I pointed out that other C drivers also triggered the same bugs because the API is just bad and unintuitive and there are many secret hidden lifetime requirements, he wouldn’t budge.
I suspect the answer is “you have to figure that out yourself because there’s 30 years of history there” … or “that is a misguided way of looking at the problem – the solution does not match reality”
But that lays bare a horrible implication: no-one knows how to safely write file-systems against this API then. Regardless of whether it is when writing a Rust wrapper for the API or someone writing a new or maintaining an existing file-system in C.
Yeah, I was somewhat surprised to find that no one even knows how the ext4 filesystem works. The most authoritative document was basically some guy reverse engineering it with lots of “from what I can tell…” and “I think it does this…”, and after digging through the code I have to say he did a much better job understanding it than I’m capable of doing. It’s still wild to me that something as foundational as a filesystem isn’t specified such that people can write tools to operate on them without having to FFI to the Linux source code.
Yes, this is how most C and C++ APIs work. People who are horrified, I envy you because it seems like this isn’t something you have to deal with on a daily basis.
It’s also why Rust (and, to a lesser degree, modern C++) is such a breath of fresh air to so many of us who are used to dealing with giant old C and C++ code bases. Just the fact that Rust encodes lifetime information in the type system eliminates so many questions. When I write against someone else’s C APIs, my biggest question is usually “what are the lifetime requirements of this object? Should I free it? If so, when?”. That question is very rarely answered by documentation, so it’s left up to intuition, reading the implementation, and address sanitizer telling me when I’m leaning something or double-freeing something or use-after-freeing something.
There are many things about the Rust language that I’m not a huge fan of, and I personally prefer writing C++, but I don’t feel like I can ignore it.
When I write against someone else’s C APIs, my biggest question is usually “what are the lifetime requirements of this object? Should I free it? If so, when?”. That question is very rarely answered by documentation, so it’s left up to intuition, reading the implementation, and address sanitizer telling me when I’m leaning something or double-freeing something or use-after-freeing something.
Worse: many codebases don’t have a rule for that, either. I’m guilty of that, too, I think I’ve written at least one long piece of spaghetti code where, halfway through the implementation, I realised that accommodating a particular quirk of some underlying protocol or filesystem required something to be freed based on slightly different conventions than the rest of the code followed.
Sure, you document that visibly, comment your code, whatever, but wetware sidechannels just aren’t very good for that.
[1] Regarding “whether encoding file system semantics statically in the Rust type system is a good idea”
Take this with a grain of salt, since I haven’t looked at the specific problem, nor do I have any real expertise in it
But I think there is the general problem where some people think “Of course that’s a good idea, why wouldn’t you do that?”
And then there is the reality that there are inherently dynamic aspects to software interfaces.
I ran into this difference in thinking while working on a garbage collector. Some people want there to always be a static way of doing things, but in this case it’s mathematically impossible (due to Rice’s theorem, etc.).
I suspect there is a big bridge to gap between Linux kernel dev and Rust for a similar reason
It’s a dynamic vs. static way of thinking, and again the answer is going to be somewhere in between.
The fallacy of the dynamic side is perhaps a status quo fallacy.
The fallacy of the static side is that everything important can be encoded statically. The failure mode is when you only encode the trivial properties, and the cost isn’t worth the benefit. The dynamic techniques for correctness still end up bearing most of the weight, and then you have a static “bureaucracy” off to the side.
I suspect @matklad might have some thoughts/opinions on this, e.g. since after using Rust, he’s using Zig and writing more about dynamic properties of software:
My guess is that the Linux kernel is more like Tiger Beetle … are you going to try to encode the invariants of a transactional database in a type system?
Or are you doing to do it with dynamic assertions and the like? (Of course it’s not either-or, but I think there is a contrast philosophically, which is similar to the one between Rust and Zig)
To me that suggests that one of the most important properties of the system – performance, and the algorithms you use to get there – don’t benefit that much from static encodings
Of course the answer is different for each system, and that’s what makes it hard.
(“advice = limited life experience + generalization”)
And then there is the reality that there are inherently dynamic aspects to software interfaces.
This is somewhat of a non sequitur. Type systems encode dynamic aspects of programs all the time, especially so in Rust which has sum types. The example API in the talk was doing exactly this.
The simplest example is, I feel, Arc, which statically describes a set of rules for entirely dynamically managing the life cycle of an object. You don’t know which thread is going to end up freeing it, but it’s still safe because the rules lay out why that doesn’t matter.
By “inherently dynamic” I mean “expressing it statically is like solving the halting problem” – i.e. mathematically impossible
I didn’t say dynamic – I said inherently dynamic, and gave an example of what I mean
For people who don’t understand what I mean, I suggest writing a garbage collector in Rust. It will give you a good perspective on the nature of – and the limitations of – the abstraction you’re using.
I also believe there is a pretty strong analogy with the conventions used in say kernels or transactional databases
Your example doesn’t demonstrate what you claim it does. Every property captured by a static type system is already dancing with the halting problem. There is no “inherently dynamic” boundary to cross here.
The business of a (sound) type system is to find an approximation of the dynamic property we are interested in, such that it can rule out all the violations without ruling out too many interesting dynamically-valid programs. All Rice’s theorem means is that this will always strictly be an approximation, not that it can’t be good enough for general purpose use.
GC rooting is absolutely no exception to this, and the borrow checker is actually uniquely suited to capture this kind of thing- an un-rooted reference is very much like a borrow, during which the collector must wait for a safepoint when the reference is again rooted or discarded. There are several designs for encoding this property in the Rust type system: https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe-tracing-gc-designs-in-rust/
Again, while these encodings are approximations, all this really means is that you can’t go crazy passing around un-rooted references in ways that are too complicated for the type system to understand. But this is essentially never something you want to do anyway! These encodings are plenty flexible enough to capture all the typical ways that the mutator holds onto un-rooted references, which are very localized.
You can encode SOME rooting policy, but what about the most efficient (minimal) rooting policy?
Do you agree that this is a possible failure mode?
The failure mode is when you only encode the trivial properties, and the cost isn’t worth the benefit. The dynamic techniques for correctness still end up bearing most of the weight, and then you have a static “bureaucracy” off to the side.
Or is it inconceivable? Is it always better to use the static approach, and there is no tradeoff to make?
I haven’t said anything about which side of the tradeoff is better. I only specifically disagreed with your claim about the “reality” that some things were “inherently” dynamic.
But with that out of the way, I think it should also be obvious that nobody is claiming that the static approach is always better. Rust itself uses the dynamic approach for things like bounds checks and integer overflow checks!
But even then, your argument is somewhat of a non sequitur: the thing Linux is doing is neither dynamic nor static. It is just an un-checked free-for-all where the human programmer has to manually learn and follow the rules of the API, and when they fail it just corrupts the abstraction.
Right, so if I have a Rust program with an integer i, then it is an inherently dynamic property of that program whether the integer overflows.
It’s not a property you can statically encode in the type system. It’s mathematically impossible to do so (in general)
Do you agree?
Likewise, I claim that software interfaces and especially hardware interfaces have inherently dynamic properties. (I’m not sure if the keyboard firmware example is one, but it appears to be a case where the type system is creating bureaucracy that doesn’t help correctness. It is sort of beating around the bush, and not really helping with the core problem.)
You can approximate them with a static property, but it may not be the algorithm or policy you actually want.
For example, it might run too slowly, which is why I brought up the GC rooting example.
Just because there is no encoding of the file system API in a static type system doesn’t mean that not well-specified, prima facie
It could be well specified, but impossible to express in Rust’s type system. Or you can express some part of it in Rust type’s system, but not in a way that actually helps you ship 50 working file systems.
It can certainly be be a big mess too – Linux code is messy with many hands in it.
Let me additionally quote Tso
I suspect the best thing to do is you to continue maintaining your rust bindings
over time there will be continued C code refactoring right
maybe we will start using you know k3 RCU
if that breaks rust, we will find out whether or not this concept of encoding huge amounts of semantics into the type system is a good thing or a bad thing
and instead of trying to convince us what is actually correct let’s see what happens in a year or two and it will either work or it won’t and we will see
Do you believe that this question makes any sense?
Is the idea of encoding semantics in the static type system prima facie a good idea?
My feeling from this thread is that many Rust users believe that what he’s saying can’t possibly be an argument, which is what I alluded to in the comment that you replied to.
I believe there is a fundamental difference in thinking – and it is more or less accurate to call it dynamic vs. static.
On the one side, you have the dynamic “reality”, backed by shipping 50 file systems over a few decades (which implies debugging them), and on the other side you have “we think in static type signatures; the program can’t be correct and can’t be reasoned about unless it passes the type checker”.
Tso is not saying it won’t work – he is treating it as an empirical question. But I believe many Rust users do not believe it’s an empirical question.
Is it an empirical question?
Is it possible for a static type system to model a problem poorly, and get in the way of a correct program? Or are the static types reality itself?
It’s not a property you can statically encode in the type system. It’s mathematically impossible to do so (in general)
Do you agree?
Absolutely not, for the reasons I already gave. You can use ranged integer types, and reject operations where the ranges of the inputs mean there may be overflow. This is a classic example of encoding a property in the type system.
For example, it might run too slowly, which is why I brought up the GC rooting example.
The GC rooting example does not suggest anything like this. As I already said, the rooting behavior of existing GC languages is already easily local enough that it would not have to change at all to be encoded in a type system.
Do you believe that this question makes any sense?
I repeat: nobody is claiming that the static approach is always better. The reason Rust uses dynamic checking for overflow is not that it would be impossible to encode in the type system, but that they judged it to be more practical to check that particular property at runtime.
You are trying to counter an argument that you completely made up, not anything the Rust language or the Rust-for-Linux project is actually saying. And worse, you are trying to pull me into that argument, which I am entirely uninterested in.
(For context: I use and like Rust, but I have ~no opinion on whether it’s a good fit for Linux.)
Is it possible for a static type system to model a problem poorly, and get in the way of a correct program? Or are the static types reality itself?
This feels to me like a false dilemma posed in such as way as to make people either agree with you or appear to agree with an absurd proposition (that static types are “reality itself” and no use of them ever models a problem poorly). Maybe something more concrete can be more constructive….
for an example of why hardware may not match what your type system can express
Likewise, I claim that software interfaces and especially hardware interfaces have inherently dynamic properties. (I’m not sure if the keyboard firmware example is one, …
I get an impression that you use (or previously used) that keyboard firmware post to suggest that Rust is bad for interfacing with hardware, but I still don’t think that keyboard firmware post is relevant.
I think a better example of some Rust code being bad at interfacing with hardware is David Chisnall’s MMIO anecdote (see, e.g., here or here). The details weren’t clearly stated, but it sounded like what was happening in that case was that some Rust code was reading the value of a “device register” as a richly typed value, which is not okay. The solution would be to read the register value as just an integer and then map that to a more richly typed value with plain, safe Rust code like
Rust code can use structs and enums and lifetime-equipped references within itself, but, at an interface with hardware like that, Rust code must treat values it gets from the hardware as just bytes, or just integers, not structs or enums or lifetime-equipped references. The device registers’ world is a wild, untyped one whose values mustn’t be eaten raw in Rust’s typed world.
I think the many remarks you’ve made here about “dynamic vs. static” could be more understandable if more concrete examples were given. Does this MMIO example sound relevant to what you’re trying to say about “inherently dynamic properties”?
Yeah I could have omitted the last line, but it made me chuckle … I don’t believe the general point is a strawman, because I see a very strong consensus in this thread and elsewhere that if an interface is not expressible in Rust’s static type system, it can’t be a good interface, and should be changed so that it is.
I disagree with that.
Also, I ended up skimming a mailing list thread, and it is very clear to me that it is a clash between the dynamic mindset of kernel devs and static mindset of Rust devs:
For the record, I would like the future of kernels to use more static analysis, and static types. I think it would make kernel programming a lot more accessible to me personally, and to everyone, and thus widen the pool of contributors, and make kernels better.
I just think the types need to be appropriate to the problem. And what I am hearing from Tso is that this might be possible, but it’s a question that should be answered empirically.
My suspicion is basically the same as what chisnall and matklad said elsewhere in the thread:
There is a “Rust view of the world”, and Rust has a very specific aliasing model. I would even say that Rust is domain-specific language – because all languages are.
And type safety is a global property of a program.
This makes it harder to migrate an existing codebase like Linux, with its own specific model. The models clash.
I believe what they are saying is not substantially different from Tso’s suspicion – it’s just expressed with less shouting
But like I said, it’s an empirical question that will (eventually) be answered …
The MMIO issue with unsafe does seem relevant and important, though not exactly what I was thinking of
There were 2 related claims
some interfaces are inherently dynamic
some things can be expressed statically, but they might not help you with the core of the problem
As for examples:
It “feels” like RCU is “inherently dynamic”, with respect to the Rust type system, though I have no expertise in this area:
Can the Rust type system say anything about this? Can it statically eliminate errors in obeying these protocols?
I could certainly be underestimating what it can express
My suspicion is if that it were shown that Rust could statically check all usages of RCU protocols, kernels developers would be JUMPING to learn and use Rust
But I think Rust doesn’t help there. The Rust way would be to introduce some other mechanism that’s probably not as finely tuned.
As an aside, the top comment seems to be from a pretty experienced Rust programmer, who expresses an opinion that Rust penalizes RUNTIME behavior in favor of its “model” (async/await in this case):
The fixation on async-await, despite it slowing down almost every real-world workload it is applied to, and despite it adding additional bug classes and compiler errors that simply don’t exist unless you start using it, has been particularly detrimental to the ecosystem.
That is basically what I mean by models vs dynamic reality.
You want make a fast concurrent system - the reality is what it does, what syscalls it makes, how many requests per second it can handle, etc.
The model is using say async/await vs. C vs. Zig. Each of the languages has different tools / a different model for reasoning about the dynamic behavior of programs.
The keyboard post also expresses something like this:
I just wanted to blink the little squares on the screen on and off very quickly.
That is what has to happen in reality. And the author is very neutral and agnostic about which tool will be used to get there – it is very problem-focused rather than tool-focused.
Does it have some examples of where Rust’s type systems misrepresents reality?
Reading over it, I think it’s closer to “the type system made my life hard”, and when I used Zig, with a weaker type system, was a breath of fresh air.
Though there is some good humility at the end – it is possible that tradeoff can change over time, as the program evolves and is maintained by more people
Nonetheless I think this is similar to the issues that I suspect will result in continued clashes on the Rust for Linux project.
I don’t believe the general point is a strawman, because I see a very strong consensus in this thread and elsewhere that if an interface is not expressible in Rust’s static type system, it can’t be a good interface, and should be changed so that it is.
Hm I just noticed this sentence in the Wikipedia page:
The RCU infrastructure observes the time sequence of rcu_read_lock, rcu_read_unlock, synchronize_rcu, and call_rcu invocations in order to determine when (1) synchronize_rcu invocations may return to their callers and (2) call_rcu callbacks may be invoked.
“Observing the time sequence” certainly sounds “inherently dynamic” to me!
You are describing an implicit state machine, and the question is whether you can encode the valid state transitions in the type a way that is useful in Rust’s type system. In many cases like this you can.
This may still result in dynamic checks - but in those cases, the type will guide you to insert those checks, and the code will not compile without them.
There is a field called choreographic programming which goes much deeper into encoding this kind of stuff in types than what you can do in Rust, too, if you are interested in that kind of thing.
You’re not alone as I understood it the same way as you. It almost felt to as the kind of discussion I’d hear in the corporate world.
New member of the dev team: “We could rewrite this like that and it would be so much better!”
Veteran of the dev team: “Yeah it could be better long term but you do understand that we have to keep releasing the product at a steady rate and while the old stuff is not perfect, it does work and it is what everyone here knows.”
You may not know this, but Rust for Linux is an experiment to see whether Rust would be a good fit for the kernel, and Linus Torvalds is quite supportive of it. Some senior maintainers who dislike Rust are not content to let the experiment simply run its course, they are obstructing it.
New member of the dev team: “We could rewrite this like that and it would be so much better!”
Veteran of the dev team: “Yeah it could be better long term but you do understand that we have to keep releasing the product at a steady rate and while the old stuff is not perfect, it does work and it is what everyone here knows.”
But the actual situation is that Rust is proposed to be used in new drivers, not rewriting tons of stuff. And the veterans are not being respectful and thoughtful about how they respond, they are being caustic shitheads.
Some senior maintainers who dislike Rust are not content to let the experiment simply run its course, they are obstructing it.
Wouldn’t that be part of the experiment though? In grade school we might say: “my hypothesis is that not everyone will love rust and welcome it with open arms”.
How are they supposed to test if it will work well if some maintainers simply block all work? Linus said that writing an fs module in Rust would be a great test for Rust in Linux. When Rust people ask for stuff from the fs people, stuff that they’d need even if they were writing C, like “what is the correct way to use this interface?”, the maintainers get caustic and go on rants about how the Rust people are pushing a religion.
It’s the same rhetoric, the same vibe. Instead of screaming ‘they are shoving GENDER IDEOLOGY down our throat’ they are screaming ‘they are shoving the religion of SUBSTRUCTURAL TYPE SYSTEMS down our throat’.
Feedbro, a browser extension: https://nodetics.com/feedbro/
Hats off for asking this.
Here’s my view as a wannabe blogger: if I don’t see the traffic to my website I might be asking myself if it makes any sense to continue to blog.
A few of the big RSS reader services like feedbin will include a dynamic subscriber count in the user agent, which is a nice touch.
Then you’re blogging for the wrong reasons. I would continue writing blog posts even if nobody read them, because to me, the value of blogging is to write things down, to concretize thoughts and let them take form, to develop my worldview, to research, to keep a record of when I thought what and to help me remember prior events and trains of thought. If other people enjoy the blog posts, that’s all the better, but that does not determine the value of the activity by any means.
Apparently I’ve been blogging for the wrong reasons for years but I still enjoy it.
I would love to see a comparison with LibreSSL…
Does anyone on the beta here have some opinions on how it compares to WezTerm which seems to have similar goals?
I daily drove WezTerm for a bit, and now use Ghostty. I think they’re both very similar in that they’re terminal emulators that both aim to be fast while having a lot of features, and either is very good to use if you don’t care about the details too much. The main differences IME are:
Does Ghostty offer multiplexing?
Ghostty offers splits, but it doesn’t support persistence like WezTerm. I’d say you’re better of using zellij either way if you want persistence.
That was basically what I was coming here to post. I’m a current WezTerm user, and the main advantage I see of Ghostty over it is native (GTK, for me) tabs, splits, &c, rather than the cross-platform non-native tabs and TUI menus that WezTerm has.
I’ve used both a lot. Ghostty is my daily driver now. WezTerm would be my go to if not for Ghostty, then it would be a tossup between Terminal.app and Kitty.
WezTerm has a feel like emacs or nvim-as-blogged-about-on-internet – you are kind of expected to do a lot of coding as configuration to turn it into a tool carefully crafted around the nuances of what you want. If you do that, it is great.
Ghostty is more opinionated and gives you fewer knobs, but the knobs are well chosen. Analogizes to OS X whereas WezTerm is a crunchy Linux (Arch or such).
In my personal journey, well, I declared .emacs bankruptcy a few years ago and wiped my accumulated configs from over two decades and moved to using defaults everywhere as much as I can bring myself to, as I don’t have the cycles to spend hand customizing all my tools and keeping everything up to date and so on :-/ YMMV
WezTerm is easily the best terminal emulator I tried so far and it too checks all the boxes in that list:
https://mitchellh.com/_next/image?url=https%3A%2F%2Fstatic.mitchellh.com%2Fghostty%2Fzig-showtime%2Fslide-7.png&w=3840&q=75
WezTerm does not check the native UI/integration boxes.
Thanks! I configured WezTerm to show very little window decorations and totally forgot about them being not native.
What would be today’s definition of “native”?
using the platform’s gui toolkit to draw tabs, right click menus etc
In terms of font weight, Wezterm renders thinner text than iTerm or Terminal.app does, enough to keep bothering me. I tried to tweak the configuration, but nothing helped enough.
To be fair, I faced the same problem with Kitty and Alacritty too.
I will see how Ghostty fares when I can.
Wezterm has many options for font customization. For example, it’s possible to disable anti-aliasing for even thinner fonts
I don’t think I’m after anti-aliasing.
Look at this screenshot that compares rendering of Cascadia Code fonts in iTerm with that of wezterm.
You should see that the characters marked with a red circle in the WezTerm window are rendered better visibly in iTerm than in WezTerm.
I wonder how ghostty compares to these two.
For what it’s worth, the only font-related config in .wezterm.lua is:
Interesting, I just tried Cascadia Code and it looks like the rendering is the same in iterm2 and wezrerm, maybe we have different font versions or something.
https://imgur.com/a/sh7Grk0
Yeah the results are almost identical. Can you share your config? Are you running wezterm on Sonoma on MacBook Pro M1?
Sure, here is wezterm config: https://pastebin.com/KChBQ2yW I tested on Sonoma on MacBook Pro M2, wezterm version is ‘wezterm 20240922-151228-2b76c63b’ and the latest version of Cascadia Code (2404.23).
Nope. I used your config verbatim with the latest wezterm. But I still get cut-off characters, and thinner fonts than on iTerm.
Thank you for your efforts though!
I think there are some global Fontconfig settings you can apply that will get you exactly the rendering you want. Unfortunately, I’m not at any of my Linux machines right now to share it here.
Yeh, same for me: https://federate.me.uk/@jperkin/112574990612338660
It’s such a small issue but makes applications unusable for me, there’s just something wrong with Linux-style rendering. It’s especially noticeable with “anything and everything” near the top of my first screenshot, the “y” is clearly rendered incorrectly.
I haven’t tried wezterm on Linux, so can’t speak to that experience. My problem is on macOS.
In general, though, while fonts on Linux (NixOS) are less crisp than on macOS, they don’t zig-zag as your
y.Yeh, this is on macOS. What I mean by Linux-style rendering is that wezterm uses harfbuzz rather than native macOS.
I see. I wasn’t aware of that. So if ghostty uses CoreText instead of harfbuzz on macOS, only then its font rendering will be comparable to that of iTerm.
I had the same annoyance with WezTerm and at least IME Ghostty looks functionally identical to iTerm. I did manage to get WezTerm to behave better by using the WebGpu frontend with a medium font weight, so you can try that if you haven’t already.
Thank you for the tip! I’m not a terminal emulator aficionado enough to have another go at wezterm. I will just stick to iTerm for the time being.
I remember mitchellh’s posts (on Twitter?) talking about the pains he took to implement font rendering in ghostty. I appreciate the efforts.
It’s really good! Ironically, I’d call Wezterm vs Ghostty to be emacs vs neovim despite wezterm being the one with Lua. Wezterm is far more flexible, one of if not the only terminal who’s config is a programming language. The sky is the limit with Wezterm, letting you even customize the UI.
Ghostty on the other hand is much more streamlined. It has less potential for ricing, but feels much lighter while still keeping the important stuff. Imagine alacritty, but with a 10% speed nerf, but with 90% of the features of wezterm, and all the ones anyone could ever want.
Recently got invited to the beta, making the switch from Wezterm. I mostly use CLIs and Helix / Vim though, so I don’t know if I’m as qualified to answer as, say, a power user would be.
This is my:
At least asciitable.com works without JavaScript ;-)
I don’t understand why people use JS to display plain text.
This is my favorite way to visualize the 16 colors:
Another advantage of brackets: in Vim you can press ‘%’ to jump to the corresponding bracket.
You can do that with keyword delimiters too in languages that use them.
This was my favorite.
Anecdote about this: https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/
Tk is the easiest way I know of to create simple GUIs.
Here’s an Hello World in Python. (There are bindings for other languages too).
it weighs about 200MB to deliver this with pyinstaller and at this point I’d rather use Qt (and I wish I understood this earlier without wasting time on “lighter” options which really aren’t and have various issues)
That’s surprising (although I haven’t looked at tk for decades so perhaps it shouldn’t be). Is any significant proportion of that 200M specific to the python bindings/bundle?
i have no idea. i just ran pyinstaller on a file with a single use of tkinter and observed the 200MB output (very slow to unzip in part due to lots of small files looking like they are language specific data?..)
I am sure you could make it smaller by getting clever, but when the pitch is “the simplest way to make a GUI” getting clever detracts from the pitch and makes you look at all the other things in the package except for simplicity
I have little Python experience, but I suspect you could get a smaller package than that. Last time I tested Python, I was able to get a self-contained “hello world” down to ~7 MB (on Windows, if I recall correctly), and the Tcl/Tk runtime is pretty small, so it shouldn’t add too much on top.
The last time I looked at cross-platform GUI toolkits with Common Lisp bindings, everything was bad, but Tk was significantly less bad than any of the other options.
For railroad diagrams there is also
kgt: https://katef.github.io/kgt/Example: https://katef.github.io/kgt/examples/expr.svg
Awesome!
Finally I can hide the “What are you doing this week”:
lobste.rs##li.story:has(span[role="heading"].link > a:has-text("What are you doing this week")):remove()Yeah, I was annoyed that the tag proposal for weekly posts failed, seemingly based on ad hominem arguments about the proposer rather than on the merits of the tag itself.
Awesome intereview! I’ve never seen this youtube channel before but am definitely subscribing.
You can also get it as a podcast. Developer Voices and Software Unscripted are my two favorites in this area.
The host of Software Unscripted is on Lobsters: @rtfeldman
Not sure about Developer Voices.
Yup, I’m the Developer Voices host and I’m over here: @krisajenkins
👋🙂
Also, we’ve been on each others’ podcasts! [cue Spider Man meme]
Kris on Software Unscripted: https://podcasts.apple.com/us/podcast/hiring-functional-programmers-with-kris-jenkins/id1602572955?i=1000577649734
Me on Developer Voices: https://youtu.be/DzhIprQan68?si=gxdXbUXvRx48pbA_
Kudos! You did a great job interviewing Drew, I loved the curiosity you brought to the conversation and it seemed like you were genuinely interested.
Oh wow! I remember him from a talk about treating “effects as data.” 1 It’s definitely foundational to how I think about side-effects
I had a similar experience with dune and now use
ocamloptwith a mkfile.$7,500 just for servers? Wow…
They also run all the code the users write, maybe that explains need for a lot of servers.
Good note for future language developers: If you’re on the fence about implementation language for compilers, not that picking a language like C, C++, Rust or Zig will allow you to distribute your compiler as a WASM module that you can run in the browser.
This way you can host an interactive language playground at $0 cost.
You can also have an interpreter. Python officially supports this, for example:
https://devguide.python.org/getting-started/setup-building/#wasi
https://peps.python.org/pep-0011/#tier-2
Not to mention:
Plus TIC-80 can run games written in lua, ruby, js, moonscript, fennel, scheme, squirrel, wren, janet or python in the browser: https://tic80.com/learn
Running all this stuff server-side probably made sense when Exercism was started, but if you were building something like that today it would not be my first choice.
Jeremy went into some details about their costs here: https://news.ycombinator.com/item?id=41464985
When I read “$7.5k for servers” I immediately though of AWS/ECS. Unfortunately, I was right…
this is very cool, i want to use alpine with systemd
No systemd is one of the major reasons I use Alpine.
ok
I once helped maintain a commercially successful code base that contained a lot of unused code. We all spent too much time trying to understand how it worked only to realise we were wasting our time.
I managed to delete lots of it with a few unsophisticated uses of grep and gave a quick lightning talk about doing so in my limited spare time.
Nice lightning talk. I felt disproportionally pleased by you mentioning that you included the code snippets used to find stuff in the resulting commit message. As a git log enjoyer myself it is so helpful for future work.
That was funny, thanks for sharing.
Seems like there a more Perl devs maintaining huge code bases ;-)
Sidenote: this is an article from a user with the substring “gopher” in his nick ;-)
I don’t have a strong opinion on that, but I guess many readers here don’t care about HN ;-)
I watched the video linked in the email and there’s definitely a degree of completely unwarranted hostility that would’ve prompted me to make a similar decision. I can imagine this wasn’t remotely close to the first time someone from the RustForLinux project has had to field aggressive questions arising from made up ideas about what bringing Rust into the kernel entails.
Edit: Here’s a summary of the discussion that was happening in the linked video: https://lwn.net/Articles/978738/
I wrote large chunks of RFD 26, the document describing our thought process and our choice at Oxide to go with illumos rather than, say, Linux, for our host operating system. I recall wringing my hands for months on the subject of how likely it would be that we could work towards use of Rust in the core upstream repository of the OS, for both kernel and user mode components. Basically everybody is familiar with the stereotypes about what it’s like to work in the Linux kernel community and participate in their project spaces, and with widely shouted (if not shared!) opinions about whether it’s good to have debugging tools and safer languages. In the end I tried to give credit or at least open mindedness to the idea that perhaps the Linux folks were coming around in 2020 and 2021 and that they would have seen the light by now.
In hindsight it increasingly seems to have been a waste of good hand wringing.
Not just hostility but an incredible degree of ignorance. Saying something like “we’ve learned from Java that methods are bad” (barely paraphrasing) is such a hilarious misunderstanding of so many concepts in programming.
I don’t usually get angry with people on the internet. But this level of hostility and assumption of bad intent is next level. (Also, wow, looks like my corner of the internet is more friendly than I thought).
There was absolutely zero reason for the hostility of that audience member and the conference organisers should have stepped in.
Yeah that part shocked me as well, at the very least someone should have offered to continue the discussion offline/sidebar to allow others a chance ask questions before time. Anytime emotions start to become visible it’s passed time to step in. The speakers held their composure quite well, and I can’t imagine what kind of stress that adds on top of an already stressful event for most people (public speaking about controversial topics).
I would consider this to be tyrannical organizational behavior. If this actually happened I would absolutely have supported counter-organizers stepping in in order to allow Ted Ts’o to continue talking, and if that failed organizing and promoting a completely different conference run by different people in order to allow Ted Tso’ to continue making this point.
The result of such approach is that arguments are won by those who shout the loudest and have the most power, not on the merits of their arguments. We have a prime example how an organisation loses contributors by defending asshole behavior. Assholes tolerate assholes, but others don’t.
I’m an experienced Rust developer with expertise in C<>Rust interoperability, and in position where I could have been working on it professionally. There’s no way I’m going to contribute to Linux when it’s run this way.
Considering working on Redox?
I don’t contribute to any OS at the moment, but I’m considering seeing how I can help out Redox purely out of protest to this kind of circumstance. I don’t think Linux should have it’s place in the market anymore.
It’s a complex situation, and the people who say Rust is a religion probably wouldn’t reflect on themselves even if Redox eclipsed their work.
I suspect it’s more constructive to just focus on Rust’s own ecosystem and tooling (in userspace).
I started looking into contributing a week or two ago and I’ve started working on a Nix-based build system for Redox, see here: https://gitlab.redox-os.org/redox-os/redox/-/issues/1552
Seems like a small but friendly group so far.
I agree the other replies, but I think this hasn’t been said clearly enough: the issue is not what Ted is saying, but how. The question is valid, though it has been rehashed a lot, but the tone and aggressiveness is not a valid way to ask a question in any context. That’s toxic behavior, plain and simple, so yes it falls within an organizer’s duty to rein in.
Is the question valid? It was addressed by the speakers but he kept going. And I believe this has come up before.
I meant in general it’s a valid question, I agree it sucks to bring it up then again, and shows Ted was more in it to rant than ask a good question.
The “though it has been rehashed a lot” was meant to hint at that, but it wasn’t really the point of my comment.
Have you ever been to any sort of professional conference? Talks are organised into thematic sessions, sessions have chairs, chairs keep the Q&A on track and stop things devolving like they did here, or at least encourage people not to shout over each other, like Ts’o was doing. It’s not tyranical in the least and it’s not CeNSoRsHIp!!1 either.
Who are the organizers that they would have enough political capital to shut down Ted Ts’o?
Shutting down flagrant nonsense and defending community members from abuse is one way to develop capital!
Accusations of abuse are often a form of abuse, precisely because they offer an excuse for an organization to shut down something they claim is flagrant nonsense. I wouldn’t want to work with anyone who thinks that Ted Ts’o should’ve been prevented by some outside power from communicating the way he did here.
What in the actual… what kind of conferences do people here go to!? Like, for me, it’s been years, and the ones I’ve attended were primarily academic conferences, but the religion comment + shouting would’ve been more than enough to make the session chair step in. Abuse or not, that kind of thing just derails the whole presentation.
I wouldn’t want to work with you either, so I think we’re all happy.
The chair of a track has the full right to the room at any descent conference.
To be more clear, I don’t question whether a conference organizer could kick out a high Linux maintainer if the organizer so chose but rather whether the organizers would find it worthwhile to begin a conflict with someone who presumably has influence in the Linux dev community with which to make continued participation in that community unpleasant for the organizers (assuming the organizers are, and want to continue to be, participants in that community).
Asahi Linux’s developer also recounts a similar experience. https://vt.social/@lina/113045455229442533
Please tell me that wasn’t actually Ted T’so being that aggressive, as LWN suggests. I expect better from such a senior Linux contributor.
You shouldn’t! This is the norm, and although some things are no longer as publicly inflammatory the attitude has been this way for literal decades.
I don’t like to wear it as a badge of honor, but “I stood next to a lieutenant while Linus yelled at them during kernel summit” is definitely the closest I’ve ever been to the kernel development process, and it was standard practice back then whenever something new was coming to Linux. At that time, it was Kernel Mode-Setting (KMS) for GPUs.
It’s interesting that he mentions if this breaks the function of a bunch of critical file systems that users depend on, it’s not his problem.
I’m pretty sure that would be considered breaking userspace?
What’s the first rule of Linux kernel development?
And then his suggestion “Lets just see what happens if we don’t give a crap about the semantic interfaces in a year.”
Like he doesn’t know that it’s just going to be a total disaster and blow the fuck up; and claim that is evidence of the unworkability of the solution, rather than evidence of the unwillingness to even make minor changes for compatibility sake.
Also the comparison to Java… They are certainly suffering a lot with people just fundamentally misunderstanding what Rust is.
The semantic definitions I would imagine would be useful even to C programmers using C interfaces in the Linux Kernel.
This is a truly unfortunate development. I really hope the Rust ecosystem in the Linux Kernel continues to grow.
As a long time Linux kernel module developer, and current Rust developer, I’ve been following this project closely.
It’s not breaking user space, it’s breaking kernel space. He didn’t say that he would break file systems that end-users depend on, but rather break APIs which in-kernel users depend on.
This would mean breaking file systems among other things, but those breakages would be fixed before the kernel with that change is released; because Linux does not break userspace. The question is who’s responsible for fixing that, the person who made the breaking change in the API or the users of the API.
The presenters were pretty clear that they do not expect maintainers to learn rust and that they will maintain the rust API. So that is not the question.
The presentation was about describing the state of their patch and clarifying how the C API actually is meant to be used. My impression was that the maintainers do not really know either:-)
The Asahi graphics driver dev said pretty much the same thing about the DRM layer they need to interface with… the only crashes she sees are in that layer – due to unclear and undocumented lifetime issues.
IMHO it would be nice to have rust wrappers for those layers: Lifetimes are clearly documented there.
Oh I agree completely, tho Ted did problematise the “we can’t fix your Rust code when we break APIs” thing even though it was in bad faith. However I was mainly trying to delineate between “driver developer breaks their users, namely the end user, user has to adapt” and “core infrastructure breaks their users, namely drivers, driver developers have to adapt”. The former is breaking userspace, the latter is not,
Good Lord yes, what a troubled audience member. I felt like we were about three seconds away from him shouting about a ‘goddamn WOKE AGENDA’. It must be exhausting to deal with such deep confusion combined with fearful hostility.
That seems to be Ted Ts’o, the maintainer of ext4.
https://en.wikipedia.org/wiki/Theodore_Ts'o
That’s an interesting piece of history. Kerberos remains one of the worst technologies I am forced to use on regular basis especially on non-Windows hosts.
Sorry I laughed. I used to work with MIT Kerberos and the GSSAPI and don’t have any fondness.
I am not sure where you’re getting the “woke agenda” thing … that seems to be inflaming an already inflamed situation without reason. It’s a non-sequitir
I watched the video, and I can definitely sympathize with the author, and why an interaction like that it would prompt him to leave the project.
At the same time, I think the technical disagreement is fairly clear, and the social / project management disagreement is fairly clear:
And he actually offers a path forward – keep doing what you’re doing, but know that we’re going to break you, and it’s up to YOU to fix that, not US.
He also says we will find out OVER TIME if this idea is good or not. He is not REJECTING the idea, but merely saying he refuses to do any work (and maybe even learning) to accommodate an idea that he views as experimental (or maybe even unpromising).
Now I have no idea if this is the right thing, because I am not involved in the kernel, and I also don’t write Rust.
But to me if the maintainer of a piece of code is saying this, it is actually crystal clear what the disagreement is.
He wants to put the burden on you to do the work, because he doesn’t see the benefit right now.
The Rust for Linux is making what seems like a reasonable request for more information on the semantics, so that they can encode it statically in the type system.
I am not sure, but I suspect the answer is “you have to figure that out yourself because there’s 30 years of history there” … or “that is a misguided way of looking at the problem – the solution does not match reality” [1]
I have been involved in such migrations professionally, and this is a very typical disagreement between the “old team” and a “new team”.
A new team assumes they are going rewrite everything and make the world better.
The old team has been down in the trenches for years. They have intimate knowledge of the code and the painful debugging necessary to get the system into its current state (a very successful state in this case, as Linux file systems store approximately ALL the data in the cloud, when it comes down to it)
The old team feels disrepected by the oversimplifications in the new way of thinking. (The perceived disrespect is probably why you’re getting this aggressive tone.)
A new team is genuinely optimistic and wants to improve things
The results are usually a mix, which is unsurprising. It’s never what the old team thinks it was, or a new team thinks it will be. It is a very typical conflict.
(And note it’s also possible that there are multiple new teams, and that one or more new teams is abandoned. But that doesn’t mean it’s not worth trying.)
It has nothing to do with any “woke agenda”. Do you agree? If so, I suggest retracting this comment, because it’s unhelpful and inaccurate
To me, the issue with what he said has nothing to do with the technical content and everything to do with the hostility. It sounded like he was seething with hatred toward the language and the Linux Rust project. Hell, he even described the speaker as pushing a religion!
It was not a comment from someone trying to productively discuss technical challenges.
The discussion was about power, really, disguised as technical one. It’s about establishing who is subservient to whom: the Rust interfaces to C ones, or vice versa.
Yes, in the context of the Linux project. The people who have power are the ones who have made things work for users, and Linux has a track record of making things work.
Are there Rust devs interested in contributing to GNU Hurd, and converting it to Rust? (honest question)
If Rust devs make the kernel better, and I hope they do, then they will naturally have more power. But so far it looks like it’s still the early days.
Rust developers can fork Linux and do whatever they want with it – that is the beauty of open source. There can be parallel development among people who disagree.
Users can vote with their feet
I actually suspect that is the best solution here – as I would personally like a memory safe kernel, but I’m not sure if Rust is on the path to it. It would let both projects move faster.
Ted Tso is a long time maintainer and he’s basically saying he refuses to merge stuff which is going to make his job harder later.
That’s not what I heard. Ted said that he isn’t interested in learning anything about Rust, even if it makes his job easier later. It’s about anti-intellectualism and machismo, not about maintenance burdens.
He has not yet been sold on the values of Rust in projects of the scope of the Linux kernel.
At such a time as he is convinced, he will probably change his mind on what he wishes to learn.
This isn’t anti-intellectualism. This is pragmatism.
Ted clearly isn’t listening to what the presenter is saying. Ted says “I don’t want to fix Rust code when it breaks because we change the C API” and the presenter says “that’s fine, I’ll fix the Rust code, but please tell me what the current semantics of the C API are”, to which Ted says “I don’t want to learn Rust!”.
Pragmatism would be delegating the work to someone else. This isn’t pragmatism, it’s childishness.
Right, and learning Rust deeply enough only to be able to make such a decision might feel like putting the cart before the horse to him.
Not really. I’ve answered a few questions like this on the Phoronix Forums, but basically:
Linux is a very special case because it’s used everywhere, it’s the standard OS of the world, even MS has given up on Windows and is just letting everyone use Linux now (through WSL or Azure Linux). There are a lot of reasons to use Rust, but the primary benefits are a more secure kernel and it will bring in new developers, as there are a lot less new C developers than there used to be.
I’ve considered the implications of making a separate fork of Linux just for Rust, but I don’t think it’s feasible. I can’t see a bunch of people just going over to some random fork that has no funding, and the split would be detrimental for both projects, but especially the fork as they’ll slowly lose the ability to merge patches as they fundamentally change how Linux is architected.
They have. The Asahi Linux GPU drivers are all in Rust in their own fork.
It’s a side-note but I wish people would stop using “memory safe” in reference to programs to mean “written in a memory-safe language” and not “free of memory errors”, which is what it is (or at least was) actually supposed to mean (of course the first implies the second, but the reverse is not true). The use of
unsafeas an actual keyword in Rust hasn’t helped the situation; “unsafe Rust” can mean so many things depending on the context (an unsafe languagesubsetsuperset, or a piece of code that is only valid in that subset, or a piece of code written in that subset that also has a memory safety issue, or code within anunsafeblock regardless of whether it uses unsafe language constructs) and it causes so much confusion in discussions about memory safety.I think what you are saying is that you like the idea of a kernel written in a memory-safe language, not just that you want a kernel free of memory safety errors, which should really be a given.
I want a kernel that’s free of memory safety errors [1], not necessarily one that’s written in Rust or any other particular language
Rust is one promising solution, but not the only possible solution
[1] and one that’s free of logical errors like missing/incorrect access checks, local root exploits, etc.
I think this might be where the ‘religion’ word came from. I don’t see other languages aggressively pushing rewrites for everything. Video said “Rust has ADTs” which weren’t invented in Rust, nor exclusive to Rust, nor popularized by Rust. Same applies to memory safety, and other arguments used in the ‘why Rust’—but also in the Venn diagram of the languages that are suitable for systems programming is Rust not alone or particularly remarkable.
Other languages with Rust’s features aren’t suitable for integration into the Linux codebase.
Rust is the first successful attempt to write a language that solves the same problems as C and also has the sort of nice features that application programmers have had for twenty years. Of course people would be excited about it.
Zig is not memory safe language.
Go is not memory safe in the presence of multiple threads.
None of these are memory safe, nor will they ever be.
Yep. Started a Go job recently after five years of rust. My heart sank the first time I saw “make sure not to call this without holding a mutex!” in some function’s comments.
Thats not traditionally what memory safety means. Traditionally memory safety means something more like free from memory errors that would lead to control of the instruction pointer which removes a massive class of never ending security vulns. Go achieves this.
Crashing from threads racing to overwrite a variable could definitely be considered a safety issue in some domains of course.But, If you redefine memory safety this way, doesn’t that exclude all languages but rust?
Go does not achieve this.
In Go, stores to slice-type variables are not atomic. You can create three goroutines that all have access to a struct that has a slice as one of its fields:
Goroutine one stores a small slice to the field, in a loop.
Goroutine two stores a large slice to the field, in a loop.
Goroutine three reads the field until it gets the base of the small slice and the length of the last one. From there, you can build type confusion, use-after-free, and all other categories of memory safety bugs. You can overwrite a function pointer (or interface type) with a value that you control and cause control flow to transition to n arbitrary point.
No, this is something that doesn’t happen in any memory-safe language. Nothing in the JVM or CLR has this problem, neither do Haskell, ML, Lisp, JavaScript, Erlang, and so on.
Memory safe means that every memory access must be via a valid pointer that is derived from a pointer to a valid object (global, heap, or stack allocation), is within the bounds of that object, and is within the lifetime of that object. Any access that does not follow these rules must either trap at run time or be disallowed at compile time. It is a subset of type safety, which additionally imposes rules on the operations within an object.
Super interesting. Would it break backwards compatibility to fix this?
No, it would be an ABI change and Go doesn’t guarantee a stable ABI. It would be a perf hit though. Almost no CPUs can do atomic three-word stores, so you’d need to either hold a lock while updating slices or do what .NET did and make slices heap-allocated things. This places more strain on the GC.
I realize this is possible: https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html
But, I still argue that Go is considered a memory-safe language by normal definitions. I have never seen a single real-world Go bug of this nature that could be used as a security vuln which brings it out of the class of languages like C/C++ for which large code bases seem to have a never ending problem of bugs and security vulns from being memory-unsafe.
I think at the very least it would also exclude BEAM languages, where nothing is shared?
OCaml has a moderate runtime. I wouldn’t call it ‘large’. The MirageOS unikernel is written in OCaml and Mirage programs are very small and start up in a handful of milliseconds. Also I wouldn’t say it needs ‘a lot of tooling’ for basic C interop, it supports C FFI out of the box. Finally, OCaml is widely recognized as generating quite predictable Assembly.
I think all your points do hold for Haskell, though.
One point on OCaml, aren’t they looking to deprecate 32 bit support? Probably wouldn’t be suitable for Linux.
They have removed 32-bit support from OCaml 5 onwards, but the latest 4.14.x series is still supported. And Linux might remove 32-bit support in the near-to-mid future: https://www.reddit.com/r/linux/comments/152yeqx/there_are_plans_to_drop_32bit_support_from_the/
One random maintainer opining that they should remove 32 bit support is not indicative of much.
Will it be supported 20 years from now? We are talking about integration into the Linux kernel, after all.
Will Linux support 32-bit 20 years from now?
At most the syscall ABI. Maybe redirected binfmt style to 2030’s kernel running in a special VM (points at WSL).
Yes, because the cheapest processor nodes are not getting any smaller, so the silicon cost savings of 32 bit over 64 bit will continue to make sense forever. Linux will only lose 32 bit support if people decide to just stop using Linux for small systems.
If the cost savings are substantial enough then I’m sure someone will step up and pay to maintain OCaml 32-bit support. It shouldn’t be that difficult since the support already exists in the 4.14.x series, the last series before 5.x (multicore) 🤷♂️
“First successful” implies other attempts didn’t reach that goal & they have, but community uptake & such are a fickle bit that can get a “aren’t mature enough yet” aren’t despite having sound fundamentals, but even some are quite old/mature/stable, just not a lot of users even if they, say, have a more robust type system than Rust’s affine types which has limitations (such as linear types). One other difference is unless exposing externs for C binding, Rust’s ABI isn’t stable or particularly usable/portable outside of Rust which continues to fuel the rewrite it all in Rust with Rust libs situation as opposed to the C libs that back so many projects regardless of language. If Rust was as easy to use/link from every language as C, then I would be more enthusiastic about it as a step in the right direction even with type system limitations, but as the post above me mentioned, it is not the only language that could be a solution to this problem.
Which non-Rust language do you think should be used for writing memory-safe code in the Linux kernel?
I think you’re mixing up a couple issues.
The C ABI is widely used because any language with the concepts of function calls and memory access can use it. It’s common ground for any language that compiles to native code, but that also means it’s not idiomatic in any of the languages that are using it for FFI. Even in C++, which has the smoothest possible upgrade path from C, you’ll need an
extern "C"layer of plain functions wrapping your classes and templates.Whether or not Rust has a stable ABI for its own semantics doesn’t matter for cross-language use cases. The reason to want a stable ABI is better support for pre-compiled object code archives, which is pretty niche in the use cases that Rust is focused on.
The push to rewrite existing code in a memory-safe language is because people are tired of having their programs and computers crash, or get taken over by botnets, or get all their tax documents encrypted.
It’s not about Rust. Rust is probably the least-popular memory-safe language in common use today. All the Rust code in the world is a fraction of a percent of the C#, Swift, Java, and JavaScript code out there – and that code has almost entirely displaced C/C++ for the development of applications.
The reason people object to Rust isn’t because of anything about Rust, it’s because because they want to use C forever, and they hate the idea of seeing the last remnants of the PDP-11 era get scoured away down the drain.
Rust is as easy to use/link from every language as C – easier in some ways, because you don’t have to worry about dynamic symbol compatibility in libc. The
rustcoutput is a regular object file that can be passed into the regular build toolchain, and a shared library written in Rust can be a drop-in replacement for one in C.If it were gun to my head (meaning developer ecosystem/community isn’t there even if it is an old language), I would pick ATS as a ‘C generator’ for supporting linear types for tracking resources over Rust’s affine types–along with having refinement + dependent types & a proof system you could actually start asserting things in the type system beyond Rust’s type system & language features capabilities (including tail call optimization as jumps) while having all the low-level resource allocations + tracking (memory alloc, shared memory, locks, pointers, etc.). The type system asserts + zero-cost abstractions can eliminate most run time checking, and being from the ML family tree (which technically Rust came from OCaml explaining many of its features), you have a syntax, if unfamiliar to the C programmer, that is more ergonomic for doing ADTs/pattern matching & recursion. The compiler is built around abstracting over & even outputting C code to be linked via C code so it doesn’t disrupt those still wanting to use C or where C is easier.
But this would likely never happen & be even less popular of an option even if I think it is neat & crosses all the boxes.
You may be interested in the proposed crABI ABI, which has as a goal the ability to interop with other languages in a richer way than simply exposing C types.
There are languages in development that could do the job of Rust here, none of which I think have been mentioned in this thread, but they’re all way less mature than Rust. All languages in existence that may be mature enough are simply inadequate.
All popular languages with a young and enthusiastic user base ask for projects to be rewritten in their language of choice.
The C++ crowd famously nagged Linus to use C++ in the kernel till he told them very explicitly he does not want to. And evenntoday youbget people arguing for C++ in the kernel in addition to or instead of rust. The kernel got by pretty well as there are not too many languages that fit its niche, applications get this a lot more.
I was going to say that the user base was the only truly exceptional bit, but being non-technical & might be just zeitgeist (we will see) I left it out :)
I want a memory-safe kernel, which definitionally means a kernel written primarily in a memory-safe language.
There do exist kernels written in memory-unsafe languages that, when compiled to a binary artifact with a specific toolchain, can be proven to contain no memory safety errors. But those kernels have extremely high development overhead due to all the extra manual verification. Consequently they do not, and likely never will, have the breadth of hardware and software support needed to supplant Windows / macOS / Linux as the foundation layer of all general-purpose computing.
I think you’ve got this wrong – “unsafe Rust” has a single definition[0]. When discussing code that contains memory safety errors, Rust programmers use terms such as “unsound” (or “incorrect”, “buggy”, “fucking broken bullshit”, etc depending on mood) to describe code that contains memory safety errors.
Being unsafe doesn’t mean that the code contains memory safety errors, it means that the code can’t be proven memory-safe by the compiler.
[0] To the extent that any programming language name does. It’s true that programming language names are usually used for both the language itself and code written in that language (e.g. “a new version of Java was released” and “I don’t want to read ten thousand lines of Java”), but that’s not Rust-specific.
It doesn’t though, that was the whole point I was making.
It might have a single formal definition (where?), but it is “casually” used in all the ways I pointed out.
Yes, that’s the problem. They can’t call it “unsafe”, which is what would’ve been said prior to the existence of Rust, because it has become ambiguous.
I spoke of programs, not of smaller pieces of code, for which I don’t think there’s necessarily any prevalent definition of “unsafe”. But for programs, being unsafe definitely does or at least did mean that the program (code) contains a memory safety error. It’s only since the emergence of Rust (and its growing popularity) that this definition has become muddied.
You’re unintentionally reinforcing my point - that the use of “unsafe” as a keyword in Rust has led to confusion about what a “memory-unsafe program” actually is.
I disagree with both assertions. The term “unsafe” in programming has always described code that may contain errors, because if the code is known to contain an error then it’s simply incorrect.
I know from personal experience that the use of “unsafe” to describe programming languages without memory-safety guarantees dates to at least the mid ‘90s (when it featured prominently in arguments about Sun’s Java applets vs Microsoft’s ActiveX vs Macromedia’s Flash), and would not be surprised if more experienced devs could cite examples from the Usenet era.
Rust introduced the concept of memory safety to a generation of systems programmers who grew up after C had conclusively trounced all of its competitors, but that doesn’t mean Rust originated the idea.
Here’s a 2009 paper discussing memory safety as a property of a C program: safe if it contains no memory errors, unsafe otherwise:
https://link.springer.com/chapter/10.1007/978-3-642-04694-0_10
Here it’s talking about specific executions being safe or unsafe, and here:
It’s talking about proving the memory safety of a program (though it’s not written in a memory-safe language).
This spells it out very clearly:
So, it’s certainly not true that:
At least this one paper is an exception to that claim. I’m sure there are plenty of others, if you are willing to search.
Here’s a 2014 blog post by Michael Hicks, a professor of Computer Science at the University of Maryland:
http://www.pl-enthusiast.net/2014/07/21/memory-safety/
That’s a pretty clear definition, in line with what I’ve stated and not equivalent to your own definition. A memory-safe language can only be used to write memory-safe programs, but that doesn’t mean that all memory-safe programs are written in memory-safe languages.
The use of “safe” or “unsafe” to describe programming languages isn’t at question.
I agree with both davmac and jmillikin.
Everyone agrees that for languages, the natural definition of being “memory safe” is that no program has memory errors. (In practice we use a more complex, less natural definition, closer to “a language that pushes you towards writing programs mostly with this property and with clear social contracts about the exceptions”) Same with programs, a program is “memory safe” if no run of the program has a memory error. This is consistent with Mike Hicks’ terminology, which is fairly clear.
Obviously “not safe” is the negation of “safe”, so a language is “not memory-safe” if some of its programs have memory errors, and a program is “not memory-safe” if some of its runs/executions have memory errors.
We probably want “unsafe” to mean the same thing as “not safe” because doing something different would be confusing. (But not unheard of.) So we want to define an “unsafe” program as a program that has some runs that have memory errors, which is consistent with what davmac claims but appears contradictory to what jmillikin’s claim.
But note that jmillikin is talking about what “unsafe” means in Rust, and
unsafeis first a qualifier of program fragments, not whole programs. A natural definition of “memory safe” for a program fragment is something like: for any usage of this fragment in a program that “has no other source of unsafety”, the program is memory safe. (This is a bit tricky and not obvious to define formally, but programming language researchers are good at this.) Say a function, for example (but it also works for language constructs, etc.), is memory-safe in this sense if there isn’t a way to get a memory error by calling it.I believe that this notion of safety of a program fragment is consistent with the established use of “memory safe” in industry and academia. It is compatible with the claims of jmillikin, and also with the formal statements of Mike Hicks cited by davmac. In OCaml, we have a function
Array.unsafe_get : 'a array -> int -> 'a, which is not memory-safe as it does not perform bound-checking on the array access; this is “unsafe” precisely in this sense – and has been around well before Rust was introduced.Now one thing that is a bit confusing is that there are several reasonable but incompatible definitions of what it means for a program to be “unsafe”. The academic citations from davmac write that a program is unsafe if some of its executions contain memory errors. Another usage that exists in the wild (I believe well before Rust, but maybe Rust popularized it) is to say that a program is “unsafe” if it contains “unsafe” fragments. I believe that the first definition makes more sense if we think of the program extensionally, as an abstract object that runs, and that the second definition makes sense if we think of the program intentionally, mostly as source code (that can be executed).
I appreciate that you’re trying to engage in this discussion in good faith. I do need to point out though:
That is exactly the issue I was raising right off the bat - the terminology introduced by Rust has muddied the more general, previously-existing terminology about memory-safe programs. jmilkin rejected that assertion, though; so, if their ongoing argument was actually about a different “unsafe” that is specific to Rust, then that would accord with my point, that the terminology has become confused.
And also:
Indeed, but the only reason that I only cited academic sources because those were the ones that I could find that could easily be dated to a pre-Rust-prevalance period. There are plenty of non-academic uses of “memory safe” entailing the exact same definition. I won’t point them out because I’m not a personal assistant and people should be able to do their own Google searches. After pointing out the academic cases, jmilkin shifted the goalposts by dismissing them as being only relevant to an “academic bubble”. Their response was so arrogant and condescending that I posted a snarky reply (that I partially regret, but which frankly was deserved) designed to close off the conversation. The fact is that uses of those definitions can easily be found, today, outside of any “academic bubble”, but it’s not my job to provide counterexamples to every bad argument that is made against something I’ve said. People can believe what they want, even if it’s wrong, or do a tiny bit of groundwork and find out for themselves.
The way I understood it was clear enough, and the quotes I did provide illustrate some nice concise definitions which matched that understanding. While indeed these don’t prove that other definitions weren’t used, they do clearly disprove jmilkin’s sweeping statement:
I think, if there’s going to be any argument about what definitions were around and when, they need to be based on more than just bold assertions that are clearly contradicted by available evidence. Your observation about Array.unsafe_get is at least a starting point in that regard (although it doesn’t prove anything by itself, of course).
It’s possible that some areas of academia use non-standard terminology, in the same way that astrophysics describes all elements heavier than helium as “metallic”. I don’t think that matters to anyone outside that specific academic bubble.
It’s also possible that terminology originates in some area of academia, and is used somewhat consistently outside of that area until some popular phenomenon - say, the emergence of a new programming language - leads to it entering the lexicon of a broader population, and beginning to be misused by a segment of that population who don’t realise that they are overloading the term by using it a slightly different context, for example.
I don’t know if that’s how it actually happened, but it’s certainly possible, and since we’re just apparently throwing possibilities out there now, may as well throw that one out too right?
That you don’t think it matters to anyone isn’t of any concern to me or anyone else that it does matter to, sorry.
I feel like your definition of
unsafein Rust is a bit nebulous. I have a better one: Rust guarantees that it will have no undefined behavior (there’s one or two places it doesn’t, but those are known bugs.) Rust also has a few built-in APIs to perform actions which can lead to undefined behavior (operations outside of the purview of the compiler), these APIs are manually marked asunsafeso that they can only be used in otherunsafe(allows UB) scopes.This is what people mean when they say Rust is safer than C because C is basically Rust in an entire
unsafecontext, because C itself allows UB, whereas Rust doesn’t. It’s a matter of UB.The question being discussed in this thread isn’t the exact types of behavior that are forbidden outside of
unsafe { ... }blocks, it’s the definition of “unsafe” itself.davmac wants “unsafe” to refer to a property of the program as a whole. In this definition if a program can reach a state that permits it to execute instructions that violate the safety guarantees of the language, then the program is “unsafe”. In this model it doesn’t make sense to describe a function (or module, or library) as safe or unsafe – safety can only be verified given a full execution graph. And if someone says a program is unsafe, they’re not saying it might contain an error, they’re claiming that it does contain an error.
Furthermore, he wants to define “memory-safe language” to mean a language that can only express memory-safe programs. In other words, if it’s possible to write a program that can violate memory-safety guarantees, then he would say that the language that program is written in is not memory-safe.
Thus he claims that Rust is not a memory-safe language – and presumably none of Java, C#, Haskell, Python, Ada, or JavaScript are either. I’m honestly not sure whether there are any languages he would consider memory-safe. It strikes me as the conversational equivalent of setting off a fart bomb in a theater.
I’m sorry, but you’re confused. It’s not that I want “unsafe” to mean anything in particular, it’s that I believe it does mean something in particular. But not what you are claiming here; in the previously established meaning, “unsafe” has meaning outside of languages that don’t provide any safety guarantees.
What? I didn’t claim that. (Unless perhaps… if you mean “Rust including unsafe Rust” then … well, if you want to argue that “Rust including unsafe Rust is a memory safe language”, go at it, I won’t try to stop you).
I don’t see how, though that seems like almost an appropriate response to the ridiculous claims you’re making here now.
Using the definition “memory-safe language” as a language for which all valid programs obey the language’s memory safety guarantees, then a language cannot be memory safe if it (1) has some concept of memory mutability or visibility, (2) supports Linux as an execution platform, and (3) is able to perform file I/O on arbitrary paths.
Rust distinguishes mutable and immutable memory regions, supports Linux as a target platform, and is able to perform file I/O. Therefore, it’s possible to define a program entirely in safe Rust that modifies its own memory via
/proc/self/mem, and therefore the program is unsafe, and (per the claimed definition) safe Rust is unsafe.I don’t see the value in such a definition, since all of the languages of interest to industry would be excluded from the “safe” category, so I follow the standard definition of memory-safety as applied to both source code (not programs) and programming languages.
That wasn’t the definition, read it again. It’s not about violating or not violating the “language’s memory safety guarantees” (if it was, it would be meaningless for languages which don’t provide such guarantees).
And for that matter, I wish that people would stop calling any old language which bolts memory-safe constructs onto conventional pointer arithmetic but leaves the latter exposed to unskilled programmers “memory safe”.
There’s no reason in principle why those should be mutually-exclusive.
Interestingly, to me it sounded like a disagreement between experience and inexperience. I have conflated experience with hostility and/or authority many times in the past.
EDIT: @andyc said it way better than I could!
The “you’re pushing a religion” part invalidates that interpretation in my opinion.
I am inclined to agree on this point, though I lack full context and cannot be 100% sure.
?? The Rust guy kept saying over and over that no one is going to force any C dev to fix Rust interfaces. They already offered that path forward! The audience member was strawmanning hard.
What you’re saying here is equivalent to saying that it’s impossible for new C code to use the interface correctly because no one actually knows how it’s supposed to work. Asahi Lina actually pointed out something similar about the DRM subsystem here:
Fediverse version of that link which (unlike xitter) can be viewed in full without logging in: https://vt.social/@lina/113045455229442533
Thank you!
But that lays bare a horrible implication: no-one knows how to safely write file-systems against this API then. Regardless of whether it is when writing a Rust wrapper for the API or someone writing a new or maintaining an existing file-system in C.
Yeah, I was somewhat surprised to find that no one even knows how the ext4 filesystem works. The most authoritative document was basically some guy reverse engineering it with lots of “from what I can tell…” and “I think it does this…”, and after digging through the code I have to say he did a much better job understanding it than I’m capable of doing. It’s still wild to me that something as foundational as a filesystem isn’t specified such that people can write tools to operate on them without having to FFI to the Linux source code.
Yes, this is how most C and C++ APIs work. People who are horrified, I envy you because it seems like this isn’t something you have to deal with on a daily basis.
It’s also why Rust (and, to a lesser degree, modern C++) is such a breath of fresh air to so many of us who are used to dealing with giant old C and C++ code bases. Just the fact that Rust encodes lifetime information in the type system eliminates so many questions. When I write against someone else’s C APIs, my biggest question is usually “what are the lifetime requirements of this object? Should I free it? If so, when?”. That question is very rarely answered by documentation, so it’s left up to intuition, reading the implementation, and address sanitizer telling me when I’m leaning something or double-freeing something or use-after-freeing something.
There are many things about the Rust language that I’m not a huge fan of, and I personally prefer writing C++, but I don’t feel like I can ignore it.
Worse: many codebases don’t have a rule for that, either. I’m guilty of that, too, I think I’ve written at least one long piece of spaghetti code where, halfway through the implementation, I realised that accommodating a particular quirk of some underlying protocol or filesystem required something to be freed based on slightly different conventions than the rest of the code followed.
Sure, you document that visibly, comment your code, whatever, but wetware sidechannels just aren’t very good for that.
If you get a pointer from a function call, then you should free it, no?
Wouldn’t that be after you’re done using it?
No, and there are even examples in the standard library. For example, you are not supposed to free the
char *returned bygetenv.I wish those rules were universal, but they’re not.
Is that surprising?
I wonder in how many C projects the size and age of Linux people really know how the APIs work.
you have a dangling reference here
Good job checking that for them
[1] Regarding “whether encoding file system semantics statically in the Rust type system is a good idea”
Take this with a grain of salt, since I haven’t looked at the specific problem, nor do I have any real expertise in it
But I think there is the general problem where some people think “Of course that’s a good idea, why wouldn’t you do that?”
And then there is the reality that there are inherently dynamic aspects to software interfaces.
I ran into this difference in thinking while working on a garbage collector. Some people want there to always be a static way of doing things, but in this case it’s mathematically impossible (due to Rice’s theorem, etc.).
https://lobste.rs/s/8dqbty/my_experience_crafting_interpreter_with#c_a6kmdz
GC and rooting are inherently dynamic.
I suspect there is a big bridge to gap between Linux kernel dev and Rust for a similar reason
It’s a dynamic vs. static way of thinking, and again the answer is going to be somewhere in between.
The fallacy of the dynamic side is perhaps a status quo fallacy.
The fallacy of the static side is that everything important can be encoded statically. The failure mode is when you only encode the trivial properties, and the cost isn’t worth the benefit. The dynamic techniques for correctness still end up bearing most of the weight, and then you have a static “bureaucracy” off to the side.
I suspect @matklad might have some thoughts/opinions on this, e.g. since after using Rust, he’s using Zig and writing more about dynamic properties of software:
https://tigerbeetle.com/blog/2023-12-27-it-takes-two-to-contract
https://lobste.rs/s/blszfs/it_takes_two_contract
https://matklad.github.io/2024/07/05/properly-testing-concurrent-data-structures.html
My guess is that the Linux kernel is more like Tiger Beetle … are you going to try to encode the invariants of a transactional database in a type system?
Or are you doing to do it with dynamic assertions and the like? (Of course it’s not either-or, but I think there is a contrast philosophically, which is similar to the one between Rust and Zig)
I also noticed from the recent thread that the prototype of Tiger Beetle was done in node.js (https://lobste.rs/s/tr8ozm/why_is_spawning_new_process_node_so_slow)
To me that suggests that one of the most important properties of the system – performance, and the algorithms you use to get there – don’t benefit that much from static encodings
Of course the answer is different for each system, and that’s what makes it hard.
(“advice = limited life experience + generalization”)
This is somewhat of a non sequitur. Type systems encode dynamic aspects of programs all the time, especially so in Rust which has sum types. The example API in the talk was doing exactly this.
The simplest example is, I feel,
Arc, which statically describes a set of rules for entirely dynamically managing the life cycle of an object. You don’t know which thread is going to end up freeing it, but it’s still safe because the rules lay out why that doesn’t matter.By “inherently dynamic” I mean “expressing it statically is like solving the halting problem” – i.e. mathematically impossible
I didn’t say dynamic – I said inherently dynamic, and gave an example of what I mean
For people who don’t understand what I mean, I suggest writing a garbage collector in Rust. It will give you a good perspective on the nature of – and the limitations of – the abstraction you’re using.
I also believe there is a pretty strong analogy with the conventions used in say kernels or transactional databases
I also recommend reading this article
https://kevinlynagh.com/rust-zig/
https://lobste.rs/s/eppfav/why_i_rewrote_my_rust_keyboard_firmware
for an example of why hardware may not match what your type system can express, which is very relevant to kernel development.
Basically, you can be spending a lot of effort solving the wrong problems.
The Linux kernel has tons of problems I’m sure, so I’m glad this experiment is being done – but it does still appear to be an experiment.
Your example doesn’t demonstrate what you claim it does. Every property captured by a static type system is already dancing with the halting problem. There is no “inherently dynamic” boundary to cross here.
The business of a (sound) type system is to find an approximation of the dynamic property we are interested in, such that it can rule out all the violations without ruling out too many interesting dynamically-valid programs. All Rice’s theorem means is that this will always strictly be an approximation, not that it can’t be good enough for general purpose use.
GC rooting is absolutely no exception to this, and the borrow checker is actually uniquely suited to capture this kind of thing- an un-rooted reference is very much like a borrow, during which the collector must wait for a safepoint when the reference is again rooted or discarded. There are several designs for encoding this property in the Rust type system: https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe-tracing-gc-designs-in-rust/
Again, while these encodings are approximations, all this really means is that you can’t go crazy passing around un-rooted references in ways that are too complicated for the type system to understand. But this is essentially never something you want to do anyway! These encodings are plenty flexible enough to capture all the typical ways that the mutator holds onto un-rooted references, which are very localized.
You can encode SOME rooting policy, but what about the most efficient (minimal) rooting policy?
Do you agree that this is a possible failure mode?
Or is it inconceivable? Is it always better to use the static approach, and there is no tradeoff to make?
I haven’t said anything about which side of the tradeoff is better. I only specifically disagreed with your claim about the “reality” that some things were “inherently” dynamic.
But with that out of the way, I think it should also be obvious that nobody is claiming that the static approach is always better. Rust itself uses the dynamic approach for things like bounds checks and integer overflow checks!
But even then, your argument is somewhat of a non sequitur: the thing Linux is doing is neither dynamic nor static. It is just an un-checked free-for-all where the human programmer has to manually learn and follow the rules of the API, and when they fail it just corrupts the abstraction.
Right, so if I have a Rust program with an integer
i, then it is an inherently dynamic property of that program whether the integer overflows.It’s not a property you can statically encode in the type system. It’s mathematically impossible to do so (in general)
Do you agree?
Likewise, I claim that software interfaces and especially hardware interfaces have inherently dynamic properties. (I’m not sure if the keyboard firmware example is one, but it appears to be a case where the type system is creating bureaucracy that doesn’t help correctness. It is sort of beating around the bush, and not really helping with the core problem.)
You can approximate them with a static property, but it may not be the algorithm or policy you actually want.
For example, it might run too slowly, which is why I brought up the GC rooting example.
Just because there is no encoding of the file system API in a static type system doesn’t mean that not well-specified, prima facie
It could be well specified, but impossible to express in Rust’s type system. Or you can express some part of it in Rust type’s system, but not in a way that actually helps you ship 50 working file systems.
It can certainly be be a big mess too – Linux code is messy with many hands in it.
Let me additionally quote Tso
Do you believe that this question makes any sense?
Is the idea of encoding semantics in the static type system prima facie a good idea?
My feeling from this thread is that many Rust users believe that what he’s saying can’t possibly be an argument, which is what I alluded to in the comment that you replied to.
I believe there is a fundamental difference in thinking – and it is more or less accurate to call it dynamic vs. static.
On the one side, you have the dynamic “reality”, backed by shipping 50 file systems over a few decades (which implies debugging them), and on the other side you have “we think in static type signatures; the program can’t be correct and can’t be reasoned about unless it passes the type checker”.
Tso is not saying it won’t work – he is treating it as an empirical question. But I believe many Rust users do not believe it’s an empirical question.
Is it an empirical question?
Is it possible for a static type system to model a problem poorly, and get in the way of a correct program? Or are the static types reality itself?
Absolutely not, for the reasons I already gave. You can use ranged integer types, and reject operations where the ranges of the inputs mean there may be overflow. This is a classic example of encoding a property in the type system.
The GC rooting example does not suggest anything like this. As I already said, the rooting behavior of existing GC languages is already easily local enough that it would not have to change at all to be encoded in a type system.
I repeat: nobody is claiming that the static approach is always better. The reason Rust uses dynamic checking for overflow is not that it would be impossible to encode in the type system, but that they judged it to be more practical to check that particular property at runtime.
You are trying to counter an argument that you completely made up, not anything the Rust language or the Rust-for-Linux project is actually saying. And worse, you are trying to pull me into that argument, which I am entirely uninterested in.
This issue came up again and I responded here - https://lobste.rs/s/yx57uf/is_linux_collapsing_under_its_own_weight#c_gvj8fk
(won’t reply again on this thread due to length)
(For context: I use and like Rust, but I have ~no opinion on whether it’s a good fit for Linux.)
This feels to me like a false dilemma posed in such as way as to make people either agree with you or appear to agree with an absurd proposition (that static types are “reality itself” and no use of them ever models a problem poorly). Maybe something more concrete can be more constructive….
I get an impression that you use (or previously used) that keyboard firmware post to suggest that Rust is bad for interfacing with hardware, but I still don’t think that keyboard firmware post is relevant.
I think a better example of some Rust code being bad at interfacing with hardware is David Chisnall’s MMIO anecdote (see, e.g., here or here). The details weren’t clearly stated, but it sounded like what was happening in that case was that some Rust code was reading the value of a “device register” as a richly typed value, which is not okay. The solution would be to read the register value as just an integer and then map that to a more richly typed value with plain, safe Rust code like
Rust code can use structs and enums and lifetime-equipped references within itself, but, at an interface with hardware like that, Rust code must treat values it gets from the hardware as just bytes, or just integers, not structs or enums or lifetime-equipped references. The device registers’ world is a wild, untyped one whose values mustn’t be eaten raw in Rust’s typed world.
I think the many remarks you’ve made here about “dynamic vs. static” could be more understandable if more concrete examples were given. Does this MMIO example sound relevant to what you’re trying to say about “inherently dynamic properties”?
Yeah I could have omitted the last line, but it made me chuckle … I don’t believe the general point is a strawman, because I see a very strong consensus in this thread and elsewhere that if an interface is not expressible in Rust’s static type system, it can’t be a good interface, and should be changed so that it is.
I disagree with that.
Also, I ended up skimming a mailing list thread, and it is very clear to me that it is a clash between the dynamic mindset of kernel devs and static mindset of Rust devs:
https://lwn.net/ml/linux-fsdevel/ZZWhQGkl0xPiBD5%[email protected]/
For the record, I would like the future of kernels to use more static analysis, and static types. I think it would make kernel programming a lot more accessible to me personally, and to everyone, and thus widen the pool of contributors, and make kernels better.
I just think the types need to be appropriate to the problem. And what I am hearing from Tso is that this might be possible, but it’s a question that should be answered empirically.
My suspicion is basically the same as what chisnall and matklad said elsewhere in the thread:
https://lobste.rs/s/46pt2l/retiring_from_rust_for_linux_project#c_eqlhxb
There is a “Rust view of the world”, and Rust has a very specific aliasing model. I would even say that Rust is domain-specific language – because all languages are.
And type safety is a global property of a program.
This makes it harder to migrate an existing codebase like Linux, with its own specific model. The models clash.
I believe what they are saying is not substantially different from Tso’s suspicion – it’s just expressed with less shouting
But like I said, it’s an empirical question that will (eventually) be answered …
The MMIO issue with unsafe does seem relevant and important, though not exactly what I was thinking of
There were 2 related claims
As for examples:
It “feels” like RCU is “inherently dynamic”, with respect to the Rust type system, though I have no expertise in this area:
https://en.wikipedia.org/wiki/Read-copy-update#Sample_RCU_interface
https://lwn.net/Articles/653326/#Other%20RCU%20Flavors
Can the Rust type system say anything about this? Can it statically eliminate errors in obeying these protocols?
I could certainly be underestimating what it can express
My suspicion is if that it were shown that Rust could statically check all usages of RCU protocols, kernels developers would be JUMPING to learn and use Rust
But I think Rust doesn’t help there. The Rust way would be to introduce some other mechanism that’s probably not as finely tuned.
I read over this story and thread again - https://lobste.rs/s/eppfav/why_i_rewrote_my_rust_keyboard_firmware
As an aside, the top comment seems to be from a pretty experienced Rust programmer, who expresses an opinion that Rust penalizes RUNTIME behavior in favor of its “model” (async/await in this case):
That is basically what I mean by models vs dynamic reality.
The keyboard post also expresses something like this:
That is what has to happen in reality. And the author is very neutral and agnostic about which tool will be used to get there – it is very problem-focused rather than tool-focused.
Does it have some examples of where Rust’s type systems misrepresents reality?
Reading over it, I think it’s closer to “the type system made my life hard”, and when I used Zig, with a weaker type system, was a breath of fresh air.
Though there is some good humility at the end – it is possible that tradeoff can change over time, as the program evolves and is maintained by more people
Nonetheless I think this is similar to the issues that I suspect will result in continued clashes on the Rust for Linux project.
I haven’t seen that at all here, actually.
Hm I just noticed this sentence in the Wikipedia page:
“Observing the time sequence” certainly sounds “inherently dynamic” to me!
You are describing an implicit state machine, and the question is whether you can encode the valid state transitions in the type a way that is useful in Rust’s type system. In many cases like this you can.
This may still result in dynamic checks - but in those cases, the type will guide you to insert those checks, and the code will not compile without them.
There is a field called choreographic programming which goes much deeper into encoding this kind of stuff in types than what you can do in Rust, too, if you are interested in that kind of thing.
This issue came up again and I responded here - https://lobste.rs/s/yx57uf/is_linux_collapsing_under_its_own_weight#c_gvj8fk
(won’t reply again on this thread due to length)
You’re not alone as I understood it the same way as you. It almost felt to as the kind of discussion I’d hear in the corporate world.
New member of the dev team: “We could rewrite this like that and it would be so much better!”
Veteran of the dev team: “Yeah it could be better long term but you do understand that we have to keep releasing the product at a steady rate and while the old stuff is not perfect, it does work and it is what everyone here knows.”
You may not know this, but Rust for Linux is an experiment to see whether Rust would be a good fit for the kernel, and Linus Torvalds is quite supportive of it. Some senior maintainers who dislike Rust are not content to let the experiment simply run its course, they are obstructing it.
But the actual situation is that Rust is proposed to be used in new drivers, not rewriting tons of stuff. And the veterans are not being respectful and thoughtful about how they respond, they are being caustic shitheads.
Wouldn’t that be part of the experiment though? In grade school we might say: “my hypothesis is that not everyone will love rust and welcome it with open arms”.
How are they supposed to test if it will work well if some maintainers simply block all work? Linus said that writing an fs module in Rust would be a great test for Rust in Linux. When Rust people ask for stuff from the fs people, stuff that they’d need even if they were writing C, like “what is the correct way to use this interface?”, the maintainers get caustic and go on rants about how the Rust people are pushing a religion.
It’s completely fucking unhinged.
It’s the same rhetoric, the same vibe. Instead of screaming ‘they are shoving GENDER IDEOLOGY down our throat’ they are screaming ‘they are shoving the religion of SUBSTRUCTURAL TYPE SYSTEMS down our throat’.