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]

#91

Post by gens » Wed, Sep 06, 2017, 1:29 AM UTC

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.

No, he did not. Not as far as i remember.

I am not British, and i did want to dramatize it a bit. In my defense, words are to convey meaning as much as to describe action. (you don't literally "beat a dead horse" or "fart in your general direction")

EDIT: In bluejekyll's defense, we here are a bit chafed (hehe) by extreme fans of certain programming languages (IMO even some functional programming fans get a tad too.. unrealistic in their talks)

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

#92

Post by kibwen » Wed, Sep 06, 2017, 1:31 AM UTC

Const-me wrote: post #54

bluejekyll wrote: post #33

Earlier quoted context omitted.

Graph in Rust: https://github.com/bluss/petgraph SIMD in Rust: http://huonw.github.io/blog/2015/08/simd-in-rust/ (yes, still in nightly)

> Graph in Rust: https://github.com/bluss/petgraph Thousands lines of code. Large amount of that is unsafe rust, even C++ is safer than that :-) > SIMD in Rust: http://huonw.github.io/blog/2015/08/simd-in-rust/ (yes, still in nightly) It was already “still in nightly” a year ago. Also it’s harder to do integer math with it, because type safety: very often, even consecutive instructions interpret these __m128i registe…

> Thousands lines of code.

Have you taken a look at petgraph? It does quite a lot of things. The same functionality in C would be thousands of lines as well.

> It was already “still in nightly” a year ago.

SIMD is in Rust nightly not because it's immature, but because the Rust developers would rather design a portable interface than quickly standardize a nonportable one. Given that AFAIK neither the C nor C++ specifications include provisions for SIMD and all support is compiler-specific, the only difference between C/C++ and Rust here is that Rust follows a release model that features a nightly channel.

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

#93

Post by dikaiosune » Wed, Sep 06, 2017, 1:32 AM UTC

bluejekyll wrote: post #85

Const-me wrote: post #71

Earlier quoted context omitted.

> I can't reply directly to your other comment Next time just wait 5-10 minutes. > Most data structures in Rust require unsafe for performance or memory access patterns. And when I want to compose 2 data structures into my own higher-level one, for performance and memory access patterns I need these two lower-level structures to expose unsafe stuff at their API boundaries. The data structures I saw don’t do that, the…

More like 20 it seems ;) > I need these two lower-level structures to expose unsafe stuff at the API boundary Two thoughts: 1) I think you can always use unsafe to get access to a raw pointer (I honestly don't use unsafe often) 2) you need someway to express ownership between both data structures, this can be annoying, no doubt. > C++, with these iterators and smart pointers Does that make it safer than unsafe Rust?…

If you click directly on the time of a comment, it's a link to a direct reply page.

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

#94

Post by Const-me » Wed, Sep 06, 2017, 1:34 AM UTC

burntsushi wrote: post #83

Const-me wrote: post #71

Earlier quoted context omitted.

> I can't reply directly to your other comment Next time just wait 5-10 minutes. > Most data structures in Rust require unsafe for performance or memory access patterns. And when I want to compose 2 data structures into my own higher-level one, for performance and memory access patterns I need these two lower-level structures to expose unsafe stuff at their API boundaries. The data structures I saw don’t do that, the…

> And when I want to compose 2 data structures into my own higher-level one Could you give a specific example please? I compose data structures in Rust all the time.

https://news.ycombinator.com/item?id=15180500

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

#95

Post by haneefmubarak » Wed, Sep 06, 2017, 1:34 AM UTC

panic wrote: post #43

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…

Certainly, but for instance, take one of your examples: Kaitai Struct. It doesn't have support for C (at least it's not listed among the languages on its homepage). OTOH, for more complex payloads I've often seen Protocol Buffers used (yes, I know they don't have native C support either but there's lots of good libraries for using `protobuf`s with C).

The thing with FFIs is that above all we want them to be fast and simple. C rules for laying out structs generally means no parsing necessary, with direct access to fixed offsets for everything you want. If you're ever having problems figuring out the layout of a struct, it's relatively straightforward to just dump some simple load/store code into a compiler and have a look at what it does (assuming you can understand assembly at a basic level): https://godbolt.org/g/khGPWA

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

#96

Post by kibwen » Wed, Sep 06, 2017, 1:34 AM UTC

josephg wrote: post #66

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

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

Rust has two string types, not six. If you're referring to the `OsString` type, that exists only for platform interop, and there's no confusion as to when one needs to use it.

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

#97

Post by burntsushi » Wed, Sep 06, 2017, 1:36 AM UTC

Const-me wrote: post #90

pcwalton wrote: post #81

Earlier quoted context omitted.

> And when I want to compose 2 data structures into my own higher-level one, for performance and memory access patterns I need these two lower-level structures to expose unsafe stuff at their API boundaries. The data structures I saw don’t do that, they’re designed to be consumed from safe Rust instead. Can you give a specific example of something you want to do that you can't? > I think in modern C++, with these ite…

> Can you give a specific example of something you want to do that you can't? Compose a hash map + linked list into an LRU cache. Rust how has that in standard library, but they had to implement their own linked list for that. In C++ it’s just a few lines of code, because standard maps+lists compose just fine. Or (more generic example and thus harder to put in the standard library), add an index to existing collectio…

Use an Rc? If you can't afford the reference count, then use unsafe/raw pointers, which it sounds like you'd do in C++ anyway.

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

#98

Post by pcwalton » Wed, Sep 06, 2017, 1:37 AM UTC

wahern wrote: post #86

pcwalton wrote: post #69

Earlier quoted context omitted.

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

I think the article helps to explain why C was able to leverage network effects so well. Neither C nor Unix came out of the gate in a dominating position. Indeed, it's arguably only in the past 20 years that it clearly dominated. Fortran, Pascal, and a bevy of other languages were at times much more widespread and influential. Even today C isn't the most used language. And yet it's influence continues to be outsized.…

C wasn't useless and unsafe at the time it became dominant. It was quite state-of-the-art at the time. We've just learned more about what works well and what doesn't in programming languages since 1978, which is why C is no longer as dominant as it once was.

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

#99

Post by Retra » Wed, Sep 06, 2017, 1:38 AM UTC

camus2 wrote: post #38

mannykannot wrote: post #25

Earlier quoted context omitted.

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

> 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. Don't people think there are things C could improve that wouldn't affect its suitability for these task…

In fact, all of the things you propose are fairly simple. Leads one to wonder why C programmers haven't implemented these trivial things. Something about the C ecosystem seems to abhor standardization, modernization, and distribution. May have something to do with the kinds of people choosing to use C every day, despite the existence of an endless supply of potential replacements. I'm fairly sure the people who want all that stuff can already find it elsewhere, after all.

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

#100

Post by flukus » Wed, Sep 06, 2017, 1:38 AM UTC

pcwalton wrote: post #63

flukus wrote: post #46

Earlier quoted context omitted.

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

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

This is the same attitude that makes electron so attractive. As a user, I don't care what makes your life easier as a developer, I care that I'm getting a more bloated and less secure result. This is an awful attitude that's creeped into software development lately.

> Besides, we ship desktop software on Windows: we cannot tell our users "sorry, you need to install Ubuntu".

So bundle them on windows, bloated installers are the norm their already. You're probably going to have to include an auto updater and a lot of other stuff that windows doesn't provide as well. Not having to deal with that stuff is part of why I use ubuntu in the first place.

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

Until there is a stable ABI that isn't a solution because you have to distribute those libraries with the app.