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

41–50 of 253 posts

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

#41

Post by nly »

AnimalMuppet wrote: post #23
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…

> why did C/C++ win there, too?

Maybe C because of its legacy an ubiquity, and C++ because it was one of the few languages with 1) serious compatibility with C, 2) good featureset, and 3) became an ISO standard

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

#42

Post by wahern »

pcwalton wrote: post #24
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…

Following the logic of the article, Rust has made the exact same mistake every other language has made, which is to conceptualize compatibility with the C ecosystem has merely an issue FFI. Rust is hardly the first language to focus on easy FFI from day 1, but according to the article that's not nearly sufficient. And like most other modern so-called systems language, Rust hasn't gotten around to committing to a stable, exportable ABI. In fact, I think much like Go the general sentiment is that this is largely undesirable, as stable ABIs can cripple evolution of the implementation, especially those that rely on sophisticated type systems.

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

#43

Post by panic »

Is such a safe implementation of C really suitable for systems programming, rather than merely application programming? If we understand system-building as communicativity, then certainly such a system retains communicativity—so long as alien objects can be described to it in a manner sufficient for dispatching the same dynamic checks. If I memory-map a file, say, I can safely access that memory only if the structure and meaning—the bounds and the types, roughly—are described much like those of other in-memory objects. Tools and systems for providing these descriptions are currently lacking—but are a logical extension of the runtime type information already developed in recent work. In the case of file formats, some cases like the ELF example we saw earlier (§5.5) show that the format has already been defined for us, thanks to the manifest layout of objects declared in C.

This is a key point. There are scattered systems for describing the layout of arbitrary binary data—C structs/unions, Erlang binary patterns, ASN.1 Encoding Control Notation, Kaitai Struct[1]—but nothing has really caught on across language boundaries. It's hard not to feel this data format barrier when you're using a C API from another language. We'll need to do something about this barrier if we want a true multi-language system (not just a bunch of awkward C FFIs).

[1] http://kaitai.io/

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

#44

Post by bluejekyll »

jstewartmobile wrote: post #35
bluejekyll wrote: post #29

Earlier quoted context omitted.

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

You wrote "scoff" first before you edited it, that's why gens wrote "You can scoff all you want". From the tone of your comments, I think that's what you're really doing.

hmm... I did not. But ok.

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

#45

Post by Chiba-City »

Low level backward compatibility with portability idioms is great for enduring software assets. Anyone not sweating speed and space between equivalent possible implementations is a different kind of useful software developer with different operative quality criteria and execution risks. Rust will hopefully enjoy a long and boring stable future.

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

#46

Post by flukus »

pcwalton wrote: post #24
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…

> All I can say is that the reaction to Cargo from Rust programmers is overwhelmingly, almost universally positive

You can prove anything when you introduce a sampling bias that large.

> Not solving builds and package management is not a realistic option for a language in 2017.

Package management was solved decades ago, my OS manages the packages and a lean and mean system is the result. The rust solution results in massive binary sizes for simple command line tools. This is fine if there goal is to replace java, but not if they want to replace c.

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

#47

Post by Const-me »

pcwalton wrote: post #30
Const-me wrote: post #26

Earlier quoted context omitted.

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

> They may not be "sane" in your view because they're different from the way you implement them in C++

I saw two kinds of Rust graphs.

One is safe, easy to understand, but slow (e.g. reference counting).

Another one (unsafe Rust) is very hard to implement, thousands lines of code. Also, modern C++ is much safer than unsafe rust.

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

CRT debug heap / MALLOC_CHECK_ / libefence, depending on the platform/compiler

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

#48

Post by ChuckMcM »

jasode wrote: post #5

This is a long paper and the author has 2 main claims: 1) C Language popularity is more to do with cognitive ease of memory addresses as a conceptual model for inspection and change. Author claims memory address mental model overshadows runtime performance . 2) switching to "safe" languages like Java/C#/Rust is not necessary. With no changes/violations to existing C Language specification, a new/different implementat…

Excellent, I think the author would do well to re-frame the question as you have. If nothing else to put it more clearly into the space of provable compilation.

When I transferred into the "Oak" group that later became the "Java" organization, the team I was on was looking at whether or not you could write an OS in Java sort of in spite of its safety rules. This sort of concept has been revisited by Rust with its safe/unsafe modal operation.

What both of those efforts have in common is that determining safety may be impossible at the construct level but provable if you were to exhaustively search all possible outcomes.

What the paper and your comment add to the discussion is the intriguing idea that you could create a 'safe' backend (say the equivalent of the JVM) as a target for a C compiler. And code that could not be compiled would be flagged for later analysis. Much like VHDL can express hardware that cannot by synthesized you might end up with a C compiler that could compile code that could not be executed. I could be fun to spend a bit of time poking around that rabbit hole.

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

#49

Post by chubot »

pcwalton wrote: post #24
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…

Well, just saying it has fast FFI doesn't tell me much. Being able to wrap something like sin() was in Python 1.0, but most applications need more help than that. There have been 5+ popular systems since then trying to make the experience better... it still is barely solved.

That said, I admit I'm more on the pessimistic side. Having touched Go before it's open source release in 2009, I didn't think they thought enough about integration either. I think it was worse than Rust, because you couldn't call Go from C or C++, unless the main program was in Go.

Also their build system isn't used inside Google. And they do nontrivial stuff with signals and threads.

But Go seems to be being adopted. However there is an important distinction: Everybody is rewriting new versions of Google-style servers in the open source world. But all the stuff at Google is still in C++.

So I think nobody ever rewrites old software. They write new versions of similar things, and then hopefully those new things get adopted. But the old thing will probably be around for a long time too.

And to be fair C didn't replace Fortran or Cobol either -- scientific applications still use Fortran and old banks (apparently?) still use Cobol on mainframes.

Maybe that's the most you can expect. But in that case there still does need to be a "plan" for making existing C code like the Linux kernel and OpenSSL safer. I think my issue is that some people apparently think that plan involves Rust when it doesn't. Maybe the core team has never pushed that idea but some other people seem to be under that illusion.

-----

This is a different argument, but a language only needs to "solve" package management if it always assumes it has main(). I was looking for something more humble that you could stick in a file in an existing C or C++ project, e.g. for writing as safe parser.

Also the 5+ different Python + C/C++ solutions now need a Python + Rust analogue. For a language at the Rust layer, there's this O(m*n) problem or strong network effect to deal with.

Actually that was thing I was thinking while reading this PDF -- a lot of it can be boiled down to "C and C++ have network effects". Particularly C++.

Asking Rust to break the network effect is like asking Apple to break the Windows monopoly with Mac OS X. That didn't happen -- they built the new thing iOS, and beat Windows with that. So then the question is if Rust is more like OS X or iOS.

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

#50

Post by ktRolster »

jasode wrote: post #5

This is a long paper and the author has 2 main claims: 1) C Language popularity is more to do with cognitive ease of memory addresses as a conceptual model for inspection and change. Author claims memory address mental model overshadows runtime performance . 2) switching to "safe" languages like Java/C#/Rust is not necessary. With no changes/violations to existing C Language specification, a new/different implementat…

It's not just the mental ease, it's also the physical typing ease (and in some cases, the possibility).

For example, he points out that to connect C to existing parts of the system (which is the OS and OS level tools), all you have to do is call the functions. If you want to call a C library from a Java program, it's a lot more work. Furthermore, C has the capability of understanding Java structures (although it's awkward), but Java has no way of understanding C structures from within the language. There is no way to model a driver I/O port in Java, but in C there is.

The paper is worth thinking about. If you are creating a language, take interoperability between already existing languages into consideration. JNI is ok, but think how much better it could be if it did auto-marshalling of objects!

Post reply on HN