> 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.
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.)