There’s no building things up from basic concepts, just piling feature atop feature until you have an endless pile of one-off special cases.

I disagree completely with this assessment. In my experience, Ada is very well designed specifically in that it takes the big, monolithic features of other languages and break them down into their constituent parts, so you can choose which portions of those features you want. As a concrete example, I never truly understood object-oriented programming until I learned Ada, which breaks down object-oriented programming into separate features of

• encapsulation,
• reuse,
• inheritance, and
• dynamic dispatch.

In Ada, you can opt into each of those things separately, depending on what you need “object-oriented programming” for. This is in big contrast to Java, where you type the keyword “class” and then all of that comes along for the ride.

I much prefer Ada’s fine-grained control over which language features you use, and it’s a bit sad to see someone look at it and think of it as a random hodge-podge of features. No. They are designed incredibly well to fit together and provide a whole that is much more than the sum of its parts.

I think that much like Modula-2 there could be a fairly useful, pleasant language somewhere in there waiting to be discovered.

Indeed, I think that useful, pleaseant language is Ada, once one takes the time to discover and become familiar with it.

Ada really came out unfairly poorly here. Two points:

1. “Basic type system: 6.5/10”: Is this a joke, given the author gives Rust a 10/10? Rust is still, comparably, in the stone age, only allowing explicit-bit-width-integers (8, 16, 32, etc.) rather than ranges. Ada has type predicates (static and dynamic) that pretty much leaves you no bounds for type definitions.
2. “Spatial safety: 1/10”/“Temporal safety: 3/10”: This is very unfair, given Ada allows you to prove so many things at compile-time, even more so when you’re using SPARK, the safe subset. Program correctness doesn’t end with correct memory management, and from what I can tell Rust doesn’t offer much beyond that, whereas Ada does.

I do agree with the author’s criticism of Ada’s packages/standard library, though, but projects like Alire (Cargo for Ada, basically) bring a breath of fresh wind here.

In the end, though, I see this survey as an opinion piece, which has merits on its own.

Clarifying some Ada here, if you want a language break down from a non-Adaist (?) perspective, there’s a talk on that.

some of the pointer lifetime shenanigans described below probably require a nontrivial amount of bookkeeping though, and will result in more restrictive designs to get around the limitations on pointer lifetimes and aliasing.

This is done at compile time, is called “accessibility” and is known in the standard as the “Heart of Darkness.” Ada has nominally typed “pointers”, with bounds given by their lexical scope since you can declare new pointer types in both packages, in functions or procedures and inline in a declare block.

Along with structs there’s “aggregates”, which are more or less tuples

Aggregates are a syntax to assign to structures like a C designated initializer, Ada has no tuples. You can use hook up aggregate syntax to initialize your own custom containers and such with the Aggregate aspect.

procedures and functions are different things

Procedures are statements and functions are expressions. This prevents inadvertently forgetting about return values – there’s the whole [[nodiscard]] struggle that C++ has had to try to deal with this problem.

There’s no building things up from basic concepts, just piling feature atop feature until you have an endless pile of one-off special cases

I very much disagree with this. There’s types (really subtypes, but waves hands), subprograms (functions/procedures), packages, tasks and protected objects. Aspects and generics layer on top of that, the syntax gets a bit broad in all of the forms of these though.

In fact you don’t define integers with particular sizes, you define them by ranges and let the compiler decide how big they need to be

The ranges of something are usually more important, but you can force an integer to be a specific size by using declaring your integer with a bitwidth like Size => 16 or creating a new semantic from a sized integer type in the Interfaces package:

type Bar is range 1 .. 10 with Size => 64;
type My_Integer is new Interfaces.Integer_64;

there’s basically no type inference

I know I’m probably one of the few people who find this as a feature. Hindley-Milner makes it super easy to write and refactor code, but for readability it’s nice to have the types there. Unless I’m using a plugin while writing Rust, C++, or F# I find it difficult to understand what’s going on when types are omitted (here’s looking at you auto&).

There’s a notion of “definite” vs “indefinite” types, which appear to be types whose size is vs. is not known at compile time; the latter can only be touched via pointers.

You can use indefinite types without pointers. There’s a bunch of hand waving things where you can return dynamically sized arrays on the stacks and use these types on the stack provided the size is available when variables are assigned. GNAT uses a secondary stack to do a bunch of heavily lifting where otherwise you’d have to allocate to return something with an unknown size.

Pointers/access types can usually only point to dynamic memory

There’s a separation between “plain” access types which point to heap allocated memory, and access all types which can also point to the stack. It helps prevent holding an address to something on the stack.

Freeing a single pointer is possible, but it modifies the metadata attached to the access type so a double-free doesn’t corrupt the heap.

The standard is fuzzy about if the language uses fat pointers or not.

Freeing a access type (“pointer-like”) sets it to zero automatically, which is a common C/C++ pattern. It doesn’t prevent free-after-use if you’re holding a second access type to the same thing. A lot of “can this be deleted” gets avoided since you have to explicitly instantiate a generic function to do the free.

Aliasing where multiple pointers point to the same thing is also mostly not allowed.

This is not true.

This is basically what OO inheritance or Rust traits is for

You can do dynamic dispatching by declaring a parameter type with 'Class, but otherwise you don’t get dispatching behavior. Like many other things in Ada 'Class here doesn’t mean class as in OOP, it’s a set of types closed under derivation, wherein “derivation” also means something slightly different in Ada than in OOP (sigh). Other than that, generic packages and functions are probably the closest thing for existential types.

“controlled types” which loooook like C++-style RAII, complete with objects and copy constructors

Yes, controlled types are C++ RAII. There are no actual copy constructors, but you can prevent objectcs from being copied by making them limited.

You can write interface files by hand but it seems like you usually don’t have to, perhaps unless you want to declare private vs public functions and types? Oh, public types might also require interface files. Forward declarations are necessary if you need mutual recursion, but mutual recursion is pretty rare in general. There’s more to explore but it’s frankly so tedious and complicated that I have a hard time wanting to.

There’s a declaration for procedures/functions and packages, and then a body definition. In GNAT a .ads file is like a .h file, and a .adb file is like a .cpp file, but since this is at the language level, there isn’t a preprocessor stitching things together. This assists in separate compilation and unless the specification is changed you don’t need to recompile other parts of the program using your code, though you’d have to re-link.

You can write interface files by hand but it seems like you usually don’t have to,

If your program has more than a single entry body, you need to write a spec for each package you make.

Figuring out how the heck to put multiple functions into the same file is unironically difficult.

--  example.ads
package Example
    procedure Foo;
    procedure Bar;
end Example;

--  example.adb
package body Example is
    --  empty procedures as example
    procedure Foo is begin
        null;  --  we have to have a statement
    end Foo;

    -- shorthand for an empty procedure
    procedure Bar is null;
end Example;

I have a really hard time imagining myself getting good at it and thinking “boy this really DOES make reading code so much easier”

It took me less than a week or two from knowing none of the language to reading the standard library and a bunch of code samples from other people.

you need to jump around a lot to actually figure out what the hell anything

Pretty much you use package specs like mini-docs while you’re working.

The amount of work it takes to arrange and declare various functions and types probably makes refactoring hell

Quite the opposite. All declaration sections operate the same way, so you can move functions and types super easily around the code. You also don’t need to rewrite your functions or procedures if you turn a struct into a class-like (tagged) for example, since they’re all declared like procedure (Self : My_Class; P1 : Param).

pointers default to non-aliasing, so you can declare a pointer type with an annotation as aliasing

Not sure what is intended here. The aliased keyword is to indicate a thing on the stack can be pointed to.

One aspect I tend to over-optimize for is “will this language still be around (and popular) in 10+ years?” But based on how infrequently I actually reuse (or even build) my old code, this might be foolish.

Having said that, other than C and C++, which languages will stick around and continue to be popular, cross-platform?

Rust seems to have achieved critical mindshare and Zig’s tooling makes me optimistic about its future. Any others?

There’s nothing super groundbreaking [about rust modules], it just pretty much works.

I disagree :P Rust doesn’t have single global shared namespace, and it is a pretty big-brained idea! When a crate participates in compilation graph, the crate doesn’t have a name. The name is a property of dependency edge between two crates (so, the same thing could be known under different names to different users).

This in turn unlocks the killer feature of “you can link foo 1.2.3 and foo 2.0.0 together”, without which we simply wouldn’t have sprawling dependency trees.

Stripping the author’s nebulous “joy” and “dread” dimensions and focusing on the pure aspects considered, the results are:

1. Zig 8.3 up from 7.9
2. Rust 7.6 down from 7.8
3. Odin 6.8 up from 6.4
4. Ada 6.6 up from 5.7
5. Hare 6.4 up from 6.2
6. Jai 5.6 up from 4.75
7. C 3.8 up from 3.7

I think it’s interesting that excluding these dimensions does not change the ordering by much. The only change is that Hare and Ada swap places, because Ada was punished harshly on these je ne sais quoi dimensions. (Granted, some of this was obvious given the high correlation between a mean of ten values and the same mean but with two variables removed!)

I also find it interesting that the joy and dread axes generally serve to bring a language’s score down, with the exception of Rust which is – apparently – good nebulously but in a way that’s hard to capture on features alone.

lots of things with no better home just get added to the list of over 120 compiler built-in functions,

I got a similar impression initially, but it flipped to the opposite couple of months in. The big thing is that std in Zig is not special. There are no lang items. So, builtins are the entire interface between compiler and user code, it’s just that this interface isn’t particularly well-hidden in the guts of standard library, but is just there to be used.

In a similar vein, the fact that @import is a reverse syntax sugar is cute. Import is syntax in a sense that the argument must be a sting literal, and you can’t alias the import “function”, even at comptime. It fully behaves as a custom import “path” syntax, except that there’s no concrete syntax for it and a function-call is re-used.

I love it! Minor minor nit in the Zig section:

Zig generics are just functions that can take and return types the same way as any other value. They’re just all evaluated at compile time, and RTTI fills in some gaps to let you do a bit of inspection of types at runtime as well.

I don’t think there’s any RTTI in Zig! (as evidenced by type not being something you can handle at runtime whatsoever.) All the fun type stuff happens at comptime, and you’re left with some pretty clean codegen.

One of the complaints about Rust I’ve heard from people is that writing low-level code in Rust actually kinda sucks, and from my modest experiences with it I have to agree. Unsafe pointers have shitty ergonomics. Lots of small but necessary features tend to be locked behind unstable compiler features, which may never become stable. It’s real easy to accidentally cause UB or otherwise screw up in unsafe code. And it’s hard to understand the compiler’s assumptions about how things fit together under the hood. The docs help, and the story in general has slowly gotten better as the stdlib has improved and evolved, but it still often feels a lot like a second-class citizen. The feeling a lot of the time is that Rust is not really for writing OS and embedded code, it’s for writing high-performance applications.

I’ve also written a modest amount of low-level code in Rust, and I’m not as pessimistic about its suitability for low-level work. Unsafe pointers are more complicated and verbose to use than safe references are, but this is kind of a virtue I think - it encourages you to very quickly write safe abstractions around them so you don’t have to think about e.g. doing manual pointer arithmetic anymore, which is exactly the design pattern you want your embedded OS or similar to have.

However, it doesn’t loooook like there’s any good way to do what type theory goons call “existential types”? This is basically what OO inheritance or Rust traits is for; “existential types” are basically any feature that lets you write fn foo(x: impl Something) and then call it with any type that has a Something trait which defines some interesting operations. The examples I can find for generics in Ada do things like swap values or concatenate arrays where the only operation done on the generic type is “copy”

Type theory goon nit: I think it would be better to describe this as “bounded” or “ad-hoc polymorphism” rather than “existential types”, although existential types are likely relevant in the implementation. A lot more languages support bounded polymorphism than explicit encodings of existential types.

Hence, for me, a language not having “existential types” is unfortunate, but less important than not having “bounded universally-quantified types” as an explicit language feature.

The provided Rust syntax is essentially sugar for a bounded universally-quantified type fn foo<T: Something>(x: T). Note that a signature with impl in output position instead (like fn foo() -> impl Something) is an existential type, and doesn’t have a simple encoding in terms of other language syntax.

As another example, you might consider wildcards (?) in Java as existential types, but you typically use bounded universally-quantified types in Java without needing ?.

It’s true that, from inside the function definition, the input universal type can be typechecked as an existential type (and an output existential type can be typechecked as if it were a universal type), but I don’t think it’s the standard way of naming the feature in question.

The paragraph on D has a number of common misconceptions mixed up in it:

Both of these languages started off roughly in the “C#/Java/Go” level of abstraction and slowly worked their way downward.

D has had its full set of C-like features from the beginning, plus various common extensions like pragmas and inline asm. (This is why I don’t really like the term “system languages”, its definition is too vague…) So, if C counts, D should too. Many of the language lists C interop as a selling point, which D has also had from the beginning.

D, of course, offers more than C, things like the easy strings and garbage collector and such, also from day one, so I think it can also be called an “application language” if you wanted - the original D release was really recycled Java and C compiler components, and I think this hybrid nature is its big strength - but since you choose not to use those parts and play with your pointer arithmetic, inline asm, etc. from the first release, I can’t agree that it started at one thing and slowly worked its way downward.

Heck, if anything, I’d say it started low, and then tried to build more abstraction on top of it - the original release rejected most of what C++ did, no templates, for example, no references, no const - then those were tacked back on over time.

f I understand correctly it started with a GC, then made it optional, then realized that to make it optional you needed an entirely different stdlib, then had a community split over the different stdlib

D has always had a GC, from day one to present day. You don’t have to use it, like previously said, it also has all the same C functions (you can call malloc and free and cast the pointers yada yada yada, exactly as in C - this is where the marketing claim “optional GC” comes from), but it is there.

The stdlib fork had nothing to do with optional GC though. The forked stdlib (something that happened in 2004 and was officially reconciled in 2007… yet still gets talked about in basically ever D thread ever) was over a (mostly) closed door to outside contributions, not memory management philosophy. Both stdlibs embraced the garbage collector and were awkward to use without it.

I think

Spatial safety: 10/10

for Zig is unfortunately a bit cope: not only does Zig still have a few cases of miscompilation that users hit practically, but the runtime check behavior they mention is only in debug mode. If you use any others, then you still have a lot of potential undefined behavior, and even worse the ReleaseFast mode has some wild footguns like assert becoming assume and introducing UB. As far as I know you can also still write stack use-after-frees even in debug mode.

Practically, hitting an assert due to uaf that debug mode “catches” is still bad ergonomics even if it no longer is exploitable as memory unsafety. And “memory safe only in debug mode” is worth a lot less to me than Rust: I wouldn’t claim that a c compiler that defaults to -fsanitize=address is a “10/10” spatial safety language, because I doubt a lot of people are running with that in production and the presence of it in debug doesn’t magically catch everything, and likewise don’t think that claiming Zig is 10/10 spatial safety is accurate.

[Comment removed by author]

I don’t really do much low-level programming, I’m a garbage collection enthusiast (my main professional language is C#, and my main hobby language is Common Lisp). So these comments come from that POV.

1. I really like that Hare is designed around interoperability with other languages both ways, not just having a C FFI. So if someone writes some really amazing library in Hare, like a cross-platform GUI toolkit, it’s pretty easy for me to write a Common Lisp wrapper. The number 2 thing I dislike about Rust is that it feels like a graveyard for good ideas: people write interesting Rust libraries that serve some function that’s not Rust-specific , and then they’re unusable from anything but Rust.

2. Overall, it seems like Zig is the closest to what I would want in a system language. Safer than Hare, not an exploding mess of accidental complexity like Rust. And from the point of view of a Lisp user, the fact that compile-time programming is done in the language itself is sweet, and the fact that so many other features are implemented in terms of comptime is elegant.

All that said, I also feel like I’m not qualified to have opinions about this stuff, it’s just that Rust gives me The Fear in a way C doesn’t, even though I know how many footguns there are in C.

Forgive my ignorance if this is a dumb question, but I don’t see golang at all in this article aside from a passing reference to its mascot. Is that an intentional omission? Why?

Sad that ATS doesn’t event make the “weird Indie shit” part of the page. I feel like its ideas were before the time where the popularity of those ideas became mainstream. I hope development of it continues.

While we acknowledge that C’s score cannot be too high, I feel that assigning “Spatial safety: 1/10” to C while 10/10 to Zig isn’t very fair. C gives implementations a lot of choices. An implementation could pick -ftrivial-auto-var-init=zero, either -fwrapv or -fsanitize=signed-integer-overflow, a hardened allocator like -fsanitize=scudo, in the future https://clang.llvm.org/docs/BoundsSafetyImplPlans.html

Somehow C gets by without a single mention of integer overflows… which are extra special with auto-casting of int types and signed overflow being undefined. I guess the author was including that under spatial safety, and gave C a 1/10 on that anyways, but not overflows are a spatial problem.

Random anecdote: Earlier today I was reading some sqlite code, and was very confused about how there wasn’t trivial undefined behavior in the parser, until I tried to exploit it and discovered that they (partially) solved this problem by giving up on checking cases and instead limiting the size of allocations to 2^31 - 255 so that simple counts of (a subset of) a single array/string can’t accidentally overflow. Still not a perfect solution of course.

Good stuff. I think this is the first time I’ve seen someone actually take a detailed look at Ada.

Maybe you could have “fearlessness” instead of “dread” as the name of the last item so you could have a more intuitive “bigger number means more of the thing” meaning for the score?

@icefox,

Could you elaborate on the poor design choices Scala made that it will never shake off?

As far as I’ve seen Swift Seems Fine(tm) but it seems to have the Scala Problem where they made some bad design choices that they will never be able to shake off.

Another one for the honorable mention pile is Chapel, a language designed specifically for supercomputers. I thought it would technically count as a systems language, but turns out it has automatic memory management. It also fails your other goal of “being good for gamedev”. Chapel is a weird language, but it’s got a lot of interesting ideas that might also apply to systems programming.

Another fun fact, the Lobsters developer also made the very first esoteric programming language, False

I think C needs to be thought of more as ‘building material for a language / toolset’ rather than a language / toolset in itself. I’ve had a decent amount of fun doing custom codegen (with a quasiquotation-like thing) for the specific case of generics I’ve wanted (basically just … dynamic arrays – but then also reflection for serialization etc. more generally than just ‘type parameters’) and trying to write a simple borrow checker for C. Codegen has honestly been much nicer than other language generics implementations where the compiler internally does codegen but … hides the generated code from you. With generated code that actually is materialized – you can LSP or debugger jump into the generated code and just read it, profiler shows decent function names, etc. Not having namespaces and function names being globally unique makes it so my LSP symbol search is actually pretty usable. The whole ‘method syntax’ thing in other languages ends up distracting me with the question of whether something should be a method or not. Overall that’s how I’ve felt about other langs – lots of cases where I end up having to make a decision that is orthogonal to what I’m actually designing because there are so many different ways of expressing the same thing.

Beyond C what I want is actually like – functional correctness (verification through proofs or model checking or such) which none of these other languages provide. I looked at Frama-C and also Verifast but didn’t stick for various reasons. So been exploring hacking on the Dafny C++ backend (it doesn’t support reals and generates a lot of shared_ptr) or trying some custom embedded DSL in Coq that extracts to C… There’s also RefinedC and VST etc. The verification thing may also work out as a way of implementing a formal verified borrow checker for C at least… (similar to the Rust stacked borrows model on Iris).

Would be cool to see a ‘system language’ that includes some decently expressive separation logic that helps you reason about functional correctness.

What about Fortran?