Hacker News Reader

Comment by gjsman-1000 | Hacker News Reader

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).

View on HN

> 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.

> 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/ 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.

does 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.

I 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.

What advantages does Ada have over Rust (in terms of memory safety)?

Ada/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.

(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?

Apparently [0][1] the FSF distribution of GNAT permits development of non-GPL software.

[0] https://news.ycombinator.com/item?id=24492653

[1] https://old.reddit.com/r/ada/comments/3989f4/gnat_gpl_restri...

I was asking the opposite question, I think. I know of GNAT, but I was asking whether there's any Ada/Spark that has a GPL (or whatever non-proprietary) license.

The person you're responding to is wrong (there have been lots of languages before and after Rust that have been used for systems programming), but there are also lots of legitimate reasons why Ada was never considered a serious contender: GCC's mainline support (via GNAT) still didn't fully stabilize until the late 2000s, and GNAT (AFAIK) remains the only unencumbered implementation that's broadly available. Rust has the same single-implementation issue, but is actively working on different codegen backends to resolve it.

For better or worse, the ship has probably sailed on Ada/SPARK making its way into mainline Linux.

> 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.aicas.com/wp/products-services/jamaicavm/

C++ 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.

I'm really sorry but memory safety reliant on best practices is not memory safety.

It'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.

I'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.

>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.

> 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.

If by successful you mean where changing one line of code takes 2 weeks of change request, 2 weeks of requirement analysis, 2 weeks of system specification translation, 2 weeks of test specification, 2 weeks of test case implementation, 1 day of implementation and finally 2 weeks of code review, and so on. Then yes, you are completely right.

In aerospace you probably want all this anyway, but for others, where 99.99% is enough, there needs to be a cheaper and more efficient way.

Rust also relies on best practices. It is best practice not to use `unsafe` blocks unless absolutely needed. That does not mean Rust is an unsafe language.

1. The corollary is that code that does not contain unsafe code is guaranteed to not contain memory safety bugs, assuming that you trust and/or have audited unsafe usage in your dependencies.

2. unsafe blocks are explicit and therefore visible during code review. Memory safety violations in C++ are not always visible, simply because they are implicit.

3. Thanks to (2), unsafe usage in a codebase can be easily quantified and, if needed, audited.

Violations to the C++ best practices that enforce memory safety are definitely visible during code reviews.

The harder problem is convincing people that raising their quality standards is a necessary requirement for them to contribute to the code.

Firstly, the difference I was trying to emphasize is "guaranteed to be visible due to the unsafe keyword" vs. "potentially not visible".

Secondly, quality standards rely on the human element, which we know is fallible and never 100% reliable. Compiler-enforced memory safety checks are (in theory) infallible[1].

[1]: Infallible when all of your dependencies are also verifiably memory safe. In reality, this is not the case, but I believe that Rust can reliably get much closer to 100% than usual.

> 1. The corollary is that code that does not contain unsafe code is guaranteed to not contain memory safety bugs, assuming that you trust and/or have audited unsafe usage in your dependencies.

Doesn't this assume that there are no bugs in the Rust compiler (for "safe" code)? Isn't that still somewhat of a big assumption at this point? I get that is indeed a very core goal of Rust, but has this been proven for any/all released versions of the Rust compilers?

It ultimately depends on how you define your TCB (trusted computing base). I am not aware of any formally verified compilers for any language, but assuming one exists, wouldn't you also require said compiler to run on a formally verified OS? Also, how do you tackle the infamous "Reflections on Trusting Trust" compiler attack? It's turtles all the way down :)

Long story short, for the vast majority of use-cases, developers can assume that the compiler and stdlib are trusted. This is also how Rust defines "safety", which leaves you to focus on your code and its dependencies.

Not talking about situations where the compiler or the OS are compromised - of course all bets are off in those situations.

But "guaranteed" that there can be no security holes in code marked "safe" due to an inadvertent compiler bug? I would be very surprised if that is actually the case.

Less likely than C/C++? Yes of course. Guaranteed? Probably not.

An inadvertent bug in the compiler can be modeled as a compromise. So, as before, it depends on how you define “safe” in your model. In the case of Rust, the compiler is safe and is considered to be within the safety boundary.

Will the Rust compiler have bugs in practice? Of course. Do you - as a developer - have a different safety model than the Rust language (i.e., one that does not include the compiler)? If the answer is no, you can “ignore” compiler bugs from a safety perspective.

Ensuring memory safety in C++ is an endless game of spinning plates. It's possible, but the "best practices" for doing so certainly don't feel like best practices. I've watched people repeatedly compile a program, changing a single line and running it through Valgrind for hours on end. With Rust, you actively have to fight the compiler to cause memory leaks.

Addendum: yes, that last line is what pisses a lot of people off with Rust, and honestly, rightfully so. I've written quite a bit of Rust by now, and getting your code to work can feel like a bit of an escape room. Having C as an option on the kernel alongside it is a great idea though, because there are situations where I'd happily pick up C over Rust, and they're not just 'edge cases' where Rust falls short. Ideally, they're two different tools that can be applied depending on the situation at hand.

If you correctly model ownership with RAII, which also enforces strong class invariants, and make sure all operations satisfy basic exception safety, then leaks are not possible.

Those are the most elementary rules that one must follow when writing C++.

> If you correctly model ownership

Doing something correctly is not a best practice though. If it were, we could just say "if you correctly manage memory".

What happens when you mess up? What happens if you incorrectly model ownership with RAII? Or is it not really possible?

Object graphs where there's no clear owner are not automatically "incorrect" - whatever they're modelling might be non-hierarchical itself - yet would result in a leak without a GC.

They are, sorry. There is no way to enforce basic guarantees without ownership.

Graphs where no single object is a clear owner happen all the time in real world, so I would argue that any object model that can't accurately model that is just not good enough.

And what basic guarantees are not enforceable without ownership?

One nit:

> With Rust, you actively have to fight the compiler to cause memory leaks.

Memory leaks are not considered unsafe in Rust[1]! They're actually an important part of Rust's lifetime semantics: intentionally leaking memory is both safe and equivalent to producing a `'static` out of thin air.

You probably shouldn't leak memory as a matter of practice, of course, but Rust will happily allow you to do so in 100% safe code.

[1]: https://stackoverflow.com/a/56108074

C++ also bring implicit memory allocation. This is a big no for kernel.

When rust was proposed for linux, controlled memory allocation was on the top of requirements list

What implicit memory allocation are you talking about?

The only thing I can think of that allocates is throwing an exception (nad that's an ABI-specific strategy), but I doubt that's what he means.

They might be referring to how easy it is to accidentally/unwittingly invoke the copy constructor in C++. `Foo x = Foo();` used to be the famous example of that, although more recent versions of C++ may guarantee that the copy is elided there.

Another good example is implicit comparison conversions, e.g. some class defines `operator==` as non-explicit and any code that does `x == y` where `typeof(x) != typeof(y)` may find itself going though a possibly-allocating constructor.

Allocations in this context usually refers to heap allocations. Temporaries aren't heap-allocated.

Temporaries may or may not be heap-allocated; the C++ spec doesn't specify.

But even beyond that: you can have a non-trivial constructor that requires heap allocations internally. So even relying on (sane) compiler-defined behavior won't save you in the general case.

> Temporaries may or may not be heap-allocated; the C++ spec doesn't specify.

Presumably the same is true of C.

Are there any C++ implementatons that actually heap-allocate temporaries? The only context where I can imagine that happening is an async (as in co_await) function, where all autos might need to be heap-allocated for obvious reasons.

But that aside, it just seems like a very weird choice that would have profound perf implications - to the point of removing pretty much the sole remaining advantage of the language - for no gain whatsoever, since it's not even simpler.

As for non-trivial ctors - at that point you might as well worry that every function call made in pure C code can also heap-allocate, no?

'best practices' for memory safety in C++, even modern C++, are still so convoluted as to not be reliably followable in practice, either by humans or humans assisted by static analysis.

They are exactly the same practices that Rust has built-in into the language, so I'm not sure what you're hinting at.

In theory, C++ programs use std::optional, just as Rust programs use std::option. In practice, such C++ programs are extremely rare, whereas such Rust programs are majority.

There's an even clearer example here: dereferencing a C++ std::optional is undefined behaviour. Dereferencing a Rust std::Option is a compile time error.

In theory, in practice when using debug libraries, undefined becomes defined as a runtime check that will lead to an assertion error, or a static analyser failure.

https://godbolt.org/z/re51ensMe

    terminate called after throwing an instance of 'std::bad_optional_access'
      what():  bad optional access

Naturally not everyone goes by adopting best practices, so there is that.

They're saying that the Rust compiler will reliably enforce these things... and that it's completely trivial to surface any cases where the programmer thinks that they are smarter than the compiler, e.g. for extra code review, outright rejection, etc.

no, he's saying the C++ best practices are too convoluted, (implying the Rust ones aren't), when they're essentially the same, just enforced differently.

Read the post in the context of what it's replying to.

Rust has semantics which are designed to allow those best practices to be watertight and enforced by the compiler. C++ has semantics which are designed to fit around many years of backwards compatibility with unsafe practices. Attempts to make static analysis for C++ which mirror rust's borrow checker have thus far failed. There is not an automatically enforcable set of rules for C++ in any version which give you the same safety guarantees at rust (and the non-automatically enforcable set of rules is not followable by humans in practice, since we keep getting memory safety bugs in C++ code).

>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)

>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.

You 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.

I 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

D and Zig could work.

Nobody 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.

Insofar 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.

Heh, there were plans to add ownership&borrowing to 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.

I 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.

Zig 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.

D is upstream in GCC since 2019, so it is actually superior to Rust in that respect. Days of proprietary D compiler is long past.

Zig 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.

Sure; I should have said: "Unlike D, Zig isn't substantially older than Rust..."

Yes. Zig started in 2016 Feb, Rust started in 2006 and pre-Alpha 0.1 release in January 2012. ( Needless to say the design Rust and borrow checker is way more complicated )

Free 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/

As 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.

Very 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...

It'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...

IIRC 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.

You 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.

-fno-exceptions is a thing. No grep required.

Disallowing exceptions pretty much removes a large part of what makes C++ good.

Exceptions are necessary to enforce class invariants.

No? You could just enforce invariants by panicking, which is what the C linux kernel already does.

How would a "panic" differ from an "exception"? Keep in mind what happens in C++ if you do not catch an exception.

Exactly my point.

If you allow exceptions, people try to catch them.

you'd catch and handle the exception at the adequate point inside your subsystem.

The same argument could be made with return values: what happens if you don't handle them and just panic on them.

Linux tries pretty hard to use panics as an absolute last resort: there are a lot of invariant failures that are better handled by disabling drivers or subsystems, marking an impossible response as illegal and just trying to muster on, etc.

Having exception-worthy invariants become panics would probably be a nightmare, at least for idiomatic C++: every nontrivial ctor (including copies and moves) might be a panic site.

Eh? A lot of modern C++ development explicitly disables exceptions, they are unnecessary whether or not they should be used in practice. For more low-level systems-y code, there are good reasons to avoid them.

While there are arguments over when and how to use exceptions, I think this is the first time I've seen them positioned as a killer feature of C++.

> I think this is the first time I've seen them positioned as a killer feature of C++.

It's not a killer feature of C++, it's a requirement, without exceptions you can't have faillible ctors meaning your object lifecycle suddenly becomes a lot more complicated and full of additional traps.

A requirement for classes using the default memory allocator, there are other ways to design programs, and to allocate memory.

> there are other ways to design programs, and to allocate memory.

I covered this option:

> your object lifecycle suddenly becomes a lot more complicated and full of additional traps.

because without ctors you don't have object invariants as you have to split instantiation and initialisation, or you have to implement bespoke and unusual strategies drawing you further and further away from anything which could be described as "standard" C++, thus making the advantages of C++ dwindle further into the distance. And all that with, as far as I know, no standard tooling to support you.

Those invariants can still be kept by making use of DbC approach, which is anyway a good coding practice.

Classe invariants must be kept in each method call, not only constructors and destructors, and again they only matter in classes.

C++ is a multi-paradigm language, this is not Python Zen.

How would you define such a contract without adding a "bool is_valid" (or semantic equivalent) to every object, the constructor of which might fail?

Model fallible instantiation with factory methods. e.g. Node::make(Args..) -> Result<Node>. It won't always be as efficient or ergonomic but it works. And hey it's c++, you've been conditioned to accept a ton of ceremony to get things done. Famously the bulk of google's code is written without exceptions. And from what I know of it (not much), factory methods are how they model instantiation fallibility.

As a related but separate thought, sometimes adding invalid states to an object is useful. For example, take a look at std::thread::detach. Sometimes you see rvalue qualifiers on such methods (indicating the object has been consumed).

If you consider memory allocation to be infallible, there is a lot of stuff that can be written as pretty normal c++ without exceptions. The STL even pretty much works without throwing given this. If you consider allocation to be fallible you're going to have a bad time with "standard" c++ too.

It's widely accepted by the C++ community that Google's C++ standards are bad. They're more concerned about using a simple subset of the language anyone with minimal C++ training can understand than about writing good C++.

And detaching a thread is pretty much always a bad idea.

> Model fallible instantiation with factory methods. e.g. Node::make(Args..) -> Result<Node>. It won't always be as efficient or ergonomic but it works. And hey it's c++, you've been conditioned to accept a ton of ceremony to get things done. Famously the bulk of google's code is written without exceptions. And from what I know of it (not much), factory methods are how they model instantiation fallibility.

The problem is not the ability to do it but the ability to enforce it. "Just be careful" has not worked, and will keep not working. Google's coding standard has not stopped C++ from causing them problems.

> As a related but separate thought, sometimes adding invalid states to an object is useful. For example, take a look at std::thread::detach. Sometimes you see rvalue qualifiers on such methods (indicating the object has been consumed).

You know what's actually useful and good?

For the object to actually be consumed and not be accessible at all anymore.

> If you consider memory allocation to be infallible

Which you can't in the kernel.

> If you consider allocation to be fallible you're going to have a bad time with "standard" c++ too.

Yes? That would be the point.

Modern C++ is very much about exceptions.

Disabling exceptions gives you C with classes, which is the old style.

I write ultra low-latency system-level code for HFT, and I certainly use exceptions.

I write ultra high-throughput database kernels. We use just about every feature of C++17 and beyond, particularly since so much of the implementation is generated via metaprogramming scaffolds. I don’t use exceptions at all, mostly because it is a poor abstraction for this type of code. Exceptions aren’t all upside.

Clearly, modern C++ has very little to do with exceptions, or I would have required them or found them useful at some point. I’m not saying exceptions are not useful, but their centrality to the language is empirically false given the vast number of modern C++ code bases that don’t use them and lose nothing by it.

How do you deal with failures to allocate in stdlib?

By providing custom allocators?

Also when speaking about kernels, it isn't as if the other languages being discussed (including C), make use of their respective stdlib in kernel space.

How would the custom allocator report the failure to allocate to the container, though?

Database kernels do virtually no heap allocation as a matter of good design. They also rarely use stdlib containers or anything else that dynamically allocates on the heap outside of the bootstrap context. Virtually all of this memory has to be dynamically pageable to storage (and you can’t use mmap() or virtual memory) which largely precludes using parts of the stdlib that require allocations. They work within a tightly bounded memory footprint plus the stack, and these resource reservations are pretty strongly guaranteed at bootstrap. Even the stack often has analyzable bounds. It is hard to design good schedulers, whence most optimization comes, without these constraints.

If your process doesn’t survive allocation in bootstrap then it is badly misconfigured. If it survives bootstrap, then the software has been able to make hard guarantees about its resource constraints; the runtime will optimize to those constraints. Many years ago, given the designs of the time, you had to worry about blowing out the stack memory occasionally in edge cases, but even that isn’t a real problem these days due to changes in how it is done.

You would design things this way in any language. The benefit from a software design standpoint is that you can derive an enormous number of invariants from these constraints that can be used to guarantee that the core processes will never experience resource exhaustion. This eliminates a massive number of edge cases that would have to be accounted for if resource exhaustion was detected by testing limits.

While I disagree with disabling exceptions, modern C++ has all the goodies as Rust (minus pattern matching) for using return errors instead of exceptions.

However returning errors from failing constructors would not be very clean.

C++ also does not have decent macro system, which is leveraged in Rust error handling (the derive system).

True, but for that you will need to be using classes to start with.

Yeah macro like tooling in C++ is clunky, but on the other hand I think Rust goes overboard with macros.

Reply on news.ycombinator.com