4 ms·

I'll just put this over here with the rest of the C supersets.

by fl0ki 3y ago

bxparks 3y ago
That's a bit harsh, but I understand your sentiment. I wish that one of the numerous supersets of C would gain some traction, for those cases where C must be used. I'm thinking of cases such as bare-metal embedded, operating systems, and low-powered microcomputers. There seems to be no option right now that hits a sweet spot between the creaky old C and the unbearably complex C++.
- jimbob45 3y ago
  This should have been the one but it’s ultra dead. I feel like they made the right decisions in all the cases C++ didn’t.
  - jinwoo68 3y ago
    Their GitHub repo seems still active though: https://github.com/ecere/ecere-sdk/ https://github.com/ecere/ecere-sdk/
  - jerstlouis3 3y ago
    Very much alive, just not gaining traction. The slowdown in development is mostly because eC works relatively well and the efforts of our small development team are spent mostly using it rather than improving it :)
- keybored 3y ago
  Fragmentation is good IMO. That gives more oxygen to the low-level innovators.
- pjmlp 3y ago
  There is Objective-C, but it was never really usable outside NeXT and Apple ecosystems. Also having to type @ [ ] all the time isn't appealing.
- fl0ki 3y ago
  My problem is that if you're an actual C superset, you're carrying a lot of baggage that will permanently compromise the best case of what you can ever become. These days, with C standards back on a regular cadence, the thing you have to be a superset of is also a moving target, and you have to make sure your extensions don't end up incompatible with future C changes. If you succeed enough, the C standard has to be worried about compatibility with you in return. Even the most conservative C supersets like non-standard GNU C have created friction for what the actual ISO standard can do in future, including the highly demanded addition of nested functions [1]. One could almost argue that the long-term value of that C superset will be net-negative precisely because it was successful enough to become a permanent interoperability hazard for C itself. (They could have avoided that by not claiming to be C at build time, but that would have also avoided anyone ever using it, just like almost all of the other supersets). C++ isn't even a C superset and still that relationship creates friction both ways [2]. Now if you're not a C superset, you have a more difficult adoption story and that is enough to kill a language before it ever has a chance. Even so, far more languages have succeeded by tackling interoperability problems than by being supersets. Rust has a fair amount of friction binding to C, but people see enough value in overcoming that; and part of what people claim to love about Zig is that it has much less friction, right down to the build tooling. It's looking like interoperability is increasingly winning over creating supersets. Related: In the "C++ successor language" space race, almost every candidate is trying to be low-friction to interoperate without being a superset, because in C++'s case there's even more baggage to want to avoid. [1] https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please#nested-functions-are-an-abi-break https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-... [2] https://cor3ntin.github.io/posts/c/ https://cor3ntin.github.io/posts/c/
  - bxparks 3y ago
    I completely agree with your analysis. I think I meant "interop" instead of "superset" when craving for something better than C, but not as mind-numbing as C++.

I'll just put this over here with the rest of the C supersets.

by fl0ki 3y ago

I'll just put this over here with the rest of the C supersets.

That's a bit harsh, but I understand your sentiment. I wish that one of the numerous supersets of C would gain some traction, for those cases where C must be used. I'm thinking of cases such as bare-metal embedded, operating systems, and low-powered microcomputers. There seems to be no option right now that hits a sweet spot between the creaky old C and the unbearably complex C++.

jimbob45 3y ago
This should have been the one but it’s ultra dead. I feel like they made the right decisions in all the cases C++ didn’t.
- jinwoo68 3y ago
  Their GitHub repo seems still active though: https://github.com/ecere/ecere-sdk/ https://github.com/ecere/ecere-sdk/
- jerstlouis3 3y ago
  Very much alive, just not gaining traction. The slowdown in development is mostly because eC works relatively well and the efforts of our small development team are spent mostly using it rather than improving it :)
keybored 3y ago
Fragmentation is good IMO. That gives more oxygen to the low-level innovators.
pjmlp 3y ago
There is Objective-C, but it was never really usable outside NeXT and Apple ecosystems. Also having to type @ [ ] all the time isn't appealing.
fl0ki 3y ago
My problem is that if you're an actual C superset, you're carrying a lot of baggage that will permanently compromise the best case of what you can ever become. These days, with C standards back on a regular cadence, the thing you have to be a superset of is also a moving target, and you have to make sure your extensions don't end up incompatible with future C changes. If you succeed enough, the C standard has to be worried about compatibility with you in return. Even the most conservative C supersets like non-standard GNU C have created friction for what the actual ISO standard can do in future, including the highly demanded addition of nested functions [1]. One could almost argue that the long-term value of that C superset will be net-negative precisely because it was successful enough to become a permanent interoperability hazard for C itself. (They could have avoided that by not claiming to be C at build time, but that would have also avoided anyone ever using it, just like almost all of the other supersets). C++ isn't even a C superset and still that relationship creates friction both ways [2]. Now if you're not a C superset, you have a more difficult adoption story and that is enough to kill a language before it ever has a chance. Even so, far more languages have succeeded by tackling interoperability problems than by being supersets. Rust has a fair amount of friction binding to C, but people see enough value in overcoming that; and part of what people claim to love about Zig is that it has much less friction, right down to the build tooling. It's looking like interoperability is increasingly winning over creating supersets. Related: In the "C++ successor language" space race, almost every candidate is trying to be low-friction to interoperate without being a superset, because in C++'s case there's even more baggage to want to avoid. [1] https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please#nested-functions-are-an-abi-break https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-... [2] https://cor3ntin.github.io/posts/c/ https://cor3ntin.github.io/posts/c/
- bxparks 3y ago
  I completely agree with your analysis. I think I meant "interop" instead of "superset" when craving for something better than C, but not as mind-numbing as C++.