Some Were Meant for C: The Endurance of an Unmanageable Language [pdf] • Hacker News Board

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

#61

Post by kahlonel » Wed, Sep 06, 2017, 12:33 AM UTC

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…

Did you even the read the article? How are you comparing JS, Python (or any language "gaining popularity" in your metrics) to C, when the author clearly describes the set of problems only solvable in C?

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

#62

Post by jstelly » Wed, Sep 06, 2017, 12:33 AM UTC

pcwalton wrote: post #39

AnimalMuppet wrote: post #23

Earlier quoted context omitted.

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…

> 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? Turbo Pascal was quite successful in its day. But Microsoft chose C, and the rest is history. Absent Microsoft's decision, Pascal might still be around. If you look at early Mac development, for instance, Pascal was actually preferred. C only ended up winning due to being…

That doesn't agree with my experience. I switched from Turbo Pascal to Turbo C in the late 80s while doing DOS development because it was a better tool for the job. It had nothing to do with microsoft or windows (v3.0 was not yet out and few people developed windows apps before v3.0). Pascal (the language) was definitely not preferred for DOS development at that time - it's just that until 1987 there wasn't really C development environment that could compete with Turbo Pascal.

I did some Amiga development back then also and that was exclusively in C with some 68k assembly. I don't really recall anyone hoping for a pascal environment to replace their C tools, but the Amiga OS was more C-oriented than DOS at the time.

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

#63

Post by pcwalton » Wed, Sep 06, 2017, 12:33 AM UTC

flukus wrote: post #46

pcwalton wrote: post #24

Earlier quoted context omitted.

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

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

I'm confident that programmers don't want to be writing Makefiles. We don't have to take formal surveys to observe the obvious trend away from raw "make" that has been occurring for decades.

Besides, if Rust programmers really had a problem with Cargo, they would tell us. Programmers don't suffer in silence.

> Package management was solved decades ago, my OS manages the packages and a lean and mean system is the result.

I'm glad you like your package manager. Most programmers, including me, don't want to have to deal with it when the goal is simply to put a Rust project together. Besides, we ship desktop software on Windows: we cannot tell our users "sorry, you need to install Ubuntu".

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

The Rust solution is customizable. You can use dynamic libraries if you like, and earlier prerelease versions of Rust did in fact do that. Dynamic libraries are a single rustc flag away.

The feedback we got was that people preferred the convenience of a single standalone binary to the complexity of dynamic linking managed by the OS.

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

#64

Post by bluejekyll » Wed, Sep 06, 2017, 12:33 AM UTC

Const-me wrote: post #47

pcwalton wrote: post #30

Earlier quoted context omitted.

> 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, particularl…

I can't reply directly to your other comment, so I'll do it here. In the case of pet-graph, I wouldn't say it has large amounts of unsafe (I reviewed it recently b/c I might start using it), but it does use unsafe. Most data structures in Rust require unsafe for performance or memory access patterns. In these cases the developer is the one responsible for guaranteeing that it is safe (no loss over an unsafe language).

> modern C++ is much safer than unsafe rust

This is an interesting comment. I can't say if you are right or wrong, but it's thought provoking. So I'll quote the rustinomicon here:

    Unsafe Rust is exactly like Safe Rust with all the same 
    rules and semantics. However Unsafe Rust lets you do 
    some extra things that are Definitely Not Safe.

    The only things that are different in Unsafe Rust are 
    that you can:

    -Dereference raw pointers
    -Call unsafe functions (including C functions, intrinsics, and the raw allocator)
    -Implement unsafe traits
    -Mutate statics

Point being Rust doesn't just throw out all the rules. But it's a very interesting assertion.

https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

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

#65

Post by nickpsecurity » Wed, Sep 06, 2017, 12:33 AM UTC

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…

Great overview. To support it on the design side, the video below shows the evolution of the language from CPL to BCPL to B to C. In it, you see they don't start with what's great for analysis, safety, or efficiency so much as what can compile on terrible hardware. Thompson's modifications are a mix of arbitrary and what will make it work on a PDP. Ritchie enhances a bit for operating systems. This is start contrast from the careful design of languages like Ada or Modula-3 balancing expressiveness vs safety vs performance. No surprise a bunch of problems followed. And same ones today, 30+ years later, in average app even with better tooling available since the language itself defaults on making simple stuff require extra work to do safely. Not necessary as Wirth, Morrisett, and others showed.

https://vimeo.com/132192250

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

#66

Post by josephg » Wed, Sep 06, 2017, 12:34 AM UTC

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

When I checked out rust a year ago, I tried to implement three things:

- Some OT code. This went ok, but I still have no idea which of the 6 string types I should use for a library like that. I think I ended up settling for Rc> or something, but it still wasn't ideal. Swift, Go and C all each have a canonical string type.

- First I tried to make a skip list with performance matching the performance of my C implementation. I discovered that even with unsafe there was no way to make a struct with a dynamically sized array at the end, like I can easily do in C.

- Then I tried to make a networked server using tokio. Despite all the hype, adding a dynamic item to the event bus didn't work because it wasn't 'static didn't work. After spending a few hours fighting the borrow checker, I went online and was told that this would get better with impl trait or something.

I'd really like to use rust, but as far as I can tell its not mature enough for what I want. I've started a new server project recently and I'm writing it in straight C, as none of the newcomer C-replacement languages I tried seem good enough to replace C.

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

#67

Post by pcwalton » Wed, Sep 06, 2017, 12:34 AM UTC

kahlonel wrote: post #61

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…

Did you even the read the article? How are you comparing JS, Python (or any language "gaining popularity" in your metrics) to C, when the author clearly describes the set of problems only solvable in C?

The point is that those problems are (a) not only solvable in C; (b) not problems that most programmers need to solve. That is why C and C++ are declining in usage.

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

#68

Post by steveklabnik » Wed, Sep 06, 2017, 12:38 AM UTC

flukus wrote: post #46

pcwalton wrote: post #24

Earlier quoted context omitted.

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

Many existing Rust users were extremely skeptical when Cargo was announced, many said they'd stick with Makefiles. In the end, they didn't.

> Package management was solved decades ago

If it was, there wouldn't be new package managers popping up all the time; it's a non-trivial problem. They're not created for no reason.

> The rust solution results in massive binary sizes for simple command line tools.

This isn't exactly true, or rather, you're comparing two different things. https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab... has the details.

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

#69

Post by pcwalton » Wed, Sep 06, 2017, 12:40 AM UTC

chubot wrote: post #49

pcwalton wrote: post #24

Earlier quoted context omitted.

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

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

That's very true. The most we can hope for is that Rust and other languages, such as Go and Swift, continue to chip away at the market share of C and C++. It'll be a long process.

I'm not a "rewrite everything in Rust" booster; as much as I would like to, that won't realistically happen. Instead, I see Rust as another player in the "programming language Renaissance" that has been going on since the mid-2000s. C and C++ are losing their dominance and instead are becoming part of a broad ecosystem of languages. And that's great: the fact that we have so many choices in languages now has been a very good thing for productivity and security.

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

I agree. That's why I think this paper overanalyzes the success of C and C++. They became dominant because of network effects: simple as that.

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

#70

Post by panic » Wed, Sep 06, 2017, 12:40 AM UTC

pcwalton wrote: post #27

dig1 wrote: post #22

Earlier quoted context omitted.

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

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

FreeBSD switched to clang, and could (with some work) be made to use whatever safe C compiler people come up with. That's much easier than rewriting the entire FreeBSD system in a new language.