5 ms·

This was something that surprised me about the Rust ecosystem, coming from Go. Even a mature Go project (e.g. some business' production web backend) may only ha

by abound 2y ago

This was something that surprised me about the Rust ecosystem, coming from Go. Even a mature Go project (e.g. some business' production web backend) may only have 10-20 dependencies including the transitive ones. As noted in this post, even a small Rust project will likely have many more than that, and it's virtually guaranteed if you're doing async stuff. No idea how much of it is cultural versus based on the language features, e.g. in Go interfaces are implicitly satisfied, no need to import anything to say you implement it.

petecorreia 2y ago
Go's vast standard library helps a lot with keeping dependency numbers down
- lionkor 2y ago
  Exactly this. You want logging in Rust? You will need at least `log` and another logger crate, for example `env_logger`, maybe the `dotenvy` crate to read `.env` files automatically, you already have 3 direct dependencies + all the transitive ones. In Go: https://pkg.go.dev/log https://pkg.go.dev/log
  - LinXitoW 2y ago
    The built-in "logging" in Go is barely more than a fancy Println. For example, where are the levels, like DEBUG and WARN?
    - nickzelei 2y ago
      https://pkg.go.dev/log/slog https://pkg.go.dev/log/slog
    - jcgl 2y ago
      The slog (structured logging) package of the stdlib has those, I believe. As well as support for custom levels.
Cyph0n 2y ago
For Rust and Go in particular, the difference is in the standard library. The Rust stdlib is (intentionally) small.
- sesm 2y ago
  I would expect crates like `stdlib-terminal` and `stdlib-web-api` in that case. Honestly, something feels off with Rust trying to advertise itself for embedded: no stdlib and encourage stack allocation, but then married to Clang (which doesn't have a good embedded target support) and have panic in the language. Building a C++ replacement for a browser engine rewrite and building a C replacement for embedded have different and often conflicting design constraints. It seems like Rust is a C++ replacement with extra unnecessary constraints of a C replacement.
  - palata 2y ago
    I often wonder about this: obviously Rust is fashionable, and many people push to use it everywhere. But in a ton of situations, there are modern memory-safe languages (Go, Swift, Kotlin, Scala, Java, ...) that are better suited. To me Rust is good when you need the performance (e.g. computer vision) and when you don't want a garbage collector (e.g. embedded). So really, a replacement for C/C++. Even though it takes time because C/C++ have a ton of libraries that may not have been ported to Rust (yet). Anyway, I guess my point is that Rust should focus on the problem it solves. Sometimes I feel like people try to make it sound like a competitor to those other memory-safe languages and... even though I like Rust as a language, it's much easier to write Go, Swift or Kotlin than Rust (IMHO).
    - jcgrillo 2y ago
      > it's much easier to write Go, Swift or Kotlin than Rust (IMHO). While I respect your opinion, I must say I find it much more difficult to get work done in golang than rust. Mainly due to stringly typed errors and nonexistent documentation culture. Trying to figure out what error states my program might get itself into is essentially a futile exercise in golang whereas in rust it's generally annotated right there in the source code by lsp.
jitl 2y ago
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.
- drrotmos 2y ago
  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.
  - jitl 2y ago
    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/ 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.
    - IshKebab 2y ago
      > 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.

by abound 2y ago

petecorreia 2y ago

Go's vast standard library helps a lot with keeping dependency numbers down

lionkor 2y ago
Exactly this. You want logging in Rust? You will need at least `log` and another logger crate, for example `env_logger`, maybe the `dotenvy` crate to read `.env` files automatically, you already have 3 direct dependencies + all the transitive ones. In Go: https://pkg.go.dev/log https://pkg.go.dev/log
- LinXitoW 2y ago
  The built-in "logging" in Go is barely more than a fancy Println. For example, where are the levels, like DEBUG and WARN?
  - nickzelei 2y ago
    https://pkg.go.dev/log/slog https://pkg.go.dev/log/slog
  - jcgl 2y ago
    The slog (structured logging) package of the stdlib has those, I believe. As well as support for custom levels.

Cyph0n 2y ago

For Rust and Go in particular, the difference is in the standard library. The Rust stdlib is (intentionally) small.

sesm 2y ago
I would expect crates like `stdlib-terminal` and `stdlib-web-api` in that case. Honestly, something feels off with Rust trying to advertise itself for embedded: no stdlib and encourage stack allocation, but then married to Clang (which doesn't have a good embedded target support) and have panic in the language. Building a C++ replacement for a browser engine rewrite and building a C replacement for embedded have different and often conflicting design constraints. It seems like Rust is a C++ replacement with extra unnecessary constraints of a C replacement.
- palata 2y ago
  I often wonder about this: obviously Rust is fashionable, and many people push to use it everywhere. But in a ton of situations, there are modern memory-safe languages (Go, Swift, Kotlin, Scala, Java, ...) that are better suited. To me Rust is good when you need the performance (e.g. computer vision) and when you don't want a garbage collector (e.g. embedded). So really, a replacement for C/C++. Even though it takes time because C/C++ have a ton of libraries that may not have been ported to Rust (yet). Anyway, I guess my point is that Rust should focus on the problem it solves. Sometimes I feel like people try to make it sound like a competitor to those other memory-safe languages and... even though I like Rust as a language, it's much easier to write Go, Swift or Kotlin than Rust (IMHO).
  - jcgrillo 2y ago
    > it's much easier to write Go, Swift or Kotlin than Rust (IMHO). While I respect your opinion, I must say I find it much more difficult to get work done in golang than rust. Mainly due to stringly typed errors and nonexistent documentation culture. Trying to figure out what error states my program might get itself into is essentially a futile exercise in golang whereas in rust it's generally annotated right there in the source code by lsp.

jitl 2y ago

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.

drrotmos 2y ago
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.
- jitl 2y ago
  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/ 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.
  - IshKebab 2y ago
    > 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.