"C is finished if it doesn't address the buffer overflow problem"
You should keep making this prediction ... one day you might be right! :)
You should keep making this prediction ... one day you might be right! :)
It also helps that C's standardization proceeds in ways that feel somewhat between sabotage and utter neglect.
Meanwhile, C is still the absolute best binary interop language devised by mankind.
This is not a random pet peeve, and WalterBright is as far as you can get from someone "who never wrote a line of code in C". This is the cause of numerous security bugs in the past and currently, and the reason most C material written in the 70s/80s is unsafe to be used today (mostly due to usage of strlen/etc vs strnlen/etc).
Fair warning - once you get accustomed to DasBetterC, you're not likely to want to go back to C :-)
I've been meaning to experiment with DasBetterC for a while, and I have a project C I've been wanting to migrate to something with proper strings (it's an converter for some binary file formats, but now I want it to import some obscure text formats too). Maybe that's the push I needed :)
After 20 minutes and about 250 out of 2098 lines converted, the error messages are very good and give very nice hints about what to change, I must say I prefer them to Rust's verbose messages.
DasBetterC's trial-by-fire was when I used it to convert DMD's backend from C to D.
I'm sure you already know this, but the trick to translating is to resist the urge to refactor and fix bugs while you're at it. Convert files one at a time, and after each run the test suite.
Only after it's all converted and passing the test suite can refactoring and bug fixing be considered.
C will still be used long after you and I and everyone here have returned to dust.
there are also people still riding horses. does not make it relevant in any way.
This is one of HN's comment guidelines. If you're not sure that someone is who you think they are, you can just ask, e.g.: "Hey, are you Walter Bright who did X and Y?"
Is it a rule at HN that you can't take someone else's name? Otherwise, there's no guarantee that you're talking to the "Real" Walter Bright...
... or that you're talking to that Walter Bright, come to think of it.
Nothing about Walter Bright in this statement, but some of the harshest criticisms from others I have seen of C are not from expert practitioners in C.
People who are experts and also critics seem to have a more practical, realistic, nuanced critique, that understands history and challenges to adoption, admits that the long history and difficulty of replacing C isn't exactly for no reason.
I also agree that what the standard committee has been doing for the last 20 years amounts to willful sabotage.
What about between c99 and c18? Is there anything you can think of? I think the _s() functions, advertised as security features, are a weak effort. Anything else come to mind?
Also the amount of UB descriptions just increased and are now well over 200.
Annex K was badly managed, a weak effort as you say, given that pointer and size were still handled separately, and in the end instead of coming up with a better design with struct based handles, like sds, everything was dropped.
ISO C drafts are freely available, I recommend everyone that thinks that they know C out of some book, or have only read K&R book, to actually read them.
But were they expert practitioners of C in the past? My experience is that most of the harshest criticisms of C come from former C experts who moved on to other languages because it became clear to them that C would never be fixed - Walter Bright included.
My point was that people were mistaking the comment for an attack on you, which I don't think was necessarily intended or needs to be without it being a valid point about a different set of critics.
You're mistaking the “C” ABI with the C language. The so-called C ABI should actually be called the UNIX-derived ABI, as (i) C doesn't define an ABI and (ii) C can perfectly produce binaries using another ABI (such as e.g. the “Pascal” one, common on the DOS platform).
By what measure would C be losing ground?
When we start seeing Rust or similar being used instead of C would be a good metric and / or major OS development.
However, the word "isoteric" is more correctly spelled (in non-phonetic spelling) as esoteric. The prefix "eso-" means "inside" in Greek, as in "esothermic", or "esophagus". The prefix "iso-" means "equal", as in "isomorphism", "isosceles", "isometric", etc.
The question is are people using C to program these hardware more? .. or are people gravitating towards safer compiled languages (Rust?). That's a valid question, even if the answer is "no C's usage is only increasing."
Nobody would do a project in C today with Go/Rust/C++ etc unless it's for a very specific situation
It's the one they know.
A C programmer isn't automatically going to switch to Rust for new projects that they would use C for, unless their goal is to use Rust.
And the history of Linux kernel and Android might come to an end if Zirkon ever replaces it, then it will be no more C on Android.
Android and Fuchsia source code are public available, just as their code reviews and ongoing work to port ART to Fuchsia.
Anyone skilful to use C without creating CVEs of their own, is surely able to find that information.
More usefully, if you want people to use D instead, what is stopping them, what reasons do they give? How can these be mitigated, cos while I like C I sure would like something better.
One of the key areas C is used that Rust cannot be used easily is in limited embedded devices. That looks like it'll be the case for at least 10 years and probably much longer than that.
The main limitation is going to be if your MCU is supported by LLVM. If you're targetting ARM, RISC-V, MSP430 or Xtensa you might get further than you'd expect.
There's a hell of a lot of tooling built around C though. So nomatter what happens I don't think we'll ever be rid of it.
A viable C replacement is Ada, although it is not for people who dislike the "code is documentation" bit.
Maybe he meant outside of the education system. I think the reason for that would be hype and peer pressure, and the feeling of novelty, with a hint of FOMO. I do not see any languages being pushed/hyped as hard as Rust.
That is a mighty good showing for C.
(We learned C++ in university in New York which was basically C with occasional help from C++'s standard library).
For every young programmer learning Rust there are probably 10000 learning C.
C is still the only language you can count on anyone with a programming-related education to have knowledge of. (That doesn't translate into being able to program is C, but still.)
not saying you're necessarily wrong (c is definitely simpler than rust), but I think most people would write a similar comment for whatever language they feel most comfortable with. I write c++ most days. even though it's the most verbose and complicated language I've ever used, I can still probably get stuff done way faster than in another language I happen to pick up.
if I'm just throwing something together really fast, I do mostly use the old school C functions though. scanf is way nicer than streams.
I don’t go out of my way to teach or suggest Perl to my younger colleagues. I don’t know why that is. They don’t usually reach for Python, which I think would probably be their best choice.
Maybe I’m just a curmudgeon ... and by the way, can you please stay off my lawn?
:)
Nothing wrong with learning multiple languages, of course. C was my first professional language, and I spend most of my days in rust now. No shortage of rust devs who are big on C too.
But I was responding to "C code is being replaced by Rust fast.".
The syntax is also currently REALLY unstable. As in: The hello world has changed almost every major version. Hopefully that too will be squashed with 1.0
To be fair though, Zig is probably the lest egregious and most flexible of the modern "C killers". I can see it's really trying to innovate low level programming. I really like it's flexible malloc systems and support for dynamic linking at runtime. It's compile time code execution is excellent too. The fact that they're actually trying to support obscure platforms like the z80 is a good indicator that they're staying true to C's "code anywhere" mantra. That's why I'm mostly focusing on linting issues of all things.
I think Rust has been very quickly fading into obscurity. What Rust hast brought to the tables was nearly the same what was brought by 100+ other programming languages in attempts to "fix C."
> What Rust hast brought to the tables was nearly the same what was brought by 100+ other programming languages in attempts to "fix C."
> Oh... can you show me those 100+ other languages that have opt-out memory safety, explicit lifetime annotation, a borrow checker and no runtime?
Maybe I can make it even clearer:
> What Rust has brought to the tables was nearly the same as 100+ other languages
> Oh... can you show me those 100+ other languages that have (some unique Rust features)
Because Google wants people to search using the Google search engine, and see ads while they're at it. That would happen less often if Chrome were properly capable of searching the history.
Opera did full text history search a decade ago, but that browser doesn't exist anymore.
Also, history is expected not to be tied to the device in the cloud era. What more history data could you scalably sync other than URLs and page titles?