Hacker News Reader

Comment by flashm | Hacker News Reader

Why does anything need to replace C? It's been fine for years and still does exactly what it needs to do.

You're right. It keeps on giving us heartbleed, slammer, sasser, kernel null check eliding holes, and literally thousands upon thousands of other memory exploiting, remote executing, security breaking bugs.

But I'm sure, Real Soon Now(TM), if teams just adopt (best practices / better libraries / better code reviews / better static analysis tools / better testing) all those problems will be solved and C will be a great language to keep using.

After all, saving a few extra CPU cycles is totally worth breaking all SSL encryption and leaking private keys, quite literally putting the security of EVERY SINGLE FUCKING HUMAN WHO HAS EVER TOUCHED THE INTERNET in jeopardy.

So sure, let's just keep using C. It's fine, why change anything amirite?

(Sarcasm aside: In the general case it is not possible for humans to write security-critical code in C. So far the history of the internet has proven me 100% correct.)

Every one of those problems you mentioned occurred in C code, not C++. That might seem like quibbling, but many of those bugs are caused by C memory management bullshit like malloc(that) if (error) goto: free(that), which isn't a problem that C++ has. A scratch reimplementation of OpenSSL in C++ would probably be 1/3rd the lines of code and entirely devoid of both goto and malloc.

And a Rust implementation might be half the code and entirely devoid of classes of bugs that might be in the C++.

Rust's standard library aborts on OOM. That's completely unacceptable. More generally, I find Rust's error handling awkward --- the most common excuse for Rust's OOM handling is "Otherwise, you'd need to cart Result everywhere." Of course. That's why we invented exceptions decades ago.

The designers should have used traditional exceptions instead of trying to create something new --- the designers (just like Go's designers) had to go back and add exception support anyway.

I'd have liked Rust more if it'd focused on memory safety and less on being different for the sake of being different. I want a memory safe, non-GC language with traditional curly brace syntax, traditional types, and exceptional error handling. Modern C++ is a much better approximation of that language than Rust is.

It's definitely very important for some domains, but handling OOM "properly" is a really vague/impossible concept for most non-bare-metal programming. Modern operating systems will over-allocate/over-commit memory via virtual memory (so malloc usually succeeds), and kill programs when the physical memory limit is reached, and/or just grind to a halt by swapping.

For instance, I can happily "allocate" 100 terabytes of memory on my laptop (16 GB of RAM, 16 of swap):

  use std::{thread, time};

  fn main() {
      let _v: Vec<Vec<u8>> =
          (0..100_000)
          .map(|_| Vec::with_capacity(1 << 30)) // 1GB each
          .collect();

      thread::sleep(time::Duration::from_secs(10));
  }

Of course, if I actually tried to use much of it, bad things would happen, but the point is the allocations themselves never failed.

Bare-metal programming, like a kernel, will typically use the lower-level `core` part of the standard library, rather than the whole thing (i.e. `std`) because the kernel will be literally providing the interfaces required for most of std-minus-core.

(I think it would be really great if the standard library could be less harsh when an OOM is actually detected, and I suspect it can be tuned in future, but it's not a show-stopper for most tasks.)

> handling OOM "properly" is a really vague/impossible concept for most non-bare-metal programming

I strongly disagree. Handling memory allocation failure is trivial: throw an exception. It's also trivial to reserve enough memory to throw an exception. I honestly don't understand people who claim that recovering from OOM is futile because you need to almost always allocate memory to recover: in fact, you almost never do.

> Modern operating systems will over-allocate/over-commit memory

Windows is a very modern operating system and does not overcommit. (To its credit: overcommit is a terrible idea.) Even on overcommit systems, you can exhaust your address space and see allocation failures. No, 64 bits is not actually infinity. No, the whole world is not 64 bit. (Not every program even benefits from being 64 bit --- that's why the x32 ABI exists.)

> point is the allocations themselves never failed.

The resource you're allocating is address space. When you run out of this resource, your allocations will fail. On overcommit systems, you don't allocate commit charge until you access the memory. It's very difficult to explain to people who work exclusively on overcommit systems that "memory" isn't a single resource, but a set of related ones, each of which can be exhausted.

> I think it would be really great if the standard library could be less harsh when an OOM is actually detected

The only reasonable thing to do on OOM failure is throw an exception, like Java and C++ do. Error codes are too cumbersome even if you dress them up and call them "monads" --- a lot of code allocates, so if you used error codes to indicate OOM, you'd have to manually propagate exceptions from almost everywhere) and just panicking or aborting is too brittle, since you can, in fact, successfully recover from allocation failure, persistent folk myths aside.

Now Rust has both Result _and_ panic/catch_panic, which I think is both sad and hilarious, as it's going to lead to decades of confusion over which error reporting mechanism to use in a particular situation. (The Go designers made exactly the same mistake, as did the designers of the old java.io.File interface.)

It's a shame for such a young language to have that kind of baggage already. If Rust's designers hadn't been so stridently anti-exception in the first place, we'd have ended up with a much better language.

  > Now Rust has both Result _and_ panic/catch_panic

The forthcoming facilities for "catching" panics are deliberately hobbled so as to prevent them from being suitable for use as a general-purpose error-handling mechanism. What they're for is fault isolation, most specifically for preventing code from unwinding across a FFI boundary (which would result in undefined behavior).

catch_panic doesn't look particularly hobbled to me. Besides, I can insert an "FFI" boundary between any two parts of the program I want, and nothing can stop me. But it's moot: I'm not keen on using a language designed by people who are opposed in principle to exceptions, the cleanest form of error handling around.

You can read the comments on the original RFC for stabilizing catch support and see that the majority of them revolve around various ways of deliberately handicapping the API: https://github.com/rust-lang/rfcs/pull/1236

It even inspired a followup RFC for the purpose of codifying these restrictions in a brand-new fundamental trait: https://github.com/rust-lang/rfcs/pull/1323

Yes, but it's still progress toward the inevitable end result of traditional C++-style exceptions. That's the inevitable end state because the traditional exception model is simply the best one.

  > the inevitable

It's not inevitable in the slightest. Rust made a conscious effort to avoid exceptions for good reasons, and there's no reason to suspect that Rust will suddenly pivot on its heel in the opposite direction. Despite your attempts to paint this as a slippery slope, the unwinding-halting mechanisms are there to provide a safety net for people writing Rust libraries that expose C ABIs so that library code can fail gracefully without taking down the parent process.

  > the traditional exception model is simply the best one

Citation needed. :P The Rust community has long since embraced Result-based error handling; I don't hear calls for adding exceptions nearly as often as you seem to suspect. As to "inevitability", you'll be sad to learn that Rust plans on adding a mechanism that will enable applications to make panics impossible to catch, by disabling unwinding entirely and translating all panics to outright aborts (some argue that this should even be the default behavior of Rust code, but that won't happen any time soon). And considering that Mozilla disables exceptions entirely in Firefox, I see no reason they would pressure the Rust developers to add exceptions to Rust.

You seem to be taking Rust's approach to error handling far too personally. :P It is not Rust's position that exceptions are a blight that must be scoured from the face of the Earth. It is merely Rust's position that there are easier ways to achieve concise and composable error handling for its intended domain, given Rust's other features and safety mechanisms.

> Despite your attempts to paint this as a slippery slope

It is, though. I'm not[1][2] the only one who very much prefers the exceptional model of error handling. Once the ability to catch exceptions exists, people like me are going to write exceptional code.

[1] https://github.com/rust-lang/rfcs/pull/1236#issuecomment-127... [2] https://github.com/rust-lang/rfcs/pull/1236#issuecomment-128...

> > the traditional exception model is simply the best one

> Citation needed. :P

When Java, Python, C++, and Common Lisp all converge on the same thing, maybe that thing has something going for it. Part of my claim is subjective, but I've worked on systems that used everything from abort to error codes to tagged unions to exceptions for error reporting, and I've found the exceptional code by far the easiest to work with.

In exceptional code, I can write foo().bar().qux() even though foo, bar, and qux can all fail, and without any extra syntactic noise.

> by disabling unwinding entirely and translating all panics to outright aborts

I believe that's a mistake: it's a reprise of the -fno-exceptions debacle of the C++ world, where the ecosystem is fragmented due to fundamental disagreements on the correct error handling strategy. You'll get into a situation where some components rely on panics being hard aborts for correctness and other components rely on non-aborting panics for error handling.

> And considering that Mozilla disables exceptions entirely in Firefox, I see no reason they would pressure the Rust developers to add exceptions to Rust.

Rust is probably a fine Servo implementation language. Tellingly, Mozilla also uses an infallible memory allocator. I merely believe that Rust's design choices for allocation failure and error handling lead to it being a losing contender when compared to modern C++ for general-purpose systems programming.

  > Once the ability to catch exceptions exists, people like 
  > me are going to write exceptional code.

By all means, go ahead. :) Application code is free to do whatever it wants, and godspeed to you. Meanwhile, the restrictions on the catch API will be sufficiently onerous that library authors will continue to favor Result-based error-handling for their public APIs (to say nothing of the fact that some of their users may have opted to turn panics into aborts).

  > You'll get into a situation where some components rely on panics 
  > being hard aborts for correctness and other components rely on 
  > non-aborting panics for error handling.

Indeed, this is precisely why Rust decided to ship 1.0 with unwinding enabled by default, much to the consternation of those who wished unwinding to be excised from the language entirely. The language is defined such that if your personal `unsafe` blocks fail to consider exception safety, you run the risk of undefined behavior and thereby forfeit Rust's guaranteed safety mechanisms: http://doc.rust-lang.org/nightly/nomicon/exception-safety.ht... . Meanwhile, the fact that catching unwinding is all but unusable as anything other than a failsafe of last resort (and even then is only intended to prevent a total abort and/or undefined behavior) means that no library is going to resort to non-aborting panics for error handling, as mentioned previously.

> library authors will continue to favor Result-based error-handling for their public APIs

Except for the library authors who opt to write in C++ instead, of course. If you have to deliberately make a feature of your environment difficult to use, you're optimizing for the wrong thing. The Java experience shows that bad programmers will write bad code no matter how many safeguards you try to add to the language, so the only worthwhile "speed bumps" are those that help people who know what they're doing not accidentally shoot themselves in the foot. I cannot imagine an exception-catch block appearing in my code by accident.

Quite a bit of the discussion in the threads you mentioned has to do with flagging code as "requiring review" and adding "speed bumps" for "potentially troublesome" code. That's very worrisome, as it indicates that at least some members of the Rust community favor the Java-esque sandbox model of safety over the safety-catch model.

C++ has many flaws, but at least it never makes me feel like the language designers thought I need to be protected from myself.

  > the only worthwhile "speed bumps" are those that help 
  > people who know what they're doing not accidentally 
  > shoot themselves in the foot. I cannot imagine an 
  > exception-catch block appearing in my code by accident.

Rust is very much designed to help people who know what they're doing not shoot themselves in the foot. The risk isn't in a catch block appearing in your program by accident, it's the fact that exception safety is an invisible footgun that has potentially severe implications even for code that doesn't believe that it has any reason to concern itself with error handling in the slightest.

(The irony in all this is that Rust's approach can be interpreted as an attempt to return exceptions to their roots by relegating unwinding to exceptional circumstances, as opposed to the routine error-handling solution that they've become in languages that have chosen to embrace exceptions (e.g. Python's egregious `StopIteration` exception for loop termination).)

> return exceptions to their roots by relegating them to exceptional circumstances

Python does it right. I've never bought the argument that "exceptions are for exceptional circumstances". If you use error codes for some errors and exceptions for others, all you do is confuse people. The definition of "exceptional error" is subjective, after all.

As far as I can tell, the advice to use "exceptions for exceptional circumstances" originated in C++ circles in the 1990s, when support for exceptions was bad and throws were slow. The thinking was that you could efficiently use error codes for commonly-encountered errors and still get some of the syntactic benefits of using exceptions for rarer errors. Also, if you were using a compiler without exceptions support, you could turn your exceptions into aborts while not aborting just because a file doesn't exist. You can see vestiges of this thinking in the iostreams API.

Somehow, this performance hack morphed into commonly-accepted dogma. I don't accept this dogma. Exceptions are for any situation that a function can't meet its contract. In Python, if an iterator can't supply its next element, it can't satisfy the contract, and the exception tells you why. I don't think there's anything particularly wrong with that.

I suppose we'll have to agree to disagree, then. :)

> Handling memory allocation failure is trivial

The problem I'm talking about is allocation failure and OOM are not the same: handling out-of-memory reliably is a lot more than just checking for NULL in `malloc`, as I demonstrated. There's no guarantee that allocations will fail when they "should" and so you'll only learn that you're beyond reasonable limits when you touch enough pages that the operating system starts killing programs (possibly yours, possibly others), or when the user cannot actually use their computer in any reasonable manner.

> Windows is a very modern operating system and does not overcommit

Yeah definitely, it's why I was sure to mention the problems with swapping (sure, the memory is allocated and usable by the program, but in slow motion; not so great if you actually want to use the computer).

> The resource you're allocating is address space. When you run out of this resource, your allocations will fail. On overcommit systems, you don't allocate commit charge until you access the memory.

Yes, running out of virtual memory is one way for allocations to fail, but, as you say, there's a variety of different systems at play here. Only failure in one of those systems (requesting virtual memory/address space) is handled by checking for `malloc` returning NULL, and so focusing on just that is missing the forest for the trees. Presumably the overall goal is to handle memory exhaustion gracefully, not to check the return value of NULL (which is just one part of the former).

That some operating systems lie about resource commitments is no reason not to provide reasonable facilities for reacting to allocation failures. By doing so, you make it harder to write well-behaved programs for systems that don't overcommit --- besides, no system overcommits address space, so malloc can always fail.

It's true that even with reasonable allocation failure reporting on a non-overcommit system, you can use too much memory and make life unpleasant for users without actually seeing allocations fail. Bounding resource use is important regardless. That's an issue of good behavior, however. Even absent good behavior, programs should at least be robust.

One of the reasons overcommit bothers me so much is that infects programming communities with the idea that resource consumption doesn't matter, since if you use too much, you're just going to get a SIGKILL anyway.

If you throw an exception, what would the resulting recovery mode even /be/, aside from clearing out unused memory (never mind that just finding all of your allocations is a nightmare in and of itself)? And how would this actually work in a non GC world where functions can allocate and free at any time -- ie, you are working on a team and can't know the state of every thread, task or chunk of code at once?

> If you throw an exception, what would the resulting recovery mode even /be/

Unwind the stack and present an error message or take other appropriate action, just as we would for any other error. By unwinding the stack, we release owned resources, and some of those resources happen to be memory blocks. What makes memory so special?

> just finding all of your allocations is a nightmare in and of itself

Huh? In a non-GC system, if you can't find your allocations, you're leaking memory.

My point about finding the allocations is actually a bit poorly put: not all parts of your program may be ready to release memory it has held without losing user data in the process.

Memory is special insofar as it is a core resource that has so much contention that OOM situations may not be directly because of your application, and recovery may not even be possible without allocation.

I'm slowly coming to realize my argumentative point is losing ground -- this is great! :-)

You're not supposed to use the stdlib for baremetal programming.

> instead of trying to create something new

monadic error handling isn't new. It's an old feature used by many languages, and preferred by many over exceptions.

> You're not supposed to use the stdlib for baremetal programming.

I don't think it's useful to partition the world into microcontrollers and "LOL, memory is finite?" domains. Allocations can fail for normal programs, particularly when imposing subsystem-specific allocation limits or when running in small, crowded address spaces (e.g., mobile devices). It's often useful to be able to recover from this condition without completely killing the process, since process death is much more annoying for users than a specific task failing. (Wouldn't you rather see a video not play than see your entire program die?)

Rust's libcore wasn't split out for "LOL, memory is finite" domains. It exists so that you can write Rust programs that restrict themselves to doing no dynamic allocation whatsoever, as needed for environments where an allocator simply isn't available or allowed.

My point is that I want to write programs that do use dynamic allocation, but also handle failure of this dynamic allocation in a reasonable way. Right now, Rust's philosophy is that you can choose whether to use dynamic allocation, but if you do, it'd better be an infallible allocator.

On OOM, what should happen other than a hard abort? On most VM systems, malloc and friends oversubscribe what is actually available. What possible recovery mechanism can you implement to prevent this from happening?

> On OOM, what should happen other than a hard abort?

On a web server, 500? On a document editor? "Sorry, couldn't add attachment". What to do in response to error is application-specific. My point is that memory is not special and there is no reason to treat memory errors differently from other errors. You wouldn't abort if you run out of disk space.

> On most VM systems, malloc and friends oversubscribe what is actually available.

Windows is a common non-overcommit OS. Even on overcommit systems, it's possible to exhaust a process's virtual address space. (Overcommit systems also have ulimit -v.) If you do run out of either address space or commit, it's frequently the case that you can just stop what you were doing and display an out-of-memory dialog. The process of "stop what you were doing" can certainly free enough memory to keep going.

http://www.gotw.ca/publications/mill16.htm

So Herb Sutter mostly agrees with your view, but my question is a corollary, and something he touches on: how do you keep going if you stop what you were doing? The process of recovering is not straightforward, and if you have threads running, that process is utter chaos, if not outright impossible in some languages. Even on non overcommit systems, the user finding another way to work around a memory failure is useless because the system is already hosed to the point where a small memory allocation will fail. Either way, the situation is so bad that the user does not have the ability to recover what was just done in your application without closing your application in the first place -- which, incidentally, leaves the user stuck in exactly the same place as if your application aborted.

The big idea here is that the OOM condition may not be because of your application.

> how do you keep going if you stop what you were doing

You unwind. If you have threads, you reliably signal for them to stop (using resources you've set aside for the task), then you join the threads and continue unwinding. I think it's perfectly straightforward.

> Even on non overcommit systems, the user finding another way to work around a memory failure is useless because the system is already hosed to the point where a small memory allocation will fail.

Most serious operating systems have a way to say "run this process in this special environment where it can't allocate more than X MB of memory". (Some examples are NT Job objects, FreeBSD jails, Linux cgroups, and plain old ulimit.) In this kind of environment, you can certainly run up against limits for your process without the system having been rendered unusable.

> because the system is already hosed to the point where a small memory allocation will fail

Absolutely not the case. Imagine a state where a 100MB allocation (e.g., for an image) might fail (say, due to virtual address space fragmentation), but a 10 byte allocation would work just fine. The same principle applies to system commit considered globally instead of virtual address space considered per-process.

> the situation is so bad that the user does not have the ability to recover what was just done in your application without closing your application in the first plac

If that's the case, the application is just badly coded. Memory is not special. It's just another resource. If you can't keep track of resources and release them when they're unneeded (as they would be after an error), you're doing something wrong.

> http://www.gotw.ca/publications/mill16.htm

That article is factually incorrect. Sutter claims that "On...Linux, memory allocation always succeeds. Full stop." That's false, as a ten-line C program that calls malloc in a loop can demonstrate. You eventually run out of address space, especially in a 32-bit process. (There's a very popular overwhelmingly 32-bit Linux distribution out there called Android. You may have heard of it.) Sutter also claims that on other operating systems, overcommit is configurable. It's in fact configurable under Linux too. Linux can run in sane, non-overcommitting mode.

> Every one of those problems you mentioned occurred in C code, not C++

The title of the post talks about C, not C++.

While C++ certainly makes it easier to write safe code, you still need to be quite careful. C arrays, manual memory management, dangling pointers and all kinds of other unsafe constructs lurk behind the thin veneer of modern C++ style.

No way, C++ removed some C problems but just added a whole host of its own problems, that don't exist in C: operator overload hell, static initialization and deinitialization hell. Calling virtual methods in constructors blow up. I programmed C++ for 13 years and must have had rose tinted glasses on. I kept reading books like Effective C++ thinking that my bugs would go away as soon as I learned all the intricacies of C++ and best practices. I realize now that I mostly program in other languages that the enormous amount of knowledge you need when writing C++ safely simply isn't needed in most other mainstream languages.

If you think C++ is the answer to C's problems I think you suffer Stockholm syndrome. You've gotten so used to all the issues in C++ and started thinking about them as normal, so you stop seeing what a mess this language is.

Nobody is going to make you overload operators, do work in constructors, or throw exceptions. Restrict yourself to the subset of C++ that you prefer.

By comparison there is no subset of C that lacks malloc/free.

In practice most of us are restricted to the subsets (note plural) chosen by the people who wrote the original systems we work on.

But then you can't move to another language anyway. If you can move to another language (say if you start a new project), it's worth moving from C++ to C++11.

And a new language is magically going to solve all the problems you mentioned and do everything c can at the same speed?

Not magically, but with a lot of technical effort Rust does solve those problems and at the same speed.

As in a Rust compiler will generate equivalent assembly as C in equivalent cases. With practically for now some places where Rust will win and some where C will win performance wise. But there are no practical reasons for Rust to be slower than C or C++.

Could you rewrite linux kernel in Rust?

Yes. However, writing a linux-like kernel that is not 95% `unsafe` code would be a lot harder than just a straightforward syntax change of C to rust.

Sure, but it probably wouldn't make sense to. Instead, you'd be better off doing like the Redox folks and designing your own Rust-based OS, with plans for a Linux-compatible userspace: http://www.redox-os.org/

C was dog slow in its early days and there were safer systems programming languages available outside the UNIX world that were equally fast.

What has gotten C compilers to generate the code quality that have nowadays is 40 years of work in compiler optimizations targeted to improve C compilers code generation.

I still wouldn't blame the language for the errors its users commit. Its like blaming Java and PHP for XSS and SQL Injections. Unskilled developers will always write insecure code, despite what language they are using.

Edit: To clarify my point, "A fool with a tool is still a fool"

>Unskilled developers will always write insecure code, despite what language they are using.

They - uhh I mean - we won't if it's impossible.

Then explain me how you would make an Language inherently immune to string injections.

You can make a language inherently resistant to string injections. You only need library authors to cooperate and an extension to your string type like Ruby does, to have your language reject thoughtless injection vulnerabilities.

Its possible, but if these solution make an language that secure, why haven't them caught on yet?

Back to my point: Tools can't replace knowledge. A fool with an tool is still a fool.

Are you claiming that unless we erase all security problems, it was all for nothing?

What other language would someone use to write a kernel or driver? Even if you use a higher-level language for most of the logic you'll likely want the core to be C -- amazing considering the language is nearly 40 years old. C is, to me, a systems programming language. Writing code that handles any significant amount of user input in the language is a mistake I believe. Note that this doesn't include C++ which has more modern constructs.

That's Rust: it aims to be a viable replacement for C in bare metal and high performance code including drivers, kernels, embedded and all of those areas where C used to be the only game in town. It should do everything C does, but safely and without performance penalties.

Today Ada, Rust, Spark, C++, ATS.

Eventually Swift, Systems C# (if it ever comes out MSR), D, or any other language.

You might be surprised that NeXTStep used Objective-C for device drivers in the kernel.

That is pretty cool. Shows some of the versatility of Objective-C. I was also surprised that a low level API like Metal also uses Objective-C.

Lua

http://bsd.slashdot.org/story/13/02/16/2329259/netbsd-to-sup...

www.lua.org/wshop13/Cormack.pdf

> After all, saving a few extra CPU cycles is totally worth breaking all SSL encryption and leaking private keys,

I'm afraid that these few CPU cycles do make a difference.

Throughput is the number one concern for thousands of network operators and service providers. They spend millions so you can get your content and not "509 Bandwidth Limit Exceeded".

You can't just go and replace all efficiency critical software by something that runs maybe just 10% slower.

It is 100% possible for humans to write utterly secure code in 'C'. The vast majority of practices which make code not open to memory exploits were common in the 1980s - the late '80s, anyway. Yes, there were virii even then.

Now, is this common? I have no idea. A great deal of 'C' code never sees the larger Internet anyway.

Because a large portion of massive security holes in recent history have been due to archaic C libraries that have security holes a-plenty. A lot of these issues that plague C don't happen in modern languages.

It's 43 years old (times have changed), and while I'm sure C still has its places, I think it's time to come to terms with the fact that people suck at handling memory manually and making sure type conversions are safe & a host of other security risks.

Other, safer languages can accomplish many of the same things C does these days.

Again, I'm not calling for the end of C, but in a lot of situations, it's just asking for it now.

There is a slightly disingenuity here. "a large portion of massive security holes in recent history have been due to archaic libraries that have security holes a-plenty".

The fact they are also C libraries is because that was the only real option of the time when they were written; rather like saying most car accidents were caused by black ones when the only option was a model T.

It is not true.

Before C escaped UNIX there were other systems programming languages available.

The manner in which it escaped Unix was through Microsoft and Borland, and I spent oodles of time evaluating other choices at the time. I could not get the boss to buy Ada, and everything was a compromise. Borland 'C' was super cheap and 100% available, as was Microsoft 'C' before it.

I kind of disagree.

Turbo Pascal and Apple Pascal ruled back then, at least in Europe. On Apple's case it was even the main OS language.

However with UNIX being adopted at work and universities, many wanted to be able to transport their work between home and work/uni. So people started to slowly adopt C.

I followed the same pattern with C++. Eventually Turbo Pascal wasn't no longer an option, so started using Turbo C++, C was just too primitive and unsafe already back then, vs TP.

At least C++ had some of the safety features I was used from TP, as long as one stayed away from C style coding.

Turbo Pascal was common before Turbo 'C' in the US as well. I personally was rather relieved to change from Pascal to 'C'. It's possible that that transition helped me to understand how to use 'C' safely.

With Pascal, I recall having to use more assembler.

I would say that from my vague memories, Turbo C 2.0 wasn't much different from Turbo Pascal 5.x and 6.0.

I had to use Assembly in both cases.

I was writing protocol drivers, and 'C' is better for that.

So don't use those parts of the library. We actually kept a mock-stub library to link against with the Bad Things missing to check before a release at one place. It was actually one object file and I dunno... 150 lines of 'C'?

I despair that "people suck at handling memory manually" :) It's not that hard, folks...

I think this is not a serious question, but I'll bite. We're paying a hefty price for C in the form of buffer overflows, memory leaks, slow development, and other problems and will continue to do so as long as we run software written in C. If we instead switch to a language that doesn't have these problems, then we'll come out better in the long run.

It was slightly tongue in cheek - C is good at what it does, but I agree that there are plenty of good options going forward.

I just don't think C will be 'replaced' across the board though, but I suppose that's obvious.

Of the languages mentioned, I've only got experience with Go (which I use for APIs). Rust looks interesting though, I need to have a proper look at it.

We won't come out "better". We'll have made a trade-off. For some situations, it will have been a trade-off that benefits. For others, it will have been the wrong choice.

Just use the right tool for the job given the circumstances.

These aren't problems of the language. These are a result of having a design choice of full programmer control.

Having automatic cars is convenient and has its uses. But the argument that not using a manual cars will cause less road accidents is misinformed. It looks like that because common sense dictates that as it's easier to drive, more people will drive it easier. But usually the result is that now you have people on road who could not drive a stick!

Some things are meant to be written in lowest level possible. Programming languages are tools and it helps us to have tools for entire spectrum of abstractions. Electronic screwdrivers haven't replaced manual ones in 2 decades. That's not how tools work.

As far as direct comparisons go, these isn't any indication that raising the level of abstraction actually helps with more secure, bug-free code. Compare Java code written (in FOSS setting) with C code written in last 15 years. I bet you'd find C code more secure, more fast, more faster to refactor than a lot of Java code. So if Java was a systems language, would the world be better off if it replaced C? Probably no. Which shows that it's our infatuation with new shiny toys (languages like Go) that's driving our opinion rather than evidence.

C is like running around with scissors in your hand because it allows you to cut paper faster when needed.

Yes, its true but it is also likely to cost your eyes.

Java FOSS code is often faster, more secure, and a lot easier to reason about than equivalent C code. This is not really a language thing but a standard library thing.

The use of char array with a null termination for human readable strings is a terrible 'C' ism. And glibc standard String struct would have saved us all a lot of (security) issues.

The second is a community thing. Java uses defined behaviour to drive optimisation. C tends to use undefined behaviour to drinve optimisatio. The C case really trips programmers up.

Most of these things are not actual technical but more social issues. Computers don't care, it is us humans who do.

> Java FOSS code is often faster, more secure

But uses significantly more memory and requires a VM.

The VM probably is written in C, too.

There are AOT compilers for Java, some of them actually written in Java.

The reference JVM uses a mix of Java and C++, with code being migrated from C++ to Java and replaced with intrisics in each release.

Java 9 will bring Graal/Truffle plugins, which are a JIT compiler framework, written in Java.

> But uses significantly more memory and requires a VM. Do they really use more memory for equivalent code. e.g. Is jetty that much worse than apache? I don't really think so.

Even if the intrinsic memory consumption of a java object is more than one for a C struct that does not mean it will in practice actually use more memory, or that it has too be that way due to unassailable theoretical grounds. See Realtime java for an example.

> The VM probably is written in C, too. Historical reasons only. It could have been fortran or pascal. Its not that C is magical in its low level. There are a whole bunch of other options as well. C was easy to get and it came with the OS for many developers when computers became more accessible due to lower costs in the late 70's and 80's. C is slow is not an uncommon opinion among fortran programmers, for good reasons. In practice the C++ parts of the different JVMs are getting smaller each release. And there have been JVMs that are written in Java with a bootstrap interpreter in ASM. As an OS with just java and assembly. After all, the language is turing complete...

Don't take me wrong Java is not some promised land without issues, its got plenty of those. I am just refuting the idea that just because it written in C it is fast claim.

GCC/XLC/ICC are not magic, neither is HotSpot or Vuze or J9 or any other JVM system.

In many ways C and Java are alike, crap languages introduced in a time when other, better alternatives where available. Only saved by industry adoption and decades of engineering work to make them fly.

Rust is so interesting as it has industry attention and is also academically interesting as bringing something new to the programming world. (at least I am not aware of any pl with the borrow checker concept worked out).

Full programmer control and preventing bugs, security holes and so on are not fundamentally opposed. It's not like most programmers go to work trying to make sure their software has a certain number of buffer overflows in it. It just turns out that preventing that in C is really, really hard.

To take the car analogy further, whether your car is manual or automatic, seat belts and airbags are valuable. Neither of them compromises a driver's full control of their car.

Java isn't exactly a big step up. Compare instead old C code to Haskell or OCaml. I am pretty sure the latter comes out a lot better with respect to serious bugs.

Also I have real world experience with working with the same type of code in two different languages and seeing a clear difference. I've rewritten a lot of Objective-C code to Swift e.g. Objective-C as a language is much like C with similar problems as C. Just doing a straight conversion the Swift compiler picked up a lot of problems from my Objective-C code I had never discovered otherwise.

Lots of other people write about similar experience of getting significant bug reduction from moving to a much more type safe language like Swift.

Actually serious bug detection and prevention is not bad in C either. Most C code uses very well accepted design patterns which is very readable to a seasoned C programmer. Haskell and OCaml are better at easy reasoning of correctness of a program. Serious C bugs are around performance and security, not correctness.

The thing is, what a C programmer would consider a serious bug pertaining to performance and security, would not be fixable by Haskell being a better syntax. Ultimately it's the compiler that would bear the onus. Now generic compilers would always have performance issues and can't make everyone happy. That's the real problem here. It's easy to fix serious bugs (from perspective of systems programmers) in C than to fix them in Haskell. You have no control over compiled code or how it's going to turn out. The so called weirdness of C arises from the fact that non-seasoned C programmer do not understand why a C programmer is doing something. A weird C syntax usually is a signal to the compiler to write instruction code in a certain way.

It's not about correctness that a lot of C programmers are worried about. Well, at least not more than other languages. What we're worried about is what happens when rubber hits the road. It's very hard to do that from the driver's seat. Even Go, which tries to be closer to metal has issues around this. Things like Go, Obj-C, Swift are great where you simply want performance of machine code. But that's not the major argument to use C.

You seem to be talking about a very specific area. As I've eluded to earlier, there are clearly jobs where C is best suited, but C is hardly the best choice in most of the areas it is used. People are still doing GUI programming in C. That is a really poor fit for the language.

C isn't automatically easier to achieve high performance. Depends on what sort of problems we are talking about. If I remember correctly CouchDB was written in C/C++ originally and they switched to Erlang and got both much less code and higher performance.

But in something like a game engine were you want to be able to control memory layout and allocation C/C++ is a benefit. But Rust/Swift/Go allows you to do much of the same to various degrees.

At my work people write codecs and stuff and C is clearly a benefit due to its closeness to the metal. And as you say, yes they do write odd code at times because they know a lot about how the C compiler translates various constructs to assembly code. But this is specialist work. Most C coding doesn't involve this type of coding.

I think I just have to agree to disagree with you about correctness though. I had several years of C experience when I first tried Standard ML, and I manage to get a sorting algorithm correct on first try in SML, something I've never done in C. There will always be some stupid off by one type of error.

People have conducted studies of these sort of things and tend to measure better results for functional languages. One notable property of C programs is also that for any group of C programmers there is a huge variation in performance of the programs they write. The top C developers beat anybody. But average C programs are often slower than even average Python programs.

> Why does anything need to replace C? It's been fine for years and still does exactly what it needs to do.

well, for one the h/w model for one has far progressed beyond what the state of the art was during C's genesis. for example with the advent of multicore machines trying to use C's facilities to exploit available h/w resources becomes quickly unwieldy. witness the rise of event based approaches f.e. libevent and friends, or the rise of lockfree mechanisms etc. etc.

Agree. The unstated conclusion is nothing is close to being a C replacement. A good analysis of the languages anyway.

The endless, eternal, continual stream of catastrophic security flaws in every C program of note begs to differ.

Reply on news.ycombinator.com