4 ms·

I've enjoyed learning Rust, but I'm at the stage where I'm hitting constant stumbling blocks because of the slightly niche nature of what I'm doing. It's the u

I've enjoyed learning Rust, but I'm at the stage where I'm hitting constant stumbling blocks because of the slightly niche nature of what I'm doing. It's the ugly side of Rust; when you're stuck with a series of problems that you can't solve (or take too long to solve), when there aren't enough people in the community to help you, and you end up being unproductive for a while. Where I've seen small projects to their completion, Rust has been greatly rewarding to me. It's the projects that are bigger and more ambitious where I'm struggling. > After reading the first 10 chapters of Programming Rust, I was able to push through the rest of the implementation. I still have open questions, and I’m not sure if the structure I used makes the most sense. There's some chapters of TRPL and other resources that I've re-read a few times by now. Learning the language ends up being quite a lot of an academic exercise, but the benefit's that once a concept clicks, it paves way for many other concepts. My only advice to less experienced programmers (whom you're not) learning Rust: Stay away from writing or rewriting time-critical applications in Rust if you can't tolerate being stuck on a problem or series thereof for weeks.

ammaskartik 8y ago
Great job in pushing through though. Where have you been posting for help, I am no ways an expert, and have been learning Rust, but all I have heard is the welcoming nature of the community, and would love to at-least try and help. Its a great language, but yes, a stabilizing and emerging ecosystem. But this is the way it will mature; implement tasks that push the language and hopefully come out with good solutions. The Go ecosystem evolved in this manner as-well, and others as well.
manaskarekar 8y ago
Usually someone will help you out on irc or on the rust subreddit, but I think your point may still stand.
- nevi-me 8y ago
  It depends, my biggest struggle right now is with the tokio/futures ecosystem, so I'm on gitter::tokio quite a bit, and have posted once on /r/rust. With patience, I eventually solve many problems, but the lead-time is costly. Plus when I'm doing something wrong in my code, rustc could take over 5 minutes compiling, and then come back complaining. Even when I find someone willing to help me debug, the process takes a few hours, and I end up feeling bad for wasting someone's time.
  - nicoburns 8y ago
    I think the tokio/async ecosystem just isn't ready for prime time. Hopefully this (and compile times!) get much better.
    - ammaskartik 8y ago
      While compile times can be slow, the rust system is checking so much for you, so that you can have a predictable @scale runtime. What was the issue with tokio? Plus, with async/await Futures coming in soon, already on nightly right, this should become good if not already? Rust went down the Kotlin route of not including coroutines/async/await initially and allowed Lib devs to build, but now have included as we all know. But anyways, keep at it, I have found Rust to be very helpful, using it at the startup I am at, and will keep using it deeper and in more complex scenarios.
      - nicoburns 8y ago
        Rust is checking a lot, but type checking is not the slow part! (I can usually run cargo check within a couple of seconds max). Rusts LLVM IR output, LLVM, and linking seem to be the main culprits. And I'm hopeful that these can be greatly improved :)
    - bluejekyll 8y ago
      The issue isn't exactly that it's not ready for prime time, but that it's not ergonomic at the moment. The biggest issue that you have to get used to is that pretty much everything has to be owned data, and no references passed around when constructing Future types. This can feel like it comes into conflict with the poll(&mut self) interface (in 0.1). Also, I found truly understanding the fact that returning data from functions either must be sized or boxed, no references. Again, the &mut self can come into conflict here. But there are simple tricks for dealing with it, like using inner enums for iterating through a state machine of the future, and using Option where you can take() the value when ready. You'll see these patterns if you look at the Future library and Tokio impls of many of the core types. So I encourage you to generate docs with `cargo doc` and then click the `src` link on any types you want to understand better. The thing I wish I had internalized more earlier (and have been cleaning up a lot lately), is that "Futures should do no work unless polled". This is easy to mess up and regret later as you might accidentally start a Timer or initiate a connection before polling the Future. Anyway, hopefully people help out when you ask, though everyone's often busy :)
deleted 8y ago
[deleted]
karavelov 8y ago
It depends how you approach learning Rust. If you expect learning curve as going from Java to C#, you are going to be disappointed. If you expect learning curve like going from Java to Haskell, it will be more in-line with expectations. My point is that we very much align out expectations for the dominant paradigm and we got surprized when we have to actually "learn", i.e. internalize some different logic. BTW, I started feel comfortable with Rust/Tokio/futures/etc. in less than a month. But I come from Scala/C++/logic and type theory background, that I guess is not so common.

ammaskartik 8y ago

Great job in pushing through though. Where have you been posting for help, I am no ways an expert, and have been learning Rust, but all I have heard is the welcoming nature of the community, and would love to at-least try and help. Its a great language, but yes, a stabilizing and emerging ecosystem. But this is the way it will mature; implement tasks that push the language and hopefully come out with good solutions. The Go ecosystem evolved in this manner as-well, and others as well.

manaskarekar 8y ago

Usually someone will help you out on irc or on the rust subreddit, but I think your point may still stand.

nevi-me 8y ago
It depends, my biggest struggle right now is with the tokio/futures ecosystem, so I'm on gitter::tokio quite a bit, and have posted once on /r/rust. With patience, I eventually solve many problems, but the lead-time is costly. Plus when I'm doing something wrong in my code, rustc could take over 5 minutes compiling, and then come back complaining. Even when I find someone willing to help me debug, the process takes a few hours, and I end up feeling bad for wasting someone's time.
- nicoburns 8y ago
  I think the tokio/async ecosystem just isn't ready for prime time. Hopefully this (and compile times!) get much better.
  - ammaskartik 8y ago
    While compile times can be slow, the rust system is checking so much for you, so that you can have a predictable @scale runtime. What was the issue with tokio? Plus, with async/await Futures coming in soon, already on nightly right, this should become good if not already? Rust went down the Kotlin route of not including coroutines/async/await initially and allowed Lib devs to build, but now have included as we all know. But anyways, keep at it, I have found Rust to be very helpful, using it at the startup I am at, and will keep using it deeper and in more complex scenarios.
    - nicoburns 8y ago
      Rust is checking a lot, but type checking is not the slow part! (I can usually run cargo check within a couple of seconds max). Rusts LLVM IR output, LLVM, and linking seem to be the main culprits. And I'm hopeful that these can be greatly improved :)
  - bluejekyll 8y ago
    The issue isn't exactly that it's not ready for prime time, but that it's not ergonomic at the moment. The biggest issue that you have to get used to is that pretty much everything has to be owned data, and no references passed around when constructing Future types. This can feel like it comes into conflict with the poll(&mut self) interface (in 0.1). Also, I found truly understanding the fact that returning data from functions either must be sized or boxed, no references. Again, the &mut self can come into conflict here. But there are simple tricks for dealing with it, like using inner enums for iterating through a state machine of the future, and using Option where you can take() the value when ready. You'll see these patterns if you look at the Future library and Tokio impls of many of the core types. So I encourage you to generate docs with `cargo doc` and then click the `src` link on any types you want to understand better. The thing I wish I had internalized more earlier (and have been cleaning up a lot lately), is that "Futures should do no work unless polled". This is easy to mess up and regret later as you might accidentally start a Timer or initiate a connection before polling the Future. Anyway, hopefully people help out when you ask, though everyone's often busy :)

deleted 8y ago

[deleted]

karavelov 8y ago

It depends how you approach learning Rust. If you expect learning curve as going from Java to C#, you are going to be disappointed. If you expect learning curve like going from Java to Haskell, it will be more in-line with expectations. My point is that we very much align out expectations for the dominant paradigm and we got surprized when we have to actually "learn", i.e. internalize some different logic. BTW, I started feel comfortable with Rust/Tokio/futures/etc. in less than a month. But I come from Scala/C++/logic and type theory background, that I guess is not so common.