6 ms·

I second this. Rust gets miles easier after you internalise the borrow checker, which takes anywhere from a week to several, but it's definitely worth it. I be

I second this. Rust gets miles easier after you internalise the borrow checker, which takes anywhere from a week to several, but it's definitely worth it. I believe part of the reason is that people have limited time to play with this stuff and so they want instant gratification. Rust is not like that, but offers a much higher dose of delayed gratification instead. Once you familiarise yourself with the rules and get things working on the first or second compile, it means not only that you program appears to be working, but that it also passes a complex set of tests verified at compile time. When you become confident enough with Rust, you're basically as productive as with any other compiled language, with the added benefit that the code you wrote might actually be (re)usable afterwards. With Rust, you put in some work up front and reap the benefits since then, with other languages you can feel 'productive' right away, but not be able to write production grade software for weeks/months to come. Once you realise this, spending more than a few hours with Rust becomes an easier calculation.

k__ 10y ago
I don't understand what problems the people have with the borrow checker. I can't imagine internalizing the borrow checker is harder than internalizing all the idiosyncratic quirks languages like JavaScript have.
- dbrgn 10y ago
  The borrow checker prevents code from running at all, sometimes even if the code would be perfectly safe (e.g. two slices to non-overlapping areas of a vector). JavaScript on the other hand is full of quirks, but you get something to work quickly, even if it's buggy. The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated.
  - pimeys 10y ago
    > The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated. This. In my company, our Rust apps have a very small amount of tests, mostly integration tests written with Python. You need to test certain business logic, but mostly if it compiles, deploy all the things :)
    - vog 10y ago
      "If it compiles, it works." You don't hear this often, but when you hear this, people a usually talking about either OCaml or Haskell. Nice to see Rust joining this club, too. I often rephrase this as: "When switching from Python(/Ruby/PHP) to OCaml(/Haskell/Rust) you notice how many of your unit tests were really just type checks."
      - pimeys 10y ago
        But then again, there are some gotchas. Runtime errors can happen when using unwrap like in every example around the Internet. I too used the unwrap everywhere when I started writing Rust, but soon realized that one must handle the results and everything can be an Err or None, even if you think it is not possible. I'd say beginner tutorials should UNDERLINE that the use of unwrap() is just for the first prototype and you must refactor them out to proper error handling.
        vog 10y ago
        Maybe there should be a compiler warning for that. Or, to be more modern, there should be a linter rule for that.
        iopq 10y ago
        It's not as ergonomic to use unwrap() instead of expect("error code here") because of which line shows as failing at runtime.
  - k__ 10y ago
    Sure, but if you want to get correct software you have to learn about the language you're using. The borrow checker and quirks are just concrete manifestations of that fact.
    - pimeys 10y ago
      But when you have some months behind with daily Rust usage, basically the compiler just helps you to write correct code. I usually write code fast and then start iterating with the compiler to get everything right. If I need to fight too long with the borrow checker phase, I know my structure is wrong and I should rewind a bit and try again.
      - k__ 10y ago
        I didn't want to say that JS' quirks are better than or equal than Rusts borrow checker. I just wanted to say people are hating on the borrow checker, while they gladly invest time in learning quirks and I don't understand why :)
        pimeys 10y ago
        But I must say, I was also kind of upset the first couple of weeks when always getting errors whatever I tried to do with Rust. And spending lots of time fixing those errors. When you learn the style, it's very easy to work with, but the first two weeks were a massive slap to my overblown programmer ego... :D
  - jackmott 10y ago
    this same tendency to run if it compiles exists in most/all statically typed garbage collected languages too though, with less cognitive overhead while coding (but more runtime overhead of course!) What will be interesting is if Rust proves to be, or can be made to be, a productive choice for programs where the runtime performance is not needed. At the moment I feel like it adds so much verbosity compared to other ML-based languages that it just isn't. But I do love performance, even if I don't need it :)
  - gigatexal 10y ago
    I don't think Rust was meant to be a "quick" language for prototyping I think that's python.
  - iopq 10y ago
    > JavaScript on the other hand is full of quirks, but you get something to work quickly, even if it's buggy. In my experience JS is the worst at NOT working. Because when one part of the application fails, the entire PAGE stops working. Buttons don't work anymore, dropdowns don't work, nothing works. And all of this is just one buggy line of code away.
- jackmott 10y ago
  the simplest way to illustrate the kind of pain that can arise is, make a binary tree from scratch. this is like a 10 second job in languages like C# or F#, but really weird in Rust. And analogous things can come up with any graph that isn't directed.
  - winstonewert 10y ago
    I've had no issues with tree structures: enum BinaryTree { Leaf(i32), Node(BinaryTree, BinaryTree) } But perhaps there are some operations you are doing on the tree that are more difficult? Also, what kind of undirected graphs do you find yourself writing? I'm curious, because I rarely if ever find myself needing a graph.
    - m1el 10y ago
      This struct doesn't compile: recursive type `BinaryTree` has infinite size
      - steveklabnik 10y ago
        Simplest solution: enum BinaryTree { Leaf(i32), Node(Box<BinaryTree>, Box<BinaryTree>) }
      - winstonewert 10y ago
        My bad. In my actual code I was thinking of it was a Vec<>, because my nodes aren't binary.
  - dvdkon 10y ago
    Sure, but writing a graph (any kind, but even more so undirected) in a language without GC is a minefield from the standpoint of memory safery. You simply need some kind of reference counting. High-level languages like C# and F# hide this need behind using GC for everything, but Rust tries to be lower level than those and therefore exposes the extra layer.
- lj3 10y ago
  You guys (rust guys) are starting to sound an awful lot like the Haskell guys do. I'd urge you not to brush off complaints about the language being difficult or complicated to use. Learn from their mistakes.
  - steveklabnik 10y ago
    Random comments don't always represent the entire community. Making Rust easier to use and helping people get onboarded is a significant priority of 2017, it's not being ignored. It's being tackled head-on.
    - k__ 10y ago
      Also, I'm a JavaScript guy and not a Rust guy, whelp.
      - steveklabnik 10y ago
        Yes. Extrapolating anything from a single comment is going to be rife with inaccuracy. To bring it back around, there are a lot of people who say things like "It's not as bad as it might seem at first" or "yes, at first you struggle, but then it becomes second nature, keep at it!" but I don't see anyone completely dismiss outright the difficulty up front. I've heard some people say that they thought it was going to be harder than it actually was, based on people trying to set accurate expectations.
        k__ 10y ago
        "I've heard some people say that they thought it was going to be harder than it actually was, based on people trying to set accurate expectations" Yes, sometimes I have the feeling people with a unnaturally low stress tolerance are the ones who comment the most :D
Tade0 10y ago
To me personally Rust was the first compiled language in which my reaction to each new part of the syntax was "Of course you do it like that, why would you do it any other way?". My only gripe is that being a JS dev I'm spoiled with Node.js's gratuitous amount of community-written modules and finding out that a lot of the modules I picked for my projects in Rust are not actively maintained was a little bit disheartening.
- AsyncAwait 10y ago
  > a lot of the modules I picked for my projects in Rust are not actively maintained There's an effort underway to 'bless' crates for common tasks, (ie tokio, futures for async, hyper for http etc.), so this will get better soon.
  - Tade0 10y ago
    That's great news! Honestly I'm more interested in stuff that involves some degree of heavy-lifting like real-time audio processing etc. for which JavaScript is going to be slow(no SIMD).
  - galangalalgol 10y ago
    Do you think there will ever be a standalone package that has all the blessed crates? Getting approval to use boost at work was hard enough. Getting them to approve any random 3rd tier dependency I might unintentionally pull down from crates is not even worth asking.
    - steveklabnik 10y ago
      It's not clear. The Rust core team proposed such a thing, but it was resoundingly rejected by the community. There are some people working on projects like this, http://github.com/brson/stdx http://github.com/brson/stdx for example.
      - galangalalgol 10y ago
        Interesting, thanks! The ideal would be someone to bundle said crates and then sell the bundling service. In my experience companies don't like anything free. It also helps if you are going to drop it on an air gapped dev network.

k__ 10y ago

I don't understand what problems the people have with the borrow checker. I can't imagine internalizing the borrow checker is harder than internalizing all the idiosyncratic quirks languages like JavaScript have.

dbrgn 10y ago
The borrow checker prevents code from running at all, sometimes even if the code would be perfectly safe (e.g. two slices to non-overlapping areas of a vector). JavaScript on the other hand is full of quirks, but you get something to work quickly, even if it's buggy. The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated.
- pimeys 10y ago
  > The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated. This. In my company, our Rust apps have a very small amount of tests, mostly integration tests written with Python. You need to test certain business logic, but mostly if it compiles, deploy all the things :)
  - vog 10y ago
    "If it compiles, it works." You don't hear this often, but when you hear this, people a usually talking about either OCaml or Haskell. Nice to see Rust joining this club, too. I often rephrase this as: "When switching from Python(/Ruby/PHP) to OCaml(/Haskell/Rust) you notice how many of your unit tests were really just type checks."
    - pimeys 10y ago
      But then again, there are some gotchas. Runtime errors can happen when using unwrap like in every example around the Internet. I too used the unwrap everywhere when I started writing Rust, but soon realized that one must handle the results and everything can be an Err or None, even if you think it is not possible. I'd say beginner tutorials should UNDERLINE that the use of unwrap() is just for the first prototype and you must refactor them out to proper error handling.
      - vog 10y ago
        Maybe there should be a compiler warning for that. Or, to be more modern, there should be a linter rule for that.
      - iopq 10y ago
        It's not as ergonomic to use unwrap() instead of expect("error code here") because of which line shows as failing at runtime.
- k__ 10y ago
  Sure, but if you want to get correct software you have to learn about the language you're using. The borrow checker and quirks are just concrete manifestations of that fact.
  - pimeys 10y ago
    But when you have some months behind with daily Rust usage, basically the compiler just helps you to write correct code. I usually write code fast and then start iterating with the compiler to get everything right. If I need to fight too long with the borrow checker phase, I know my structure is wrong and I should rewind a bit and try again.
    - k__ 10y ago
      I didn't want to say that JS' quirks are better than or equal than Rusts borrow checker. I just wanted to say people are hating on the borrow checker, while they gladly invest time in learning quirks and I don't understand why :)
      - pimeys 10y ago
        But I must say, I was also kind of upset the first couple of weeks when always getting errors whatever I tried to do with Rust. And spending lots of time fixing those errors. When you learn the style, it's very easy to work with, but the first two weeks were a massive slap to my overblown programmer ego... :D
- jackmott 10y ago
  this same tendency to run if it compiles exists in most/all statically typed garbage collected languages too though, with less cognitive overhead while coding (but more runtime overhead of course!) What will be interesting is if Rust proves to be, or can be made to be, a productive choice for programs where the runtime performance is not needed. At the moment I feel like it adds so much verbosity compared to other ML-based languages that it just isn't. But I do love performance, even if I don't need it :)
- gigatexal 10y ago
  I don't think Rust was meant to be a "quick" language for prototyping I think that's python.
- iopq 10y ago
  > JavaScript on the other hand is full of quirks, but you get something to work quickly, even if it's buggy. In my experience JS is the worst at NOT working. Because when one part of the application fails, the entire PAGE stops working. Buttons don't work anymore, dropdowns don't work, nothing works. And all of this is just one buggy line of code away.
jackmott 10y ago
the simplest way to illustrate the kind of pain that can arise is, make a binary tree from scratch. this is like a 10 second job in languages like C# or F#, but really weird in Rust. And analogous things can come up with any graph that isn't directed.
- winstonewert 10y ago
  I've had no issues with tree structures: enum BinaryTree { Leaf(i32), Node(BinaryTree, BinaryTree) } But perhaps there are some operations you are doing on the tree that are more difficult? Also, what kind of undirected graphs do you find yourself writing? I'm curious, because I rarely if ever find myself needing a graph.
  - m1el 10y ago
    This struct doesn't compile: recursive type `BinaryTree` has infinite size
    - steveklabnik 10y ago
      Simplest solution: enum BinaryTree { Leaf(i32), Node(Box<BinaryTree>, Box<BinaryTree>) }
    - winstonewert 10y ago
      My bad. In my actual code I was thinking of it was a Vec<>, because my nodes aren't binary.
- dvdkon 10y ago
  Sure, but writing a graph (any kind, but even more so undirected) in a language without GC is a minefield from the standpoint of memory safery. You simply need some kind of reference counting. High-level languages like C# and F# hide this need behind using GC for everything, but Rust tries to be lower level than those and therefore exposes the extra layer.
lj3 10y ago
You guys (rust guys) are starting to sound an awful lot like the Haskell guys do. I'd urge you not to brush off complaints about the language being difficult or complicated to use. Learn from their mistakes.
- steveklabnik 10y ago
  Random comments don't always represent the entire community. Making Rust easier to use and helping people get onboarded is a significant priority of 2017, it's not being ignored. It's being tackled head-on.
  - k__ 10y ago
    Also, I'm a JavaScript guy and not a Rust guy, whelp.
    - steveklabnik 10y ago
      Yes. Extrapolating anything from a single comment is going to be rife with inaccuracy. To bring it back around, there are a lot of people who say things like "It's not as bad as it might seem at first" or "yes, at first you struggle, but then it becomes second nature, keep at it!" but I don't see anyone completely dismiss outright the difficulty up front. I've heard some people say that they thought it was going to be harder than it actually was, based on people trying to set accurate expectations.
      - k__ 10y ago
        "I've heard some people say that they thought it was going to be harder than it actually was, based on people trying to set accurate expectations" Yes, sometimes I have the feeling people with a unnaturally low stress tolerance are the ones who comment the most :D

Tade0 10y ago

To me personally Rust was the first compiled language in which my reaction to each new part of the syntax was "Of course you do it like that, why would you do it any other way?". My only gripe is that being a JS dev I'm spoiled with Node.js's gratuitous amount of community-written modules and finding out that a lot of the modules I picked for my projects in Rust are not actively maintained was a little bit disheartening.

AsyncAwait 10y ago
> a lot of the modules I picked for my projects in Rust are not actively maintained There's an effort underway to 'bless' crates for common tasks, (ie tokio, futures for async, hyper for http etc.), so this will get better soon.
- Tade0 10y ago
  That's great news! Honestly I'm more interested in stuff that involves some degree of heavy-lifting like real-time audio processing etc. for which JavaScript is going to be slow(no SIMD).
- galangalalgol 10y ago
  Do you think there will ever be a standalone package that has all the blessed crates? Getting approval to use boost at work was hard enough. Getting them to approve any random 3rd tier dependency I might unintentionally pull down from crates is not even worth asking.
  - steveklabnik 10y ago
    It's not clear. The Rust core team proposed such a thing, but it was resoundingly rejected by the community. There are some people working on projects like this, http://github.com/brson/stdx http://github.com/brson/stdx for example.
    - galangalalgol 10y ago
      Interesting, thanks! The ideal would be someone to bundle said crates and then sell the bundling service. In my experience companies don't like anything free. It also helps if you are going to drop it on an air gapped dev network.