Comment by nevi-me | Hacker News Reader

Comment by nevi-me | Hacker News Reader

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.

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.

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

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.

I think the tokio/async ecosystem just isn't ready for prime time. Hopefully this (and compile times!) get much better.

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.

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 :)

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 :)

One of the challenges I'm having now is with some library that connects to a steaming pubsub server. I found a problem with the library, my use-case differs from what's being tested, and because I'm struggling to use the library the way the author suggests; I'm unable to convince them that being unable to Clone their data structure is causing a problem.

I unfortunately am not at the point of "X didn't work, so I wrote Y" as that's how we end up with competing libraries.

Sometimes there are good reasons for not cloning, such as underlying resources that can’t be cloned. But I agreed it can be ergonomically easier in many cases. If they truly don’t want it, and you really don’t want to fork, can rewrapping it in an Arc<T> or Arc<Mutex<T>> get you around the problem?

Wait, if I do (in any language)

  foo = createFuture(1)
  bar = createFuture(2)
  foo.poll()
  bar.poll()

I would expect them to start doing work before polled, otherwise there'd be no concurrency. Do I undsrstand you correctly about polling?

You didn’t say what you understood, but nothing would happen until poll is called in Rust. And calling poll would only result in one churn of the event loop. You don’t call poll yourself, you put the future onto an event loop and it calls poll for you.

Oof, I got burned by the tokio/futures ecosystem too. It's definitely a frustrating experience. Thank god it was only a pet project with no deadline pressure, cause it's been 6months now and I'm still waiting for stabilization.

Which stabilization?

async/await is the big one :)

I guessed, it’s huge for sure :) since everything does work on stable, I wasn’t sure if there was something else I was missing, or if you meant the libraries, which still have some churn to go.

I can’t wait myself.

I spent two years of my professional career with Rust doing async web services and most of it with tokio/futurrs. First you finally get comfortable with Rust and then you do the learning again with futures... I did it. It paid off. Wrote some fast and stable services with it and it is not that hard when you get to the other side.

But for newcomers, be careful with references when using futures and be smart how you use the combinators. The errors can be tough and this is the only place in Rust ecosystem where they don't really help at all sometimes.

I eventually got something working, and it was stupid stupid fast, but it definitely took a lot longer to write than I would've liked.

Just waiting for the features and APIs to finalize and async/await for the ergonomics improvements. I believe in it's potential, but I'm in no hurry to use it again in it's current state.

Didn't mean though I think the current situation is that bad. What you get already is a type safe way to build async programs where the runtime is separated from the logic. I remember switching from a single threaded event loop into a work-stealing threadpool by just changing one line of code. It's very explicit and nice.

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.

Reply on news.ycombinator.com