Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deconstructing K&R C Is Dead (2015)

c.learncodethehardway.org

Post reply on HN
Print view View original

171–180 of 190 posts

Re: Deconstructing K&R C Is Dead (2015)

#171

Post by dikaiosune »

DLA wrote: post #23

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…

> 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.

Re: Deconstructing K&R C Is Dead (2015)

#172

Post by smitherfield »

barbs wrote: post #110
ktRolster wrote: post #109

Earlier quoted context omitted.

>Has he at least mellowed out since 2007? Yes

Not by much though. https://zedshaw.com/2015/06/01/dear-paul/

I know I really shouldn't be picking on the mentally ill, but the thought processes of extreme narcissists are honestly more alien to me than those of schizophrenics, who at least react in an understandable way to being told by God that what we call "reality" is actually an illusion.

Whereas the guy we're discussing seems to actually think that Paul Graham, billionaire, wakes up every morning thinking "how, today, can I enable the vicious internet slander campaign against Zed Shaw? (I am so intimidated by his genius)."

  What would happen if I decided to pay you back for HN Paul?
  What would happen if I started honestly reviewing your startups’ products?
  If I just picked the worst ones, and then started tearing them in half?
  What would happen if I went on every HN hiring post and started
  posting dirt about the various shit HR practices your companies have?
  What if I took all this writing and got my friends
  you’ve fucked over to help me broadcast it?
  What if I started posting this writing as replies to many of your comments?
  What if I started offering to advise new coders, the millions I teach a year
  (yes, millions Paul) to avoid all of your company’s startups?
  What would happen if I just started putting anti-YC ads on my properties?
  What if I started telling everyone how you take
  7% and don’t give startups any real guidance?
  What would happen if I started talking about the crazy bullshit I know
  has happened at YC startups I’ve worked for and others have told me about?
Er… nothing?

Re: Deconstructing K&R C Is Dead (2015)

#173

Post by dang »

lkrubner wrote: post #162
dang wrote: post #104

Earlier quoted context omitted.

I don't think bringing out a list of generically outrageous things someone said in the past rises to the level of discourse we're trying for here. We detached this subthread from https://news.ycombinator.com/item?id=11727718 and marked it off-topic.

The man has a long history of writing angry rants. You don't think that would influence how people might read his current rant? You don't think the readers of Hacker News might like to know about his past history of similar behavior? You don't think it helps interpret the level of anger in his current rant?

I do think all those things. But the cost of moving in the direction of personal vendettas or witch hunts is higher than the benefits you listed (if benefits they are).

I don't mean that's what you intended, but that's the direction it points in, which it isn't in the long-term interests of HN to allow.

Re: Deconstructing K&R C Is Dead (2015)

#174

Post by dikaiosune »

dig1 wrote: post #145
blub wrote: post #94

Earlier quoted context omitted.

I wouldn't say that C is easy to master, but it's not very difficult either. The problem with C is that even a C master can't necessarily write correct code, because C is a very programmer-unfriendly language, making developers remember to do various actions manually and perform error-prone calculations. C++ is definitely harder to master (after many years, I can't say I master every corner of the language), but it's…

> C lost this battle a long time ago... The number of domains where one must use C is shrinking I doubt that. Kernels, drivers, embedded devices (not IoT), GNU world, are all highly C oriented. Want to develop for a customer with unknown unix variant? Want to develop a tool everyone are going to use, either on Linux/BSD/Solaris? C is the only option. > but it's much easier to write correct code in C++ and it will be…

Rust can piggyback on almost any C tooling (emits DWARF debug info), and has very strong C interoperability, if C can talk to it, rust probably can too.

Re: Deconstructing K&R C Is Dead (2015)

#175

Post by Manishearth »

DLA wrote: post #23

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…

> 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.

Re: Deconstructing K&R C Is Dead (2015)

#176

Post by courtf »

Manishearth wrote: post #175
DLA wrote: post #23

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…

> 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 e…

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

Re: Deconstructing K&R C Is Dead (2015)

#177

Post by Manishearth »

wahern wrote: post #124
dbaupp wrote: post #117

Earlier quoted context omitted.

> There's a reason languages like Rust and Go rely heavily on static linking and stack allocation This is untrue: Rust certainly does not do any optimisations linking statically by default, nor is there a difference between putting an array on the stack or on the heap. While it is true that code can benefit from whole-program optimisation, it isn't the default in either language, just like it isn't the default in C.

Languages which bake in automatic bounds checking at every access rely on optimization to recover the performance hit. Without static linking, automatic GC, and other constructs that's very difficult. LTO notwithstanding, once you add those more sophisticated constructs, iterating the language becomes more difficult. You don't hit upon the best method for implementing various types the first time, or the second time,…

> Try using Rust without boxing, for example, as is necessary if you want to catch OOM.

It's not necessary, you can plug in a custom allocator that works differently and use boxing as usual.

There are plans for more robust custom allocator APIs that make this even easier to handle.

Also, really, even if Rust didn't have this, the situation wouldn't be worse than C. In C you have to malloc and free things manually. In Rust you can do that too. Rust's abort-on-OOM is an stdlib thing (which can be overridden as previously mentioned).

Re: Deconstructing K&R C Is Dead (2015)

#178

Post by Manishearth »

caconym_ wrote: post #57
pcwalton wrote: post #35

Earlier quoted context omitted.

What in particular makes Rust (or Go or Swift) unsuitable?

Doesn't the design of Go, the language, basically require that the implementation involve a runtime with a GC system? So that would make it a non-viable choice for programming in applications where memory footprint and real-time performance must be tightly controlled. Rust is a better choice, and it's designed with this in mind. It's still young, though, and I think there might be some as-yet-unsolved issues (these a…

Rusts binary size issues are just a matter of defaults, and they're an additive bloat, not multiplicative (If the corresponding rust binary for a 5kb C binary is 200kb, then the corresponding rust binary for a 100kb C binary is 305kb). Most people don't care about a few extra kilobytes in their binary, so Rust has chosen defaults that make some things easier but also add some extra binary size. You can turn these off and get tiny binaries if you wish without much effort.

Re: Deconstructing K&R C Is Dead (2015)

#179

Post by Manishearth »

kinkdr wrote: post #81
tomjakubowski wrote: post #64

Earlier quoted context omitted.

Calling C from Rust is very convenient. All you have to do is declare the structs and function signatures and then it's like calling any other unsafe function.

IMHO it is OK if you are only going to call a few simple one, but for calling a few hundred complex ones (callbacks with variable argument list, etc..), it becomes a bit cumbersome. BTW I am not implying that is Rust's fault, actually I can't think a syntax that would make it less verbose, and I am a huge Rust fan.

Not really, there are tools that can take C header files and spit out bindings. Rust also supports vararg C functions even though Rust itself doesn't support varargs. Writing safe Rust wrappers around these unsafe C bindings can sometimes be tedious, but this isn't worse than using C directly (which is inherently unsafe).

Re: Deconstructing K&R C Is Dead (2015)

#180

Post by Manishearth »

DonFromWyoming wrote: post #163
steveklabnik wrote: post #50

Earlier quoted context omitted.

You don't describe why you think it's a joke.

Steve - did you read the FAQ? They really don't know what direction to go. At least Swift stuck with ARC, being a necessity as they were tasked with merging Swift with the Objective-C runtime for interoperability. Rust's multiple methods of memory management makes it strange, at best, for programmers to decide how to build a program or an API. Are the owners of Rust planning on adding a GC? Really?

Steve wrote the FAQ and most of the docs
Post reply on HN