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

I think the problem with "friendly C", "safe C++" proposals is they come from a place of "I want to continue using what I know in C/C++ but get some of the safety benefits. I'm willing to trade some of the safety benefits for familiarity". The problem is the friendly C/safe C++ that people picture from that is on a spectrum. On one end you have people that really just want to keep writing C++98 or C99 and see this as basically a way to keep the network effects of C/C++ by having other people write C who wouldn't. The other extreme are people who are willingly to significantly rework their codebases to this hypothetical safe C.

The people on one end of this spectrum actually wouldn't accept any of the changes to meaningfully move the needle, while the people on the other end have already moved or are moving to Rust.

Then in the middle you have a large group of people but not one that agrees on which points of compatibility they will give up for which points of safety. If someone just said "Ok, here's the standard variant, deal with it", they might adopt it... but they wouldn't be the ones invested enough to make it and the people who would make it have already moved to other languages.



Apologies for mentioning the same idea in multiple comments, but it seems relevant.

In my opinion, a good path forward is to add safety features to mainline C toolchains. An example is -fbounds-safety for clang/llvm

https://clang.llvm.org/docs/BoundsSafetyAdoptionGuide.html


History has already proven this with Objective-C and C++, also with TypeScript, while those languages provide stronger safety guarantees over plain old C and JavaScript, there are always those that will keep using the old tricks on the new system.

Only removing copy-paste compatibility fixes that.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: