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

341–350 of 459 posts

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

#341

Post by torginus »

zozbot234 wrote: post #308
citrin_ru wrote: post #306

Earlier quoted context omitted.

But gorutines are better than threads when you need you need many (say >100K) of them. Lightweight threads are not unique to Go but in Go they are easy to use and the default way to build network applications. Java is catching up with project Loom but it would never be as easy as Go to use.

> are better than threads when you need many (say >100K) of them Stackless coroutines are even more efficient for that case, and Rust makes them comparatively easy. (And slated to get even easier in future versions, as the async support is improved further.) Moreover stackful coroutines/fibers as used in Golang also makes it infeasible to have seamless FFI with the standard C API/ABI, which cuts you off from the bulk…

Stackless coroutines are what every language that has async/await (Js, C#) uses. I've seen them getting a lot of hate here for needing a special kind of method to run in and being less elegant than green threads.

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

#342

Post by torginus »

citrin_ru wrote: post #306
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…

But gorutines are better than threads when you need you need many (say >100K) of them. Lightweight threads are not unique to Go but in Go they are easy to use and the default way to build network applications. Java is catching up with project Loom but it would never be as easy as Go to use.

Why do you need that many threads? Linux doesn't even allow you that many file handles.

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

#343

Post by jyounker »

The author's first example seems to undermine the thesis. Their Point class allows two separate locations to independently update the X and Y fields, leaving the object in an inconsistent state.

It seems to me that this is exactly the sort of thing that Rust is intended to prevent, and it makes complete sense to reject the code.

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

#344

Post by oneshtein »

duped wrote: post #183

> My examples code above may not be persuasive to experienced Rustaceans. They might argue that the snippets don't show there is any real ergonomic problem, because the solutions to make the snippets compile are completely trivial. In the last example, I could just derive Clone + Copy for Id. No, you could use destructuring. This doesn't work for all cases but it does for your examples without needing to derive copy…

What stops you from writing such data container with interior mutability, like vec_cell[0], which then enforce borrowing rules at runtime?

[0]: https://github.com/alexanderved/vec_cell

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

#345

Post by torginus »

I'd argue the very reason Rust was created to get rid of the aliasing problem that's plaguing C-family languages, (meaning that there's always a chance 2 pointers refer to the same piece of memory, meaning all writes might potentially invalidate all variables).

This isn't really solvable in C/C++, and its worked around with a bunch of hacks, which might be overly convervative at times, and at others, generates buggy code.

Rust managed to fix this issue elegantly, but I'm wondering if the solution might be worse than the problem.

It's essentially impossible to write a Rust program without relying on many of its escape hatches like RefCell and unsafe, that make the borrow checker go away.

Essentially any program, that needs to communicate or store data in some sort of persistent structure, which is then accessed in some other part of the program, has multiple mutable references to said abstract central point, which is not allowed in Rust, without the aforementioned workarounds.

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

#346

Post by loeg »

conradludgate wrote: post #258
loeg wrote: 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.

The practical ramifications are often similar, even if UB can in theory do anything.

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

#347

Post by tialaramex »

camgunz wrote: post #325
tialaramex wrote: post #294

Earlier quoted context omitted.

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

Just searching for "programming language popularity": - TIOBE [0]: Go 7 :: Rust n/a (> 10) - IEEE Spectrum [1]: Go 8 :: Rust 11 - Stack Overflow [2]: Go 13 :: Rust 14 (they're pretty close here) - GitHub [3]: Go 10 :: Rust n/a (> 10) - PYPL [4]: Go 12 :: Rust 10 - HackerRank [5]: Go 8 :: Rust n/a (> 13) - Pluralsight [6]: Go 9 :: Rust n/a (> 10) - Redmonk [7]: Go 12 :: Rust 19 Although I admit we probably don't have…

You seem to be arguing that Go is more popular than Rust, but that's not what we're talking about.

The claim made was "Go is the only popular modern language (ie from this millennium)"

That's a binary, either a programming language is "modern" (from this millennium) or not and either it is "popular" (undefined) or it is not, Go is popular and modern according to the claim.

On your lists you find Go is anywhere from 7th to 13th in popularity. So apparently "popular" might mean 9th like Ada on TIOBE's list right? Or maybe "modern" includes Typescript, on several of these lists?

No, the whole contrivance is silly. Go is a relatively popular modern language, nobody is surprised to discover that. Is it the most popular? No. Is it the most modern? Also no.

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

#348

Post by aw1621107 »

spacechild1 wrote: post #319
aw1621107 wrote: post #281

Earlier quoted context omitted.

Concepts are basically a half solution - they check that a type has some set of properties, but they don't check that the implementation only uses those properties. As a result, even with concepts you can't know what types will work in a template without looking at the implementation as well. Example [0]: #include template concept fooable = requires(T t) { { t.foo() } -> std::same_as ; }; struct only_foo { int foo();…

> they check that a type has some set of properties, but they don't check that the implementation only uses those properties. I'd say that's a mistake of the person who wrote the template then. Also, there are Concepts where you absolutely know which types are allowed, e.g. std::same_as, std::integral, std::floating_point, etc.

> I'd say that's a mistake of the person who wrote the template then.

The fact that it's possible to make that mistake is basically the point! If "the whole point of concepts" were to "tell you what types you can successfully call it with" then that kind of mistake should not be possible.

It's true that there are certain cases where you know the full set of types you can use, but I'd argue that those are the less interesting/useful cases, anyways.

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

#349

Post by jandrewrogers »

IshKebab wrote: post #8

This post pretty much completely ignores the advantages of the borrow checker. I'm not talking about memory safety, which is it's original purpose. I'm talking about the fact that code that follows Rust's tree-style ownership pattern and doesn't excessively circumvent the borrow checker is more likely to be correct . I don't think that was ever the intent behind the borrow checker but it is definitely an outcome. So…

> code that follows Rust's tree-style ownership pattern

This is a pretty important qualification. Most low-level systems code doesn't and can't have this ownership structure. It provides a reason why Rust has more traction replacing code that could have been written in Java rather than e.g. C++ in the domains where C++ excels (like database engines).

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

#350

Post by Mawr »

zozbot234 wrote: post #251
tptacek wrote: post #231

Earlier quoted context omitted.

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…

Unfortunately, Golang has a whole lot of weird, pointless quirks in both its base language and standard library, compared to something with a more elegant and from-the-ground-up design, like Rust itself or perhaps OCaml/ReasonML. Not very good news if you want the language to just "get the hell out of your way". I suppose it's still way better than the "enterprise" favored alternative of Java/C# though!

> Rust itself or perhaps OCaml/ReasonML

So compared to... very niche languages? Go has exceptionally few quirks compared to mainstream languages.

Post reply on HN