The C programming language is even today among the most popular languages in usage despite having been released all the way back in 1972, and having quite a number of limitations and flaws by today\u2019s standards.<\/p>\n\n\n\n This is the key reason why C ought to be replaced. Too much critical software is written in C\/C++ which has wide ranging implications. One example is bugs in libraries such as OpenSSL. C is notoriously bad at catching problems such as buffer overruns. C is a language allowing you to shoot yourself in the foot in too may ways.<\/p>\n\n\n\n This may sound strange coming from someone who is an avid fan of dynamic languages. However the issue here is type safety. Dynamic languages such as Python and Julia typically catch wrong usage of types. Such as using an integer in an if-statement. Dynamic languages may not catch problems at compilation time but if they have a strong type system, a lot of problems will be caught at runtime. That matters especially with security. Security vulnerabilities is in large part down to causing undefined behavior, rather than a controlled shutdown.<\/p>\n\n\n\n But if C is so bad, why has it not been replaced already? There are many reasons for that. In part it already has been replaced. Java, C#, C++ and many other languages already have taken over tasks previously done in C.<\/p>\n\n\n\n So this is really more about the kind of software which is left, where C still dominates:<\/p>\n\n\n\n Why is C still dominating these areas? Because the alternatives until recently have not been very good. A lot of languages in the 90s such as Java, C#, VB.NET and F# seemed to have been focused primarily on creating garbage collected managed languages. Not a great solution for the examples listed above.<\/p>\n\n\n\n Then you have other languages popping up in the 80s and 90s such as Perl, Python, Ruby, JavaScript, none of them suitable either for these tasks.<\/p>\n\n\n\n Sure there has always been other statically typed languages such as Ada, Modula-2 etc. However these generally did not try to cater to people\u2019s existing skillset, or could be used easily with existing C libraries.<\/p>\n\n\n\n There has been languages such as D, but it has C++ level complexity which is probably not appealing to C developers. It also has initially required garbage collection which likely makes it unsuitable for many of the areas mentioned. You don\u2019t want a garbage collector to kick in while you are trying to maintain a frame rate.<\/p>\n\n\n\n I think one of the first real signs that there is an appetite for a modern incarnation of C and C++ is the rising popularity of Go and Rust. We see a lot of typical tools that was commonly written in C or C++ in the past now being written in Go or Rust. A plethora of command line tools e.g. are popping up, which have been written in either of these langauges. I cover some of these tools here<\/a>. You see people attempt to write game engines in Rust.<\/p>\n\n\n\n A big part of the possibilities of providing an alternative to C I believe exists today due to the maturity of LLVM. LLVM means a of the really complicated stuff of generating high performance code and targeting many platforms is solved. It makes language development accessible to a lot more people.<\/p>\n\n\n\n Both Go and Rust gave some inspiration to how C\/C++ could be rethought and armed with this inspiration and LLVM, a little cottage industry of possible C replacements are popping up:<\/p>\n\n\n\n To replace C, a language will typically need to be suitable for the niches that C still dominate. Not all types of languages are suited for this. So the languages I have listed have a number of features in common which make the suitable to replace C:<\/p>\n\n\n\n Let us expand on the last point. Nobody is even going to bother starting to replace the existing C infrastructure if it means you need to rewrite the whole program from scratch in one go. One thing that in my experience made it easy to transition from Objective-C to Swift was that I could in fact rewrite one single method at a time, recompile and test the program.<\/p>\n\n\n\n With languages such as Zig you can quite easily do that.<\/p>\n\n\n\n There are many reasons why we should replace C, and the primary reason it has not been done before is that the focus has been elsewhere and the tools have been lacking. This is not the kind of thing one large organization necessarily decides to do. You need it to be easy for a little cottage industry of individuals to try there hand at it. With LLVM as a tool and Go as inspiration that is fully possible today.<\/p>\n\n\n\n Do I personally think C will be replaced? I am not holding my breath. This is a long process, and we don\u2019t have any clear winners yet. Large organizations are not going to jump onto Zig, Odin, V or whatever else comes along until a clear alternative has crystalized.<\/p>\n\n\n\n And what does replace even mean? Cobol is still running a lot of our financial transactions. Yet I think we can say that Cobol has been replaced in the sense that nobody today will deliberately choose Cobol for any new project. And wherever possible people will attempt to migrate away from it.<\/mark><\/p>\n\n\n\n Likewise a lot of well tested C code will not get rewritten. It will simply linger. But we may in the future reach a point where other languages are simply picked over C for the areas C has traditionally dominated.<\/p>\n","protected":false},"excerpt":{"rendered":" Do We Need a Replacement for C? I found this old draft that cites Zig programming language… time to undraft it… \ud83d\ude42 C is a widely used language used to program anything from OS kernels to cryptography libraries. Is it time for a replacement? Erik EngheimNov 25, 2020\u00b75 min read The C programming language is…<\/p>\n![\"Image](\"https:\/\/i0.wp.com\/miro.medium.com\/max\/1000\/1%2ALFLf7dpZNlfIxekysYSP1A.png?w=910&ssl=1\")
\n
ls<\/code> , cat<\/code> and git<\/code><\/li>\n<\/ul>\n\n\n\nGo and Rust Shows Possibilities<\/h1>\n\n\n\n
LLVM: The Missing Puzzle<\/h1>\n\n\n\n
\n
What is a C Replacement Language?<\/h1>\n\n\n\n
\n
Conclusion<\/h1>\n\n\n\n