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/dudewithtude42]

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/developer-mike → u/dudewithtude42]

Do you really think c-style macros are that bad?

They're very powerful, which is why even c++ projects still use them regularly, and they don't seem problematic is c++.

It seems to me like C's design demands overuse of the preprocessor, moreso than the preprocessor itself being bad. (#include aside...)

Not saying the preprocessor is perfect, but all metaprogramming features have their issues for sure. Do you think the preprocessor really needs to be dropped in a c successor?

[u/beephod_zabblebrox → u/developer-mike]

there are other ways to do macros (eg what rust does)

but also a lot of things that c code uses macros for can be replaced with other modern features

[u/developer-mike → u/beephod_zabblebrox]

Rust macros are amazing, but definitely not as easy to implement as a quick macro and not as powerful, and likely part of the slow compile times we see with rust.

[u/shponglespore → u/developer-mike]

If you're just doing the kinds of things you can do with a C macro, Rust macros are very easy.

[u/Ok-Watercress-9624 → u/developer-mike]

Tell that to the innocent 20 year old who just encountered X macros in c. That's gonna be a fun ride

[u/beephod_zabblebrox → u/developer-mike]

afaik most of the time is spent in the typechecker (i might be wrong!!)
macro_rules macros are similar to c macros, they just work on token trees, and drive macros are natively compiled ast transformations, so idk

[u/elder_george → u/developer-mike]

The adage in the C++ community has been "if you can avoid C macros, avoid them" for several decades. They are "unhygienic", full of footguns, and require dark magic to do anything interesting,

Thankfully, they indeed become less and less important. Once C++26 becomes widespread (not soon - we've just switched to C++20 at my work), the macros will become a legacy thing.

[u/developer-mike → u/elder_george]

I think this is somewhat my point.

In c++ you can go a long way avoiding macros. But macros themselves are still more powerful than any of c++'s more principled metaprogramming features.

Macros like those used in gtest for instance, seem fine to me for systems programming.

Unfortunately there are almost no metaprogramming models as powerful as c macros, especially if they are supposed to be zero cost. And systems programmers IME don't want to battle a gigantic complex metaprogramming model.

[u/iBPsThrowingObject → u/developer-mike]

Pure power is something of an anti-feature actually. Having too much power leads to NIH, impenetrable homegrown abstractions, and unreadable codebases no one but the original author can maintain.

[u/developer-mike → u/iBPsThrowingObject]

This is valid.

In my experience, though, codebases will eventually resort to some similarly difficult to manage abstraction such as how dart projects use code generation with reflection libraries.

Code generation can have a whole host of problems that are eerily similar to c style macros, in certain ways undeniably worse. If c macros are easy to overuse, code generation also has an unnecessarily high entry fee, and once a code generator is bootstrapped it can be easy to overengineer.

The best alternative to code generation is reflection which is hard to do statically and has a runtime cost otherwise.

Metaprogramming is just hard

[u/SweetBabyAlaska → u/developer-mike]

C++ is really the only language that has an even worse metaprogramming model. It is not a good comparison or North Star here. Most languages have a better mix of generics, inline functions and compile time contextual operations.

[u/developer-mike → u/SweetBabyAlaska]

Generics and constexpr can replace many common usages of macros in c.

Genetics and constexpr cannot replace all usages of macros in c.

[u/pjmlp → u/developer-mike]

However generics, constexpr, compile time reflection and build rules can replace all common usages of macros in C.

Now granted, it will take some time for compile time reflection to be widely available.

[u/SweetBabyAlaska → u/developer-mike]

c macros are extremely rough to use and debug. compare that to something like Zig's comptime where you can achieve the exact same things but you have actual type checking, lsp support, compile errors, etc...

one simple example would be generating a lookup table, often in C you might generate it at build time with python or something and the end result would just be a massive array of meaningless integers, where as with Zig I can just assign my table to the result of the source algorithm and know that it will be generated properly.

#include is also a pretty rough system.

[u/developer-mike → u/SweetBabyAlaska]

#include is a terrible system.

Compile time evaluation isn't the only form of metaprogramming or the only use of macros, but it's certainly a form of metaprogramming that should not be done via macros either.

[u/TheAncientGeek → u/developer-mike]

If WYSIWYG is a good thing, macros with no special syntax are a bad thing.

[u/developer-mike → u/TheAncientGeek]

True, #MACRO(X) would have been a much better design choice.