Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making C++ safe without borrow checking, reference counting, or tracing GC

verdagon.dev

Post reply on HN
Print view View original

121–130 of 226 posts

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#121

Post by jjnoakes »

steveklabnik wrote: post #103
amelius wrote: post #98

Earlier quoted context omitted.

This would be true if code using the borrow checker was easier to read than to write.

The point is that the compiler helps you “read” it. This takes mental effort off of you. I agree that not everyone thinks this is true, but this is my experience. I do not relate to the compiler as a straight jacket. I relate to it as a helpful assistant.

This is my experience as well. I find it much easier to work faster when the compiler is helping me, and I don't consider it a "straitjacket" at all.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#122

Post by Yoric »

cmrdporcupine wrote: post #66
convolvatron wrote: post #24

Earlier quoted context omitted.

I really love parts of rust and kinda hate other parts. but this is what really ruins it for me. I want to play. I want to knock something together and work with it and see what kind of shape it is. rust demands that I cross every last t before I can run it at all. which is great if you already have a crystal notion of what you are building

This is definitely true, but I also don't know what a reasonable alternative is at this point for systems dev (aka places where a GC is a Bad Idea). I wouldn't unleash C or C++ onto a new project like that? I'd just feel icky. And Zig's type system IMHO isn't good enough, I'd really miss pattern matching for one. I do think many people are using Rust in the Wrong Places(tm). It seems like torture to me to be applying…

I think I agree with most of what you write, but note that async has lots of applications beyond microservices. In particular, writing anything that uses the network (e.g. a web browser), which definitely feels system-y to me.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#123

Post by jjnoakes »

kbenson wrote: post #63

Methods such as these for C and C++ are interesting, and needed, but only solve a part of the problem. As others have noted before, they do little good because they're opt-in. I think there's a bit of nuance to that which needs to be explored though, as I think it's less a problem that the extra checks are opt in, and more a problem of how we use and categorize libraries. As long as we encourage dynamic and static li…

I feel like a few languages are better than others in a related but not quite identical area:

Languages like Java and Go, while they CAN escape to native libraries, have cultures that tend to avoid that kind of thing. At least, in my projects, I have quite an easy time using zero native dependencies with those languages (except for the underlying kernel of course), and so I feel like there is a much lower chance of escape-hatch issues sneaking in.

They aren't built on a foundation of legacy C and C++ libraries - not even the crypto - and I find that to be an advantage.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#124

Post by mr_00ff00 »

jjnoakes wrote: post #119
mr_00ff00 wrote: post #107

Earlier quoted context omitted.

If unsafe means “safe but the compiler cannot verify” then I guess just consider .cpp to mean “safe but the compiler cannot verify” and we have suddenly made C++ memory safe

Sure, and if a typical Rust program that I write has no unsafe in it directly, and 5% of its dependencies' code have unsafe in them, that's also the same as writing a program in the "not c++" language directly, and using "not c++" dependencies for all but 5% of the dependency code. Seems like a silly analogy to me, though.

Right but it’s that 5% the origin comment is talking about. The times when rust has to use unsafe for the type of program.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#125

Post by mr_00ff00 »

ammar2 wrote: post #114
mr_00ff00 wrote: post #113

Earlier quoted context omitted.

Sure, but I think the point here is the degree. Presumably if it takes a lot of unsafe rust lines to build something, it won’t matter if it’s 30% safe or whatever. I just see the point of “unsafe is fine” a lot when the whole point of rust is that memory safety issues are never worth the cost.

Right, I guess the question is what will that proportion be when Rust is used for things like operating systems and web browsers. 30% would be untenable but a few hundred/thousand lines of unsafe code is fairly easy to put under a microscope. For some current day research into this, there is the paper "How Do Programmers Use Unsafe Rust?"[1] which I'll drop a quote from here: > The majority of crates (76.4%) contain…

Ahh that is quite interesting, I’ll check those links out

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#126

Post by Ygg2 »

mr_00ff00 wrote: post #107
dralley wrote: post #91

Earlier quoted context omitted.

> Slotmap uses unsafe everywhere, it's a memory usage pattern not supported by the borrow checker. Is disabling the borrow checker really a common pattern in Rust? Wrapping "unsafe" code in a safe interface is a common pattern in Rust, yes. There is absolutely nothing wrong with using "unsafe" so long as you are diligent about checking invariants, and keep it contained as much as possible. Obviously the standard libr…

If unsafe means “safe but the compiler cannot verify” then I guess just consider .cpp to mean “safe but the compiler cannot verify” and we have suddenly made C++ memory safe

It's not what unsafe means. Unsafe means this might cause UB for some invocations (accessing raw pointers, calling into another language, etc.). Safe means it will not cause UB for any invocations (it may panic or abort).

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#127

Post by SubjectToChange »

antonvs wrote: post #55
josefx wrote: post #27

Earlier quoted context omitted.

> The memory model is a flat space provided by the OS that can be addressed by pointers From what I understand this is not true. Pointers cease to be valid the moment you try to leave a single allocation. You get to play around within a single continuous allocation and one past the end, everything further out is playing with fire. Even comparing the "addresses" of two separate allocations is undefined if done with "…

> everything further out is playing with fire. That's the point. C and C++ don't prevent you from playing with that for. Memory-safe language do.

Rust only requires you to wrap it in unsafe. And I think C# allows you to do some pretty crazy stuff too.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#128

Post by estebank »

spacechild1 wrote: post #112
estebank wrote: post #102

Earlier quoted context omitted.

Out of bound access is avoided because you ise handles that the arena has given you, creating an invalid handle is restricted. You avoid double free because of Rust's owbership semantics that make the arena itself reaponsible for "deallocation" (which is just blanking the value and letting Drop do its thing). You avoid stale pointers because every access is checked at runtime if you're using a generational arena.

We are talking about C++ ;-)

You're right, I was reading a sister thread that was talking about Rust and lost the plot.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#129

Post by jjnoakes »

mr_00ff00 wrote: post #124
jjnoakes wrote: post #119

Earlier quoted context omitted.

Sure, and if a typical Rust program that I write has no unsafe in it directly, and 5% of its dependencies' code have unsafe in them, that's also the same as writing a program in the "not c++" language directly, and using "not c++" dependencies for all but 5% of the dependency code. Seems like a silly analogy to me, though.

Right but it’s that 5% the origin comment is talking about. The times when rust has to use unsafe for the type of program.

Unsafe Rust is safer than C++, and even if it wasn't, 5% unsafe in Rust programs (in well-marked locations) is vastly superior to 100% unsafe in C++ programs.

Any analogy that equates the two is silly.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#130

Post by Gwypaas »

ammar2 wrote: post #114
mr_00ff00 wrote: post #113

Earlier quoted context omitted.

Sure, but I think the point here is the degree. Presumably if it takes a lot of unsafe rust lines to build something, it won’t matter if it’s 30% safe or whatever. I just see the point of “unsafe is fine” a lot when the whole point of rust is that memory safety issues are never worth the cost.

Right, I guess the question is what will that proportion be when Rust is used for things like operating systems and web browsers. 30% would be untenable but a few hundred/thousand lines of unsafe code is fairly easy to put under a microscope. For some current day research into this, there is the paper "How Do Programmers Use Unsafe Rust?"[1] which I'll drop a quote from here: > The majority of crates (76.4%) contain…

Or Rust in Android, in this deep dice gaining two places of unsafe code which found a bug in the existing implementation due to the vetting triggered by being the only two places.

https://security.googleblog.com/2022/12/memory-safe-language...

Post reply on HN