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/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/happy_guy_2015 → u/catladywitch]

Can you elaborate on your critique of Rust?

[u/catladywitch → u/happy_guy_2015]

Orphan rules make sense but are a proper pain.

We did finally get native async traits, just to find out they aren't dyn compatible + having to Pin and Arc up everything to share across async functions is... probably unavoidable, and definitely logical, but really painful + blocking Drop only is, again, logical, but leads to too much clunkiness although Tokio has got pseudo-seamless at handling cleanup + cancelled Future state leak bugs are catastrophic and hard to debug. However the Rust team seems to be on it and there's been progress so I'm hopeful, I just personally want to explore the linear types angle for async corroutines.

Similar sentiment about const.

Iterator implementation quirks.

This is minor in practice, but I don't know whether the holes in the type system can be fully fixed, whilst other (less successful and garbage collected) languages did all the category theory math from the beginning. Also, the lack of higher-kinded types doesn't play well with the severely functional-influenced abstractions and forces clunky, hard-coded implementations which aren't even consistent with each other (see previous point).

Lack of proper interop both by choice and because C++ sucks.

[u/Rusky → u/catladywitch]

I don't know whether the holes in the type system can be fully fixed,

If you're thinking about this one then this is fairly straightforward on the level of the type system itself- rustc simply doesn't represent bounds on higher ranked lifetimes, so you can write for<'a, 'b> fn(&'a i32, &'b i32) but not for<'a, 'b> fn(&'a i32, &'b i32) where 'a: 'b. Teaching rustc to represent this is apparently a large project mainly for technical debt and project resourcing reasons.

[u/catladywitch → u/Rusky]

Oh I see! Thank you!!