4 ms·

> I have a lot, and find useful to turn some python stuff so is easier to ship (surely Go work here...) That’s basically how I learned Go. The language is very

by oefrha 6y ago

> I have a lot, and find useful to turn some python stuff so is easier to ship (surely Go work here...) That’s basically how I learned Go. The language is very simple coming from practically any imperative language, once I stopped hating on the directory structure imposed on me (Go module helped) and went through the short language tour, code basically flowed. Even got a nice productivity boost over Python when dealing with concurrency. Rust is totally different. Want to deal with a few strings? Fight with borrow checker for an hour. Want some functionality outside the practically nonexistent standard library? Frantically try to find a library, turning up either none or a bunch without clear winner. Realizing that examples are outdated. Then fight with borrow checker for another hour. After a while I ask myself, why the hell should I subject myself to this torture when I don’t need to squeeze out every ounce of performance? Switch to Go or Python, be done in an hour. esr had a similar experience: http://esr.ibiblio.org/?p=7294 http://esr.ibiblio.org/?p=7294 > In practice, I found Rust painful to the point of unusability. The learning curve was far worse than I expected; it took me those four days of struggling with inadequate documentation to write 67 lines of wrapper code for the server. > Even things that should be dirt-simple, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done. > The contrast with Go is extreme. By four days in of exploring Go I had mastered most of the language, had a working program and tests, and was adding features to taste. (Not saying Go doesn’t have pain points. Specifically for writing command line tools, the argument parsing story is garbage.) Oh and I did end up learning Rust to a reasonable degree, one way or another.

estebank 6y ago
I always found that esr post quite bizarre. He's the self-proclaimed best known software developer in the world, having written quite a bit of C over the years and yet doesn't see the need or benefit of differentiating between heap allocated strings (String) and string slices into them (&str)? Complaining about Rust's documentation is a bit weird because even back in 2015 there was quite a bit of good documentation, let alone 2017 and the language encourages good crate API documentation. I also find it ironic that the author of The Cathedral and The Bazaar would say: > The Rust community appears to have elected to use the decentralized nature of their crate system (which undeniably has some very nice technical properties) to execute a swarm attack on the design space around the language. Which is wonderful in theory but seems to be failing in practice. There are certainly deficiencies in the language and the ecosystem, but to me they stem from immaturity, only 5 years out from 1.0, and not from any fundamental major mistake. It always seemed to me that what happened here is what happens often with a lot of experienced people that try Rust and bounce, where they approach the endeavour as "I know how to program, this will be easy, I just have to map my already existing mental framework to the new language" and hit walls early on because Rust is different enough but they didn't anticipate it. Functional languages have similar issues, but the more "esoteric" syntax helps flip a switch in people's minds to learning mode. This happened to me back in May of 2015 and it wasn't until I picked it up a few months later that it clicked.
- zozbot234 6y ago
  The biggest beef ESR had with the language as it looked like back in 2017 was the lack of a consistent story around async programming. Obviously the Rust of 2020 is rather more developed.
- eloff 6y ago
  This mirrors my experience with Rust. That said, I'm currently creating a shared library in Rust because it seems to be the best tool for the job. If it needs to run in the browser, or React native, I use TypeScript. Else if it needs to run on the JVM I use Kotlin. Else if performance doesn't matter and the project is small, I use Python. Else if I can use a garbage collector, I use Go. Because why manually manage memory with the borrow checker in Rust if I can let the runtime handle it? Else Rust. Because I don't want to mess with C++ anymore.
  - acomjean 6y ago
    Are you saying that different languages are best suited for specific tasks? There’s not one to rule them all? Sarcasm aside, choosing languages this way makes great sense. Though it can be hard if you don’t one that’s ideally suited to your problem set.
    - eloff 6y ago
      Yeah, I know, shocking. I don't know Rust, I've just read the book before and played around with it a little. So using C or C++ would have been a more natural choice - but I like having an opportunity to add another tool to my belt. Compared to learning Go it's been a slog.

by oefrha 6y ago

estebank 6y ago

I always found that esr post quite bizarre. He's the self-proclaimed best known software developer in the world, having written quite a bit of C over the years and yet doesn't see the need or benefit of differentiating between heap allocated strings (String) and string slices into them (&str)? Complaining about Rust's documentation is a bit weird because even back in 2015 there was quite a bit of good documentation, let alone 2017 and the language encourages good crate API documentation. I also find it ironic that the author of The Cathedral and The Bazaar would say: > The Rust community appears to have elected to use the decentralized nature of their crate system (which undeniably has some very nice technical properties) to execute a swarm attack on the design space around the language. Which is wonderful in theory but seems to be failing in practice. There are certainly deficiencies in the language and the ecosystem, but to me they stem from immaturity, only 5 years out from 1.0, and not from any fundamental major mistake. It always seemed to me that what happened here is what happens often with a lot of experienced people that try Rust and bounce, where they approach the endeavour as "I know how to program, this will be easy, I just have to map my already existing mental framework to the new language" and hit walls early on because Rust is different enough but they didn't anticipate it. Functional languages have similar issues, but the more "esoteric" syntax helps flip a switch in people's minds to learning mode. This happened to me back in May of 2015 and it wasn't until I picked it up a few months later that it clicked.

zozbot234 6y ago
The biggest beef ESR had with the language as it looked like back in 2017 was the lack of a consistent story around async programming. Obviously the Rust of 2020 is rather more developed.
eloff 6y ago
This mirrors my experience with Rust. That said, I'm currently creating a shared library in Rust because it seems to be the best tool for the job. If it needs to run in the browser, or React native, I use TypeScript. Else if it needs to run on the JVM I use Kotlin. Else if performance doesn't matter and the project is small, I use Python. Else if I can use a garbage collector, I use Go. Because why manually manage memory with the borrow checker in Rust if I can let the runtime handle it? Else Rust. Because I don't want to mess with C++ anymore.
- acomjean 6y ago
  Are you saying that different languages are best suited for specific tasks? There’s not one to rule them all? Sarcasm aside, choosing languages this way makes great sense. Though it can be hard if you don’t one that’s ideally suited to your problem set.
  - eloff 6y ago
    Yeah, I know, shocking. I don't know Rust, I've just read the book before and played around with it a little. So using C or C++ would have been a more natural choice - but I like having an opportunity to add another tool to my belt. Compared to learning Go it's been a slog.