It’s not “the segmentation fault thing”. It’s that C allows you to shoot yourself in the foot in many various ways, part of which will immediately show itself in the form of a segfault, part of which may show itself in the form of a segfault minutes, days, or years later depending on how the users use the software, and part of which will not show itself in the form of a segfault ever but make the program unstable in other ways.
Yeah, sure, you can say that it’s “a skill issue”, but maybe that’s not the attitude of the year if you want more contributors in the project, which is a useful goal if you don’t want it’s developer community to die out or otherwise disintegrate.
where people indirectly include 6,000 crates and
That’s why the maintainers shouldn’t allow anyone to just add any new dependencies without a proper consideration. I don’t think this is an unsolvable problem.
I admit to not knowing how running an open source project goes, but wanting more contributors seems like the wrong metric compared to better contributors.
I understand the pitfalls of C are not limited to segmentation faults, but I suspect it would be more productive to fix C by including some of Rust’s better ideas than to throw it away, as seems to be the current trend.
I don’t think Rust is wholly bad, to be clear, but it seems over-engineered to me, and the fact its useful new features don’t even completely work (see rust-cve) isn’t very encouraging.
I would recommend listening to Jonathan Blow’s opinion on Rust, which I tend to agree with. I personally think I’m just going to stick with C until Rust either becomes the standard, or I retire and let the next generation worry about that.
including some of Rust’s better ideas than to throw it away
The problem is that you can’t just tack Rust’s ideas onto an existing language. Generics, traits, lifetimes, borrowing, sum types, and match are key Rust features, but took considerable design time before Rust even reached 1.0. They interlock to produce a pleasant development experience. You can’t just attached them to C and call it a day.
I don’t think Rust is wholly bad, to be clear, but it seems over-engineered to me, and the fact its useful new features don’t even completely work (see rust-cve) isn’t very encouraging.
Most of the CVE’s listed there are in unsafe code in the standard library. At some point, some code is going to have to have to implement the tricky cases. In C, this code is common place, ready for any coder to run into problems. In Rust, these are bizarre edge cases that most people would never trigger.
I haven’t heard Jonathan Blow’s take yet, but one thing a person pointed out is that he tends to prefer a style that uses a lot of shared state. Rust explicitly discourages that style, considering it a source of bugs.
I encourage you to give Rust a try. It never hurts to have another language in your arsenal. Who knows, you might even find it fun.
I don’t have much experience in C, but I’m not sure if bringing Rust’s ideas over to C would help.
As I understand, a lot of problems come from either that arrays are actually just pointers and if you don’t enforce it’s length for yourself then no one will, and in practice they span the entire area of process memory dorwards and backwards too. Or from that you free memory at the wrong time, or you never do that at all.
You can’t make mistakes with the first thing in Rust because the compiler takes note of the array’s length, and you just can’t abuse it as it won’t compile then. The second is a nonissue too, as memory management is automatic (kind of).
Fixing C sounds to me like patching up a sieve. That language was designed with those features in mind that make it error prone, and changing them would result in a different language. You would have to change your program anyway, and that probably wouldn’t be a small renovation. Also, you often can’t afford to not use pointers, because that’s how you pass things by reference in C, and besides passing by reference being important for performance reasons (to avoid copies) that’s the only option if so you have is a pointer to something, and when it’s stored in the heap.
It’s not “the segmentation fault thing”. It’s that C allows you to shoot yourself in the foot in many various ways, part of which will immediately show itself in the form of a segfault, part of which may show itself in the form of a segfault minutes, days, or years later depending on how the users use the software, and part of which will not show itself in the form of a segfault ever but make the program unstable in other ways.
Yeah, sure, you can say that it’s “a skill issue”, but maybe that’s not the attitude of the year if you want more contributors in the project, which is a useful goal if you don’t want it’s developer community to die out or otherwise disintegrate.
That’s why the maintainers shouldn’t allow anyone to just add any new dependencies without a proper consideration. I don’t think this is an unsolvable problem.
I admit to not knowing how running an open source project goes, but wanting more contributors seems like the wrong metric compared to better contributors.
I understand the pitfalls of C are not limited to segmentation faults, but I suspect it would be more productive to fix C by including some of Rust’s better ideas than to throw it away, as seems to be the current trend.
I don’t think Rust is wholly bad, to be clear, but it seems over-engineered to me, and the fact its useful new features don’t even completely work (see rust-cve) isn’t very encouraging.
I would recommend listening to Jonathan Blow’s opinion on Rust, which I tend to agree with. I personally think I’m just going to stick with C until Rust either becomes the standard, or I retire and let the next generation worry about that.
The problem is that you can’t just tack Rust’s ideas onto an existing language. Generics, traits, lifetimes, borrowing, sum types, and match are key Rust features, but took considerable design time before Rust even reached 1.0. They interlock to produce a pleasant development experience. You can’t just attached them to C and call it a day.
Most of the CVE’s listed there are in unsafe code in the standard library. At some point, some code is going to have to have to implement the tricky cases. In C, this code is common place, ready for any coder to run into problems. In Rust, these are bizarre edge cases that most people would never trigger.
I haven’t heard Jonathan Blow’s take yet, but one thing a person pointed out is that he tends to prefer a style that uses a lot of shared state. Rust explicitly discourages that style, considering it a source of bugs.
I encourage you to give Rust a try. It never hurts to have another language in your arsenal. Who knows, you might even find it fun.
I don’t have much experience in C, but I’m not sure if bringing Rust’s ideas over to C would help.
As I understand, a lot of problems come from either that arrays are actually just pointers and if you don’t enforce it’s length for yourself then no one will, and in practice they span the entire area of process memory dorwards and backwards too. Or from that you free memory at the wrong time, or you never do that at all.
You can’t make mistakes with the first thing in Rust because the compiler takes note of the array’s length, and you just can’t abuse it as it won’t compile then. The second is a nonissue too, as memory management is automatic (kind of).
Fixing C sounds to me like patching up a sieve. That language was designed with those features in mind that make it error prone, and changing them would result in a different language. You would have to change your program anyway, and that probably wouldn’t be a small renovation. Also, you often can’t afford to not use pointers, because that’s how you pass things by reference in C, and besides passing by reference being important for performance reasons (to avoid copies) that’s the only option if so you have is a pointer to something, and when it’s stored in the heap.