4 ms·

So one should not rewrite programs out of some form of respect for the original author's language choice? That doesn't sound reasonable. It is actually worse:

by bborud 5y ago

So one should not rewrite programs out of some form of respect for the original author's language choice? That doesn't sound reasonable. It is actually worse: it sounds like a socially unsound approach. It would be really nice to be able to rewrite the Linux kernel in something that is better suited to writing reliable low level software than C. That's not very controversial. The problem is that there hasn't been many clear candidates for this. For that investment to pay off the language you rewrite it in has to be sufficiently better than C in ways meaningful to the project to make the investment worth it. I think it is very good that people do these experiments. And even though I am not a Rust developer, I really want people to explore Rust as an alternative low level language for writing operating systems. Including Linux. Part of this comes from having worked off and on with embedded code for the past few years. The state of much embedded code is just awful. And it is clear that languages that offer more safeguards are desperately needed.

lionkor 5y ago
Rewrites are a misguided idea. You cannot rewrite a project this big, almost at all. My favorite example of how difficult rewrites are is the Rust rewrite of the GNU coreutils. A project since 2014, usable, but nowhere close to the completeness of the original. It's way, way, harder than you'd think to rewrite mature software (especially software that is heavily tested).
- kaba0 5y ago
  I generally agree with you, but at the other hand, linux ecosystem is held back a lot by this everything C mentality. Like, ripgrep, a grep clone written in rust with proper parallelism runs loops around the C version. Rewrites of smallish mature software is hard more because of reliance on backwards compatibility — for such long-living programs, even certain bugs/strange behaviors are part of their specification.
  - bborud 5y ago
    (this is a slightly different discussion since I think most people who work on the Linux kernel see it as something entirely separate from the userspace. It isn't a given that the kernel must absolutely be the same language as the userspace or vice versa) I think it might be a good idea to examine whether there is indeed such a mentality. I suspect that much of this comes down to "tradition" (whatever that is) and convenience. In particular, what it takes to set up a build environment for the tools in userspace, and to package and distribute them. For instance, how many people care that Docker and Kubernetes is written in Go? Does it have any practical consequence for the user? Would people notice if, say, Ubuntu were to distribute a `grep` that was written in Rust? Or better yet: if unixen were to adopt a replacement for grep that can be trusted to behave in a defined manner? As for backwards compatibility, well, that ship has kind of sailed since you can't really trust utilities to behave the same way across systems and configurations. For instance if you change locale on machines things may start to behave differently. ("Back in the day", we used to lean quite heavily on "sort", "uniq" and "grep" and a few other utilities in a system that essentially was a hilbilly, shellscript version of map-reduce, and quickly found that these do not behave identically across UNIXen - or even across the exact same version of the same distribution if someone has messed with the locale. So we wrote our own versions of all of these small utilities and made them militantly ignorant of their surroundings. If I learned something from this exercise it is that any promises of "compatibility" are highly dubious and the design of these utilities isn't always so good that one wouldn't be served better by perhaps augmenting the menagerie of utilities with ones that have properly defined, and sensible, behaviors)
- bborud 5y ago
  If I think about it: most of my career has consisted of re-creating something that already exists. And the one constant is that there is never any lack of people who line up to tell me what a bad idea this is. They aren't always wrong. But they also are not always right. And when they aren't right interesting things tend to happen that sometimes involve important changes. Linux itself was a "misguided" project as Minix already existed for the low end and lots of UNIXen existed for the higher end. The exact same sentiments, plus a lot less charitable ones, were put forward back then. And I remember people thinking me silly for working for a web search company in the late 90s "because Altavista already exists". Rewrites are perhaps a misguided idea for people who are highly entrenched in a "worker" mentality. But there are other modes of thinking and working. There exist people with what one could call a "creator" mentality. But I would distill one point from your post that I think is important: the goal of re-creating Linux may not be the correct goal. But I think staying close to Linux has merit. Usability over fashion has proven to be a deciding factor for success as far as design goes. The rest is down to leadership and organizational skill.

by bborud 5y ago

lionkor 5y ago

Rewrites are a misguided idea. You cannot rewrite a project this big, almost at all. My favorite example of how difficult rewrites are is the Rust rewrite of the GNU coreutils. A project since 2014, usable, but nowhere close to the completeness of the original. It's way, way, harder than you'd think to rewrite mature software (especially software that is heavily tested).

kaba0 5y ago
I generally agree with you, but at the other hand, linux ecosystem is held back a lot by this everything C mentality. Like, ripgrep, a grep clone written in rust with proper parallelism runs loops around the C version. Rewrites of smallish mature software is hard more because of reliance on backwards compatibility — for such long-living programs, even certain bugs/strange behaviors are part of their specification.
- bborud 5y ago
  (this is a slightly different discussion since I think most people who work on the Linux kernel see it as something entirely separate from the userspace. It isn't a given that the kernel must absolutely be the same language as the userspace or vice versa) I think it might be a good idea to examine whether there is indeed such a mentality. I suspect that much of this comes down to "tradition" (whatever that is) and convenience. In particular, what it takes to set up a build environment for the tools in userspace, and to package and distribute them. For instance, how many people care that Docker and Kubernetes is written in Go? Does it have any practical consequence for the user? Would people notice if, say, Ubuntu were to distribute a `grep` that was written in Rust? Or better yet: if unixen were to adopt a replacement for grep that can be trusted to behave in a defined manner? As for backwards compatibility, well, that ship has kind of sailed since you can't really trust utilities to behave the same way across systems and configurations. For instance if you change locale on machines things may start to behave differently. ("Back in the day", we used to lean quite heavily on "sort", "uniq" and "grep" and a few other utilities in a system that essentially was a hilbilly, shellscript version of map-reduce, and quickly found that these do not behave identically across UNIXen - or even across the exact same version of the same distribution if someone has messed with the locale. So we wrote our own versions of all of these small utilities and made them militantly ignorant of their surroundings. If I learned something from this exercise it is that any promises of "compatibility" are highly dubious and the design of these utilities isn't always so good that one wouldn't be served better by perhaps augmenting the menagerie of utilities with ones that have properly defined, and sensible, behaviors)
bborud 5y ago
If I think about it: most of my career has consisted of re-creating something that already exists. And the one constant is that there is never any lack of people who line up to tell me what a bad idea this is. They aren't always wrong. But they also are not always right. And when they aren't right interesting things tend to happen that sometimes involve important changes. Linux itself was a "misguided" project as Minix already existed for the low end and lots of UNIXen existed for the higher end. The exact same sentiments, plus a lot less charitable ones, were put forward back then. And I remember people thinking me silly for working for a web search company in the late 90s "because Altavista already exists". Rewrites are perhaps a misguided idea for people who are highly entrenched in a "worker" mentality. But there are other modes of thinking and working. There exist people with what one could call a "creator" mentality. But I would distill one point from your post that I think is important: the goal of re-creating Linux may not be the correct goal. But I think staying close to Linux has merit. Usability over fashion has proven to be a deciding factor for success as far as design goes. The rest is down to leadership and organizational skill.