Ask HN: Memory-safe low level languages?
118 comments
·April 27, 2025khaledh
Check out Nim. I'm using it to build an x86-64 kernel¹ (Fusion OS), and it satisfies a lot of the low-level system programming requirements with an elegant and expressive syntax. For memory management you can choose between ARC/ORC and/or manual. It has two downsides though: small community, and the BDFL can sometimes be rough to interact with.
¹https://0xc0ffee.netlify.app/osdev
I, too, have been looking for a unicorn systems programming language, but it doesn't exit yet. Here's what I looked at so far (only languages that don't rely on a GC):
- C: lots of UB, less safe (memory- and type-wise)
- C++: too complex, not a big fan of OO
- Rust: too complex, gets in the way when writing mostly unsafe kernel code
- Zig: Good, but syntax is too noisy; lacks interfaces/dynamic dispatch
- Swift: Doesn't have a good bare metal story
- D: Seems interesting, I may be looking at it (although need to use betterC mode, i.e. not all language features)
- Odin: Game programming focused, small but growing community
- Ada: Strong candidate, but it has too much ceremony
- Pony: I like the capabilities model, but tiny community
- Hare: Also tiny community, lacks polymorphism
- Hylo (Val): Experimental (mutable value semantics), too immature
- Vale: Experimental (regional memory management), seems stalled
- V: Good candidate, but mixed reviews on its claims vs. reality
- Austral: Experimental (linear types), tiny community, not much progress
- Jakt: Built for Serenity OS, not sure if it's getting enough attention
- Jai: Focused on game programming, good reviews, but currently closed source (beta)
- Mojo: (Python-like) Seems very interesting and I'd give it a try, but too focused on GPU/parallel programming; also too early for adoption
az09mugen
Thanks a lot for that list ! It matches pretty much what I imagined.
On a side note and coming from high-level languages, D is the easiest to learn IMHO, as it is very dev-friendly, mature enough and has a good interoperability with C libraries.
I considered for a long time nim for its syntax and "low-levelness", but my lack of knowledge in low-level languages made the learning curve too much steep for me. I think I'll switch to it when I'll have more experience.
codr7
There have several attempts at cleaning up C without giving up too much of its simplicity; from what I can see, Zig is the only one even close to reaching critical mass.
A programming language is always going to make some kind of compromise; better at some things, worse at others.
Simplicity/power and safety pull the design in different directions.
nielsbot
Related, Apple has a safer C variant they use to build firmware:
chrisrodrigue
Zig hits on a lot of Zen of Python.
> Beautiful is better than ugly.
> Explicit is better than implicit.
> Simple is better than complex.
> Readability counts.
What really sets Zig apart from the usual suspects (C, C++, Rust) is that it has first class compile-time reflection capabilities built into the language (comptime, @field, @typeInfo, etc.) rather than bolted on as macros or templates.
90s_dev
> Python
Funny you make that analogy. I remember back when the two contending C alternatives were Zig and Nim, with Nim being syntactically almost a Python clone.
It seems Nim has gone the way of Crystal (Ruby version of Nim) and is just kind of there but mostly forgotten and doomed to be abandoned unless it finds a niche.
> What sets Zig apart is compile-time
I see this claim a lot, but I'm not sure. I think it's the fact that Zig is more or less still C syntax and semantics, just... fixed. The way it does comptime does seem better than how other languages do it, but I haven't actually used it, much less for long enough to judge it properly.
tauoverpi
Comptime is a gateway to partial evaluation, precomputing tables, and data layout optimization using the same language zig that you're familiar with when you need it and just a convenient way to handle generics when you don't.
As an example from my unfinished project, I use it to select the encoding to use [1] when resolving pointers to components [2] to reduce code size [3] as much as possible while keeping a high-level interface [4] where you don't need to care about any of it, just "map" a system over every matching entry within the database and it computes the "best" traversal for a single-thread. This is something that's generally difficult to both keep simple enough to work with and for it to generate good enough code to be worth it while retaining type safety.
Comptime enables such without much cognitive overhead as you're working in the same language as before just with lazy evaluation [5] and slightly more lenient rules around memory management making it easier to focus on working towards the desired the data model.
[1]: https://codeberg.org/tauoverpi/game/src/commit/77ec827ec93bc...
[2]: https://codeberg.org/tauoverpi/game/src/commit/77ec827ec93bc...
[3]: https://codeberg.org/tauoverpi/game/src/commit/77ec827ec93bc...
[4]: https://codeberg.org/tauoverpi/game/src/commit/77ec827ec93bc...
aalhour
I haven't used Nim but your comment made me remember that language, yeah it was forgotten but I am not sure if it's completely abandoned, it seems that their team has been launching new language releases on a nice cadence: https://nim-lang.org/blog.html
hyperbrainer
I don't mind the language having substantially worse "something" as long as it can be a smaller alternative for Rust, for the lack of a better word. Of course, there always needs to be some compromise. I don't mind that. I just have two requirements, and am curious to see how people have tackled that problem.
codr7
Sure, and I'm just as curious.
But at the same time, I'm pretty sure that smaller/simpler is going to mean less safe.
uecker
I think the opposite is true. The Rust philosophy is the idea that a complicated type system should ensure safety. This may work to some degree, but the overall complexity will introduce new issues. I say this as someone who was really excited about type systems in the past, but Rust is ... meh.
tiffanyh
SPARK (Ada) is about as memory-safe as it gets.
andsoitis
I was also going to suggest Spark https://www.adacore.com/sparkpro
There's also this paper, "Memory Safety in Ada, SPARK, and Rust"
https://www.adacore.com/papers/memory-safety-in-ada-spark-an...
tiffanyh
I’ve always found the table comparison (Rust/Ada/SPARK) from that same source to be very informative:
https://blog.adacore.com/should-i-choose-ada-spark-or-rust-o...
shakna
V [0] aims for something along those lines, but I've had a few issues with the safety aspects of the language. Breaking through the checker isn't that difficult.
I absolutely adore Ada [1], but the Pascal-syntax isn't for everyone.
I haven't used it yet, but have been hearing rumblings about Odin [2] a fair bit in these kinds of discussions. I tend to avoid too many symbol-heavy langs, but it's probably still less than Rust (I use a screenreader half the time).
arp242
I just so happened to use Odin a bit this week, and I hit several different problems: two compiler bugs and a stdlib bug. I'm not having a go at the Odin people, just pointing out it's very much an "in development" language with some fairly sharp edges.
baranul
That's going to be the case with any of these languages which are still in beta (Zig, Odin, Jai, Vlang, C3, etc...).
Not saying you in particular, but it's weird, how too many won't tolerate running into some problems when they knowingly chose something still in beta. "Oh my, there was an issue with the beta software I'm using".
Maybe why JBlow refuses to release his beta to the public. Actually, it can be a good thing for the language, by people filing bug reports (so they can get fixed) or to do a PR (if they are at that level). That way, the language has more vetting, from more eyes on it.
arp242
There are degrees of things. I've had my issues with Zig, mostly relating to things changing, but I've never had these types of issues. "Beta" can mean many things. Gmail was "beta" for over a decade. Just pointing out what, in my limited experience, "beta" means for Odin.
n42
I see so much controversy every time V comes up; can someone explain why, without devolving into name calling and personal attacks? What specific design choices or implementation details are contentious, and what legitimate concerns exist beyond interpersonal conflicts?
andrewflnr
Having only watched the discussion: The main problem seems to be grossly inflated claims about its capabilities. As in, the docs say it already does X Y and Z, and when you try them they plainly don't work. And then the creator starts with the personal attacks when you point this out.
detaro
When it launched it proudly claimed to do a lot of things, some of which most people would consider still open research questions. Unsurprisingly, it didn't actually do these things or have a concrete plan of achieving them, and they didn't handle people pointing that out very well. Some other language developers were unhappy about the support V gathered based on these claims vs languages that were further along but honest about what they actually had.
(I have no idea what the current state is)
arp242
> they didn't handle people pointing that out very well
I think that's a fair thing to say. But in all honesty, the people pointing that out were not exactly polite about it, to put it mildly.
I never really looked at V myself and have no opinion, but I do know unpleasant behaviour when I see it and quite a few of the people "pointing out" some of the shortcomings of V were engaging in it.
shakna
V... Overpromised, and underdelivered, on what it could do. Promised complete Type Safety, before the type checker was even implemented, for example.
As for concerns... The main developer is a concern. Hard to trust them to support the language well, with some of the... Well, tantrums. This isn't aimed at a personal attack. But it is very hard to describe their responses in another manner.
This [0] thread on HN covers some of all of the above.
But, probably also important to point out that V and its drama have had dang threaten to ban the topic altogether [1]. There's a lot of drama.
n42
Oh. I fear that I have unwittingly summoned HN demons.
mirashii
https://news.ycombinator.com/item?id=39492680
See this article and the discussions, and if you’re so inclined follow along links in that thread from last time that show folks from the vlang team flaming all over HN.
baranul
Most of it looks like unprofessionalism among language creators, throwing haymakers at a competitor. Of course languages have significant technical differences, but that also pertains to their different goals, purposes, and users.
hyperbrainer
V looks exactly like one of the languages I was talking about. Some controversy about the project, it seems like, but very cool nonetheless. Even if it doesn't actually work like described, the description seems quite interesting.
> But I've had a few issues with the safety aspects of the language. Breaking through the checker isn't that difficult.
What do you mean? Can you "break through the checker" outside of unsafe blocks?
shakna
Its... Buggy. For example, fmt can currently break mutable handles. [0] Or you can modify immutable structures [1].
But there was a time where autofree was just a compiler flag and wasn't actually implemented, even though the author claimed that it was.
baranul
It's a language in beta and larger project (so more users). Take Zig for instance (also in beta), it has over 3,000 issues[0], and that's 3X more than Vlang. People run into problems using Zig all of the time. Any language can be claimed to be buggy or minor issues taken out of context.
square_usual
At least as of 2024 [1], V relies heavily on a GC for memory management, so I wouldn't really call it low-level.
[1]: https://justinas.org/the-bizarre-world-of-v#memory-unmanagem...
baranul
V's GC can be turned off. V's libraries do not rely on the GC. Check out their Vinix[0] project (where they built an OS). They have other such projects.
Better to review more balanced and neutral takes on V[1][2], where the reviewers are not just stirring up drama with their community or funneling traffic to their site.
[0] https://github.com/vlang/vinix
[1] https://www.youtube.com/watch?v=puy77WfM1Tg (Anthony GG reviews Vlang)
[2] https://www.youtube.com/watch?v=dmVKerNY-fQ (Mike Shah reviews Vlang)
square_usual
If you turn off the GC you need to manage memory manually, like in C. That is not "Memory safe".
> Better to review more balanced and neutral takes on V
Is anything I said factually wrong?
Cloudef
[flagged]
andrewflnr
F-star, which was used to build a verified TLS implementation. https://fstar-lang.org/ Though I guess that's actually on the far side of Rust relative to what you're looking for.
hyperbrainer
The full language is indeed even further ahead of Rust on the spectrum I am looking at, but this seems like a cool effort. I love proof-based languages and dependent types, so this is an absolute win.
What intrigues me quite a bit relative to the main topic of the HN thread is Low[0]
> Low is not only a language subset, but also a set of F* libraries that model a curated set of C features: the C memory model, stack- and heap-allocated arrays, machine integers, C string literals, and a few system-level functions from the C standard library. Writing in Low, the programmer enjoys the full power of F for proofs and specifications. At compile-time, proofs are erased, leaving only the low-level code to be compiled to C. In short: the code is low-level, but the verification is not.
[0] https://fstarlang.github.io/lowstar/html/Introduction.html#t...
thih9
(link from the description, clickable)
> Austral is a new systems programming language. It uses linear types to provide memory safety and capability-secure code, and is designed to be simple enough to be understood by a single person, with a focus on readability, maintainbility, and modularity.
fpoling
Austral GitHub has not received any significant updates for the last two years so I suppose the language development stopped.
efficax
https://dlang.org/articles/safed.html check out the safed subset of the D language
hyperbrainer
Unfortunately, it seems to use a GC for the safety, which makes it unsuitable for a variety of tasks in the systems programming domain. Seems to me like an alternative to Go more than Rust or C or Zig
skavi
D has a “BetterC” subset that depends only on a C runtime. Presumably there is some overlap with the “SafeD” subset.
Curious if there are any D users here who try to stay within that intersection?
rurban
On the contrary GC is very suitable to systems programming.
The bigger problem is guaranteeing concurrency safety, which you can only provide with nonblocking IO. Everybody loves blocks though, so that's far away.
ksec
>it seems to use a GC for the safety, which makes it unsuitable for a variety of tasks in the systems programming domain.
That depends. It is really a Hard NO for GC?
Crystal is low level enough with a GC and people have written a complete OS with it. On my mobile now so I can't provide link. But it was featured on HN a while ago.
fithisux
I second that
sn9
You might try OCaml [0] or SML [1] if you want speed, memory safety, and an expressive type system.
[0] https://ocaml.github.io/ocamlunix/index.html
[1] https://matt.might.net/articles/best-programming-languages/#...
modeless
C can be memory safe now! https://github.com/pizlonator/llvm-project-deluge
Yes, this is a real project that really works. It can compile real and widely used software written in C including SQLite, OpenSSL, and CPython, giving them true memory safety without escape hatches.
reirob
Thanks for sharing this. I was not aware about this project. Quite impressive they got sqlite and openssl compiling.
From their manifesto [1]: "The biggest impediment to using Fil-C in production is speed. Fil-C is currently about 1.5x-4x slower than legacy C."
And for the moment being it is running only on Linux/X86_64, even though there should be nothing preventing it from running on other platforms.
[1]: https://github.com/pizlonator/llvm-project-deluge/blob/delug...
jedimastert
Side question and possibly off topic, but is there a formal definition to the term "memory safe"? It seems to mean different things to different people and I'm unsure if I'm just out of the loop and there is an actual definition.
addaon
A memory safe language is one for which (a) there is a subset of programs which can be statically proven to not perform unsafe memory operations at runtime and (b) no programs outside of this subset will be accepted. The set of operations that are considered to be unsafe can vary, but always includes writes to unowned memory, and often includes reads from unowned and/or uninitialized memory.
fpoling
Vale is interesting, https://vale.dev/
For memory safety compared with Rust it does not use a borrow checker for the price of more checks and extra memory usage at runtime while avoiding GC or even reference counting.
I think this is very interesting trade off. Plus there are plans to implement few interesting ideas that even Rust type system cannot implement while keeping the language simple.
gwbas1c
> I am looking for memory-safe languages that can be used for systems/graphics programming.
C# was kinda-sorta for this; as long as you're targeting an environment where GC is acceptable. (IE, as long as you're running in user-mode, as opposed to writing a kernel or a driver.)
It does allow for C-style pointers, which might be useful if you need to call a lower-level system API. (Unfortunately, you can't just suck in a header file.)
One thing you might miss is how errors, in Rust, are 0-cost. C# encourages exceptions over error codes, and throwing an exception has a much higher overhead than panic, because it captures a stack trace and allocates an object. (I must admit that I like Rust's error handling over C# because it differentiates cleanly "anticipated" errors versus exceptional situations.)
I am looking for memory-safe languages that can be used for systems/graphics programming. I love Rust, but it often feels like too massive a language with too much stuff going on. Is there a language like C, which is simpler (obviously without all the UB and other problems)?
This is an especially hard ask, given how useful the FP-like features of Rust are, and I find it almost impossible to live without them. Basically, I am looking for a middle ground between C/Zig and Rust.
One such language I have found is Austral[0]. What other such languages are there?
[0] https://austral-lang.org/