This is apparently a language designed in 2004. In 2004, I'm pretty sure most of the world knew that manual memory management and zero-terminated strings are foot guns and sources of bugs. The sockets and HTTP server samples showcase this language has both of those features, the code is very C-like. Is this niche language any useful 20 years later?
The website seems to be unavailable. I don't know if the language is any good.
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.
The main safety issue really is with dealing with string management. We started working on a more full-featured String class for eC, but never quite managed to perfect it to the point where it could replace all use cases for traditional C string manipulations... Still hoping to get there!
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.
I don’t understand this paragraph. How does it do reference counting if the developer needs to manually increment and decrement the counter? Does the language provide anything beyond automatically allocating an integer and initializing it to 1?
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++.
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 :)
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.
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++.
Hi everyone, Jerome here who designed eC 20 years ago.
Happy to see this momentary spike of interest in eC :)
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.
I looked a bit deeper into your website and I am impressed with the amount of work that has gone into this language and its tools. I agree with the other commenters that eC seems like a pragmatic and ergonomic extension to the C language. It solves many of the problems that I find annoying about C: removing header files, adding access control through modules, a reasonable object system.
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.
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.
What C-like but supposedly better languages are worth trying out, for small but real world apps, to start with? I have a long, though sometime prior, C background, had done a lot of real world work with it, and would like to try out one or more of these newer C-likes.
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.
Yes, I thought of mentioning Nim in this category, but did not, because although I have looked at it a bit, I am not sure how C-like it is considered to be,
29 comments
[ 2.8 ms ] story [ 81.1 ms ] threadThere 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.
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).
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 :)
Also having to type @ [ ] all the time isn't appealing.
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++-...
[2] https://cor3ntin.github.io/posts/c/
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.
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.
It's uneasy to spot declarations:
Semicolons are sometimes required, sometimes not: I despise the use of <...> as a type of parentheses, as if the < and > symbols were not enough overloaded.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++.
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.