Thank you for writing this! It validates what I’ve been thinking about Rust for some time now. Basic things in how a language operates or libraries that are used by 90% of all users should either go into the compiler or stdlib is my (controversial) opinion. I want to point out that C# also solves this in a much nicer way than Rust. I wonder how Zig will handle this in the feature. If some library ends up getting used by 90% of projects will it be upstreamed into stdlib? I surely hope so but I believe that goes against the philosophy of the language.
Sorry for being combative here but it bothers me when people say X is bad because… and then go on to make up reasons instead of pointing at actual problems.
unsafe {}is not a way to use pointers but rather “I am hereby going to check everything what compiler does myself, and ALSO everything what it might check in the future” which is extremely scary (and I have no idea how anyone can say that Rust is safe with such feature)
The borrow checker is still checking your code. You are certainly not taking on the full responsibility of the compiler by typing `unsafe`. IME unsafe is specifically used when you need pointers and need FFI.
the whole safety argument is only true until you interface with anything useful (like OS).
This is also one of those false arguments brought up. For the vast majority of Rust projects 95% of the code is gonna be safe. The idea is that you use `unsafe` only around those parts that explicitly demand it. So for example if you’re interacting with an OS through the already existing std lib abstractions you won’t be writing unsafe code for the most part. This is also similar to how it works in C#. There you also have the `unsafe` keyword but you don’t see that thrown around in every project.
It’s not my intention here to be glazing Rust in any way, I just think it’s good to talk about actual issues.
2 Likes
unsafe is a famously poorly chosen keyword. It’s like it was designed to give people the wrong impression about what it means.
1 Like
What unsafe {} means is that you are ie. responsible to check all mutability rules yourself - there can be only one (alive) mutable ref to the same place in memory at all times. This is also why Rust can be slightly faster than other languages for the same kind of code. This optimization was disabled and re-enabled several times and already caused safety issues in various crates.
If it’s so easy-peasy then why others already failed to do so? Of course the compiler is still doing something and of course it’s going to be safer in common case, it’s just not the unicorn mem-safe-land that is usually advertised for Rust.
When you put it that way I agree that the programmer has to be more careful. The way you wrote your initial bullet point it sounded to me like you were saying the compiler was basically turned off. Using unsafe Rust should be similar to using C with the `restrict` keyword on every pointer as far as I can tell. I think one situation you have to be very diligent is when going from a mutable pointer to a mutable reference. This is what is stated in the reference
&mut Tmust point to memory that is not read or written by any pointer not derived from the reference and that no other reference points to while they are live.
I think outside of this difference, unsafe in Rust is of a similar nature to C++, Zig or C?
If it’s so easy-peasy then why others already failed to do so? Of course the compiler is still doing something and of course it’s going to be safer in common case, it’s just not the unicorn mem-safe-land that is usually advertised for Rust.
Developers accidentally write UB code in C++ all the time as well. Not sure I understand the argument you are making? I don’t remember seeing anyone that claims that `unsafe` Rust is this unicorn memory safe thing. I think people are claiming that safe Rust (except for some famous exceptions) gives you memory safety and no overhead (unlike a GC).
1 Like
Therefore, in hindsight, Bun’s initial choice of Zig was a mistake. They have now realized this problem and are trying to change it.
You make the assumption that Bun could be where they are now, or further along some imaginary path they wanted to take, if they had chosen something different than Zig to start with.
That is not necessarily true. It is easy to imagine they would have chosen some technology, with the same resources (team, money, etc.) available at the beginning, and never gotten as far as a 1.0 release.
[quote=“vulpesx, post:41, topic:15330”]
Zig is unstable software, it advertises that upfront; if zig’s breaking changes are an issue for them, then it is bun’s responsibility as they chose zig in the first place.
[/quote]
Bun has every right and the necessity to reconsider their initial choice.
I sincerely hope their attempt will yield a successful outcome!
I have a slightly different perspective. Even if bun is eventually ported to Rust, this does not necessarily mean bad news for Zig.
As is well known, Rust is a language that is not suitable for prototyping at the cost of memory safety. Bun’s achievements today owe much to Zig. RIIR, in a sense, is indeed Rust’s strength because it is not good at developing prototypes with changing requirements, but it excels at rewriting.
If LLM porting can work, it would merely mean there is an additional path:
fast prototyping in Zig–LLM ported to Rust to ensure memory safety.
This does not mean Zig has failed, because I believe that if bun had started development in Rust, it probably would not have reached today.
Of course, actually I don’t really believe that LLM can make it through this path.
8 Likes
slopware probing rust, why would this be a surprise? 
I’m skeptical.
You can’t really port non-trivial zig to rust line-by-line because the borrow checker will get in the way, and the LLM will bypass these restrictions in the laziest manner possible. The end result will almost certainly be some combination of horribly inefficient, overly complex, and potentially unsafe.
I still think it’s an interesting exercise, I just think that when architecting a solution in rust versus zig using their respective idioms, the solutions will look very different, and any attempt to mechanically port one to the other will end up being far from ideal.
5 Likes
just port everything under the unsafe scope, easy-peasy—the borrow checker is for hands that are unable to properly manage memory (/follow specs), so it should not be the case coming from zig 
1 Like
TL;DR: Almost all std IO(files/network) have been replaced.
WARNING - link to AI related content
So bun uses strongest part of Zig functionality…
clearly they are dissatisfied with zig, but that doesn’t mean it was a mistake to use zig in the first place.
I merely stated that it is their own responsibility, and was talking in response of someone speaking as if it was zigs fault for making breaking changes.
2 Likes