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

201–210 of 253 posts

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

#201

Post by burntsushi »

Const-me wrote: post #200
burntsushi wrote: post #193

Earlier quoted context omitted.

Right, and I don't understand why you think that same exact approach wouldn't work in Rust either. If you have a `Vec >`, then you can spread all the raw pointers you want everywhere without any additional boxing of `tValue`, and you know exactly when those pointers might become invalidated: whenever you call an `&mut` method on your `Vec >` (or rather, on one of the interior `Vec `s). Because of that, you can even b…

The exact container is not that important here. The point is, C++ allows composing these containers making higher-level ones, such as this indexed array example. They can be standard, third-party, my own, I still can compose them. About my particular example, I’m not sure you can easily implement a free list in rust, to reuse space from de-allocated items. Especially if these items have non-empty constructor and dest…

> The point is, C++ allows composing these containers making higher-level ones, such as this indexed array example.

What I---and others---are trying to tell you is that it's perfectly possible in Rust too. I don't think you've pointed out anything that isn't possible in Rust. My previous comment was exactly about composing containers to make higher-level ones.

Have you tried building such things? Did you get stuck? Maybe someone can help.

> About my particular example, I’m not sure you can easily implement a free list in rust, to reuse space from de-allocated items. Especially if these items have non-empty constructor and destructor.

I don't see any reason why implementing a free list in Rust wouldn't be possible either.

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

#202

Post by [deleted] »

ktRolster wrote: post #50
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 aw…

[deleted]

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

#203

Post by flukus »

burntsushi wrote: post #188
flukus wrote: post #132

Earlier quoted context omitted.

I'm dealing with the result of this attitude on my phone right now. The end result is I can't even install your app because I'm out of space on my phone. I'm out of space because every other app maker favored developer productivity over being conservative with users resources. It's a tragedy of the commons.

Seems like you are shifting the goal posts. If I'm building something to run on resource constrained devices, then it makes sense to value use of resources more highly! But otherwise, most of your comments just seem to repeat the same old dynamic vs static linking debate that had been hashed out already for decades. There is no one right answer. Trade offs abound. People who expect a stable ABI from Rust such that no…

> most of your comments just seem to repeat the same old dynamic vs static linking debate that had been hashed out already for decades. There is no one right answer. Trade offs abound.

Rust doesn't let me make that trade off, it's made the decision for me.

> People who expect a stable ABI from Rust such that normal Rust libraries can be dynamically linked like you would C libraries would do well to adjust their expectations. It isn't happening any time soon.

I think it's the rustaceans that need to adjust their expectations, as long as this holds rust won't be a real systems language, it stands a better chance of unseating java than c.

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

#204

Post by pg314 »

mike_hearn wrote: post #184
clarry wrote: post #181

Earlier quoted context omitted.

> Even such a simple use case is fraught with major problems: > > 1. who allocates needed memory? > > 2. who free's it? That's also a major feature. It allows people to write systems that are resilient in the face of tight memory limitations. It's not cool when a language forces string operations to allocate & duplicate memory willy-nilly. > 3. can the compiler constant fold cat("hello","world") ? Does the result win…

It's the opposite. I've seen lots of code written in C that pretends to be out of memory safe. I've never once seen such a program that actually is out of memory safe. Invariably the codepaths triggered by malloc returning null are never exercised. With a GC and exceptions you can theoretically be quite resistant to OOM conditions, not that anyone really cares.

> I've never once seen such a program that actually is out of memory safe. Invariably the codepaths triggered by malloc returning null are never exercised.

sqlite takes care to correctly deal with out of memory conditions. It has explicit tests for that code too. See section 3.1, Out-Of-Memory Testing, of [1].

[1] https://sqlite.org/testing.html

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

#205

Post by burntsushi »

flukus wrote: post #203
burntsushi wrote: post #188

Earlier quoted context omitted.

Seems like you are shifting the goal posts. If I'm building something to run on resource constrained devices, then it makes sense to value use of resources more highly! But otherwise, most of your comments just seem to repeat the same old dynamic vs static linking debate that had been hashed out already for decades. There is no one right answer. Trade offs abound. People who expect a stable ABI from Rust such that no…

> most of your comments just seem to repeat the same old dynamic vs static linking debate that had been hashed out already for decades. There is no one right answer. Trade offs abound. Rust doesn't let me make that trade off, it's made the decision for me. > People who expect a stable ABI from Rust such that normal Rust libraries can be dynamically linked like you would C libraries would do well to adjust their expec…

> Rust doesn't let me make that trade off, it's made the decision for me.

Umm, right, exactly, the state of having a stable ABI is one set of trade offs, and even if that were option, electing to use it for dynamic linking is another set of trade offs. I feel like I was obviously referring to the former, but if that wasn't clear, it should be now. An obvious negative is exactly what you say: you can't use standard Rust libraries like you would C libraries. That's what I meant by trade offs. But there are plenty on the other side of things as well.

> I think it's the rustaceans that need to adjust their expectations

Sure! We do all the time! I'm just trying to tell you the reality of the situation. The reality is that Rust won't be getting a stable ABI (outside of explicitly exporting a stable C ABI) any time soon. If that means flukus doesn't consider Rust a systems language, then that's exactly what I meant by adjusting your expectations. But don't expect everyone to agree with you.

From personal experience, a lot of folks don't care nearly as much as you do about things like "the binary is using 2.6MB instead of the equivalent C binary which is using only 156KB." Now if you're in a resource constrained environment where that size difference is important, then that's a different story, and you might want to spend more effort to use dynamic linking in Rust, which you can do. You won't get a stable ABI across different versions of rustc, but you can still get the size reduction if that's important to you in a specific use case.

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

#206

Post by mike_hearn »

pg314 wrote: post #204
mike_hearn wrote: post #184

Earlier quoted context omitted.

It's the opposite. I've seen lots of code written in C that pretends to be out of memory safe. I've never once seen such a program that actually is out of memory safe. Invariably the codepaths triggered by malloc returning null are never exercised. With a GC and exceptions you can theoretically be quite resistant to OOM conditions, not that anyone really cares.

> I've never once seen such a program that actually is out of memory safe. Invariably the codepaths triggered by malloc returning null are never exercised. sqlite takes care to correctly deal with out of memory conditions. It has explicit tests for that code too. See section 3.1, Out-Of-Memory Testing, of [1]. [1] https://sqlite.org/testing.html

Now I found my first program that actually tests it properly :)

I knew you had to systematically drive the code through every OOM codepath to even have a shot at doing that in an unmanaged language. Sadly a lot of C code is written by people who think:

    if ((ptr = malloc(sizeof(struct foo))) == null)
        return -1;
is the same thing as being OOM safe.

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

#207

Post by bluejekyll »

quickben wrote: post #176
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.…

I am fluent in c, c++, c#. The performance level difference in implementations in some cases is over five orders of magnitude. I envy people that don't have to worry or use pointer management. I imagine them coding in rust with one hand while drinking martinies with the other :)

This is exactly how I code, well s/martinies/burbon/. ;)

The compiler makes sure those types I'm seeing double of are legit.

Seriously, there's a reason the moto 'fearless programming' has been applied to Rust.

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

#208

Post by oconnor663 »

burntsushi wrote: post #201
Const-me wrote: post #200

Earlier quoted context omitted.

The exact container is not that important here. The point is, C++ allows composing these containers making higher-level ones, such as this indexed array example. They can be standard, third-party, my own, I still can compose them. About my particular example, I’m not sure you can easily implement a free list in rust, to reuse space from de-allocated items. Especially if these items have non-empty constructor and dest…

> The point is, C++ allows composing these containers making higher-level ones, such as this indexed array example. What I---and others---are trying to tell you is that it's perfectly possible in Rust too. I don't think you've pointed out anything that isn't possible in Rust. My previous comment was exactly about composing containers to make higher-level ones. Have you tried building such things? Did you get stuck? M…

It seems like one of Const-me's objections is that Rust data structures like HashMap don't document a lot of guarantees about when they would and wouldn't invalidate unsafe interior pointers. That said, for Vec in particular, Rust actually makes a ton of guarantees about its layout (more that C++ std::vector I think): https://doc.rust-lang.org/std/vec/struct.Vec.html

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

#209

Post by _5ysi »

cesarb wrote: post #199
_5ysi wrote: post #171

Earlier quoted context omitted.

Unions would be nice if the syntax for accessing substructure members could be nominally short circuited. For example: struct ab { int a; int b; }; union c { struct ab ab_short_circuit; int a; }; union c c1; c1.a = 1; c1.b = 2;

That already exists, as a Microsoft extension, and if the struct is declared within the union, in standard C: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Unnamed-Fields.... (However, in your example, c1.a is ambiguous, so it won't compile.)

I did not realize this as a Linux user--thanks.

(But this is my point, it is should not be ambiguous.)

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

#210

Post by pcwalton »

blub wrote: post #178
pcwalton wrote: post #78

Earlier quoted context omitted.

Unique pointers provide no protection against use after free, because you can take a reference to their contents and that reference can become dangling. Because the destructor of a unique pointer is invoked automatically per the language rules, as opposed to in C where an explicit call to free is required, this makes C++ more prone to UAF than C.

It's unusual to take references to the contents of a unique pointer. There is one idiom which says that if one has a smart ptr and a function taking a ref, the raw ptr should be passed, but that's it. It's frowned upon... nay scoffed at to store references one receives as parameters, so that temporary ref will go away after the function call, leaving the smart ptr as unique owner. This should not be a problem and it…

> It's unusual to take references to the contents of a unique pointer.

No, it's not. It happens every time you call a method on the referent (well, OK, this is technically not a reference, but it doesn't matter to the argument).

Post reply on HN