13 ms·

Slightly off-topic but since the author mentions it; I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of

Slightly off-topic but since the author mentions it; I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary. Since the kernel started, you can't begin to count the number of "better than C" languages that appeared. Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago? Zig, D, Ada, ... they all offer massive benefits over C. The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be". No regard for software that works great, the engineers that put time and effort into it to make it secure and fast, if its not Rust it must be broken. Im excited to see the linux kernel improve even further, no matter what it takes, but it does rub me the wrong way and makes me stop and think a little bit when one particular language is held on such a gigantic pedestal.

pjmlp 5y ago
C was already bad when it appeared, the only reason it won, was UNIX being made available for a symbolic price with source code. Had AT&T been allowed to take commercial advantage of UNIX, we would probably be coding OSes in PL/I, BLISS, Mesa, Modula-2, Ada or some offspring of them.
- laumars 5y ago
  I never understood how C took over the desktop space as well. Pascal was a way better language and already dominant for home computing back in the 80s. Then by the 90s everywhere was C and C++. I never quite understood how or why that happened.
  - jasode 5y ago
    >Pascal was a way better language and already dominant for home computing back in the 80s. Not sure what you mean there ("dominant"?) but in the 1980s, BASIC was the dominant language on home computers because that's what they included. Commodore VIC-20 & 64, Atari 400/800, Texas Instruments TI-99 TI-BASIC, and IBM home computers like the PC jr had IBM-BASIC which was licensed from Microsoft's GW-BASIC. Something like Turbo Pascal was only purchased by a minority of 1980s computer users. That's why 1980s home computer enthusiast magazines like Compute! published their code lists in BASIC: https://www.google.com/search?q=%22compute!%22+magazine+code+list&tbm=isch https://www.google.com/search?q=%22compute!%22+magazine+code... >I never understood how C took over the desktop space as well. I'm guessing it's because C Language was already popular on the commercial side because of UNIX implementations which spread into microcomputers. Microsoft dabbled in XENIX which was AT&T UNIX. In the 1980s when popular desktop programs such as DOS, Lotus-123, and WordPerfect migrated from pure assembly to <high_level_language> ... they all ended up choosing C instead of Pascal. Why did industry converge on C? Maybe because there were more C compilers for various platforms. (The portability and cross-platform angle.)
    - laumars 5y ago
      > Not sure what you mean there ("dominant"?) but in the 1980s, BASIC was the dominant language on home computers because that's what they included. That was late 70s / early 80s and the firmware was all assembly with most software being written in machine code because the speed of those BASIc interpreters left a lot to be desired. I’m talking later in the decade when operating systems became the norm. Early versions of Windows and Mac OS were written in Pascal.
      - jasode 5y ago
        >Early versions of Windows and Mac OS were written in Pascal. Windows 1.0 in 1985 was written in C Language and assembly. The x86 alternative os to MS-DOS such as Digital Research GEM was also written in C and assembly. The Windows 16-bit ABI did have Pascal-style calling-convention for the stack but the OS was not written in Pascal: https://en.wikipedia.org/wiki/X86_calling_conventions#pascal:~:text=them%20usually%20faster.-,pascal,removing%20them%20from%20the%20stack https://en.wikipedia.org/wiki/X86_calling_conventions#pascal....
        laumars 5y ago
        > The x86 alternative os to MS-DOS such as Digital Research GEM was also written in C and assembly. Minor nitpick from what you’ve posted above (I’m sure you know this and perhaps had a brain fart when you posted): GEM was DRs GUI so an alternative to Windows. Their DOS equivalent (in fact the predecessor to DOS technically speaking) was CP/M. I do take your larger point though and thank you for the links. It was very informative. However that example aside, it’s still worth noting that Pascal was a popular language that fell out of favour in the 90s as C its derivatives swept through the industry. Now it seems uncool to have ALGOL-like syntax with languages either opting for C-braces or being whitespace driven like Python. And I see that as a loss in terms of readability. I’m probably just sound old now though — moaning about “the good old days” lol
  - pjmlp 5y ago
    Not in what concerned 16 bit platforms, at least in Europe. Turbo Pascal, and compilers for Basic dialects were everywhere. On Amiga, most stuff was being done in Assembly, Modula-2, AMOS, and yes if you bought the Commodore SDK, there was a C compiler. Mac OS was written in Object Pascal, and eventually moved into C++ with MPW and Symantec PowerPlant around 1992. On OS/2 we had Smalltalk and C++ with CSet++, on Windows Delphi (TPW still managed an appearance on Windows 3.1), VB, C++ with OWL, VCL, MFC. Even if the kernel for Windows and OS/2 was written in C, the upper layer was all about C++ with those SDKs, which meant using proper strings, vectors and collection classes with bounds checking was already quite an improvement anyway. C and UNIX only took new wind into their sails thanks to the GNU Manifesto that all FOSS software should be written in C.
    - laumars 5y ago
      OS/2 and NT weren’t really seen on home systems. I’m sure Pascal was much more widespread than your post suggests though. I’m sure I read somewhere that early Windows (as well as Lisa) was written in Pascal. And I do remember Pascal compilers for the Atari ST too. I’d be amazed if there wasn’t one for the Amiga. But even just going back to DOS, Turbo Pascal was a real game changer for me.
dataflow 5y ago
I actually feel like Rust makes more sense for a kernel than user mode-apps. If there's any software that you want provable safety guarantees on, it's the kernel. What bothers me is the indiscriminate push to rewrite any and all user-mode apps in Rust. That one feels far less necessary to me in general, though there are exceptions obviously.
- lionkor 5y ago
  Wow, yeah, good point. Rewrites in general are usually a terrible idea, unless the original is horribly broken (and beyond fixable). If you wrote your app in C++, instead of rewriting it for the next decade in Rust just to get to the same point, slap some AddressSanitizer, ThreadSanitizer, -fanalyzer, cppcheck, etc. on it. You will get 98% of the way there. Instead of spending 8+ years(!) rewriting[1] the GNU coreutils in Rust, you could spend half that time to ensure full coverage (branch-coverage, condition-coverage) in the existing ones. I will actually have a breakdown if someone tries to rewrite SQLite in Rust[2]. 1: https://github.com/uutils/coreutils https://github.com/uutils/coreutils 2: https://sqlite.org/testing.html https://sqlite.org/testing.html
  - moocowtruck 5y ago
    >If you wrote your app in C++, instead of rewriting it for the next decade in Rust just to get to the same point, slap some AddressSanitizer, ThreadSanitizer, -fanalyzer, cppcheck, etc. on it. You will get 98% of the way there. if that were true, why is chrome still looking at rust, because they use all those tools already
  - KptMarchewa 5y ago
    There are obviously different people doing this stuff than original GNU coreutils people. I'd be very wary to try to contribute anything to old GNU project like that, since despite having right licensing ideas, they attract the biggest assholes. This might be another reason why different people are doing rewrites. And sometimes, it turns out extremely well, like ripgrep.
    - 5y ago
deleted 5y ago
[deleted]
rhn_mk1 5y ago
The push to use a language comes from the mindshare, and Rust is more popular than Zig, D, or Ada. There does seem that some boundary was crossed: the attempt has decent manpower, and is being taken seriously. I also think you've gotten the wrong impression. "if its not written in Rust, it should be" is rather wrong, no one is suggesting to replace Python with Rust. Instead, there's a spirit of "if it's written in C, it should be replaced with Rust". Since a lot of free software is written in C, I can't blame you for generalizing.
- lionkor 5y ago
  I was too general there, that's true. It's mostly C and C++ applications, which to be fair make up most apps and OSs today.
pizza234 5y ago
> cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary There's no "strong" push; the RIIR narrative doesn't actually belong to the Rust community (which I've found very pragramatic), but it's so inherently inflammatory that the general public associated it to the Rust community nonetheless. What's actually happening is that some major projects are evaluating - slowly - whether Rust could be integrated in some areas. Besides the kernel, another high-profile project is QEMU. > Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago? Zig, D, Ada, ... they all offer massive benefits over C. Because of the "well-known value proposition" that Rust brings. I'm continuously mystified, now that unsafe memory management has been unambiguously shown to be the major factor in vulnerabilities, how safe memory management is still not recognized as the highest priority (which doesn't imply to rewrite in Rust/Golang/etc) by everybody.
- WJW 5y ago
  > I'm continuously mystified, now that unsafe memory management has been unambiguously shown to be the major factor in vulnerabilities, how safe memory management is still not recognized as the highest priority It is very straightforward to recognize the reason for this as soon as you realize that vulnerabilities themselves almost never have the highest priority either. Therefore, preventing them also can't have the highest priority.
- lionkor 5y ago
  I entirely agree that safe memory management is one of the most important topics today. I just wonder if our time would be better spent developing tools to formally verify memory safety of existing languages, instead of trying to "rewrite everything in Rust" to get safety. I see your point, though, and I was definitely being snarky for the sake of being snarky.
  - bawolff 5y ago
    People have been trying the formally verify things route for way longer than rust has been a thing.
rz2k 5y ago
I think it will matter where the model in C does not match the hardware in terms of CPU, cache, and auxiliary processors. Maybe the Rust developers will more quickly adjust to the assembly and machine language of chip developers. As an outsider, it sounds like C just tries to be a good enough assembly language to save people some time.
- lionkor 5y ago
  > C just tries to be a good enough assembly language Funnily enough, C was developed in order to rewrite an older kernel at the time (and thus create Unix)
  - hnlmorg 5y ago
    Kind of. Unix was originally written in assembly. B was then created to write some user land applications but it lacked some features that the PDP-11 supported and thus it was slow. Eventually as those features were added that language was re-invented as C. However it wasn't until Version 4 when the Unix kernel was rewritten in C. Which is still very early in Unix's time line but certainly after the creation of Unix.
rustnote 5y ago
People love writing Rust, if they want to try rewriting stuff why not? Might end up better might end up worse, can't hurt. I doubt it's out of spite for other languages, think it's just out of personal passion and curiosity.
- lionkor 5y ago
  Of course! I also write / rewrite / reinvent lots of things, for fun or out of curiosity. The issue with this topic specifically is that these rewrites are considered a solution to a plethora of extremely difficult problems (safety, etc.).
IshKebab 5y ago
> Zig, D, Ada, ... they all offer massive benefits over C. > The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be". Nonsense. Zig is even newer than Rust and still not ready. D pretty much required garbage collection. Ada probably would have been a decent option but it still doesn't solve heap memory safety like Rust does.
- nikbackm 5y ago
  Ada lacked platform support and free/open compilers compared to C as well.
  - deleted 5y ago
    [deleted]
  - touisteur 5y ago
    GNAT is based on gcc and is as such very portable. The kernel is gpl so no problem even using gnat gpl, right ? But even then gccada has been there for a long time. My guess about rust is more about mindshare and coming from a 'cool' company, and probably timing...
- johnisgood 5y ago
  > but it still doesn't solve heap memory safety like Rust does Care to elaborate on this? > Ada also prevents dangling references to objects on the stack or the heap, by providing automatic compile-time checking of "accessibility" levels, which reflect the lifetimes of stack and heap objects.[1] Or what are you referring to? [1] https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memory-Management-in-Ada-and-SPARK.pdf https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memo...
ajsnigrutin 5y ago
This is HN... every few days there is another post about "$old_software in $new_language_of_the_week", years go by, languages of the week change, from ruby, to go, to rust, to...., and the old, original software is still the only useful variant.
bawolff 5y ago
> Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago? Couldn't you always say this up until the time it happens? There always has to be a first success. E.g. pre unix you could ask, if high level languages are so great, why weren't they used instead of assembly a long time ago. > Zig, D, Ada, ... they all offer massive benefits over C. So does perl, there's more to the debate than if a language has some "benefit". Its all about costs and benefits. I think the way rust has positioned itself makes it a bit more palatable than those other languages in this domain. That doesn't neccesarily mean it will succeed, but it seems more in the right direction for that goal than some of its competitors.
- hnlmorg 5y ago
  You've dismissed his question without really answering it, which is a little unfair. The OP's question might be unpopular on HN (who largely seem to be in love with Rust) but it's a valid question and not one that's at odds with Rust either. To paraphrase his question: "Why is there more momentum behind Rust to replace C than there has been before?" > So does perl, there's more to the debate than if a language has some "benefit". It's pretty clear that Perl isn't a systems language nor performant enough to write a kernel even if it were a systems language. So bringing that up is rather silly. And you don't even answer the question of "what is more to the debate than "some benefit". Zig, D and Ada might all be perfectly valid languages to rewrite Linux in. So might OCaml and countless others. But it is Rust that has the momentum. As someone who can program in > dozen different languages, I too have found the momentum behind Rust a little unusual and I can't really put my finger on why it has proven so popular when others have, relatively speaking, failed. There are aspects of Rust that I like but I don't find it an order of magnitude better than Ada, OCaml nor Zig. So the question remains open, what has changed that all of a sudden the time is right to rewrite Linux? I wonder if a large part of Rust's success isn't down to the language per se but rather down to it emerging just as C++ was finally reaching that critical mass point where developers are fed up with it's complexity and ready to jump ship. With the other languages either peaking too early or simply lacking enough corporate sponsorship for the mainstream to adopt. Maybe the syntax has a part to play too where Rust looks more familiar to new C/C++ developers in a way that Ada and OCaml do not.
peter_retief 5y ago
forth? emacs? mumps?
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)
geon 5y ago
Rewriting/porting the Linux kernel would be a massive undertaking, and guaranteed to introduce new bugs. Not something you would do without massive benefits. Rust with its safety guarantees has those benefits in a way no other language does. While Zig enables writing safe code, it does not enforce it. D and C++ mainly improves productivity.
- johnisgood 5y ago
  > Rust with its safety guarantees has those benefits in a way no other language does. Excuse me? Do you know about Ada/SPARK? Rust is super far from Ada in terms of safety. I see misconceptions about Ada here all the time. Well, either that, or they do not know much about the language. Seriously, if you are interested in safety, you must check Ada/SPARK out.
  - brabel 5y ago
    I think you're right, but there's very little chance Ada/SPARK will ever become as popular as Rust because of politics. Rust managed, somehow, to get the backing of tech giants like Microsoft and Amazon... the fact it started at Mozilla, a well-regarded company with lots of influence in tech (despite its downwards trajectory in the browser wars) probably means more than any technical advantage Rust has over the competition (though I have to say Rust's type system and the borrow-checker are really inovative on their own and deserve the general praise they receive). If Ada/SPARK were to be successful, they would need this corporate backing. Maybe that's possible outside the USA? Say, the EU probably has enough influential tech companies and weight to push forward with a Rust competitor that's perhaps superior (as you claim, I don't know enough about SPARK yet to make that claim myself)? I think that would be extremely benefitial to both the tech world AND to Rust and Ada themselves... competition is a great way to make things evolve fast. EDIT: Ada/SPARK does seem to have a really good advantage over Rust: it's an actual specification, not just a single compiler implementation where "whatever the compiler does" is how the language behaves. This is very important in many industries. I know there's work ongoing to fix this for Rust, but that may take several years and even never amount to anything.
    - 5y ago
johnisgood 5y ago
Nothing can beat Ada when it comes to safety, and it has all the constructs in the language you want, and it has all the positives that you want. Heck, there is a reason for why Ada/SPARK is used for a lot of important projects, say, a cryptographic library. In any case, Ada would be the perfect choice, IMO.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
devit 5y ago
These languages, when used without garbage collection and with dynamic memory allocation, are not memory safe. Gaining memory safety at no cost is the whole point of rewriting in Rust, since it dramatically changes the behavior of the resulting program (it no longer has memory-related bugs and vulnerabilities). The other languages might have slight benefits over C, but they either also have drawbacks (with makes them unsuitable) or the benefits are not worth a rewrite.
lmm 5y ago
C was a terrible language from day 1. But cheap high-performance compilers were rare until fairly recently, and language ergonomics or expressiveness are hard to measure objectively, whereas "my language is faster on these unrepresentative microbenchmarks" is easy to measure. If unix culture had cared about safety or quality or really anything other than microbenchmarks and the feeling of superiority you get from doing something gratuitously difficult they'd have rewritten everything in OCaml back in the '90s, sure. But kernel developers love the macho culture of being a hardcore elite even more than regular developers, and once you've framed the question "how fast a language should we use?" it's very hard to answer anything other than "the fastest language possible". Rust is the first decent language that can match C on the silly microbenchmarks. D doesn't, Ada doesn't, and Zig is far less mature than Rust. That's the real reason it's succeeding where previous alternatives failed.
fiedzia 5y ago
> Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago? There are very few alternatives, and even fewer of them gained much popularity, so Rust is an exception here. Being better than C technically is not enough, you need something that other people want to use (and ideally already use). Kernel is more of a social than technical thing. > if its not Rust it must be broken That's simply true, especially for operating systems. The amount of safety bugs they have is staggering, even after decades of work, and Rust largely fixes that.
smoyer 5y ago
The kernel IMHO needs to be consistent and the tools to build it need to be widely available. Many distributions have everything you need to build the kernel already installed. I think Rust will be a good choice for the kernel when people start talking about Rust software with some new language "X".
gpderetta 5y ago
Linus hates C++ with a passion. Other than that there hasn't really been any other credible candidate. Rust is the only new language that appear to have enough momentum and community to be a candidate.
moltonel3x 5y ago
D and Ada both use a GC in many contexts, and are not half as interesting in their GC-less contexts. They both initially only had a proprietary compiler, which durably harmed adoption. They both seem to cater to fewer domains than C/C++/Rust. Today Ada is only used in high-stakes industry, and D doesn't seem to have any claim to fame. It's a pity that neither succeeded in their time, but there's no good reason to use either of them today. Zig is very promissing, but is just too new. You failed to mention C++. It's well loved (and hated), has many pros and cons compared to C, and is used for kernel development (just not Linux). It's silly to think that the only explanation for Rust success is community lobbying. Rust has many concrete advantages, like being safer than C/C++/D/Zig, being fully GC-free and suitable for kernel and embedded development, having actually gained significant traction, having great tooling/docs/ecosystem... And generally being a language that people enjoy. Rust isn't the end-game of kernel programming, but it isn't just "yet another better C".
- pjmlp 5y ago
  Ada doesn't use a GC! The only reason it isn't highly adopted was the high cost of its compilers, only SGI and Sun cared to have compilers on UNIX back in the day, and Microsoft, IBM and Apple rather doubled down on C++.
  - moltonel3x 5y ago
    Sorry, bad mischaracterisation on my part, annoyingly it's too late to edit my post. Looking at the Ada docs again, it considers manual deallocation an unsafe operation and suggests avoiding it altogether (IIUC, by restricting yourself to the stack or by leaking to the heap). That seems like a huge restriction, making the "Ada is safer than Rust" claims rather academic.
    - pjmlp 5y ago
      Indeed, when using Ada83 and ignoring all the later language standards. You should compare with Ada 2012 with finalization types and SPARK. Hardly any different than using unsafe on Rust's standard library, wrapped with safer constructs.
volta83 5y ago
> I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary. As a Linux kernel developer, I feel like non-kernel developers like yourself telling me which language I should use is definetly overstepping a boundary. I couldn't care less about what non-kernel-developers think about this issue, but "since you mention this": please do mind your own business. > Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago? Because we, as in the actual people that spend their whole day developing the Linux kernel *do not want* to write and maintain Linux kernel code written in these languages. > The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be". This is so wrong. We, Linux kernel developers, are already writing drivers and kernel modules in Rust, *because we want to*. We now want to merge this new code so that other devs and users can use it. Most other devs want this too, so now we added Rust support to the Linux tree. --- It really is that simple. My code, my body, my rules. I really don't know what's so hard for people to understand here.
- gens 5y ago
  May I ask what you developed in the kernel ?
  - volta83 5y ago
    Mostly I/O drivers for network and storage, and let's say "DMA-related" functionality. Anything more specific than would probably de-anonymize me.
    - gens 5y ago
      That's cool. I truly wish you all the best in your future :).
- theshadowknows 5y ago
  Who told you what language to write in?
- 5y ago
lawn 5y ago
> The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be". It could also be that Rust is just much better for the kernel use-case than the alternatives we've seen so far?
bregma 5y ago
The idiopathic priapism manifested by Rusties is pretty much identical to the enthusiasm every junior developers seems to show for rewriting everything. Toy examples, software that hasn't yet had contact with production, it's all just so easy. Then comes shifting and unclear requirements, change orders, prioritizations, schedules, resource constraints, career changes, cowboys and petty dictators, and next thing you know your mature C-based code mess is replaced with a less mature Rust-based code mess and the few technical edge cases it was designed to avoid haven't solved any of the big important problems in software development.
- shakow 5y ago
  According to your comment, there's reasonably no reason to replace our old asm/fortran codebases with better, more modern alternatives. Well, science goes forward one burial at a time, same goes for IT I guess.
  - bregma 5y ago
    Your equivalence of "newer" and "better" lacks substance.
    - shakow 5y ago
      Says the guy talking about “idiopathic priapism” when referring to a language's adepts.
- xvector 5y ago
  Writing secure C code is a fool's errand. The sheer volume of C code and the vulnerabilities therein is perhaps the biggest obstacle to computer security today. I don't care if it's Rust or some other language, but it has been clear for some time that C needs to go.
  - scoutt 5y ago
    I'm pretty sure that if you compare total "lines of code written in C/C++" or "projects written in C/C++" versus "vulnerabilities found" you'd be surprised of the (small) result. See. Not all code is "vulnerable", connected to the net or facing a user. But let's leave outside of the count every other project that is not a Triple-A videogame written in C/C++. That amount of projects alone probably would be larger than the quantity of "big" projects that would be written in Rust in the next 10 years. And they are not all "packed with vulnerabilities", or at least, nothing that's big enough to be read here on HN.
shakow 5y ago
> I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary. Assuming you're not a kernel developer, I don't understand why you need the feel to be offended in their stead, as they don't really seem to mind at all. > Zig, D, Ada (i) not yet stable; (ii) torn apart between two runtimes, not really GC-free; (iii) has a... complicated toolchain story, and basically didn't exist in a free/libre aspect on PC until very recently – and didn't/doesn't compile on 90% of Linux targets. > The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be". No, the only reason there is a push for Rust in the kernel is because people are interested enough to write the code to get Rust in the kernel. > it does rub me the wrong way and makes me stop and think a little bit when one particular language is held on such a gigantic pedestal. Maybe you should stop and think a little bit on why kernel developers, arguably among the most competent ones on this subject, put Rust on what you perceive as a ‶gigantic pedestal″.
cannabis_sam 5y ago
> No regard for software that works great, the engineers that put time and effort into it to make it secure and fast, if its not Rust it must be broken. I wasn’t aware that this was a widespread attitude in the rust community, my personal experience has been the exact opposite..
- colejohnson66 5y ago
  It’s probably a view driven by the fact that there’s a lot of “Show HN” that mention Rust, or are just pet projects to rewrite something in Rust. It can definitely give the appearance of “if it’s not Rust, it should be”
simias 5y ago
If it were some other open source project I could see where you're coming from, but if there's one community I do not expect to kowtow to language hype and zealotry it's the kernel devs. You know, the people who still coordinate their development through mailing lists and sending unified diffs around. I write a lot of C, some of it in the kernel (although I don't think any of my code made it upstream since I mostly do vendor code for vendors who don't care for mainlining, so I don't think I qualify as a true kernel dev). Out of the languages you mention I think only Zig could be a serious contender but it's probably way too novel and niche to be a serious contender at this point. D has a GC and is probably less popular than Rust nowadays, Ada uses garbage collection (or other forms of memory management that don't seem very suitable for kernel work AFAIK). But most importantly there seem to be people willing to actually write Rust code in the kernel and add support for it, whereas I don't see a very strong initiative to push Ada upstream...
raxxorrax 5y ago
I think Golang was put on a similar pedestal for a time and it got a lot more silent again. I really think it is a phase, but Google is also pushing for this. I talked about someone that it was mainly to have a better pipeline for new developers, but I don't yet see how that is the case.

pjmlp 5y ago

C was already bad when it appeared, the only reason it won, was UNIX being made available for a symbolic price with source code. Had AT&T been allowed to take commercial advantage of UNIX, we would probably be coding OSes in PL/I, BLISS, Mesa, Modula-2, Ada or some offspring of them.

laumars 5y ago
I never understood how C took over the desktop space as well. Pascal was a way better language and already dominant for home computing back in the 80s. Then by the 90s everywhere was C and C++. I never quite understood how or why that happened.
- jasode 5y ago
  >Pascal was a way better language and already dominant for home computing back in the 80s. Not sure what you mean there ("dominant"?) but in the 1980s, BASIC was the dominant language on home computers because that's what they included. Commodore VIC-20 & 64, Atari 400/800, Texas Instruments TI-99 TI-BASIC, and IBM home computers like the PC jr had IBM-BASIC which was licensed from Microsoft's GW-BASIC. Something like Turbo Pascal was only purchased by a minority of 1980s computer users. That's why 1980s home computer enthusiast magazines like Compute! published their code lists in BASIC: https://www.google.com/search?q=%22compute!%22+magazine+code+list&tbm=isch https://www.google.com/search?q=%22compute!%22+magazine+code... >I never understood how C took over the desktop space as well. I'm guessing it's because C Language was already popular on the commercial side because of UNIX implementations which spread into microcomputers. Microsoft dabbled in XENIX which was AT&T UNIX. In the 1980s when popular desktop programs such as DOS, Lotus-123, and WordPerfect migrated from pure assembly to <high_level_language> ... they all ended up choosing C instead of Pascal. Why did industry converge on C? Maybe because there were more C compilers for various platforms. (The portability and cross-platform angle.)
  - laumars 5y ago
    > Not sure what you mean there ("dominant"?) but in the 1980s, BASIC was the dominant language on home computers because that's what they included. That was late 70s / early 80s and the firmware was all assembly with most software being written in machine code because the speed of those BASIc interpreters left a lot to be desired. I’m talking later in the decade when operating systems became the norm. Early versions of Windows and Mac OS were written in Pascal.
    - jasode 5y ago
      >Early versions of Windows and Mac OS were written in Pascal. Windows 1.0 in 1985 was written in C Language and assembly. The x86 alternative os to MS-DOS such as Digital Research GEM was also written in C and assembly. The Windows 16-bit ABI did have Pascal-style calling-convention for the stack but the OS was not written in Pascal: https://en.wikipedia.org/wiki/X86_calling_conventions#pascal:~:text=them%20usually%20faster.-,pascal,removing%20them%20from%20the%20stack https://en.wikipedia.org/wiki/X86_calling_conventions#pascal....
      - laumars 5y ago
        > The x86 alternative os to MS-DOS such as Digital Research GEM was also written in C and assembly. Minor nitpick from what you’ve posted above (I’m sure you know this and perhaps had a brain fart when you posted): GEM was DRs GUI so an alternative to Windows. Their DOS equivalent (in fact the predecessor to DOS technically speaking) was CP/M. I do take your larger point though and thank you for the links. It was very informative. However that example aside, it’s still worth noting that Pascal was a popular language that fell out of favour in the 90s as C its derivatives swept through the industry. Now it seems uncool to have ALGOL-like syntax with languages either opting for C-braces or being whitespace driven like Python. And I see that as a loss in terms of readability. I’m probably just sound old now though — moaning about “the good old days” lol
- pjmlp 5y ago
  Not in what concerned 16 bit platforms, at least in Europe. Turbo Pascal, and compilers for Basic dialects were everywhere. On Amiga, most stuff was being done in Assembly, Modula-2, AMOS, and yes if you bought the Commodore SDK, there was a C compiler. Mac OS was written in Object Pascal, and eventually moved into C++ with MPW and Symantec PowerPlant around 1992. On OS/2 we had Smalltalk and C++ with CSet++, on Windows Delphi (TPW still managed an appearance on Windows 3.1), VB, C++ with OWL, VCL, MFC. Even if the kernel for Windows and OS/2 was written in C, the upper layer was all about C++ with those SDKs, which meant using proper strings, vectors and collection classes with bounds checking was already quite an improvement anyway. C and UNIX only took new wind into their sails thanks to the GNU Manifesto that all FOSS software should be written in C.
  - laumars 5y ago
    OS/2 and NT weren’t really seen on home systems. I’m sure Pascal was much more widespread than your post suggests though. I’m sure I read somewhere that early Windows (as well as Lisa) was written in Pascal. And I do remember Pascal compilers for the Atari ST too. I’d be amazed if there wasn’t one for the Amiga. But even just going back to DOS, Turbo Pascal was a real game changer for me.

dataflow 5y ago

I actually feel like Rust makes more sense for a kernel than user mode-apps. If there's any software that you want provable safety guarantees on, it's the kernel. What bothers me is the indiscriminate push to rewrite any and all user-mode apps in Rust. That one feels far less necessary to me in general, though there are exceptions obviously.

lionkor 5y ago
Wow, yeah, good point. Rewrites in general are usually a terrible idea, unless the original is horribly broken (and beyond fixable). If you wrote your app in C++, instead of rewriting it for the next decade in Rust just to get to the same point, slap some AddressSanitizer, ThreadSanitizer, -fanalyzer, cppcheck, etc. on it. You will get 98% of the way there. Instead of spending 8+ years(!) rewriting[1] the GNU coreutils in Rust, you could spend half that time to ensure full coverage (branch-coverage, condition-coverage) in the existing ones. I will actually have a breakdown if someone tries to rewrite SQLite in Rust[2]. 1: https://github.com/uutils/coreutils https://github.com/uutils/coreutils 2: https://sqlite.org/testing.html https://sqlite.org/testing.html
- moocowtruck 5y ago
  >If you wrote your app in C++, instead of rewriting it for the next decade in Rust just to get to the same point, slap some AddressSanitizer, ThreadSanitizer, -fanalyzer, cppcheck, etc. on it. You will get 98% of the way there. if that were true, why is chrome still looking at rust, because they use all those tools already
- KptMarchewa 5y ago
  There are obviously different people doing this stuff than original GNU coreutils people. I'd be very wary to try to contribute anything to old GNU project like that, since despite having right licensing ideas, they attract the biggest assholes. This might be another reason why different people are doing rewrites. And sometimes, it turns out extremely well, like ripgrep.
  - 5y ago

deleted 5y ago

[deleted]

rhn_mk1 5y ago

The push to use a language comes from the mindshare, and Rust is more popular than Zig, D, or Ada. There does seem that some boundary was crossed: the attempt has decent manpower, and is being taken seriously. I also think you've gotten the wrong impression. "if its not written in Rust, it should be" is rather wrong, no one is suggesting to replace Python with Rust. Instead, there's a spirit of "if it's written in C, it should be replaced with Rust". Since a lot of free software is written in C, I can't blame you for generalizing.

lionkor 5y ago
I was too general there, that's true. It's mostly C and C++ applications, which to be fair make up most apps and OSs today.

pizza234 5y ago

> cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary There's no "strong" push; the RIIR narrative doesn't actually belong to the Rust community (which I've found very pragramatic), but it's so inherently inflammatory that the general public associated it to the Rust community nonetheless. What's actually happening is that some major projects are evaluating - slowly - whether Rust could be integrated in some areas. Besides the kernel, another high-profile project is QEMU. > Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago? Zig, D, Ada, ... they all offer massive benefits over C. Because of the "well-known value proposition" that Rust brings. I'm continuously mystified, now that unsafe memory management has been unambiguously shown to be the major factor in vulnerabilities, how safe memory management is still not recognized as the highest priority (which doesn't imply to rewrite in Rust/Golang/etc) by everybody.

WJW 5y ago
> I'm continuously mystified, now that unsafe memory management has been unambiguously shown to be the major factor in vulnerabilities, how safe memory management is still not recognized as the highest priority It is very straightforward to recognize the reason for this as soon as you realize that vulnerabilities themselves almost never have the highest priority either. Therefore, preventing them also can't have the highest priority.
lionkor 5y ago
I entirely agree that safe memory management is one of the most important topics today. I just wonder if our time would be better spent developing tools to formally verify memory safety of existing languages, instead of trying to "rewrite everything in Rust" to get safety. I see your point, though, and I was definitely being snarky for the sake of being snarky.
- bawolff 5y ago
  People have been trying the formally verify things route for way longer than rust has been a thing.

rz2k 5y ago

I think it will matter where the model in C does not match the hardware in terms of CPU, cache, and auxiliary processors. Maybe the Rust developers will more quickly adjust to the assembly and machine language of chip developers. As an outsider, it sounds like C just tries to be a good enough assembly language to save people some time.

lionkor 5y ago
> C just tries to be a good enough assembly language Funnily enough, C was developed in order to rewrite an older kernel at the time (and thus create Unix)
- hnlmorg 5y ago
  Kind of. Unix was originally written in assembly. B was then created to write some user land applications but it lacked some features that the PDP-11 supported and thus it was slow. Eventually as those features were added that language was re-invented as C. However it wasn't until Version 4 when the Unix kernel was rewritten in C. Which is still very early in Unix's time line but certainly after the creation of Unix.

rustnote 5y ago

People love writing Rust, if they want to try rewriting stuff why not? Might end up better might end up worse, can't hurt. I doubt it's out of spite for other languages, think it's just out of personal passion and curiosity.

lionkor 5y ago
Of course! I also write / rewrite / reinvent lots of things, for fun or out of curiosity. The issue with this topic specifically is that these rewrites are considered a solution to a plethora of extremely difficult problems (safety, etc.).

IshKebab 5y ago

> Zig, D, Ada, ... they all offer massive benefits over C. > The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be". Nonsense. Zig is even newer than Rust and still not ready. D pretty much required garbage collection. Ada probably would have been a decent option but it still doesn't solve heap memory safety like Rust does.

nikbackm 5y ago
Ada lacked platform support and free/open compilers compared to C as well.
- deleted 5y ago
  [deleted]
- touisteur 5y ago
  GNAT is based on gcc and is as such very portable. The kernel is gpl so no problem even using gnat gpl, right ? But even then gccada has been there for a long time. My guess about rust is more about mindshare and coming from a 'cool' company, and probably timing...
johnisgood 5y ago
> but it still doesn't solve heap memory safety like Rust does Care to elaborate on this? > Ada also prevents dangling references to objects on the stack or the heap, by providing automatic compile-time checking of "accessibility" levels, which reflect the lifetimes of stack and heap objects.[1] Or what are you referring to? [1] https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memory-Management-in-Ada-and-SPARK.pdf https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memo...

ajsnigrutin 5y ago

This is HN... every few days there is another post about "$old_software in $new_language_of_the_week", years go by, languages of the week change, from ruby, to go, to rust, to...., and the old, original software is still the only useful variant.

bawolff 5y ago

> Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago? Couldn't you always say this up until the time it happens? There always has to be a first success. E.g. pre unix you could ask, if high level languages are so great, why weren't they used instead of assembly a long time ago. > Zig, D, Ada, ... they all offer massive benefits over C. So does perl, there's more to the debate than if a language has some "benefit". Its all about costs and benefits. I think the way rust has positioned itself makes it a bit more palatable than those other languages in this domain. That doesn't neccesarily mean it will succeed, but it seems more in the right direction for that goal than some of its competitors.

hnlmorg 5y ago
You've dismissed his question without really answering it, which is a little unfair. The OP's question might be unpopular on HN (who largely seem to be in love with Rust) but it's a valid question and not one that's at odds with Rust either. To paraphrase his question: "Why is there more momentum behind Rust to replace C than there has been before?" > So does perl, there's more to the debate than if a language has some "benefit". It's pretty clear that Perl isn't a systems language nor performant enough to write a kernel even if it were a systems language. So bringing that up is rather silly. And you don't even answer the question of "what is more to the debate than "some benefit". Zig, D and Ada might all be perfectly valid languages to rewrite Linux in. So might OCaml and countless others. But it is Rust that has the momentum. As someone who can program in > dozen different languages, I too have found the momentum behind Rust a little unusual and I can't really put my finger on why it has proven so popular when others have, relatively speaking, failed. There are aspects of Rust that I like but I don't find it an order of magnitude better than Ada, OCaml nor Zig. So the question remains open, what has changed that all of a sudden the time is right to rewrite Linux? I wonder if a large part of Rust's success isn't down to the language per se but rather down to it emerging just as C++ was finally reaching that critical mass point where developers are fed up with it's complexity and ready to jump ship. With the other languages either peaking too early or simply lacking enough corporate sponsorship for the mainstream to adopt. Maybe the syntax has a part to play too where Rust looks more familiar to new C/C++ developers in a way that Ada and OCaml do not.

peter_retief 5y ago

forth? emacs? mumps?

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)

geon 5y ago

Rewriting/porting the Linux kernel would be a massive undertaking, and guaranteed to introduce new bugs. Not something you would do without massive benefits. Rust with its safety guarantees has those benefits in a way no other language does. While Zig enables writing safe code, it does not enforce it. D and C++ mainly improves productivity.

johnisgood 5y ago
> Rust with its safety guarantees has those benefits in a way no other language does. Excuse me? Do you know about Ada/SPARK? Rust is super far from Ada in terms of safety. I see misconceptions about Ada here all the time. Well, either that, or they do not know much about the language. Seriously, if you are interested in safety, you must check Ada/SPARK out.
- brabel 5y ago
  I think you're right, but there's very little chance Ada/SPARK will ever become as popular as Rust because of politics. Rust managed, somehow, to get the backing of tech giants like Microsoft and Amazon... the fact it started at Mozilla, a well-regarded company with lots of influence in tech (despite its downwards trajectory in the browser wars) probably means more than any technical advantage Rust has over the competition (though I have to say Rust's type system and the borrow-checker are really inovative on their own and deserve the general praise they receive). If Ada/SPARK were to be successful, they would need this corporate backing. Maybe that's possible outside the USA? Say, the EU probably has enough influential tech companies and weight to push forward with a Rust competitor that's perhaps superior (as you claim, I don't know enough about SPARK yet to make that claim myself)? I think that would be extremely benefitial to both the tech world AND to Rust and Ada themselves... competition is a great way to make things evolve fast. EDIT: Ada/SPARK does seem to have a really good advantage over Rust: it's an actual specification, not just a single compiler implementation where "whatever the compiler does" is how the language behaves. This is very important in many industries. I know there's work ongoing to fix this for Rust, but that may take several years and even never amount to anything.
  - 5y ago

johnisgood 5y ago

Nothing can beat Ada when it comes to safety, and it has all the constructs in the language you want, and it has all the positives that you want. Heck, there is a reason for why Ada/SPARK is used for a lot of important projects, say, a cryptographic library. In any case, Ada would be the perfect choice, IMO.

deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

devit 5y ago

These languages, when used without garbage collection and with dynamic memory allocation, are not memory safe. Gaining memory safety at no cost is the whole point of rewriting in Rust, since it dramatically changes the behavior of the resulting program (it no longer has memory-related bugs and vulnerabilities). The other languages might have slight benefits over C, but they either also have drawbacks (with makes them unsuitable) or the benefits are not worth a rewrite.

lmm 5y ago

C was a terrible language from day 1. But cheap high-performance compilers were rare until fairly recently, and language ergonomics or expressiveness are hard to measure objectively, whereas "my language is faster on these unrepresentative microbenchmarks" is easy to measure. If unix culture had cared about safety or quality or really anything other than microbenchmarks and the feeling of superiority you get from doing something gratuitously difficult they'd have rewritten everything in OCaml back in the '90s, sure. But kernel developers love the macho culture of being a hardcore elite even more than regular developers, and once you've framed the question "how fast a language should we use?" it's very hard to answer anything other than "the fastest language possible". Rust is the first decent language that can match C on the silly microbenchmarks. D doesn't, Ada doesn't, and Zig is far less mature than Rust. That's the real reason it's succeeding where previous alternatives failed.

fiedzia 5y ago

> Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago? There are very few alternatives, and even fewer of them gained much popularity, so Rust is an exception here. Being better than C technically is not enough, you need something that other people want to use (and ideally already use). Kernel is more of a social than technical thing. > if its not Rust it must be broken That's simply true, especially for operating systems. The amount of safety bugs they have is staggering, even after decades of work, and Rust largely fixes that.

smoyer 5y ago

The kernel IMHO needs to be consistent and the tools to build it need to be widely available. Many distributions have everything you need to build the kernel already installed. I think Rust will be a good choice for the kernel when people start talking about Rust software with some new language "X".

gpderetta 5y ago

Linus hates C++ with a passion. Other than that there hasn't really been any other credible candidate. Rust is the only new language that appear to have enough momentum and community to be a candidate.

moltonel3x 5y ago

D and Ada both use a GC in many contexts, and are not half as interesting in their GC-less contexts. They both initially only had a proprietary compiler, which durably harmed adoption. They both seem to cater to fewer domains than C/C++/Rust. Today Ada is only used in high-stakes industry, and D doesn't seem to have any claim to fame. It's a pity that neither succeeded in their time, but there's no good reason to use either of them today. Zig is very promissing, but is just too new. You failed to mention C++. It's well loved (and hated), has many pros and cons compared to C, and is used for kernel development (just not Linux). It's silly to think that the only explanation for Rust success is community lobbying. Rust has many concrete advantages, like being safer than C/C++/D/Zig, being fully GC-free and suitable for kernel and embedded development, having actually gained significant traction, having great tooling/docs/ecosystem... And generally being a language that people enjoy. Rust isn't the end-game of kernel programming, but it isn't just "yet another better C".

pjmlp 5y ago
Ada doesn't use a GC! The only reason it isn't highly adopted was the high cost of its compilers, only SGI and Sun cared to have compilers on UNIX back in the day, and Microsoft, IBM and Apple rather doubled down on C++.
- moltonel3x 5y ago
  Sorry, bad mischaracterisation on my part, annoyingly it's too late to edit my post. Looking at the Ada docs again, it considers manual deallocation an unsafe operation and suggests avoiding it altogether (IIUC, by restricting yourself to the stack or by leaking to the heap). That seems like a huge restriction, making the "Ada is safer than Rust" claims rather academic.
  - pjmlp 5y ago
    Indeed, when using Ada83 and ignoring all the later language standards. You should compare with Ada 2012 with finalization types and SPARK. Hardly any different than using unsafe on Rust's standard library, wrapped with safer constructs.

volta83 5y ago

> I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary. As a Linux kernel developer, I feel like non-kernel developers like yourself telling me which language I should use is definetly overstepping a boundary. I couldn't care less about what non-kernel-developers think about this issue, but "since you mention this": please do mind your own business. > Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago? Because we, as in the actual people that spend their whole day developing the Linux kernel *do not want* to write and maintain Linux kernel code written in these languages. > The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be". This is so wrong. We, Linux kernel developers, are already writing drivers and kernel modules in Rust, *because we want to*. We now want to merge this new code so that other devs and users can use it. Most other devs want this too, so now we added Rust support to the Linux tree. --- It really is that simple. My code, my body, my rules. I really don't know what's so hard for people to understand here.

gens 5y ago
May I ask what you developed in the kernel ?
- volta83 5y ago
  Mostly I/O drivers for network and storage, and let's say "DMA-related" functionality. Anything more specific than would probably de-anonymize me.
  - gens 5y ago
    That's cool. I truly wish you all the best in your future :).
theshadowknows 5y ago
Who told you what language to write in?
5y ago

lawn 5y ago

> The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be". It could also be that Rust is just much better for the kernel use-case than the alternatives we've seen so far?

bregma 5y ago

The idiopathic priapism manifested by Rusties is pretty much identical to the enthusiasm every junior developers seems to show for rewriting everything. Toy examples, software that hasn't yet had contact with production, it's all just so easy. Then comes shifting and unclear requirements, change orders, prioritizations, schedules, resource constraints, career changes, cowboys and petty dictators, and next thing you know your mature C-based code mess is replaced with a less mature Rust-based code mess and the few technical edge cases it was designed to avoid haven't solved any of the big important problems in software development.

shakow 5y ago
According to your comment, there's reasonably no reason to replace our old asm/fortran codebases with better, more modern alternatives. Well, science goes forward one burial at a time, same goes for IT I guess.
- bregma 5y ago
  Your equivalence of "newer" and "better" lacks substance.
  - shakow 5y ago
    Says the guy talking about “idiopathic priapism” when referring to a language's adepts.
xvector 5y ago
Writing secure C code is a fool's errand. The sheer volume of C code and the vulnerabilities therein is perhaps the biggest obstacle to computer security today. I don't care if it's Rust or some other language, but it has been clear for some time that C needs to go.
- scoutt 5y ago
  I'm pretty sure that if you compare total "lines of code written in C/C++" or "projects written in C/C++" versus "vulnerabilities found" you'd be surprised of the (small) result. See. Not all code is "vulnerable", connected to the net or facing a user. But let's leave outside of the count every other project that is not a Triple-A videogame written in C/C++. That amount of projects alone probably would be larger than the quantity of "big" projects that would be written in Rust in the next 10 years. And they are not all "packed with vulnerabilities", or at least, nothing that's big enough to be read here on HN.

shakow 5y ago

> I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary. Assuming you're not a kernel developer, I don't understand why you need the feel to be offended in their stead, as they don't really seem to mind at all. > Zig, D, Ada (i) not yet stable; (ii) torn apart between two runtimes, not really GC-free; (iii) has a... complicated toolchain story, and basically didn't exist in a free/libre aspect on PC until very recently – and didn't/doesn't compile on 90% of Linux targets. > The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be". No, the only reason there is a push for Rust in the kernel is because people are interested enough to write the code to get Rust in the kernel. > it does rub me the wrong way and makes me stop and think a little bit when one particular language is held on such a gigantic pedestal. Maybe you should stop and think a little bit on why kernel developers, arguably among the most competent ones on this subject, put Rust on what you perceive as a ‶gigantic pedestal″.

cannabis_sam 5y ago

> No regard for software that works great, the engineers that put time and effort into it to make it secure and fast, if its not Rust it must be broken. I wasn’t aware that this was a widespread attitude in the rust community, my personal experience has been the exact opposite..

colejohnson66 5y ago
It’s probably a view driven by the fact that there’s a lot of “Show HN” that mention Rust, or are just pet projects to rewrite something in Rust. It can definitely give the appearance of “if it’s not Rust, it should be”

simias 5y ago

If it were some other open source project I could see where you're coming from, but if there's one community I do not expect to kowtow to language hype and zealotry it's the kernel devs. You know, the people who still coordinate their development through mailing lists and sending unified diffs around. I write a lot of C, some of it in the kernel (although I don't think any of my code made it upstream since I mostly do vendor code for vendors who don't care for mainlining, so I don't think I qualify as a true kernel dev). Out of the languages you mention I think only Zig could be a serious contender but it's probably way too novel and niche to be a serious contender at this point. D has a GC and is probably less popular than Rust nowadays, Ada uses garbage collection (or other forms of memory management that don't seem very suitable for kernel work AFAIK). But most importantly there seem to be people willing to actually write Rust code in the kernel and add support for it, whereas I don't see a very strong initiative to push Ada upstream...

raxxorrax 5y ago

I think Golang was put on a similar pedestal for a time and it got a lot more silent again. I really think it is a phase, but Google is also pushing for this. I talked about someone that it was mainly to have a better pipeline for new developers, but I don't yet see how that is the case.