Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The struggle with Rust

ayende.com

Post reply on HN
Print view View original

51–60 of 301 posts

Re: The struggle with Rust

#51

Post by noxToken »

wiremine wrote: post #39
adwhit wrote: 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. In my experience, most developers can't or won't put in this sort of investment. Which leads me to wonder what fields/niches will Rust land in? This might change if, as other commenters have stated, it is taught as a first or second language, but that doesn't seem likely anytime soon...

> it is taught as a first or second language

This is interesting. Many universities teach Java, C, C++ or Python as a first language. The headache that many first year students suffer from these basic (relatively speaking) languages is readily apparent. Rust is very strict, and it requires an entirely different mindset to use. I wonder how this would fare with students who have a clean slate.

Re: The struggle with Rust

#52

Post by [deleted] »

farresito wrote: post #46

Why this circlejerk about rust being hard to learn and use? I've seen multiple threads like this one in the past week. Yeah, rust is not easy and takes some time to get used to, but I'm surprised this kind of threads come up so often from a community like hacker news. You decided to learn a language that is a bit different than what you usually find out there that requires to wrap your head around some new concepts.…

[deleted]

Re: The struggle with Rust

#53

Post by jnbiche »

gnuvince wrote: post #11

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…

> I believe that we are seeing the same kind of phenomenon in Rust:

I don't know. I picked up OCaml fairly quickly, but I have consistently struggled with Rust, trying it for a while before abandoning it in frustration with lifetimes, 2 or 3 times. I can program in Rust, but it still seems like an ongoing struggle, as opposed to the smooth brain to text programming I've gotten used to in Python, JavaScript, OCaml, and Lua, and to a lesser extend C, Go and Elixir (just because I haven't used to latter 3 as much, at least recently).

I think Rust may be ideal for embedded software development, or low-level systems software, but for general application development, I think OCaml or perhaps Swift or Scala are more ideal, at least for me (or at least until I decide to try Rust again, perhaps it will stick this time).

Edit: Oh yeah, and I was even able to become productive enough in Scala to build a significant project (a programming language) in a relatively short period of time. Now, I'm not silly enough to think I've really mastered Scala in such a short period of time, but I was using it productively as a functional language as I would OCaml with little difficulty. On the other hand, I've started 3 (3!) programming languages in Rust but have yet to get beyond much beyond the parser/AST stage before I quit in frustration.

Re: The struggle with Rust

#54

Post by lmm »

tejinderss wrote: post #15
gnuvince wrote: post #11

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…

Not related to the topic but how do you find ocaml as compared to python or rust? Do you think its worth learning today as opposed to rust for high level general purpose programming?

It is well worth learning an ML-family language. In addition to Rust, OCaml or Haskell as njs12345 mentioned, F# or Scala might be options. OCaml is probably more mature than Rust, has more libraries available, and has automatic memory management which takes some of the load off you (especially if you're writing a GUI application, IME). But it's not got Rust's "hot right now" factor, it doesn't have Rust's ease of embedding in other languages, and it doesn't have quite the same focus on high-quality documentation.

If you already know Rust I wouldn't bother learning both - they're very similar languages.

Re: The struggle with Rust

#55

Post by rbehrends »

gnuvince wrote: post #11

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…

This is a different issue. The problem that the author is observing is that Rust operates on the hypothesis that the ownership relation is mostly left-unique and acyclic and that you run into problems when this hypothesis doesn't hold. And this affects not only explicit data structures, but also the implicit structures that involve stack frames (local variables, closures, etc.).

While Rust has mechanisms to deal with this (copying, Rc, etc.), all these mechanisms add pain points, and for problems that are not just theoretical. It affects a number of design patterns, closures that survive the scope they were created in, functional-style programming, functional data structures, any data structure that naturally involves a DAG or cycles.

The difference compared to a (good) static type system is that a good [1] static type system does not measurably reduce expressiveness; Rust's ownership model does.

This is not to say that there isn't a point to Rust's model. Rust directly competes with garbage collection as the main alternative model to achieve memory safety and is an obvious choice in cases where garbage collection is not a realistic option. But where garbage collection is an option, the tradeoffs that Rust makes become much less attractive.

[1] Obviously, primitive static type systems (example: Java up to version 1.4) do pose a problem.

Re: The struggle with Rust

#56

Post by burntsushi »

radarsat1 wrote: post #43
burntsushi wrote: post #20

Earlier quoted context omitted.

There's no single solution to the problem, which is perhaps one reason why folks new to Rust might stumble over it. You can't just get two aliased mutable pointers to the same region of memory in safe code. Sometimes the borrow checker can't quite see through everything. Consider this trivial example, which will fail the borrow checker: let mut owned = vec![1, 2]; let x = &mut owned[0]; let y = &mut owned[1]; That th…

> That this fails might come as a surprise to a lot of folks because it's easy for a human to see that it's perfectly safe. So what's still unclear to me is, is this failing in the borrow checker "by design", or is it something that will be "improved"? Also, _why_ does it fail in the borrow checker? Is it correct that it fails, or is it a deficiency of the current borrow checker?

If "correct" corresponds to "if and only if safe," then no, it's not correct because the code I posted in my previous comment is safe, but the borrow checker rejects it.

I only posted samples to demonstrate working with the borrow checker. Think about this code:

    let mut owned = vec![1, 2];
    let x = &mut owned[i];
    let y = &mut owned[j];
What are the values of `i` and `j`? If they are equivalent, then this code is unsafe, because it would permit mutable aliases. Therefore, the borrow checker would need to prove something about what values of `i` and `j` are legal at this particular point in the program. (Errmmm, dependent types anyone?)

With that said, if you do have code like my original sample (where the indices are constants and trivially not equal), then perhaps it would be reasonable to say that is a deficiency of the borrow checker as it currently exists that could be feasibly fixed. It's not clear what the impact of fixing that deficiency would be. For example, I don't think it would have made the OP's life any better.

Re: The struggle with Rust

#57

Post by camus2 »

farresito wrote: post #46

Why this circlejerk about rust being hard to learn and use? I've seen multiple threads like this one in the past week. Yeah, rust is not easy and takes some time to get used to, but I'm surprised this kind of threads come up so often from a community like hacker news. You decided to learn a language that is a bit different than what you usually find out there that requires to wrap your head around some new concepts.…

> Why this circlejerk about rust being hard to learn and use?

Dismissing concerns about rust learning curve as a "circlejerk" isn't going to make more people want to learn rust. I thought the rust community was a bit more mature than the Go one and wouldn't fall into this kind of mindset ...

> If that's the case, then learning rust is probably not the right choice.

Same tired argument I hear from Go folks. "Go wasn't invented for you ...". Extremely arrogant.

Re: The struggle with Rust

#58

Post by pron »

Rust provides something that few if any other languages do: memory safety without GC. It is very obvious that this comes at a non-negligible cost in development effort. If you need what Rust provides -- and an important class of software certainly does -- you should be more than happy to pay that extra cost. If you don't, there are plenty of alternatives. But exchanging effort for rather unique guarantees is the very explicit tradeoff that Rust makes. That few other languages choose to make this tradeoff is what makes Rust so valuable.

Re: The struggle with Rust

#59

Post by Diggsey »

gravypod wrote: post #37

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.

Having a more powerful theorem prover is not always better: it makes it harder for the programmer to know whether a piece of code will work, and you can start getting non-local effects, where a change in one part of the code can break a (seemingly) unrelated part.

However, what you're asking for is very similar to what types like `RefCell` and `RwLock` do - they effectively delay borrow-checking until runtime. Now you can have references to a `RefCell` in multiple places in the code, and they can all get mutable access to the interior, just not at the same time.

Having said that, I find it interesting how rarely things like `RefCell` are needed in practice: there's almost always a better way to satisfy the borrow checker, and it usually results in much cleaner code.

Re: The struggle with Rust

#60

Post by lmm »

rubber_duck wrote: post #22
adwhit wrote: 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…

F# and Scala are halfway to Haskell - maybe 3/4 of the way even - compared to the languages that were popular at the time (and the more experienced people get the more Haskelly their code tends to become). Hell, those popular languages are about 1/3 of the way to Haskell now. Any serious language these days has lambdas, map/reduce/filter, and type inference; most have list comprehensions and pattern-matching.

You're right that there needs to be a path up to there though. The reason Scala really worked for me is that it let me make my way up to a very Haskell-like style while remaining productive every step of the way.

Post reply on HN