The unsafe keyword doesn't disable the borrow checker... it lets you interact with different pointer types that aren't borrow checked, but if you're using the normal reference types in rust the same guardrails are still in place.
That's not the spirit Rust wants to have. You can already disable borrow checker selectively by using "raw" pointers in places where you think you know better, and this is used very commonly. Every String in Rust has such raw pointer inside.
It doesn't make much sense to globally relax restrictions of Rust's references to be like C/C++ pointers, because the reference types imply a set of guarantees: must be non-null (affects struct layout), always initialized, and have strict shared/immutable vs exclusive access distinction. If you relax these guarantees, you'll break existing code that relies on having them, and make the `--yolo` flag code incompatible with the rest. OTOH if you don't remove them, then you still have almost all of borrow checker's restrictions with none of the help of upholding them. It'd be like a flag that disables the sign bit of signed integers. It just makes an existing type mean something else.
> you need the borrow checker guarantees to implement downstream compilation steps.
You don't technically. The borrow checker doesn't effect the semantics of the program (like, for example, type inference does) and the rest of the compiler doesn't need to (and in fact, doesn't) use its analysis to figure out how to compile the code.
The downstream compiler does assume that the code followed the rules for accessing references - i.e. didn't violating aliasing rules. The borrow checker guarantees this, but it's fundamentally a conservative check. It rejects programs it can't guarantee are correct, and rice's theorem proves that there are always correct programs that it can't guarantee are correct.
That said if you just treat rust-references like C-pointers you will run into issues. The aliasing rules for rust references are stricter. Also not fully agreed upon yet - the currently closest to accepted definition is in the "tree borrows" paper but it has yet to be adopted as the official one by the rust team.
Is rust simple aesthetics to you? Why use rust, or any language at all really, at all then? The whole point of formal languages is to point a gun at the people who refuse to be adults.
If we can't have this, C itself offers zero benefit over assembly.
I think it's more in the spirit of playfulness, like in "don't take yourself too seriously". It's why people want to mod Minecraft and Doom for example.
Because it's fun.
I can totally understand why you wouldn't want to do this though - the plethora of incompatible lisp dialects come to mind. That's why I said it was controversial.
I would assume that this is easy enough to implement that it will likely appear in a minor update to the upcoming Visual Studio version. MS kept updating the compiler since VS 2022, too.
I certainly hope so, but we'll see. To give an example, std::chrono::current_zone (C++20) still doesn't work on Android even to this day.
So as long as #embed isn't supported by all the 3 major compilers, I am sticking with my current embedding setup. I guess that's what I was thinking of.
It's kind of ironic since AI can only grow by feeding on data and open source with its good intentions of sharing knowledge is absolutely perfect for this.
But AI is also the ultimate meat grinder, there's no yours or theirs in the final dish, it's just meat.
And open source licenses are practically unenforceable for an AI system, unless you can maybe get it to cough up verbatim code from its training data.
At the same time, we all know they're not going anywhere, they're here to stay.
I'm personally not against them, they're very useful obviously, but I do have mixed or mostly negative feelings on how they got their training data.
Getting an email from an AI praising you for your contributions to humanity and for enlarging its training data must rank among the finest mockery possible to man or machine.
Still, I'm a bit surprised he overreacted and didn't manage to keep his cool.
yeah, so many things have not worked for me. after 30 years apparently it's dexamphetamine and a location away from my house i only use for work or nothing
As a long time HN reader, I'm well acquainted with this article and every time I read it again, I'm reminded of these 2 famous sayings, which seem amusing in this context:
1. "Do as the priest says not as he does"
2. "It is far easier for me to teach twenty what were right to be done, than be one of the twenty to follow mine own teaching."
So now that you know what must be done, go out and do it, if you can. If not, teach it to others.
> it just sort of grew gradually and I felt it was better spending my time working on something that was fun to work on even if at the time it looked like there was no possibility of it becoming commercially worthwhile.
The indie ethos, before it was even a thing (or in the very early stages).
Optimize for human satisfaction: NP-hardest
reply