Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I currently have no reason to believe C won't outlive it, by a lot.

My reaction is kind of: "So what?" I really don't care about the relative lives of languages and don't really understand why anyone would. Unless I am wrong, there is still lots of COBOL we wish wasn't COBOL? And that reality doesn't sound like a celebration of COBOL?

IMHO it would be completely amazing if magically something 10x better than Rust came along tomorrow, and I'd bet most Rust people would agree. Death should be welcomed after a well lived life.

To me, the more interesting question is -- what if efforts like c2rust, Eurydice, TRACTOR and/or LLMs make translations more automatic and idiomatic? Maybe C will exist, but no one will be "writing" C in 20 years? Perhaps C persists like the COBOL zombie? Perhaps this zombification is a fate worse than death? Perhaps C becomes like Latin. Something students loath and are completely bored with, but are forced to learn simply as the ancient interface language for the next millennia.

Is that winning? I'd much rather people were excited about tech/a language/a business/vibrant community, than, whatever it is, simply persisted, and sometimes I wish certain C people could see that.





I plan to be writing C for the next decades even for new projects, because I think it is a great language, and I appreciate its simplicity, fast compilation times, stability, and portability.

I am happy if people are excited about Rust, but I do not like it too much myself. Although I acknowledge that it contains good ideas, it also has many aspects I find problematic and which why I do not think we should all switch to it as a replacement for C.


>it also has many aspects I find problematic

Could you share those?

Not trying to argue, just curious on the perspective of a C veteran, as someone who’s just starting with lower level languages.


Mostly the advantages a listed for C: stability, portability, simplicity, fast compilation times could all in reverse also be considered disadvantages of Rust. I am also not a fan of monomorphization, not of static linking, and not of having many dependencies out of a large uncurated pile of many projects. I also think Rust is not pragmatic enough. Overall though, my main issue is complexity of the language which I think goes in the wrong direction - this may be ok if the alternative is C++, but if you prefer C to C++ then Rust is equally unappealing. At the same time I think the advantages of Rust are exaggerated. I still agree memory safety is important, I just think Rust is not an ideal approach.

C strings (it's almost an exaggeration to say that C has strings) and "just never make any mistakes bro" based memory management come to mind.

With LLMs becoming so good at coding, "just never make any mistake" is also becoming easier. I usually write my own code because I don't like the coding style of LLMs, but on more than one occasion now they have proven very useful as code reviewers and bug hunters.

We were talking about Rust issues. But yes, C should have a proper string type. But as long as it does not have a better standardized string type, it is possible to define your own (or use a library).

Absolutely. Even when I preferred C over C++ (a long time ago), it was "but with a string library".

I bet that C won't just be around for legacy projects, but also for writing new code for at least the next 30 years.

C will end when our entire technological civilization collapses and has to start over from scratch and even then after a century of progress they will invent C again.

Hopefully not. C is a bad language even for the standard of the times it was invented in.

C isn't a bad language per-se, it just doesn't have an opinion on most things and I think that's exactly the reason why it survived many higher level (and more opinionated) languages that also already existed when C was created.

This is exactly right. The trend is towards comprehensive programming frameworks for convenient programming with batteries included. I hope this trend dies and we focus more on integration into the overall ecosystem again.

C was great... for the PDP-11.

Nowadays, not so much. Computers are multiple orders of magnitude faster, have multiple orders of magnitude more memory and storage and do things multiple orders of magnitude more complex than they used to. Portable assembly still has its uses obviously, but safer/easier/faster alternatives exist in all its niches.


> Portable assembly still has its uses obviously

C is much closer to any other high level language than it is to assembly. 'Portable assembly' might have been true with trivial C compilers of the 70s and 80s, but not with compilers like gcc or clang.


> Computers are multiple orders of magnitude faster, have multiple orders of magnitude more memory and storage

And C is still the best way to talk to the hardware in a portable way.


I haven't ever had to do anything serious in C but it's hard to imagine getting it 100% right.

A while back I wrote some C code to do the "short-bread" problem (it's a bit of a tradition at work to give it to people as their first task, though in Python it's a lot easier). Implementing a deque using all of the modern guard rails and a single file unit test framework still took me a lot of attempts.


COBOL has enough business money around to get new tools and ISO standards[0], so it is unlikley to think otherwise regarding C.

https://www.rocketsoftware.com/en-us/products/cobol/visual-c...

[0] ISO COBOL 2023 - https://www.iso.org/standard/74527.html


> COBOL has enough business money around to get new tools and ISO standards[0], so it is unlikley to think otherwise regarding C.

I don't think you understand my point. I am explicitly saying "C will definitely survive (like COBOL)". I am asking is that the kind of life people want for C?


Ideally we would have moved on into some Assembly glue + compiled managed high level languages by now, like Xerox PARC when then moved away from BCPL into Smalltalk, Interlisp-D, Mesa and Mesa/Cedar, but some folks and industry standards cannot let go of C, and those have to contend with that kind of life for C, exactly.

yeah, this is the actual good mindset.

C has never been a particularly good language, and is so good that finally (with tons of pushbacks!) there is an alternative that make the case so strong that is at least considered the possibility that will come the very happy day where C will be our past.

The only, true, real blocker is that C is the ABI. But if we consider the possibility that C can AND should be the past, then the C Abi can finally adds sophisticated things like Strings and such, and maybe dreaming, algebraic types (ie: the C will be improved with the required features so it can evolve the ABI, but not because will be a good language for write it (manually) on it).

And to reiterate: C should finally be a real assembly language, something we not need to worry about.


> And to reiterate: C should finally be a real assembly language, something we not need to worry about.

Assembly is used quite a lot and if you're a programmer Assembly is very valuable to know _at least_ how to understand it.

I disagree, also, that C should go away. Saying it was never a good language is a bit harsh. It's a great language. One that industries are built on. I'd rather read/write C code than, say, Rust.

Edit: There are, of course, languages coming up that can absolutely compete with C. Zig could be one when it's mature, for instance.


In my timeline, something 10x better than Rust came along in 1995.

Would you mind elaborating…?

Sane, easily readable syntax and expressive semantics. Easy to learn. Very scalable. Suitability, by design, for low level systems programming, including microcontrollers. Suitability, by design, for large, complex real-time applications. Easy to interface with C and other languages. Available as part of GCC. Stable and ongoing language evolution.

Manual memory management for anything beyond RAII.

I’d guess that’s a reference to Ada 95.


Java? Delphi? Better at what?


Honestly I'd be a bit disappointed if something better came along tomorrow. Just as we as an industry spent all this effort moving to Rust something better comes along? Lame. Obviously I want better languages to come out, but I'd either want a bit of warning or a slower pace so we as an industry don't totally "waste" tons of time on transitioning between short-lived languages. Thankfully languages need about 10 years to mature from 0.1 to production readiness, and industry happily ignores marginally (and moderately) better languages than what they're using, so this is not a realistic issue.

If all Rust accomplishes is ushering some other better project, it would have been worth it.

I think it would take a while for that to happen, purely due to momentum' the same thing that makes some people think that Rust isn't being used will affect any younger language just as much, if not more.

I think that there's an easier language than Rust struggling to come out of it, but if Rust had been that easier language with different compromises, I doubt it would have gained critical mass that allowed it to get where it is today. Being fast and safe meant it carved a niche in a "free square" that drove it to have a clear differentiator that allowed it to gain an initial audience. I also suspect that it is easier toale a language fast and then evolve it to make it easier to use, than it is to make it easy to use first and then make it fast.


Note I ignored the 10x part. I'd find it a bit lame if a language came out that's 1.1x better than Rust because we're now in the awkward position of having rewritten lots of stuff in the second best language. However, should a 10x language come out you'll just have to swallow all that bitterness and start over because 10x is 10x.

Obviously a 1.1x language will come out - we don't just jump directly to 10x - and that's fine, fantastic even, but a little bit annoying when you're a language enthusiast and you've personally spent lots of time advocating for the now next-best language.


> Honestly I'd be a bit disappointed if something better came along tomorrow.

You'd be disappointed if something 10x better came along tomorrow? I suppose you would you also be disappointed if magically we had economical fusion power, because you own utility stocks? Or we invented 10x better new car, because you already own an old car?

Of course the world wouldn't immediately move to one thing or the other, etc., and we'd still have a 10x better thing?

> Obviously I want better languages to come out, but I'd either want a bit of warning or a slower pace

The purpose of this thought experiment is to say -- it's perfectly fine for things to live and die, if they must. We've had a second Cambrian period for PLs. It's perfectly alright if some don't live forever, including Rust, which I really like.

In my thought experiment, Rust and C could also accept this new paradigm, and adapt, and perhaps become 10x better themselves. Though this is something heretofore C/C++ haven't done very well. IMHO new things don't preclude old things, and there mustn't be only one winner.

> Thankfully languages need about 10 years to mature from 0.1 to production readiness, and industry happily ignores marginally (and moderately) better languages

Which my thought experiment did as well? Read: This is a 10x improvement!


Oops, skipped the 10x part. If it's really 10x better that would indeed be amazing. That's basically the leap from C to Rust in domains that C is not good at.

COBOL is actively developed and maintained. It's far from being dead. Its working flawlessly and will be for the next few decades :)

I bet you never wrote single program in Cobol...


> COBOL is actively developed and maintained. It's far from being dead.

Who said it was dead? I was clear that I thought it was very much undead, like a zombie.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: