Hacker News new | past | comments | ask | show | jobs | submit login

One big reason is because Go has a very nice complete standard library, and Rust really does not.

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.




I hate that. I don't want dependencies for serialization or logging. But you do and now you have to choose which of the dozen logging crates you need.

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.


This is why things like https://blessed.rs exist. Although since they're unofficial, their discoverability is also likely a problem.


Thanks for that. Didn’t know about the site


Which may or may not be fine in a Go binary that runs on a modern desktop CPU, but what if your code is supposed to run on say an ESP32-C3 with a whopping 160 MHz RISC-V core, 400 KB of RAM and maybe 2 MB of XIP flash storage?

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.


It’s the same as in C, Rust, or any other programming language I’ve ever used. If you don’t use a library, it doesn’t end up linked in your executable. Don’t want to animate GIFs on your microcontroller, then you don’t write `import “image/gif”` in your source file.

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.


> It’s the same as in C, Rust, or any other programming language I’ve ever used. If you don’t use a library, it doesn’t end up linked in your executable.

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's hardly the case that a good reason to not have a more complete standard library on the basis of having to do a tiny bit more work in a more special case to get binary sizes down.


No I totally agree. IMO Rust should have a more complete standard library.


Does anyone use the full standard library for embedded targets? I've not seen it done in C, java has a special embedded edition, python has micro-python, rust seems to usually use no-std, but I might be wrong there.

It seems like a bad reason to constrain the regular standard library


I have in the past, but most people don't.

E.g. for esp32 see https://docs.esp-rs.org/book/overview/using-the-standard-lib...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: