Hacker News Reader

Comment by t43562 | Hacker News Reader

For new code you can use any language but we do have a lot of C code out there so it would be nice to have some ways to modernize it in, say 10 years, when those modernizations have made it out to every conceivable platform that runs the software.

e.g. GNU make could do very much with some better abstractions (not sure about this one specifically) and yet one cannot use such things until the last VMS user of gmake has got that feature in their C compiler.

IMO that probably means the most effective way to modernise C programs might be to transpile the modernisations to e.g. C89. That could be done on any device and the result, one hopes, would work on all the systems out there which might not have the modern compiler on them.

View on HN

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.

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.

> 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.

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.

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.

> Incrementally replacing C code with Rust is far, far easier than C++.

And yet other languages manage to do that far better than Rust.

Interfacing to C from Zig is both pleasant and straightforward, for example.

rust is a cpp replacement for people who know cpp enough to hate it.

and the ecosystem is very java and JavaScript like. it's impossible to import any dependency today and cross compile without a lot of troubles.

so yes, c things are being ported to rust, but in situations they would have been ported to cpp.

so yes, c things are being ported to rust, but in situations they would have been ported to cpp.

Not quite. I doubt librsvg would have been ported to C++ if Rust didn't exist. Nor do I believe that C++ would have been allowed into the Linux kernel as readily as Rust currently is, e.g. Android's binder.

Sure, Rust is a small language, but it is making consistent progress and it is only becoming more of a viable C replacement. Of course, C isn't going anywhere and the vast majority of C code is not going to be rewritten in Rust. However, that is normal in the lifecycle of programming languages, i.e. codebases are not usually rewritten, they simply become obsolete and are replaced. Just like Java didn't need to replace every line COBOL to become the enterprise language of choice, Rust doesn't need to replace C everywhere to become the preferred systems programming language.

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.

I wonder how hard it would be to just convert old C code to C++?

I mean, most of C just compiles as C++ and does the right thing. There may be some caveats with UB (but less if you don't switch compiler vendor) and minor syntactic differences, but I guess most of them could be statically checked.

Or is there any other (performance/size) reason to not do this?

> most of C just compiles as C++

um, not unless explicitly written to so.

> I mean, most of C just compiles as C++ and does the right thing.

In my experience, unless you’re strictly talking about header files (which I’m assuming you’re not), C code compiling via C++ compilers is usually hit or miss and highly dependent on the author of the C code having put in some effort into making sure the code actually compiles properly via a C++ compiler.

In the overwhelming majority of cases, what lots of folks do is just slap that `extern "C"` in between `#ifdef __cplusplus` and call it a day—that may work for most forward declarations in header files, but that’s absolutely not enough for most C source files.

By the way, a great example of C code that does this exceptionally well is Daan Leijen’s awesome mimalloc [0]—you can compile it via a C or C++ compiler and it simply just works. It’s been a while since I read the code, but when I did, it was immediately obvious to me that the code was written with that type of compatibility in mind.

[0]: https://github.com/microsoft/mimalloc

There are pretty fundamental differences in key areas, like zero initialization of a struct or array (`{0}` vs `{}`). Use the C way in C++ and you only 0 the first element or member. Use the C++ way in C and you don't 0 anything.

IMO there's no point even attempting a blind recompile of C as C++. A transpiler tool would be needed.

`int array[100] = {0};` results in an array with 100 zeroes in both C and C++. In C if there are too few values the remaining ones are initialized following the same rules as for static variables, and in C++ they're initialized using value initialization. For all types supported by C these have the same result.

We could fire WG14 and add Walter Brights fix for passing arrays, buffer and slice types. Add phat pointers and types as fist class objects.

If you did that and implemented marking passing size info over function calls then you could probably mechanically convert crappy foo(void *buf, int sz) code to foo(slice_t buf) which would be a lot safer to maintain.

The ABI for C++ is a disaster. That alone would doom such a conversion.

> I mean, most of C just compiles as C++

You're asking about old C code - that code won't compile as C++. And newer C code would likely also be cleaner and not benefit much from being compiled as C++.

(And, C++ is a net negative over C anyway due to much poorer reviewability.)

Reply on news.ycombinator.com