3 ms·

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 ex

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.

skohan 9y ago
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#.
hinkley 9y ago
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.
- vec 9y ago
  Don't leave us hanging. What's the other piece of advice?
  - hinkley 9y ago
    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.)
jgilchrist 9y ago
"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)
- Analemma_ 9y ago
  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.
  - yorwba 9y ago
    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#?
    - pjmlp 9y ago
      I see a complete E2E example here. https://msdn.microsoft.com/en-us/library/system.datetime.parse(v=vs.110).aspx#Parse1_Example https://msdn.microsoft.com/en-us/library/system.datetime.par...
      - yorwba 9y ago
        Interesting. I found https://msdn.microsoft.com/en-us/library/system.datetime(v=vs.110).aspx 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).aspx https://msdn.microsoft.com/en-us/library/1k1skd40(v=vs.110).... , which doesn't have the example.
pjmlp 9y ago
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.

skohan 9y ago

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

hinkley 9y ago

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.

vec 9y ago
Don't leave us hanging. What's the other piece of advice?
- hinkley 9y ago
  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.)

jgilchrist 9y ago

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

Analemma_ 9y ago
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.
- yorwba 9y ago
  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#?
  - pjmlp 9y ago
    I see a complete E2E example here. https://msdn.microsoft.com/en-us/library/system.datetime.parse(v=vs.110).aspx#Parse1_Example https://msdn.microsoft.com/en-us/library/system.datetime.par...
    - yorwba 9y ago
      Interesting. I found https://msdn.microsoft.com/en-us/library/system.datetime(v=vs.110).aspx 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).aspx https://msdn.microsoft.com/en-us/library/1k1skd40(v=vs.110).... , which doesn't have the example.

pjmlp 9y ago

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.