Hacker News Reader

Comment by Animats | Hacker News Reader

My big problem with Rust is too much "unsafe" code. Every time I've had to debug a hard problem, it's been in unsafe code in someone else's crate. Or in something that was C underneath. I'm about 50,000 lines of Rust into a metaverse client, and my own code has zero "unsafe". I'm not even calling "mem", or transmuting anything. Yet this has both networking and graphics, and goes fast. I just do not see why people seem to use "unsafe" so much.

Rust does need a better way to do backlinks. You can do it with Rc, RefCell, and Weak, but it involves run-time borrow checks that should never fail. Those should be checked at compile time. Detecting a double borrow is the same problem as detecting a double lock of a mutex by one thread, which is being worked on.

View on HN

> I just do not see why people seem to use "unsafe" so much

Because it’s impossible to implement any non-trivial data structures in safe Rust. Even Vec has unsafe code in the implementation to allocate heap memory. When you need efficient trees or graphs (I doubt any non-trivial software doesn’t need at least one of them), unsafe code is the only reasonable choice.

C++ does pretty much the same under the hood, but that’s OK because the entire language is unsafe.

C# has an unsafe subset of the language with more features, just like Rust. However, it runs inside a memory-safe garbage collected runtime. Even List and Dictionary data structures from the standard library are implemented with safe subset of the language. Efficient trees and graphs are also trivial to implement in safe C#, thanks to the GC.

> When you need efficient trees or graphs (I doubt any non-trivial software doesn’t need at least one of them), unsafe code is the only reasonable choice.

To name one example, the AnimationGraph in Bevy is implemented with petgraph, which is built using adjacency lists, and doesn't use any unsafe code in any of the parts that we use. It is very high-performance, as animation evaluation has to be.

> It is very high-performance, as animation evaluation has to be

Are you sure evaluating these animations is performance critical? I doubt games have enough data to saturate a CPU core doing that. Screens only have 2-8 megapixels; animated objects need to be much larger than 1 pixel.

If you animate bones for skeletal animation that’s still not much data to compute because real life people have less than 256 bones. You don’t need much more than that even if your models have fancy manually-animated clothes.

> Are you sure evaluating these animations is performance critical?

Isn't this obviously true? A key part of UI work is avoiding "jank", which commonly refers to skipped frames.

> I doubt games have enough data to saturate a CPU core doing that.

Got a bit lost here: games?

> Screens only have 2-8 megapixels.

4 bytes per pixel, 32 MB/frame. 120 frames / sec = 8 ms/frame. 3.84 GB/second.

> animated objects need to be much larger than 1 pixel.

Got lost again here.

In general, I'm lost.

First, there's a weak claim that all performant data structures in Rust must use unsafe code.

I don't think the author meant all performant data structures must use unsafe code.

I assume they meant "a Rust data structure with unsafe code will outperform an equivalent Rust data structure with only safe code"

Then, someone mentions a 3D renderer, written in Rust, is using a data structure with only safe code.

I don't understand how questioning if its truly performant, then arguing rendering 3D isn't that hard, is relevant.

> Isn't this obviously true?

To an extent sure, but we’re talking about low level micro-optimizations. Games don’t animate individual pixels. I don’t think animating 1000 things per frame gonna saturate a CPU core doing these computations, which means the code doing that is not actually performance critical.

> Got a bit lost here: games?

I searched the internets for “Bevy Engine” and found this web site https://bevyengine.org/ which says “game engine”. I wonder is there another Bevy unrelated to games?

> 3.84 GB/second

In modern games none of that bandwidth is processed on CPU. Games use GPU for that, which don’t run Rust.

> there's a weak claim that all performant data structures in Rust must use unsafe code

Weak claim? Look at the source code of data structures implemented by Rust standard library. You will find unsafe code everywhere. When you need custom data structures instead of merely using the standard ones you will have to do the same, because safe Rust is fundamentally limited in that regard.

> Look at the source code of data structures implemented by Rust standard library. You will find unsafe code everywhere.

This is survivorship bias: one of the criteria back in the day for “should this go in the standard library” was “is it a data structure that uses a lot of unsafe?” because it was understood that the folks in the project would understand unsafe Rust better than your average Rust programmer. These days, that isn’t as true anymore, but back then, things were different.

> I don’t think animating 1000 things per frame gonna saturate a CPU core doing these computations

Oh, my sweet summer child. :)

> In modern games none of that bandwidth is processed on CPU. Games use GPU for that, which don’t run Rust.

So is your claim that OP is making up stuff about running code on the CPU because its a 3D engine?

Also, why mention megapixels if you think it's irrelevant? :)

> Weak claim?

"_all_ performant data structures in Rust _must_ use unsafe code" is a long tail reading of the original comment. If that was the intent, it is a weak claim, because we can observe many memory-safe languages and runtimes and have performant data structures. (minecraft was written in Java, years and years ago!)

> Look at the source code of data structures implemented by Rust standard library.

This is the bailey, which was directly covered in the previous comment.

The motte was "all performant data structures in Rust must use unsafe code"

Here, the bailey, steelmanning as strongly as possible, is "data structures with unsafe code are more performant than ones without", which was directly said in the comment you are replying to.

In addition to the swapping, this is a picture-perfect replication of the bomber with holes on it meme, as the other reply notes.

> OP is making up stuff about running code on the CPU because its a 3D engine?

I’m not sure CPU-evaluated animations are often critical performance bottlenecks of game engines.

> why mention megapixels if you think it's irrelevant?

Count of screen-space pixels is a hard upper limit of count of simultaneously visible things on the screen. Animating occluded meshes is pointless.

> many memory-safe languages and runtimes and have performant data structures

Indeed, because people who designed these memory-safe languages wanted to support arbitrarily complicated data structures implemented using safe subset of these languages.

Safe Rust supports arbitrarily complicated code, but requires unsafe to implement most non-trivial data structures.

It’s possible to hide unsafe code deep inside standard library, possible to implement safe APIs over unsafe implementations, but still, for people who actually need to create custom data structures (as opposed to consuming libraries implemented by someone else) none of that is relevant.

Non-trivial data structures are often just a bunch of arrays/maps with additional semantics. You may consider implementing/using unchecked versions of basic operations for a little bit of additional performance. If you implement (de)serialization yourself, you may need unsafe code. Sometimes the safety of deserialization may be a convenient lie, if checking the invariants fully would be too expensive. And sometimes you may want to expose internal helper functions for various purposes, which may have to be marked unsafe if they can break the invariants.

Beyond that, you only need unsafe code for specific kinds of data structures. At least in my experience.

> Non-trivial data structures are often just a bunch of arrays/maps with additional semantics

This might be fine for code which consumes data structures implemented by other people. The approach is not good when you actually need to implement data structures in your program.

In modern world this is especially bad for a low-level language (marketed as high performance, BTW) because the gap between memory latency and compute performance is now huge. You do need efficient data structures, which often implies developing custom ones for specific use cases. This is required to saturate CPU cores as opposed to stalling on RAM latency while chasing pointers, or on cache coherency protocol while incrementing/decrementing reference counters from multiple CPU cores.

Interestingly, neither C++ nor C# has that boundary, for different reasons: C++ is completely unsafe, and safe C# supports almost all data structures (except really weird ones like XOR linked lists) because GC.

> You do need efficient data structures, which often implies developing custom ones for specific use cases.

You are assuming you can't do this with those vecs/maps. But you can! That's what the "additional semantics" are.

They will be slightly slower due to often using indexes instead of raw pointer, which requires a bound check and an addition to get the pointer, and sometimes a reallocation, but they won't be that slow. Surely they will be faster than C#, which you claim can implement those same data structures efficiently. You also often get the benefit of better cache locality due to packing everything together, meaning it could even be faster.

> They will be slightly slower due to often using indexes instead of raw pointer, which requires a bound check and an addition to get the pointer, and sometimes a reallocation, but they won't be that slow.

This is not a fundamental requirement, though. Assuming arena-like behavior, the index will be constructed/provided by the arena itself, so the bounds check can be safely ellided by-construction. Reallocation cost of the entire arena could be expensive, but if that is a cost you'd want to ammortize down to a new allocation, the arena could be implemented as an extensible list of non-growable arenas: every time an arena is full, you append another. This can be an issue if you don't keep track of deletions/tombstones or can't afford a compaction step to keep memory usage down, but in practice having all of these requirements at once is not as common.

I used to think like that. Then C++11 arrived, and I realized I could get effectively the same performance with containers and move semantics, while spending less effort on writing and debugging the code.

If you need an array for your custom data structure, a standard library vector is almost always good enough. Associative arrays are a bit more tricky, but you should be able to find a handful of map implementations that cover most of your needs. And when you need a custom one, you can often implement it on top of the standard library vector.

> I could get effectively the same performance with containers and move semantics

When I’m happy with the level of performance delivered by idiomatic C++ and standard collections, I tend to avoid C++ all together because I also proficient with C# which is even faster to write and debug.

But sometimes I want more performance. An example from my day job is a multi-step numerical simulation which needs to handle grids of 200M nodes. When processing that amount of data, standard collections are suboptimal. I’m not using std::vector because I don’t need them to grow and I want to allocate these huge buffers bypassing C heap i.e. page-aligned blocks of memory zero initialized by the OS.

I've been using std::vector with arrays that take up to tens of gigabytes for ~15 years without any real issues. Once the size of the allocation exceeds a few megabytes, any reasonable allocator is going to use an anonymous memory map anyway. And if the array doesn't need to grow, it takes effort to make a standard library vector worse than a manually optimized one. It's just a pointer and two integers, after all.

> it takes effort to make a standard library vector worse than a manually optimized one

A simple use case is a 2D array where rows are padded to be multiples of 32 bytes (size of AVX SIMD vectors, saves a lot of implementation complexity because no need to handle remainders) or 64 bytes (saves a tiny bit of performance when parallelizing, guarantees cache lines aren’t shared between rows).

When element size is not a power of 2, it’s impossible to implement that RAM layout on top of an std::vector

It's obviously possible to find niche cases where the standard containers are not good enough. But the remaining 9999 cases out of 10000 are more interesting.

I also had one of those, in an application that created and deleted a large number of fixed-size arrays across many threads. A naive implementation using glibc malloc ended up with a massive memory leak caused by hundreds/thousands of fragmented arenas. A thread could usually not reuse the memory it had just freed, because it was using a different arena. And because the arena was not empty, it was not possible to unmap the memory.

> proficient with C# which is even faster to write and debug.

I don't get it - why are we ignoring the fact that C# necessarily implies distributing CLR? NativeAOT doesn't work for everything.

On AMD64 Windows, .NET 8.0 runtime takes 31.7 MB to download, and 70.7 MB on disk. On ARM64 Linux, the numbers are 28.4 MB and 75.0 MB, respectively.

For that amount of data, both internet bandwidth and disk space are rather cheap these days?

As usual the typical argument that if it doesn't cover 100% of everything it isn't good enough.

There are plenty of use cases where NativeAOT works perfectly fine, and is getting better with each .NET release.

> As usual the typical argument that if it doesn't cover 100% of everything it isn't good enough.

This text

> When I’m happy with the level of performance delivered by idiomatic C++ and standard collections, I tend to avoid C++ all together because I also proficient with C# which is even faster to write and debug.

very strongly implies that they're completely interchangeable. They're not. It's as simple as that.

Sometimes it's hard to keep track of whether I work in software or politics.

> very strongly implies that they're completely interchangeable

Not completely but they are interchangeable. C# at its inception was as much inspired by C++ as it was by Java. Since then, it only further evolved to accommodate far more low-level scenarios and improve their performance.

It provides the kind of capabilities you'd usually expect from C++, so this statement holds true. Calling C exports is one `static extern ...` method away, you can define explicit layout for structs (that satisfy 'unmanaged' constraint), you have fixed arrays in structs, stack buffers, pointers and ability to do raw or abstracted away manual memory management, etc. You can mmap device-shared memory and push data into GPU. You can accept pointers from C or C++ and wrap them into Span<T>s and pass those to most standard library methods.

> Not completely but they are interchangeable ... <whole lotta words telling me things i'm already extremely well aware of>

I'll just ask you this extremely simple question: does C# compile/run/whatever-magic-you-think-it-does on targets that aren't in {x32, x86, ARM64}? Does it target RISC-V? Does it target PTX? Does it target AMDGPU? Are you getting the picture?

Pre-empting the most low-brow dismissal: these are only niche targets if you've never heard of a company called NVIDIA.

> RISC-V

The work is underway: https://github.com/dotnet/runtime/pulls?q=label%3Aarch-riscv

> Nvidia's PTX, AMD

https://ilgpu.net/ and even https://github.com/m4rs-mt/ILGPU/blob/c3af8f368445d8e6443f36...

While not PTX, there's also this project: https://github.com/Sergio0694/ComputeSharp which partially overlaps with what ILGPU offers

Arguably, even C++ itself - you are not using "full" C++ but a special subset that works on top of specific abstraction to compile to GPUs, and I was told that CUDA C++ is considered legacy.

The original context of discussion is performance and perceived issue of "having runtime", which is what my reply is targeted at. In that context, C# provides you the tools and a solution other languages in the class of Java, Go, TS and anything else interpreted just don't have. So you could reasonably replace a project written in C++ that requires assurances provided by C++ with C#, and possibly re-apply all the freed-up developer productivity into further optimizations, but you wouldn't be able to do so with the same degree of confidence with most other originally high-level languages. Another upcoming contender is Swift.

> you are not using "full" C++ but a special subset that works on top of specific abstraction to compile to GPUs

you're wrong - GPU offloading is just window dressing (#defines and CMake) around the compiler itself, which supports almost all of C++; see https://libc.llvm.org/gpu/ which builds libc (which is implemented using C++ in llvm) to amdgpu/ptx/etc.

> C# provides you the tools and a solution other languages in the class of Java, Go, TS

absolutely no one in their right mind would compare these languages to C++

> So you could reasonably replace a project written in C++ that requires assurances provided by C++ with C#

i think people that don't write C++ professionally just don't understand where/how/why C++ is used :shrug:

Goverments of the world in their upcoming cybersecurity laws do.

> on targets that aren't in {x32, x86, ARM64}?

I have personally shipped embedded Linux software running on 32 bit ARMv7 SoC written mostly in C#. The product is long in production and we’re happy with the outcome.

> Does it target RISC-V?

Not sure if it’s ready for production, but see that article: https://www.phoronix.com/news/Microsoft-dotNET-RISC-V

> Does it target PTX?

According to nVidia, the answer is yes: https://developer.nvidia.com/blog/hybridizer-csharp/

> Does it target AMDGPU?

Not sure, probably not.

> Not sure if it’s ready for production, but see that article: https://www.phoronix.com/news/Microsoft-dotNET-RISC-V

> It's coming from a Samsung engineer, Dong-Heon Jung, who is involved with the .NET platform team and works on it as part of his role at Samsung.

answer: no

> According to nVidia, the answer is yes: https://developer.nvidia.com/blog/hybridizer-csharp/

> Dec 13, 2017

answer: no

> Not sure, probably not.

correct, the answer is no.

again: this isn't politics, this is software, where the details actually matter.

> Dec 13, 2017

OK, here’s a newer project which does about the same thing i.e. compiles C# to PTX https://ilgpu.net/ BTW, it supports OpenCL backend in addition to CUDA.

> https://github.com/m4rs-mt/ILGPU/releases/tag/v1.5.1

> Sept 2023.

you guys just don't get it - there's a reason why CUDA is a dialect of C/C++ and not C# and it's not because the engineers at NVIDIA have just never heard of C#.

You are the one that doesn't get it, just like Intel and AMD creating CUDA clones that only focus on C and C++ APIs from CUDA, and not on CUDA the C, C++, Fortran, and PTX ecosystem.

Yes, NVidia has support for .NET on the CUDA ecosystem via partners, the only one that matters on GPGPU.

Yes, Linaro is doing work for managed runtimes on RISC-V, although it remains questionable how much RISC-V matters outside nerd circles.

> Yes, NVidia has support for .NET on the CUDA ecosystem via partners, the only one that matters on GPGPU.

Ironic because "via partners" is equivalent to "doesn't matter".

No my dear, it matters enough that in a freetards world, there are people willing to pay for such product.

The C++ Standard Library containers are very good and generic, and almost always the right tool to reach for. People are finally giving up on that notion that their own custom linked list is so much better than <list>. My estimate is that out of all the C++ programmers, 1% of them think that the C++ standard containers are not appropriate for their application, and only 1% of that 1% is right, due to their extremely specialized application needs.

>> I just do not see why people seem to use "unsafe" so much

>Because it’s impossible to implement any non-trivial data structures in safe Rust. Even Vec has unsafe code

Hmm.. wasn't memory safety the main selling point for rust? If not the only. Now mix of two languages looks even worst than one complex. Especially taking into account that it can be paired with safe language from long list. Don't know what rust fans are thinking, but from outside it doesn't look very attractive. Definitely not enough to make a switch. Julia looked better at first, but turned out to be just a graveyard of abandoned academic projects.

> Now mix of two languages looks even worst than one complex.

The point is that the vast majority of code doesn't have to be unsafe. Empirically, Rust code has far fewer memory safety problems than non-memory-safe languages.

Memory safety without gc is not the only reason people use rust. It's also nicer to use than C++ for multiple reasons (language features, included package manager, easy to integrate tests...)

I use Qt, and I think if you have the Qt libraries then C++ is way better than rust. Most things are there instead of having to go and find a crate and then decide which one to use and hope it will remain maintained.

> Hmm.. wasn't memory safety the main selling point for rust?

The vast majority of Rust programmers aren't spending their time re-implementing core data structures like Vec, so memory safety (and the fact that library authors can build safe abstractions on top of unsafe code, which is impossible in C or C++) still benefits them.

You fan wrap unsafe implementations with safe APIs. The point is there's an explicit boundary between unsafe an safe.

Nope it isn't. You just aren't experienced in system programming. Working with hardware is unsafe since it has state that one cannot completely encapsulate in a single program. The entire specific design of a chip isn't available to programmer; only the machine code is. We usually don't know how a processor decides to cache things or switch to kernel permission level. Usually this isn't even the level we're at, OSes have private internals that change behind the programs and they are not accessible from user space. Pressing Ctrl+C to interrupt changes so many things in memory, it would be outright impossible to write programs that handle every single thing.

The fundamental / syntactic promise of Rust is providing mechanisms to handle and encapsulate unsafety such that it is possible to construct a set of libraries that handle the unsafety in designated places. Therefore the rest of the program can be mathematically proven to be safe. Only the unsafe parts can be unsafe.

Coming from Java or Go or Js or Python angle wouldn't be the same. Those languages don't come with mechanisms to let you to make system calls directly or handle the precise memory structure of the data which is necessary when one is communicating with hardware or the OS or just wants to have an acceptable amount of performance.

In C++, the compiler can literally remove your code if you sum or multiply integers wrong or assume the char is signed/unsigned. There is no designated syntax that limits the places possible memory overflow error happen. The design of the language is such that some most trivial oversight can break your program silently and significantly. It is too broad so it is not possible to create a safe and mathematically proven and performant subset with the C and C++ syntax. It is possible with Rust. It is like the difference of chips that didn't have a hardware mechanism to switch between user and kernel mode so everything was simply "all programs should behave well and no writes to other programs' memory pinky promise".

Rust doesn't leave this just as a possibility. Its standard library is mostly safe and one can already write completely safe and useful utilities with the standard library. The purpose of the standard library is provide you ways to avoid unsafe as much as possible.

Of course more hardware access or extremely efficient implementations would require unsafe. However again, only the unsafe parts can cause safety bugs. They are much easier to find and debug compared to C++. People write libraries for encapsulating unsafe so there are even less places that use unsafe. If people are out of their C++ habit, reaching for the big unsafe stick way too often, then they are using Rust wrong.

Whatever you do, there will be always a need for people and software that enables a certain hardware mode, multiply matrices fast, allocates a part of display for rendering a window etc. We can encapsulate the critical parts of those operations with unsafe and the rest of the business logic can be safe.

> Those languages don't come with mechanisms to let you to make system calls directly or handle the precise memory structure of the data

Here’s a C# library for Linux where I’m doing all these things https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Rea... As you see from that readme, the performance is pretty good too.

> In C++, the compiler can literally remove your code if you sum or multiply integers wrong or assume the char is signed/unsigned. There is no designated syntax that limits the places possible memory overflow error happen. The design of the language is such that some most trivial oversight can break your program silently and significantly.

Here is an interesting case of an optimization-triggered bug in Rust code I've heard of: https://www.youtube.com/watch?v=hBjQ3HqCfxs

> Those languages don't come with mechanisms to let you to make system calls directly or handle the precise memory structure of the data

Eh? You can of course do all of that in python. https://docs.python.org/3/library/struct.html

> Because it’s impossible to implement any non-trivial data structures in safe Rust

This is why I think rust is great for application programmers. Honestly high performance web servers, games, anything in that realm it's pretty good for.

Low level systems and high performance data structures are better implemented with direct memory management, but the consumers of those libraries shouldn't have that same burden (as much as possible).

Granted, I haven't worked with rust enough to run into issues with other people's unsafe code.

> I'm about 50,000 lines of Rust into a metaverse client, and my own code has zero "unsafe". I'm not even calling "mem", or transmuting anything. Yet this has both networking and graphics, and goes fast. I just do not see why people seem to use "unsafe" so much.

I agree. I rarely ever use unsafe, and only as a last resort. Unsafe code is really not needed to achieve high performance.

> Rust does need a better way to do backlinks. You can do it with Rc, RefCell, and Weak, but it involves run-time borrow checks that should never fail.

I think this will basically turn into provably-correct data structures. Which is possible to do, and I've long thought there should be systems built on top of Rust to allow for proving these correct. But we should be clear that something like Idris is what we're signing up for. Whatever it is, it is assuredly going to be far more complex than the borrow check. We should basically only use such systems for the implementations of core data structures.

> I think this will basically turn into provably-correct data structures.

That's kind of what I'm thinking. The basic idea is to prove that .upgrade().unwrap() and .borrow() never panic. This isn't all that much harder than what the borrow checker does. If you have the rule that the return value from those functions must stay within the scope where they are created, then what has to be proven is that no two such scopes for the same RefCell overlap. Sometimes this will be easy; sometimes it will be hard. A reasonable first cut would be to check that no such scopes overlap for a specific type, anywhere. That's rather conservative. If you can prove that, you don't need the checking. So it's an optimization.

> My big problem with Rust is too much "unsafe" code.

I hear cargo-geiger is useful identifying such crates.

> I just do not see why people seem to use "unsafe" so much.

Because it's:

A) fast (branchless access)

B) fast (calling C libs or assembly)

C) fast (SIMD)

D) people think unsafe Rust is easier

Want to write a JSON parser that will gobble up gigabytes per second? Your only way is removing as many branches and use assembly as much as possible. Doubly so on stable! I guess the same goes for making a "blazingly fast"™ graphical stack.

People that think unsafe is easier, shouldn't be writing unsafe code. Writing unsafe code correctly is like juggling burning chainsaws. Saying that's easier than using chainsaws is moronic at best.

EDIT: Consider following, if each of your unsafe {} blocks doesn't contain a

    // SAFETY:
    // Detailed explanation of invariants

One of the chainsaws just cut off your leg.

>people think unsafe Rust is easier

If that's their line of thought, I don't know why they simply don't use C/++. Or even C# with unsafe blocks. I know you said the same, but I wanted to reiterate that.

But yes, I can see a few very specific cases where unsafe access is needed. Emphasis on "few". I think anything past some fundamentals should be at best a late optimizing step after an MVP is established.

I also think, if it's not already there, that crates should be able to identify if it's "safe" or "unsafe". Same mentality where I'd probably want to rely on safe crates until I need to optimize a sector and then look into blazing fast but unsafe crates.

> Rust does need a better way to do backlinks. You can do it with Rc, RefCell, and Weak, but it involves run-time borrow checks that should never fail. Those should be checked at compile time.

It's not clear to me how rustc could detect a dangling backlink in a tree structure at compile time. Seems impossible short of adding proofs to the type system.

If the language actually supported a full set of memory policies it would be quite possible.

Unfortunately it only thinks about are unique, an opinionated form of borrowed ownership, and a little bit about shared (weak I think is punted entirely to the library?), and not all other ownership policies can effectively be implemented on top of them.

The usual thing approach would be:

  given two types, P and C (which may be the same type in case of homogeneous trees, but this), with at least the following fields:

  class P:
    child1: ChildPointer[C]
  class C:
    parent: ParentPointer[P]

Then `p.child1 = c` will transparently be transformed into something like:

  p.child1?.parent = null
  c?.parent?.child1 = null # only needed if splice-to-steal is permitted; may need iteration if multiple children
  p.child1 = c
  p.child1?.parent = p

Note that ChildPointer might be come in unique-like or shared-like implementations. ParentPointer[T] is basically Optional[UnopinionatedlyBorrowed[T]].

A have a list of several other ownership policies that people actually want: https://gist.github.com/o11c/dee52f11428b3d70914c4ed5652d43f...

Is there some research that shows these are actually safe and can be reasonably checked by a compiler?

I don't use Rust and I've bounced off trying to learn it 3 times so far, so take this with a mountain of salt, but...

I think that Rust having unsafe is fine as there will be edge cases where the compiler can't quite work out whether some code will work fine or not and where the programmer can vouch for it. That's no problem.

The issue I have with it is that the unsafe block then gets kinda swallowed by the supposedly safe wrappers around it. And there's no clear auditable trail back to it. I find that a bit surprising as I'd expect it obvious to have some kind of 'uses unsafe' declaration (annotation? I don't know what Rust calls those statements with a number sign and square brackets in front of a subroutine) which would then propagate upwards. A bit like how in Java (the most elegant and refined of all programming languages) you can use an annotation to state that a function 'throws XYZException' which then needs to be propagated up to a point where it can get handled.

Not having such a mechanism feels a bit icky to me. It's like if there's spiders crawling out of your ears it's useful to know that they're coming out of your ears so you don't have to wonder 'are those spiders creeping out of my ears? Or out of my nose? Or out of my eyelids?', which would be a bit inconvenient.

This annotation would be useless, because it would infect ~99% of your codebase. All IO is implemented as unsafe FFI calls or unsafe inline assembly somewhere down the stack. And even "pure" types like Box, Option, Vec have a lot of unsafe in their implementations. At some point these standard implementations just have to talk to an allocator which is implemented unsafely (obviously), or they have to construct a slice [1], etc. Would you make an exception for the standard library and why? I think, this just doesn't make sense. It's all unsafe somewhere down the stack.

[1] https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html

> I just do not see why people seem to use "unsafe" so much.

SIMD seems to be a big one.

If you're doing graphics then you will have to use `unsafe` to interface with the OS primitives, there's no other way.

Backlinks would be "nice" but they break fundamental assumptions that the borrow checker does.

> Detecting a double borrow is the same problem as detecting a double lock of a mutex by one thread, which is being worked on.

Is it being worked on using heuristics or formal methods?

I’ve been using Rust almost daily since 2015 and I’ve used unsafe twice - both when interoping with C.

I don’t know what fancy things you’re doing with unsafe that you’re seeing it on a daily basis… maybe it’s a you problem

It is explicitly mentioned that ubsafe is in their dependencies not their own code.

It's ugly but it's inevitable in some sense. The author should know what they are doing, and `// SAFETY:` comment is a must.

No. Nobody is going read those (because most people won't even know that some unsafe is buried 5 layers of dependencies below what they work with). The author should make reasonable effort to prove the code is working correctly (and cannot be abused) by other means if possible. It might be a domain issue, so far all my apps are 100% safe (not counting libraries).

You put those safety comments in two places: when you declare an API as being unsafe, and when you use an unsafe API. Not coincidentally, those are the two places in the language that force you to use the “unsafe” keyword. If you declare a safe API that uses unsafe under the hood, it’s on you to ensure that it’s safe to call under any situation, so that callers can call it without worrying that their program is suddenly unsafe. If you can’t guarantee that your API is safe under all circumstances, you need to declare it unsafe and make it the caller’s job to use it safely.

Unsoundness is considered a bug and should be reported and fixed.

Reply on news.ycombinator.com