Hacker News Reader

Comment by 01HNNWZ0MV43FF | Hacker News Reader

IDK, I thought well-written c and c++ had the same notions of ownership and lifetimes, just not enforced by the compiler

View on HN

No, C++ and especially C have much looser notions around ownership and lifetimes. They still require the basic idea of temporaral safety at all times, but differ greatly in how that's achieved in practice. For example, you'd typically share an Arc<RwLock<T>> between threads in rust, even if it doesn't strictly need them for whatever reason. I can't say I've ever seen someone manually implement Arc in C, and RwLock might be ensured half a dozen ways spanning the entire gamut from no protection for things like file handles all the way up to full mutexes.

There are dozens of Arc implementations in the kernel. Atomic reference counting is an important way to manage lifetimes and is used extensively in things like making sure that shared resources (files, pages, …) are managed correctly.

The rust notion of lifetimes is one of the most c++ things I've ever seen. I've always assumed it grew out of the same culture that produced c++ smart pointers and RAII.

> I can't say I've ever seen someone manually implement Arc in C

In C++, shared_ptr in the standard. But this was common even before the c++11 standard introduced that. I've rolled my own before, more than once. Microsoft ATL had CComPtr.

It wasn't surprising to me either that rust came from Mozilla, which made heavy use of COM, an object model that is very heavily based on reference counting.

I might not have made it clear enough, but I was speaking specifically about plain ol C rather than dialects like kernel C or other languages like C++.

Anyway, what do you prefer to lifetimes? They go back to at least the 60s with lisps and algol and possibly earlier. I wouldn't be surprised to find that idea predates electromechanical computers entirely.

In plain old C it's very common to roll your own atomic reference counting. I've done it many many times. I'm surprised you haven't seen it done. GCC and MSVC both provide intrinsics to wrap synchronization primitives such as compare and swap (lock cmpxchg instruction on x86). __sync_bool_compare_and_swap and InterlockedCompareExchange respectively. Often you might put the reference counting in a helper function for your specific data structure.

To your second question, writing C I like to let the scope dominate the lifetime by doing a free as soon as an object goes out of scope. To make something borrow, you assign it to something with a different scope, then assign your local copy to NULL, exploiting the fact that free(NULL) is a well behaved no-op. In c++ you do the same but you can use destructors to make it more automatic.

I think that's misunderstanding their point a little bit?

I agree with them that in any well-written program (in any language really, not just C and C++) the ownership and lifetime constraints are not necessarily enforced by the compiler - that is, they are not expressed through types or even necessarily through code at all - but they are definitely existent in the design and behaviour of the system. If the programmer cannot explain who holds what and for how long, and therefore when it's safe to read or write particular resources, then that isn't well-written code IMO.

> I can't say I've ever seen someone manually implement Arc in C

...an Arc is literally just a shared pointer. It's in the name, Atomically Reference Counted. Reference counted resources that use atomic operations to adjust the count are a dime a dozen in C projects in my experience.

Rust did not invent the concept of a multiple-reader/single-writer lock either, e.g. the Linux kernel has the `rw_semaphore` type. I don't understand treating types like this as something arcane simply because they're given an explicit tag in Rust.

Golang has also had these types for quite a long time

I'm not calling arc arcane. Have you genuinely ever come across a "small" C project that uses arc? I can't say I have, only large industrial projects like the kernel and gtk. That's my point, it's almost never done by people writing "plain and simple" C, it's something that crops up much later when people start building a bunch of infrastructure onto the language to restrict things into safer patterns.

Is it not because “plain and simple C” often doesn’t often use threads?

C and C++ are very different. I think Casey Muratori hits the nail on the head here:

https://youtu.be/xt1KNDmOYqA

In short, RAII and smart pointers and borrow checker are all signs of "individual element thinking" and that way lies madness. You smear out lifetime and ownership so badly that it practically by definition becomes a problem.

Your goal is to think about this stuff in groups to make thinking about allocation way, way easier. Programming is all about abstracting to the next layer.

I'm not sure he has quite gotten to the heart of the issue, yet. However, a bunch of smart people (Casey Muratori, Jonathan Blow, Andrew Kelley, etc.) are all dancing around something that Rust and C++ don't seem to fit the bill on. Hopefully they can crystallize it out so that everybody can see it.

Oh interesting. I was expecting to see nonsense in that video (probably triggered by the first line -- C and C++ are basically the same thing, in that you can, and folks did forever, implement all the C++ fancy stuff in C -- just because something isn't in the core language, doesn't mean it wasn't done).

But actually it's suggesting how I've been wanting memory to be managed for a couple decades (and have achieved long ago in C projects). Basically some sort of "domain-orientated arena allocator". A simple example is in a network server -- you receive a request from a client, do a bunch of stuff to service that request, and now you're done. Please blow away the memory used to service the request, thanks, all at once. Of course it's not quite that simple because there will be some "chaff" objects thrown off in processing the request that we need to keep around for a while later (e.g. for logging to drain).

I suppose the reference to Jonathan Blow should have been a clue that this would be something worthwhile.

> C and C++ are basically the same thing

I disagree here. For example, try writing something that does reference counting in C vs C++. In C++, it's practically trivial. In C, it's a nightmare of bugs. RAII support being directly in the language is huge in this case.

Casey writes games. Of course to him everything ought to be an arena allocator. This is not actually the best way to write all software.

That's a bit glib. Games almost always have significant networking component nowadays.

And Andrew Kelley writes compilers. And arenas still appear to be superior.

Games and compilers seem to do better with custom allocators. Embedded almost always static allocates. GPU workloads generally don't have "heap-like" allocations either.

We have an increasing amount of evidence that "malloc-like" or "heap-like" allocations on an individual level seem to be a net negative.

My gut feel, as someone with a grey beard, is that we're looking at a breakpoint like we did with garbage collection.

Garbage collection absolutely suuuuucks until you get big enough memory that you can overallocate by about a factor of 2 at which point garbage collection flies.

I think we're at a similar point in "systems programming". It's now okay to overallocate, overcopy, and especially overcalculate things due to current CPU architectures. Chasing pointers is now mega-bad so vtables and the like are becoming a performance bottleneck.

Embedded almost always static allocates is outdated, like integer is almost always faster than floating point.

Some embedded nowadays has hundreds of megs of RAM, with its application using mmap, out of an overcommitted virtual memory.

I would argue that if you have an MMU, you aren't really "embedded" anymore. An RPi isn't "embedded". However, you may still be doing systems programming.

Embedded means that something that is not itself computer contains one, running some dedicated control application. If a Raspberry Pi is built into a toaster, where it controls the temperature and toasting duration according to the user-selected selected darkness level, it's embedded. If the toaster has a screen, and you can install and uninstall apps on the Pi, then it doesn't look so embedded any more.

> And Andrew Kelley writes compilers. And arenas still appear to be superior.

Is Andrew pro-arenas for compilers? I have seen him preach re: data oriented design, and Zig certainly does more re: allocators than Rust, but do you have more info re: this claim?

Rust can do these things. It is maybe true that culturally many Rust programmers do not. There’s both good and bad reasons for this.

The point is that many of the problems rust aims to solve become much less relevant. For example, if your program only does 10 Malloc and frees, you can probably track down the memory bugs.

I agree that these techniques help you write better code, but enforcing something is better than not. Obviously it’s a spectrum, so I wouldn’t say doing that is bad, but it does not really mean Rust is irrelevant.

And Rust brings more to the table than just the borrow checker.

Sure, it just invalidates the impending doom, ban C programming narrative.

I’m not sure I would characterize it this way, but it doesn’t satisfy the criteria of “memory safety by default,” which is what more and more organizations are desiring.

Time will tell.

> RAII and smart pointers and borrow checker are all signs of "individual element thinking"

I'd call it object-oriented thinking. To me Rust and modern C++ are attempting to "OO-ify" systems programming and I think you get push back from folks who view their resources more holistically.

I wouldn’t really describe a lot of Rist codebases I’ve seen as “OO-ify’d”. I’d say it’s got a more functional flavour if anything.

In my experience “de-programming” OOP-programmers is one of the first things teams I’ve been have had to do so that said OOP devs have a better time and write more idiomatic code.

I took my time to watch part of this. I don't entirely agree, however. I'm not really a large systems programmer (I'm a scientist, actually). I really do like the group oriented thinking, but it does seem like there is space for "individual element thinking" at times. This sounds a lot like the philosophical notions of reductionist thinking vs. holistic thinking which is something I think about a lot when it comes to science and physics in general. The way of thinking I've come to value most at this point in my life for understanding the world that might sound a bit silly applied to this is a synthesis (so called hegelian dielectic), which is this case for me means that reductionist thinking and holistic thinking are not really opposites but are simply modes of mental modeling, and can be apply in different ways and different times to your code. Sometimes, it is valuable to have simple, self-contained types which is reductionist or individual element thinking. However, nests of pointers are always much more complicated and unnecessary than programming at the system level for a group of related objects. Which you use depends on the context, and I don't really like identifying them as opposing forces more than different modes that can be drawn from at different times.

That said, most of the time, I find myself utilizing group oriented thinking in my codes and I avoid atomistic, reductionist thinking whenever analyzing a problem at a first pass, but reductionist reasoning does help at times, it just depends on the problem and the context. It is also true, unfortunately, that in science teaching at least we teach students to be reductionist first, and then that reductionist thinking clouds their understanding and it is something young scientists need to break out of at some point, and some never do break out of it. May be in that way it's similar to what this person refers to here (n vs n+1) I just didn't also get stuck thinking reductionism is always bad and avoided it as a rule but I draw from both sides, so to speak.

Reply on news.ycombinator.com