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

Fine, but there's no reason you should be allowed to ship C in devices which have safety critical consequences to the public, including unnecessary risk of data security breaches through allowing buffer overruns. You can write in a nice safe sandbox over there.

(maybe this will eventually be part of the UL/CE requirements, "contains no C code")



C and C++ have another brand of safety "safe" languages du jour don't have: it's an ISO standard. Granted, it's not a very good standard, but the upside is that everyone and their dog has a C compiler for every new architecture, and I bet C++ too. You are not, strictly speaking, beholden to any single compiler implementation out there, they all have their idiosyncrasies, but C won't disappear overnight.

It's more even than having a single foundation oversee it. C and C++ are largely immune to, say, a foundation dissolving because one day it turns out its members cannot comport themselves as responsible adults and a big enough drama ensues. The fact that C and C++ have no singular "community" to speak of is a very strong side.

So when there are at least two (or better three) fully independent implementations of your C alternative, we'll talk about gatekeeping C.

Now, if you are a vendor and capital owner, nothing forbids you from forbidding C within your company and devices you produce. That has been your prerogative since forever, predicated on your ability to afford it. I'm more wound up about activists and evangelists trying to impose their hobby horse upon others. You do you. Show, don't tell.




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

Search: