Live data from Hacker News

Why is Rust difficult?

vorner.github.io

51–60 of 260 posts

Re: Why is Rust difficult?

#51
post #10
post #4

Isn't the problem with Rust that it uses crappy pessimistic heuristics (borrow checker) for essentially NP-C problem, causing complaints where code is perfectly OK? IMO interesting design decision but I am staying away precisely because of this.

"Crappy pessimistic heuristics" Are you talking about the borrow checker from half a decade ago? [0] Have you used the language since then? This is FUD -- it's really not hard to get code past the borrow checker anymore. Maybe every thousand lines or so you'll need to add a block or pull a temporary variable out of a one-liner, but the compiler basically tells you exactly what to do when something like that is releva…

Try to use the borrow checker of this decade to write callbacks in GUI frameworks, without polluting the code with Rc and RefCell, even though it is obvious there is only one path to the data being used.

Re: Why is Rust difficult?

#52
post #9

Earlier quoted context omitted.

Not really. Just it's super difficult to understand how exactly borrow checker operates and when would it allow program to compile or not, causing all kinds of unpredictable situations and unless you are "black belt"-level, difficulty providing any estimates. Not mentioning loss of morale when you have to fight it every single day.

This is not my experience using Rust. I had six months of programming experience when I first tried Rust. I definitely got confusing errors at first, but I grasped the system within a month or two. And that was in 2014 - the borrowchecker and especially its errors have way improved since then! But this is also a very different objection from your initial objection, which was just a statement of fact about type system…

Have you tried to write GUI code in Rust?

Re: Why is Rust difficult?

#53
post #31

I feel Go and Rust are great options for writing modern server side applications today, but they exist on two different ends of the spectrum. The Go language is highly minimal, constrained, and forces devopers to write unified code, that performs extremely fast idiomatically. This uniformity is helpful for open source collaboration. Rust is a much more robust language (eg generics), but is more complicated to pick up…

Go does not perform "extremely fast idiomatically". There are a lot of cases where replacing channels with semaphores or atomics, avoiding too many go routines etc. can lead to significantly better performance.

But Go does perform good enough if one uses simple idiomatic code style while making things relatively safe and maintainable. That is its huge advantage.

Re: Why is Rust difficult?

#54
post #40

Is there a way to avoid the true-believer syndrome for Rust? I want to embrace Rust, but everyone ~100% of the time comes away chanting about how awesome Rust is. So much so that it's a bit unsettling. Zealotry in general is bad, but especially in programming: once you identify as an X programmer, you lose out on ideas from Y and Z. Every tool has its flaws, but for whatever reason it seems extremely rare to discuss…

Remember that Rust is competing with C and C++. Neither of them have REPLs. Both are statically typed (actually a lot of C programs are pseudo-dynamically typed with void * but pretty much nobody thinks that is better than actually using a dynamic language, or using something that has better generics). C++ is famous for long compilation times. For the class of problems in which your choices are C or C++, Rust is such…

> Neither of them have REPLs.

Sure they do, FOSS developers just don't look into the right places.

Already in the 90's there were companies selling C interpreters.

CERN created CINT and Cling for C++.

Microsoft has quite a good interactive debugger, and edit-and-continue, which is a kind of very poor man's REPL.

Re: Why is Rust difficult?

#55
post #50

Rust's problem is not correctness. The borrow checker is the good part of the language. It's feeping creaturism. The language started out as imperative, and then became semi-functional. It started out as thread-oriented, and now is acquiring "green threads"/coroutines/cooperative multitasking. The generics system and library started where C++ and Boost left off. The "trait" system was more "objects bad, must do somet…

This is a misnomer. This hasn't been an issue since 1.0. Before then, the language designers specifically warned people that they were taking the time to learn what works together.

Lightweight threading isn't being re-added to the language. It might emerge from some of the asynchronous I/O work, but that's part of a third party library.

Re: Why is Rust difficult?

#56
post #50

Rust's problem is not correctness. The borrow checker is the good part of the language. It's feeping creaturism. The language started out as imperative, and then became semi-functional. It started out as thread-oriented, and now is acquiring "green threads"/coroutines/cooperative multitasking. The generics system and library started where C++ and Boost left off. The "trait" system was more "objects bad, must do somet…

Er, no, Rust started out pretty solidly as a functional language.

It used to look like an ML variant, with purity and stuff. And it had a GC. It's lost most of that now.

It also used to have green threads up till 1.0 (they were removed pre-1.0), we're now adding them back. And they're being added back as a library, not as part of the language.

It moved away from both of these.

Re: Why is Rust difficult?

#57
post #44

Earlier quoted context omitted.

Mind you even correctness checkers aren't panacea - they won't go all the way down to check if you are using IEEE 754 correctly and handle all possible edge cases and rather assume "well-defined math properties". And as Donald Knuth used to say: "Beware of bugs in the above code; I have only proved it correct, not tried it."

Made me think, maybe they should check if you are using IEEE 754 correctly...

Numeric 'correctness' is a business-problem property.

For a game engine, correctness is speed and "right enough". For a research physics simulation, it may be "as right as possible".

You can't check whether floating point inaccuracy is correct generically because the definition is entirely dependent on the business needs of the program in question.

Re: Why is Rust difficult?

#58

Is there a way to avoid the true-believer syndrome for Rust? I want to embrace Rust, but everyone ~100% of the time comes away chanting about how awesome Rust is. So much so that it's a bit unsettling. Zealotry in general is bad, but especially in programming: once you identify as an X programmer, you lose out on ideas from Y and Z. Every tool has its flaws, but for whatever reason it seems extremely rare to discuss…

> but for whatever reason it seems extremely rare to discuss Rust's

At least within Rust spaces these get discussed at a regular cadence, in my experience. The usual pushback you see is "we're working on it", which is a valid response. I'm curious to see examples of what you're talking about, we try to push back hard on language zealotry in Rust spaces.

Re: Why is Rust difficult?

#59
post #44

Earlier quoted context omitted.

Mind you even correctness checkers aren't panacea - they won't go all the way down to check if you are using IEEE 754 correctly and handle all possible edge cases and rather assume "well-defined math properties". And as Donald Knuth used to say: "Beware of bugs in the above code; I have only proved it correct, not tried it."

Made me think, maybe they should check if you are using IEEE 754 correctly...

An "ancient" conversation demonstrating this issue with early Coq:

http://grouper.ieee.org/groups/754/email/msg00574.html

Re: Why is Rust difficult?

#60

I do think a lot of the difficulty when starting Rust was all about it forcing you to do everything correctly, even when the 'correctness' wasn't needed for how the program was currently being used. However, my experience learning Rust was that it was pretty easy to work through these things because of how precise the compiler is at describing the issue. I feel like the compiler was my teacher, and it kept on teachin…

> I feel like the compiler was my teacher, and it kept on teaching me new concepts to look up in the docs.

I work primarily in F#, a functional .Net language, which also enforces strict rules at compile time to ensure correctness... With the benefit of experience it's amazing and comforting and lets you reason happily about applications at a higher level. It's on of my favorite parts of the language, TBH.

And while I see its strength over time, and see the benefit it gives to code bases, I also know that for your average C# dev used to firing up their app and debugging at run-time, or working in certain ways with their code, it feels like putting on a straight-jacket. It hurts the "first week" story to the benefit of long term concerns.

I totally agree: it's forced learning, which makes it a bit of a grind. But damned if I'm not a much better programmer for the effort :)

Post reply on HN