4 ms·

The eC Programming Language

60 points by thefilmore 3y ago

Kwpolska 3y ago
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?
- wazbug 3y ago
  From the website: "eC is a superset of C and its ABI is fully compatible with C."
- dwheeler 3y ago
  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.
  - jerstlouis3 3y ago
    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!
- temporarely 3y ago
  From the OP: 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.
  - Kwpolska 3y ago
    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?
    - temporarely 3y ago
      tbh self-censored a couple of snarky comments regarding the same. I had trouble parsing it as well.
    - jerstlouis3 3y ago
      I realize this is not super clear, and in fact we have an open issue to improve on where reference counting are done automatically. 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).
fl0ki 3y ago
I'll just put this over here with the rest of the C supersets.
- 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.
bhoaglund 3y ago
[dead]
IshKebab 3y ago
Nice hobby language but there doesn't seem to be any reason to use this.
pgraf 3y ago
Seems to be hugged to death. https://archive.is/xixuj https://archive.is/xixuj
dgan 3y ago
I ve read the overview, and actually seems like a boring (in a "OK" sense), decent language with sensible behaviour. No bells no whistles Speculation: it's the c++ we needed, not the one we had Reading other comments, looks like it's rather dead than alive
- jerstlouis3 3y ago
  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. Cheers!
  - bxparks 3y ago
    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.
williamDafoe 3y ago
First commit in the bug system was in 2008. https://www.ec-lang.org/mantis/view.php?id=1 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.
teo_zero 3y ago
I know many will disagree, but I feel that all the worst syntax mistakes from C/C++ are there. It's uneasy to spot declarations: Point p {1,2} // declaration Point {1,2} // expression Semicolons are sometimes required, sometimes not: class C { ... } struct S { ... }; 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.
- jerstlouis3 3y ago
  < > are used for template arguments, just as in the familiar C++ syntax. Not a big fan of the syntax myself, but that seemed like the right decision at the time :) Similar reason for ::, inspired from C++.
fuzztester 3y ago
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. Any others that anyone would recommend?
- armchairhacker 3y ago
  Idk how “C-like” it is vs “Swift-like” or just being another general-purpose language, but: Nim.
  - fuzztester 3y ago
    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, But thanks.

60 points by thefilmore 3y ago

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?

wazbug 3y ago
From the website: "eC is a superset of C and its ABI is fully compatible with C."
dwheeler 3y ago
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.
- jerstlouis3 3y ago
  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!
temporarely 3y ago
From the OP: 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.
- Kwpolska 3y ago
  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?
  - temporarely 3y ago
    tbh self-censored a couple of snarky comments regarding the same. I had trouble parsing it as well.
  - jerstlouis3 3y ago
    I realize this is not super clear, and in fact we have an open issue to improve on where reference counting are done automatically. 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).

fl0ki 3y ago

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

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.

bhoaglund 3y ago

[dead]

IshKebab 3y ago

Nice hobby language but there doesn't seem to be any reason to use this.

pgraf 3y ago

Seems to be hugged to death. https://archive.is/xixuj https://archive.is/xixuj

dgan 3y ago

I ve read the overview, and actually seems like a boring (in a "OK" sense), decent language with sensible behaviour. No bells no whistles Speculation: it's the c++ we needed, not the one we had Reading other comments, looks like it's rather dead than alive

jerstlouis3 3y ago
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. Cheers!
- bxparks 3y ago
  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.

williamDafoe 3y ago

First commit in the bug system was in 2008. https://www.ec-lang.org/mantis/view.php?id=1 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.

teo_zero 3y ago

I know many will disagree, but I feel that all the worst syntax mistakes from C/C++ are there. It's uneasy to spot declarations: Point p {1,2} // declaration Point {1,2} // expression Semicolons are sometimes required, sometimes not: class C { ... } struct S { ... }; 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.

jerstlouis3 3y ago
< > are used for template arguments, just as in the familiar C++ syntax. Not a big fan of the syntax myself, but that seemed like the right decision at the time :) Similar reason for ::, inspired from C++.

fuzztester 3y ago

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. Any others that anyone would recommend?

armchairhacker 3y ago
Idk how “C-like” it is vs “Swift-like” or just being another general-purpose language, but: Nim.
- fuzztester 3y ago
  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, But thanks.