16 ms·
It’s truly the only low-level language that could actually be used for systems programming. C#, Java? Managed code with JITs, not supported on a kernel level n
by gjsman-1000 5y ago
It’s truly the only low-level language that could actually be used for systems programming.
C#, Java? Managed code with JITs, not supported on a kernel level no-way no-how. Ditto for Python, PHP, JavaScript, and other high-level languages without pointers and all that jazz.
Go would be close… but it requires bundling a bunch of libraries in with each binary and wasn’t designed for low-level development. Again unsuitable.
C++? Linus Torvalds and the kernel developers hate it for being unnecessarily complicated and only making things harder to maintain while bringing little to the table at this point (they’ve made it this far without classes, and C++ doesn’t bring anything new like memory safety).
- vips7L 5y agoD and Zig could work.
- gjsman-1000 5y agoNobody really proposed these in earnest. Also, it’s a kernel, where diversity of programming languages is a nightmare. It’s not the kernel’s job to support every language people want - it’s just that Rust has enough going for it that it’s finally being considered worthwhile after years of investigation.
- infogulch 5y agoInsofar as they don't bundle a runtime (unlike the languages mentioned by GP), yes. But they don't really offer much above C in the area of resource tracking / safety that rust's novel ownership+lifetimes system provides.
- floatboth 5y agoHeh, there were plans to add ownership&borrowing to D: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... but of course bolting something on as an option is not the same as having the whole language designed strictly around it.
- dralley 5y agoI would say "defer" and "errdefer" do offer a lot compared to C, but you're right that it's not comparable with the resource tracking in Rust.
- loeg 5y agoZig isn’t substantially older than Rust, and is arguably less compelling. Certainly fewer resources backing an attempt at use as a 2nd kernel language. D I think suffered from a proprietary compiler and wide use of GC. But I’m not really familiar with it.
- sanxiyn 5y agoD is upstream in GCC since 2019, so it is actually superior to Rust in that respect. Days of proprietary D compiler is long past.
- nicoburns 5y agoZig is actually quite a bit younger than Rust. The first release of Zig predates the 1.0 release of Rust by a few months, but that was also a pre-release version. The earliest versions of Rust predate Zig by around 4 years.
- badsectoracula 5y agoFree Pascal too. An example would be Ultibo[0] which, despite the completely awful site (in terms of learning what it is - it feels like a developer's cynical overjaded idea of how a modern site that tries to market something is supposed to look like), is an OS for Rasberry Pi written in Free Pascal. It is meant to be used as a base for purpose-built projects instead of a general purpose OS, but it does show that it is possible to make one using the language (it already supports pretty much all "standard" features like networking, threads, 2d/3d graphics, a few filesystems, etc). Of course it doesn't make much sense to use it in the Linux kernel but it is a low level (or low level capable) programming language that can be used for systems programming. [0] https://ultibo.org/ https://ultibo.org/
- retrac 5y agoAs an historical note, Pascal was very popular in the late 70s and 80s for systems programming. The entire Apple Lisa/Macintosh platform started out in Pascal, for example. The limits of Pascal led Apple to team up with Wirth and develop Object Pascal, which is basically the language Free Pascal implements now. The gap between Pascal with a couple extensions and C, or between Object Pascal and Objective-C, is very small, anyway. Most semantic elements have a one-to-one correspondence. There were even UNIX clones written in Pascal.
- Tozen 5y agoVery true. Many people don't realize how Pascal evolved into Object Pascal, and how it's such a strong alternative to C++, C#, Objective-C, Java, etc...
- johnisgood 5y ago> It’s truly the only low-level language that could actually be used for systems programming. No it is not. There is Ada/SPARK and has been for a long time, and it is for critical systems. I recommend checking out https://blog.adacore.com/ https://blog.adacore.com/ for examples, there is plenty of that. For one: "An Embedded USB Device stack in Ada". There are also many articles about SPARK. For example: "Enhancing the Security of a TCP Stack with SPARK". These are just one of the recent articles.
- fnord77 5y agodoes Ada have a big enough user base for there to be people around to do kernel work? People seem to love Rust. I've never seen that kind of enthusiasm for Ada.
- johnisgood 5y agoI know. That is one of the major issues: lack of hype. Most Rust enthusiasts have not even heard of the language, or they did and they have misconceptions about it. If they truly care about safety, they should definitely check Ada/SPARK out.
- rp1 5y agoWhat advantages does Ada have over Rust (in terms of memory safety)?
- rcxdude 5y agoAda/SPARK allows formal verification of many more properties than just memory safety. Ada on its own does not have the same kind of memory safety guarantees as rust though.
- Quekid5 5y ago(I have no horse in this race, just curious.) Are there any non-proprietary implementations of Ada/SPARK which don't place limitations on the compiler output?
- pjmlp 5y ago> C#, Java? Managed code with JITs, not supported on a kernel level no-way no-how Not for Linux, although they work perfectly fine in industrial installations running bare metal JVMs. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.aicas.com/wp/products-services/jamaicavm/
- dnautics 5y agoIIRC C++ is dangerous because of how it does exceptions, and you might have exception-inducing code creep in unnoticed, esp. given that the standard library uses exceptions. I could be totally wrong about this.
- loeg 5y agoYou could (and would) disallow exceptions in a Linux kernel use of C++. This could be enforced with something almost as dumb as grep. Exception-less C++ is still perceived as having more cons than pros. You likely would not use the userspace stdlib — much like how Rust’s core/alloc crates are significantly limited here.
- vlovich123 5y ago-fno-exceptions is a thing. No grep required.
- deleted 5y ago[deleted]
- mgaunard 5y agoDisallowing exceptions pretty much removes a large part of what makes C++ good. Exceptions are necessary to enforce class invariants.
- kgeist 5y ago>C#, Java? Managed code with JITs, not supported on a kernel level no-way no-how. Ditto for Python, PHP, JavaScript, and other high-level languages without pointers and all that jazz. C# has pointers and can be compiled to native code. I think the main problem is GC which is required for most of the standard library (you can avoid heap allocations but that would be unidiomatic)
- HideousKojima 5y ago>you can avoid heap allocations but that would be unidiomatic AFAIK until recently (with the introduction of the Span<T> types), the only way to avoid heap allocations for arrays or any other kind of collections in C# was with stackalloc, which is unsafe.
- notanaverageman 5y agoYou still have to use stackalloc to allocate on stack. With Span<T> you don’t have to use the unsafe keyword and you can pass the allocated array to other functions easily.
- kaba0 5y agoI don’t think GC would be a problem in a general case (there are OSs written in Java, so there is that), but yeah, it probably wouldn’t be a great fit for the already existing linux code base. Especially that one kinda important function of the kernel is to GC other resources either way :D
- mgaunard 5y agoC++ does bring memory safety, but relies on best practices being followed to do so. Rust is actually heavily influenced by C++, but enforces that those practices are respected as part of the language.
- varjag 5y agoI'm really sorry but memory safety reliant on best practices is not memory safety.
- mumblemumble 5y agoIt's long been done fairly successfully in business domains like aerospace and firmware development. Where I'm less convinced that it's an option with a high likelihood of success is in open source. It's one thing when you've got a $250,000 salary riding on you ability to scrupulously follow best practices. But results may vary when the work is being done on an amateur basis.
- varjag 5y agoI'm doing embedded development day and night, so am aware how prolific C is. That however does not make it memory safe. 'Best practices' really means using humans as compiler preprocessors and hedges on humans being infallible.
- xxpor 5y ago>you've got a $250,000 salary riding on you ability to scrupulously follow best practices Sounds like a great way to have a toxic workplace that either yells at people for bugs, or never gets anything done because people are paranoid about committing bugs (or both!). Meanwhile, with a different language you get the compiler yelling at you instead. Automated enforcement uber alles. I don't think open source vs commercial dev really matters that much.
- adwn 5y ago> But results may vary when the work is being done on an amateur basis. Much, if not most, of Linux kernel development is done by employees of various companies, who are being paid for their work. Typically, that's in the form of device drivers, which also happens to be where I've seen the shoddiest, buggiest code in the kernel [1]. [1] Think "driver A abusing the 'private' pointer of driver B for its own purposes" kind of buggy.
- kingcharles 5y agoIt's not the only one, but if we're going to finally start moving away from C we have to pick one. And Rust is trendy right now, so it has more support than all the other options. It's a good option, and in another 30 years, just as the last .c file gets replaced from the kernel, we can re-evaluate again...
- stouset 5y ago> Go would be close… but it requires bundling a bunch of libraries in with each binary and wasn’t designed for low-level development. Again unsuitable. Go has a garbage collector and doesn't allow for manual memory management which would rule it out entirely. This adds a requirement for the go runtime, which is a further nonstarter.