Comment by Analemma_ | Hacker News Reader

Comment by Analemma_ | Hacker News Reader

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 documentation to answer simple questions (one that I ran into the other day was "How do I parse a string into a datetime in a particular timezone?", which took about an hour to answer, compared to the 60 seconds it would take in something like C#)

I'm saying this as a lover, not a hater. I really believe in the mission of Rust, and I really want to like it, but I realized that even after a few months of learning, it was still taking me orders of magnitude longer to accomplish things in Rust than in C# (or even C++), and I wasn't finding the tradeoff worth it.

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#.

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.

Don't leave us hanging. What's the other piece of advice?

Oh. For a similar reason (nobody reads your code unless they're looking at a problem): describe your piece of code in plain english. If you can make the code work the way you just described it, the code will age better.

(It might not be the fastest, but everyone will know if it's correct. When you're hunting for a bug it's important how quickly you can eliminate false positives to get to the real culprit. And you can make good code fast but you can't make fast code good.)

  "2014-11-28T21:00:09+09:00".parse::<DateTime<FixedOffset>>()

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::<DateTime<Utc>>().with_timezone(&UTC)

That is indeed what I found :)

But trying to find stuff like this with Rust's documentation-- when you're using a search engine instead of relying on having a human to interpret the question for you-- is usually tremendously frustrating. My experience has been that Rust developers lean heavily on autogenerated documentation, where each method of a struct/enum is heavily documented but there are few to no examples or "E2E scenario" explanations to get you started from scratch.

That's why the above scenario took me an hour: first I had to discover chrono, then a while to realize it wouldn't do what I needed and actually had to use chrono_tz, then a while longer to find where the documentation for time format strings live, etc. All the methods were documented just fine, but there was no high-level explanation leading to them.

When I just did the search for C#, the first non-StackOverflow link was to Microsoft's autogenerated documentation. Without any examples, I'm not sure whether System.DateTime.Parse does what you want. Where would you have looked to get those examples/E2E scenarios for C#?

I see a complete E2E example here.

https://msdn.microsoft.com/en-us/library/system.datetime.par...

Interesting. I found https://msdn.microsoft.com/en-us/library/system.datetime(v=v... and there in the long list of methods is a link to https://msdn.microsoft.com/en-us/library/1k1skd40(v=vs.110).... , which doesn't have the example.

.NET allows for function overloading, so usually the examples tend to be on the same page where all variants get listed, not on every single one.

With the main page for a class listing the most common use cases.

Did you look at the READMEs of those libraries? Most of the common use cases are documented fairly comprehensively there - I pulled those examples almost directly out of those documents

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.

Reply on news.ycombinator.com