I've pretty much settled on Zig at this point, if only for how dead-simple it is to cross-compile for other hardware platforms. The process of compiling working code for oddball platforms (in my case the Nintendo 64) was way easier than I expected it to be.
The only downside is the stdlib being as fast-moving of a target as it is. Right now I've had to put a pin on getting panic stack traces to work on my N64 code because apparently the upcoming release changes a bunch of stuff around panic/stacktrace handling (and it's already changed quite a bit over the years even before these new changes).
> The only downside is the stdlib being as fast-moving of a target as it is.
Ah that's an interesting take, my opinion is that the stdlib doesn't move fast enough.
In its current state it's pretty broken, most of the "process", "os" and "posix" modules are either straight up raising unreachable in normal scenarios, or simply badly designed. I would like the stdlib to be much more fast moving and fix all these issues, but I had the impression most work on it is frozen until 0.15 or 0.16, after incremental compilation is done.
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.
> I think the problem you describe can be solved by having more contributors focussing on the standard library.
I don't think so, my impression is that stdlib improvements are volontarily frozen for now, not because of a lack of contributors but because of a lack of clear plan as to what the stdlib should look like. There are a number of issues and PR of people willing to contribute to stdlib that are stalled.
That's not to say that's its bad per se, "we don't have a plan for now and don't want people to commit time for an unclear target" is a perfectly OK answer.
> how dead-simple it is to cross-compile for other hardware platforms
The fact that zig can compile C code makes it useful for other languages too.
I recently started using `zig cc` to cross-compile Nim for lots of different platforms within the same environment.
It takes no time to setup and, honestly, works like magic.
> 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()) ...
100% depends on how it’s written. It gives a ton of flexibility regarding incorporating “magic variables” which can lead to incredibly abstruse code. The language motto is “there’s more than one way to do it”, and that’s implemented to a fault.
I've been using Odin [1] for my hobby game development and I've been liking it a lot. Feels like a more ergonomic C.
Things I like:
- Vendor libraries like Raylib and MicroUI make it easy to get started
- I can pass around memory allocators and loggers implicitly using context, or explicitly if I need to.
- natively supports vector math and swizzling
- error handling with `or_else` and `or_return`
Things I don't like:
- Name spacing is a bit annoying. The convention is to prefix the procedures but I don't like how they look. It really isn't a big issue.
Have a quick read of the overview and if you are still interested, I highly recommand 'Understanding the Odin Programming Language' book by Karl Zylinski [2]
I like Odin, but the creator is not too motivational (or rather, actively un-motivational)[1]. I still use it nonetheless for some of my own stuff, for now.
Regardless, I do recommend people to try it out. I use Linux and OpenBSD, too, despite Linus and Theo. :)
[1] The reason for why I think this can be found in their pull requests, but it's been some time I think.
I want to like OCaml but OPAM is just so bad... and tooling is super important (it's one of the reasons Go is popular at all). Windows support is also an afterthought. There's no native debugger as far as I can tell. This is before you even get to the language which definitely has its own big flaws (e.g. the lack of native 64-bit integers that MrMacCall mentioned.
The syntax is also not very friendly IMO. It's a shame because it has a lot of great ideas and a nice type system without getting all monad in your face. I think with better tooling and friendlier syntax it could have been a lot more popular. Too late for that though; it's going to stay consigned to Jane Street and maybe some compilers. Everyone else will use Rust and deal with the much worse compile time.
It's my understanding that OCaml does not allow its programs to specify the size and signedness of its ints, so no 16-bit unsigned, 32-bit signed, etc...
Being a huge fan of F# v2 who has ditched all MS products, I didn't think OCaml was able to be systems-level because its integer vars can't be precisely specified.
That would be mix of D, Object Pascal, Swift, Ada, C#, Java.
A few decades ago plenty of Oberon dialects.
As language geek, I randomly select languages when doing hobby coding.
Regarding Go's remark, even if I dislike Go's authors decisions, back in my day writing compilers, linkers, firmware, networking stacks, and OS services was considered systems programming.
Likewise .NET team has been making wonders catching up to what C# 1.0 should have been for low level code, given its Delphi linage.
Java, in the context of being whole Android userspace, including drivers, there is very little systems exposed in the NDK. Vulkan is one of the few things not exposed to Java land, and that is being fixed with WebGPU like API in an upcoming version.
Loving Ada without using exceptions or inheritance on embedded and desktop. Some love Ada full OOP tagged types. I love Ada procedural style with privacy and abstract data types. I wish Flutter was written in Ada but atleast Dart is better than JavaScript atleast for procedural code without it's oop boiler plate. You don't actually need OOP for widgets.
But is Dart better than Typescript? I prefer Typescript for multiple reasons but one of them is that you don't have to use classes to use the advanced typing system. Without a typing system I like Ruby the most, but sometimes we just need a typing system.
C#. While a popular language, it is criminally overlooked for high-performance programming. Obviously, you can't use it for embedded or kernel development. For other use cases though, it can almost reach the performance of C/C++/Rust when written with proper care.
Embedded is diverse. I would not use .NET for small embedded, i.e. stuff running on Arduino or ESP32.
However, I have successfully used .NET runtime in production for embedded software running on top of more performant SoCs, like 4 ARMv7 cores, couple GB RAM, Linux kernel. The software still has large pieces written in C and C++ (e.g. NanoVG rendering library) but all higher-level stuff like networking, file handling, and GUI are in memory-safe C#.
You actually can use it for embedded and kernel development! See .NET Nano Framework [1] for embedded - works on microcontrollers like ESP32. For kernel development there's nothing really built in to support it but people have built tools [2] to do 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.
The only thing Singularity and Midori share is the idea.
You should also pour one out for Longhorn, where internal politics tanked the idea, and eventually Windows team redid all those .NET based ideas into COM/C++, and were even proud of doing so (see Hilo sample documentation), hence why nowadays COM based libraries are the main way to expose modern Windows APIs (aka post Windows XP).
Had they collaborated instead, probably Windows would be closer to something like Android userspace nowadays.
Or for Ironclad, another one from Microsoft research, lesser known, also from the same research group, which even includes type safe Assembly,
Microsoft Research has plenty of work in such domains, they also had a LLVM like compiler framework, based on MSIL, called Phoenix, among other stuff, e.g. Dafny, FStar, Drawbridge, also come from OS projects.
Unfortunely classical Microsoft management has been more like it isn't Windows, it isn't shipping.
Partly off-topic: which well-known companies have research groups? I knew about Microsoft and IBM. Google, probably. Others? Might be interesting to browse their sites for nuggets to explore or use.
I sometimes write C# in my day job. But I think I don't know much about how to write really fast C#. Do you have any recommendations for learning resources on that topic?
LINQ is fine (but enterprise style never is, yes), it’s a matter of scale and what kind of a domain the code is targeted too. C# needs to be approached a little like C++ and Rust in this regard. Having standard performance optimization knowledge helps greatly.
Also can recommend reading all the performance improvements blog posts by Stephen Toub as well as learning to understand disassembly at a basic level which .NET offers a few convenient tools to get access to.
Thank you. I once read a bit about Span<T>, but some of this reference stuff is very new to me. Interesting, definitely. C# really is a big language nowadays...
Spans are just a slice type, but those which any type based on contiguous memory can be coerced to (usually). I’m sure you’re already using them somewhere without realizing that. Their main use case in regular code is zero-cost slicing e.g. text.AsSpan(2..8).
Trying to write it as if it was a different language instead or, for whatever reason, copying the worst style a team could come up with does happen and must be avoided, but that’s user error and not a language issue. Also the tooling, especially CLI, is excellent and on par with what you find in Rust, far ahead of Java and C++.
If you link an example snippet of the type of code that gave you pause, I’m sure there is a better and more idiomatic way to write it.
It's a heavily gamed benchmark, but TechEmpower Fortunes is pretty good at revealing the max throughput of a language runtime for "specially tuned" code (instead of idiomatic code).
I judge more idiomatic / typical code complexity by the length of stack traces in production web app crashes. Enterprise Java apps can produce monstrous traces that are tens of pages long.
ASP.NET Core 9 is a bit worse than ASP.NET Web Forms used to be because of the increased flexibility and async capability, but it's still nowhere near as bad as a typical Java app.
What matters in practical scenarios is that ASP.NET Core is significantly faster than Spring Boot. If you have a team willing to use ActiveJ or Vert.x, you are just as likely have a team willing to customize their C# implementation to produce numbers just as good at web application tasks and much better at something lower level. There are also issues with TechEmpower that make it highly sensitive to specific HW/Kernel/Libraries combination in ways which alter the rankings significantly. .NET team hosts a farm to do their own TechEmpower runs and it just keeps regressing with each new version of Linux kernel (for all entries), despite CPU% going down and throughput improving in separate more isolated ASP.NET Core evaluations. Mind you, the architecture of ASP.NET Core + Kestrel, in my opinion, leaves some performance on the table, and I think Techempower is a decent demonstration of where you can expect the average framework performance to sit at once you start looking at specific popular options most teams use.
Free Pascal, but I am interested in Ada and will be learning it more this year. I love the readability of the syntax, and on the outside looking in, the community seems good.
I have also moved back hard to using TCL as my scripting language. I like it too much, and bouncing between Python, Go, and such for DevOps glue tires me out.
For systems, I love using plan9 (9front) to solve problems, which grounds me to C, awk, sed, and the rc shell.
My major system programming languages are C and C++, but I did some projects in Oberon (which turned out to be not particularly suited for systems programming), and then created a modified, better suited version of it called Oberon+ (https://github.com/rochus-keller/Oberon), which I e.g. used to create platform-independend versions of different Oberon System generations.
But Oberon+ is still too high-level for many system programming tasks. So I'm designing a new system programming language called Micron (for Micro Oberon, see https://github.com/micron-language/specification) which has the full power of C without its disadvantages. You can even use it for the OS boot sequence when there is no stack and no heap, but also for higher-level application development, due to its selectable language levels.
I recently dabbled in "hare" which was quite a nice experienced.
I liked how the language stayed pretty simple compared to other C-replacements. The standard library is also pretty nice. It is however an extremely niche language, but still quite capable
I was pretty excited about Hare until Devault said that Hare wouldn't be doing multithreading as he preferred multiprocessing. That was a pretty big dealbreaker for me. The rest of the language looks quite clean though!
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.
I am currently contracted 3 days a week writing Zig. I can't say much because NDA, but I just love working with Zig almost every day. I think for the right projects, it is such a great choice for mission critical software.
You get the added benefit of being able to easily consume C libraries without much fuss. The fuss is in navigating the C APIs of decades old libraries that we all still depend on every day.
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.
F#! I’m in love with the language. It is my defacto pick for most things these days. Very expressive AND strongly typed. Being a part of the .Net ecosystem is also a plus.
I've also gotten it working with FNA. I haven't done anything too elaborate in the game development world, but as far as I can tell there's really no limitations imposed by F# in that front.
I'm not very good at using it, but every now and then try to do a small project in Chicken Scheme. Mostly I'm unsuccessful, but I enjoy the language a lot and have a great time using it.
I started using Idris a few years ago because the idea is fascinating. Such as state machines in your type system, the size of a list being defined in the static type system, even if the list size changes over time (pretty mind blowing), etc..
But ultimately I realized that I’m not writing the type of software which requires such strict verification. If I was writing an internet protocol or something like that, I may reach for it again.
Similar boat. I've read about Idris (and been 'shown the door' enough times) and I love the idea of it, but sadly I haven't yet had any reason to use it.
Every now and then Freepascal with Lazarus but the same bug being in the IDE for ten years plus kind of annoys me. If I save a new project and I move any files around it does weird stuff, or if I rename a module.
Theres also D but finding libraries for whatever I want to work on proves problematic at times as well.
OK, here's a pretty niche blast from the past: the boo programming language. It ran on the CLR (.NET) and had syntax similar to python. I recall using it back around 2006 - 2008 because it offered scripting features for .NET on Windows.
https://boo-language.github.io/ "A scarily powerful language for .Net". I didn't use it for too long before switching to Iron Python.
zig is coming along quite nicely. If you've not heard about zig, take a look at https://ghostty.org/ (a terminal for Linux/Mac and Windows in future), https://tigerbeetle.com (a database for financial accounting) and http://bun.sh (a modern, faster alternative to nodejs).
Coming from a more Python/Java/PHP/JS background, Elixir was a lot easier to pick up and doesn't frustrate me as much. Most of the remaining scary bits involve concurrency and process supervision trees.
Macros are powerful, but also easy to use in a way that makes everything hard to debug. For those unfamiliar with them, it's a bit like a function except any expressions you call it with are not evaluated first, but arrive as metadata that can be used to assemble and run new code.
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.
Yeah, I loved Elm, but the restriction that you can't build your own "effect" modules really made it impossible to embrace. Say you want to use a new web API similar to using Elm's core `Http`, well... you can try and fork Elm...
The only true "system programming" I've done was in Microsoft Macro Assembler, a product I grew to hate with a passion.
A non-answer, but tangentially relevant:
I once fiddled with Forth, but never actually accomplished anything with it.
Several OSs are written in Lisp; in some of them the difference between OS and application is a bit vague. At the time none of them were available to me to play with.
I discovered Oberon and fell in love. My first real programming language was Pascal, and Oberon is part of the same family. Oberon consisted of a compiler, operating system, user interface, application software, and tools, all self-hosted on Oberon. There was even an Oberon CPU at one time. But Oberon turned out to be just an academic curiosity, and wasn't available for any hardware I had access to anyway.
“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.
Pascal interfaces and direct 68k ASM for the first years of Macintosh. C language bindings were third party and discouraged by Apple. There were good reasons for that in those days IMHO, since C came with a lot of Unix software libraries and people would demand that the science libs run. Apple said "no" but third parties built the compilers anyway. Many developers were attracted to Michael Kahl's brilliant ThinkC system, later to MetroWerks. MPW built a more *nix-like environment eventually, also.
source: C language developers for the Macintosh OS
even early Windows versions were somewhat Pascal-oriented, with things like "long far pascal" used in C function declarations, to indicate the calling convention being used, whether right to left, or left to right, iirc.
Not presently, but not long ago, Fortran and Ada. I still like Ada better than the alternatives, especially as it's changed this past couple decades. I find it hard to miss Fortran, though. I'd consider it for scientific computing and that's about it, which isn't my present domain.
Did you ever check out Eiffel for systems programming work?
I had been checking it out some years ago, and apart from the general points about it, one use of it that I found interesting was in an article about using it for creating HP printer drivers. The author had mentioned some concrete benefits that they found from using it for that purpose.
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.
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].
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.
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.
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)
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).
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.
I had played around with D some time ago, and wrote some small programs in it for fun and learning. I both liked and disliked things about the language.
there was some Russian dev running a systems tech company, I forget his name, living in Thailand, like in koh samui or similar place. he used D for his work, which was software products. came across him on the net. I saw a couple of his posts about D.
one was titled, why D, and the other was, D as a scripting language.
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
Nim is great, I wrote a crypto trading engine with it. The performance is excellent, memory safety works well, and it was much easier to write compared to Rust.
That said, the edges are still (very) rough when it comes to tooling (generics and macros absolutely murder Nimsuggest/lsp) and also "invisible" things impacting performance such as defect handling (--panics:on) and the way the different memory management schemes introduce different types of overhead even when working with purely stack allocated data.
But even with all that it's still an extremely pleasant and performant language to work with (when writing single threaded programs at least)
I do systems programming in i386 (32-bit) assembly language with NASM.
For me it doesn't scale beyond a few dozen kilobytes (executable program file size) per program. For others (such as Chris Sawyer) assembly scales much better.
Nim. Fantastic choice for modern headless software. Simple obvious type system, preference for immutability and referential transparency. Dynamic collections are by default managed by hidden unique pointers on the stack. So the default RC isn't necessary unless explicitly invoked for a ref type.
Currently solo managing a 30k line data analysis application I built for my company. Easily fits in my head given the obvious pyramidal functional-like structure. Maybe two lines of memory semantics anywhere in the entire thing, and only one module that's OO with a constrained scope. Lots of static data files (style sheets, fonts) slurped up as const strings at compile time. Incredible performance. Invoked by our PHP server backend, so instead of doing parallel or async in the analysis, the server gets that through batch invocation.
Working stupid well for our product, plus I can easily compile binaries that run on ARM and RISC-V chips for our embedded team just by invoking the proper gcc backend.
Replaced an ailing and deliberately obfuscated 20 year old jumble of C and PHP designed to extort an IP settlement from my company. Did it in a year.
I am using Haxe which compiles to other languages (C++, JavaScript, PHP...). This is a nice language when you want to create a web application or a even a CLI.
If you have played video games by Shiro Games (Evoland, Dune Spice Wars) or Motion Twin (Dead Cells) or even Paper Please!, then you had been exposed to this language.
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).
I have been watching with interest. I can't help but think Rust will easily win. Zig isn't different enough, and it's somewhat opinionated (in good ways but not always clearly better)
Perl is kinda less popular now. I use that at work. Used to write perl6/raku in my previous job, I loved the grammars made a nice way to try and Wirte an nginx configuration manager.
We still use it for all kinds of web services development work, mainly because there's years of in-house modules for everything and the malleability Perl has.
i don't know if pike counts as a systems language, but i consider it an alternative to C, if only because it has good C integration so that you can easily include a module written in C. pikes syntax is also very close to C, which may be appealing to some (ironically that's an aspect i don't really care about myself)
if the question of go being a systems language is controversial, then pike is even more so. i would situate pike somewhere between python and go. pikes major drawback is that it doesn't produce standalone executables.
the real question i'd like to ask is, what actually is a systems language?
It certainly doesn’t run like C. I once thought to port my JSM machine learning engine to python and it felt Cython might just be what I needed. Simply put it’s tight loops doing bitwise ops on bit-vectors. In reality no amount of adding type annotations would help the thing was slower then C++ by an order of magnitude.
Tried trying zig, but was baffled by all the allocator dance you need to do and asking nicely to access a list (catching potential exceptions?)
Tried odin, but the tooling is very raw.
Tried rust, didnt want to try to please borrow checker that distracts me from my thoughts.
Idk, if someone just reinvents clean C without the nonsense garbage with some modules and package manager this will be a huge win. Let me access my null pointers, let me leak memory, just get the hell out of my way and let me program and hold my hand only where I want it to be held - sane types that give me refactoring, code completion and code understanding, modules with imports. Let compiler give sane error messages instead of this cryptic c++ garbage. Is this too much to ask?
I also had a brief look at Zig for writing a WASM module, but settled for Rust. I had no real gripes with the language, but the spartan documentation made making progress into a slog.
I wouldn't mind a "better C" that could use an LLM for static code analysis while I was coding. I.e. be more strict about typing, perhaps. Get out of my way, but please inform me if I need more coffee.
Allocation in Zig takes some getting used to but it's actually really nice. It took me a few weeks but I honestly believe you should give it another chance and more time
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.
There is no reason you can't attach an Allocator to the type (or struct, in Zig).
A fairly common pattern in the Zig stdlib and my own code is to pass the allocator to the `init` function of a struct.
If what you mean is that allocation should be internal to the type, I don't agree with that. I much prefer having explicit control over allocation and deallocation.
The stdlib GPA for example is pretty slow, so I often prefer to use an alternative allocator such as an arena backed by a page allocator. For a CLI program that runs and then exits, this is perfect.
C's compilation unit model, lack of a formal module system and lack of language-level package management are the best things about it.
Separating interface and implementation is a good thing, but often you just want to split things into separate files without separate compilation. C supports #include and so it is maximally flexible.
I've been writing some Scala Native recently. See https://github.com/creativescala/terminus/. It's a high-level language but you can still reach down and grub about in memory if necessary. I'm having fun.
Pony is fun and I love the actor paradigm but it definitely feels like the community lost a lot of energy when Sylvan Clebsch stopped working on it (to work on a similar project for MS).
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 used c and java, and have recently been thinking about go. It's interesting that the comments here only mention go in the negative. Can someone give me the back story about go?
I think Go is fine for application development (any stuffs that runs on top of OS).
But for system programming, which is generally understood as developing OS kernel (filesystem, memory management, device driver etc) or embedded which you built a mini OS), then Go is not the proper choice (features like coroutine, AFAIK, needs OS). You'd want C/Pascal/Rust/Zig/<what else?> ...
I don't know if go counts as "systems programming" like the other commenter mentions.
But I have been recently using it for some tooling and small servers on personal projects where I'd have used python before.
Frankly it's been a joy and I wish I'd started earlier. The concurrency primitives are great, and the static binaries make deployment easy (raspberry pi in this case).
Struggle to use anything other than python professionally, the need to settle on a common denominator trumps pretty much everything else.
D language (Dlang). It is especially good if you are porting from C as the semantics are the same enough to rum a lot of code via copy and paste, or if not it will fail to compile.
OCaml and Factor, too, but I am not sure OCaml is not popular. Factor rarely, but I love it, too, just do not use it as much. I actually write more Factor than Forth.
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.
commenting after seeing multiple comments here, after about a day.
first of all, thanks, guys, to all who replied. that's a wealth of info to follow up on.
referring to the comments seen so far:
I considered mentioning (Free) Pascal, but thought of not doing it, because I thought it is nowadays too niche, even though it is one of my early programming language loves (forgetting that the title of my post says "less popular languages" :)
and I also didn't think of Ada at all, somehow, although have been interested in it, too, lately, and have been checking out websites and blogs about it, and also have been searching hn.algolia.com for posts about it.
so it was cool to see multiple mentions of Ada here, by people who like and use it.
> so it was cool to see multiple mentions of Ada here, by people who like and use it.
I'm surprised how popular Ada is here in these comments. I like some of the ideas (ranged types, for example) in Ada, I'm inspired to give it a try after seeing all the comments here.
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.
It's not a systems programming language, but I actually wrote a userland "device driver" in Python, for startup MVP pragmatic firefighting reasons.
It was somehow rock-solid in over a year of factory production overseas. Which might not have been the case, if I'd written it in C and put in the kernel, like might normally be good practice.
(It hooked into some kernel interfaces, did a little multiple USB device management, and low-level keyboard-like decoding with efficient I/O, and buffered and parsed and did something with the output of that.)
I have mixed feelings about Python: it often it hurts more than it helps (if you know better ways to do things), but the ecosystem has some nice off-the-shelf components, and it's popular/employable. However, due to the popularity, the average quality of any article you might find through Web is unfortunately low.
(For an unpopular language, you'll get a few people writing articles from a junior/neophyte knowledge level, as part of their learning, or because someone said it was good for resume-boosting. That can be good. But no one is going to waste time pounding SEO low-quality filler for a language that doesn't make money. Well, at least they wouldn't before LLMs, but who knows how the economics have changed, now. :)
I've pretty much settled on Zig at this point, if only for how dead-simple it is to cross-compile for other hardware platforms. The process of compiling working code for oddball platforms (in my case the Nintendo 64) was way easier than I expected it to be.
The only downside is the stdlib being as fast-moving of a target as it is. Right now I've had to put a pin on getting panic stack traces to work on my N64 code because apparently the upcoming release changes a bunch of stuff around panic/stacktrace handling (and it's already changed quite a bit over the years even before these new changes).
> The only downside is the stdlib being as fast-moving of a target as it is.
Ah that's an interesting take, my opinion is that the stdlib doesn't move fast enough.
In its current state it's pretty broken, most of the "process", "os" and "posix" modules are either straight up raising unreachable in normal scenarios, or simply badly designed. I would like the stdlib to be much more fast moving and fix all these issues, but I had the impression most work on it is frozen until 0.15 or 0.16, after incremental compilation is done.
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.
> I think the problem you describe can be solved by having more contributors focussing on the standard library.
I don't think so, my impression is that stdlib improvements are volontarily frozen for now, not because of a lack of contributors but because of a lack of clear plan as to what the stdlib should look like. There are a number of issues and PR of people willing to contribute to stdlib that are stalled.
That's not to say that's its bad per se, "we don't have a plan for now and don't want people to commit time for an unclear target" is a perfectly OK answer.
> how dead-simple it is to cross-compile for other hardware platforms
The fact that zig can compile C code makes it useful for other languages too. I recently started using `zig cc` to cross-compile Nim for lots of different platforms within the same environment.
It takes no time to setup and, honestly, works like magic.
> 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()) ...
I also choose Perl most of the time, but I think this is the first time I've ever heard anyone call it super nice to read
I've heard it called a "write-only language"
It's more readable than C++, C or Rust though
100% depends on how it’s written. It gives a ton of flexibility regarding incorporating “magic variables” which can lead to incredibly abstruse code. The language motto is “there’s more than one way to do it”, and that’s implemented to a fault.
My Perl code is super nice to read. :D
My perl code isn’t. But neither is my Python, or Java, or C, or JavaScript or bash or anything.
Clearly the problem is all these languages, and not me.
Could be... or readable by who, who do not know these languages at all? :P
Maybe he's used to K?
Importing stuff fron CPAN used to be a nighthmare but I admit I have a sweet spot in my heart for Perl.
What N64 code are you working on? I am intrigued.
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.
I've been using Odin [1] for my hobby game development and I've been liking it a lot. Feels like a more ergonomic C.
Things I like:
- Vendor libraries like Raylib and MicroUI make it easy to get started
- I can pass around memory allocators and loggers implicitly using context, or explicitly if I need to.
- natively supports vector math and swizzling
- error handling with `or_else` and `or_return`
Things I don't like:
- Name spacing is a bit annoying. The convention is to prefix the procedures but I don't like how they look. It really isn't a big issue.
Have a quick read of the overview and if you are still interested, I highly recommand 'Understanding the Odin Programming Language' book by Karl Zylinski [2]
[1] https://odin-lang.org/docs/overview/
[2] https://odinbook.com/
I like Odin, but the creator is not too motivational (or rather, actively un-motivational)[1]. I still use it nonetheless for some of my own stuff, for now.
Regardless, I do recommend people to try it out. I use Linux and OpenBSD, too, despite Linus and Theo. :)
[1] The reason for why I think this can be found in their pull requests, but it's been some time I think.
OCaml
The compiler is very fast, even over large codebases.
Mostly trying to bring AWS tooling to the platform[1], or experimenting with cross-compilation[2] using another less well known systems language, zig.
[1] https://github.com/chris-armstrong/smaws/ [2] https://github.com/chris-armstrong/opam-cross-lambda
I want to like OCaml but OPAM is just so bad... and tooling is super important (it's one of the reasons Go is popular at all). Windows support is also an afterthought. There's no native debugger as far as I can tell. This is before you even get to the language which definitely has its own big flaws (e.g. the lack of native 64-bit integers that MrMacCall mentioned.
The syntax is also not very friendly IMO. It's a shame because it has a lot of great ideas and a nice type system without getting all monad in your face. I think with better tooling and friendlier syntax it could have been a lot more popular. Too late for that though; it's going to stay consigned to Jane Street and maybe some compilers. Everyone else will use Rust and deal with the much worse compile time.
It's my understanding that OCaml does not allow its programs to specify the size and signedness of its ints, so no 16-bit unsigned, 32-bit signed, etc...
Being a huge fan of F# v2 who has ditched all MS products, I didn't think OCaml was able to be systems-level because its integer vars can't be precisely specified.
I'd love to know if I'm wrong about this. Anyone?
That would be mix of D, Object Pascal, Swift, Ada, C#, Java.
A few decades ago plenty of Oberon dialects.
As language geek, I randomly select languages when doing hobby coding.
Regarding Go's remark, even if I dislike Go's authors decisions, back in my day writing compilers, linkers, firmware, networking stacks, and OS services was considered systems programming.
Likewise .NET team has been making wonders catching up to what C# 1.0 should have been for low level code, given its Delphi linage.
Java, in the context of being whole Android userspace, including drivers, there is very little systems exposed in the NDK. Vulkan is one of the few things not exposed to Java land, and that is being fixed with WebGPU like API in an upcoming version.
What are your thoughts on D? My experience is limited but seems like a very underrated language.
Loving Ada without using exceptions or inheritance on embedded and desktop. Some love Ada full OOP tagged types. I love Ada procedural style with privacy and abstract data types. I wish Flutter was written in Ada but atleast Dart is better than JavaScript atleast for procedural code without it's oop boiler plate. You don't actually need OOP for widgets.
But is Dart better than Typescript? I prefer Typescript for multiple reasons but one of them is that you don't have to use classes to use the advanced typing system. Without a typing system I like Ruby the most, but sometimes we just need a typing system.
I'm a big fan of Ada. I first encountered exceptions in Ada. When I first saw Python, way back in version 1.5, I was happy to see exceptions.
C#. While a popular language, it is criminally overlooked for high-performance programming. Obviously, you can't use it for embedded or kernel development. For other use cases though, it can almost reach the performance of C/C++/Rust when written with proper care.
> Obviously, you can't use it for embedded
Embedded is diverse. I would not use .NET for small embedded, i.e. stuff running on Arduino or ESP32.
However, I have successfully used .NET runtime in production for embedded software running on top of more performant SoCs, like 4 ARMv7 cores, couple GB RAM, Linux kernel. The software still has large pieces written in C and C++ (e.g. NanoVG rendering library) but all higher-level stuff like networking, file handling, and GUI are in memory-safe C#.
You surely can use it for embedded,
https://learn.microsoft.com/en-us/archive/msdn-magazine/2015...
https://www.ghielectronics.com/netmf/
https://www.ghielectronics.com/sitcore/
https://www.wildernesslabs.co/
You actually can use it for embedded and kernel development! See .NET Nano Framework [1] for embedded - works on microcontrollers like ESP32. For kernel development there's nothing really built in to support it but people have built tools [2] to do it.
[1] https://nanoframework.net/ [2] https://gocosmos.org/
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.
The only thing Singularity and Midori share is the idea.
You should also pour one out for Longhorn, where internal politics tanked the idea, and eventually Windows team redid all those .NET based ideas into COM/C++, and were even proud of doing so (see Hilo sample documentation), hence why nowadays COM based libraries are the main way to expose modern Windows APIs (aka post Windows XP).
Had they collaborated instead, probably Windows would be closer to something like Android userspace nowadays.
Or for Ironclad, another one from Microsoft research, lesser known, also from the same research group, which even includes type safe Assembly,
https://www.microsoft.com/en-us/research/publication/safe-to...
Microsoft Research has plenty of work in such domains, they also had a LLVM like compiler framework, based on MSIL, called Phoenix, among other stuff, e.g. Dafny, FStar, Drawbridge, also come from OS projects.
Unfortunely classical Microsoft management has been more like it isn't Windows, it isn't shipping.
Partly off-topic: which well-known companies have research groups? I knew about Microsoft and IBM. Google, probably. Others? Might be interesting to browse their sites for nuggets to explore or use.
I sometimes write C# in my day job. But I think I don't know much about how to write really fast C#. Do you have any recommendations for learning resources on that topic?
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.
LINQ is fine (but enterprise style never is, yes), it’s a matter of scale and what kind of a domain the code is targeted too. C# needs to be approached a little like C++ and Rust in this regard. Having standard performance optimization knowledge helps greatly.
Also can recommend reading all the performance improvements blog posts by Stephen Toub as well as learning to understand disassembly at a basic level which .NET offers a few convenient tools to get access to.
Thank you. I once read a bit about Span<T>, but some of this reference stuff is very new to me. Interesting, definitely. C# really is a big language nowadays...
Spans are just a slice type, but those which any type based on contiguous memory can be coerced to (usually). I’m sure you’re already using them somewhere without realizing that. Their main use case in regular code is zero-cost slicing e.g. text.AsSpan(2..8).
C# is specifically designed for enterprise-style OOP, so if you want to avoid that, why use C# at all?
> C# is specifically designed for enterprise-style OOP
Then why would they add Span<T>, SIMD types and overhaul ref types in the first place?
Because some people wanted to use C# for low-level programming, so they added these things as an afterthought.
You’ve clearly never used it and have no idea what you are talking about.
I have used it a few years ago and the enforced OOP boilerplate was too much for me.
I have the same issues with JVM-like languages, like Java. I only write Java if I am getting financially compensated for it!
You can write procedural or functional style as well, and with top-level statement you can write without any OOP or boilerplate whatsoever.
Trying to write it as if it was a different language instead or, for whatever reason, copying the worst style a team could come up with does happen and must be avoided, but that’s user error and not a language issue. Also the tooling, especially CLI, is excellent and on par with what you find in Rust, far ahead of Java and C++.
If you link an example snippet of the type of code that gave you pause, I’m sure there is a better and more idiomatic way to write it.
C# was originally a clone of Java. It was almost literally copy/paste compatible.
You're thinking of Java, which is Enterprize Buzzword Compliant to the maximum extent possible.
C# is Java-but-with-lessons-learnt, and is significantly less verbose and "enterprisey" in typical usage.
Modern .NET 9 especially embraces compile-time code generation, a "minimal" style, and relatively high performance code compared to Java.
Even if the JVM is faster in benchmarks for hot loops, typical Java code has far more ceremony and overhead compared to typical C# code.
> Even if the JVM is faster in benchmarks for hot loops, typical Java code has far more ceremony and overhead compared to typical C# code.
Can you give an example? I don't think this is true anymore for modern Java (Java 21+)
It's a heavily gamed benchmark, but TechEmpower Fortunes is pretty good at revealing the max throughput of a language runtime for "specially tuned" code (instead of idiomatic code).
Java currently beats .NET by about 40%: https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...
I judge more idiomatic / typical code complexity by the length of stack traces in production web app crashes. Enterprise Java apps can produce monstrous traces that are tens of pages long.
ASP.NET Core 9 is a bit worse than ASP.NET Web Forms used to be because of the increased flexibility and async capability, but it's still nowhere near as bad as a typical Java app.
In terms of code length / abstraction nonsense overhead, have a look at the new Minimal APIs for how lightweight code can get in modern C# web apps: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...
For those interested in performance ceiling, https://benchmarksgame-team.pages.debian.net/benchmarksgame/... provides additional data points.
What matters in practical scenarios is that ASP.NET Core is significantly faster than Spring Boot. If you have a team willing to use ActiveJ or Vert.x, you are just as likely have a team willing to customize their C# implementation to produce numbers just as good at web application tasks and much better at something lower level. There are also issues with TechEmpower that make it highly sensitive to specific HW/Kernel/Libraries combination in ways which alter the rankings significantly. .NET team hosts a farm to do their own TechEmpower runs and it just keeps regressing with each new version of Linux kernel (for all entries), despite CPU% going down and throughput improving in separate more isolated ASP.NET Core evaluations. Mind you, the architecture of ASP.NET Core + Kestrel, in my opinion, leaves some performance on the table, and I think Techempower is a decent demonstration of where you can expect the average framework performance to sit at once you start looking at specific popular options most teams use.
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.
Free Pascal, but I am interested in Ada and will be learning it more this year. I love the readability of the syntax, and on the outside looking in, the community seems good.
I have also moved back hard to using TCL as my scripting language. I like it too much, and bouncing between Python, Go, and such for DevOps glue tires me out.
For systems, I love using plan9 (9front) to solve problems, which grounds me to C, awk, sed, and the rc shell.
My major system programming languages are C and C++, but I did some projects in Oberon (which turned out to be not particularly suited for systems programming), and then created a modified, better suited version of it called Oberon+ (https://github.com/rochus-keller/Oberon), which I e.g. used to create platform-independend versions of different Oberon System generations.
But Oberon+ is still too high-level for many system programming tasks. So I'm designing a new system programming language called Micron (for Micro Oberon, see https://github.com/micron-language/specification) which has the full power of C without its disadvantages. You can even use it for the OS boot sequence when there is no stack and no heap, but also for higher-level application development, due to its selectable language levels.
I recently dabbled in "hare" which was quite a nice experienced.
I liked how the language stayed pretty simple compared to other C-replacements. The standard library is also pretty nice. It is however an extremely niche language, but still quite capable
I was pretty excited about Hare until Devault said that Hare wouldn't be doing multithreading as he preferred multiprocessing. That was a pretty big dealbreaker for me. The rest of the language looks quite clean though!
You could always link to pthread and use that in your Hare code, no?
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
hare will not support Windows.
https://harelang.org/documentation/install/#supported-platfo...
Interesting reasons.
Makes sense
I am currently contracted 3 days a week writing Zig. I can't say much because NDA, but I just love working with Zig almost every day. I think for the right projects, it is such a great choice for mission critical software.
You get the added benefit of being able to easily consume C libraries without much fuss. The fuss is in navigating the C APIs of decades old libraries that we all still depend on every day.
I write a fair bit of rust/c for my day job. Do you find zig easier than the ffi interface in Rust?
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.
Zig is easier than Rust here, but you can auto generate bindings, you don’t have to write them by hand.
In LuaJIT and Odin it is also easy to do FFI.
F#! I’m in love with the language. It is my defacto pick for most things these days. Very expressive AND strongly typed. Being a part of the .Net ecosystem is also a plus.
I wouldn’t call F# a systems programming language, but it’s definitely on my list of things to properly try out at some point
Can you create desktop GUI apps with it?
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)
I've also gotten it working with FNA. I haven't done anything too elaborate in the game development world, but as far as I can tell there's really no limitations imposed by F# in that front.
cool, thanks.
I'm not very good at using it, but every now and then try to do a small project in Chicken Scheme. Mostly I'm unsuccessful, but I enjoy the language a lot and have a great time using it.
I started using Idris a few years ago because the idea is fascinating. Such as state machines in your type system, the size of a list being defined in the static type system, even if the list size changes over time (pretty mind blowing), etc..
But ultimately I realized that I’m not writing the type of software which requires such strict verification. If I was writing an internet protocol or something like that, I may reach for it again.
Similar boat. I've read about Idris (and been 'shown the door' enough times) and I love the idea of it, but sadly I haven't yet had any reason to use it.
Every now and then Freepascal with Lazarus but the same bug being in the IDE for ten years plus kind of annoys me. If I save a new project and I move any files around it does weird stuff, or if I rename a module.
Theres also D but finding libraries for whatever I want to work on proves problematic at times as well.
On the other hand, the Ultibo OS for the Raspberry Pi is written in FreePascal.
Ada
The open source tooling has significantly improved since I started using it in the last five years.
OK, here's a pretty niche blast from the past: the boo programming language. It ran on the CLR (.NET) and had syntax similar to python. I recall using it back around 2006 - 2008 because it offered scripting features for .NET on Windows.
https://boo-language.github.io/ "A scarily powerful language for .Net". I didn't use it for too long before switching to Iron Python.
I remember reading about the Boo language and IronPython some years ago. Do you still use IronPython?
zig is coming along quite nicely. If you've not heard about zig, take a look at https://ghostty.org/ (a terminal for Linux/Mac and Windows in future), https://tigerbeetle.com (a database for financial accounting) and http://bun.sh (a modern, faster alternative to nodejs).
Using Elixir and Elm at my day job.
Coming from a more Python/Java/PHP/JS background, Elixir was a lot easier to pick up and doesn't frustrate me as much. Most of the remaining scary bits involve concurrency and process supervision trees.
Macros are powerful, but also easy to use in a way that makes everything hard to debug. For those unfamiliar with them, it's a bit like a function except any expressions you call it with are not evaluated first, but arrive as metadata that can be used to assemble and run new code.
The question is about systems programming.
Why elm over LiveView?
I know “why” elm, I liked everything I saw about it, but how do you combine the two, if you do?
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.
Yeah, I loved Elm, but the restriction that you can't build your own "effect" modules really made it impossible to embrace. Say you want to use a new web API similar to using Elm's core `Http`, well... you can try and fork Elm...
You can use webcomponents to work around a few of those limitations.
The only true "system programming" I've done was in Microsoft Macro Assembler, a product I grew to hate with a passion.
A non-answer, but tangentially relevant:
I once fiddled with Forth, but never actually accomplished anything with it.
Several OSs are written in Lisp; in some of them the difference between OS and application is a bit vague. At the time none of them were available to me to play with.
I discovered Oberon and fell in love. My first real programming language was Pascal, and Oberon is part of the same family. Oberon consisted of a compiler, operating system, user interface, application software, and tools, all self-hosted on Oberon. There was even an Oberon CPU at one time. But Oberon turned out to be just an academic curiosity, and wasn't available for any hardware I had access to anyway.
Have a look at https://github.com/rochus-keller/Oberon which runs on different operating systems and architectures. You can even generate platform-independent C which I e.g. used to port the Oberon System 3 (https://github.com/rochus-keller/OberonSystem3).
Pascal.
Sure these days not many folks write OS kernel in Pascal, but there are some, e.g: https://github.com/torokernel/torokernel
I once want to try Forth (perhaps there's a Unix clone in Forth?), but seems like most folks using it are embedded/hardware devs.
I had read somewhere that some of the early Apple (not Mac) software, i.e., systems, application or both, was written in some Pascal variant.
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.
Pascal interfaces and direct 68k ASM for the first years of Macintosh. C language bindings were third party and discouraged by Apple. There were good reasons for that in those days IMHO, since C came with a lot of Unix software libraries and people would demand that the science libs run. Apple said "no" but third parties built the compilers anyway. Many developers were attracted to Michael Kahl's brilliant ThinkC system, later to MetroWerks. MPW built a more *nix-like environment eventually, also.
source: C language developers for the Macintosh OS
ha ha, nice.
even early Windows versions were somewhat Pascal-oriented, with things like "long far pascal" used in C function declarations, to indicate the calling convention being used, whether right to left, or left to right, iirc.
Not presently, but not long ago, Fortran and Ada. I still like Ada better than the alternatives, especially as it's changed this past couple decades. I find it hard to miss Fortran, though. I'd consider it for scientific computing and that's about it, which isn't my present domain.
Interesting, thanks.
Did you ever check out Eiffel for systems programming work?
I had been checking it out some years ago, and apart from the general points about it, one use of it that I found interesting was in an article about using it for creating HP printer drivers. The author had mentioned some concrete benefits that they found from using it for that purpose.
Edit: I searched for that article, and found it:
Eiffel for embedded systems at Hewlett-Packard:
https://archive.eiffel.com/eiffel/projects/hp/creel.html
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.
How would Fortran be used other than numerics/scientific computing?
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).
The language (f90+) is a pleasure more often than a pain IMO. That it evolves, but quite slowly, feels appropriate and reassuring.
Fortran reminded me of John Backus.
I had read about him and about his FP language early in my career, when I was reading up on all kinds of computer subjects.
https://en.m.wikipedia.org/wiki/John_Backus
https://en.m.wikipedia.org/wiki/Function-level_programming
https://en.m.wikipedia.org/wiki/FP_(programming_language)
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...
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.
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.
I almost exclusively work in Ada for my hobby projects these days; It's great for doing both high level and low level programming.
Where does tooling and platform support stand for Ada? Could one develop desktop, mobile, web apps, too using Ada? Thanks.
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/
Are there Ada jobs?
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
Ada for bigger projects, D for quick one-offs and more “scripty” work.
I had played around with D some time ago, and wrote some small programs in it for fun and learning. I both liked and disliked things about the language.
there was some Russian dev running a systems tech company, I forget his name, living in Thailand, like in koh samui or similar place. he used D for his work, which was software products. came across him on the net. I saw a couple of his posts about D.
one was titled, why D, and the other was, D as a scripting language.
I thought both were good.
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
I like nim so far, but I have to admit I haven't done all that much with it yet.
Nim is great, I wrote a crypto trading engine with it. The performance is excellent, memory safety works well, and it was much easier to write compared to Rust.
If the support was still there I'd still be using VB.NET.
I've coded professionally in a dozen languages, including a lot of time in x86 assembler, C++ etc.
Still like VB.NET better than any other. To me, it was the most readable code.
Is it not still supported?
it is still supported and developed.
Nim, I love its “make simple things simple and complex things possible” philosophy.
I absolutely adore Nim.
That said, the edges are still (very) rough when it comes to tooling (generics and macros absolutely murder Nimsuggest/lsp) and also "invisible" things impacting performance such as defect handling (--panics:on) and the way the different memory management schemes introduce different types of overhead even when working with purely stack allocated data.
But even with all that it's still an extremely pleasant and performant language to work with (when writing single threaded programs at least)
I really should continue my Nim series :( https://youtube.com/@nimward
Perl had somewhat the same, IIRC.
https://www.google.com/search?q=perl+simple+things+easy+and+...
I do systems programming in i386 (32-bit) assembly language with NASM.
For me it doesn't scale beyond a few dozen kilobytes (executable program file size) per program. For others (such as Chris Sawyer) assembly scales much better.
Did you get a look at fasm [0] ? It has nice capabilities
[0] : https://flatassembler.net/
Nim. Fantastic choice for modern headless software. Simple obvious type system, preference for immutability and referential transparency. Dynamic collections are by default managed by hidden unique pointers on the stack. So the default RC isn't necessary unless explicitly invoked for a ref type.
Currently solo managing a 30k line data analysis application I built for my company. Easily fits in my head given the obvious pyramidal functional-like structure. Maybe two lines of memory semantics anywhere in the entire thing, and only one module that's OO with a constrained scope. Lots of static data files (style sheets, fonts) slurped up as const strings at compile time. Incredible performance. Invoked by our PHP server backend, so instead of doing parallel or async in the analysis, the server gets that through batch invocation.
Working stupid well for our product, plus I can easily compile binaries that run on ARM and RISC-V chips for our embedded team just by invoking the proper gcc backend.
Replaced an ailing and deliberately obfuscated 20 year old jumble of C and PHP designed to extort an IP settlement from my company. Did it in a year.
Do you have any recommendations for well designed open source Nim projects for someone study to get a feel for the language?
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
I am using Haxe which compiles to other languages (C++, JavaScript, PHP...). This is a nice language when you want to create a web application or a even a CLI.
If you have played video games by Shiro Games (Evoland, Dune Spice Wars) or Motion Twin (Dead Cells) or even Paper Please!, then you had been exposed to this language.
Julia https://julialang.org/
I don't know if Julia is a system programming language
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).
Using the `mcl` DSL language in https://github.com/purpleidea/mgmt/
It's awesome. But I'm biased because I designed it.
You can't build anything, but you can build many things much more easily. Particularly distributed systems.
Have a look at hare. It's got some interesting bits [1]
Also C3
[1] https://harelang.org
[2] https://c3-lang.org
Common Lisp. It offers powerful abstractions and high speed. I’m happy with it.
Seconding CL. For my personality, purposes, and preferences it's the closest thing to a perfect language.
I've been using Zig for nearly 4 years now. A lot of changes in that period were not great, but I haven't really wanted to use anything else.
I have been watching with interest. I can't help but think Rust will easily win. Zig isn't different enough, and it's somewhat opinionated (in good ways but not always clearly better)
I just looked into Zig and it looks great on first glance. What recent changes were not great in your opinion?
Perl is kinda less popular now. I use that at work. Used to write perl6/raku in my previous job, I loved the grammars made a nice way to try and Wirte an nginx configuration manager.
Perl here, too.
We still use it for all kinds of web services development work, mainly because there's years of in-house modules for everything and the malleability Perl has.
i don't know if pike counts as a systems language, but i consider it an alternative to C, if only because it has good C integration so that you can easily include a module written in C. pikes syntax is also very close to C, which may be appealing to some (ironically that's an aspect i don't really care about myself)
if the question of go being a systems language is controversial, then pike is even more so. i would situate pike somewhere between python and go. pikes major drawback is that it doesn't produce standalone executables.
the real question i'd like to ask is, what actually is a systems language?
Cython. Writes like Python, runs like C. Strangely underappreciated.
It certainly doesn’t run like C. I once thought to port my JSM machine learning engine to python and it felt Cython might just be what I needed. Simply put it’s tight loops doing bitwise ops on bit-vectors. In reality no amount of adding type annotations would help the thing was slower then C++ by an order of magnitude.
Forth. Old but very versatile. wrote the runtime myself years ago in portabel c.
D and Crystal always fascinate me. And if Go is a system language, Erlang and Common Lisp are even more so.
I wish Crystal had better IDE support, otherwise it’s just about perfect.
IIRC, I read somewhere, several months ago ago, that its type inference made it slow to compile anything but small programs?
I like Erlang a lot.
Me too buddy, super powerful, syntax is a little weird but once you get used to it..
gen servers, everywhere.
Tried trying zig, but was baffled by all the allocator dance you need to do and asking nicely to access a list (catching potential exceptions?) Tried odin, but the tooling is very raw. Tried rust, didnt want to try to please borrow checker that distracts me from my thoughts.
Idk, if someone just reinvents clean C without the nonsense garbage with some modules and package manager this will be a huge win. Let me access my null pointers, let me leak memory, just get the hell out of my way and let me program and hold my hand only where I want it to be held - sane types that give me refactoring, code completion and code understanding, modules with imports. Let compiler give sane error messages instead of this cryptic c++ garbage. Is this too much to ask?
D's "Better C"[1] mode looks like what you describe. Has syntax similar to C with a real module system, metaprogramming, slice types etc.,
1 - https://dlang.org/spec/betterc.html
I also had a brief look at Zig for writing a WASM module, but settled for Rust. I had no real gripes with the language, but the spartan documentation made making progress into a slog.
I wouldn't mind a "better C" that could use an LLM for static code analysis while I was coding. I.e. be more strict about typing, perhaps. Get out of my way, but please inform me if I need more coffee.
looks like zig is exactly what you want. Difference only in std. C prefer global allocator, while zig ask it explicitly.
So, if only there is std with implicit allocators?
Allocation in Zig takes some getting used to but it's actually really nice. It took me a few weeks but I honestly believe you should give it another chance and more time
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.
There is no reason you can't attach an Allocator to the type (or struct, in Zig).
A fairly common pattern in the Zig stdlib and my own code is to pass the allocator to the `init` function of a struct.
If what you mean is that allocation should be internal to the type, I don't agree with that. I much prefer having explicit control over allocation and deallocation.
The stdlib GPA for example is pretty slow, so I often prefer to use an alternative allocator such as an arena backed by a page allocator. For a CLI program that runs and then exits, this is perfect.
C's compilation unit model, lack of a formal module system and lack of language-level package management are the best things about it.
Separating interface and implementation is a good thing, but often you just want to split things into separate files without separate compilation. C supports #include and so it is maximally flexible.
I've been writing some Scala Native recently. See https://github.com/creativescala/terminus/. It's a high-level language but you can still reach down and grub about in memory if necessary. I'm having fun.
Take a look at Pony https://www.ponylang.io/
Pony is fun and I love the actor paradigm but it definitely feels like the community lost a lot of energy when Sylvan Clebsch stopped working on it (to work on a similar project for MS).
I will, thanks.
Odin. It's just too easy and fun.
Why is Odin easy for you? Because it is non-OOP (I think, have not confirmed that) or some other reason?
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 will put in a plug for Mercury: https://mercurylang.org/
I read a while ago, when checking out Prince XML (a high-end HTML to PDF conversion tool), that is written using Mercury.
https://www.princexml.com/
Wow, I haven’t heard about that language in a long time. What do you use it for?
Chicken Scheme for personal projects.
F# and Haxe. Love both of those languages
Haskell + copilot (from Nasa) and/or MicroHs when targeting embedded (like RPi Pico)
Very cool, was not aware of either of them. Thanks for sharing
https://github.com/copilot-language/copilot
https://github.com/augustss/MicroHs
Any good examples for these in systems projects?
I've used c and java, and have recently been thinking about go. It's interesting that the comments here only mention go in the negative. Can someone give me the back story about go?
I think Go is fine for application development (any stuffs that runs on top of OS).
But for system programming, which is generally understood as developing OS kernel (filesystem, memory management, device driver etc) or embedded which you built a mini OS), then Go is not the proper choice (features like coroutine, AFAIK, needs OS). You'd want C/Pascal/Rust/Zig/<what else?> ...
I don't know if go counts as "systems programming" like the other commenter mentions.
But I have been recently using it for some tooling and small servers on personal projects where I'd have used python before.
Frankly it's been a joy and I wish I'd started earlier. The concurrency primitives are great, and the static binaries make deployment easy (raspberry pi in this case).
Struggle to use anything other than python professionally, the need to settle on a common denominator trumps pretty much everything else.
D language (Dlang). It is especially good if you are porting from C as the semantics are the same enough to rum a lot of code via copy and paste, or if not it will fail to compile.
Ada and Odin that I would consider less popular, rarely Forth.
OCaml and Factor, too, but I am not sure OCaml is not popular. Factor rarely, but I love it, too, just do not use it as much. I actually write more Factor than Forth.
I still absolutely love my Elm. Never a programming language has made me as confident and joyful when writing code <3.
Are people using Elm for systems level programming? I have only used it on the front end.
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.
I personally mix languages, using higher level languages for the structural work and calling C for the code or data structures that require it.
So a good FFI to C has always been an important requirement for me.
I’m considering Mojo.
Me too for projects and tools. Would like to use Ada for IOT projects and tools.
I've been learning Elixir just for fun. I wish I was using it in my day job.
Elixir is not a systems programming language.
Learning a new language for the sake of learning a new language might be why they asked.
> Less popular
Bash.
> I used C for both application programming and systems programming
Gross. Learn C++, it's better than C in every way! shotsfired.jpg
> I've been wanting to get back to doing some systems programming, but preferably in a more modern language (than C) which is meant for that.
Use C++ then. Or if you're a hater and/or don't know how to keep footguns pointed away from your legs, use Rust.
> less commonly used ones
but tbqh why not Xojo?
Fuzztester here is asking about system languages. I see a lot of people suggesting things I'd consider non systems languages.
The IEC 61131-3 languages, though 95% of my work is Structured Text. Anyone need a PLC programmed?
Ada and Scheme.
It hasn't been released yet, but I'm very excited for Carbon :)
My team hates when I write POSIT shell.
commenting after seeing multiple comments here, after about a day.
first of all, thanks, guys, to all who replied. that's a wealth of info to follow up on.
referring to the comments seen so far:
I considered mentioning (Free) Pascal, but thought of not doing it, because I thought it is nowadays too niche, even though it is one of my early programming language loves (forgetting that the title of my post says "less popular languages" :)
and I also didn't think of Ada at all, somehow, although have been interested in it, too, lately, and have been checking out websites and blogs about it, and also have been searching hn.algolia.com for posts about it.
so it was cool to see multiple mentions of Ada here, by people who like and use it.
> so it was cool to see multiple mentions of Ada here, by people who like and use it.
I'm surprised how popular Ada is here in these comments. I like some of the ideas (ranged types, for example) in Ada, I'm inspired to give it a try after seeing all the comments here.
visual basic. i learned a lot from this language because i'm able to create a system from scratch without import a library.
Haxe and Dart (without Flutter) are quite nice.
Micropython of course
I've written a non-trivial (5K SLOC) app in Zig and it's very nice.
tcl
Swift
(kebab-use-elisp)
RPG
C#, to match the performance of reference implementations in C and Rust, and completely crush the performance of those in Go :)
Why do you need to downvote / compare Go on every of your post? Do you have insecurities with Go?
I was reading another post about someone showing some AI stuff and then: https://news.ycombinator.com/item?id=43246127
what do you mean by reference implementations, in this context?
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.
Python.
It's not a systems programming language, but I actually wrote a userland "device driver" in Python, for startup MVP pragmatic firefighting reasons.
It was somehow rock-solid in over a year of factory production overseas. Which might not have been the case, if I'd written it in C and put in the kernel, like might normally be good practice.
(It hooked into some kernel interfaces, did a little multiple USB device management, and low-level keyboard-like decoding with efficient I/O, and buffered and parsed and did something with the output of that.)
I have mixed feelings about Python: it often it hurts more than it helps (if you know better ways to do things), but the ecosystem has some nice off-the-shelf components, and it's popular/employable. However, due to the popularity, the average quality of any article you might find through Web is unfortunately low.
(For an unpopular language, you'll get a few people writing articles from a junior/neophyte knowledge level, as part of their learning, or because someone said it was good for resume-boosting. That can be good. But no one is going to waste time pounding SEO low-quality filler for a language that doesn't make money. Well, at least they wouldn't before LLMs, but who knows how the economics have changed, now. :)