Live data from Hacker News

The borrowchecker is what I like the least about Rust

viralinstruction.com

131–140 of 459 posts

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

#131
If you notice a rule for the first time, restricting what you want to do and making you jump through a hoop, it can be hard to see what the rule is actually for. The thrust of the piece is 'there should not be so many rules, let me do whatever I want to do if the code would make sense to me'. This does not survive contact with (say) an Enterprise Java codebase filled with a billion cases of defensive strict immutability and defensive copies, because the language lacks Rust's rules and constructs about shared mutability and without them you have to use constant discipline to prevent bugs. `derive(Copy)` as One More Pointless Thing You Have To Do only makes sense if you haven't spent much time code-reviewing someone's C++.

If you try to write Java in Rust, you will fail. Rust is no different in this regard from Haskell, but method syntax feels so friendly that it doesn't register that this is a language you genuinely have to learn instead of picking up the basics in a couple hours and immediately start implementing `increment_counter`-style interfaces.

And this is an inexperienced take, no matter how eloquently it's written. You can see it immediately from the complaint about CS101 pointer-chasing graph structures, and apoplexy at the thought of index-based structures, when any serious graph should be written with an index-based adjacency list and writing your own nonintrusive collection types is pretty rare in normal code. Just Use Petgraph.

A beginner is told to 'Just' use borrow-splitting functions, and this feels like a hoop to jump through. This is because it's not the real answer. The real answer is that once you have properly learned Rust, once your reflexes are procedural instead of object-oriented, you stop running into the problem altogether; you automatically architect code so it doesn't come up (as often). The article mentions this point and says 'nuh uh', but everyone saying it is personally at this level; 'intermittent' Rust usage is not really a good Learning Environment.

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

#132
post #48
post #43

Earlier quoted context omitted.

Rather, an academia language. Also, OCaml had trouble with multithreading for quite some time, which was a limiting factor for many applications. Facebook made a large effort to thrust OCaml into the limelight, and even wrote a nice alternative frontend (Reason). Sadly, it did not stick.

I had the impression that SML was more popular in academia, and OCaml in industry. Old but funny comparison: http://adam.chlipala.net/mlcomp/

If by "popular in industry" you mean a handful of companies use it, but has 1/100th the momentum and community and resources of Go or Rust, then yes.

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

#133

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…

> But Lua?

Lua, Bash ... these are birds of a feather. They are the glue holding things together all over the place. No one thinks about them but if they disappeared over night a LOT of stuff would fall apart.

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

#134
post #48

Earlier quoted context omitted.

I had the impression that SML was more popular in academia, and OCaml in industry. Old but funny comparison: http://adam.chlipala.net/mlcomp/

If by "popular in industry" you mean a handful of companies use it, but has 1/100th the momentum and community and resources of Go or Rust, then yes.

I meant among ML-family languages.

> 1/100th the momentum and community and resources of Go or Rust

I think even 1/100 would be pretty generous.

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

#135
I think the borrow checker doesn't get enough credit for supporting one of rusts other biggest selling points - it's ecosystem. In C and C++ libraries often go through pains to pass as little allocated memory over the API barrier as possible, communicating about lifetime constraints and ownership is flimsy and frequently causes crashes. In Rust if a function returns Vec then every Foo is valid until dropped, and if it's not someone did something unsafe.

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

#136
post #94

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…

C, C++, Python, Perl, Ruby, didn't have "millions of dollars in advertising", and yet.

Java and C# are the only one's that fit this. Go and Rust had some publicity from being associated with Google and Mozilla, but they both caught on without "millions of dollars in advertising" too. Endorsement by big companies like MS came much later for Rust, and Google only started devoting some PR to Go after several years of it already catching momentum.

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

#137

Earlier quoted context omitted.

Maybe I’m wrong, but I only really know of Jane Street for OCaml, meanwhile FAANG all has at least some rust code. Also I would argue the rust compiler started as a hobby project

Facebook Messenger's backend was/is OCaml... React was originally written in SML, then OCaml, then whatever it is now. And a bunch of places use it for various things. https://ocaml.org/industrial-users

React is and has always been javascript…

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

#138
I used Rust for about an hour and immediately ran into an issue I found amusing.

The compiler changed the type of my variable based on its usage. Usage in code I didn't write. There was no warning about this (even with clippy). The program crashed at runtime.

I found this amusing because it doesn't happen in dynamic languages, and it doesn't happen in languages where you have to specify the types. But Rust, with its emphasis on safety, somehow lured me into this trap within the first 15 minutes of programming.

I found it more amusing because in my other attempts at Rust, the compiler rejected my code constantly (which was valid and worked fine), but then also silently modified my program without warning to crash at runtime.

I saw an article by the developers of the Flow language, which suffered from a similar issue until it was fixed. They called it Spooky Action at a Distance.

This being said, I like Rust and its goals overall. I just wish it was a little more explicit with the types, and a little more configurable on the compiler strictness side. Many of its errors are actually just warnings, depending on your program. It feels disrespectful for a compiler to insist it knows better than the programmer, and to refuse to even compile the program.

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

#140
post #70

One of his examples of a borrow checker excess: struct Id(u32); fn main() { let id = Id(5); let mut v = vec![id]; println!("{}", id.0); } isn't even legit in modern C++. That's just move semantics. When you move it, it's gone at the old name. He does point out two significant problems in Rust. When you need to change a program, re-doing the ownership plumbing can be quite time-consuming. Losing a few days on that is…

I always say for people coming from C++ ... just imagine a std::move is there around everything (well, except for things that are Copy) ... then it will all make sense.

The problem is this mental model is entirely foreign to people who have worked in literally every other language where pass by value (copy or pass by reference are the way things work, always.

Post reply on HN