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

Pitfalls of Safe Rust

corrode.dev

Post reply on HN
Print view View original

141–145 of 145 posts

Re: Pitfalls of Safe Rust

#141

Post by int_19h »

dwattttt wrote: post #100
tialaramex wrote: post #93

Earlier quoted context omitted.

I think sum types in general and Option in particular is nicer. But the reason C# has nullability isn't that they disagree with me, it's that fundamentally the CLR has the same model as Java, all these types can be null, even though in the modern C# language you can say "No, not null that's never OK" at runtime on the CLR too bad maybe it's null. For example if I write a C# function which takes a Goose, specifically…

> For example if I write a C# function which takes a Goose, specifically a Goose, not a Goose? or similar - well, too bad the CLR says my C# function can be called by this obsolete BASIC code which has no idea what a Goose is, but it's OK because it passed null. If my code can't cope with a null? Too bad, runtime exception. That's actually no different to Rust still; if you try, you can pass a 0 value to a function t…

The difference is that C# has well-defined behavior in this case - a non-nullable notification is really "not-nullable-ish", and there are cases even in the language itself where code without any casts in it will observe null values of such types. It's just a type system hole they allow for convenience and back-compat.

OTOH with Rust you'd have to violate its safety guarantees, which if I understand correctly triggers UB.

Re: Pitfalls of Safe Rust

#142

Post by steveklabnik »

int_19h wrote: post #141
dwattttt wrote: post #100

Earlier quoted context omitted.

> For example if I write a C# function which takes a Goose, specifically a Goose, not a Goose? or similar - well, too bad the CLR says my C# function can be called by this obsolete BASIC code which has no idea what a Goose is, but it's OK because it passed null. If my code can't cope with a null? Too bad, runtime exception. That's actually no different to Rust still; if you try, you can pass a 0 value to a function t…

The difference is that C# has well-defined behavior in this case - a non-nullable notification is really "not-nullable-ish", and there are cases even in the language itself where code without any casts in it will observe null values of such types. It's just a type system hole they allow for convenience and back-compat. OTOH with Rust you'd have to violate its safety guarantees, which if I understand correctly trigger…

> which if I understand correctly triggers UB.

Yes, your parent's example would be UB, and require unsafe.

Re: Pitfalls of Safe Rust

#143

Post by josephg »

pjmlp wrote: post #120
josephg wrote: post #91

Earlier quoted context omitted.

Me too. I agree that its not a bed of roses - and all the memory safety guarantees in the world don't stop you from making a huge mess. But I haven't run into any of the impossible-to-debug crashes / heisenbugs in my multithreaded rust code that I have in C/C++. I think rust delivers on its safety promise.

Most likely because it all multi-threaded code access in-memory data structures, internal to the process memory, the only scenario in multi-threaded systems that Rust has some support for. Make those threads access external resources simultaneously, or memory mapped to external writers, and there is no support from Rust type system.

> Make those threads access external resources simultaneously, or memory mapped to external writers, and there is no support from Rust type system.

I don’t think that’s true.

External thread-unsafe resources like that are similar in a way to external C libraries: they’re sort of unsafe by default. It’s possible to misuse them to violate rust’s safe memory guarantees. But it’s usually also possible to create safe struct / API wrappers around them which prevent misuse from safe code. If you model an external, thread-unsafe resource as a struct that isn’t Send / Sync then you’re forced to use the appropriate threading primitives to interact with the resource from multiple threads. When you use it like that, the type system can be a great help. I think the same trick can often be done for memory mapped resources - but it might come down to the specifics.

If you disagree, I’d love to see an example.

Re: Pitfalls of Safe Rust

#144

Post by pjmlp »

josephg wrote: post #143
pjmlp wrote: post #120

Earlier quoted context omitted.

Most likely because it all multi-threaded code access in-memory data structures, internal to the process memory, the only scenario in multi-threaded systems that Rust has some support for. Make those threads access external resources simultaneously, or memory mapped to external writers, and there is no support from Rust type system.

> Make those threads access external resources simultaneously, or memory mapped to external writers, and there is no support from Rust type system. I don’t think that’s true. External thread-unsafe resources like that are similar in a way to external C libraries: they’re sort of unsafe by default. It’s possible to misuse them to violate rust’s safe memory guarantees. But it’s usually also possible to create safe stru…

Shared memory, shared files, hardware DMA, shared database connections to the same database.

You can control safety as much as you feel like from Rust side, there is no way to validate that the data coming into the process memory doesn't get corrupted by the other side, while it is being read from Rust side.

Unless access is built in a way that all parties accessing the resource have to play by the same validation rules before writting into it, OS IPC resources like shared mutexes, semaphores, critical section.

The kind of typical readers-writers algorithms in distributed computing.

Re: Pitfalls of Safe Rust

#145

Post by adhamsalama »

int_19h wrote: post #80
adhamsalama wrote: post #57

Earlier quoted context omitted.

That's a weird thing to say about a language that doesn't have null safety.

Not to be outdone here, Go introduces multiple null values that are considered distinct, yet they all exhibit the same problem.

I'm still new to Go so I don't know much about this other than empty slices. Can you give me some hints?
Post reply on HN