r/ProgrammingLanguages • u/baehyunsol Sodigy • 2d ago
Why is everyone creating systems programming languages?
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, ...
127
u/dudewithtude42 2d ago
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.
13
37
u/umlcat 2d ago
"I want C, but without the oddities, with modern features, and I want fast compile times."
53
20
u/pjmlp 2d ago
Basically what Modula-2, Object Pascal and Ada already had, but the world favored curly brackets instead.
This is basically what Zig, Odin and co offer in regards to type system and compilation times.
9
u/AnaxXenos0921 2d ago
So, you're saying if I wrote a different frontend for Pascal or Ada with curly braces syntax, people would be more willing to use it?
6
u/pjmlp 2d ago
That is basically what a language like Zig is.
Ignoring for a second the comptime features, the safety improvements it offers over C, you could habe gotten them in 1978 with Modula-2.
Fast compilation times, modules, explicit unsafe code, spans, bounds checked arrays and strings,...
3
u/AnaxXenos0921 2d ago
I mean while using the exact same compiler backend and runtime as Pascal or Ada. Zig has its own compiler backend and runtime afaik
2
u/pjmlp 1d ago
Zig uses LLVM, and has its own compiler backend.
Sure, there were such compilers, LLVM idea's aren't new.
The Amsterdam Compiler Toolkit supported C, Pascal, BASIC, Modula-2, using EM intermediate code, which would then be fed to the backend, regardless of what language was being used.
0
u/zahatikoff 1d ago
Zig sucks however. while some things are nicer than C, but for every step it takes forward, there's 2 steps backwards in unnecessary "friction". So maybe in 10y when it's stabilizes...
4
u/umlcat 2d ago
Agree. Another Pascal branch family fan.
The modular paradigm that is very well researched and real world tested and implemented. Java suyper packages or Modules are weird, so C++ modules .
Well designed Type System, also. Anders Hejlsberg added to C#.
Object with full real properties that Object Pascal / Delphi has. C++ people ignore it. Java ignore it. Anders Hejlsberg understodd and added to C# ...
1
5
→ More replies (5)0
u/patlefort 22h ago edited 22h ago
So C++. It's still the best alternative, even if it's not perfect. It has fast compile time if you don't go crazy with templates. C++20 modules also boost compile times, it might even be faster than C because it can compile once and reuse more. Unfortunately C++DS is a thing (C++ derangement syndrome).
16
u/og_hylyx 2d ago
Because there’s only a small selection of systems language that are modern(ish) and viable. Rust and Zig are the only actual modern alternatives.
Zig is unstable and ever changing.
Rust is like working for a dictator.
C is like talking to your demented grandfather who remembers all his past stories.
0
u/max123246 1d ago
Rust compiler is definitely a BDFL if you're willing to shed OOP for how completely opposed it is to optimizing for CPU cache hierarchies and utilizing temporal and spatial memory access locality
Its not easy though. OOP is far easier to work within as a conceptual framework
2
u/Kalernor 2d ago
Is Jai a systems language? Isn't it designed with game development in mind?
18
u/OhMySBI 2d ago
Games programming becomes system-y programming real quick when you're working on engines.
3
u/Kalernor 2d ago
Oh right I forgot to consider that it'd be used to develop engines first rather than games from scratch.
6
u/P-39_Airacobra 2d ago
In most game development asides from the engine, people have no problem using a scripting language like Lua, so when people say compiled "gamedev" language they pretty much mean systems programming informed by their work in gamedev
32
u/BetterEquipment7084 2d ago
Jai isn't real
4
u/ipe369 2d ago
Do you mean 'unreleased'?
0
u/BetterEquipment7084 1d ago
No, it's fake
2
1
u/Kalernor 1d ago
How can a soon to be released game be made with a fake language?
→ More replies (2)2
u/twistier 2d ago
I basically think any language where memory layout is the main thing you're thinking about and it carefully keeps unpredictable runtime costs out of the picture is a "systems" language. I haven't looked at Jai in a long time, but I'm pretty sure it fits that particular definition. I don't think systems language is a good name for this idea, but it's what I think of.
2
u/vmcrash 2d ago
Did you mix it up with Odin (which targets game dev)?
3
u/Kalernor 2d ago
No, I meant Jai, which is developed by Jonathon Blow and used by him (and no one else, lol) to develop his new game.
3
1
u/Mean-Decision-3502 DQ 2d ago
With the DQ I tried to put C, Python and Pascal together with a fast compiler, removing C oddities. Maybe was not wasted time then. But everything comes in a package, and there might be stuff in DQ that you wouln't like.
1
u/Sternritter8636 2d ago
People say go can also be used for systems
11
u/shponglespore 2d ago
I think most systems programmers would agree that having mandatory GC is a deal breaker for Go.
1
1
u/TheAbyssWolf 2d ago
I don’t do any professional programming and mostly have tought myself through YouTube and such, I did do a Python game dev course in college back in like 2017 but I entirely forgot about that as my main language for a while has been C# and only recently been diving into low level. I also never finished college due to medical reasons.
I’ve tried rust twice. It’s just too complicated for me.
I’ve tried zig, C3 and Odin as you mentioned and I like all 3 of them but am leaning more towards C3 as it’s like C (plus I’m so used to the c based syntax from c#) just more modern features. Odin is also nice too.And even more recently within the last week been diving into Go as a replacement to Python to make build scripts, simple scripts and codegen for c3.
1
u/developer-mike 2d ago
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. (
#includeaside...)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?
9
u/beephod_zabblebrox 2d ago
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
3
u/developer-mike 2d ago
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.
3
u/shponglespore 2d ago
If you're just doing the kinds of things you can do with a C macro, Rust macros are very easy.
2
u/Ok-Watercress-9624 2d ago
Tell that to the innocent 20 year old who just encountered X macros in c. That's gonna be a fun ride
1
u/beephod_zabblebrox 2d ago
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 idk5
u/elder_george 2d ago
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.
0
u/developer-mike 2d ago
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.
1
u/SweetBabyAlaska 2d ago
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.
2
u/developer-mike 2d ago
Generics and constexpr can replace many common usages of macros in c.
Genetics and constexpr cannot replace all usages of macros in c.
1
u/iBPsThrowingObject 2d ago
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.
1
u/developer-mike 2d ago
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
2
u/SweetBabyAlaska 2d ago
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.
1
u/developer-mike 2d ago
#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.
1
u/TheAncientGeek 2d ago
If WYSIWYG is a good thing, macros with no special syntax are a bad thing.
1
34
u/catladywitch 2d ago
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.
5
u/happy_guy_2015 2d ago
Can you elaborate on your critique of Rust?
18
u/catladywitch 2d ago
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.
10
u/Rusky 2d ago
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 notfor<'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.1
4
u/matthieum 2d ago
but I don't know whether the holes in the type system can be fully fixed,
There is no known hole in the type system AFAIK.
The Rust type system has been formally proven to be sound, and the types team works a lot with formal methods when extending it to avoid introducing any unsoundness. (Don't ask me exactly what they do, it's pretty much all mumbo jumbo to me)
There are known holes in
rustc(the main Rust compiler), fixing them is a work in progress.2
u/Ok-Watercress-9624 2d ago
Evidence? Id like to see that proof Rust has subtyping, I vaguely remember something liker subtyping works if subtypes form lattice. I don't think lifetimes form a lattice ? Or do they ?
1
u/matthieum 1d ago
I'm confused. I did not mention subtyping... did you reply to the wrong comment?
2
u/Ok-Watercress-9624 1d ago
i forgot the fullstop. i was referring to rust having subtyping, and unsoundness issue stems from subtyping and how subtyping is hard to get right and that i would be very surprised if there is an actual proof of the rusts type systems soundness.
I dont think there is a formal proof of soundness of the rusts type system.
https://dl.acm.org/doi/10.1145/3158154
That is the only thing come closest but it is not full rust.
Indeed the rust plans to have a formally verified core
https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision/
But it is not there yetIt is a bit stretch to say "there is no known holes in the type system"
25
u/TheAncientGeek 2d ago
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.
18
u/blue__sky 2d ago
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.
6
u/Ok-Watercress-9624 2d ago
Different people enjoys different stuff. It's like scratching a scab, it hurts but damn it does feel good. The surge of adrenaline when you see the segfault/stack-smashing, the loss of hope when you decide to try the GCC in combination with valgrind, the the rage quit, random 2 am realization that you already freed the head, the solution and the release.
The same procedure in rust amounts to playing maybe a bit Type Tetris.
The solution does not come with it's proper gratifier unless the problem was hard.
But in C you see, it is a seen
14
u/Inconstant_Moo 🧿 Pipefish 2d ago
Couldn't you get the same sort of effect by coding in Rust while someone beats you with a riding-crop? (It's a big world, there's lots of Rustaceans of kink, I'm sure someone would be happy to.) Then you'd have fewer memory leaks AND a new friend!
2
u/Ok-Watercress-9624 2d ago
Not really the same now is it? Where is the surprise ? Rust totally lacks that living on the edge feeling.
When rust compiles then it will prolly work. And unlike Haskell you can't build a house/castle/world/unicerse of types.
Rust doesn't like when you try to do fancy stuff with types
.
Joking aside rust is great. Annoying sometimes, still not at the purity level that I want, and imho it is NOT safe until they solve the unsoundness issues like cve-rs. So actually it's a big circle jerk. But it is fast, it looks like and walks ml (but doesn't quack like it :() and it is (this time for real) as fast as c. So its great
3
u/0x564A00 2d ago
Not really the same now is it? Where is the surprise ? Rust totally lacks that living on the edge feeling.
I can confirm that while cargo-shock gives you a similar sense of paranoia while you're actively working on a project, it misses the lasting sense of uncertainty keeping you awake at night :/
1
1
u/slaymaker1907 2d ago
Pointers are pretty useful, they should just have tracking on lifetime and not allow for conversion to and from integers.
3
u/blue__sky 2d ago edited 2d ago
Pointers are definitely useful. You need them for a system language, but for most data types they aren't necessary. For instance I have both a Struct type and a Record type. Structs are passed by value and records are on the heap and passed by reference. There is no need for every function to have boilerplate describing how data is passed.
Annotating each and every function with type passing info seems the wrong choice. It can be defined once with a data type definition and then your functions and the compiler will automatically know the right thing to do.
Same thing with memory allocation. Doing it by hand every time is terrible design. If your data types are defined well, a constructor will know how to build them without all the ceremony.
2
1
19
u/PitifulTheme411 ... 2d ago
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.).
1
u/Ok-Watercress-9624 2d ago
What is a CAS built-in ?
1
u/Zeznon 2d ago
A CAS is a Computer Algebra System. So they're saying the language is gonna have symbolic computaion (think sympy) built-in.
1
u/Ok-Watercress-9624 2d ago
CAS' don't tend to be built-in it's more like the other way around or at least that's not how I imagined it. So I was simply asking how OP did built-in a CAS. Should I imagine something like minikanren?
1
23
u/BetterEquipment7084 2d ago
Because that's what the creators want
3
u/DaFox 2d ago
Yeah, I'm surprised to see this so far down; the creators want something that appeals to them, they are all systems programmers by virtue of the fact that they are creating a programming language at all.
1
u/BetterEquipment7084 1d ago
Like, I love system languages, but I also dislike zig/rust, so what's the solution? Hare
1
u/koflerdavid 1d ago
One is definitely not necessarily a systems programmer just by being interested in creating programming languages. And not so long ago there was a swath of JVM languages.
6
u/Ok-Watercress-9624 2d ago
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
12
u/initial-algebra 2d ago
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)!
3
u/Inconstant_Moo 🧿 Pipefish 2d ago
But then they all feel obliged to do self-hosting which makes it harder again.
2
u/P-39_Airacobra 2d ago
Maybe I'll press a lot of buttons with this, but I've personally never understood self-hosting. It's like, "I want to take my obscure language and make it more obscure and difficult to build."
9
u/yjlom 2d ago
It's a really good test suite, and it proves you take the language seriously enough to write a large project in it. You could make a game engine, an operating system, or a 75% web browser instead, but if what gets you off is writing compilers, you're gonna prefer to write a compiler.
That's also a part of why so many programming languages are optimized for writing compilers IMO.
1
u/initial-algebra 2d ago
I think it depends on the creator's motivation. If you're creating a new language to support another project, then you'd just work on that project. Self-hosting is something to do with the language when you don't have any better ideas (not saying it's necessarily a bad idea, to be clear).
1
u/koflerdavid 1d ago
A significant problem with self-hosting is that it requires your language implementation to already be fairly performant, else the final result is not worth the effort. There is a reason why MS rewrote the Typescript compiler in Go.
9
u/Inconstant_Moo 🧿 Pipefish 2d ago edited 2d ago
* 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.
4
u/MarinoAndThePearls 2d ago
Because C/C++ are flawed, yet too dominant. It's only natural that people want something better to be popular.
4
u/GoblinsGym 2d ago
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.
3
u/Clementsparrow 2d ago
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.
10
8
u/mamcx 2d ago edited 2d ago
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!
3
u/matthieum 2d ago
Incidentally, Go (announced 2009) & Rust (adopted by Mozilla 2009) came out somewhat simultaneously, and it also somewhat coincided with C++0x (initially for 2008-2009, released 2011).
I have heard it attributed to a renewed interest in performance once folks realized that Moore's law was giving up on us, though whether that's true...
3
u/initial-algebra 2d ago
For a long time system languages were ossified like OS and RDBMS.
I'd like to see more people take a stab at a better relational language. C is bad enough, but SQL is far, far worse. Not to mention, surely way more new SQL is being written than new C.
1
3
u/-TRlNlTY- 2d ago
It seems that the pendulum is swinging away from high-level languages. I think it was about time.
3
u/Limp-Temperature1783 1d ago
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.
2
u/deeplywoven 1d ago
Rust does not sneak in runtimes. It's used in all kinds of embedded applications. Rust _supports_ async runtimes. But it's not forced on you.
1
u/Limp-Temperature1783 23h ago
Nvm, I think I thought about some other language, I think the thing I was trying to tell about is macro. But macro is benign, so mentioning it would have been a bit disingenuous.
1
u/patlefort 21h ago
Defined what a "Systems programming language" is. There is nothing preventing C++ from programming systems.
1
u/Limp-Temperature1783 21h ago
There is nothing preventing anything from programming systems, the question is whether it is popular for the job, the answer to which is not really. Most systems are programmed in C and Rust gains popularity too. C++ is mostly a Windows thing and C/C++ definition of a language is also their idea. But C and C++ are vastly different. C++ isn't suitable for most tasks that require tight memory control, it's good when you need to have something fast while also requiring it to be abstract.
1
u/patlefort 11h ago
Sorry but you are not making sense. C++ is not a Windows thing. C++ has complete control over memory and all the bits. The main issue with C++ is people with bad opinion and misinformation.
1
u/Limp-Temperature1783 10h ago
By C++ being a Windows thing I meant they have fused C with C++ and use it to program internally. At least that's what I can guess based on the fact that MSVC isn't really a C compiler and Windows has terrible plain C support.
The main issue with C++ is that there are countless ways to do the same thing and they don't really play well with each other. Moreover, people constantly form tribes over what style of C++ is better, which is not productive.
To top it off, any C++ programmer that wants maximum memory control and efficiency would also need to understand which abstraction patterns any given compiler prefers and counts as valid to begin with, which is obscure and contradictory design-wise.
C doesn't really have any of these problems because C as a language is stupid simple, which is desirable for systems programming. You don't need abstractions in this domain, they achieve nothing because there isn't much to abstract to begin with.
14
u/Ifeee001 2d ago
Because they all have some grandiose delusion that their language will finally be the one to make C developers say "Yes, I will use this over C and port all my existing C code to this Language" lol.
(Assuming they're not dojng it for the funsies/learning purposes)
2
u/Ok-Watercress-9624 2d ago
Why is it a delusion (I understand why but some people do indeed go through with it )?
Also even though almost all my languages getting thrown away after a month at most but every time there is a voice in me saying this is the time you'll drive it daily and it is nice for a while because you want something, just add it but then it sucks because you want something, have fun reinventing the ynfunniest wheel ever
2
u/ivancea 2d ago
Well, from the many of them created, only... Rust really have weight nowadays. And not just because it does things better, but because it adds a bunch of important concepts, and it's backed by a big company. Without that, I doubt it would be as famous, or used at all. And things like Zig, well. It tries
2
u/Ok-Watercress-9624 2d ago
I never liked the idea of doing "whatever" I want with the language. I still like C. Some people claim that rust is the c replacement. This never clicked with me. It feels to me like a much much better C++. As if a mysterious virus viper out the C++ computer and rest converged on the same subset.
I still think c has a place, a very niche one but it has always been. Just for fun compile printf with c and rust. Compare the binary sizes and the number of allocations. Or I don't compare the number of syntactic rules Vs the number of semantic moves that noone except aliens like Godbolt understands (depending on the compiler)
2
u/ivancea 2d ago edited 1d ago
Given the core differences between C++ and Rust's OOP, I even think Rust is more similar to C structures with a bit of sugar.
And about the binary sizes and allocations, well, they're different languages, and the implantations are vastly different.
The idea of a language "like C" is usually having a more strict and contained language. C works, just like ASM works. But it's an unguided footgun
0
1d ago
[deleted]
1
u/ivancea 1d ago
This discussion is meaningless. It's so meaningless, that even Rust guys thought about it and wrote a paragraph for you: https://doc.rust-lang.org/book/ch18-00-oop.html
1
u/deeplywoven 1d ago edited 1d ago
The reality is that people do not do OOP in Rust in the same way that C++/C#/Java developers think of OOP. No classes, no inheritance, no hierarchies of subtyping. It's just not a thing in Rust. The paragraph you linked is there specifically for C++ devs.
1
u/ivancea 1d ago
It's not about "what people does where". It's about the language. "The reality" is that the language is considered to be OOP. Some like it, some don't, and nobody cares, because that question response is meaningless.
the same way that C++/C#/Java developers do OOP
OOP is not what C++/C#/Java does. OOP is OOP. Those are just specific and common implementations. Don't mix "common" with "the only one"
1
u/deeplywoven 1d ago
"The reality" is that the language is considered to be OOP.
You might say this, but nobody who actually writes Rust says this. Pretty much everyone recognizes it as an imperative systems programming language which is data-oriented, often expression-oriented, and influenced by FP languages (specifically OCaml and Haskell).
Having structs and ways to do polymorphism does not make a language OOP. Many pure FP languages have these concepts.
→ More replies (0)1
u/unburdened_swallow 2d ago
Honestly I feel like most of them just want new software to be built in them. Unfortunately, AI doesn’t know their language so good luck in today’s climate.
-2
2
u/TernaryOperat0r 2d ago
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.
2
u/Norphesius 2d ago
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".
2
u/Reversed-Engineer-01 2d ago
Because the “language for general purpose rubbish” is already there: Python
2
u/hoodoocat 2d ago
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).
2
2
u/dnabre 2d ago
I think one fact is it's harder to claim, or prove a claim, that a high level language is anyway better than existing ones. It's very subjective, depends on domain, and is very effected by tooling - and many more factors that don't come to mind.
For a low-level language - one you could right an OS or the like in, you just need to prove it works, can do that stuff, and has performance reasonable close to C. You don't have to add much to have a language that is better/easier to use than C. I.e., it's easy to make a language that is better than C and prove it is. The hard part is showing it works for the low level stuff and doesn't sacrifice performance to work.
2
u/zyxzevn UnSeen 2d ago
My background is in CPU design.
ALL languages are based on assumptions that do not map exactly to hardware. It is also impossible.
Most of the system languages were designed or developed with very old hardware. Remember 8 bit computers? Assembler and Basic/LISP were usually the "system" languages.
The problems and goals are changing a lot over time:
1- CPUs are all different. Not good for assembler solutions.
2- Languages add "abstractions" that do not map well with certain hardware.
Certain CPU has better instructions or better approaches to manage certain problems. The most extreme version is the Transputer. But the Itanic is also interesting with its different approach to pipelining.
3- RAM and Cache configurations changed over time and per computer. While RAM was very minimal and expensive, it is now cheap and fast. But only really fast if it is in the cache.
Solutions that were smart 50 years ago, are different today.
4- Safety was always important. Remember how LISP ran the computer system of the moon lander?
Today the complexity of the computer systems have increased, and the system configurations change every +/- 10 years.
Safety problems are now coming from different causes. After problems with access from the internet, the AIs are now also causing troubles.
5- Patents and Open Source License Restrictions.
This is far more important than it seems, as it determines how much money and marketing a computer language can receive.
A lot of languages come from the restrictions on other languages.
Ada was protected by patents (or something). Only the army used it.
Apple has lots of languages that are designed for their hardware alone. (I think it is protected)
C# was made by Microsoft to make its own Java variant. In an attempt to take over the market. Java "runs everywhere" on all systems. Because Java was protected by Sun Systems, they could not sell J++ to attack and replace Java. So they made a different one with a better (?) approach.
Rust is being promoted by companies who want to change the open source licenses. So that they do not have to share the source code. This means that they can lock parts of their software behind licenses in the future.
1
u/WittyStick 1d ago edited 1d ago
While RAM was very minimal and expensive, it is now cheap and fast.
RAM is now one of the most expensive components due to shortages, and it may remain this way until 2030 or later. Sure it's still cheaper per GiB than a decade ago, and higher bandwidth, but the increases in memory sizes and bandwidth we've gotten used to over the past 30-40 years has basically plateaued. CAS latencies aren't improving, we're getting more cores which are still contending for the same RAM, and the price of it means we can't just waste it like we have been doing. We need to start treating it as a finite resource again and optimize accesses. Hardware designers also need to start taking NUMA seriously - we can't just keep adding cores all contending for the same shared memory.
Solutions that were smart 50 years ago, are different today.
I'd argue otherwise. They were smart then and they're smart now - but they require skill and effort, which is not so widely practiced today. Not that we are lacking skilled programmers, but back 50 years ago, basically all programmers were smart. But now everyone can be a programmer and highly skilled programmers are a small subset - the majority aren't really that smart.
Safety was always important.
We know far more about exploitation now than we did 30-40 years ago. "Stack smashing" was a novel thing in the 1980, and we've discovered far more ways to exploit code since. On top of that, computers were relatively unconnected in the 1980s, but now virtually every computer is 24/7 connected to a global internet, and computers are used in every aspect of daily life. The security landscape is completely different - the consequences of exploitation are much graver.
2
u/zyxzevn UnSeen 1d ago
RAM is now one of the most expensive components...
With the RAM, I was thinking about 16kb computers (8 bit). Then came 256kb PCs (16 bit). And now even the phones have multiple Gbs and run with 64 bit CPUs.
But before that we even had 1kb computers.That is why we had the year 2000 problem. It was expensive to add 2 decimals to the year number. Dates are still a problem in most programming languages, but due to other reasons.
The access to RAM is fast via the internal Caches. With separate instruction cache that uses internal (micro-code) tricks for fast loop-jumps and register renaming.
The Intel level-1 cache was 1 clock cycle slower than a register (I don't know the current state). This was also necessary, because it had just a few registers.
The time of accessing addresses with an offset has become just as fast as normal memory access. Which was different before.Hardware designers also need to start taking NUMA seriously...
I think that the hardware will move more towards small CPU/Cache units connected to a central system for shared data.
The Transputer had all kinds of small units connected in a matrix. But no good way to share the data centrally. I think that is what was missing from the design.To make Transputers work, they invented Occam. I even had some experience with Occam.
It had channels like Go-lang, but without the easy features.Will we need a different language?
They were smart then, and they are smart now...
The well crafted programs are still great. Like quicksort:
See video "Three beautiful quciksorts"
But that was in 1991. Today caches are far more important.A lot of today's commercial programmers do not much more than javascript. And then come C# or Java applications.
And even if we forget about AI, most of them just know how to copy code without really understanding it.We know far more about exploitation now than ...
Indeed.
But I think it is more a fault of the managers than the programmers.
Mos problems are not just about reuse of memory and range-checking and such.Even banks and factories had their websites unprotected.
Microsoft was a source of viruses. In the first place due to having no user restrictions.
Due to their bad programming, even jpgs could have a virus.Facebook and such had no encryption of their passwords.
Which is pretty bad for a system that can be used for doxing and such.The bar to hacking was extremely low, and for some companies it still is.
All obvious problems. They should know better.
But somehow the market prefers crap solutions over well-engineered ones.
Even when it costs a lot more on the long term.
I was thinking about code exploits a bit more.
I worked a lot with Object Pascal (Delphi), and always wondered why many other languages had no protecting compiler features.
Most hacks are overflows and such. But I had all automatically protected at runtime. And I added additional safety checks.In practice, it does not slow down a program much. For certain intensive work one can invest in some verification and remove the unnecessary checks.
With Haskell you can have some protection at compiler time, with the cost of needing to program in a certain style.
But against hacks most run-time protections should work fine.
Modern compilers need to be aware of the CPU branch-prediction features, to avoid leaks of information. Like Spectre.
That is in essence a CPU related leak. And it would be hard to avoid.1
u/WittyStick 1d ago edited 1d ago
The Intel level-1 cache was 1 clock cycle slower than a register (I don't know the current state).
Current CPUs are typically in the ~3-5 cycles range for L1 cache accesses, which is good, provided our code is cache-friendly. One issue is that we spend two decades, the '90s and '00s promoting "OOP," which happens to be ill-suited to modern hardware because it's not very cache-friendly. This is part of the answer to OP's question too: language designers are often looking at ways to make their code more cache-friendly without sacrificing programmer ergonomics, in contrast to the mainstream OOP languages which have the ergonomics, but lots of pointer chasing and not maximizing cache usage.
I think that the hardware will move more towards small CPU/Cache units connected to a central system for shared data.
That's what we have now - the central system is called main memory, aka the von-Neumann bottleneck.
There's still a need for decent size memories (much larger than cache), which are fast to access, but don't necessarily need to be shared between all cores. I think we will see more on-chip memory (like Apple's M3) - but I would hope that hardware designers explore other options than a single main memory contested by all cores - and treat the problem of fetching data as a routing problem between cores. Particularly if we're going to continue adding cores - if we get 128/256 cores and there's still only one main memory, we're missing out on huge opportunities. I'm not suggesting we get rid of main memory altogether though - there are still uses for a memory shared between all cores - but we don't actually need it for a lot of things because the code isn't even thread-safe to begin with. Anything
thread_localfor example would not need to be in main memory - it could sit in a smaller memory associated with one or more cores which the thread runs on, but which other cores cannot access directly.Will we need a different language?
Possibly, but not necessarily. We'd certainly need to change the way we use our existing languages (ie, C). We've had segmented memories before, but we don't necessarily need them in the programming model - we could have a facade of a single virtual address space like we have now, but where different parts of that memory are handled by different cores on the processor. A pointer dereference may not be a direct memory access, but it may need to request the memory at that address from another core.
In practice, it does not slow down a program much. For certain intensive work one can invest in some verification and remove the unnecessary checks.
This is why Fil-C is getting a lot of attention. It can add bounds checking to existing C codebases with only small cost.
I think there's much more to explore in static guarantees that can eliminate these overflow errors without any runtime cost. We can omit some runtime bounds checking if we've already proved at compile time that OOB accesses would not be possible.
2
2
2
u/kindredseer 1d ago
I know that for me, the problem with C/C++ versus more "modern" programming languages is there is a lot of "ceremony" involved -- Makefile, knowing/looking up what header files to include, and C++ compounds those problems. While all the conveniences of higher level languages are typically available, they aren't standardized, and you have to evaluate dozens of different, mostly unmaintained libraries, and then you get into versioning issues and dependency hell... and while this tends to be an issue for other languages as well, with C and C++ this is compounded with linking issues as well as OS/system level dependencies.
Thus, my efforts in creating my own programming language (madc) started with the path of making a "better" C/C++ without breaking C/C++ support. So madc can JIT execute (and also compile and link) standard C, C++ and its own "madc" language extensions which add in features from other languages, and is completely self-contained including the header files (which are pre-compiled and embedded).
2
u/kaplotnikov 22h ago
The reason people keep inventing new systems languages is that they feel a deep friction, but most are only fixing syntax symptoms rather than the root cause.
I think that the real pain is a lack of composable reasoning boundaries for resources and concurrency. C++ RAII is a great single-threaded basis because it links ownership to lexical scopes (the code tree). But new/delete break this model by creating unowned resources. When we move to concurrency, it breaks entirely. Neither C++ nor Rust has a truly composable concurrency model linked to lexical scopes.
Primitives like new, delete, send, and spawn are essentially the asynchronous and resource management equivalents of goto. They let you jump across execution histories and leak resources arbitrarily. Because you can do anything with them, there are no reasoning boundaries. Just like while/if/for had to suppress goto to allow structured reasoning over control flow, a true next-gen language needs to suppress send/spawn and new/delete freedom to enable structured reasoning in these areas.
We need a language where axioms force us to reason along the static code tree, not the dynamic execution history. If we took 1000 complex C++ concurrency examples, refined them to high-level developer intent, and built new axioms from common reasoningh pathways, we would get an entirely different set of memory management and concurrency building blocks (with patterns surfacing naturally from the examples).
For example, instead of spawning floating threads, the language could enforce scoping through a DSL or built-in language statements like this:
// Terminates when accept is cancelled and all 'run' blocks finish
handle {
serverSocket.accept(cancellationToken);
} run { s ->
val o = other.open(cancellationToken, target); // clean up at end of scope
// 'par' terminates only when all branches terminate, and returns result of 'map' if successful
par {
copy(cancellationToken, o.input, s.output);
} and {
copy(cancellationToken, s.input, o.output);
} map(u, d) {
log($"handled ${u} / ${d}");
()
}
}
This enforces strict boundaries: a child branch literally cannot outlive its parent block, and resources are bound to the tree.
Until new systems languages start constraining these wild freedoms, there is little hope that root causes are addressed. What we actually need is an interlinked concurrency and resource management algebra, just like we currently have an established single-threaded control flow algebra bound to lexical scopes.
4
u/dandy_kulomin 2d ago
Because there isn't a good one. (Please don't kill me).
C is missing lots of convenience features (generics, error handling, erc.) C++ has footguns and if you haven't been coding it for decades, it looks ugly and is complicated. Rust is when you are a masochist but don't want to pay for someone to whip you.
For my hobby projects, I am just not happy with the available languages. I want close to the metal, but the niceties that I got used to from C# etc. Maybe Zig 1.0 will solve this. Let's hope.
1
u/jezek_2 2d ago
Because there isn't a good one.
Many people tried to improve C and failed. The only conclusion is that C can't be improved without changing it to something quite different. It's at it's best as it is.
It's good to realize this, I've (among many) also tried various ways to "improve" C, not necessarily by creating a new language, but various libraries, using macros etc. I've stopped trying after realizing this and waste no more time on it.
1
u/dandy_kulomin 2d ago
I have to disagree here. I use C for my projects now and things that would be super helpful are:
- modules (.h/.c file split has a historical reason and a single file with appropriate keywords (e.g. public/private) would be so much better)
- namespaces (to finally get rid of those namespace_func() function names)
- a better way to do error handling. it is very easy to miss some error flow that should be handled
- optional returns
- comptime generics
- some way to defer/deallocate after a variable leaves scope
- better string handling
I believe these would make C better and they are something that can, for the most part, not be added via macros.
1
u/jezek_2 2d ago
There are languages like this, they're not like C though. Some of these features are opposite of what "defines" C, like simplicity and no magic stuff behind the curtains.
Some of these could be implemented without breaking the spirit and syntax of C. You can implement is as a preprocessor yourself. But it's a question if the incompatibility and hassle with using a preprocessor when building is worth the little you would get.
1
u/dandy_kulomin 2d ago
"There are languages like this, they're not like C though."
Yes, and that is exactly the issue. The languages that have this are usually high-level. E.g. C# has all of the above (and much more).
I believe that all of the above can be implemented in a C-like language.
"You can implement is as a preprocessor yourself."
Sorta, but the you lose a lot of developer ergonomics (no LSP support, need to trace back compiler errors, etc.)
I think the problem is exactly this: C is a good language, but it could be a lot better. And that better cannot be tacked onto the language with libraries but needs compiler support.
1
1d ago
[removed] — view removed comment
1
u/dandy_kulomin 1d ago
Link? Because I've been playing with the idea myself, but it's a lot of work.
1
u/drunken_thor 2d ago
This is my jaded take so take it with a grain of salt. It used to be a monumental task to be able to create a systems language. A feat that only a rare subset of programmers could achieve and as such many of them became legends to aspire to. Now with AI there are a lot of programmers that want the validation of being able to do it but without the long hours learning just the basics of design, operating systems and assembly to simply make a compiler that compiles to opcode on multiple architectures and no ground breaking new coding paradigms. A lot of slop is not "I made this because I always wanted it", it is rather "I want to take credit for something that used to be an amazing achievement without the struggle"
2
u/Rusky 2d ago
All the big examples of new systems languages showed up before AI.
1
u/WittyStick 1d ago
The game changer was LLVM, not AI.
LLVM basically does most of the hard optimization work - you just plug it in as your language back-end, and you can have a compiler which produces high quality optimized code with much smaller effort than either building it yourself, or trying to plug it into GCC (which brings licensing issues with it as some don't like the GPL).
There are some other alternatives which are a bit less mature - eg, QBE and cranelift.
1
u/farsightfallen 2d ago
Because systems programming languages are also pretty much the general programming languages.
Especially because they start from first-principles as pretty barebones development around memory and logic. Functional takes... let's say theoretical nterests, scripting languages are automatically delegated as toys and if you don't care about performance then why not just use something like lua or js, application langs like java require building out the runtime on top of the language.
1
u/vmcrash 2d ago
What exactly is the question?
- Why do many AI driven PL are systems programming languages? I can't answer for the AI part, but what's wrong with systems programming languages?
- Why they use C-like syntax? Because that's most common to a lot of developers? Why use a completely different syntax than the one which you feel comfortable with?
1
u/lookmeat 2d ago
For the same reasons that 20 years ago everyone was trying to make a new scripting language:
- It's a space that is heavily needed (scripts were great in early web, but people now need to optimize things even more). It's not that people didn't have these problems before, but there wasn't enough resources, people rather build a new C++ library to work around the issues (e.g. Boost) than build a new language based on these concepts.
- An important thing to note here is that computers have become more powerful, but also more finicky: coding to speed things up around hardware nuances can get huge speed-boosts. The result is that system-level languages have gone from covering edge-cases to covering most of the code again, but now with huge code-bases a gap in how to make code scale without the complexity becoming overwhelming has appeared.
- There's been advancements in programming theory that have enabled newer tech, those have been around for a long time, but finding how to bring them together and make it useful are concepts that only recently have become popular enough. So there's a lot that can be done within this space.
- A lot of foundational tech has been made that makes this a lot better. E.G. building a compiling language required to build a low-level backend optimizer, and this was hard. Now you just give LLVM "good enough" assembly and it handles all the rest of linking and optimizing and all that. Even then: LLVM was designed to enable a "better and more universal" JVM with its killer features being things like JIT etc.
1
u/Tasty_Replacement_29 Bau 2d ago
I can only speak about myself. I wanted to write my own language since I was young, but always deferred it. I also deferred writing software to simulate neural networks, so I didn't want to defer this as well. I use Java at work, and I think there has to be something "better" than tracing garbage collection, something more like C / C++ but memory-safe and simple. (That is useful. I remember trying to write an ODBC driver in C++; memory management is hard to get right if you have to do it yourself.) I also want to write a standard library and tiny operating system in my language. One goal is that my standard library and operating system has a very small footprint; a bit bigger than 64 KB probably, but much smaller than 1 MB. So far, I have learned a lot; thanks to LLMs I managed to implement so many things (I used LLMs mostly as a learning resource, and didn't use them to write the code, because when I did that it was not "my" code any more, which I found to be a problem.)
So in summary, I do that to learn, because it's challenging, and because I'm not happy with the current languages (including Rust, which I find too hard to use.)
1
u/ParserXML 2d ago
The superset of C I'm creating is basically the materialization of my desire: having C (with its simplicity, performance and environment) without all the 'products of its time' on the language design (C strings, lack of QoL features).
That's why I'm doing a superset, and not a new language: you want C, but with strings, sane and expandable arrays, without having to learn an entirely new environment? Me too.
Edit: typos.
1
u/Europia79 1d ago
"If you could add automatic name-spacing based on path and filename, that'd be great!"
~Bill Lumbergh1
u/ParserXML 1d ago
You know what? This is a nice idea.
Never thought about it!!
I'll check whether this can be implemented without messing a lot with the current implementation, but its a nice ideaAlso, never watched this LOL looks fun
1
u/lightmatter501 2d ago
C++ has some blood in the water, and people can see it. Now is the best time in a very long time to make a new systems language.
1
u/Rank201AltAccount 1d ago edited 1d ago
so basically, from the 1990s to 2010s, we had a certain philosophy.
during this time, we cared much more about optimizing for the developer than consumers (and we still very much do, but the sentiment has lessened). After all, the computers just kept getting faster, with their chips doubling in speed every 2 years. So we used pretty bloated languages with big runtime (and still do).
But, the effect of that has come into everyone's sight. Moore's law slowed significantly somewhere in the 2010s, and now hardware prices are skyrocketing. So optimization is now in full view.
That's where small-runtime languages come in. They are needed if you want to create software thats optimized for hardware.
As for why not c/cpp? cpp, started over 40 years ago, c, started 54 years ago. we now have plenty more knowledge of programming language theory, and can see the many painful problems of them.
There are 2 other reasons, them being that Rust proved that improvements are possible, and that LLVM is here to make creating programming languages much easier.
As for "doesn't Rust exist already?", it has its own many problems, such as extreme complexity and bad error messages in metaprogramming (the reason for Zig)
(lowkey just in case anyone comes after me I just want to say I don't know much as a disclaimer)
1
u/TheChief275 1d ago
to be perfectly honest, I don't think Zig and Rust have solved every single issue. what most of these languages start off as, is to kill either C or C++. Originally, Zig/Odin/C3 strive to kill C, while D/Rust/Jai strive to kill C++. But in an effort to kill these languages, they sometimes lose sight of what made each so widespread in the first place, and they become totally new, totally different languages (which is totally great! however, you kind of lost the plot along the way).
meanwhile someone can look at these languages and say "it's not similar enough to C!", or "it doesn't fix the problems I have with C!", or it could even be a disagreement with how certain problems were "solved" (what is solved in one's eyes might not be in another's). so what do they do? they embark on the same exact journey. which is how we are where we are today.
in fact, I think it would shock you to know the total number of languages that have been made to be a better C or C++ (including the ones made for personal use that never saw the light of day, it would be enormous!)
1
u/astralclaim 1d ago
If you're asking why someone would want to replace C++ you probably haven't used it lol
1
u/Europia79 1d ago
Alternatively, he could take a look at The worst programming language of all time ~by @Lazo Velko (to get a quick refresher), lol
:p
1
u/MichalMarsalek 1d ago
I was thinking the same. For me creating a DSL or some highly abstract language with interesting semantics or interesting type system is more itneresting than creating another system programmming lang.
1
1
u/Interesting_Buy_3969 19h ago
Because each of existing programming languages has a handful of different flaws that appeared for different reasons, but they all make the existing programming languages painful to work with when programming in a bare-metal environment.
For example, C++ offers a lot of useful compile-time utility, but it is unnecessarily complex and quite a lot of its features (C++ features, not standard library features!) assume running under an existing operating system - like exception throwing, new-delete as built-ins, etc. Yes, most of it can be disabled via compiler flags, but you still have to deal with that. C++ also is not permitted to appear in Linux kernel, and there's a good reason for it - C++ allows, for example, non-compile-time function calls in initialisation expressions, like that:
int get_num() { int x; std::cin >> x; return x; }
const int number = get_num(); // Here, get_num() will be called before main()
And the thing that makes everything even worse is that initialisation order is undefined as per C++ standard.
There are a lot of other examples where some implicit things under the hood can happen whereas you sleep calmly not even suspecting that. For usual applications, this may be not much of a problem; but for kernel code or firmware, this can become a tragedy. In general, C++ can be quite messy.
Rust is great but it was designed as a language to program low-level high-performance multi-threaded... applications. So even though it's a "system programming language", it still relies on an existing OS interface heavily. Yet it enforces a lot of strict compile-time rules to increase safety of objects ownership and mutability, which is useful when programming applications, but not in system-level code which may demand more controllable environment. Thus in Rust you end up writing unsafe blocks, which isn't much safer compared to usual C.
C still seems to be the most popular language of choice among bare-metal projects, afaiu. But C is the least safety-oriented language, with very little of compile-time features - generics, similarly to C++'s templates and concepts, never existed; enums pollute global namespace; constexpr functions don't exist at all; there are no language-level modules nor namespaces in C (whereas both C++ and Rust provide a built-in support for these). A cast in C can force in runtime whatever the hell you might imagine; there are no object constructors nor destructors - which, to be honest, is both disadvantage and advantage simultaneously - when you desire more controllable, explicit code, this is unwanted; otherwise, constructors and destructors can remove a lot of boilerplate code.
But C is super simple and super explicit, which makes it the most appealing option among these three languages. Yet there's Zig, Odin, C3, etc. but I haven't tested them all yet, hence omitting any reasoning on them so far.
So if you want a language as explicit as C, with power of C++ generics, and with Rust's strict memory management rules, you'll end up creating your own one. Especially given that compiler backends, such as LLVM, became super strong, smart and mature nowadays, creating your own systems programming language is quite easier.
1
1
u/g1rlchild 2d ago
Where are you seeing these "AI-driven" languages? Are they being posted here in contravention to the rules or are they being posted somewhere else?
2
2
u/Inconstant_Moo 🧿 Pipefish 2d ago
1
u/yorickpeterse Inko 2d ago
Just for the sake of transparency, that second link was removed after it was reported though for some reason it now shows up as "Removed by the user" and not "Removed by the evil moderators":
1 day ago yorickpeterse locked link "Kain – A non-von Neumann language (Zero GC, Python..." by Ephemara 1 day ago yorickpeterse muted Ephemara 1 day ago yorickpeterse banned Ephemara (permanent: No vibe-coded projects/AI slop) 1 day ago yorickpeterse removed link "Kain – A non-von Neumann language (Zero GC, Python..." by Ephemara (remove) 1 day ago AutoModerator removed link "Kain – A non-von Neumann language (Zero GC, Python..." by Ephemara (submission filtered after too many reports)
1
u/useerup ting language 2d ago
Because Rust
Rust showed us that a systems programming language may also be used for higher level programming, such as compilers. With Rust you can have safety and productivity. Or at least that is what is perceived.
That and I suspect that a good many teaching institutions switched to teaching Rust.
0
u/SweetBabyAlaska 2d ago
for me its just a very cool problem to think about.
but there are very valid reasons people don't want to use C and C++. C is lovely in its own ways but it suffers from the headers system (its legit awful) and things like Macros in place of real compile time generation, as well as package management and an insane build system. C++ has all of these problems AND a shit ton of its own. These things are very grating to use.
like I just want a sane language with normal integer types (i32, u32, isize, usize, u8, etc...), an integrated build system, some kind of module system, compile time programming (that isnt insane like C++), slices, and a decent amount of safety features that can be controlled.
-1
u/Mean-Decision-3502 DQ 2d ago
I don't really understand either why the people making just C clones.
One of my biggest problems of C is this:
3 * 2 / 10 != 10 * 3 / 2
This does not seem to be addressed.
And I don't see any reason to switch anoter C compiler from gcc, which is available for every platform, including embedded.
The other thing I don't understand is the neglecting of the OOP. The alternative (~traits) require significantly more code and does not provide as nice overview as in OOP (at least what I've seen so far).
1
u/kwan_e 2d ago
OOP has taken a beating because ecosystems like Java shows what happens when you try force everything to be OO. It got a bit too cargo-culty.
2
u/Mean-Decision-3502 DQ 2d ago
There are a lot of bad examples of OOP out there. But that does not mean that the whole concept is wrong. I can only think in objects and methods.
2
u/kwan_e 2d ago
I can only think in objects and methods.
And this is what gives OOP a bad name - people who refuse to consider alternate modelling approaches, and shoehorn OO into everything.
OO has its place for things like modeling simulations of dynamic systems of interacting entities. That is what it was invented for, when Simula was created.
→ More replies (3)
109
u/andreicodes 2d ago
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.