3 ms·

At this point, I think I'd rather that C simply freeze in amber to open the field to its replacement. C is sufficient. There doesn't seem to be anything left

by bsder 2y ago

At this point, I think I'd rather that C simply freeze in amber to open the field to its replacement. C is sufficient. There doesn't seem to be anything left that you can do without making it "Not C". Its ABI is the de facto standard. I would rather all the energy go to making a language without the legacy requirements. Programming languages develop very slowly because they are bound by social uptake. Putting C specifically as legacy would help accelerate those timelines.

t43562 2y ago
This is typical of software development projects - the "new" replacement wants to kill off the old one so cannot have any improvements happening to the old one. If the new ones are so great though ..... I suspect that quite a lot of maintainers of code don't want to rewrite it particularly and quite a lot of people upstream of that don't want to re-integrate everything to use something new. So little improvements that can be taken a bit at a time are fantastic.
eqvinox 2y ago
It's already frozen and the replacement is already there. It's Rust. (Yes there are other competitors, but unless a large shift happens, Rust has won¹´⁴.) The intent of maintaining C is to help maintain the shittons of existing C code. Even if people were to immediately start rewriting everything, it'd take a decade or two until most things have a replacement. And you still need to maintain and update things until then. There's enough work to think about making that task better - especially for safety concerns, like we're talking about here. (And, yeah, sunk cost and whatnot… especially if you're making a commercial product, a rewrite is a hard sell and a lot of C code will live far longer than we all wish. It'll be the COBOL of 2077, I suspect.) ¹ "high-level" C code has a lot of other options and probably shouldn't have been written in C to begin with. For low-level C code, Rust is the most suitable² and popular option, everything else is significantly behind (in popularity/usage at least). That might of course change, but for the time being, it is Rust and Rust is it³. ² this doesn't mean Rust is specifically targeted at or limited to low-level things, it just does them quite well and is a good slot-in for previous C uses. ³ of course C++ was supposed to be "it" the entire time, but at least as far as I'm personally concerned, C++ is a worse disaster than C and needs to be replaced even more urgently. ⁴ I'm aware Zig exists. Call me when it reaches some notable fraction (let's say ⅓) of Rust's ratings on the TIOBE index.
- bsder 2y ago
  > It's already frozen and the replacement is already there. It's Rust. (Yes there are other competitors, but unless a large shift happens, Rust has won¹´⁴.) Call me when I can integrate Rust into my build system without Cargo. Or when the Rust standard libary handles out of memory correctly. Or when compile times are within a factor of 2 of C. Or when debug mode isn't an order of magnitude or more slower to execute. Or ... Rust ain't gonna displace C any time soon. For C++, you might have a better argument.
  - eqvinox 2y ago
    Rust is suitable to replace C in some (nontrivial) percentage of cases right now, and that percentage will likely/hopefully increase over time. I agree integrating with existing C build systems is a sore point (in fact my largest personal grievance against Rust — tied to it's very annoying 'modern' habit of "everything brings its own package manager"). But for the time being I don't see any signs of design decisions that would permanently hamper Rust. That said, I think some of your expectations are rather personal to you with limited objective merit: the Linux kernel Rust people seem to be happy to use Rust without its stdlib to get the panic-freedom they need, and compile times being slower is something that needs to be weighted against the safety guarantees you get in exchange. Rust intrinsically warns/errors on a lot of things that with C you need a static analysis build for — and if you compare build time against C+SA, it's actually not slow.
  - SubjectToChange 2y ago
    Rust ain't gonna displace C any time soon. For C++, you might have a better argument. Incrementally replacing C code with Rust is far, far easier than C++. For instance, passing null-terminated strings to Rust code is quite straightforward, whereas a std::string absolutely is not. C will live for a very long time, but C++ will live even longer. Maybe that sounds absurd, but the fact is that every major C compiler is written in C++, and the rest of the toolchain is moving that direction if it isn't already there.
    - bsder 2y ago

by bsder 2y ago

t43562 2y ago

This is typical of software development projects - the "new" replacement wants to kill off the old one so cannot have any improvements happening to the old one. If the new ones are so great though ..... I suspect that quite a lot of maintainers of code don't want to rewrite it particularly and quite a lot of people upstream of that don't want to re-integrate everything to use something new. So little improvements that can be taken a bit at a time are fantastic.

eqvinox 2y ago

It's already frozen and the replacement is already there. It's Rust. (Yes there are other competitors, but unless a large shift happens, Rust has won¹´⁴.) The intent of maintaining C is to help maintain the shittons of existing C code. Even if people were to immediately start rewriting everything, it'd take a decade or two until most things have a replacement. And you still need to maintain and update things until then. There's enough work to think about making that task better - especially for safety concerns, like we're talking about here. (And, yeah, sunk cost and whatnot… especially if you're making a commercial product, a rewrite is a hard sell and a lot of C code will live far longer than we all wish. It'll be the COBOL of 2077, I suspect.) ¹ "high-level" C code has a lot of other options and probably shouldn't have been written in C to begin with. For low-level C code, Rust is the most suitable² and popular option, everything else is significantly behind (in popularity/usage at least). That might of course change, but for the time being, it is Rust and Rust is it³. ² this doesn't mean Rust is specifically targeted at or limited to low-level things, it just does them quite well and is a good slot-in for previous C uses. ³ of course C++ was supposed to be "it" the entire time, but at least as far as I'm personally concerned, C++ is a worse disaster than C and needs to be replaced even more urgently. ⁴ I'm aware Zig exists. Call me when it reaches some notable fraction (let's say ⅓) of Rust's ratings on the TIOBE index.

bsder 2y ago
> It's already frozen and the replacement is already there. It's Rust. (Yes there are other competitors, but unless a large shift happens, Rust has won¹´⁴.) Call me when I can integrate Rust into my build system without Cargo. Or when the Rust standard libary handles out of memory correctly. Or when compile times are within a factor of 2 of C. Or when debug mode isn't an order of magnitude or more slower to execute. Or ... Rust ain't gonna displace C any time soon. For C++, you might have a better argument.
- eqvinox 2y ago
  Rust is suitable to replace C in some (nontrivial) percentage of cases right now, and that percentage will likely/hopefully increase over time. I agree integrating with existing C build systems is a sore point (in fact my largest personal grievance against Rust — tied to it's very annoying 'modern' habit of "everything brings its own package manager"). But for the time being I don't see any signs of design decisions that would permanently hamper Rust. That said, I think some of your expectations are rather personal to you with limited objective merit: the Linux kernel Rust people seem to be happy to use Rust without its stdlib to get the panic-freedom they need, and compile times being slower is something that needs to be weighted against the safety guarantees you get in exchange. Rust intrinsically warns/errors on a lot of things that with C you need a static analysis build for — and if you compare build time against C+SA, it's actually not slow.
- SubjectToChange 2y ago
  Rust ain't gonna displace C any time soon. For C++, you might have a better argument. Incrementally replacing C code with Rust is far, far easier than C++. For instance, passing null-terminated strings to Rust code is quite straightforward, whereas a std::string absolutely is not. C will live for a very long time, but C++ will live even longer. Maybe that sounds absurd, but the fact is that every major C compiler is written in C++, and the rest of the toolchain is moving that direction if it isn't already there.
  - bsder 2y ago