3 ms·

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 fo

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

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