241–250 of 475 posts
Earlier quoted context omitted.
I’d add that the Rust code and C code will probably have the same number of bugs. The C code will likely have some vulnerabilities on top of those. Rust doesn’t magically make the vast majority of bugs go away. Most of bugs are entirely portable!
This is objectively nonsense
I fully understand that sentiment. For several years now, I have also felt the strong urge to develop something in pure C. My main language is C++, but I have noticed over and over again that I really enjoy using the old C libraries - the interfaces are just so simple and basic, there is no fluff. When I develop methods in pure C, I always enjoy that I can concentrate 100% on algorithmic aspects instead of architectu…
Most of the embedded world is still C, if you want to write C that's probably the place to find a community.
Earlier quoted context omitted.
i never really understand why these get compared. i wouldn't expect that much overlap in the audiences zig seems like someone wanted something between C and "the good parts" of C++, with the generations of cruft scrubbed out rust seems like someone wanted a haskell-flavoured replacement for C++, and memory-safety i would expect "zig for C++" to look more like D or Carbon than rust. and i'd expect "rust for C" to have…
The single best feature (and I would say the _core_ feature separating it from C) that C++ has to offer is RAII and zig does not have that. So I don’t know which good parts of C++ they kept. Zig is more of its own thing, and they take from wherever they like, not just C++.
Not everyone likes RAII by itself. Allocating and deallocating things one at a time is not always efficient. That is not the only way to use RAII but it's the most prevalent way.
Earlier quoted context omitted.
Just FYI. Back in 1994/95, I wrote an API, in C, that was a communication interface. We had to use C, because it was the only language that had binary/link compatibility between compilers (the ones that we used). We designed what I call "false object pattern." It used a C struct to simulate a dynamic object, complete with function pointers (that could be replaced, in implementation), and that gave us a "sorta/kinda"…
Sure, that's a pretty common pattern in use in C to this day. It's a useful pattern, but it's still all manual. Forget to fill in a function pointer in a struct? Crash. At least with C++ it will fail to compile if you don't implement a method that you have to implement.
You don't have to think about exceptions, overloaded operators, copy constructors, move semantics etc.
I'm kinda in the opposite camp. After doing a bunch of VB in my tweens and teens, I learned Java, C, and C++ in college, settling on mostly C for personal and professional projects. I became a core developer of Xfce and worked on that for 5 years. Then I moved into backend development, where I was doing all Java, Scala, and Python. It was... dare I say... easy! Sure, these kinds of languages bring with them other pro…
That is very interesting. You have quite the resume too. While I've dabbled in nearly everything, I'm a day to day pro C# developer and I absolutely love it. I've never been upset or had a complaint. If I were forced off for some reason, I'd just go to Typescript. I can't imagine using C. Perhaps with some form of AI valgrind. The problems C solved are just not relevant any longer, and it remains entrenched in 2025.…
I realize a lot of people don't want to use it; and that's fine, don't use it.
Earlier quoted context omitted.
> Memory leaks, NULL pointer dereferences, use-after-free I suffered writing those for many years. I finally simply learned not to do them anymore. Sort of like there's a grain of sand on the bottom of my foot and the skin just sort of entombed it in a callous.
I've seen you make these kinds of comments before on other articles. Please stop. Not everyone is perfect and can forevermore avoid making any mistakes. I strongly suspect your opinion of your skill here is overinflated. Even if it isn't, and you really are that good, everyone cannot be in the top 0.00001% of all programmers out there, so your suggestion to "simply" learn not to make mistakes is useless. This all jus…
In this instance Walter is correct - the mistakes he listed are very rarely made by experienced C programmers, just as ballet dancers rarely trip over their own feet walking down a pavement.
The problem of those errors being commonplace in those that are barely five years in to C coding and still have another five to go before hitting the ten year mark still exists, of course.
But it's a fair point that given enough practice and pain those mistakes go away.
Earlier quoted context omitted.
Since it's underlining code you wrote, it must be "found" that is highlighted, not "expected". Much like up and down, gravity exists to ground all of us in the same direction.
I'm over here with TTS: Underlining in a terminal rarely translates to audio. It isn't the only consideration that needs to be made, when making things clear.
Earlier quoted context omitted.
I think Rust is harder to learn , but once you grok it, I don't think it's harder to use , or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`. Rust's normal error messages are delightfully helpful. For example, I just wrote some bad code and got: --> src/main.rs:45:34 | 45 | actions.append(&mut func(opt.selected)); | ---- ^^^^^^^^^^^^ expe…
> I think Rust is harder to learn, but once you grok it, I don't think it's harder to use, or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`. When I say Rust is harder to use (even after learning it decently well), what I mean is that it's still easier to write a pile of C code and get it to compile than it is to write a pile of Rust code…
As someone who is more familiar with Rust than C: only if you grok the C build system(s). For me, getting C to build at all (esp. if I want to split it up into multiple files or use any kind of external library) is much more difficult than doing the same in Rust.
So nobody would use code written in common lisp... but they will use code written in an entirely new language.... right...
This reads like a cautionary tale about getting nerdsniped, without a happy ending.
Yeah, I think every programmer experiences the "I should write a language" moment when the solution to the problem is abstracted to be the language itself.