Things you can find in go’s built in to the language or in standard libraries that need a dependency in Rust:
- green threads
- channels
- regular expressions
- http client
- http server
- time
- command line flags
- a logger
- read and write animated GIFs
I don’t love the Go language, but it’s the leader for tooling and standard library, definitely the best I’ve used.
As a beginner this is horrible, because everybody knows serde, but I have to learn that serde is the defacto, and that is not easy because when coming from other languages, it sounds like the second best choice. And that is with most rust crates.
You could of course argue that that's why no-std exists in Rust, or that your compiler might optimize out the animated GIF routines, but personally, I'd argue that in this context, it is bloat, that - while it could occasionally be useful - it could just as easily be a third party library.
For a microcontroller sized runtime, there’s https://tinygo.org/
I think the lack of strong standard library actually leads to more bloat in your program in the long run. Bloat is needing to deal with an ecosystem that has 4 competing packages for time, ending up with all 4 installed because other libraries you need didn’t agree, and then you need ancillary compatibility packages for converting between the different time packages.
I don't think that's true. If the standard library is pre-compiled, and it doesn't use `-ffunction-sections` etc. then I'm pretty sure you'll just get the whole thing.
There is experimental support for building Rust's standard library from source, but by default it is pre-compiled.
It seems like a bad reason to constrain the regular standard library
E.g. for esp32 see https://docs.esp-rs.org/book/overview/using-the-standard-lib...