I think what a lot of people don't realize is that, at least if you're writing Unix userspace code that mostly interacts with POSIX and/or kernel-specific interfaces, C remains the most convenient because the API/ABI standards are all designed with C semantics in mind, and a lot of wrapper/binding libraries in other languages are either too clunky or too abstracted, unless you decide to roll your own... and depending on the language, FFIs can be quite a nuisance.<p>The only languages so far that seem to have really gotten this are Go... and OCaml, to some extent (see the "Unix system programming in OCaml" document). Go in particular bypasses libc entirely by directly using the syscall interface, from what I recall.
The problems described are accurate. From a modern standpoint, C and C++ are terrible. The only problem is that most new languages are more terrible along other axes, making them unusable for what C and C++ get used for.<p>The author is accurate that Rust may be a substantial improvement.<p>I don't necessarily want to program in Rust, which is why I am designing my own alternative, but I think if you are building safety-critical software than something Rust-like is a pretty good idea.<p>For my own experiments I am going more in the direction of giving the programmer auditing power, rather than just having the programmer have to silently worry about what code may or may not be doing.
Extensive discussion: <a href="https://news.ycombinator.com/item?id=9477006" rel="nofollow">https://news.ycombinator.com/item?id=9477006</a><p>Nice to see all the same arguments from just 4 hours ago being repeated again here.
I'm almost tempted to pull out the old adage "if you can't stand the heat, get out of the kitchen". Yes, the C family of languages allows you to do many terrible things. It also allows you to do many great things. It is up to the programmer to decide what path to choose.<p>While the appropriate territory for the C family has decreased with the increase in processing capacity, there are still many areas where these languages are the right tool for the job. When another language family finally arises which offers the flexibility, conciseness and low-level access which characterises C (and its siblings, to a lesser extent) it'll be welcomed as a saviour, until that time they're the right time for the job.
Not gonna happen.<p>We need close to the metal tools for a whole pile of things, and that's not going to change.<p>If anything, tools to help write C, or find errors, test, etc... are the more likely path.<p>That said, we could reduce the number of use cases for C now, and not lose too much, but that's not going to be the death of it by any means. More like a rational pruning.
Every time I look at it, I have a very hard time taking Rust seriously. I really don't get whoever decided to use the shortest keyword names possible. It looks like a nice alternative to C, but wrapped in a horrible syntax. fn, f64, i32, u8, mut, mod, pub, ...
> Can we stop hand-writing parsing code in C please?<p>I think that tweet is more about using Lex or Yacc instead of hand-coding logic to parse strings.
C tooling is much better these days. If you run your code under valgrind or address sanitizer with a good fuzzer, most of these concerns go away. True, you might not need that for a memory-safe language, but you probably still need to fuzz your parsing code if you want it to be any good. And enabling address sanitizer requires adding one flag, so it's not all that much harder.<p>Hm, this arguments sounds similar to the "you need to write tests with good coverage anyway" argument that fans of dynamically typed languages make when they're told that static typing catches many errors at compile time :-)
Problem is: C, while very powerful, ends up being a burden in today's complex software.<p>It won by being less verbose and "more powerful" (for some uses) than Pascal (amongst other things), however, the way software evolved it starts to pull down.<p>There's a lot of unmanaged complexity in C (and in C++ it just ballooned); things like Go, Python (and even Java) taught us that managing complexity is important<p>It's very easy to shoot itself in the foot in C, C++ gives you a laser scope on top.<p>Some software gets away with C (like the Linux Kernel) by being very careful with it.<p><a href="https://twitter.com/id_aa_carmack/status/329210881898606593" rel="nofollow">https://twitter.com/id_aa_carmack/status/329210881898606593</a><p>Can C be salvaged? Maybe D is the answer?<p>What I would do: built-in strings into the language (C's strings are pretty much a syntax shortcut to a char array), safe strings, bounds checking, if you want an array of bytes you get an array of bytes, not a string. Type aware allocations (no more sizeof all around), maybe exceptions.
Blah blah blah. Another batch of anti-C/C++ propaganda by a technologically illiterate ignoramus. If C/C++ are too difficult for you then stay out of the way and use Ruby.
C! Made in AMERICA! (F--K YEAH!)<p>We can't be using any of those sissy languages made in Switzerland!<p>The real tragedy is that [Turbo] Pascal / Modula / Oberon / Eiffel never got any traction. We could have been ahead of where we are now for low / medium low level languages DECADES ago.<p>E.g. - Turbo Pascal:<p>* Checks array boundaries, but you can cobble up pointer arithmetic if you really need to squeeze something (it looks funny, as it <i>should</i>, but it converts into the same assembly code as ptr += size ; <i>ptr)<p></i> references ("var" params) used safely as non-optional values in most cases, using pointers for parameters that are truly optional.<p>* much stricter type checking and type range restriction allowed - most of which is only paid for at compile time, rather than run time.<p>* faster compiles, allowing quicker test cycles.<p>I suppose Ada fits in this group as well, but it was expensive in the late 80s.<p>Modern GC languages do well for long running application server programs, but they don't make good "transient" utility programs. We still need lower level languages for some types of programs.<p>Mobile could benefit from smaller memory footprints as well. I'm "gaming the game", but here are some tests on a 32 bit quad core setup, sorting by memory used for something that grinds through a number of connected objects as a surrogate for bulk data twiddling:<p><a href="http://benchmarksgame.alioth.debian.org/u32q/performance.php?test=binarytrees&sort=kb" rel="nofollow">http://benchmarksgame.alioth.debian.org/u32q/performance.php...</a><p>Alas, the Pascal version used 3 times the CPU seconds that the (fastest, but 2x more memory) GCC version did. However, a lot of work has been thrown into tuning GCC. Also, there were 6 C/GCC solutions submitted for this problem, of which 3 were not even correct. Of the other 2 C attempts, one was about the same size and speed as the Pascal version, and the other was twice as big and three times as slow.
inflammatory post. but it's techcrutch so what was i expecting?<p>this is the same as saying "armed concrete buildings fail more often then buildings made of paper and bamboo" while completely ignoring that all the world around them not even being possible without talented people building the armed concrete structures around the ego of whoever wrote this.
>> <i>…Which is why I’m so interested in Rust. It’s the one new programming language that might, finally, at last, replace C and C++ </i><p>Oh, I see ...
Pathetic human frailty has nothing to do with the validity of syntax. The machines will do as we say, for the most part.<p>Don't be an ass, and don't whine about bullshit like extra curly braces and semi-colons. Know your memory map. Get your shit together.