Live data from Hacker News

The borrowchecker is what I like the least about Rust

viralinstruction.com

411–420 of 459 posts

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

#411
post #5

Earlier quoted context omitted.

> For the disjoint field issues raised, it’s not that the borrow checker can’t “reason across functions,” it’s that the field borrows are done through getter functions which themselves borrow the whole struct mutably Right, and even more to the point, there's another important property of Rust at play here: a function's signature should be the only thing necessary to typecheck the program; changes in the body of a fu…

Exactly. We've talked about fixing this, but doing so without breaking this encapsulation would require being able to declare something like (syntax is illustrative only) `&mut [set1] self` and `&mut [set2] self`, where `set1` and `set2` are defined as non-overlapping sets of fields in the definition of the type. (A type with private fields could declare semantic non-overlapping subsets without actually exposing whic…

You could it in a more limited fashion by allowing fields of a struct to be declared "const", which would have similar semantics to Java's final. If you add the ability to return const references, you get the ability to have read only and mutable references to stuff within a struct co-exist.

For example, this won't compile:

    struct Something { z: usize }
    struct Foo { x: usize, y: &'a Something }
    impl Foo {
        fn bar(&mut self) -> &Something
        { let something = self.bar(); self.x += something.z; something }
    }
But if you could tell the borrow checker the mutable borrow of self can never modify z, then it would be safe. This would achieve that:

    struct Something { z: usize }
    struct Foo { x: usize, y: &'a const Something }
    impl Foo {
        fn bar(&mut self) -> &const Something
        { let something = self.bar(); self.x += something.z; something }
    }
I've now had several instances where they would have let me win a battle with the borrow checker succinctly rather than the long work around I was forced to adopt. Const struct members allow you implement read only fields with having to hide them, and provide getters is icing on the cake.

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

#412
post #376

Earlier quoted context omitted.

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

Well, in some sense. But in practice, come on: "write your own slow simple reference-counted GC" is a rather more expensive compromise than "just use Java or Go or whatever, it's faster and simpler for your problem". Aside from all the nitpickery about runtime implementation, the rustacean community has a serious problem with compromise in general. If you whine in a python/Go/Java/whatever forum about performance, th…

> But come at rust with a use case (cyclic data structures here) for which it's a poor fit

I'm not even disagreeing in general that Java is likely to be better for most problems. But the options in Rust for cyclic data are actually fine:

* You can use integer indices into an array instead of pointers.

* You can use unsafe and raw pointers, and be in the exact same situation as C++. The doubly linked list in the standard library is a cyclic data structure does that.[1]

* You can use reference counting (std::rc)[0]. This is literally a garbage collector in the standard library, equivalent to C++'s std::shared_ptr.

These are all simple. None of them is as complicated as "write your own GC".

[0]: https://doc.rust-lang.org/stable/std/rc/

[1]: https://doc.rust-lang.org/std/collections/struct.LinkedList....

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

#413

Earlier quoted context omitted.

This isn't true in practice. People don't write impossibly comprehensive test suites in C, and they don't use extremely loose types in Rust either. It really does matter which language you choose if you want correct code. > programming in something like C is going to be more efficient, whereas the second language will force you write a lot more code for basic things. Like how string manipulation is so much simpler an…

Also practice, most of Rust codebases are filled with `unsafe`, for interface with system libraries. Also the argument of forcing a language onto a project based on the lowest common denominator of programmers never plays out - this is how you get insanely messy Java codebases. Language choice will never solve poor programming style. >Like how string manipulation is so much simpler and easier in C compared to Rust? H…

> most of Rust codebases are filled with `unsafe`

That is absolutely untrue. Most Rust codebases have very few uses of `unsafe`. I have written tens of thousands of lines of Rust and used `unsafe` I think once. Maybe twice.

> Language choice will never solve poor programming style.

It absolutely does. Rust pushes you very strongly into the "pit of success". You can Google that term if you want to learn.

> Plenty of libraries for C for this.

I have yet to see a single C program in the wild use anything other than libc for string manipulation. I'm sure they exist but they are the 0.1%.

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

#414

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?

Yeah that's definitely optimistic. More like 1-6 months depending on how intensively you learn. It's still worth it though. It easily takes as long to learn C++ and nobody talks about how that is too much.

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

#415
post #371

Earlier quoted context omitted.

The whole point is that languages like Java won't keep track of what's "shared" or "mutable" for you. And no, it doesn't just trip up "very junior developers in code review", quite the opposite. It typically comes up as surprising cross-module interactions in evolving code bases, that no "code review" process can feasibly catch.

Speak for yourself. I haven't seen any bug like this in Java for years. You think you know better and my experience is not valid? Ha. Ok. Keep living in your dreams.

Yes I think he knows better and your experience is not valid.

Well, maybe not valid, but insufficient at least.

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

#416
post #280

Earlier quoted context omitted.

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

It’s pretty common to implement graphs in terms of arrays, not because of indices but because of cache locality. So your “UB” and “non-UB” code would look effectively identical to the CPU and would take the same amount of debugging. The reality is whether an index was tombstones and referenced or “deallocated” and referenced it is still a programmer fault that is a bug that the compiler could not catch

> So your “UB” and “non-UB” code would look effectively identical to the CPU and would take the same amount of debugging.

Said the person who has never had to debug serious UB...

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

#417

Earlier quoted context omitted.

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.

There's no irony, bash and VB6, no matter what you think about the quality of the said languages, are also scripting language and neither are in the “hobby language” category as their use is (or was) very broadly distributed. OCaml's use is comparatively very, very narrow. And, in case you are wondering, I have absolutely nothing again OCaml. In fact, my first ever programming language was, as a significant fraction…

Dassault Systèmes makes defense software, among other things... https://www.3ds.com/industries/aerospace-defense

Dassault Aviation makes the planes themselves. All Dassault companies are under one umbrella anyway.

The OCaml website lists a bunch of other users.

In my opinion, none of that really matters, any single one of those uses proves it's utility... Facebook Messenger alone is probably used by more people than every piece of Lua software ever made though.

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

#418

Earlier quoted context omitted.

I think it's reasonable enough. The author already argued that there are reasons for non GC languages to exist, even if the performance doesn't matter to them. One interpretation of the article is just the author doesn't personally like the borrow checker, but another interpretation is the author saying the borrow checker is just a bad abstraction. So under the assumption that we don't have a GC available, what else…

Author here. Yeah, I don't like the borrowchecker. But the motivation for me writing the article is the almost religious zeal with which many Rustaceans refuse to even acknowledge that the borrowchecker has a cost in terms of ergonomics, and that this translates to e.g. iteration speed. You encounter borrowchecker issues? Well, you're just a beginner or not skilled enough. Rust makes you jump through hoops? No it doe…

You should look up the term "zero cost abstractions".

It's the organizing principle of the second generation of Rust's leadership[1]. Formally, it means "zero runtime cost"[2], but the now-former maintainers operated as though it meant Rust could get rid of all cost. The belief was that they can have a language that's faster than C, safer than Ada, more ergonomic than Java, more memory safe than Go, by either making the compiler do more work, or working more on the compiler. In practice, I think this belief caused massive complexity in the compiler, trade-off dishonesty in the community, and bad evangelism in domains unsuited for memory safety (e.g. games programming)

[1] Graydon, the original author of Rust, was against this idea.

[2] The term originates from C++ as "zero overhead" which was smaller in scope, and not a governing principle of the C++ language.

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

#419

Earlier quoted context omitted.

Author here. Yeah, I don't like the borrowchecker. But the motivation for me writing the article is the almost religious zeal with which many Rustaceans refuse to even acknowledge that the borrowchecker has a cost in terms of ergonomics, and that this translates to e.g. iteration speed. You encounter borrowchecker issues? Well, you're just a beginner or not skilled enough. Rust makes you jump through hoops? No it doe…

You should look up the term "zero cost abstractions". It's the organizing principle of the second generation of Rust's leadership[1]. Formally, it means "zero runtime cost"[2], but the now-former maintainers operated as though it meant Rust could get rid of all cost. The belief was that they can have a language that's faster than C, safer than Ada, more ergonomic than Java, more memory safe than Go, by either making…

> but the now-former maintainers operated as though it meant Rust could get rid of all cost.

It always referred to runtime overhead, always. Same as C++. Which does consider it a foundational principle: https://www.stroustrup.com/ETAPS-corrected-draft.pdf

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

#420

Earlier quoted context omitted.

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

Just as a someone with a hammer could truthfully claim they don’t need a nail gun. Not that I think Erlang manages to be a nail gun; it has enough idiosyncrasies that the comparison is not terribly accurate. Still, “need” is doing a lot of heavy lifting in that sentence.

> Not that I think Erlang manages to be a nail gun; it has enough idiosyncrasies that the comparison is not terribly accurate. Still, “need” is doing a lot of heavy lifting in that sentence.

Yeah it was a bit vague -- I should have said something more like "not many developers/teams/companies need telecom level uptime and resilience enforced at the single system level". In reality, most groups have solved this by redundancy and building multiple systems/distributing them. You could argue it's the wrong solution, but it's been good enough for so many people that... it's probably fine.

Post reply on HN