8 ms·

This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle havi

This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle having a batteries included standard lib just fine.

0cf8612b2e1e 27d ago
On the other hand, there are some bad Go standard libraries that are frozen in time.
- rirze 27d ago
  which, as painful as it may be, is ok. Better to have a safe functional stdlib library than a exposed external crate (which then asks the question; what's the replacement...)
  - lesuorac 27d ago
    Those aren't the only two choices. We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. To me the answer is still to vendor your dependencies and don't be on the bleeding edge of updates unless you're willing to invest the time into validating them.
    - kergonath 27d ago
      > We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. I think it goes without saying that emulating PHP is rarely a good decision.
      - VorpalWay 27d ago
        Don't forget C++ where large parts of the standard library are unusable (regex is slow and unfixable) or soft deprecated (dont use iostreams for formatting, use std::format, etc). No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.
        pjmlp 27d ago
        Regex does the job for most business software, iostreams is alright, using them since 1993, std::format is cool provided one has control over their compiler version,...
        VorpalWay 27d ago
        Regex is absolutely not suitable for most use cases that I have come across. Iostreams formatting is awful, especially if you care about internationalization (which is very common). Not sure what the issue with std::format would be here, you would have to elaborate. Obviously you need to specify a minimum version to have support for it at all.
        pjmlp 27d ago
        It works good enough for stuff I would be using Java or .NET for. Not every application requires internationalisation, especially server code or internal company tools.
- bigstrat2003 27d ago
  Which isn't actually a problem. You can ignore the bad standard library and use something different.
- pjmlp 27d ago
  Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries. I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.
  - pie_flavor 27d ago
    Platform support is a non-issue for every library being discussed. This is an array construction macro, it has nothing to do with what operating system you're running on.
    - pjmlp 27d ago
      Just because some trees have a specific trait, it doesn't mean the whole forest is the same.
      - imtringued 27d ago
        Your argument only works for no_std crates, but the std exists and allows the vast majority of crates to be cross platform out of the box.
        pjmlp 25d ago
        I bet there are plenty of them that don't work on IBM i, while Java does fine there. Just to quote a possible scenario among others.
  - dwattttt 27d ago
    Add more and more to a standard library, and you're going to start losing your "works everywhere".
    - pjmlp 27d ago
      Naturally there is a balance, still I think Java, .NET, Python, Go, Smalltalk, manage quite well, while having subsets to slim down when needed for specific deployment scenarios like embedded devices.
afdbcreid 27d ago
People confuse what they want. They do not want a big stdlib. The downsides are real (the stdlib cannot make breaking changes), and there are no upsides (except, maybe, for faster compilation, since std comes precompiled). They want more official crates (e.g. `regex` and `libc` are official crates, maintained by the Rust project). And the Rust project does not oppose to that, it just doesn't have the funding.
- Pannoniae 27d ago
  Who said a standard library can't make breaking changes? That used to be a norm some time ago. There are upsides, your program is smaller, better security because a random kid can't pwn your deps, quality and interoperability. What's not to love?
  - afdbcreid 27d ago
    > Who said a standard library can't make breaking changes? The std making a breaking change is the language making a breaking change. Most mainstream languages guarantee stability, certainly Rust. > your program is smaller How so? It doesn't matter if the code is in std or a crate. > better security because a random kid can't pwn your deps, quality and interoperability That's exactly what I said: you don't need bigger std, you just need more official crates.
    - Pannoniae 27d ago
      >Most mainstream languages guarantee stability, certainly Rust. That's their mistake, right there... When you're upgrading software, you presumably want a better version. You can't have something better without changing it. It's a logical contradiction. >It doesn't matter if the code is in std or a crate. It very much does because you don't need 95% of the random stuff in the crates. Even for something like rand, you need an xorshift and that's roughly it. 25 lines of code, sorted. You can even write it as a copypaste "dependency" without much fuss in practically any language. That, versus importing a whole rand library with lots of different algorithms, deps on crypto, tests, OS random-based seeding, customisability, etc. >you just need more official crates I guess that's one solution but it would probably just be a better idea to split std in two SLAs, one is guaranteed for core stuff i.e. the status quo, one is YMMV.

0cf8612b2e1e 27d ago

On the other hand, there are some bad Go standard libraries that are frozen in time.

rirze 27d ago
which, as painful as it may be, is ok. Better to have a safe functional stdlib library than a exposed external crate (which then asks the question; what's the replacement...)
- lesuorac 27d ago
  Those aren't the only two choices. We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. To me the answer is still to vendor your dependencies and don't be on the bleeding edge of updates unless you're willing to invest the time into validating them.
  - kergonath 27d ago
    > We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. I think it goes without saying that emulating PHP is rarely a good decision.
    - VorpalWay 27d ago
      Don't forget C++ where large parts of the standard library are unusable (regex is slow and unfixable) or soft deprecated (dont use iostreams for formatting, use std::format, etc). No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.
      - pjmlp 27d ago
        Regex does the job for most business software, iostreams is alright, using them since 1993, std::format is cool provided one has control over their compiler version,...
        VorpalWay 27d ago
        Regex is absolutely not suitable for most use cases that I have come across. Iostreams formatting is awful, especially if you care about internationalization (which is very common). Not sure what the issue with std::format would be here, you would have to elaborate. Obviously you need to specify a minimum version to have support for it at all.
        pjmlp 27d ago
        It works good enough for stuff I would be using Java or .NET for. Not every application requires internationalisation, especially server code or internal company tools.
bigstrat2003 27d ago
Which isn't actually a problem. You can ignore the bad standard library and use something different.
pjmlp 27d ago
Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries. I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.
- pie_flavor 27d ago
  Platform support is a non-issue for every library being discussed. This is an array construction macro, it has nothing to do with what operating system you're running on.
  - pjmlp 27d ago
    Just because some trees have a specific trait, it doesn't mean the whole forest is the same.
    - imtringued 27d ago
      Your argument only works for no_std crates, but the std exists and allows the vast majority of crates to be cross platform out of the box.
      - pjmlp 25d ago
        I bet there are plenty of them that don't work on IBM i, while Java does fine there. Just to quote a possible scenario among others.
- dwattttt 27d ago
  Add more and more to a standard library, and you're going to start losing your "works everywhere".
  - pjmlp 27d ago
    Naturally there is a balance, still I think Java, .NET, Python, Go, Smalltalk, manage quite well, while having subsets to slim down when needed for specific deployment scenarios like embedded devices.

afdbcreid 27d ago

People confuse what they want. They do not want a big stdlib. The downsides are real (the stdlib cannot make breaking changes), and there are no upsides (except, maybe, for faster compilation, since std comes precompiled). They want more official crates (e.g. `regex` and `libc` are official crates, maintained by the Rust project). And the Rust project does not oppose to that, it just doesn't have the funding.

Pannoniae 27d ago
Who said a standard library can't make breaking changes? That used to be a norm some time ago. There are upsides, your program is smaller, better security because a random kid can't pwn your deps, quality and interoperability. What's not to love?
- afdbcreid 27d ago
  > Who said a standard library can't make breaking changes? The std making a breaking change is the language making a breaking change. Most mainstream languages guarantee stability, certainly Rust. > your program is smaller How so? It doesn't matter if the code is in std or a crate. > better security because a random kid can't pwn your deps, quality and interoperability That's exactly what I said: you don't need bigger std, you just need more official crates.
  - Pannoniae 27d ago
    >Most mainstream languages guarantee stability, certainly Rust. That's their mistake, right there... When you're upgrading software, you presumably want a better version. You can't have something better without changing it. It's a logical contradiction. >It doesn't matter if the code is in std or a crate. It very much does because you don't need 95% of the random stuff in the crates. Even for something like rand, you need an xorshift and that's roughly it. 25 lines of code, sorted. You can even write it as a copypaste "dependency" without much fuss in practically any language. That, versus importing a whole rand library with lots of different algorithms, deps on crypto, tests, OS random-based seeding, customisability, etc. >you just need more official crates I guess that's one solution but it would probably just be a better idea to split std in two SLAs, one is guaranteed for core stuff i.e. the status quo, one is YMMV.