The eC Programming Language
ec-lang.org
ec-lang.org
Speculation: it's the c++ we needed, not the one we had
Reading other comments, looks like it's rather dead than alive
eC is still very much alive, but it never gained much traction, as few languages without a major backer do. Our latest efforts over the last decade have been more about using eC rather than trying to make it gain popularity, as well as working on geospatial Open Standards.
Just wanted to point out that the project and language (and the related FOSS Cross-Platform Ecere SDK) are alive and well, and I do hope to find time or resources to address some of the issues pointed out in this thread.
Cheers!
I'd been looking for a language like this for maybe 10-15 years, but I had never heard of eC until now. I know about Zig, D, Nim, Odin, C2, C3, and a bunch of other obscure languages aimed at C-like use cases, but not eC. I'm not sure how it can get more traction.
I know of Zig, Odin and Hare in this category. Saw a video about Hare very recently.
Zig and Odin have been discussed on HN multiple times in the past, and Zig often still is. Maybe Hare too, didn't check yet.
I've also played around with D a fair amount earlier.
Any others that anyone would recommend?
But thanks.
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++-...
Also having to type @ [ ] all the time isn't appealing.
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 :)
It's uneasy to spot declarations:
Point p {1,2} // declaration
Point {1,2} // expression
class C { ... }
struct S { ... };
And finally, probably it's my problem, I really really hate the :: symbol.
Not a big fan of the syntax myself, but that seemed like the right decision at the time :)
Similar reason for ::, inspired from C++.
https://www.ec-lang.org/mantis/view.php?id=1
To be ready for prime time an enhanced C language should be able to compile and run the Linux kernel correctly. Now that rust is being added to the Linux kernel this gets a lot harder, it must also port rust or compile rust.
Memory Management
eC already takes care of many aspects of memory management through reference counting. However, it does not automatically manage [memory] allocated with the new operator, which must be manually freed with the delete operator. Furthermore, to avoid the overhead and recognizing the limits of reference counting, reference count increments and decrements is left to the user, except for the initial construction (at instantiation) and destruction of the object (when it goes out of scope). At the moment this automatic behavior is also limited to global and member instances, other instances currently start with a 0 reference count and must be manually destroyed with delete.
[edited]
This is definitely a weak point in the language.
At the moment, only global and member instances get automatically incremented/decremented.
There is a plan to extend that to local instances as well.
But also `delete object` will automatically decref and delete if reaching 0.
In practice, this all saves a lot of manual allocation/deallocation efforts compared to plain C, but it's all fairly low level (which was by design).
There is definitely value in a language that is easy to move to from C (and C++) that is memory-safe and performant. Most vulnerabilities involve memory safety today (the top 3 CWE categories of exploited vulnerabilities are memory safety). Rust is a good language, but no one has the trillions of dollars necessary to rewrite everything currently in C and C++ into Rust. Some programs can be rewritten in other languages where performance is less important, but that is not always true. That said, something may be desirable, but it may not be doable.