Live data from Hacker News

The struggle with Rust

ayende.com

111–120 of 301 posts

Re: The struggle with Rust

#111
post #71

When I first learned OCaml (knowing only Python), I swore a lot at the type checker for refusing to compile code that I knew would work at run-time (e.g., a variable having multiple types, but on strictly disjoint execution paths). It seemed insane to me that people would want to subject themselves to this kind of bondage and discipline. And yet, many years later now, I have learned and internalized how type systems…

To me it seems like Rust has an additional wrinkle with safe and unsafe code. A new Rust user needs to figure out both "How do I do this" and "Is this possible in safe code". The limits of safe code seems to be something people are figuring out at all levels. Rust projects seem to start out with a relatively high amount of unsafe code. Then as the project matures the unsafe sections are reduced or eliminated.

I think whether you feel you need unsafe when you first come to Rust depends on the angle from which you're coming.

Coming from C/C++, I know that there are structs in memory and can visualize what they look like - surely I can just go and tweak them? (No I can't because either it wasn't safe to do that anyway, or I need to explain to the Rust compiler why it is safe, and that can be quite difficult.)

Coming from something like Java, I (probably) don't think too much about what the underlying structure in memory is, so I'm less likely to try to do this.

Either way, it feels like part of the learning curve is learning the "Rustic" way to do something - in general, you probably shouldn't be reaching for "unsafe" until you know what you're doing! ;)

Re: The struggle with Rust

#112
post #75

Earlier quoted context omitted.

I agree that there's no data, but I would be very surprised if the answer is indeed no, as there are at least good theoretical reasons to assume extra cost. Proving anything (let alone to a compiler) comes at a computational complexity cost (think of the proof as a certificate). In principle, a large number of proofs may be "free" in the sense that no more information than the programmer normally supplies the compile…

It's not very surprising to me. Paraphrasing, "once I got past the initial hurdle of the borrow checker, programming in Rust became much easier," is frequently uttered in the Rust community. I'm not trying to make a very nuanced claim here. All I'm saying is that there's clearly a lot of people who struggle while learning Rust, but that this is very different than paying an eternal development cost similar to that st…

> programming in Rust became much easier

Much easier than what? Writing C? I believe you.

I agree with you about maintenance, and I agree that there are two separate issues, but still, extra proof must invariably carry some extra mental burden. There are no free proofs just as there are no free prime factors. This isn't a philosophical issue, but a computational one. But it's also true that the mental burden might offset a different sort of mental burden. So whether there is additional work or not is unclear, but I think it's pretty clear that the nature of the work is different.

Re: The struggle with Rust

#113

Earlier quoted context omitted.

C++ and Java are a bad example as they are unusually similar. Consider moving between C++, Python, and Javascript: on that scale, Rust doesn't seem so far out.

I doubt moving from Java to C++ would be that trivial, Java is a comparatively safe language without many of the issues that will trip you up in C++.

From personal experience, it's not that bad. C++ is "Java plus you need to worry about these other things", and it pays off in power and speed. They're not so similar in safety/scope terms, but the structure and design have enough in common that you get plenty of spare brainpower to worry about managing C++.

It was, for instance, a way more natural transition than "Java and C++ to OCaml". Less educational, but as usual that trades against easy.

Re: The struggle with Rust

#114
post #5

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust." Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration…

Agreed. Rust is different from other languages in that it is HARD to learn. It took me 3 projects and thousands of lines of code before I finally felt like I'm okay at Rust. Each project involved tons of compiler fighting that I now know how to avoid or solve. The problem is that instead of a general technique for solving borrow checker issues, every issue has a different specific technique. Hash map matches (like th…

Are these strategies for solving borrow checker issues documented anywhere? Sounds like a case for which a best-practice reference would be golden.

Re: The struggle with Rust

#115
post #48

Earlier quoted context omitted.

I think the problems with Haskell are quite different than the ones with Rust. Haskell suffers more from being a research playground, bad documentation for both the language and it's libraries, confronting you with many unusual concepts (type theory, monads, laziness,...) and, as a pretty old language, a lot of legacy cruft that makes a lot of things awkward (string handling is the prime example). Rust wants to be a…

> Rust wants to be a widely used language I am sure they want that. But so many responses of Rust enthusiasts to any article/blog less than flattering get very aggressive. May be Steve Jobs got away with 'You're holding it wrong' but I doubt incoming users for Rust will be this kind.

The aggressiveness is unfortunate (and counterproductive), but comes from the understandable perspective that too much bad press could kill the language before it even gets off the ground.

The Rust thesis is: "You should care about all these things you don't currently care about, and Rust helps (makes) you care about them." In order to enjoy Rust, you need to thoroughly buy in to that idea. Any significant deviation from that thesis defeats the very purpose of the language.

But of course most people aren't going to buy in, because it's an idea predicated on making their lives harder (in the short term) than it currently is. Rustaceans believe the long term benefits are massive, but new users cannot possibly believe that except by taking it on faith. This creates a conflict. The Rustaceans need everyone to give the language faith over an extended period of time, and anyone giving up their faith after a short trial not only drops out of the ecosystem themselves, but possibly damages the faith of others. That's a huge problem, because Rustaceans are hoping their language will one day take over a significant portion of the systems/embedded development space. That can't happen if people sour on the language so quickly. So when Rustaceans see someone slam their language with giving it an "honest try," they get upset because the damage done is palpable.

Of course, that's the wrong strategy, as it just drives people further away from the language. The right approach is to be inhumanly kind and accepting so that the frustrations are counterbalanced by support. The good news is that the Rust community at large seems to be quite nice; it's just the angry ones that show up in blog comments.

Re: The struggle with Rust

#116
post #5

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust." Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration…

Yeah, I've seen a number of posts like this for go as well. I wonder if it may be useful to start programming in these languages with a more experienced buddy to ask questions if and do some coffee reviews, to reduce time spent banging one's head on the keyboard, and get better acquainted with the language's idioms.

Re: The struggle with Rust

#117
post #65

Could the issues of rust be rectified with a better theorem proved that goes past "2 things are touching this"? I don't think I'd mind if the compiler said "your code will not work because eventually it will modify the same bytes at the same time and create an unpredictable state" but I will mind if it says "your not good because you have two mutable references.

Well Rust's way of ensuring you don't modify the same bytes at the same time is to ensure that any byte has precisely one "owner" in any region in which it is mutated. That's a model we know how to implement and also an easy model for humans to think about - we can see what's going on (we can see the regions in the code) and we know what to expect to work (e.g. if you have a mutable reference you expect to be able to…

From an implementation standpoint that makes sense. From a usability standpoint it does not. The use case of systems programming usually involves many mutators on a single piece of, non-copiable, data. I can see why the person writing the Rust prover would say "yea this is the best" but I can't see why anyone else would because it's filter cuts out a large portion of completely valid code that is not incorrect but instead is "scary" or "spooky".

> If you can formalize a better model you can probably implement it in a language, but what model would that be?

I'm just someone on the internet here to complain. I can't do that because I'm not a smart math person who can prove how to get there or even generalize it to work with other programming related things.

Re: The struggle with Rust

#118
post #5

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust." Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration…

>It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction gra…

All the "hard" things a user learns in Rust have to be learned in C++, too. It's just some things are learned in a different way in Rust (e.g. fighting with the borrow checker) than they would be in C++ (e.g. proper use of const(expr), references, moves, etc.).

Re: The struggle with Rust

#119

Earlier quoted context omitted.

>It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction gra…

The clincher for me with respect to rust is that I see a steady stream of useful software being developed in it. I never really saw that in Haskell and I've heard people talking about it for at least 15 years. That indicates that something is missing.

There is some pretty damn useful software written in haskell. For example, I started using Pandoc long before I knew it was written in Haskell, and for me, it still dwarfs the utility of any specific tool made in Rust. That said, Haskell had a lot longer to get there, so Rust is still moving a lot faster on that front.

Re: The struggle with Rust

#120
post #5

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust." Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration…

Agreed. Rust is different from other languages in that it is HARD to learn. It took me 3 projects and thousands of lines of code before I finally felt like I'm okay at Rust. Each project involved tons of compiler fighting that I now know how to avoid or solve. The problem is that instead of a general technique for solving borrow checker issues, every issue has a different specific technique. Hash map matches (like th…

  > Cyclic data structures require an Arena or Rc>.
Is there a way of creating a cyclic data structure that doesn't involve these types?

I ask because I used the latter recently, after struggling to create lifetimes that were acceptable to the compiler. I only found it when I searched for 'cyclic data structures rust' on Google.

It would have been much nicer if the compiler could have noticed that I was trying to create a cyclic data structure and then have informed me on the different ways of doing so. Perhaps a misunderstanding on my behalf, but the error messages that I previously received felt like they were sending me on a wild goose chase.

I still don't think writing Rust code is hard, but there are definitely improvements which could be made to the compiler error messages.

Post reply on HN