Live data from Hacker News

100 days with Rust: a series of brick walls

brandur.org

11–20 of 323 posts

Re: 100 days with Rust: a series of brick walls

#11
I was following along until this:

> universally terrible documentation and lacking examples, unstable APIs, type annotation hell, and so much more.

The docs in Rust are by far some of the best I've seen, without specifics it's really hard to understand what issues he hit.

Re: 100 days with Rust: a series of brick walls

#12

I'm looking forward to the full article, because it's nice to know that I'm not alone here. I too started learning Rust with great optimism, and had the same experience: I expected that things would be difficult starting out, but assumed it would get easier as I acquired more knowledge, and then it didn't. Mostly this was for the same reasons as the author cites: Rust futures are incomprehensible, and there is rarely…

I think it really depends on what you're working on. Rust is designed to make some specific hard problems easier, like performant memory management and threading concerns. As a result of its focus it makes a lot of easy problems harder. Some of those will get better as the ecosystem matures, but it will likely never be as easy to use as other high-level languages which prioritize developer ergonomics.

For a select few domains, Rust is a god-sent. But if the performance-critical aspects of what you're working on are already abstracted several layers away from you, you're probably better of using a language which hides all the book-keeping which Rust puts at the top level.

Rust is a better C, not a better C#.

Re: 100 days with Rust: a series of brick walls

#13

I'm looking forward to the full article, because it's nice to know that I'm not alone here. I too started learning Rust with great optimism, and had the same experience: I expected that things would be difficult starting out, but assumed it would get easier as I acquired more knowledge, and then it didn't. Mostly this was for the same reasons as the author cites: Rust futures are incomprehensible, and there is rarely…

I’m observing some similar muttering in the JavaScript community with Promises. Chain them incorrectly and you get an error with no actionable context.

The most popular 3rd party promise framework in JavaScript collects extra cause and effect data when you run the code in development mode. It helps but it still isn’t always enough.

I fundamentally don’t understand how people still think writing tools and libraries is the same process as writing production code. Which is to say: I wrote it, I understand it, ship it!

It’s a profoundly different process. I don’t think we give enough kudos to the people who can do it well.

I keep telling my ambitious jr devs the same two pieces of advice. The one relevant here is: nobody is going to look at your code until something is broken. Which means they are already having a bad day. Don’t make it worse.

Re: 100 days with Rust: a series of brick walls

#14

I'm looking forward to the full article, because it's nice to know that I'm not alone here. I too started learning Rust with great optimism, and had the same experience: I expected that things would be difficult starting out, but assumed it would get easier as I acquired more knowledge, and then it didn't. Mostly this was for the same reasons as the author cites: Rust futures are incomprehensible, and there is rarely…

  "2014-11-28T21:00:09+09:00".parse::>()
With chrono, I think that's all you need. If you want to name the timezone you can use chrono-tz:

  let tz: Tz = "Europe/London".parse().unwrap()
  let date = "2014-11-28T21:00:09Z".parse::>().with_timezone(&UTC)

Re: 100 days with Rust: a series of brick walls

#15

I'm looking forward to the full article, because it's nice to know that I'm not alone here. I too started learning Rust with great optimism, and had the same experience: I expected that things would be difficult starting out, but assumed it would get easier as I acquired more knowledge, and then it didn't. Mostly this was for the same reasons as the author cites: Rust futures are incomprehensible, and there is rarely…

For me Rust’s sweet spot is anything performance related I would use C++ instead of Java, .NET, Go, Swift, MLs derived language.

Basically that performance hotspot where a managed runtime isn’t an option.

Rust is still new, it took C++ about 20 years to reach where it is, and even now there are domains where it cannot replace C for various reasons.

Re: 100 days with Rust: a series of brick walls

#16
> universally terrible documentation

Wait, what? Rust has what I consider the best documentation I've seen of any language. The docs explain things at a high-level, but concisely, and have numerous examples. The formatting is good, the keyboard navigation support is good, it's well-linked, and it has convenient features like links to the source and the ability to collapse everything but method headers for easier browsing. And it's extremely easy to add docs to your own project.

Maybe there are some dark corners filled with poorly documented unstable APIs that I haven't seen?

Re: 100 days with Rust: a series of brick walls

#17
I've been learning Rust for a little while, and while I agree that it can be frustrating, it's nowhere near as bad as trying to learn Haskell. I regularly get a friend of mine to explain things to me, because the documentation and community for Haskell are 90% incomprehensible to anyone who doesn't have a comp-sci degree or a higher education in mathematics. Example: https://wiki.haskell.org/Lifting. It's not that I don't get the concept (after being given a much better explanation), it's just that the Haskell community in particular really seems to struggle with communication. And I think that's where Rust is actually in a good place for learning.

Rust has some confusing concepts, and it does feel like you're fighting the compiler sometimes, but I can see what it's trying to achieve and it's improving very rapidly. I find that I can more-or-less stumble my way through it until I get where I want, as the documentation that is about is generally well-written, even if it doesn't cover everything yet :)

And it's kinda fun!

Re: 100 days with Rust: a series of brick walls

#18

This is a 100 sentences rant with 0 substances. Literally, there are no examples at all of any "brick wall". Why was this even posted here?

I think it sounds exactly right when a developer comes from a higher level language(like C# or Java with the rich base libraries) to a much low level one.

Re: 100 days with Rust: a series of brick walls

#19

I was following along until this: > universally terrible documentation and lacking examples, unstable APIs, type annotation hell, and so much more. The docs in Rust are by far some of the best I've seen, without specifics it's really hard to understand what issues he hit.

They're completely different kind of docs that Python's. Python's are written by hand, with many examples and tips how to use the various tools. Rust's documentation very much feels generated, and the last time I checked methods were not grouped. So vast portions of a page are consumed by variants of methods (overloaded methods?) which work exactly the same except they take different argument type. Python documentation is text with methods and code samples inbetween. Rust's documentation is like someone iterated over functions and types and printed a message for each. There's A LOT of redundancy.

Re: 100 days with Rust: a series of brick walls

#20
post #19

I was following along until this: > universally terrible documentation and lacking examples, unstable APIs, type annotation hell, and so much more. The docs in Rust are by far some of the best I've seen, without specifics it's really hard to understand what issues he hit.

They're completely different kind of docs that Python's. Python's are written by hand, with many examples and tips how to use the various tools. Rust's documentation very much feels generated, and the last time I checked methods were not grouped. So vast portions of a page are consumed by variants of methods (overloaded methods?) which work exactly the same except they take different argument type. Python documentati…

Side-note: I personally vastly prefer Rust's documentation to Python's, but I imagine it's a matter of taste.

So you'd suggest adding a manner of grouping methods in rustdoc?

Post reply on HN