5 ms·

I'm currently learning Rust (as a distinctly average programmer) and I think I agree. I put that so tentatively because I have experienced something of what Rus

I'm currently learning Rust (as a distinctly average programmer) and I think I agree. I put that so tentatively because I have experienced something of what Rust advocates claim - ie. when I've battled just trying to get a module to work at all for a while, but then when it does fit together (in a rather pleasing way, like gears snicking neatly together), it just continues to work. So I don't rule out the possibility that with more experience the fitting-together experiences will overtop the ugh-this-is-difficult ones, and I will become another Rust enthuser. But on the other hand I'm often driven mad by the complexity, not so much of the language, but the libraries. There are several very popular & foundational ones I've used where I've literally not once managed to get anything working by following the incomprehensible docs, only by chasing up blog and forum posts in the desperate hope of finding a usable snippet. Then there is the community, which despite its reputation for inclusiveness, is insufferably smug (for genuinely pleasant communities, try Elixir or Clojure). If you say something is difficult, they'll just inform you it's not, therefore by implication you must be thick or obtuse.

Cyph0n 4y ago
Out of curiosity, can you share examples of popular libraries that were difficult to get working correctly?
- aussiesnack 4y ago
  One example - clap, which is by far the most commonly recommended cli args parsing library. Plain uses of the derive api are simple enough, but I found it a huge time suck to figure out how to do anything remotely different from the docs' examples. On my first 'real' Rust project, it took nearly half my time just figuring out how to deal with cli args. In retrospect I probably should have either used the Builder api (which is more explicit) or parsed the args manually. But I've experienced similar things repeatedly. Complexity seems to be tolerated (even vaunted) by the Rust dev community at large. I don't rule out that this may have good reasons behind it (the nature of Rust's natural domain, etc).
  - rascul 4y ago
    Interesting. I find the clap derive stuff great and haven't had any trouble figuring out how to use it. Compared to anything I've done before in any other language, it's so much simpler and straightforward for me. Maybe it helps that I used structopt before clap incorporated it? I don't know. Different people can have very different experiences.
  - kibwen 4y ago
    That's fair, Clap is an 800 pound gorilla of library that is trying to be heavy-duty and production-grade. But if you're just learning Rust and want to crank out a CLI for fun or education then I'd say that Clap is overkill and a distraction from learning the language itself. There are dramatically simpler libraries out there for argument parsing, e.g. https://crates.io/crates/lexopt https://crates.io/crates/lexopt . Heck, if I was just starting out and writing a thing for fun I might just forego a library altogether and manually parse arguments from std::env::args.
    - aussiesnack 4y ago
      That was but one example of what I face at every single turn with Rust though. Complexity (not conceptual difficulty) seems to be the general culturally accepted norm. I truly don't rule out that this reasonable given Rust's domain of use. But there is a general reluctance from Rust advocates to accept that it's complex, and that this complexity makes it hard to use. I do find the intense advocacy thing singularly odd with Rust. It's not like developers have to be convinced a thing is easy for them to use it. I'm still learning Rust (for reasons). But I don't feel the need to submit to social pressure from Rust advocates to feign ease.
      - kibwen 4y ago
        > Complexity (not conceptual difficulty) seems to be the general culturally accepted norm. Can you give an example of what you mean by "complexity"? I think this could be an instance of people simply having different definitions.
pclmulqdq 4y ago
I just recently started learning rust a few months ago, and I came to the same conclusion as you about packages. Cargo seems like the biggest impediment to Rust. GCC-Rust may put Rust on track to have a decent STL since (presumably) GCC will not import a package manager. However, insisting that a package manager have first-class treatment for a systems language just seems wrong. On the other hand, the Rust STL itself is full of bit-rotting functions that have been stable for years but are still somehow only in the nightly release and haven't made it out of "experimental" status. I assume that the presence of Cargo in the ecosystem and the mentality that you can just use a crate to do what you want is a big part of this.
- kibwen 4y ago
  > GCC-Rust may put Rust on track to have a decent STL since (presumably) GCC will not import a package manager. I think you may be misunderstanding something here? GCC-Rust would have no reason to import Cargo. Cargo is a tool for resolving and managing dependencies and generating compiler invocations. GCC-Rust is a compiler that would be invoked by Cargo. > the Rust STL itself is full of bit-rotting functions that have been stable for years but are still somehow only in the nightly release and haven't made it out of "experimental" status. Rust stabilizes several new library functions with every release. Which ones are you trying to use? Rust is driven by volunteers, and many functions only get stabilized when people ask for them and present concrete use cases.
  - pclmulqdq 4y ago
    * GCC-Rust would then provide an incentive to make the STL more complete, if users of Rust on GCC don't have easy access to Cargo. * The first_entry and last_entry functions in BtreeMap come to mind immediately, but there were others I ran into. The fact that several new functions are stabilized with every release does not mean that many functions don't sit in the queue for years waiting for stabilization.
    - kibwen 4y ago
      > if users of Rust on GCC don't have easy access to Cargo. Can you clarify which users you mean? If you mean the developers of GCC-Rust, they don't need Cargo because GCC-Rust is written in C++. And users of GCC-Rust would have no problem using Cargo, assuming that GCC-Rust presents a CLI interface that's more-or-less compatible with rustc (which I assume they would want to do, because being compatible with the existing Cargo ecosystem is quite valuable). > The first_entry and last_entry functions in BtreeMap come to mind immediately, but there were others I ran into. The good news is that those functions were recently proposed for stabilization and the ten-day final comment period elapsed as of today with no objections, so these are on track to be available on stable as of Rust 1.66. As for the other functions that you allude to, I encourage you to join the libs-team Zulip and ask how best to proceed on a given API; quite often I find that there's nothing preventing an API from reaching stable other than finding someone willing to do the small amount of labor involved in documenting, writing a stabilization report, and issuing the stabilization PR.

Cyph0n 4y ago

Out of curiosity, can you share examples of popular libraries that were difficult to get working correctly?

aussiesnack 4y ago
One example - clap, which is by far the most commonly recommended cli args parsing library. Plain uses of the derive api are simple enough, but I found it a huge time suck to figure out how to do anything remotely different from the docs' examples. On my first 'real' Rust project, it took nearly half my time just figuring out how to deal with cli args. In retrospect I probably should have either used the Builder api (which is more explicit) or parsed the args manually. But I've experienced similar things repeatedly. Complexity seems to be tolerated (even vaunted) by the Rust dev community at large. I don't rule out that this may have good reasons behind it (the nature of Rust's natural domain, etc).
- rascul 4y ago
  Interesting. I find the clap derive stuff great and haven't had any trouble figuring out how to use it. Compared to anything I've done before in any other language, it's so much simpler and straightforward for me. Maybe it helps that I used structopt before clap incorporated it? I don't know. Different people can have very different experiences.
- kibwen 4y ago
  That's fair, Clap is an 800 pound gorilla of library that is trying to be heavy-duty and production-grade. But if you're just learning Rust and want to crank out a CLI for fun or education then I'd say that Clap is overkill and a distraction from learning the language itself. There are dramatically simpler libraries out there for argument parsing, e.g. https://crates.io/crates/lexopt https://crates.io/crates/lexopt . Heck, if I was just starting out and writing a thing for fun I might just forego a library altogether and manually parse arguments from std::env::args.
  - aussiesnack 4y ago
    That was but one example of what I face at every single turn with Rust though. Complexity (not conceptual difficulty) seems to be the general culturally accepted norm. I truly don't rule out that this reasonable given Rust's domain of use. But there is a general reluctance from Rust advocates to accept that it's complex, and that this complexity makes it hard to use. I do find the intense advocacy thing singularly odd with Rust. It's not like developers have to be convinced a thing is easy for them to use it. I'm still learning Rust (for reasons). But I don't feel the need to submit to social pressure from Rust advocates to feign ease.
    - kibwen 4y ago
      > Complexity (not conceptual difficulty) seems to be the general culturally accepted norm. Can you give an example of what you mean by "complexity"? I think this could be an instance of people simply having different definitions.

pclmulqdq 4y ago

I just recently started learning rust a few months ago, and I came to the same conclusion as you about packages. Cargo seems like the biggest impediment to Rust. GCC-Rust may put Rust on track to have a decent STL since (presumably) GCC will not import a package manager. However, insisting that a package manager have first-class treatment for a systems language just seems wrong. On the other hand, the Rust STL itself is full of bit-rotting functions that have been stable for years but are still somehow only in the nightly release and haven't made it out of "experimental" status. I assume that the presence of Cargo in the ecosystem and the mentality that you can just use a crate to do what you want is a big part of this.

kibwen 4y ago
> GCC-Rust may put Rust on track to have a decent STL since (presumably) GCC will not import a package manager. I think you may be misunderstanding something here? GCC-Rust would have no reason to import Cargo. Cargo is a tool for resolving and managing dependencies and generating compiler invocations. GCC-Rust is a compiler that would be invoked by Cargo. > the Rust STL itself is full of bit-rotting functions that have been stable for years but are still somehow only in the nightly release and haven't made it out of "experimental" status. Rust stabilizes several new library functions with every release. Which ones are you trying to use? Rust is driven by volunteers, and many functions only get stabilized when people ask for them and present concrete use cases.
- pclmulqdq 4y ago
  * GCC-Rust would then provide an incentive to make the STL more complete, if users of Rust on GCC don't have easy access to Cargo. * The first_entry and last_entry functions in BtreeMap come to mind immediately, but there were others I ran into. The fact that several new functions are stabilized with every release does not mean that many functions don't sit in the queue for years waiting for stabilization.
  - kibwen 4y ago
    > if users of Rust on GCC don't have easy access to Cargo. Can you clarify which users you mean? If you mean the developers of GCC-Rust, they don't need Cargo because GCC-Rust is written in C++. And users of GCC-Rust would have no problem using Cargo, assuming that GCC-Rust presents a CLI interface that's more-or-less compatible with rustc (which I assume they would want to do, because being compatible with the existing Cargo ecosystem is quite valuable). > The first_entry and last_entry functions in BtreeMap come to mind immediately, but there were others I ran into. The good news is that those functions were recently proposed for stabilization and the ten-day final comment period elapsed as of today with no objections, so these are on track to be available on stable as of Rust 1.66. As for the other functions that you allude to, I encourage you to join the libs-team Zulip and ask how best to proceed on a given API; quite often I find that there's nothing preventing an API from reaching stable other than finding someone willing to do the small amount of labor involved in documenting, writing a stabilization report, and issuing the stabilization PR.