Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust--: Rust without the borrow checker

github.com

Post reply on HN
Print view View original

161–170 of 269 posts

Re: Rust--: Rust without the borrow checker

#161

Post by qsera »

elbear wrote: post #138
qsera wrote: 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…

When I started learning Haskell, it did feel like coding with a straightjacket.

I think that is because when you start learning Haskell, you are not typically told about state monads, `IORefs` and likes that enables safe mutability.

It might be because Monads could have a tad bit advanced type machinery. But IORefs are straightforward, but typically one does not come across it until a bit too late into their Haskell journey.

Re: Rust--: Rust without the borrow checker

#162

Post by Wowfunhappy »

MangoToupe wrote: post #129
indigoabstract wrote: post #114

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

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.

You don't think assembly is more tedious to write than C? I don't think that's because of what C does/doesn't "allow" you to do.

Re: Rust--: Rust without the borrow checker

#163

Post by gpm »

qsera wrote: post #158
gpm wrote: post #137

Earlier quoted context omitted.

> "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 informat…

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

There is help from the compiler - the compiler lets the safe code expose an interface that creates strict requirements about how it is being called with and interacted with. The C language isn't expressive enough to define the same safe interface and have the compiler check it.

You can absolutely write the unsafe part in C. Rust is as good at encapsulating C into a safe rust interface as it is at encapsulating unsafe-rust into a safe rust interface. Just about every non-embedded rust program depends on C code encapsulated in this manner.

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

Good type systems describe the interface, not every implementation detail. Virality is the consequence of implementation details showing up in the interface.

Good type systems minimize the amount of work needed to use them.

IO is arguably part of the interface, but without further description of what IO it's a pretty useless detail of the interface. Meanwhile exposing a viral detail like this as part of the type system results in lots of work. It's a tradeoff that I think is generally not worth it.

Re: Rust--: Rust without the borrow checker

#164

Post by sakisv »

As someone who's only did a couple of small toy-projects in rust I was never annoyed by the borrow checker. I find it nothing but a small mental shift and I kinda like it.

What I _do_ find annoying though and I cannot wrap my head around are lifetimes. Every time I think I understand it, I end up getting it wrong.

Re: Rust--: Rust without the borrow checker

#165

Post by estebank »

vanviegen wrote: post #44
jokoon wrote: post #29

To me it feels like rust is barely readable sometimes. When I read some rust cost, I am often incapable to guess what it does, so it does not feel intuitive. I wish they made something simpler. At least C and C++ have a low barrier of entry and any beginner can write code. I don't think the borrow checker forced rust to be such a complicated language.

Yes, Rust has a pretty steep learning curve. If you're not writing very low level stuff and don't need to squeeze out every last bit of performance, there are many other, simpler languages to choose from. I think we may safely assume that Rust's designers are smart people that have made every effort to keep Rust as simple as it can be, given its intended use.

If you're not writing very low level stuff and don't need to squeeze out every last bit of performance, Rust code can be very simple and easy to understand as well.

Re: Rust--: Rust without the borrow checker

#166

Post by gpm »

torben-friis wrote: post #43

I’m not picturing how it works. In rust you don’t have a garbage collector and you don’t manually deallocate - if the compiler is not certain of who drops memory and when, what happens with those ambiguous drops ? In other words, are the silenced errors guaranteed to be memory leaks/use after frees?

I'm pretty sure that every example except example-3 in the readme intentionally invokes undefined behavior - if that helps you picture how it works ;)

Re: Rust--: Rust without the borrow checker

#167

Post by zeroxfe »

giancarlostoro wrote: post #152
accelbred wrote: post #147

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?

If Go had rust-style ADTs and pattern matching, and some parallel of "?" to short-circuit error handling, I'd be thrilled.

Re: Rust--: Rust without the borrow checker

#168

Post by dminik »

jjgreen wrote: post #128
tialaramex wrote: post #109

Earlier quoted context omitted.

Did I write that I hated somebody? I don't think I wrote anything of the sort. I can't say my thoughts about Bjarne for example rise to hatred, nobody should have humoured him in the 1980s, but we're not talking about what happened when rich idiots humoured The Donald or something as serious as that - nobody died, we just got a lot of software written in a crap programming language, I've had worse Thursdays. And alth…

Correct me if I'm wrong, but I don't think you think that C++ programmers actually want to write "broken garbage", so when you say "millions of people want broken garbage" the implication is that a) they do write broken garbage, b) they're so stupid don't even know that is what they are doing. I can't really read else than in the same vein as an apartheid-era white South-African statement starting "all blacks ...", i…

Considering how many people will defend C++ compilers bending over backwards to exploit some accidental undefined behaviour with "but it's fast though" then yeah, that's not an inaccurate assessment.

Re: Rust--: Rust without the borrow checker

#169

Post by qsera »

gpm wrote: post #163
qsera wrote: post #158

Earlier quoted context omitted.

>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 informat…

> 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? There is help from the compiler - the compiler lets the safe code expose an interface that creates strict requirements about how it is being called with and interacted with. The C language isn't expressive enoug…

>the compiler lets the safe code expose an interface that creates strict requirements about how it is being called with and interacted with..

The compiler does not and cannot check if these strict requirements are enough for the intended "safety". Right? It is the judgement of the programmer.

And what is stopping a `c` function with such requirements to be wrapped in some code that actually checks these requirements are met? The only thing that the rust compiler enables is to include a feature to mark a specific function as unsafe.

In both cases there is zero help from the compiler to actually verify that the checks that are done on top are sufficient.

And if you want to mark a `c` function as unsafe, just follow some naming convention...

>but without further description of what IO it's a pretty useless detail of the interface..

Take a look at effect-system libraries which can actually encode "What IO" at the type level and make it available everywhere. It is a pretty basic and widely used thing.

Re: Rust--: Rust without the borrow checker

#170

Post by accelbred »

giancarlostoro wrote: post #152
accelbred wrote: post #147

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?

For me its everything being an expression, macro_rules, dyn, automatic conversions (the few that it does have), traits, and the ? operator.
Post reply on HN