C is considered harmful. They should rewrite it in Rust.
> They should rewrite it in Rust. Why they? You should do it.
indeed
C Is Best (2025)
521–530 of 574 posts
Re: C Is Best (2025)
#522Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP. If they are getting good results with C and without OOP, and people like the product, then those from outside the project should…
>justify their choice not to use Rust (or Zig)
It's disingenuous to lump them together. It is the former that does the whole toxic, pushy advocacy routine.
Re: C Is Best (2025)
#523> Rust needs a mechanism to recover gracefully from OOM errors. Linus also brought this up: https://lkml.org/lkml/2021/4/14/1099
Off topic: This CSS improves the usability of that page: ul.threadlist li:hover > a { color: red; } ul.threadlist li.origin > a { display: block; background: rgb(205, 216, 216); font-weight: normal; padding: 1px 6px; margin: 1px -6px; }
Should be:
ul.threadlist li.origin a {
display: block;
background: rgb(205, 216, 216);
font-weight: normal;
padding: 1px 6px;
margin: 1px -6px;
}Re: C Is Best (2025)
#524Earlier quoted context omitted.
Just like C libraries are a bad fit for embedded, no difference there, although C++ haters pretend otherwise, even though half of libc is unusable in freestanding. It takes skill to make use of Arduino, ESP32, and other C++ embedded libraries, being able to write custom C++ libraries, master compiler switches and linker maps.
C libraries are excellent for embedded! You can write libraries like SQLite, that can run on bare metal and only require a few external functions from the platform, while still being valid C library! You cannot make it in C++, because any valid C++ library imposes massive requirements on the environment I already mentioned. C does no such thing!
Some people have the skills to make C++ work on a GBA, https://github.com/GValiente/butano
Arduino, https://docs.arduino.cc/arduino-cloud/guides/arduino-c/
Or even ESP32, https://docs.espressif.com/projects/esp-idf/en/stable/esp32/...
Others do not.
As for C does not such thing, strangly there are enough examples from TI, Microchip, Atmel that prove otherwise.
Re: C Is Best (2025)
#525Earlier quoted context omitted.
> While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process. I…
> With developments such as the Ferrocene-qualified compiler, Rust can now meet all the analysis requirements under DO-178C, one of the most stringent safety-critical standards worldwide.
“Can meet” vs “has met” is the entire difference.
Clearly C “can meet” and “has met” DO-178. So, I posit that more languages than C “can meet” this standard.
Proving it is the very hard, very expensive part.
Oh, and whatever version of the rust compiler that gets certified will be locked down as the only certified toolchain. No more compiler updates every 6 weeks. Unless you go though the whole process again.
Re: C Is Best (2025)
#526Earlier quoted context omitted.
> While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process. I…
https://ferrocene.dev/ DO-178C isn’t there yet, but I believe I heard that it’s coming. In general, Ferrous Systems works with customer demand, which has been more automotive to start.
I believe is may come, that would be really neat.
Actually having it happen, someone is going to be out 10-30 million bucks. And again for each new compiler version.
Re: C Is Best (2025)
#527Earlier quoted context omitted.
> It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics? I've only seen it done for C++ that is more C than C++, or for libraries that were designed to "bail out" to a C interface.
> Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics? If the interface itself has or leaks those features, no that's not easy indeed. But if those do not leak, then they can be used internally yes. My point was not that it's easy to wrap a currently existing C++ library that has modern features in its interface in a C interface, especially post-C++11.…
Then the statement "Stuff can't interoperate with c++" is true. Nothing from c++ ever gets exposed. You have to explicitly write a C interface yourself, or avoid using c++ features (write C in c++) so everything looks like C in the first place and all you need is #ifdef __cplusplus extern "C" #endif. But then you're not writing c++ either.
Re: C Is Best (2025)
#528I've started using SQLite years ago for its use of a single file to store data. Along the way, I found more reasons to like it. Today, I discovered a new reason when I read this article.
I also noticed many software companies have been switching to SQLite for storing data. Audacity has switched from using hundreds of tiny audio files in multiple folders for a single recording to a single file using SQLite. I suspect it is the reliability that comes from sticking to C
Re: C Is Best (2025)
#529Earlier quoted context omitted.
I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. I work for a robotics company (and have for many years), and having the flexibility to use Pion WebRTC (in Go) or PCL (in C++) or PyTorch (in Python) outweighs the cost of having software written in multiple languages.
> I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. This claim does not pass the smell test. Tech sprawl is a widely recognized problem, and dumping codebases each 2-3 years is outright unthinkable and pure madness. It doesn't even come across as resume-driven development because 3 years is not nearly enough to ge…
Your world seems small -- I never said anything about dumping codebases. If i have a library implemented in Rust, which gets called by a program written in C++ through FFI, and contacts a service which is implemented in python, I don't need to dump or waste any old work. A carpenter that only uses a hammer isn't a very good carpenter; different tools have different strengths and weaknesses.
Re: C Is Best (2025)
#530Earlier quoted context omitted.
I am talking about C syntax, not absurdely grotesque ultra-complex syntax like the ones from c++, java and similar (is that true that rust syntax is not that much less worse than c++ one now?). We need a new C, fixed, leaner and less complex: primitives are all sized (u64, u8, f64, etc), only one loop primitive (loop{}), no switch, no enum, no typedef, no typeof and other c11 _generic/etc, no integer promotion, no im…
>>primitives are all sized (u64, u8, f64, etc) stdint.h already gives you that. >> only one loop primitive (loop{}), no switch, no enum I don't think you will find many fans of that. >> atomics check stdatomic.h >>some bitwise operations (like popcnt) Check stdbit.h in C23
[dead]