Is there a list/comparison of C-Alternative systems programming languages available ?
harec uses https://c9x.me/compile/
Their two-layer design with Red/System (IIRC) and Red, was interesting too.
Odin - https://odin-lang.org/
Zig - https://ziglang.org/
Beef - https://www.beeflang.org/
Jai (not public yet) - [1]
Carbon (C++) - https://github.com/carbon-language/carbon-lang
D Lang - https://dlang.org/
Rust - https://www.rust-lang.org/
cppfront (Herb Sutter's C++ frontend/syntax) - https://github.com/hsutter/cppfront
Nim - https://nim-lang.org/
Crystal (not sure if this counts) - https://crystal-lang.org/
Vale - https://vale.dev/
Hylo (formerly Val, just found it now) - https://www.hylo-lang.org/
Vala (compiles to C, some GTK apps are written in this) - https://vala.dev/
C3 - https://github.com/c3lang/c3c
Rune (last commit 7 months ago) - https://github.com/google/rune
Kit (dead, last commit 5 years ago) - https://github.com/kitlang/kit
There's probably more. That's all I can recall off the top of my head and/or what I have in my notes.
There's also Haskell [2], which compiles down to C-- [3] (a C like language). Not sure if this counts either.
[1]: https://en.wikipedia.org/wiki/Jonathan_Blow#2017%E2%80%93pre...
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
And Meta is pretty clearly committed to Rust at this point.
I agree about the MVP stuff; in contrast to things like Zig, Jai is the completely opposite, it's being built behind closed doors with little to no community feedback, with the creator and inner circle have say in the direction.
I'm not sure how well it will pan out. Seems like, from the outside, Blow is scratching his own itch and maybe it's possible Jai will never take off. The only real world similar example is Elm, which while open source, is/(was?) also heavily design behind closed doors in many ways, albeit not to the degree to which Jai is.
There's also Mojo, the Python-like language. It's also being built behind closed doors, but it seems to have a lot of hype behind it already.
Chandler Carruth is on the record stating it doesn't matter if it eventually dies, it is an experiement, where they hope to learn something out of it.
For some strange reason people keep giving more value to Carbon, than its own design team.
Nim and D also I think are not particularly C-like unless you use some custom compiler settings.
And Haskell belongs nowhere near this list. Or is Gambit Scheme also "C-like"?
Again, not saying your list is not a good capsule of C and C++ ‘strata’ languages (with one very notable exception), but people looking for C alternatives in 2024 are (most likely) explicitly ignoring complex languages like C++.
About that exception, Haskell may compile to C, using an ill-maintained and not up to date, part of GHC, but it is still Haskell and so compiles to C program source with GC included via header. The Haskell source code does not offer the bit-banging, memory manipulating abilities of C (in any way an imperative language programmer would recognize) and is practically devoid of memory management capabilities to assist in achieving C level performance requirements.
While it is a common trope on the internet that C and C++ are totally different and nobody that prefers C over C++ would like the more "complex" languages that are "C++ replacements, not C replacements," in the real world, it's not that clear-cut. I happen to work with a bunch of people who used to be C folks, never really liked C++, but now happily write Rust instead of C.
What any "x replacement" needs to be accurate is to define what "x" actually means to you. C means different things to different people! And that's okay.
(That said I agree with you that Haskell, at least, is quite the stretch.)
However, in a topic about Odin, Hare, or Go, I think the comment was germane. These languages value simplicity as a stated goal, and whatever one thinks of the position of C on the simplicity scale, I’d like to think that it is a valid consideration in language comparisons.
I will certainly acknowledge a subjective basis for defining and assessing ‘simplicity’ in PL design, but I can not put a language as complex as Rust in a bucket with C, Odin, Go, or Hare. The syntax, semantics, and implementation issues associated with ad-hoc polymorphism alone take it into another strata.
I am obviously aware of who I’m talking to and that you would certainly be the person who would know plenary of dev’s from any number of backgrounds happy to have replaced C with Rust. So I’m not trying to imply or say that it doesn’t happen. But there is a difference in working in Rust (happily, preferably, or otherwise) vs C, and in compiling a list of language similar to C. I took the question to hinge on similarity (in at least the complexity characteristic, if not the syntax or type characteristics), while I think you looked at it as a question about valid or preferable replacements for development.
Finally, I’m sure it was personal preference and philosophy that led me to assume complexity characteristics were inherently at issue in the GP post’s request for a list. You were certainly correct to point out it is a pretty narrow POV.
Simplicity is really an "eye of the beholder" situation. In particular often (implicitly) implementation simplicity is meant, a lot of what was simple about C, especially K&R C and to an extent C89, is because a PDP-11 isn't very powerful. But while that simplicity is valuable to the compiler author (in the case of Odin, Ginger Bill) it doesn't have much value to users. Delivering simplicity in use through regularisation is expensive for the implementer.
For usage I worry that C-style simplicity comes in the form of just declining to explain the tricky corner cases. That is, I worry that if we documented all these cases properly, suddenly the "simpler" lowl level languages might look fiendishly complicated after all. Certainly I'm not confident that C was "really" simpler than Rust in many regards.
Odin is fundamentally about simple as-in _intuitive_ to use, and intuition are anything but simple as-in _simplex_. Intuitions are extremely complex and complicated things, even if they seem "easy" to use.
Designing for people's intuitions about what feels right and feels "intuitive", is a lot more complicated than you realize. The entire constant value system requires a big-number implementation to get right.
Looking at the compiler for more than 10 minutes would you should that it is anything but trivial (I will refrain from using the term simple here since it is overloaded). Odin is more complicated than C, but less complicated than C++. That is both in terms of the language and the compiler itself. You can write a C compiler is <8KLOC (in C). It would probably take <50KLOC to write a _minimal_ Odin compiler (in C), if not more.
Which falsehood? That K&R C was written to fit on the PDP-11 and its limitations reflect that? I think that's well attested.
It may very well be that Odin fits your intuitions, it certainly doesn't fit mine. Take your "range based for loop" - it does something for a handful of built-in types. What it does is presumably whatever your intuition said it should do, and then for custom types it just doesn't work at all. I'm sure that in your mind this is simple, "It just does what you expect". But to my mind it's extremely complicated - it does these different specific things I'd need to remember, and in any other cases it's just not legal Odin at all.
> The entire constant value system requires a big-number implementation to get right.
Unless "big-number" is rather over-stating what was needed here I don't get this.
It has a very pragmatic design.
Additionally: Hare stated Win and Mac will be unsupported. Jai is still closed source.