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

361–370 of 459 posts

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

#361

Post by airstrike »

torginus wrote: post #345

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…

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

I get this may be hyperbole but it's also just factually incorrect. Not only that, why is this even a goal? RefCell isn't a wart. It is part of Rust and meant to be used where it makes sense.

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

#362

Post by konart »

oneshtein wrote: post #339
konart wrote: post #302

Earlier quoted context omitted.

Serious being what? Most programmers are "lousy programmers" because most of the are not researchers and have no interest in theory. I can write in Go or Rust (or anything else given some time) but I won't ever use Rust to write any kind of business logic for my company - and this is what I do most of the time I actually write code. Why? Because Rust is terrible for the job (at least if we are talking about real life…

I can do business logic, like complex CRUD, in Rust much faster than in other languages. I assume, «lousy programmers» have problems with separation of concerns, which then cause problems with borrow checker, because developers need to perform different things in different ways on different parts of data structures (AKA «god object» anti-pattern).

> separation of concerns

but this would be a problem almost anywhere, no?

This has nothing to do with Rust vs Go vs Ruby or something else. Rust makes this even bigger problem, ok, but I don't think we should call people not using Rust (c\c++ etc) "lousy".

PS: tbh this kind of statements usually (from my experience) come from people who mainly write system level software or work with hardware directly.

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

#363

Post by dismalaf »

littlestymaar wrote: post #236
dismalaf wrote: post #112

Earlier quoted context omitted.

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.

I'm simply pointing out the irony in calling a (mostly game) scripting language like Lua "industrial" while calling a language used by FAANG, defense companies and finance companies a "hobby" language.

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

#364

Post by arresin »

klauserc wrote: post #275
pornel wrote: post #151

There are some artificial limitations, but I love the upside: I don't need defensive programming! When my function gets an exclusive reference to an object, I know for sure that it won't be touched by the caller while I use it, but I can still mutate it freely. I never need to make deep copies of inputs defensively just in case the caller tries to keep a reference to somewhere in the object they've passed to my funct…

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?

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

#365

Post by pornel »

nlitened wrote: post #307
pornel wrote: post #151

There are some artificial limitations, but I love the upside: I don't need defensive programming! When my function gets an exclusive reference to an object, I know for sure that it won't be touched by the caller while I use it, but I can still mutate it freely. I never need to make deep copies of inputs defensively just in case the caller tries to keep a reference to somewhere in the object they've passed to my funct…

> When my function gets an exclusive reference to an object, I know for sure that it won't be touched by the caller while I use it, but I can still mutate it freely. I love how this very real problem can be solved in two ways: 1. Avoid non-exclusive mutable references to objects 2. Avoid mutable objects Former approach results in pervasive complexity and rigidity (Rust), latter results in pervasive simplicity and fle…

Shared mutable state is the root of all evil, and it can be solved either by completely banning sharing (actors) or by banning mutation (functional), but Rust gives fine-grained control that lets you choose on case-by-case basis, without completely giving up either one. In Rust, immutability is not a property of an object in Rust, but a mode of access.

It's also silly to blame Rust for not having flexibility of a high-level GC-heavy VM-based language. Rust deliberately focuses on the extreme opposite of that: low-level high-performance systems programming niche, where Clojure isn't an option.

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

#366

Post by hinkley »

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…

Java, especially after generics were introduced, was a pain to use because of the type system. That’s not my opinion, I always found that claim a bit overwrought but it’s true that it was fairly widespread. Dealing with the type system got progressively a bit easier as the language evolved and certain types could be inferred. From the release notes I’ve seen I’ve gotten the impression that similar things have happened with the borrow checker. But people who have gone through the gauntlet have trouble reframing that experience and it’s always difficult to tell if the reputation is still accurate or not.

I am curious what the second language with a borrow checker will look like.

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

#368

Post by camgunz »

tialaramex wrote: post #347
camgunz wrote: post #325

Earlier quoted context omitted.

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

TL;DR: mostly what I mean is Go is the only language from this millennium that's consistently in the top 10 most popular programming languages.

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

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

Isn't this exactly what we're talking about? I don't think you have to squint too hard to invent the gap between Go and Rust (et al).

> So apparently "popular" might mean 9th like Ada on TIOBE's list right?

No because it's only on that list.

> Or maybe "modern" includes Typescript, on several of these lists?

No because TypeScript is JavaScript, which is from the last millennium.

> No, the whole contrivance is silly.

Emotionally I agree with you, but in practice you gotta pick a stack, and there's a lot of benefit to choosing Go over Rust/Kotlin/Swift/TypeScript/Java/C#/C/C++/Ada.

> Go is a relatively popular modern language, nobody is surprised to discover that.

Eh I'm making the Stroustrup "there's two kinds of programming languages" argument. IMO, at this point Go criticisms are just jeers from the cheap seats.

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

#369

Post by duped »

ethan_smith wrote: post #224
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…

Your example has an undefined 'source' variable - you likely meant 'curr' - but more importantly, this pattern can be solved with indices + interior mutability or split_at_mut() rather than unsafe, giving you safe simultaneous mutable access to different nodes.

That requires you use a Vec or similar data structure which may not be appropriate/forces you to reinvent garbage collection or deal with tombstoning/generations/etc for unused slots.

And I pointed out you can use interior mutability. Still sucks because the code is guaranteed sound, the compiler just can't prove it. IMO the correct choice is UnsafeCell and unsafe {}.

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

#370

Post by nemothekid »

ajross wrote: post #191
creata wrote: post #78

Earlier quoted context omitted.

> The trouble is that you've re-created dangling pointers That's true, but as a runtime mitigation, adding a generational counter (maybe only in debug builds) to allocations can catch use-after-frees. And at least it's less likely to be a security vulnerability, unless you put sensitive information inside one of these arrays.

> adding a generational counter (maybe only in debug builds) to allocations can catch use-after-frees. At the cost of making the use of the resulting heap significantly slower and larger than if you just wrote the thing in Java to begin with, though! The resulting instrumentation is likely to be isomorphic to GC's latency excursions, even. This is the biggest issue that bugs me about Rust. It starts from a marketing…

>It starts from a marketing position of "Safety With No Compromises" on runtime metrics like performance or whatever, then when things get hairy it's always "Well, here's a very reasonable compromise".

Well, yes. The other compromise is the one Java gives you: write a state of the art garbage collector and include it in your program.

This complaint is very annoying because it assumes a garbage collector is "free" and Rust decided to just not give you one. If you want memory safe trees your options are

* A slow, simple, reference counted garbage collector

* A fast, complex, garbage collector

both are compromises! You are just ignoring the second one.

Post reply on HN