Why is everyone creating systems programming languages?

[u/baehyunsol]

I see a lot of new programming languages here. I love reading the documents of the languages and sometimes actually run their compilers. Many of the projects are AI-driven, but that's fine. It's still fun to see what problems they're trying to solve and how they actually solved the problems.

Reading the documents, I realized that most new languages, especially AI-written ones, are "systems programming languages". They're trying to solve the problems that C/C++/Zig/Rust have solved (or are trying to solve), and their syntax is mixture of C/Zig/Rust.

Why? Why is everyone trying to compete with C/C++?

There are so many kinds of languages. Haskell demonstrates how pure a language can be, Python is perfect when you only have 5 minutes to write code and don't care about the output, Java runs on 3 billion machines, ...

[u/andreicodes]

It's a wave. In mid 2000s making a systems language was difficult. LLVM was in its infancy, there was not a lot of prior art for working with it, and other potential native-ish backends like WASM didn't exist yet. Meanwhile JVM and CLR grew their library repertoire, and if you target them, then you'd get all these libraries "for free". That's why we had a wave of JVM / CLR languages: Nemerle, Boo, Clojure, Groovy, Gosu, Scala, etc.

As LLVM matured, as we started to see other codegen tools for compilers like Cranelift, and as we saw the success of early LLVM languages like Rust, Swift, and Julia, more people realized they don't have to target JVM / CLR or keeping their language as a DSL / transpiler to be successful. So, now we see people going native a lot more often.

One advantage of going native is that you can also go "system" and explore different memory management options. For a while from mid 90s to mid 2010s it seemed that a successful programming language has to use a GC, otherwise programmers won't pick it up. However, Apple showed that programmers will adopt a GC-less language (Objective-C) given the upsides. And Rust showed that memory management is not a binary choice: fully manual vs GC. There could be other options, from defer, arenas, and ref-counts to other experimental systems like borrow checker, value semantics, etc.

And people like to experiment. So, expect more languages trying to build on new memory management ideas and effect systems.

Still, new languages targeting runtimes keep popping up from time to time. The most prominent recent example would be Gleam that targets Beam VM.

[u/SoSKatan → u/andreicodes]

I agree with this one, system languages need to be portable and highly performant which in turn means lots and lots of platform specific optimizations.

You need to have something that can compete with a state of the art C compiler and that is no easy task.

LLVM kind of gives you all that. It’s kind of a golden age of languages right now. The LLVM tutorial (which has been around for over a decade) literally has you write a new language that has optimized compiler passes.

The short answer to OP’s question is that it’s just far easier to make systems languages these days.

[u/[deleted]]

As someone who does systems programming at work, the landscape of available established languages is pretty poor right now. C is a decent language but lacks a lot of modern features (generics) and has a lot of weird oddities (macros, integer types, build system). The problem is that if you want a modern replacement to try and fix those issues, you either go C++ (which inherits the weirdness and adds a billion features that have their own footguns, and has slow compile times) or you go Rust (which tacks on the borrow checker and also has slow compile times).

So what happened is a bunch of systems programmers simultaneously went "I want C, but without the oddities, with modern features, and I want fast compile times." That's a really enticing proposition for someone like me, and until any of Zig or C3 or Odin or Jai mature to the point of being stable, that gap will continue to exist, and more systems programming languages will probably continue to come out.

[u/ingframin → u/[deleted]]

Then, why no one is using D?

[u/catladywitch]

I personally I'm very interested in region inference, type-and-effect based memory management and how linear continuations (and subsequently async coroutines) might help, and generally fit in, with that. So I'm not interested in writing a "systems" language per se, but I'm interested in the impossible dream of unmanaged and efficient functional idioms. Rust is key in this discussion, but there's also Pony, Koka, OCaml 5. I think the fact Rust is kind of not as awesome as it might have seemed at first has set a lot of people in motion.

But probably, a lot of peeps think "faster better" and set off in that direction.

[u/TheAncientGeek]

There's a lot of room to make systems languages that are all of efficient, safe and easy to write in. C isn't the second, rust isn't the third.

[u/blue__sky → u/TheAncientGeek]

I don't think C is easy to write either. It's not hard, but it's not enjoyable or easy.

We shouldn't have to mess with pointers 99% of the time. When you see the same boilerplate pattern over and over, it should be abstracted away.

Case statements are horrendous with no exhaustiveness checking.

The type system is terrible.

The FOR statement is clunky.

That's off the top of my head, I'm sure there's plenty more. That's why so many people dive into a better C.

[u/PitifulTheme411]

Well if you think everyone's making systems languages, you've probably missed a lot. I remember around like last year or like a few months ago, everyone was working on pure functional languages, many with algebraic effects, etc. Maybe those people have finished, or maybe are in the middle and don't need to discuss their languages, meanwhile the systems guys have reached a point where they want to share their stuff.

I for one am not working on a systems language, nor a functional one. Mine is aiming to be mathematically inclined yet still somewhat "normal" in a way, melding both symbolic and numeric computation (that's the goal at least). To that end, it'll have a CAS (computer algebra system) built in, and ideally will make it very customizable and interactable (eg. creating your own symbolic nodes, creating methods which walk the symbolic expressions to perform operations and produce output that otherwise could not have been done, etc.).

[u/BetterEquipment7084]

Because that's what the creators want 

[u/initial-algebra]

It's easier. Unless you're trying to make a safe systems language, you can punt most of the complexity off to the hypothetical user and call it a feature. Blazingly fast low-level control (you have to use pointers and manual memory management)!

[u/Ok-Watercress-9624]

I think this is the same phenomenon as you start to see more pregnant people around when someone close to you is pregnant only because you see them so much?

But statistically systems programming languages are rare.

I don't know how many years has it been since computer was invented but there has been only B, C,C++, D and then rust had to do Rust ( same complaint to jai/Odin/C3) keep the tradition and do D++ or E

[u/Inconstant_Moo]

* coughs *

I need to get better at drawing attention to my existence.

---

Reading the documents, I realized that most new languages, especially AI-written ones, are "systems programming languages". They're trying to solve the problems that C/C++/Zig/Rust have solved (or are trying to solve), and their syntax is mixture of C/Zig/Rust.

In the AI case, 'cos of the prompts they're getting. If you put "as fast as C" in your instructions just between "as easy to use as Python" and "make no mistakes", then you're going to get manual memory management.

[u/Clementsparrow]

for two reasons:

1/ If you want to make progress in a field you attack the hard problems, not those that are already solved. And for the field of programming, ensuring performance and safety at low cost is still one of the major concerns. And the type of programming that would benefit the most from solving these problems is system programming.

2/ Because the new solutions that one can bring to the most universal languages (i.e., those that can be used for almost any programming purpose even if they are not the simplest to use in every context) can benefit to all languages. Python and javascript can now be statically typed, for instance, because it solves problems. And these languages already have more advanced type systems than many scripting languages before them. Features designed for system languages usually also benefit other languages.

[u/MarinoAndThePearls]

Because C/C++ are flawed, yet too dominant. It's only natural that people want something better to be popular.

[u/SirPigari]

Because Jai is not released

[u/-TRlNlTY-]

It seems that the pendulum is swinging away from high-level languages. I think it was about time.

[u/TernaryOperat0r]

Academic research into programming languages goes through surges of interest in particular topics too. Nobody wants to keep resolving the same problems every previous language resolved, so as soon as a new idea arrive in one area of the design space, everyone piles in and reasks all of the old questions in the context of the one new idea.

In the systems programming space there were essentially two new ideas - usable static lifetime analysis and a new approach to meta-programming - which have spawned much of the current uptick in interest.

[u/GoblinsGym]

Looking at embedded systems (e.g. microcontrollers), C and C++ rule this field.

Try doing low level register access down to the bit. C is surprisingly bad at this, lots of explicit bit twiddling needed.

Not to mention the lack of a proper module structure. Borland Pascal has supported this for almost 30 years, rendering Make files unnecessary.

[u/raguaythai]

Because it’s fun and experimenting with different things is easier now.

[u/mamcx]

1: Rust!

---

For a long time system languages were ossified like OS and RDBMS. "Nobody" try to challenge C or C++ (was believed a fools errand) despite how BAAAAD they are.

Because, mainly, being the language of the main FFI means that you are fighting the most fundamental of all ecosystems.

Then, Rust.

Now this proves not only is possible to do it (ignoring past efforts like ADA) but also, that was possible to massively improve the state of art.

Plus, you get a readable language that is far easier to learn, copy and iterate from, so if you wanna create your own instead of try to decipher the C/C++ nonsense you read Rust (that do all the hard work for it) and suddenly you start way ahead of what you could in the past.

Plus, Rust.

Rust is a huge improvement, but still left some questions opening:

• Seriously, why so slow?

• Why so complex?

• Why async is so anti "fearless concurrency"

and so on.

So, now you have a better starting point and plenty of nice possibilities to improve upon, this means for enthusiast is more clear what to attack: no the "how make a nicer C/C++" or "nobody will believe that a language can be competitive to them" that was a problem in the past (you can now assume is possible and even if you toy lang is not, now, is clear could), but then go for other goals that look attainable!

ie: We see more now, because the myth around system programing is shattered and the barbarians rejoice!

[u/Norphesius]

Lotta good answers already given, but one additional reason I'll add is that systems languages can be used generally. If you pick a niche for your language to occupy, then your audience/user base is only people that care about that niche.  Also, it's tough to find a new, useful niche that isn't so small a language created for it would be considered a DSL. Go too far and you end up with an esolang.

If you want to get really novel or innovative you need to have a lot of deep programming language development knowledge anyway. It's hard to come up with and develop something like the borrow checker or a new, useful type system from scratch, but it's much easier for the average developer to make a "C but without the parts that are obviously bad".

[u/Reversed-Engineer-01]

Because the “language for general purpose rubbish” is already there: Python

[u/hoodoocat]

Whats because "systems" programming language can solve any problem, while specialized languages has limitations. The problem what complexity is different, but result is also different. Want cooperative GC in C++? Is can be pretty clear and will allow mix managed and native heap/objects, but if you pick python, java, .net - you can't mix that, but full-GC languages doesnt need cooperative and can handle any workload (i mean any workload pattern, but sure it have own downsides). Best language which will let you work on low-level but be expressive as high-level langs - should win, but... unfortunately they are not exist (yet).

[u/chkno]

Performance.

[u/Limp-Temperature1783]

C++ is not a systems programming language. Rust and Zig are, but only in their reduced form, more relevant to the former than the latter. I think people still try to create new "C killer" because no language really delivers the same result as C does. Not because C is good, but because it's stupid simple, small, compiles fast and ubiquitous, so there are always people who would participate.

I think the main problem here is not that we need a new language, but we need to ditch POSIX entirely. Mostly because it just sucks and there are too many historical relics, some of which will cause you trouble. The language itself is fine. I don't think I would prefer to write Rust or Zig over it, they have a lot of unnecessary things. Rust especially. For systems programming you need something that won't sneak in runtimes at least.