5 ms·

> Rust is not a panacea. Amen to that. I don't understand why more people don't highlight Rust's main weakness. The lack of strong stdlib. No stdlib means yo

> Rust is not a panacea. Amen to that. I don't understand why more people don't highlight Rust's main weakness. The lack of strong stdlib. No stdlib means you have two choices: (a) Re-invent the wheel; or (b) Use a crate. Most people choose (b) because they don't have the time, inclination or expertise to do (a). Which means you open yourself up to supply chain attacks, unless you constantly audit the upstream crates, which, let's face it, most people won't, they probably won't even audit the original version they pulled in, let alone the updates. Which means with something like an nginx re-write in Rust, which is a complex piece of software with many moving parts, you end up importing a whole ton of random crates. Half of which will probably become abandonware within a few years, because that's the way of the world with open-source, maintainers move on to bigger and better things. There is a difference between rewrite in Rust and rewrite properly in Rust. No doubt there are people out there doing solid open source work with Rust (e.g. the guys at tweede golf) but that takes time and effort, and in the case of tweede golf, the extra effort is financially sponsored, something that is not the case with most open source projects, especially the single-maintainer ones.

bborud 3y ago
Yeah, the poor stdlib is the main reason Go is my go-to (no pun intended) language for writing servers rather than Rust. That and the slow compiler, which a lot of people think shouldn't matter, but does matter.
- traceroute66 3y ago
  > language for writing servers Or indeed clients. In 2024 you shouldn't need to import third-party code to make a call to a REST endpoint and parse the JSON. Or the same with crypto. All the stuff that's bread-and-butter in today's cloud-centric world, you shouldn't need to farm out to third-party code, it should be stdlib.
  - callalex 3y ago
    That’s a bit of a slippery slope though and causes maintinence nightmares for mature projects. Let’s say I want to upgrade to a new more secure TLS protocol. If it’s bundled to the language version that may mean changing the entire concurrency model, or something equally burdensome on a million line code base.
    - traceroute66 3y ago
      > That’s a bit of a slippery slope though and causes maintinence nightmares for mature projects. I'm sorry, but I'm having great difficulty following your line of argument. Are you seriously suggesting that Go does not have any mature projects ? If not, are you seriously suggesting that the mature Go projects in Go are encountering maintenance nightmares because of stdlib ? Your line of argument is giving off a whiff of FUD, sadly.
      - hombre_fatal 3y ago
        Well, they’re right. When the changes you want are part of the stdlib, then you may have to take on many changes you don’t want just to get the one change you do want. It’s a well known trade off. A good middle ground here is to have official crates/pkgs managed by the core organization that can be upgraded separately.
        bborud 3y ago
        Do you have any real-world examples of this happening in Go?
      - callalex 3y ago
        Discussing objective engineering tradeoffs is not the same as spreading FUD. It's baffling that you are so quick to shut down conversation and get combative. I never implied that there are no mature Go projects, just that the burden of maintenance is different than that of other languages that choose to break out more functionality into libraries, and that having a comprehensive stdlib is not 100% upsides as you implied.
  - everforward 3y ago
    If you want an opposing opinion, check out Python. I haven't seen anyone use urllib in the stdlib in like a decade. Putting things like that in the stdlib makes them subject to the same API stability constraints as stuff like the threading API. They tend to ossify and get abandoned when a 3rd party lib makes a faster, or better, or just more convenient API. Go has a fair bit of this. I haven't touched the stdlib logger in forever. The HTTP server side is kinda meh, the client side is okay but not fantastic. I am a fan of Go's experimental packages. I kind of wish things could live there permanently as "things the core devs believe are a good implementation, but don't want to bind stability guarantees to the language".
    - traceroute66 3y ago
      > If you want an opposing opinion, check out Python. I would argue that Go is a fair comparison, Python is not. Python is just a mess of a language, dependency hell etc. > Go has a fair bit of this. I haven't touched the stdlib logger in forever. You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib.
      - everforward 3y ago
        > You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib. I do, it's just twice as slow as the old stdlib logger, which was already twice as slow as 3rd party loggers, and it makes like 8x as many allocs as zap. If I were going to change my logger, it would be to zerolog, not slog. > Python is just a mess of a language, dependency hell etc. We're talking about stdlib though, which are the only packages dependency hell doesn't apply to. > I would argue that Go is a fair comparison, Python is not. Go is the youngest of the major languages, making it one of the worst place to check if you want to see how packages age in the stdlib. Look at a language that's actually old if you want to see the kind of problems old apps face. It also has a weird place, language-wise, because its developed by Google who has an unusual amount of influence over developer patterns. Other languages have to follow devs to where they are, Go can kind of lead the way via Google.
finaard 3y ago
Also: No bootstrapping rustc from source. There are a bunch of projects trying to get that fixed, but currently pretty much everybody relies on binaries coming from upstream. Having a core infrastructure component like nginx rely on a compiler we can't verify would make a supply chain attack against the compiler very attractive.

bborud 3y ago

Yeah, the poor stdlib is the main reason Go is my go-to (no pun intended) language for writing servers rather than Rust. That and the slow compiler, which a lot of people think shouldn't matter, but does matter.

traceroute66 3y ago
> language for writing servers Or indeed clients. In 2024 you shouldn't need to import third-party code to make a call to a REST endpoint and parse the JSON. Or the same with crypto. All the stuff that's bread-and-butter in today's cloud-centric world, you shouldn't need to farm out to third-party code, it should be stdlib.
- callalex 3y ago
  That’s a bit of a slippery slope though and causes maintinence nightmares for mature projects. Let’s say I want to upgrade to a new more secure TLS protocol. If it’s bundled to the language version that may mean changing the entire concurrency model, or something equally burdensome on a million line code base.
  - traceroute66 3y ago
    > That’s a bit of a slippery slope though and causes maintinence nightmares for mature projects. I'm sorry, but I'm having great difficulty following your line of argument. Are you seriously suggesting that Go does not have any mature projects ? If not, are you seriously suggesting that the mature Go projects in Go are encountering maintenance nightmares because of stdlib ? Your line of argument is giving off a whiff of FUD, sadly.
    - hombre_fatal 3y ago
      Well, they’re right. When the changes you want are part of the stdlib, then you may have to take on many changes you don’t want just to get the one change you do want. It’s a well known trade off. A good middle ground here is to have official crates/pkgs managed by the core organization that can be upgraded separately.
      - bborud 3y ago
        Do you have any real-world examples of this happening in Go?
    - callalex 3y ago
      Discussing objective engineering tradeoffs is not the same as spreading FUD. It's baffling that you are so quick to shut down conversation and get combative. I never implied that there are no mature Go projects, just that the burden of maintenance is different than that of other languages that choose to break out more functionality into libraries, and that having a comprehensive stdlib is not 100% upsides as you implied.
- everforward 3y ago
  If you want an opposing opinion, check out Python. I haven't seen anyone use urllib in the stdlib in like a decade. Putting things like that in the stdlib makes them subject to the same API stability constraints as stuff like the threading API. They tend to ossify and get abandoned when a 3rd party lib makes a faster, or better, or just more convenient API. Go has a fair bit of this. I haven't touched the stdlib logger in forever. The HTTP server side is kinda meh, the client side is okay but not fantastic. I am a fan of Go's experimental packages. I kind of wish things could live there permanently as "things the core devs believe are a good implementation, but don't want to bind stability guarantees to the language".
  - traceroute66 3y ago
    > If you want an opposing opinion, check out Python. I would argue that Go is a fair comparison, Python is not. Python is just a mess of a language, dependency hell etc. > Go has a fair bit of this. I haven't touched the stdlib logger in forever. You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib.
    - everforward 3y ago
      > You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib. I do, it's just twice as slow as the old stdlib logger, which was already twice as slow as 3rd party loggers, and it makes like 8x as many allocs as zap. If I were going to change my logger, it would be to zerolog, not slog. > Python is just a mess of a language, dependency hell etc. We're talking about stdlib though, which are the only packages dependency hell doesn't apply to. > I would argue that Go is a fair comparison, Python is not. Go is the youngest of the major languages, making it one of the worst place to check if you want to see how packages age in the stdlib. Look at a language that's actually old if you want to see the kind of problems old apps face. It also has a weird place, language-wise, because its developed by Google who has an unusual amount of influence over developer patterns. Other languages have to follow devs to where they are, Go can kind of lead the way via Google.

finaard 3y ago

Also: No bootstrapping rustc from source. There are a bunch of projects trying to get that fixed, but currently pretty much everybody relies on binaries coming from upstream. Having a core infrastructure component like nginx rely on a compiler we can't verify would make a supply chain attack against the compiler very attractive.