Live data from Hacker News

Rust--: Rust without the borrow checker

github.com

151–160 of 269 posts

Re: Rust--: Rust without the borrow checker

#151

Earlier quoted context omitted.

If you write correct Rust code it'll work, the borrowck is just that, a check, if the teacher doesn't check your homework where you wrote that 10 + 5 = 15 it's still correct. If you write incorrect code where you break Rust's borrowing rules it'll have unbounded Undefined Behaviour, unlike the actual Rust where that'd be an error this thing will just give you broken garbage, exactly like a C++ compiler. Evidently mil…

The attitude expressed here and that tends to surface in any Rust discussion is the reason I completely lost interest in the language.

Rust isn't a one true language, no one necessarily needs to learn it, and I'm sure your preffered language is excellent. C and C++ are critical languages with legitimate advantages and use cases. Don't learn Rust of you aren't interested.

But Rust, its community, and language flame wars are separate concerns. When I talk shop with other Rust people, we talk about our projects, not about hating C++.

Re: Rust--: Rust without the borrow checker

#152

I've been thinking of writing a language with Rust's ergonomics but less of the memory safety stuff. I prefer using no dynamic allocations, in which case the only memory safety feature I need is leaking references to locals into outer scopes. As for the thread safety stuff, most of my stuff is single-threaded.

I've been wishing for Rust to become more ergonomic, what ergonomics does Rust currently have that other languages lack?

Re: Rust--: Rust without the borrow checker

#153

I'm the author of this repo. I see some really angry comments, some of them even personal. Obviously I didn't think that just by tinkering with a compiler, I'd get personally attacked, but anyway, fair enough. For those of you confused: yes, this started as a satirical project with the corroded lib. Then I thought "why not just remove the borrow checker?" without any real motivation. Then I just went ahead and did it…

> Then I thought "why not just remove the borrow checker?" without any real motivation. Reminds me of a chemistry kit I had as a kid. None of this tame, safe stuff you can buy these days. Mine was a gift from my dad and I never thought of asking him where he dug it up, but it had stuff like pure sulfuric acid in it. One day, when I was done with all of the experiments I had planned to do, I decided to mix a few thing…

Anything fun is dangerous. Or anything dangerous is fun. Something like that.

Re: Rust--: Rust without the borrow checker

#154

I would actually enjoy that for certain small projects. Rust without the borrow checker is a very elegant language. The borrow checker is great, of course, but it can be a pain to deal with. So, for small projects it would be nice to be able to disable it.

Instead of disabling the borrow checker what should be possible is to promote borrows to Rc/Arc as needed. I would want to restrict this mode to one where it can only work locally, never publishable to crates.io. It would be particularly useful when running tests, then instead of a compile error you can also get a runtime error with better information about the cases the borrow checker was actually encountering.

Re: Rust--: Rust without the borrow checker

#155

Earlier quoted context omitted.

If you write correct Rust code it'll work, the borrowck is just that, a check, if the teacher doesn't check your homework where you wrote that 10 + 5 = 15 it's still correct. If you write incorrect code where you break Rust's borrowing rules it'll have unbounded Undefined Behaviour, unlike the actual Rust where that'd be an error this thing will just give you broken garbage, exactly like a C++ compiler. Evidently mil…

The attitude expressed here and that tends to surface in any Rust discussion is the reason I completely lost interest in the language.

So don't use it. Rust is not intended to be used by everyone. If you are happy using your current set of tools and find yourself productive with them then by all means be happy with it.

Re: Rust--: Rust without the borrow checker

#157

I've been thinking of writing a language with Rust's ergonomics but less of the memory safety stuff. I prefer using no dynamic allocations, in which case the only memory safety feature I need is leaking references to locals into outer scopes. As for the thread safety stuff, most of my stuff is single-threaded.

I've been wishing for Rust to become more ergonomic, what ergonomics does Rust currently have that other languages lack?

I love how everything is an expression with a value. And match expressions are quite nice, especially with the option type. I really miss those when working in javascript.

Re: Rust--: Rust without the borrow checker

#158
post #137
post #102

Earlier quoted context omitted.

>Haskell (and OCaml etc) give you both straightjackets.. Haskell's thing with purity and IO does not feel like that. In fact Haskell does it right (IO type is reflected in type). And rust messed it up ("safety" does not show up in types). You want a global mutable thing in Haskell? just use something like an `IORef` and that is it. It does not involve any complicated type magic. But mutations to it will only happen i…

> "safety" does not show up in types It does in rust. An `unsafe fn()` is a different type than a (implicitly safe by the lack of keyword) `fn()`. The difference is that unsafe fn's can be encapsulated in safe wrappers, where as IO functions sort of fundamentally can't be encapsulated in non-IO wrappers. This makes the IO tagged type signatures viral throughout your program (and as a result annoying), while the safet…

>The difference is that unsafe fn's can be encapsulated in safe wrappers

This is the koolaid I am not willing to drink.

If you can add safety very carefully on top of unsafe stuff (without any help from compiler), why not just use `c` and add safety by just being very careful?

> IO tagged type signatures viral throughout your program (and as a result annoying)..

Well, that is what good type systems do. Carry information about the types "virally". Anything short is a flawed system.

Re: Rust--: Rust without the borrow checker

#159
post #121

My controversial opinion: If Rust were to "borrow" something from the C/C++ spirit, then disabling the borrow checker should be available as a compiler option. As in, you're an adult: if you want it, you can have it, instead of "we know better".

Doesn’t work - you need the borrow checker guarantees to implement downstream compilation steps. You can just turn off assumptions

> 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.

Re: Rust--: Rust without the borrow checker

#160
post #148

Earlier quoted context omitted.

If you write correct Rust code it'll work, the borrowck is just that, a check, if the teacher doesn't check your homework where you wrote that 10 + 5 = 15 it's still correct. If you write incorrect code where you break Rust's borrowing rules it'll have unbounded Undefined Behaviour, unlike the actual Rust where that'd be an error this thing will just give you broken garbage, exactly like a C++ compiler. Evidently mil…

How are we still having the same trade off discussion being argued so black and white when reality has shown that both options are preferred by different groups. Rust says that all incorrect programs (in terms of memory safety) are invalid but the trade is that some correct programs will also be marked as invalid because the compiler can't prove them correct. C++ says that all correct programs are valid but the trade…

>C++ says that all correct programs are valid but the trade is that some incorrect programs are also valid.

C++ does not say this, in fact no statically typed programming language says this, they all reject programs that could in principle be correct but get rejected because of some property of the type system.

You are trying to present a false dichotomy that simply does not exist and ignoring the many nuances and trade-offs that exist among these (and other) languages.

Post reply on HN