Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Interesting! Let’s start this debate!

I love C, when I wrote my first programs in it as a teenager, I loved the simplicity, I love procedural code. Large languages like C++ and or Rust are just too much for ME. Too much package. I like writing code in a simple way, if I can do that with a small amount of tools, I will. You can learn C and be efficient in it within a couple weeks. C systems are just built better, faster, more stable, portable, and more! This is my 2 cents.



It is a complex matter. But it narrows down to one thing: the number of real-life alternative compilers, which is in direct relation to this benchmark: can a small team of average devs, or an individual average dev, develop with reasonable effort and time and near 0 technical dependence, a real-life alternative of a compiler. It is a protection of developer/vendor lock-in, in the SDK realm.

Most honnest software developers know the answer: for any computer language with an ultra-complex syntax(c++,etc) or which requires an intrusive and tricky runtime (java,etc), the answer is obvsiously "nope". But we all know, for plain and simple C, the answer is "yes" (have a look at cproc and QBE, or scc, tinycc, etc). The new C I am talking about should reduce the effort related to such compiler developement and "fix" all C implicit stuff hiding too much things, kind of error prone.

There is a huge pitfall though: linux is not coded in plain and simple C, but in GCC C... which is VERY different, a GCC C alternative, is clancg/llvm, those are not to be called reasonable in any capacity.

If linux code would care about having clean assembly source files on top of plain and simple C code, unfortunately it would be slower. BUT, you guess what, for the ability to compile linux with an _REAL ALTERNATIVE_ C compiler (and a small assembler), I will happily accept to have a "slower" kernel.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: