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

111–120 of 459 posts

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

#111

Post by TuxSH »

dismalaf wrote: post #83
littlestymaar wrote: post #38

Earlier quoted context omitted.

Realistically unless you want to work at Jane Street or Inria (the French computer science lab where Ocaml was made), if you want to use Ocaml, it's going to be as a hobby.

You can say that for almost any language that's not C/C++, C#, Java, Python and JS. Rust is just barely beginning to become "corporate". Even Ruby, which is pretty mainstream, has relatively few jobs compared to the big corporate languages.

Speaking of Ruby, its usage has cratered down in the past decade: https://madnight.github.io/githut/#/pull_requests/2024/1

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

#112

Post by dismalaf »

littlestymaar wrote: post #98
dismalaf wrote: post #83

Earlier quoted context omitted.

You can say that for almost any language that's not C/C++, C#, Java, Python and JS. Rust is just barely beginning to become "corporate". Even Ruby, which is pretty mainstream, has relatively few jobs compared to the big corporate languages.

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. Roblox is industrial strength but Facebook, Dassault and trading firms are "hobby". Lol.

Also, I'm not dissing Lua, there's just irony in calling Lua industrial but not OCaml...

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

#113

Post by gunnarmorling »

GC also has its downsides:

- Marking and sweeping cause latency spikes which may be unacceptable if your program must have millisecond responsiveness.

- GC happens intermittently, which means garbage accumulates until each collection, and so your program is overall less memory efficient.

With modern concurrent collectors like Java's ZGC, that's not the case any longer. They show sub-millisecond pause times and run concurrently. The trade-off is a higher CPU utilization and thus reduced overall throughput, which if and when it is a problem can oftentimes be mitigated by scaling out to more compute nodes.

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

#114

Post by ok123456 »

aapoalas wrote: post #46
ok123456 wrote: post #29

Earlier quoted context omitted.

Typescript has escape hatches so you can just say "I don't care, or don't know." With Rust, you're battling a compiler that has a very restrictive model, that you can't shut up. You will end up performing major refactors to implement what seem like trivial additions.

You can always use `Box ` to get the same result in Rust :)

It's not the same because putting it in a box semantically changes the program, adds a level of indirection. It's not just telling it to go away.

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

#115

Post by ChadNauseam »

majormajor wrote: post #10
sowbug wrote: post #7

Earlier quoted context omitted.

See Rust's golden rule: https://steveklabnik.com/writing/rusts-golden-rule

This seems to be a golden rule of many languages? `return 3` in a function with a signature that says it's going to return a string is going to fail in a lot of places, especially once you exclude bolted-on-after-the-fact type hinting like what Python has. It's easier to "abuse" in some languages with casts, and of course borrow checking is not common, but it also seems like just "typed function signatures 101". Are…

My interpretation of the post is that the rule is deeper than that. This is the most important part:

> Here is the most famous implication of this rule: Rust does not infer function signatures. If it did, changing the body of the function would change its signature. While this is convenient in the small, it has massive ramifications.

Many languages violate this. As another commenter mentioned, C++ templates are one example. Rust even violates it a little - lifetime variance is inferred, not explicitly stated.

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

#116

Post by maleldil »

dismalaf wrote: post #112
littlestymaar wrote: post #98

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…

Lua is widely used for scripting in games. It might not be the main language of the project, but it's still very common.

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

#117

Post by luckystarr »

ChadNauseam wrote: post #105

> [The pain of the borrow checker is felt] when your existing project requires a small modification to ownership structure, and the borrowchecker then refuses to compile your code. Then, once you pull at the tiny loose fiber in your code's fabric, you find you have to unspool half your code before the borrowchecker is satisfied. Probably I just haven't been writing very "advanced" rust programs in the sense of doing…

I believe it. I experienced this once, as I tried to have everything owned. Now I just clone around as if there's no tomorrow and tell myself I'll optimize later.

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

#118

Post by eigenspace »

nine_k wrote: post #79
eigenspace wrote: post #67

Earlier quoted context omitted.

The author is a bioinformatician writing scientific software, and often switching back and forth between Rust, Julia, and Python. His concerns and priorities are not the same as people doing systems-level programming.

Maybe Rust, a systems language, is just a wrong tool for bioinformatic tasks. Go, Java, Typescript, Ocaml, Scala, Haskell easily offer a spectrum from extreme simplicity to extreme expressiveness, with good performance and library support, but without needing to care about memory allocation and deallocation. (Python, if you use it as the frontend to pandas / polars, also counts.)

I know you're not supposed to berate people here for not reading TFA, but this really feels like a case where it's very frustrating to engage with you because you really should read TFA.

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

#119

Post by dismalaf »

TuxSH wrote: post #111
dismalaf wrote: post #83

Earlier quoted context omitted.

You can say that for almost any language that's not C/C++, C#, Java, Python and JS. Rust is just barely beginning to become "corporate". Even Ruby, which is pretty mainstream, has relatively few jobs compared to the big corporate languages.

Speaking of Ruby, its usage has cratered down in the past decade: https://madnight.github.io/githut/#/pull_requests/2024/1

Well, it was hyped beyond belief at one point... Kind of nice that it's back to being niche, I'd hate for it to become Python or TS.

I kind of like that Ruby is still focusing on single developer/small team productivity.

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

#120

Post by ActorNightly »

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…

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

The issue is, the time it takes to develop the program to be absolutely correct is about the same. In the first case with C, you would write your program with carefully designed memory allocation (something like mempool that allocates at the start), you would design unit tests, you would run valgrind, and so on.

In the second case, you would spend a lot more time carefully designing types and operations, leading to a lot of churn of code-compile-fix error-repeat, taking you way longer to develop the program.

You could argue that the programmer is somewhat incompetent (for example, forgets to run valgrind), so the second language will have a higher change of being absolutely correct. However the argument still holds - in the second language, a slightly incompetent programmer can be lazy and define wide ranging types (similar to `any` in languages like typescript), leading to technical correctness, but logic bugs.

So in the end, it really doesn't matter which language you chose if you want ultimate correctness, because its all up to the programmer. However, if your goal is rapid prototyping, and you can guarantee that your input is constrained to a certain range, and even though out of range program will lead to a memory bug or failure of some sort, 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.

Post reply on HN