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

The borrowchecker is what I like the least about Rust

viralinstruction.com

Post reply on HN
Print view View original

291–300 of 459 posts

Re: The borrowchecker is what I like the least about Rust

#291

Post by camgunz »

gdbsjjdn wrote: post #123
eigenspace wrote: post #11

I don't use Rust much, but I agree with the thrust of the article. However, I do think that the borrowchecker is the only reason Rust actually caught on. In my opinion, it's really hard for a new language to succeed unless you can point to something and say "You literally can't do this in your language" Without something like that, I think it just would have been impossible for Rust to gain enough momentum, and also…

Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…

The "X is like Y but Z" game w languages is pretty fun, and kind of illuminating as to what one thing you pick.

Go is like C but with concurrency/strings/GC/a good stdlib

Go is like C++ but simpler/fast compilation/no generics/a good stdlib

Go is like Python but statically typed/multithreaded/fast/single executable

Go is like Java but native/no OO

---

One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). Everything else is way older. Well, I would actually say that this is probably the cause of Go hate--if it weren't popular no one would care.

Re: The borrowchecker is what I like the least about Rust

#292

Post by phire »

vineethy wrote: post #93

The author's motivation for writing this is well-founded. However, the author doesn't take into account the full spirit of rust and the un-constructive conclusion doesn't really help anyone. A huge part of the spirit of rust is fearless concurrency. The simple seeming false positive examples become non-trivial in concurrent code. The author admits they don't write large concurrent - which clearly explains why they do…

Yeah, the author's theoretical "Rust but with garbage collector" would gain a whole bunch of concurrency bugs. It wouldn't be Rust anymore, just c# with a more functional syntax.

"Fearless concurrency" is one of the best things the borrow checker gives us, and I think a lot of people undervalue it.

Re: The borrowchecker is what I like the least about Rust

#293

Post by af78 »

Kranar wrote: post #185
gdbsjjdn wrote: post #123

Earlier quoted context omitted.

Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…

I can't substantiate your claim about Erlang or weird syntax, is that either a proper quote or some kind of paraphrasing because nothing remotely close to it comes up. There are numerous interviews with Rob Pike about the design of Go from when Go was still being developed, and Erlang doesn't come up in anything that I can find other than this interview from 2010 where someone asks Rob Pike a question involving Erlan…

The parent comment does not say that Go derives from Erlang, but that both Erlang and Go implement CSP (https://en.wikipedia.org/wiki/Communicating_sequential_proce...), with the advantage for Go over Erlang that its syntax is more familiar to programmers who know C.

Re: The borrowchecker is what I like the least about Rust

#294

Post by tialaramex »

camgunz wrote: post #291
gdbsjjdn wrote: post #123

Earlier quoted context omitted.

Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…

The "X is like Y but Z" game w languages is pretty fun, and kind of illuminating as to what one thing you pick. Go is like C but with concurrency/strings/GC/a good stdlib Go is like C++ but simpler/fast compilation/no generics/a good stdlib Go is like Python but statically typed/multithreaded/fast/single executable Go is like Java but native/no OO --- One thing Go haters rarely reckon with is that Go is the only popu…

> One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium).

This requires you to squint so that "popular" happens to identify only a handful of languages but conveniently catches Go and not say Swift or Rust. It's not difficult to do this, but it's not very honest to yourself.

Re: The borrowchecker is what I like the least about Rust

#295

Post by dontlaugh »

amelius wrote: post #109
mr_00ff00 wrote: post #26

Earlier quoted context omitted.

This is also somewhat backed up by the fact that OCaml (to my understanding) is basically GC Rust without a borrow checker, and yet it’s basically a hobby language.

Idiomatic programming in a functional language requires garbage collection. There is a reason languages like OCaml and Haskell have a garbage collector. Without it, programming in these languages would be completely different. If you look at it from that perspective, then Rust is the hobby language.

Not necessarily GC, but any kind of automated memory management that allows composition.

Re: The borrowchecker is what I like the least about Rust

#296

Post by Sesse__ »

camgunz wrote: post #291
gdbsjjdn wrote: post #123

Earlier quoted context omitted.

Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…

The "X is like Y but Z" game w languages is pretty fun, and kind of illuminating as to what one thing you pick. Go is like C but with concurrency/strings/GC/a good stdlib Go is like C++ but simpler/fast compilation/no generics/a good stdlib Go is like Python but statically typed/multithreaded/fast/single executable Go is like Java but native/no OO --- One thing Go haters rarely reckon with is that Go is the only popu…

> One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). Everything else is way older.

Rust. TypeScript. Swift.

Re: The borrowchecker is what I like the least about Rust

#297

Post by safercplusplus »

loeg wrote: post #212
nemothekid wrote: post #158

Earlier quoted context omitted.

> OP's argument that this approach violates the very reason the borrowchecker was introduced in the first place. No it doesn't. I just don't think author understands the pitfalls of implementing something like a graph structure in a memory unsafe language. The author doesn't write C so I don't believe he has struggled with the pain of chasing a dangling pointer with valgrind. There are plenty of libraries in C that e…

Indices can be dangling in almost exactly the same way as pointers. Worse, it's easier to accidentally use-after-free clobber some other item in the same structure, because allocations are "dense." (Pointer designs on systems where malloc/free is ~LIFO experience similar problems.)

Might I suggest that the scpptool-enforced safe subset of C++ has a better solution for such data structures with cyclic or complex reference graphs, which is run-time checked non-owning pointers [1] that impose no restrictions on how or where the target objects are allocated. Unlike indices, they are safe against use-after-destruction, and they don't require the additional level of indirection either.

[1] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...

Re: The borrowchecker is what I like the least about Rust

#298

Post by biorach »

pyrale wrote: post #94
mr_00ff00 wrote: post #26

Earlier quoted context omitted.

This is also somewhat backed up by the fact that OCaml (to my understanding) is basically GC Rust without a borrow checker, and yet it’s basically a hobby language.

> and yet it’s basically a hobby language. The difference between academia languages such as ocaml or haskell and industry languages such as Java or C# is hundreds of millions of dollar in advertising. It's not limited to the academy: plenty of languages from other horizons failed, that weren't backed by companies with a vested interest in you using their language. You should probably not infer too much from a langua…

> The difference between academia languages such as ocaml or haskell and industry languages such as Java or C# is hundreds of millions of dollar in advertising

Rust is a significant counterexample

Re: The borrowchecker is what I like the least about Rust

#299

Post by voidnap »

loeg wrote: post #212
nemothekid wrote: post #158

Earlier quoted context omitted.

> OP's argument that this approach violates the very reason the borrowchecker was introduced in the first place. No it doesn't. I just don't think author understands the pitfalls of implementing something like a graph structure in a memory unsafe language. The author doesn't write C so I don't believe he has struggled with the pain of chasing a dangling pointer with valgrind. There are plenty of libraries in C that e…

Indices can be dangling in almost exactly the same way as pointers. Worse, it's easier to accidentally use-after-free clobber some other item in the same structure, because allocations are "dense." (Pointer designs on systems where malloc/free is ~LIFO experience similar problems.)

This is well known to be solved by using generational indexes. Its not a big deal. The author's entire post is an overreaction/rage-bait.

Basically any data structure like this where you want it relocatable in memory is going to use indirection like indexes or something instead of pointers. Its a very common use case outside of rust.

Re: The borrowchecker is what I like the least about Rust

#300

Post by tialaramex »

ameliaquining wrote: post #192
School-Cotton wrote: post #18

Earlier quoted context omitted.

Fearless concurrency is only possible because of the borrow checker.

This isn't really right; Pony does static concurrency safety without borrow checking, and while Swift sort of has borrow checking it's mostly orthogonal to how static concurrency safety works there. The relationship between borrow checking and concurrency safety in Rust is closer to "they rhyme" than "they use the exact same mechanism".

You've provided reasons why other languages have other properties, but Rust's fearless concurrency requires borrow checking.

The concurrency focused trait Send only makes sense because we have control over references, through the borrow checker. Thread #1 can give Thread #2 this Doodad because it no longer has any references to it, if you try to give it a Doodad you're still referring to, then the borrow checker will reject your code. The Send trait guarantees that this (giving the Doodad to a different thread) is an OK thing to do - but only if you don't have outstanding borrows so you won't be able to look at the Doodad once you give it to Thread #2

Post reply on HN