Live data from Hacker News

The borrowchecker is what I like the least about Rust

viralinstruction.com

441–450 of 459 posts

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

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

> is more likely to be correct. This is a moot statement. Here is a thought experiment that demonstrates the pointlessness of languages like Rust in terms of correctness. Lets say your goal is ultimate correctness - i.e for any possible input/inital state, the program produces a known and deterministic output. You can chose 1 of 2 languages to write your program in: First is standard C Second is an absolutely strict…

> Second is an absolutely strict programming language, that incorporates not only memory membership Rust style, but every single object must have a well defined type that determines not only the set of values that the object can have, but the operations on that object, which produce other well defined types. Basically, the idea is that if your program compiles, its by definition correct.

That is Rust? This is how his system of types and traits works.

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

#442

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

My first thought when I was learning Rust was "Why don't they use a different operator for move?", something like:

let a let b let j = 0; // Copy

let k = j;

This may not be convenient, but it could be useful for educational purposes.

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

#443

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

My first thought when I was learning Rust was "Why don't they use a different operator for move?", something like: let a let b let j = 0; // Copy let k = j; This may not be convenient, but it could be useful for educational purposes.

A long time ago, you would use the move keyword for this. The issue is that it’s just redundant, so it feels like unnecessary boilerplate.

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

#444

Earlier quoted context omitted.

My first thought when I was learning Rust was "Why don't they use a different operator for move?", something like: let a let b let j = 0; // Copy let k = j; This may not be convenient, but it could be useful for educational purposes.

A long time ago, you would use the move keyword for this. The issue is that it’s just redundant, so it feels like unnecessary boilerplate.

...and using it in function calls would also be inconvenient.

Now I have a clear understanding of what is happening and how.

Nevertheless, using something like this for educational purposes maybe could help. Author of the article In the example with Id literally complains that moving makes moving.

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

#445
post #435
post #426

Earlier quoted context omitted.

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

> Having to call into ffi to work with files on a major operating system is not normal.

You don’t. Normal operation like reading writing modifying and creating works just fine in windows.

The only thing that doesn’t is explicitly permissions where windows is the outlier and uses (imho a better) method of managing permissions. However they are the outlier and it is an uncommon operation. Why would the stdlib cater for that?

If you need to alter permissions at a more granular level on windows than is possible using golangs interface then call into the ffi, but in general you don’t need to to that.

If that is your only criticism then I agree we will not agree on this point, it is however also trivial to make ffi calls using go

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

#446

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.

This is very contrary to my experience. I don't use cloning or various primitives (except when I really need the shared state).

I can assume that you have this opinion because you see it as a low-level problem while its solution lies at the architectural level.

Use pure functions, group data in structures that own it, get all the necessary data in the controller, process it, and return or store it.

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

#447

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?

Maybe once or twice a month I'll get some language issue (like no negative trait bounds, restrictions on generic const, or something related to lifetime). I might spend an hour or more on each such case.

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

#448
post #399
post #153

Earlier quoted context omitted.

> hundreds of millions of dollar Yes. > in advertising No, in hiring 500 compiler and tool developers, developing and supporting libraries, optimizing it for niche use cases.

The Java ecosystem has benefited from way more than that. I was specifically refering to advertising. For instance this kind of headlines [1]. [1]: https://www.theregister.com/2003/06/09/sun_preps_500m_java_b...

This never played out, Sun ran out of money.

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

#449

Earlier quoted context omitted.

(I've successfully resisted the urge to make my entire reply "Wait, you don't like Judge Dredd?") I feel like we both understand each other at this point so I'll ask because I'm curious, what languages are you into? I'd really like a chance to dig into Erlang, OCaml, or Racket, but I can never really justify it. Mostly I'm a boring C/Python person (believe it or not, I don't like Go all that much)

Oh also, well, "Judge Dredd" was just not a very good movie. Not reprehensibly bad . Nobody involved should be sorry for making it, but not worth the price of a ticket. Swing and a miss. In contrast "Batman & Robin" is terrible. Clooney said he didn't want friends and family to see it because he is rightfully ashamed to have done it. Sometimes an actor does good work but it's hard to see because the technicians are i…

This is an intriguing anti-endorsement; I was too cool for Batman when this came out, but I feel like I have to watch this now haha.

I actually lived near a movie theater that got bought out by someone very weird and ostensibly rich, and they just played bad movies to jeer at and mock, and every... Friday was Rocky Horror Picture Show night. I think the small town I was in revolted and raised money to then buy that guy out, but man what a time. Surprised they didn't screen this steamer lol, is all I'm saying.

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

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

[deleted]
Post reply on HN