[DLA]

Oh Zed. Really?

There is nothing wrong with carefully crafted C code for applications were it is the best suited tool. Sure, there are sharp edges. True you can write crappy, security nightmare code.

You do make some good points. I agree Go is fantastic. Rust is coming along as well. However, C still runs the world. That's not changing anytime soon. Not with the explosion of IoT and GPU type devices. And, hello Linux kernel and all the glorious command line tools on nix.

Try using Go or Rust (love both, x2 for Go) to allocate say a hundred GB of memory for some huge/fast in-memory data processing. Let me know how far you get.

Your rant is as polarizing as those who are blind to C's flaws (yes, there are a few). Stop saying "don't write C", that's just childish. Rather, what about "let's write better, less security flaw prone C."

As an engineer, one ought to choose wisely when choosing tools. This means pros and cons and balanced unemotional decision making. Not a holy war against a given tool.

And I am a professional programmer.

Let's do C where C makes sense.

(Edit: fixed typos)

[dikaiosune]

> Try using Go or Rust (love both, x2 for Go) to allocate say a hundred GB of memory for some huge/fast in-memory data processing. Let me know how far you get.

I'm currently working on a couple of bugfixes for a Rust program I wrote last year which regularly allocates north of 500GB of RAM per-node on a cluster. It's wicked fast (regularly matching or beating comparable workloads implemented in C/C++), and Rust's ergonomics and safety guarantees made it very easy to extract much greater amounts of parallelism than the previous C++ version had, while never once having to chase down a bug from memory corruption, data races, or iterator invalidation.

[pcwalton]

> Try using Go or Rust (love both, x2 for Go) to allocate say a hundred GB of memory for some huge/fast in-memory data processing. Let me know how far you get.

Um, what's wrong with that in Rust?

> Rather, what about "let's write better, less security flaw prone C."

We've been trying this for the past 40 years and we've completely failed to stem the constant tide of new game-over security flaws. I think it's time to admit that if we couldn't do it in 40 years, we've failed.

[kibwen]

  > Try using Go or Rust (love both, x2 for Go) to allocate 
  > say a hundred GB of memory for some huge/fast in-memory 
  > data processing.

Why would this be a problem in Rust? It literally doesn't impose any overhead on memory consumption, at least not any that C doesn't (e.g. padding). Dropbox has clusters of machines that manage exabytes of data whose core is written in Rust.

[Manishearth]

> Try using Go or Rust (love both, x2 for Go) to allocate say a hundred GB of memory for some huge/fast in-memory data processing. Let me know how far you get.

There is no fundamental reason why this should be slower or harder in Rust. Rust generally compiles down to more or less the same code C does.

There are reasons why this could be slower in Go, but it really depends on what program you're writing, so it might even just work fine. If you don't hit the GC, for example (and Go gives you ample opportunities to not hit the GC), data processing should be quite fast. But it depends.

I'd love to hear real-world experiences with such systems in Go.

[courtf]

We have a few Go processes with high memory usage. For one in particular, while it's been higher in the past (~150GB), we're sitting at 40-80GB per node right now.

The busiest node traffic-wise had average GC time over the past 20min of 3.4ms every 54.5s. 95th percentile on GC time is 6.82ms.

That node is sitting at 36GB in-use right now, and has allocated (and freed) an additional 661GB over the past 20min.

Can't really speak to how fast this is vs other environments, but it's smooth sailing overall. /shrug

[Manishearth]

That sounds much better than the Java stories I've heard, which makes sense since Go is better at avoiding the heap.

No idea how it compares with others; and not sure if it is representative, but to me that sounds pretty decent.

[vacri]

> Stop saying "don't write C", that's just childish. Rather, what about "let's write better, less security flaw prone C."

A consistent theme throughout the article is that he's actually more interested in teaching people to write C well than fight with pedants. He's not torching his book, he's updating it and removing the contentious chapter. "let's write better, less security flaw prone C." is exactly what he's trying to say - the "don't write C" bit at the end is more about it being a dinosaur than a childish huff, though there is a little of that in that comment.