Live data from Hacker News

The borrowchecker is what I like the least about Rust

viralinstruction.com

431–440 of 459 posts

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

#431

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…

> Golang is basically just more concise Java

But golang/newsqueak was developed much earlier, in the early 80s by Rob Pike.

https://en.wikipedia.org/wiki/Newsqueak

```

type point: struct of{ x, y: int; }

a:=mk(array[10] of int) // mk renamed to make

select{ case i = ```

In the late 2000s, this language updated somewhat (for example, the mk function was renamed to make).

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

#432
post #241

Earlier quoted context omitted.

Non-UB data structure corruption and other incorrect behavior isn't like, super obviously better than UB corruption and other incorrect behavior.

The obvious upside is that it's so much easier to debug when there's no UB. Debugging UB is never enjoyable.

not sure I agree. UB has the benefit that there are a lot of tools like valgrind, memcheck, and various compiler features to detect it both statically and at runtime. And when you hit UB it is certainly an error.

Non-UB errors have no such powerful tools, only what application specific tests or assertions you create.

I've seen plenty of cases where people went and turned signed types into unsigned because signed overflow is undefined, but it had the real effect of turning easily detected and diagnosed issues into much harder to find bugs.

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

#433

Rust is pain when you want to be super basic with your types. This is actually a learning lesson for the user to understand that the bugs one has seen in languages like c++ are inherent to using simple types. The author goes about mentioning python. If you do change all your types to python equivalents, ref counted etc. Rust becomes as easy. But you don’t want to do that and so it becomes pain, but pain with a gain.…

I was surprised to have to scroll this far to see someone bring up that the comparison point seems to be Python... I mean, I have absolutely no difficulty believing the statement

> For every time I experience a bug in Python that would have been prevented in Rust by its borrowchecker, I experience maybe twenty borrowchecker issues.

Now, if you replace "Python" with C or C++, my guess is the ratio at _least_ equalizes if not flips entirely

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

#434

Earlier quoted context omitted.

Yes! One of the worst bugs to debug in my entire career boiled down to a piece of Java mutating a HashSet that it received from another component. That other component had independently made the decision to cache these HashSet instances. Boom! Spooky failure scenarios where requests only start to fail if you previously made an unrelated request that happened to mutate the cached object. This is an example where owner…

A weekend?

Yes. I learned Rust in a weekend. Basic Rust isn't that complicated, especially when you listen to the compiler's error messages (which are 42x as helpful compared with C++ compiler errors).

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

#435
post #426
post #422

Earlier quoted context omitted.

> And you can happily make Cgo calls to the windows libraries if you want to access windows APIs, the language provides an abstraction for the normal use case not the specific use case, theres an escape hatch if you want it. And regarding the complaint about timeouts, context is a thing. Not having to call into ffi/c libraries to modify files is the normal use case. Windows is the largest used operating system. > Bec…

> Not having to call into ffi/c libraries to modify files is the normal use case. A “systems” language designed by some smart people that is mostly targeted at the most deployed os in the world “cough not windows”, definitely does not need to make windows the default. > If it was intuitive you wouldn’t be able to “hold it wrong No unintuitive means if you understand the domain and idioms yet the interface still does…

I never said Windows should be the default. I implore you to please actually reread what I said and the article. Having to call into ffi to work with files on a major operating system is not normal. It is valid to criticize these decisions whether or not it’s a “systems” language made by “smart people”.

I can see this conversation will go no where though. This is the typical conversation with Go users when you point out any criticism of the language. Cheers man.

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

#436
> it manages to combine speed and low-level control with a high level of bug-resistance, more commonly referred to as safety.

This article didn't even make it 2 paragraphs before being incorrect. Safety isn't bug resistance - Safety is ensuring memory integrity. Bugs are still easy to write, they're just going to be logic bugs instead of use after frees, double frees, etc.

The first example of a function and access to fields misses point as well. If you just wanted to edit a field locally, you can do that without references. If you're sharing the struct around, then you don't want more than one mutable reference at a time anyway.

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

#437

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?

I'm a hobbiest, so I only write in it 4 times a week, but I only run into borrow checker issues when I refactor large portions of existing code.

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

#438
post #351

Earlier quoted context omitted.

Your "great read" is horrible.

From HN's guidelines: > Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. I'm curious to know why you think so, I thought it was a great article, showcasing how simplicity in the language doesn't make complexity go away, it just moves it to programs written in it.

Golangers really don’t like any criticism of their language.

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

#439
post #52

>The first time someone gave be this advice, I had to do a double take. 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. When the same borrowchecker makes references unworkable, their solution is to... recommend that I manually manage them, with zero safety and zero language supp…

Reminder that this is what the author said about safety: "it manages to combine speed and low-level control with a high level of bug-resistance, more commonly referred to as safety"

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

#440
post #172

Earlier quoted context omitted.

I know you're not supposed to berate people here for not reading TFA, but this really feels like a case where it's very frustrating to engage with you because you really should read TFA.

Well, I have read TFA. The author may have a point in the idea of borrowing record fields separately. It is possible if we assume that the fields are completely orthogonal and can be mutated independently without representing an incorrect state. It would be a good option to have. But a doubly-linked list (or graph) just can't be safely represented in the existing reference semantics. Dropping a node would lead to a d…

Look at vectors or hash maps. This is a perfect example of the Rust philosophy. Namely, writing complex low-level abstractions that offer a convenient and reliable high-level API.

It uses unsafe, but few people understand what it really is. Rust has clear invariants (for example, that a pointer to T always points to an existing and valid T) that are enforced by the compiler. Using unsafe code is shifting the enforcement of these invariants from the compiler to the programmer. The advantage compared to C is that unsafe code is limited to undefined blocks that are easy to test.

The data structure you describe should be done exactly this way. And it is not a task for the average programmer.

Post reply on HN