The Unreasonable Effectiveness of C (2013)

http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html?

by nkurz • 12 years ago

285 308 12 years ago

nkurz3• 12 years ago

Discussed a couple years ago here: https://news.ycombinator.com/item?id=5037089

And the followup discussed here: https://news.ycombinator.com/item?id=5075370

I repost because I'm becoming more and more frustrated with C, and wondered if others feel the same. Not because it's too low-level, rather because it seems to be trying (with limited success) to move to being a higher level language. There are times when I really do want a "thin layer over assembly", and C seems to have evolved to a place where that is no longer possible. I explain my distress more completely in the comments of Yann's article here: http://fastcompression.blogspot.com/2014/11/portability-woes...

pgeorgi• 12 years ago

Before reading the comments on that article I knew that it's about C compiler authors (ab)using properties of the C language for optimizations (and other code-breaking behavior).

Properties that some language lawyers cooked up back in the stone age to keep all compilers on all architectures compliant without further effort for developers, which is typical design by committee cruft to get people to buy in on the standard.

kazinator3• 12 years ago

If C was ever a thin layer over assembly, it stopped being that sometime in the 1980's, not recently.

C has not radically changed since the 1989 ANSI C standard. The library is bigger and there are some bells and whistles in there like designated initializers, structure literals, complex numbers and (now optional again) variable-length local arrays.

The trick of abusing C as a higher level assembler that are undefined behavior today were already undefined behavior already in 1980-something, and before that there was no standard at all, other than the K&R1 book.

alayne2• 12 years ago

The best optimizing compilers are C and C++ compilers (as far as I know), perhaps Fortran but even that is getting more esoteric. I think that's why the assembly idea persists.

nkurz3• 12 years ago

If tracking changes in the specs, you'd be right, but I'm referring more to the mindset. And I don't mean to imply this is anything sudden --- if pressed, I'd probably roughly gesture in the direction of 1998-2000, possibly related to a slow "changing of the guard". In this incredibly long but fantastic thread, Anton Ertl points to GCC 2.9.5 as the turning point. http://compgroups.net/comp.arch/if-it-were-easy/2993157 (search for Ertl). His rhetoric might be excessive, but he makes a good point that in practical terms, his research on "threaded interpreters" went from being possible to do in C to impossible.

I'm also not referring to syntax --- I think many of the syntactical improvements are fantastic and have no downside. And the reliability of modern compilers is much better, and by-and-large the optimizations produce smaller and faster code. But what I think we're losing is the transparency of being able to reason about code execution by looking at source code. It's still the norm for academic papers to offer source for two approaches to a problem, and use execution time to prove that one is faster than the other because "it has more operations" or "it has more memory accesses", without ever looking at the generated assembling and noticing that one approach has been vectorized and unrolled, and the other has substituted a completely different algorithm that drops all the conditionals because the compiler realized they were never being exercised.

And I don't think it's simply a matter of programmers exploiting undefined behavior without properly considering the consequences. The inclusion of the standard library into the spec for the language creates "spooky actions at a distance" that never existed before, where passing a variable to "print_debug(a)" allows the compiler to remove the later check for "if (a == NULL)" if print_debug() is observed to pass the variable to printf() and if whole program optimization is being used. Whereas if print_debug() is in a compiled shared library, this won't happen, and the null-check will work as intended. I see the reasons compiler writers want this flexibility, but it sure makes development and debugging much harder than it used to be.

cpeterso2• 12 years ago

If C was ever a thin layer over assembly, it stopped being that sometime in the 1980's, not recently.

Yes, if C were still a "thin layer over assembly", then cc -O1 and -O3 would not generate such different object code. :)

twelvechairs• 12 years ago

Not so long ago C was the 'high level language' to assembly. Now few people use assembly and C is 'low level'. Its a weird transition to make. There's still plenty of people around who want to use C for high level tasks.

userbinator• 12 years ago

You might be interested in this: http://blog.regehr.org/archives/1180 (discussed here: https://news.ycombinator.com/item?id=8233484 )

throwawayaway• 12 years ago

If I follow exactly what you are saying, you should say it's C coders who rely on undefined behaviour and compiler writers you are frustrated with, not the language itself.

rubiquity2• 12 years ago

It almost seems cruel to have a blog post written by someone from more than a month ago on the top of HN on Thanksgiving Day. I can picture the turkey and stuffing slowly tumbling out of Damien's mouth as he learns a blog post he wrote from early 2013 is at the top of HN right now.

maaaats• 12 years ago

It claims C has the fastest build/run cycle. Is this true? Many non-compiled languages I can redefine my functions at runtime, and with Java I can hotswap.

foxhill5• 12 years ago

build/run cycle
non-compiled language

C isn't trying to fit in that space. regardless, C code takes far less time to parse, optimise, and convert into machine code than all the languages i know of.

astrodust2• 12 years ago

Nope. Pascal is still king here. The speed it compiles at is simply ridiculous. Largely this is because the way the modules are defined makes it a snap to pre-compile aggressively. You're simply not allowed to do things that would change the way a module is understood by the compiler based on context.

The biggest hold-up in the C world is rampant abuse of #include files.

codygman16• 12 years ago

Doesn't Forth compile incredibly fast?

weinzierl• 12 years ago

I don't think it's true. Back in the day Pascal was known for a fast compile, single pass compile was a major selling point for Borland's Turbo Pascal. I don't know if a single pass C compiler ever existed but current C compilers use multiples passes (in addition to preprocessing). As far as I remember C was always known for a slow turn around cycle compared to other languages.

mansr• 12 years ago

Borland used to tout the virtues of their single-pass C/C++ compiler too, even as far back as version 2.0.

Most modern C compilers have used an integrated preprocessor for quite some time, and Clang/LLVM can emit machine code directly without going through a separate assembler.

jbergens3• 12 years ago

VB is actually faster to compile than C# and probably a lot of other languages. Not very used now but VB.NET works well in a .NET environment.

zik• 12 years ago

Go has the fastest build/run cycle I've seen. You can usually compile compile to a binary and run it quicker than it takes a python runtime to start up. It's totally viable to use Go as a scripting language while compiling to binaries from source.

digisign• 12 years ago

You may have a very long python-path and/or script loading a lot of modules initially if it is taking so long to start up.

For example, in a recent script I deferred loading the requests module and startup improved a few tenths of a second. Rinse, repeat.

Scramblejams14• 12 years ago

I mostly work in Python but I had a similar scripting-like experience during my Go project -- with a small codebase, the time it spent compiling was barely perceivable, if at all. Very impressive, and shows you what's possible.

Semi-relatedly, the downvoting around here has gotten completely out of control. It's sad, what's happened to HN.

codygman16• 12 years ago

I'm guessing you've never used Lisp/Slime?

SwellJoe• 12 years ago

go has a very, very fast build cycle, partly due to the language and partly due to conventions (the standard preprocessor in C is absent in go). But, that might not have been on Damien's radar when he wrote this.

And, go is built by some of the same people who built C for some of the same purposes (plus some new ones, like concurrency and networks), so it's arguably a "better C", and probably prioritizes some of the same goals. Simplicity and small surface core language area, in particular, but removes some of the dangerous aspects of C (which might be a problem for something performance-oriented, since well-written C is still faster than well-written go for most tasks, and may always be).

But, as you note, if you don't have to build, the cycle is even faster. I still consider a compile phase a slowdown over dynamic languages that don't compile.

Then again, so many people have introduced "compile" like stages into their dynamic process (SASS, LESS, test coverage checks, etc.). It may be difficult to completely get away from a compile like stage in any app of significant size.

Anyway, a large project in go is faster to compile than a large project in C, in my experience, but my experience is exceedingly limited.

codygman16• 12 years ago

I don't see why people keep calling Go a better C. Most of the C programmers I know use it because they want manual memory management which Go doesn't have.

gfodor• 12 years ago

So, is Rust a better C? I haven't dug into it too much but that's been my general impression of how it's been presented.

dllthomas8• 12 years ago

I doubt it's a uniformly better C, just because the space has so many dimensions. I hope it's a better C, on balance, for the things I want to use C for. I've not yet dug in, though.

femngi• 12 years ago

Rust is aiming more to be a better C++. However that doesn't preclude it from being used in the same space as C and can become impressively lightweight if you forgo things like the standard library.

I would argue that it is better than C for its safety features alone. I hope in the future we look back at this decade with its never ending stream of buffer overflow vulnerabilities with disbelief that we could use something so insecure for something so vital.

reikonomusha2• 12 years ago

Shouldn't we already be suspended in disbelief given the languages we have had for 30+ years?

pjmlp7• 12 years ago

I have been complaining about it since the MS-DOS days and many of us used Turbo Pascal, when Assembly wasn't required.

Somehow along the way UNIX spread into the enterprise and brought C along.

byuu9• 12 years ago

It's somewhat higher level than C.

I've always liked to think of myself as a programming polyglot, able to pick up and reason about nearly any standard language. I'm not sure how Rust is doing it, but the more I read and learn about it, the more confused I am. The syntax is just so bizarre and counter-intuitive to me. And yet I seem to be the only person in the world who doesn't "get" it. It's as if the language is being explicitly developed to be my kryptonite.

lincolnq• 12 years ago

Rust seems to me much more like Haskell than C or C++. Try thinking about it that way and see if it makes more sense.

panzi7• 12 years ago

The syntax is just so bizarre and counter-intuitive to me.

Really? What part of the syntax in particular?

jeffreyrogers3• 12 years ago

My impression of Rust is that it focuses too much on safety at the expense of making it hard to do what you want, especially when dealing with low level things.

imron2• 12 years ago

Yes, hard to accidentally introduce buffer overflows, memory leaks and other things you probably hadn't fully considered.

If the Rust compiler is stopping you from doing something, there's good chance you really shouldn't be doing it.

gnuvince• 12 years ago

Here's a question: if you write the same code in Rust and C and Rust refuses it on the grounds that you did something wrong and C accepts it, how likely is it that the C code is going to crash at runtime, and you'll have to fix it anyway?

hbex5• 12 years ago

It's basically impossible to write safe code in C. Surely that makes it pretty damn poor at what it does?

Especially since system code is the place where safety matters most.

Scramblejams14• 12 years ago

I have no idea why you're being downvoted. Probably by a bunch of people who think they can write C and C++ without writing any security bugs. Which, unless they belong to a vanishingly small group of security experts who write code in an organization with the same discipline, budget and glacial schedule of the team writing software for the Space Shuttle, they can't.

foxhill5• 12 years ago

except that literally every piece of software you have ever written or used goes through some level of C, and lets face it, most of the C projects out there are actually pretty well tested.

and it's not like higher level languages are significantly better in this regard.

alayne2• 12 years ago

Memory safety can't guarantee security or correctness. If you guys want to have a better discussion, you need to be even handed about the complexity of security. Languages can solve some classes of security problems.

frozenport• 12 years ago

Consider the Linux kernel?

Scramblejams14• 12 years ago

Which is filled with security bugs. Consider the conventional sysadmin wisdom that if someone gets a shell on your box, it's as good as owned, due to a no doubt fertile field of privilege escalation vulnerabilities in the kernel.

Don't get me wrong -- the Linux kernel is a magnificent piece of engineering, and an excellent choice for hosting a mainstream server, I run a number of such myself -- but let's not kid ourselves about its security limitations.

EliRivers• 12 years ago

One of the local Gods, "the market", would seem to imply that it doesn't matter much to most people.

Scramblejams14• 12 years ago

Distressingly true. I despair that 20 years from now, absent an utterly wrenching change, we will all still be playing whack-a-mole with a seemingly infinite number of security bugs, many of monumental severity, all because we are unable to move away from our memory unsafe foundations.

And the endless supply of ignorant C/C++ programmers (of which I am not suggesting Damien is a member) who profess to management that they can easily write secure code does not help.

sampo3• 12 years ago

I don't think he wanted safety, he wanted fast runtimes. Is there any way to achieve speed without sacrificing safety? Ada?

jbergens3• 12 years ago

He kinda did. He writes that they changed from Erlang to C because of problems in Erlang. He wanted some safety or tools to help him find problems easier (actually problems in the language or libraries they used). They might develop slightly faster now in C than they did before in Erlang but I doubt it and the rewrite took time that probably cost them 2 months of inproductivity compared to not rewriting it. As for running speed they of course want that. Can't remember if they actually thought that low speed was problem with the earlier Couchbase.

doublextremevil• 12 years ago

I think that is exactly what Rust[0] is trying to do.

[0] http://www.rust-lang.org/

ars4• 12 years ago

It's basically impossible to write safe code in C.

Of course it's possible. If your issue is memory checking you can use mudflap or valgrind.

Surely that makes it pretty damn poor at what it does?

No, it surely does not.

Especially since system code is the place where safety matters most.

And yet somehow they manage. The security issues you find in system code are not things that would be helped by range checking.

letstryagain• 12 years ago

Of course it's possible. If your issue is memory checking you can use mudflap or valgrind.

It might be theoretically possible but in practice nobody has managed to do so with any non-trivial application.

adamnemecek• 12 years ago

"When someone says: 'I want a programming language in which I need only say what I wish done', give him a lollipop."

What a shitty, shitty quote.

Double_Cast• 12 years ago

This quote confused me. What does it mean?

ArtB• 12 years ago

That dream is so child-like that you should treat that person as a child.

htor2• 12 years ago

"C has the fastest development interactivity of any mainstream statically typed language."

This is not true. Using debuggers and crash dumps to reason about your running program is not fast or interactive at all. It doesn't matter how good the tools are. They interrupt the workflow.

Working in a REPL on the other hand, is real interaction with your program. You speak the language to the program and the program responds in the same language. This is fast.

dap• 12 years ago

Using debuggers and crash dumps to reason about your running program is not fast or interactive at all.

Says you. Using core dumps is a different kind of interactive. Rather than testing out what a program would do or could do (as in a REPL), you're iterating on theories of what it did do. It definitely takes getting used to, but I'm often much faster debugging (even non-fatal problems) from a core file than iterating with a step-through debugger or rerunning the program.

It also helps a lot when the tools within the core dump debugger are good -- you should be able to quickly dump what's relevant to your program (not just threads and stacks and individual objects).

sampo3• 12 years ago

But he said "mainstream statically typed language". Is there one such with a REPL?

Would Scala be mainstream? OCaml or Haskell probably not.

htor2• 12 years ago

Yes, I'd say Haskell and ML are mainstream languages by now.

the_af• 12 years ago

True, but that's an argument to move on to other, less popular (for now) statically typed languages which are better than C and have REPLs.

We could debate whether it's wise to move on from C (I think in many situations it is), whether it's likely there will be more industry adoption of $MY_FAVORITE_LANGUAGE, but that's a different debate.

Also, if we keep favoring C (or Java, or whatever) because they are mainstream, then other languages will never become mainstream, and we will be stuck forever coding in horrible languages. Who wants that?

vezzy-fnord3• 12 years ago

Honestly, sometimes I think that the best solution for fixing the security quagmire we're in would have been not by creating a new system programming language like Go, Nim, Rust, D or even reviving one of the Wirthian languages (though having them on the table is very much a good thing), but by creating a memory safe dialect of ANSI C, and perhaps standardize on a better string handling library.

In fact, such an effort was started at AT&T back in 2001. The language was named Cyclone [1]. It met its 1.0 release in 2006. It has since been abandoned. Which is a damn shame, because it looked like it had real potential.

Is C a primitive language? Yes. In fact, it's almost stupidly simple compared to most modern languages. But its greatest weakness also proves to be its greatest strength. The main cognitive overhead from using C is in its manual memory management model and certain gotchas in standard libraries. It being bare bones as it is (but not too much) also makes it surprisingly pleasant at times. I get the feeling that plenty of modern languages try too hard to be novel and, for all the freedom you get from not having to worry about anything below program logic itself, you still end up expending a lot of effort into complicated high-level patterns that are frequently interspersed with arcane PL theory.

But that's not even the main reason why something like Cyclone is much needed. No. It's that we've pretty much perfected a ton of our APIs, like POSIX, to work with C. It simply feels most natural to work with POSIX in plain C. FFIs and bindings vary, some of them like Nim's actually feel quite clumsy (otherwise Nim makes it absolutely trivial to create FFIs, which is great).

Finally, refactoring 30 years worth of code into Cyclone sounds far more realistic than rewriting the world in Rust.

[1] https://en.wikipedia.org/wiki/Cyclone_%28programming_languag...

Scramblejams14• 12 years ago

Yes, I too had high hopes for Cyclone when I saw it back then. Sad it seems to have stagnated.

Araq• 12 years ago

Thanks for mentioning Nim! :-)

I can't say I agree with anything you say though... So only memory safety is C's problem? Not its type system that's very weak in every aspect (not just memory safety)? Not its missing module system? Not its ambiguous syntax?

You also confuse "simple" with "primitive" and perhaps "familiar". C surely is primitive, but how is it simple? Simple to use? No. Simple to implement? Not really. Has a simple mapping to the underlying hardware? That stopped being true three decades ago.

lgeek• 12 years ago

Has a simple mapping to the underlying hardware? That stopped being true three decades ago.

I've seen this claim repeated a few times in the thread and I still have no idea what it means.

For medium levels of optimisation it's usually very simple to predict what assembly code will be generated by C compilers. On many platforms the operators often match directly to a instruction (e.g. arithmetic and bitwise operations) or short patterns of instructions (the control flow primitives and conditional execution, equality testing, function calling, etc). At a higher level, compiled C functions look pretty much exactly like manually written assembly language procedures and structs are just blocks of memory with clear order and offsets. It's also very simple to interface C and assembly code without any hacks on either side.

fithisux4• 12 years ago

Cyclone has been superceded by Rust. Rust is the new Cyclone.

Scramblejams14• 12 years ago

I think he's right, though. It's too much to ask for all this memory unsafe code to be rewritten into Rust, which is a large leap in semantics from C. There really is a space in the market for a safe variation on C which is easy to port to.

Now, how much safety you can demand before the language turns into a unicorn is another question and would be interesting to explore.

andrewchambers13• 12 years ago

C is a great language, for fun I'm slowly working on my own highly C like langage - https://github.com/g-programming/glang.

Its basically C with Go like syntax, and a package system instead of headers. I aim to fully interop with existing C code and have no runtime requirements beyond what C has.

I'm not trying to go crazy with extra features over what C has though. An important part of what will make it work, is perfect interop with existing C code.

Yes I understand memory safety issues, but there is always a need for machine independent assembly languages. which C essentially is.

p4bl0• 12 years ago

Your project sounds very cool. Will it have the Go methods and interfaces system too?

andrewchambers13• 12 years ago

I think its important only add those things after the language can run the same sorts of programs C can currently.

For the future, some of my ideas include:

a form of combined data types that require a type-switch to disambiguate (and is checked by the compiler), like algebraic data types. (essentially sugar over tagged unions)

It may also have a form of defer blocks similar to Go defer statements. (sugar over the C idiom goto cleanup;)

A final thing I considered was a built in reference counted pointer type. Just to partially alleviate memory management, but without resorting to a garbage collected run time.

robmccoll• 12 years ago

This is really cool, but what about porting the go standard library to C instead? Will this make that easier? Does the ABI of g meet C's?

andrewchambers13• 12 years ago

G will use llvm as its primary backend, and my intention follow the C ABI exactly so interop requires no work.

I haven't considered the standard library much beyond the fact that I would G to have its own that is inspired by the good parts of other languages. At first it would have to rely on C libraries.

G won't be able to support every way that the Go standard library works. But if you need everything Go has, then you probably want to use Go to begin with.

ivoras• 12 years ago

Unfortunately, no one will agree exactly on which aspects of C to change and which to keep - that's why we now have hundreds of languages used by less than 10 people each.

E.g. while I applaud the idea, I found many aspects of your example code snippets ugly and un-C-like. This is not to say that I'm worthy of judging your work, but that a) so much of it is a matter of taste rather than objective thought and b) humans can adapt to literally anything, given time to get used to it.

andrewchambers13• 12 years ago

They are closer to Go than C I admit. Many languages are actually shifting to grammars similar to this for a few reasons. At the very least the grammar is less ambiguous, and its easier to code editing tools to recover after parse errors.

leaveyou• 12 years ago

You are not alone. Here is some guy doing something similar but his syntax is not so heavily inspired by Go (but still steps forward): c2lang.org

andrewchambers13• 12 years ago

c2 has simlar syntax and ideas :). Looks cool. I have a few other ideas that I think will differentiate later.

dothebart• 12 years ago

one of the best things C has to offer was omitted herein - the preprocessor ;-)

101914• 12 years ago

"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

- Joe Armstrong

One could argue, easily, this is true for many of the popular garbage collected languages. It is certainly why I do not care for them. It is also why I do not care for some of the popular OS's, or most of the popular "software solutions". It is the unwanted delivery of the kitchen sink when all I want is a glass of water.

The OP says he's frustrated with C "because it seems to be trying (with limited success) to move to being a higher level language. There are times when I really do want a "thin layer over assembly", and C seems to have evolved to a place where that is no longer possible."

"seems to have evolved"

Some of my favorite programs that continue to work reliably, year after year, are written in what I guess some would call "primitive," K&R-like C and with little need for "the" standard libraries. I am not an expert C programmer, but I have no complaints when reading and editing this "primitive" C. I have seen others complain about it in forums.

One of my favorite source code comments is in the netcat source where the author says he's going to write the program as if he's writing in assembly. In my mind C should be just a thin layer over assembly. Essentially, to me, it should be a kind of "shorthand" for writing assembly. (That implies the author should think as if he's writing assembly. And C just takes away the drudgery of actually typing out all those lines of assembly instructions.) Now, that is just my opinion. I am not an expert C programmer. I know nothing.

Kenji• 12 years ago

"One could argue, easily, this is true for many of the popular garbage collected languages [...] It is the unwanted delivery of the kitchen sink when all I want is a glass of water." Exactly. It's basically like forcing people to throw all their garbage on the ground and then forcing them to pay for the garbage men who collect said garbage. It would be easier for everyone to just go to a bin and dispose of the trash themselves.

djur• 12 years ago

The problem is that there's a great deal of data structures that are difficult or impossible to write in a provably safe way without garbage collection (or reference counting). Pick up _Purely Functional Data Structures_ and take a crack at implementing them in Rust without unsafe{} and you'll see what I mean.

reikonomusha2• 12 years ago

Not when you have an awful, tangled mess of garbage that's not all "loose leaf". Then a special person to disentangle and find out what truly is garbage can be a lot easier than trying to do it manually, every time, as a part of the computation itself.

Elrac• 12 years ago

"C has the fastest development interactivity of any mainstream statically typed language."

I wonder if this statement is true since the invention of Go. A very fast compile was one of the design goals of Go, and its authors could afford luxuries (esp. In terms of memory use and object file size) that were unthinkable in the days of C. For example, IIRC object files contain the compiled code of their source plus the top hierarchy of modules called.

People have mentioned that changing a .h file in a large C project could trigger a lengthy recompile. AFAIK, Go minimizes this problem, so if the hype is correct there should be lots of projects where similar situations will be handled faster in Go.

My own empirical experience is very limited. I can confirm that Go compiles much faster than Java for my code, but that will surprise no one and it doesn't help us compare with C.

Does anybody have more tangible data regarding Go's alleged speed demon nature esp. as compared to C when compiled with e.g. VS or gcc?

bkeroack• 12 years ago

"I always have it in the back of my head that I want to make a slightly better C. Just to clean up some of the rough edges and fix some of the more egregious problems."

This is called Go. Brought to you by the same people who gave you C.

imanaccount24722• 12 years ago

No it is not. Go is only "like C" in the sense of the most superficial syntactic similarities and that it is primitive. It isn't even in the same world as C, it is just another high level garbage collected language that compares poorly with the rest of the languages in that group. Go was not brought to us by the people who made C. It was brought to us by Rob Pike and Russ Cox. Dennis Ritchie gave us C.

jbergens3• 12 years ago

Ken Thomson was (and is) also involved with creating Go and he was also one of the writers of Unix. He actually invented the B language which preceeded C, so it was close :-) I think he wrote a lot of C in Unix and was therefore part of making C popular.

codygman16• 12 years ago

Go has a garbage collector, that makes it not like C.

angersock3• 12 years ago

Go looks more like a descendant of Sawzall and Limbo, but sure.

aosmith• 12 years ago

C is a great language but have you tried go? Feels very c like with a lot of very nice conveniences.

jeffreyrogers3• 12 years ago

Go is garbage collected though, and a lot of people using C don't want a GC'd language. (It's up for debate whether GC actually matters for most of them, but that's the feeling nonetheless).

Edit: also, not sure why you were downvoted, since your question at least deserves a reasonable answer.

Scramblejams14• 12 years ago

It's because this place has turned into Reddit. :-(

arh68• 12 years ago

(2013)

First, I think the speed of C relies heavily on the compiler. C is not fast, not if I wrote the compiler. But GCC is very fast, and ICC at least as much.

I was a little confused by the Erlang wariness, but the reasoning seemed sound

At Couchbase we recently spent easily 2+ man/months dealing with a crash in the Erlang VM. ... ... it was a race condition bug in core Erlang. We only found the problem via code inspection of Erlang.

That does not sound like a fun time, but once the bug is fixed, what's the big deal? Is there good reason to believe more bugs will come? It wasn't my ass that got bitten but I'd forgive Linux even if it had a race condition bug. (or if it crashes touching 1000 files in /etc)

andrewchambers13• 12 years ago

No, C is fast, even tcc which does essentially no optimization except for constant folding is about half as fast as gcc -O1 I think. Basically no special work is needed to be 50 times as fast as python.

ris• 12 years ago

"No special work" except the massively more laborious effort of writing the whole thing in C.

neutronicus2• 12 years ago

Hmmm. I work on a pretty large scientific computing project written in C++. Complex numbers in C++ are much, much better than they are in C. In general, I'm very happy it isn't in C.

panzi7• 12 years ago

Are you comparing C's built in complex type with a C++ library or a C++ library with a C library?

neutronicus2• 12 years ago

In both cases it's libraries defined by their respective standards, I think.

The important thing is that the C++ class overloads operators and mathematical functions, and the C class doesn't.

byuu9• 12 years ago

This last bit is so true:

I always have it in the back of my head that I want to make a slightly better C. Just to clean up some of the rough edges and fix some of the more egregious problems.

I'm always mulling over that. "Maybe just namespaces, better macros, function overloading and member functions (eg this->) would work." Yet I'm sure Bjarne Stroustrup was thinking the same thing when he started on "C with Classes." The power to add features must be so overwhelmingly corruptive. So justifiable in each and every case, in the moment. And then you just can't stop. "Closures would be helpful. I'd love to write generic containers. Inheritance would save so much typing.", and the next thing you know, you're working on virtual inheritance, concepts and user-defined literals. :/

In my opinion, C really does need just a bit more to be great, but it would need someone with a will of steel to stop and leave things be after that.

andrewchambers13• 12 years ago

I agree totally, my top level comment in this thread has my version of what a great C replacement would be. I'm slowly working on it.

byuu9• 12 years ago

Looks like a decent start, but not enough there to really judge it yet. Best of luck, I'll keep an eye on it! If you'd like feedback (ignore this post if not):

Caseless switch is a great idea, especially no-fallthrough by default. Consider extending it with substituion, eg "case > 7:", "case >= 13 && < 16:", or "switch longvariablename as N { case N > 13 && N < 16:". Return types after function parameters are nice, consider saying "function foo(params) returns type" instead.

Tuples always feel important but in practice I tend to not like them. Variable definitions are a bit clunky, and inconsistent with struct variable definitions. Consider ctors/dtors and/or inline member initialization. I would recommend not to compress keywords: func -> function, const -> constant, etc. "type name struct" would feel better and more consistent as "class name". The C. prefix feels like it'd be great if you only use a very small number of C APIs, and very annoying if you used a lot of them.

The boldest and coolest part is building this directly on LLVM. My thought was always to transform the IL into C (trying my best to preserve line numbers and variable names), and then let GCC or Clang build that.

My ideas were unified function call syntax (never any functions inside classes), subclasses (declare a class inside another class, but the child class has direct access to the parent class' scope), namespace-aware multi-line macros (trailing \ is grotesque), and if implementing a backend instead of a translator, zero undefined behaviors in the language (do what people expect on eg signed integer overflow instead of GCC doing whatever is fastest yet obviously wrong. Aim for hardware that is actually used today instead of worrying about hypothetical PDP-11 programs, so no 9-bit chars.)

tonysuper• 12 years ago

C needs wider adaptation of Apple's "Blocks" extension and MAYBE extremely limited generics and it's perfect.

bjz_• 12 years ago

and MAYBE extremely limited generics

C11 has _Generic, but it's pretty much an abomination: http://www.robertgamble.net/2012/01/c11-generic-selections.h...

rozap• 12 years ago

http://libcello.org/ looks like it might fit that bill. I haven't tried it, though I've been meaning to.

KeytarHero2• 12 years ago

So why not use C++?

Since it's a superset of C, why not just use C++ to program C-style code, using only the C++ features you want? C++ is a multi-paradigm language; you don't have to write object-oriented code if you don't want.

byuu9• 12 years ago

Code portability is a big one. People write C compilers in a week as a hobby. Now compare to how long it took Clang to fully support all of C++. Now certainly, C++ is on every major platform in broad use. But maybe you are targeting something embedded, or a hobbyist OS. Or maybe you want to write up a quick embedded interpreter for scripting in your application. There's something intrinsically satisfying about minimalism and simplicity.

It's also really hard to control the feature-set of C++ you want. The second you start pulling in code libraries, you find yourself needing to use the parts you don't want. Not in your own code directly, but in your interactions with their library code. Catching exceptions, needing RTTI, etc.

Symbol exporting is also a really sore point in C++. The symbol names C++ compilers spit out are just terrifying. With a C language, it's trivial to write bindings for other languages like C# and Python.

But for what it's worth, I still program almost exclusively in C++.

lordnacho• 12 years ago

The boring response would be that different languages have different strengths. C is indeed capable of being very fast, mainly by virtue of letting the dev have fine control over memory. But execution speed isn't the only metric. Sometimes you just need something to be done quickly and you know you aren't going to hit the constraints (time, space) of the system, so you might as well go with something like .NET to reduce your development time.

The point about the tooling I'm not so sure about. There's a lot of languages out there with well developed tools. And the tools tend to address the pain points: you have GC profiling in .NET, and you have Valgrind-type tools in c++.

imanaccount24722• 12 years ago

Every time there is a claim of "near C" performance from a higher level language like Java or Haskell, it becomes a sick joke when you see the details. They have to do awkward backflips of syntax, use special knowledge of "smart" compilers and VM internals to get that performance, to the point that the simple expressive nature of the language is lost to strange optimizations that are version specific, and usually only stand up in micro-benchmarks.

I see this kind of statement a lot, and it simply does not hold up to even a cursory look. Where are the awkward backflips of syntax, special compiler or VM knowledge, or version specific optimizations here?

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

Why are there so many java web frameworks/libraries/servers that offer performance close to C?

http://www.techempower.com/benchmarks/#section=data-r9

Critically important to developer efficiency and productivity is the "build, run, debug" cycle.

This is a pretty bizarre claim. Sure, having an equally archaic and primitive process but 10 times slower is obviously worse (C++), but that doesn't mean having an archaic and primitive process is good if it is fast. I rarely ever run my code, much less debug it. Freeing myself from that horrible way of working was one of the greatest things about working in a language with a useful type system.

applecore• 12 years ago

What's horrible about running your own code?

sliverstorm• 12 years ago

I think he is saying in a round about way his code always works just right on the first compile, so he never even needs to run it before releasing it.

imanaccount24722• 12 years ago

Nothing. What is horrible is being forced to run it constantly every single time you make a tiny change to see if you messed it up or not. I don't need to do that when I am using haskell, I just have my repl session autmatically :reload when I save a file and it tells me if I broke anything.

vezzy-fnord3• 12 years ago

I rarely ever run my code, much less debug it.

I'm not sure what you mean by this, because it sounds horribly wrong.

lmm5• 12 years ago

Imagine if just compiling your code told you all the things you get from running a good suite of unit tests. And you didn't even have to write the tests, just add a few annotation hints to help the automatic test generator occasionally. That's what a strongly typed language can get you, impossible as it sounds.

Guthur2• 12 years ago

One might assume he is using Haskell or similar, and is assuming that because the compiler accepts his code it is therefore correct, of course this is a fallacy. I will use a particular apt quote from Donald Knuth "Beware of bugs in the above code; I have only proved it correct, not tried it."

woah2• 12 years ago

Idunno I write JavaScript primarily and I can go days without running a project. It's a way that I enjoy working. I kind of thought that everyone works this way. When I run my code, I'll usually have a few typos and syntax oversights, but other than that it usually works fine and tests out. Writing in a concise functional style really helps.

To some degree, if you can't write code without running it, it's a sign that you don't really understand the code you are writing.

imanaccount24722• 12 years ago

Exactly what I said. I rarely run my code. When your compiler catches 99% of your errors as soon as you reload your repl, there's far less need to be constantly running your program to see what it is going to do. I know what it is going to do, the code tells me. I only run it when I need to, which is when I am doing something unsafe, when I have made a lot of big changes and want to double check them, or when I need it to run to produce new output for some other program to process.

CountSessine• 12 years ago

Sure, having an equally archaic and primitive process but 10 times slower is obviously worse (C++)

Oh, for heaven's sake. You don't really think that, do you?

zb• 12 years ago

C++ compilation is much slower than C, and linking is off the charts slower. I don't think that's even controversial?

imanaccount24722• 12 years ago

Yes? What is controversial about that?

panzi7• 12 years ago

The benchmarks you linked are interesting. Rust is #1, right before C: http://benchmarksgame.alioth.debian.org/u32/performance.php?... Maybe Rust will finally be a real competitor to C.

heinrich59912• 12 years ago

And that without any use of `unsafe` in the submitted solution.

jpgvm3• 12 years ago

The only thing in the way of that right now is Rust stabilising.

The future of Rust and systems programming is very bright indeed.

detrino• 12 years ago

While Rust is indeed competitive with C here, its likely only number #1 because LLVM is generating better code than gcc for this example. I'd expect clang/C to run at least as fast.

yongjik• 12 years ago

They have to do awkward backflips of syntax, use special knowledge of "smart" compilers and VM internals to get that performance, to the point that the simple expressive nature of the language is lost to strange optimizations that are version specific, and usually only stand up in micro-benchmarks.

...Huh, and the author thinks C doesn't? :)

(Well, except the VM part.)

"What Every C Programmer Should Know About Undefined Behavior" springs to mind: I believe it's been discussed several times in HN.

coldtea5• 12 years ago

Where are the awkward backflips of syntax, special compiler or VM knowledge, or version specific optimizations here?

And then you follow with 2 links that are nowhere near idiomatic Java. Plus they are microbenchmarks (which he also mentions).

imanaccount24722• 12 years ago

You managed to respond, but didn't manage to actually say anything. If you want to argue the point, then make your argument. Claiming it is "nowhere near idiomatic" despite it being perfectly normal code and doing none of the things he claimed is not an argument.

Plus they are microbenchmarks (which he also mentions).

Notice how I linked to the web benchmarks too? Your complaint was addressed in the post you are complaining about.

topviz2• 12 years ago

Haskell is beautiful and mind-bending, but to get close to C in any non-trivial problem, you will end up writing imperative code. We have 4 implementations of a graph algorithm:

a) Idiomatic Haskell takes ~25 minutes

b) Monadic Haskell takes 11 seconds

c) C++ takes 3 seconds

d) C takes 1 seconds (5x less memory than b))

If you look at all the micro-benchmarks, C uses far less memory than Java or Haskell and the memory is the bottleneck in the most cases.

This is the reason why HPC is FORTRAN, C and C++.

Reference: Computational Topology via Functional Programming: A Baseline Analysis

codygman16• 12 years ago

2 Things.

1. I don't think Monadic == Imperative...

2. Can you post the Haskell code?

imanaccount24722• 12 years ago

but to get close to C in any non-trivial problem, you will end up writing imperative code.

I know that's not true because I do it on a regular basis. For problems that require writing imperative code you end up writing imperative code. This is not a problem, writing imperative code in haskell is far nice than writing it in C.

Monadic Haskell takes 11 seconds

"Monadic Haskell" is meaningless when making performance claims. If you want help fixing your code, you need to post it. And idiomatic haskell uses monads all the time. Is this another case of the common "I am pretending that deliberately doing things the slowest way possible is the definition of idiomatic" trolling?

C takes 1 seconds

If your C++ is taking 3x as long as your C you are doing something wrong.

pjmlp7• 12 years ago

When people compare C with other languages, what they are actually comparing are optimizing implementations of native code compilers for C with 30 years of effort against implementations of other languages. Not always choosing the best ones.

Specially the fact that C is fast because of 30 years of compiler research, tends to the ignored by C zealots.

Lets not forget that 30 years ago C compilers used to suck really bad, and most of us that were coding back then were using Assembly for real men work.

C, Pascal dialects, Modula-2, Algol dialects, PL/I and many other candidates to systems programming were all equally bad in code quality.

But of course, C guys like that new generations think that C was the first systems programming language and its compilers always produced fast code.

marktangotango• 12 years ago

Ànd assembler was once an innovation as well. I read a quote by Richard Hamming once, he stated "automatic programming" as it was called, would be a great productivety booster.

mrcslws• 12 years ago

One nitpick:

That some of the most heavily used and reliable software in the world is built on C is proof that the flaws are overblown, and easy to detect and fix.

Easy to detect? Multiple times per year we find out about a security bug in Linux or Windows that has existed since the 90s.

TwoBit2• 12 years ago

C is not the fastest language. C++ is faster than C. For example, the only way you can hope to match C++ inline template algorithms in C is with a horrific macro scheme.

sharpneli2• 12 years ago

http://benchmarksgame.alioth.debian.org/u64q/c.php

Gives the indication that C++ is faster in practice only when your algorithms are so complex that writing them in C starts to become tedious.

And frankly C++ can never match C until they introduce restrict. Only with C99 C was able to match Fortran. C++ does not have that luxury yet.

TwoBit2• 12 years ago

What you say about restrict is hard to consider because every C++ compiler supports restrict.

Also, I frequently see those types of algorithms that benefit C++. It's not just an STL thing.

danenania3• 12 years ago

What's a good practical way to get my feet wet with C? I want to learn it, but I'm the sort of person that can only learn a language by actually trying to build something useful in it. Sometimes it seems like a language that everyone thinks is important to know, but that no one thinks should actually be used in a real world project unless you're working on embedded systems or building an OS. What are some ideal (and beginner-friendly) use cases?

rubiquity2• 12 years ago

A lot of people tend to recommend Zed Shaw's "Learn C The Hard Way"[0] but I would love to hear what others have to say.

0 - http://c.learncodethehardway.org/book/

danenania3• 12 years ago

Thanks, I'm actually going through Learn C The Hard Way now, but it's the sort of thing that doesn't really work for me. I just need to work on some cool little app idea that C is well suited for and learn/bang my head against the wall until I figure it out. The problem is that I can't seem to come up with anything small and practical to build that anyone actually thinks should be done in C. It's like there are beginner tutorials on one end, linux kernel hacking/database internals/NASA robots on the other end, and nothing in the middle. My experience with other languages and areas of interest are fairly wide, so it seems like I should be able to come up with something, but I'm feeling sort of at a loss.

angersock3• 12 years ago

Go download SDL 2.0 and build a simple breakout game, or space invaders, or something. Add networking support.

You won't get to hide from the annoying stuff in C (memory allocation, string manipulation, etc.), but the problem space (a simple game) is right there. It's also something that many, many people have done before, so it'll be easy to start.

danenania3• 12 years ago

Thanks, I really like the simple game idea, and SDL looks like a cool framework. Also neat that it can compile to ios/android-compatible binary (though perhaps that would introduce a new can of worms).

plow• 12 years ago

It’s as if people make asymptotic progress towards the goal of the ‘ultimate programming language’, the newer innovations which may well have improvements are too marginal to be beneficial, there is too much existing inertia, that is why the more prominent modern ones incorporate interoperability with C often. It would seem more sensible to say as the author of this post seems to propose, that C is the de facto ultimate.

otikik• 12 years ago

Remember that where there's C, there can be Lua.

Just saying.

SCdF• 12 years ago

There is currently a really cool project I suggest (if you're interested in learning / seeing C in action) called Handmade Hero[1].

He[2] is making a game, from scratch, in (mostly) C (but with a little bit of C++ niceties thrown in), and streaming[3] the entire process for an hourish, Monday -> Friday. It's intended to be a tutorial in both learning C and learning from-scratch game development (where from scratch means using GDI and like, parsing your own wav files).

It's really cool to watch, he's an entertaining guy, afaict is a pretty decent teacher (I know zero C, but C-style languages, and I _think_ I'm keeping up), so I recommend checking it out.

[1] http://handmadehero.org/ [2] https://twitter.com/cmuratori [3] http://www.twitch.tv/handmade_hero

benwaffle2• 12 years ago

unfortunately, he uses windows he said he will show how to do this on linux later

zellyn• 12 years ago

Check out http://davidgow.net/handmadepenguin/default.html

blt• 12 years ago

C was built as a replacement for assembly programming. It seems low-level today but it does a huge amount of work for you. Call stack manipulation, computing offsets for nested struct members, converting arbitrarily complex conditionals into the right branching instructions, coalescing a sequence of expressively named intermediate values into the same machine register... these are the things C does for you. I've never written a serious assembly program but I can imagine how annoying it is to do all that stuff manually. It would be easy to screw up.

I think C has been so successful because it made really good decisions about what to do for you. It eliminated a lot of those busy-work programming tasks without taking away your fundamental control of the machine. Automatic array bounds checking, garbage collection, ... they would have been unthinkable for the original goals of C. The stupid warts are annoying but I think C made fundamentally sound choices of what to do automatically and what to leave up to the programmer.

We all talk about modular, abstract code, but back in the day "modular" meant "use the same calling convention for every int(int, int) function", not "dependency injection". From that perspective, C must have felt like a huge leap in modularity and abstraction from assembler.

facorreia• 12 years ago

C is the fastest language out there.

I thought it was Fortran.

codygman16• 12 years ago

Fortran is fastest for matrix manipulation and other maths stuff IIRC.

Aldo_MX2• 12 years ago

Every time I see someone praising C I curse Microsoft for not having proper support for C99 in Visual Studio.

AlexeyBrin2• 12 years ago

Visual Studio 2013 has better support for C99, here is an article from MSDN about it http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar... . But it is not a complete C99 implementation.

The good news is that with VS 2015 you will be able to use Clang for compiling C code, so hopefully a complete C99/C11 implementation on Windows at some point.

pjmlp7• 12 years ago

Microsoft reiterated at Connect 2014 that only the parts required by the C++ standard are to be included, as well as, smaller parts required by well known FOSS projects that they see value in supporting on Windows.

Clang support is only planned as compile target for Android and eventually iOS.

Check going native videos from Connect.

fithisux4• 12 years ago

Use pellesC, it supports C11 and claim to be compatible with VS.

pjmlp7• 12 years ago

The product is called Visual C++, not Visual C.

I praise Microsoft for leading the way to eradicate C from our computers.

Animats• 12 years ago

Some of the unhappiness stems from C++, which was supposed to "fix C". Instead, it created a big mess. C++ is the only major language to support hiding ("abstraction") without memory safety. This turned out to be a poor feature combination, never again repeated. C has neither hiding nor memory safety, so if it's broken, at least it's visible at the user program level. Java/Pascal/Modula/Ada/Common LISP/Go/Rust, and the interpretive "scripting languages", all have both hiding and memory safety. We've at least come to an agreement on that feature set.

Because of the existence of C++, mainstream C language development more or less stopped. ANSI C, ISO C, C99, and C11 don't differ by much.

(At one time, I was promoting an approach to make C memory-safe in a way that allowed mixing safe and unsafe modules to allow a gradual transition and rewriting of old code. See (http://animats.com/papers/languages/safearraysforc43.pdf). It's technically feasible but politically hopeless. I'm now pinning my hopes on Rust and hoping they don't screw up.)

demarq• 12 years ago

call us when the honeymoon is over.

fithisux4• 12 years ago

In this thread I saw no mention of Freebasic. It has some good features and is comparable to C. TerraLang is another interesting approach (for system programming languages).

But the fundamental flaw is that in many cases a DSl that compiles to something lower level is the way to Go.

yason2• 12 years ago

The reason I love C——I wouldn't like to love it but I am dragged down back to C each time so I think I've just given up——is that it costs a bit more to write.

I used to prototype things with Python by the method of sheer experimentation. When I found a suitable design, I'd rewrite it "properly" in Python and if that wasn't fast enough I'd think a bit and rewrite it in C. But that's happening less and less often these days.

Because C costs a bit more to write it makes me think ahead. And I've (once again) found that while prototyping in Python is fast it's even faster to think and then just write C. I write some boilerplate C and start adding the data structures... this could take a "long" time but once I've figured it out, writing the actual C code is a breeze. All the mental work has already been done and once the data structures are right, the implementation just follows.

Curiously, this doesn't exactly happen with Python. Because you can make a Python program run almost immediately, there's nothing forcing you to the productive idleness. In C, you'll have to write a bit of code first until you can get something meaningful up and running: this is the hatching time for what you really want to write.

I'm not sure why I haven't observed this with other languages. I suppose I would need to write hefty amounts of Java until I could get a program running somewhat, but this process of forced productive idleness mostly happens in C. Maybe it's because there are no layer beneath C and assembly and you intuitively know the tradeoffs and only a negligible delta of what you write and what the machine will actually do. Maybe it's because C feels so physical. I don't know. But so far C is the only language that gives me that process in a native, intuitive way, constantly telling me that "you must not rush, because you can't rush anyway".

lmm5• 12 years ago

Have you ever used a modern strongly typed functional language, e.g. OCaml or Haskell?

yason2• 12 years ago

Yes.

The Unreasonable Effectiveness of C (2013)

Related Stories