I like what Hare sets out to do, and I like how it is going so far. But in terms of a C alternative it doesn’t really fit the bill. Hare is explicitly not supported on anything but open source platforms and that is a big divergence from C in 2023. I do not doubt there will be a Windows compiler at some point, but the language’s goals are never going to mesh with a large chunk of C usecases.
This is an odd list when responding to a ‘C-alternative’ question. I’m not saying the list is bad or outrageous, just that the parent uses ‘C’ and in a topic about a language like Odin I would expect for a response list to not include C++ and it’s competitors.
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.
> I would expect for a response list to not include C++ and it’s competitors.
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.)
While I don’t disagree with your point in general, and if this was an article about Rust, D, or maybe even Zig, I may have left off the part about C-esque vs C++-esque languages.
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.
Yep! Great comment. I certainly agree that if someone was looking for a language that does "simplicity" as an ideological thing, grouping stuff together that way would absolutely make sense. I suspect, in the same way that you reach for that comparison initially, I also do not, because I don't particularly enjoy that framing of programming languages. We truly are all the products of our own experience and biases.
I'm one of the type of people Steve was describing, albeit not someone Steve knows - people who "used to be C folks, never really liked C++, but now happily write Rust instead of C".
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's official compiler is not a "simple implementation", and Odin was not designed to be trivial to implement either. Where did you get this falsehood from? None of what you said is correct.
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.
That’s basically what the sibling comment was saying, i.e. I was the one being overly narrow in my interpretation of your question. And in light of that and your clarification, the list is more than accurate to cover nearly all the common options.
Maybe, but it’s always fun to get to be hyper specific and quibble about things, so I can at least thank you for providing something for me to comment on this evening. Seriously, like I said in my reply to a sibling comment, I was being picky about my personal preferences and interpretation of the parent question.
Nim is particularly C-like. The automatic memory management is optional and exposes destructors, it exposes pointers and is quite usable on embedded systems (see: Futhark, Ratel), there are a wide variety of design decisions made to ease interop with C... I do not know about D.
Carbon is really exhibit A of why MVPs exist. Jai and Cppfront have the same problem but Blow and Sutter probably don’t care if they never gain much traction. Conversely, Carbon is Google-backed (IIRC) and will soon die if it can’t justify its continued existence.
I can't comment on Herb Sutter. But Jonathan Blow, from what I've seen and heard, is deeply passionate about the domain Jai is targeting and appears to have Jai already in pre-production use in his next in-development game/engine.
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.
Carbon was started by Chandler Carruth, at Google, but they wanted to move it to broader governance quickly. It's not under the Google GitHub today, but its own org.
If you aren’t looking for languages that have more fancy memory management things (ref counting, borrowing or similar) then the active ones I know of are in alphabetical order:
C3, Hare, Jai (might be slightly more of a C++ alternative), Odin and Zig.
Additionally: Hare stated Win and Mac will be unsupported. Jai is still closed source.
