Ask HN: What less-popular systems programming language are you using?

> The fact that zig can compile C code makes it useful for other languages too

Agree, C interop is IMHO the big feature of Zig. There are plenty of systems programming languages in 2025, but where Zig shines is its pragmatism: a single standalone binary containing compiler, libc, build system, code formatter and test runner for C and Zig.

As of late though, I've been concerned with some "holy wars"/"ideological postures" that the dev team started which IMHO departs from the original "let's be pragmatic" mantra.

- There's a bunch of places where the stdlib just crashes on unreachable assertions, and that won't be fixed "because the kernel should have better error reporting".

- There are a bunch of kernel syscalls which are just not possible to call "because C enums should not allow aliases"

- etc

I hope this trend fades away and it gets back on a more pragmatic stance on these issues, nobody wants a systems programming language that plays the programming police.

Otherwise, C3 looks promising as well (though not as nice than Zig IMHO), but currently it's a bit too barebone to my taste. There no stable LSP, no nvim plug-in, etc.

I like Perl mostly because it's poetic (the code is super nice to read, with variable types standing out thanks to sigils), but another core strength is how very fast and light it is.

Instead of "cross-compiling" or just running a native perl interpreter (there's one for about every platform!), I prefer how Actually Portable Executables make Perl multiplatform with just 1 binary asset running everywhere!

I wanted to write a webserver processing CGI to learn more about the "old school web", so I wrote https://github.com/csdvrx/PerlPleBean and the simplicity of just downloading and running the .com on anything is very nice

I'm now trying to do the same in Python3, but it's not as fun - and I'm not yet to the part where I will try to safely run python code within the python webserver, either through restrictedpython or ast.parse(), ast.walk(), eval(compile()) ...

You are right, the stdlib is not the highest priority right now. There are major improvements coming in 0.14 though. The new default allocator for example. I think the problem you describe can be solved by having more contributors focussing on the standard library. With the compiler, there are bottlenecks which make onboarding new people hard. This is a smaller problem in stdlib.

It's such a new language, not even in 1.0.0 You won't really find companies willing to bet their livelihoods at such an early stage.

You can make your own though :)

Current progress is here: https://fsl.yellowapple.us/zig64/dir?ci=trunk

Right now it's just a bunch of WIP Zig interfaces for the N64's hardware, but the end-goal is to get it developed enough for homebrew gamedev.

Eventually, I hope to use Zig for N64 homebrew.

To get there, though, I need to implement Zig-ish interfaces to the N64's hardware, which is slowly-but-surely happening at https://fsl.yellowapple.us/zig64/dir?ci=trunk

What do you mean by "motivational?" Are you talking about how the creator is against adding new features to the language? I actually think that's perfectly fine. One of my favorite things about Odin is the simplicity; the entire language and all of its rules can be understood by reading the Odin overview document. I'm actually thrilled to have a creator that doesn't want to bloat the language.

I remember being turned off from it for the same reasons, in particular there were some fairly harsh comments directed to V's developer which felt a bit dog piley to me. Drama's long dead now.. It is a great language though. Closest to the language that would kill C for me so far, but not quite =D

> The syntax is also not very friendly IMO.

Very true. There's an alternate syntax for OCaml called "ReasonML" that looks much more, uh, reasonable: https://reasonml.github.io/

> (e.g. the lack of native 64-bit integers that MrMacCall mentioned.

They exist, I think you just mean `int` is 63-bit and you need to use operators specialized `Int64.t` for the full precision.

Why opam is bad? Compared to what? Could you elaborate

>The syntax is also not very friendly IMO.

Why do you think that the syntax is not very friendly?

Not saying you are wrong, just interested to know.

Have you tried esy?

Yes

Symbolic debugger seem to be going out of fashion

You’re wrong, not sure where you got that conception but the int32/64 distinction is in the core language, with numerous libraries (eg stdint, integers) providing the full spectrum.

The modules Int64 and Int32 and part of the OCaml standard library. You mentioned that it is needed dune or Janestreet in your comments to have this functionality. They are part of the standard library. Really, they are part of Ocaml core developments. Actually, for example, you even can use the library big-arrays with these types and int8, int16, signed, unsigned... even more you have platform-native signed integers (32 bits on 32-bit architectures, 64 bits on 64-bit architectures) with Bigarray.nativeint_elt as part of the standard library so all these types are there.

You also mention that Int32 and Int64 are recent, however these libraries were part of OCaml already in the 4.X versions of the compiler and standard library (now we are in the 5.3).

Note that in OCaml you can use C libraries and it is quite common to manage Int32, Int64, signed etc...

> F# v2

What does that mean?

https://en.m.wikipedia.org/wiki/Standard_ML

You´d be surprised.

In the 1980s, complete workstations were written in Lisp down to the lowest level code. With garbage collection of course. Operating system written in Lisp, application software written in Lisp, etc.

Symbolics Lisp Machine

https://www.chai.uni-hamburg.de/~moeller/symbolics-info/fami...

LMI Lambda http://images.computerhistory.org/revonline/images/500004885...

We're talking about commercial, production-quality, expensive machines. These machines had important software like 3D design software, CAD/CAM software, etc. And very, very advanced OS. You could inspect (step into) a function, then into the standard library, and then you could keep stepping into and into until you ended up looking at the operating system code.

The OS code, being dynamically linked, could be changed at runtime.

It makes logical sense to do imports that way when operator overloading exists. Otherwise your custom operators would look like:

    import other

    varA other.`+` varB

Which is very ugly. At that point, we might as well just go with the function name approach that languages like Go take:

    customAdd(varA, varB)

I suppose you could change it so operators are imported into the same namespace, and non-operators still require a separate namespace when referred to. But that makes it even more complicated in my opinion. I agree it's less obvious what's coming from where, but I think when your libraries have distinct responsibilities, it usually ends up being pretty straight-forward what function comes from where based on how it's named (if it's written well).

I didn't say it was novel. It's just not something you see in modern languages.

Should that make it uncool?

> You mean, something that Lisp does since the early 1980s?

Um, no. Debugging a macro in Lisp is a terrible experience while debugging a comptime function in Zig is brain dead simple.

Zig is the first "macro" system I've used that doesn't want to make me blow my brains out when I need to debug it.

Yes, I think that's what they mean.

Dart is better in some ways and worse in others.

1. It has an actually sound type system.

2. The language and standard library are waaaaaaaay ahead of Javascript.

3. The tooling is top notch. Better than JS/TS.

But on the other hand:

4. Way smaller ecosystem.

5. Debugging is worse if you're compiling to JS. The fact that the code you run is basically identical to the code you write in TS can be a big advantage. Only really applies for web pages though.

6. Type unions are way nicer in TS.

7. Non-nullable types interact badly with classes. It can make writing methods correctly really awkward - you have to explicitly copy member variables to locals, modify them and then write them back.

8. Way smaller community.

Embedded 8 and 32 bits microcontrollers to web linux based erp/crm softwares. Ada can be used for anything, with the speed of C/C++ but in a far more readable and safer way... Ada is a secret weapon. Don't spread theses infos ;)

I started using it recently for a prototype of something I'll eventually rewrite in C++ at work. I really like it.

Discarding the preprocessor and replacing it with a proper module system is huge. I got burnt by templates and horrifying compile times in C++, but haven't had any problems with D templates. The module system makes templates feel much more natural to use. The syntax for templates is a huge improvement, and throwing `static if` into the mix results in concise and easy-to-read code.

I also quickly realized (with the help of some people on the D discord) that the garbage collector is fine for my needs. So I don't have to spend any time thinking about memory management... put stuff on the stack when I can for speed, othrewise just GC and don't think about it. I think there may be some issue with multithreading and the GC, but this is supposed to get fixed with the new GC that's on the way.

There are a few other nice QOL improvements. Getting rid of `->` is honestly worth its weight in gold. There's nothing difficult about forgetting to change a `.` to a `->` or vice versa in C++, but not having to trip over it periodically when you're compiling makes the language that much smoother. I was also initially confused by the `inout` keyword but have come to really like that, as well. Little niceties like `const(T[])` are small but, again, reducing just a little bit of friction like this across the language makes D much, much more pleasant to deal with than C++.

I think the main challenge the language is facing right now is that it's huge and a lot of it is still getting worked out. I never thought I'd pine for C++'s "rule of 3/5/0", but it's a lot tighter and more logically consistent than the equivalent in D. But part of that is there being a huge community of C++ developers who have taken the time to promulgate rules of thumb in the community. I'd kill for an "Effective D" book to short circuit some of this process... after all, I'm trying to write code, not play at the margins, tinkering with D's idiosyncracies.

I've been playing with it hacking a compiler written in C++ to be sort of transliterated to D. Just to see if it then makes the compiler easier to read, while not worrying about the performance yet.

So far in converting the lexer it does make it more comprehensible, it will probably do the same for the parser and AST. The real interesting bit will be once I tackle the later stages.

Sure. Here are some resources:

* Span<T>: https://learn.microsoft.com/en-us/archive/msdn-magazine/2018...

* C# now has a limited borrow checker-like mechanism to safely handle local references: https://em-tg.github.io/csborrow/

* Here is a series of articles on the topic: https://www.stevejgordon.co.uk/writing-high-performance-csha...

* In general, avoid enterprise style C# (ie., lots of class and design patterns) and features like LINQ which allocate a lot of temporaries.

Span<T>, ReadOnlySpan<T>, Memory<T>, CollectionsMarshal, CollectionsExtensions, ref struct, ref return, ArrayPool, ArraySegment, ValueTuple, and using interfaces/structs/generics carefully.

That is if you don't want to get into unsafe code.

A few important ones: - Avoid memory allocations as much as you can. That's a primary thing. For example, case insensitive string comparisons using "a.ToUpper() == b.ToUpper()" in a tight loop are a performance disaster, when "string.Equals(a, b, StringComparison.CurrentCultureIgnoreCase)" is readily available. - Do not use string concatenation (which allocates), instead prefer StringBuilder, - Generally remember than any string operation (such as extracting a substring) means allocation of a new string. Instead use methods that return Span over the original string, in case of mystr.Substring(4,6) it can be a.AsSpan(4,6), - Beware of some combinations of Linq methods, such as "collection.Where(condition).First()" is faster than "collection.First(condition)" etc.

Apart from that (which simply concerns strings, as they're the great source of performance issues, all generic best practices, applicable to any language, should be followed.

There are plenty resources on the net, just search for it.

Pour one out for Midori, which would have replaced Windows with a capability-based OS completely written from kernel to shell in a C# dialect. Async/await, spans, and immutable support came from it, along with an (opt-in) Rust-like borrow checker. Satya canceled it, and all the work was lost to history. Singularity was the early public prototype.

[dead]

MASM was always horrible.

nasm has been lovely, but I haven't used in 10+ years. https://github.com/netwide-assembler/nasm

There are many independent consultants working in Lisp.

Yes, it is rare.

Requires open minded middle management and that is rare.

I maintain auto-generated Rust and Zig bindings for my C libraries (along with Odin-, Nim-, C3-, D- and Jai-bindings), and it's a difference like night and day (with Zig being near-perfect and Rust being near-worst-case - at least among the listed languages).

> Do you find zig easier than the ffi interface in Rust?

Yes, but it's mostly cultural.

Rust folks have a nasty habit of trying to "Rust-ify" bindings. And then proceed to only do the easy 80% of the job. So now you wind up debugging an incomplete set of bindings with strange abstractions and the wrapped library.

Zig folks suck in the header file and deal with the library as-is. That's less pretty, but it's also less complicated.

I've somehow avoided Rust, so I can only comment on what I see in the documentation.

In Zig, you can just import a C header. And as long as you have configured the source location in your `build.zig` file, off you go. Zig automatically generates bindings for you. Import the header and start coding.

This is all thanks to Zig's `translate-c` utility that is used under the hood.

Rust by contrast has a lot more steps required, including hand writing the function bindings.

Yes!

https://funcui.avaloniaui.net

https://github.com/fabulous-dev/Fabulous

(I'm sure there are more, these two are those which I could recall from the top off my head)

There's a bit of a struggle between sections that use just one or the other, but Elm has the managerial blessing right now.

While I think Elm is neat, it suffers from ecosystem issues. It drive a large amount of Not Invented Here because JS invented somewhere else is hard to incorporate. Also, good luck rendering arbitrary HTML that comes in as data from somewhere else.

I learned it once long ago, but never used it for anything other than that learning experience. I did like its concepts, though the language itself didn't quite stick with me.

This was in an embedded systems context, I came on later but it was what most of the core system was written in. It's been used in a lot of avionics systems over the years.

Modern Fortran has ISO C bindings in its standard library. You can call any C library from Fortran and wrap it in a Fortran module if you want to make it easier to use.

Despite its history it is a pretty modern language if you enable all warnings, set implicit none and ignore the old style of coding (a la FORTRAN 77 of older).

These days, we have many better options, but back in the day, Fortran was also used for compilers (e.g., IBM's Fortran H), operating systems (such as PRIMOS[0] and LTSS[1]), symbolic computation (e.g., early Prolog implementations), and real-time control systems[2].

[0] https://en.wikipedia.org/wiki/PRIMOS

[1] https://en.wikipedia.org/wiki/Livermore_Time_Sharing_System

[2] https://webhome.weizmann.ac.il/home/fhlevins/RTF/RTF-TOC.htm...

not a direct answer to your question, but the use in the domain you mentioned itself, is huge.

from the Wikipedia article about Fortran, under the Science and Engineering section:

https://en.m.wikipedia.org/wiki/Fortran

Although a 1968 journal article by the authors of BASIC already described FORTRAN as "old-fashioned",[58] programs have been written in Fortran for many decades and there is a vast body of Fortran software in daily use throughout the scientific and engineering communities.[59] Jay Pasachoff wrote in 1984 that "physics and astronomy students simply have to learn FORTRAN. So much exists in FORTRAN that it seems unlikely that scientists will change to Pascal, Modula-2, or whatever."[60] In 1993, Cecil E. Leith called FORTRAN the "mother tongue of scientific computing", adding that its replacement by any other possible language "may remain a forlorn hope".[61]

It is the primary language for some of the most intensive super-computing tasks, such as in astronomy, climate modeling, computational chemistry, computational economics, computational fluid dynamics, computational physics, data analysis,[62] hydrological modeling, numerical linear algebra and numerical libraries (LAPACK, IMSL and NAG), optimization, satellite simulation, structural engineering, and weather prediction.[63] Many of the floating-point benchmarks to gauge the performance of new computer processors, such as the floating-point components of the SPEC benchmarks (e.g., CFP2006, CFP2017) are written in Fortran. Math algorithms are well documented in Numerical Recipes.

My first Fortran program was a tool I wrote to read 8" SS/SD CP/M floppies on a minicomputer. That was very easy to do, as the dialect had a couple of useful string extensions and the operating system had efficient ways of reading a floppy.

hare-ev [0] is using epoll under the covers, which means multithreading is there, already. Especially as ev may be merged into the stdlib at some point.

[0] https://git.sr.ht/~sircmpwn/hare-ev

You could always link to pthread and use that in your Hare code, no?

Makes sense

It is a html link and a subdomain name that is the same as a protocol.

Here pdf link:

https://dl.acm.org/doi/pdf/10.1145/263698.263754

https://folklore.org/Hungarian.html:

“The Macintosh used the same Motorola 68000 microprocessor as its predecessor, the Lisa, and we wanted to leverage as much code written for Lisa as we could. But most of the Lisa code was written in the Pascal programming language. Since the Macintosh had much tighter memory constraints, we needed to write most of our system-oriented code in the most efficient way possible, using the native language of the processor, 68000 assembly language. Even so, we could still use Lisa code by hand translating the Pascal into assembly language.”

MacOS was clearly Pascal-oriented, with its ‘Str255’, ‘Str63’, etc. data types.

Definitely agree that there are rough edges, but Nim is in a better state than ever. The LSP isn't great yet, I'll agree with that. There are great optional type libraries for working around exceptions if you don't want them, and the new memory management system (ARC/ORC) is very efficient compared to the old refc implementation (now much more like the C++/Rust approach).

For parallel programming, there are also handy libraries. The best of which is Weave[1], but Malebolgia[2] is authored by the creator of Nim and works well in its own way too.

There is also active work being done on a new implementation of Nim which intends to clean up the some of the long-term spaghetti that the current implementation has turned into (like most long-term projects do), called Nimony[3], and is also led by the original creator of Nim. It is years away from production according to him, but is at least in the works.

I'd have to say Nim is by far my favorite programming language. The terseness, flexibility, and high performance, make it feel almost sci-fi to me. My only major complaint currently is the tooling, but even the tooling is still adequate. I'm glad it exists. Highly recommend.

[1] https://github.com/mratsim/weave

[2] https://github.com/Araq/malebolgia

[3] https://github.com/nim-lang/nimony

Yes please!

Tooling is pretty good; Ada has a package manager similar to Cargo (Alice: https://alire.ada.dev ), and you can install it pretty easily via GetAda ( https://getada.dev ), which brings in the compilers and any libraries you'd need. (disclaimer: I'm the author of GetAda)

Desktop apps: definitely. There's bindings for various UI toolkits like GTK and I know of a few people working on games in Ada, usually thick bindings like SDL: https://github.com/ada-game-framework and https://www.youtube.com/playlist?list=PLn3eTxaOtL2Oxl9HbNOhI... There's also Gnoga, which is similar to Electron for writing UI apps: https://github.com/Blady-Com/gnoga

A bunch of libraries for various drivers or other useful things on https://alire.ada.dev/crates.html (to include something like "ada_gui" in your ada project, you would just use alire, e.g. `alr with ada_gui`).

Much of Ada's webapp functionality is either interfacing with the Ada Web Server or gnoga (I've written a few servers using Ada Web Server, including one for an ".io" game).

There's an LLVM compiler which in theory can produce wasm but I've not messed with it: https://github.com/AdaCore/gnat-llvm

Mobile platforms can be targetted and cross-compiled in Alire, but I'm not sure who's doing it right now.

For anyone interested, I definitely recommend checking out some of the presentations of Ada's recent FOSDEM dev room https://fosdem.org/2025/schedule/track/ada/

Your favourite job board will have a tag for Ada. There are jobs out there. Some in lower level things like finance, reliability testing, embedded software. Some in higher level things like gaming, AI, web services.

There are fewer, and they do tend to be more demanding, but they certainly exist.

Huntsville Alabama has some

It’s a little like go in that it compiles quickly enough to replace scripts while still yielding good enough performance for a lot of systems tasks. It predates go and I wish Google had just supported D, it’s a much nicer language IMO

Fun side projects mostly, my GH username is the same as here if you’re (morbidly) curious.

It's quite funny to classify it as such, given you need to run your programs like a script as it's nearly impossible to compile a binary you can distribute (though I am aware they're working on this as a priority task, currently).

It's certainly not a traditional one, but it is increasingly used as one https://arxiv.org/abs/2502.01128.

Anything written by Treeform[1] is a good place to start, their libraries make up a big chunk of Nim ecosystem.

1 - https://github.com/treeform/hobby

Honestly hard to say. There are a number of styles of architecting Nim libraries and programs, and almost none match my own. My most particular criticism of the Nim ecosystem is the abuse of macros: There are a number of libraries implementing huge chunks of functionality behind macros such that code paths only appear at compile time and are not reflected in sources. Some libraries constrain macro use, but many are built entirely out of macros. I'd say to avoid looking to those examples.

I do not.

These days I would reach for a shell script for general scripting, filling in the gaps with maybe a C# console app or something in Common Lisp if I want/need some interactivity.

Something that happens pretty frequently is I'll take information I've written into an emacs org doc and run it through a CL function, whose output could be an org mode table which I can from there export to a different document format if necessary.

fasm is indeed great. It has many features, it can do all the code size optimizations, it even knows the sizes of variables (e.g. `mov myvar, 5` depends on `myvar db 0` vs `myvar dw 0`). NASM and fasm syntax are quite similar.

NASM supports more output file formats (i.e. .o files for many systems), and it can receive macro definitions from the command line (e.g. `nasm -DDEBUG`).

It is, but it's really on life support. It's supported for legacy development in the most part. There are so few people coding in it now you'll never see any example or tutorial .NET code in VB.NET.

it is still supported and developed.

Good, safe, code tends to come from Discipline, Humility, and thoroughness.

I've known many highly experienced and intelligent software devs that are terrible at that stuff, and are like coding time bombs.

This is my thought, also (it was basically a joke).

Another "unpopular" language, is PHP: https://w3techs.com/technologies/history_overview/programmin...

I personally find it much more ergonomic to have the allocator attached to the type (as in Ada). Aside from the obvious benefit of not needing to explicitly pass around your allocator everywhere, it also comes with a few other benefits:

- It becomes impossible to call the wrong deallocation procedure.

- Deallocation can happen when the type (or allocator) goes out of scope, preventing dangling pointers as you can't have a pointer type in scope when the original type is out of scope.

This probably goes against Zig's design goal of making everything explicit, but I think that they take that too far in many ways.

Same can be said about Borrow Checker.

+1, it is my go-to language whenever I have no idea how complex the task will get

heh. same.

I wish we lived in a world where Crystal dominated over Go, but we're far from being there.

Admittedly, the slowness of the compiler (due to the nature of the language), and lack of better tooling are not helping, but 9 out of 10 times I enjoy way more writing Crystal than Go.

I think Crystal is going to need much more community support (articles, tutorials, blogs, community) and corporate sponsorship for it to even thrive in today's environment where we have an abundance of choices.

IIRC, I read somewhere, several months ago ago, that its type inference made it slow to compile anything but small programs?

Me too buddy, super powerful, syntax is a little weird but once you get used to it..

gen servers, everywhere.

Looks like Prolog.

I wonder what the major differences are.

What kind of profits are you seeing with it?

Nice to hear! I will definitely give it a go now. It was on my list.

I'm lurking so far, but looks like just what I was searching for. Thanks!

Thanks. I managed to find a build of sublime that kinda works (menu bar issues), but not figured out code completion, just seems to spam recent tokens at me. I had a look at Zed thanks, but didnt fancy the tight AI integration stuff. I'm a bit grumpy old mad and like my tools totally offline.

Build system, module system, simplicity of C but much nicer, clearer syntax, lots of batteries included, it just does a lot of stuff to make life easier versus Zig or C/C++.

I personally don't think programming paradigms like OOP, procedural or functional make anything easier/harder necessarily, just talking QoL stuff.

And obviously "easy" is relative: Odin is still a low level language where you need to manage your own memory.

I've generally found it to be within a factor of 2 of hand-tuned C. (It's literally autogenerated C.) But implementation matters, and I doubt we're going to check your work here in the comments.

Lots! [1]

The biggest thing to be added recently is GPU programming, which given Mojo's focus on ML/AI makes a lot of sense.

It's probably not the best language to look into for general purpose systems programming, but if you are going to be interacting with GPUs or other hardware then maybe it's good to give it a look.

It is still changing a lot, so no real stability yet, but to be expected for such a young language.

[1] https://docs.modular.com/mojo/changelog/

Roc was inspired by Elm, and has CLI as one of its "platforms", which is systems in a loose sense. Early days for Roc, though there may be orgs using it in productiom.

So to be fair, "extremely simple to grasp" because looked at superficially. Once you dig into it, there is a lot happening in there. Both in what can go into an actual production grammar, and what is present in the parsing output. which is why I was mentioning learning curve.

But yeah, most stuff is easy, there is more than one way to do it, and the impossible isn't. Or something.

All sorts of algorithms for processing data useful in high-load scenarios: checksum calculation, text searching/analysis/transformation, data compression, networking (request analysis, routing, filtering), interop with other C ABI dependencies, etc.