> Some projects pride themselves to not use "unsafe" code
This is normal? not having unsafe code does not guarantee absence of bugs, but at least it isolates the problematic bits in the sections marked as unsafe.
If you need unsafe, you can always use unsafe.
Battle tested codebases like bind or openssh — and many others, independently of the language of implementation — had bugs in the past. It always helps to have extra assurances. Using safe/Unsafe is one more tool to have assurances.
> Ideally, the usage of `unsafe` should be discouraged by the compiler via friction.
This is enforced via tools: you have to say 'unsafe' to use something unsafe. That's the speed bump.
In addition, there's a lint that you can on to fail the build if you use `unsafe`. This won't apply to your dependencies, but you can make it apply to your code.
> or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"
The point with being able to do this though is that sometimes you really do need to use unsafe code, but you still get to isolate the unsafe parts of your codebase from the safe parts of it, and you do so in a way that is defined by the language itself rather than in an ad-hoc way.
The language and the compiler enforces safety for the rest of your codebase, which in most cases makes up the vast majority of the codebase, and for the unsafe parts of the codebase where it doesn’t, you have a much more limited and clearly defined surface of code that you and everyone else looking at the code will know that needs to be handled with extra care, and which can and should be audited extra thoroughly.
`Unsafe` doesn't mean you shouldn't do it, it just means you have to tell the compiler "I know what I'm doing, trust me" - and be careful because it will have less guarentees because it trusts you.
> It doesn't matter if that code is a VM or unsafe code.
What does matter is the amount of unsafe code to trust. It's much easier to check that a small area of clearly-marked unsafe blocks does "the right thing" than if your entire program is a gigantic unsafe block.
This is kinda disingenuous. Whenever we people use unsafe its like an alarm because you can setup CI system that warns DevOps team regarding the usage of unsafe code.
And, most of the time unsafe code is not required. I think many people will just use clone too much, or Arc rather than unsafe. Additionally, I have never seen unsafe code at least where I work.
Small, widely-verified blocks of unsafe code should be the norm if unsafe code is necessary. This does not mean "if you're using unsafe you've failed!"
Doesn't mean you shouldn't try to lessen the amount of code that's unsafe. That way you have at least a fighting chance at getting your unsafe code bugfree.
I don't see an issue with 'unsafe' if it's an implementation detail and well-tested. Obviously it would be better to avoid it if possible. 'unsafe' is overkill sometimes and worth it other times.
I am not sure you can not use `unsafe` in an embedded type of project. `unsafe` isn't necessarily bad, but when used at least makes it very clear where extra attention should be paid.
> An interpreter is totally in the clear on these subjects and should not have anyone reaching for unsafe.
This is true for a toy interpreter. You don’t “need” unsafe. But anything other then a toy interpreter has many reasons to reach for unsafe: garbage collection, flexstr, object dispatch, tagged pointers, etc. Not to mention the performance gains from using unchecked functions in hot sections of the interpreter loop.
> Agreed, the novelty is doing it in the core language (unsafety is opt-in, not the other way around) and without sacrificing performance.
Unsafe code blocks as opt-in in systems languages appeared for the first time in 1961, followed by multiple variations of it since then, far from being a novelty by now.
So why is `unsafe` even in the language, then? It would seem to me that it simultaneously undermines safety guarantees, and it can't even ensure performance improvements.
This is normal? not having unsafe code does not guarantee absence of bugs, but at least it isolates the problematic bits in the sections marked as unsafe.
If you need unsafe, you can always use unsafe.
Battle tested codebases like bind or openssh — and many others, independently of the language of implementation — had bugs in the past. It always helps to have extra assurances. Using safe/Unsafe is one more tool to have assurances.
reply