How about performance? As I understand, it uses fat pointers fat pointers and GC, so performance drop is expected. There are not many reasons to use C nowadays beside performance.
> There are not many reasons to use C nowadays beside performance.
portability? stable ABI? ... writing something in C make it easy for any other higher level language to link to it. That's why we're not done with C, at all ... it's basically the only serious language out there used to share code among every possible platform or language. Even C++ which is a bit safer in practice is harder to link.
I just wished C was a bit safer by default (arrays with bound checking,...)
> Even C++ which is a bit safer in practice is harder to link.
Not to go down the C++ evangelist route, but if you want to write libraries in C++ to use with other high level languages, you can wrap the headers in extern "C", and still write C++ as normal in your own code.
…unless your library exposes classes/templates, which is probably what the majority of C++ libraries do (e.g., wxWidgets, Qt, Boost, etc.). In this case, creating C bindings is a real pain.
There are many languages with excellent C ABI compatibility with nearly the same portability, as well as some languages that compile down to C, while offering more safety and productivity.
So aside from performance and legacy codebases, there's no huge incentive to start a project in C these days. I think those who do it, do it in spite of the alternatives out there.
portability? stable ABI? ... writing something in C make it easy for any other higher level language to link to it. That's why we're not done with C, at all ... it's basically the only serious language out there used to share code among every possible platform or language. Even C++ which is a bit safer in practice is harder to link.
I just wished C was a bit safer by default (arrays with bound checking,...)