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

Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

cl.cam.ac.uk

Post reply on HN
Print view View original

21–30 of 253 posts

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#21

Post by jstewartmobile »

bluejekyll wrote: post #12
quickben wrote: post #9

Earlier quoted context omitted.

You are ignoring the fact that many problems can't be solved in the higher level languages. Also, for some, having the c/c++ level of control is prefered.

This doesn't have to be zero sum. We don't need to choose between safe and unsafe. Safety should be a default, with unsafety being something you opt into. C/C++ are both unsafe. Rust is safe by default, and for the cases where you want/need the C/C++ level of access to the system, you can opt into unsafe. I believe Rust is more safe than Go and Java as well, because of the type safety in the threading model. There ar…

Notice that "scoff at" turned to "frown upon" here, but same difference.

I like Rust, but the kind of attitude you've shown in this comment is a) distressingly common among Rustaceans, and b) makes everyone in the embedded world who would like to get away from C/C++ keep the whole Rust ecosystem at arms-length.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#22

Post by dig1 »

pcwalton wrote: post #7

This is another article overanalyzing the success of C, when in fact the reason for the success of C is very simple and obvious: Unix was free and in a lucky position in 1973; Unix got popular; C is the language of Unix; therefore C got popular. There is no inherent benefit in C that, for example, a somewhat modified version of Pascal or Algol wouldn't have inherited. And these kinds of articles always ignore the fac…

> Switching to a new compiler is a very high burden for a lot of projects ... By contrast, switching to a new language ... is also a very high burden, but the benefits are larger

I guess switching to a new compiler (or newer version of the same vendor) is much less burden than switching to the new language.

Don't forget that all "new safe languages" are simply new. Why people like C is familiarity: known practices and known issues to avoid ironed out through 30 years of usage.

Although Rust/JavaScript/your-favorite-new-language brings on table fixes for known C issues, they introduces many unknown things. Remember Java? It promised compile-once/run-everywhere, automatic memory management approach, but introduced bloat, extremely hard to catch GC leaks no one talks about, JVM implementation differences (Oracle JVM vs IBM JVM vs OpenJDK speed) and JVM security issues only few can fix.

> why safer versions of C have repeatedly failed over the years

I guess this will be like giving to skilled hunter a toy water gun - simply a different mindset. Imagine unsafe python with pointers and mallocs; how python devs would deal with it?

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#23

Post by AnimalMuppet »

pcwalton wrote: post #7

This is another article overanalyzing the success of C, when in fact the reason for the success of C is very simple and obvious: Unix was free and in a lucky position in 1973; Unix got popular; C is the language of Unix; therefore C got popular. There is no inherent benefit in C that, for example, a somewhat modified version of Pascal or Algol wouldn't have inherited. And these kinds of articles always ignore the fac…

I've used both C and Pascal in embedded systems. Pascal is painful compared to C. A "somewhat modified" version might help, but I doubt it would be enough. To steal a phrase from my friend Michael Pavlinch: Pascal was like picking your nose with boxing gloves on. A modified boxing glove isn't really going to solve the problem.

For that matter, once we weren't on Unix but rather on the PC, and we had a nicely-modified Pascal (Turbo Pascal), why did C/C++ win there, too?

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#24

Post by pcwalton »

chubot wrote: post #19

Related: "Safe Systems Software and the Future of Computing by Joe Duffy" at RustConf 2017. https://www.youtube.com/watch?v=CuD7SCqHB7k I summarized this excellent talk here [1], but one of the main points is that compatibility with existing systems is important for adoption. (They learned that the hard way -- by having their entire project cancelled and almost everything thrown out.) He advocates unit-by-unit rewrit…

> My sense is that Rust may not have thought enough about compatibility early in its life. Only later when they ran into adoption problems did they start talking more about compatibility.

Of course Rust thought a lot about compatibility with C in its early days. I remember fast FFI was in Graydon's very first presentation about the language in 2010. Almost everything about the language changed, but that focus did not.

> Also, it seems Rust competes more with C++ than C, and there seems to be very little attempt to be compatible with C++ (although perhaps that problem is intractable.)

Rust has gone pretty far in wanting to be compatible with C++, with the C++ stuff added to bindgen for Stylo. We've gone further than most other languages. It's not fair to say there's been "very little attempt": we literally couldn't have shipped Stylo to Nightly Firefox without doing the work to bridge C++ and Rust.

From your other post, it seems that one of your main complaints is that Cargo exists instead of having Rust use Makefiles. All I can say is that the reaction to Cargo from Rust programmers is overwhelmingly, almost universally positive, and abandoning Cargo in favor of Makefiles would instantly result in a fork of the language that would take Rust's entire userbase. Not solving builds and package management is not a realistic option for a language in 2017.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#25

Post by mannykannot »

AnimalMuppet wrote: post #10

Here's a good quote: "Unless we can understand the real reasons programmers continue to use C, we risk researchers continuing to solve a set of problems that is incomplete and/or irrelevant, while practitioners continue to use flawed tools." In other words, stop blithely claiming that everyone is stupid for using C/C++. Instead, find out why they use it . Then, if you continue to think that C/C++ needs to be replaced…

C is frequently praised (including in some of the posts here) for its suitability for real-time and embedded systems development, but the author appears to be proposing modifying the C runtime and code generation in ways that, when done in other languages, are claimed to render them unsuitable for these purposes.

I think researchers are justified in looking for solutions for common problems, even if many C programmers will be uninterested in them, so I will not reject his proposals peremptorily.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#26

Post by Const-me »

bluejekyll wrote: post #16
gens wrote: post #14

Earlier quoted context omitted.

I don't like to be told what programming language i should use. You can scoff all you want, but i will be using C for most of my projects.

I don't "tell" people, what language to use. But I do encourage them to look at new languages, especially ones that fit in the same place as one that they like. I love C. It was my first programming language. I love the syntax, I love the semantics. Years ago, I left it though, because I could deliver higher quality applications with fewer unknown bugs with Java, but I always wanted to find a reason to go back to C.…

When I checked out Rust a year ago, I immediately discovered it has no SIMD (SSE, AVX, Neon). That it has no sane ways to implement a graph structure. Also that it’s hard to compose data structures into higher-level specialized ones.

Also, I highly encourage people who worry about pointer management all the time to checkout modern C++.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#27

Post by pcwalton »

dig1 wrote: post #22
pcwalton wrote: post #7

This is another article overanalyzing the success of C, when in fact the reason for the success of C is very simple and obvious: Unix was free and in a lucky position in 1973; Unix got popular; C is the language of Unix; therefore C got popular. There is no inherent benefit in C that, for example, a somewhat modified version of Pascal or Algol wouldn't have inherited. And these kinds of articles always ignore the fac…

> Switching to a new compiler is a very high burden for a lot of projects ... By contrast, switching to a new language ... is also a very high burden, but the benefits are larger I guess switching to a new compiler (or newer version of the same vendor) is much less burden than switching to the new language. Don't forget that all "new safe languages" are simply new. Why people like C is familiarity: known practices an…

> I guess switching to a new compiler (or newer version of the same vendor) is much less burden than switching to the new language.

If that were true, then Linux distros wouldn't still be using GCC. Switching to a new compiler (like clang) is a huge burden.

Both switching compilers and switching languages are enormously expensive, to be sure. But I think people (especially people in academia) consistently underestimate the cost of switching compilers and overestimate the cost of writing new components in a different language.

> Don't forget that all "new safe languages" are simply new. Why people like C is familiarity: known practices and known issues to avoid ironed out through 30 years of usage.

Most programmers haven't been programming for 30 years. New programmers, by and large, don't even know C anymore.

The problems with C haven't been so much "ironed out" as ignored since C99.

> Remember Java? It promised compile-once/run-everywhere, automatic memory management approach, but introduced bloat, extremely hard to catch GC leaks no one talks about, JVM implementation differences (Oracle JVM vs IBM JVM vs OpenJDK speed) and JVM security issues only few can fix.

You bring up Java as though it were a failure! Java has in fact been beating C++ in total usage for years. If I could point to one thing that was responsible for kickstarting the slow decline of C++ that has continued to this day, Java would be it.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#28

Post by camus2 »

pcwalton wrote: post #7

This is another article overanalyzing the success of C, when in fact the reason for the success of C is very simple and obvious: Unix was free and in a lucky position in 1973; Unix got popular; C is the language of Unix; therefore C got popular. There is no inherent benefit in C that, for example, a somewhat modified version of Pascal or Algol wouldn't have inherited. And these kinds of articles always ignore the fac…

> For better or worse (personally, I think, for the better), they're starting with JavaScript, Python, Ruby, or even PHP.

These higher level languages are still built with C(Python,PHP) or C++(V8 Javascript engine) though, so C is still a language of choice for that task, and writing a library in C allows integration with all these high level languages at very little cost. So there is still incentive for people using higher level language to write C. I mean, PHP is useless if the goal is to share code with Python or Javascript.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#29

Post by bluejekyll »

jstewartmobile wrote: post #21
bluejekyll wrote: post #12

Earlier quoted context omitted.

This doesn't have to be zero sum. We don't need to choose between safe and unsafe. Safety should be a default, with unsafety being something you opt into. C/C++ are both unsafe. Rust is safe by default, and for the cases where you want/need the C/C++ level of access to the system, you can opt into unsafe. I believe Rust is more safe than Go and Java as well, because of the type safety in the threading model. There ar…

Notice that "scoff at" turned to "frown upon" here, but same difference. I like Rust, but the kind of attitude you've shown in this comment is a) distressingly common among Rustaceans, and b) makes everyone in the embedded world who would like to get away from C/C++ keep the whole Rust ecosystem at arms-length.

Scoff: speak to someone or about something in a scornfully derisive or mocking way.

Frown: furrow one's brow in an expression of disapproval, displeasure, or concentration.

Those are definitely not the same thing. Language is deliberate. I'd prefer it if you don't change mine to mean something I do not.

I frown at a lot of things in software I review, then someone explains to me why they decided to do something the way they did, in which case they may convince me that they are correct. In the case of C/C++, you can convince me easily in the embedded space that C is still the best choice, and I'd agree. I wouldn't even debate it, I might personally go try and see if there is an option there, but it's clearly a space that Rust is still getting bootstrapped into.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#30

Post by pcwalton »

Const-me wrote: post #26
bluejekyll wrote: post #16

Earlier quoted context omitted.

I don't "tell" people, what language to use. But I do encourage them to look at new languages, especially ones that fit in the same place as one that they like. I love C. It was my first programming language. I love the syntax, I love the semantics. Years ago, I left it though, because I could deliver higher quality applications with fewer unknown bugs with Java, but I always wanted to find a reason to go back to C.…

When I checked out Rust a year ago, I immediately discovered it has no SIMD (SSE, AVX, Neon). That it has no sane ways to implement a graph structure. Also that it’s hard to compose data structures into higher-level specialized ones. Also, I highly encourage people who worry about pointer management all the time to checkout modern C++.

> That it has no sane ways to implement a graph structure.

Sure it does. I work with graphs in Rust all the time.

They may not be "sane" in your view because they're different from the way you implement them in C++, but I could equally well say that there's no "sane" way to implement a safe owning pointer in C++ (since there's no memory-safe way to do so).

> Also, I highly encourage people who worry about pointer management all the time to checkout modern C++.

Modern C++ has no protection against the most pernicious memory management errors, particularly use-after-free.

Post reply on HN