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

231–240 of 459 posts

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

#231

Post by tptacek »

nine_k wrote: post #179
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…

Due to lack of many abstractions, and lack of exceptions, Go is a less concise Java. It's a language where the lack of expressiveness forces you to write simpler code. (Not that it helps too much.) Go's selling points are different: it takes a weekend to learn, and a week to become productive, it has a well-stocked standard library, it compiles quickly, runs quickly enough, and produces a single self-contained execut…

People sometimes say this like it's a dunk, but there's a finite amount of complexity any given programming task can shoulder, you have to allocate it somehow between the programming environment, the problem domain you're working on, and the algorithmic sophistication you bring to bear on that problem, and it's not clear to me what the benefit is in allocating more than you need to your programming language.

A lot of very smart stuff is written in Go by programmers who just want the language to get the hell out of their way. Go is some ways very good at that. Rough though if you want your programming language to model your problem domain or your algorithmic approach! TANSTAAFL.

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

#232

Post by tptacek »

gdbsjjdn wrote: post #173
fmbb wrote: post #164

Earlier quoted context omitted.

> Golang is basically just more concise Java. That is exactly how it was sold. A safe C, or a nicer simpler Java. Nobody cared about Erlang back then and nobody does today. I write Erlang for a living.

I was an early Golang dev and people were _crazy_ with channels for a couple years. I remember the most popular Golang Kafka client was absolute spaghetti of channels and routines. It's never been "safe C" because it's garbage collected. Java is truly the comp because it's a great Grug language. I also wrote some Erlang in the past, I really enjoy it and I was sad that Go didn't borrow more.

This is "share by communicating, don't communicate by sharing". Pretty much everyone agrees it's a good thought. ~Most programs get there just fine with channels, because ~most code isn't so performance sensitive that channel limitations matter. Go leaves plenty of room for the rest of programs to do something else. Seems good.

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

#233

Post by TylerE »

packetlost wrote: post #210
dgfitz wrote: post #181

Earlier quoted context omitted.

> rust has a C++-flavored syntax I do not at all agree with this. Rust is by far the most complex language in terms of syntax that has ever become popular enough to compare it to anything.

I 100% disagree with this. Typescript is syntactically far more complex.

Complex isn't the same thing as hard. The rust syntax often times looks like a cat walked across the keyboard.

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

#234

Post by airstrike »

yahoozoo wrote: post #213

For those who program a lot (daily) in Rust, how often do you run into borrow checker issues? Or are lifetime scopes second nature at this point?

Very rarely, but it depends on the domain and/or the part of the code I'm writing.

For context, I mostly write GUI apps using `iced` which is inspired by Elm, so the separation between reading and writing state is front and center and makes it easy for me to avoid a whole set of issues.

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

#235

Post by tptacek »

nemothekid wrote: post #158
timmytokyo wrote: post #97

Earlier quoted context omitted.

If using indices is going to be your answer, then it seems to me you should at least contend with the OP's argument that this approach violates the very reason the borrowchecker was introduced in the first place. From the post: "The Rust community's whole thing is commitment to compiler-enforced correctness, and they built the borrowchecker on the premise that humans can't be trusted to handle references manually. Wh…

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

Whoah, hold on, the author isn't comparing writing graph structures in Rust to writing it in memory-unsafe languages --- they're comparing it to writing it in other memory-safe languages. You can't force a false dichotomy between Rust and C to rebut them.

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

#236

Post by littlestymaar »

dismalaf wrote: post #112
littlestymaar wrote: post #98

Earlier quoted context omitted.

Non-hobby languages is a narrow club, yes. Your list is at least missing PHP, Typescript, Swift, Go, Lua, Ruby and Rust though. But Ocaml really doesn't belong anywhere close to this list.

Ummm Lua? It's a nice little scripting language, but literally never seen a job ad for a job using mostly Lua. It's almost the definition of hobby language... OCaml runs software that billions use, is used by financial and defense firms, plus Facebook. But Lua? By that metric I'm throwing in every language I've ever seen a job for... R, Haskell, Odin, Lisp, etc... Edit - this site is basically a meme at this point. R…

As others already pointed out, Lua is used in tons of video games as the scripting language.

The most famous example being World of Warcraft, but it's far from the only one. If you play, or have played, games, you almost certainly have run software built with Lua without realizing it.

It's not because a language isn't relevant in your personal coding niche that it's not industrially relevant.

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

#237

Post by littlestymaar »

ameliaquining wrote: post #217
littlestymaar wrote: post #32

Earlier quoted context omitted.

Ah I see. > A more precise way to phrase what he's getting at would be something like "all types that _can_ implement `Copy` should do so automatically unless you opt out", which is not a crazy thing to want, From a memory safety PoV it's indeed entirely valid, but from a programming logic standpoint it sounds like a net regression. Rust's move semantics are such a bliss compared to the hidden copies you have in Go (…

Is it a particularly terrible thing, in and of itself, to pass structs by value? Less implicit aliasing seems less bug-prone. Note that Go only has implicit shallow copies (i.e., this only affects the direct fields of a struct or array); all other builtin types either are deeply immutable (booleans, numbers, strings), can point to other variables (pointers, slices, interfaces, functions), or are implicit references t…

I'd argue that move semantics is strictly superior to value semantics.

But more importantly, my point is that in a world where pretty much all modern languages except Go have pointer semantics by default, and when you language needs to have move semantics for memory safety in many cases, having yet another alien (to most developers) behavior is really pushing the complexity bar up for no particular gains.

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

#238

Post by hardwaresofton »

fmbb wrote: post #164
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…

> Golang is basically just more concise Java. That is exactly how it was sold. A safe C, or a nicer simpler Java. Nobody cared about Erlang back then and nobody does today. I write Erlang for a living.

> Nobody cared about Erlang back then and nobody does today. > > I write Erlang for a living.

I think this is incredibly correct and obviously personally true for you but I'd like to add one more thing from the peanut gallery.

No one really needs Erlang either. Turns out most problems are just fine not being modeled in the way that Erlang wants to model problems.

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

#239

Post by ordu »

> Data races in multithreaded code are elegantly and statically prevented by Rust. I have never written a large concurrent Rust program, and I'll grant the possibility that the borrowchecker is miraculous for that use case and easily pays for its own clunkiness.

Data races prevented not just in concurrent programs. I personally was hit once by a panic from RefCell. I have coded a data race, but I wouldn't notice it without RefCell. I borrowed the value and then called some function, and a several stack frames deeper I tried to borrow it mutably.

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

#240

Post by bombela »

burntsushi wrote: post #230
loeg wrote: post #212

Earlier quoted context omitted.

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

Except for the fact that one leads to undefined behavior and the other doesn't. This is a massive difference.

This might not seem obvious. So allow me an attempt at expanding a bit.

The difference is that a dangling raw pointer to the heap will point to anything that can be modified at any time.

But indexing a dynamic array guarantees that every elements is always well formed and safe to use.

Post reply on HN