4 ms·

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 lo

by 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.
      - bborud 3y ago
        I think it is worth trying to relate it to lived experience and ask "is this actually a problem or are we imagining problems that are unlikely to manifest?". I used to develop in Java in large organizations for many years and be responsible for deciding how we use the language, what libraries we use etc. I used to be pretty hard on developers who would choose third party libraries for anything the standard library already delivered. Even in cases where third party libraries were perhaps a bit better than the standard library. They'd have to offer a clear and significant advantage over the standard library over time to warrant consideration. Especially if we're talking about core functionality or something that would be expensive to replace later. Every third party dependency you introduce is a potential problem because you have to track them. You have to care about their development and release practices, you have to track their license (which may change), the health of the project, you have to know how they respond to defects being discovered etc. You have to do this for every single piece of third party code if the code you work on is critical to your business. My real-world experience is that third party code carries a much higher risk than whatever you depend on from a standard library and you can make mistakes that end up being extremely costly.
      - traceroute66 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. What on earth are you on about ? An assertion was made that Go stdlib was somehow "a slippery slope though and causes maintinence nightmares for mature projects". It is a rather bizarre assertion to make, especially in relation to Go. I am therefore merely asking for evidence of that assertion. Because, frankly, it smells of FUD and you know it. But instead you are the one looking to shut down the conversation by not answering the perfectly reasonable questions I posed.
  - bborud 3y ago
    I'd be tempted to think that if an application is designed in a way where switching your TLS implementation has consequences for the concurrency model, you have some serious design challenges. That being said, a good reason for using Go and its standard library is that they have been very good in terms of keeping important things in good shape and they put a lot more care into smoothing upgrades than is usually the case for random libraries. That's much of the motivation for using standard libraries: they have to be maintained in a manner that doesn't blow up billions of lines of running code. Third party libraries tend to be a far more mixed bag. As for crypto: I shudder to think what it was like to use SSL/TLS in the C/C++/Java world. Horrific implementations that are fiddly to work with so you won't be inclined to mess with them more than you absolutely need to in regimens that rarely, if ever, pushes you to improve security as algorithm preferences shift over time. We've made heavy use of the crypto parts of Go to build our own PKI solution for an IOT platform and it was a lot easier than in any language we've used before. By a good margin. I think you inadvertently made the argument for using Go and its standard library :-) (Of course, 10 years down the road, perhaps people have abandoned Go and it has become a wasteland and there's some other language with a better stdlib you should be using. But ask yourself this: how much of the code you have written in the past is still running unchanged? You'll have to evolve, develop and adapt over time no matter what so if Go were to fade away, it isn't going to happen overnight and you'll have plenty of time to move on)
    - everforward 3y ago
      > I'd be tempted to think that if an application is designed in a way where switching your TLS implementation has consequences for the concurrency model, you have some serious design challenges. I think you're misunderstanding OP's theoretical. If TLS is in the stdlib, that means its version is tied to the version of the language you're using. I.e. if you want to upgrade to a newer TLS, you need to upgrade your entire language version (compiler, interpreter, whatever). So you can end up in a spot where you need to go from v1 of a language to v2 to get a modern TLS implementation. However if v2 of the language also contains changes to how the language handles threading, you now need to rewrite your app's threading to be compatible with v2 of the language, just so you can get a safe TLS implementation. Basically because TLS is in the stdlib, TLS can force you to upgrade your language version. If TLS was 3rd party, you could upgrade the library without upgrading your language version (presuming the TLS library supports your language version).
- 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.

by bborud 3y ago

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.
    - bborud 3y ago
      I think it is worth trying to relate it to lived experience and ask "is this actually a problem or are we imagining problems that are unlikely to manifest?". I used to develop in Java in large organizations for many years and be responsible for deciding how we use the language, what libraries we use etc. I used to be pretty hard on developers who would choose third party libraries for anything the standard library already delivered. Even in cases where third party libraries were perhaps a bit better than the standard library. They'd have to offer a clear and significant advantage over the standard library over time to warrant consideration. Especially if we're talking about core functionality or something that would be expensive to replace later. Every third party dependency you introduce is a potential problem because you have to track them. You have to care about their development and release practices, you have to track their license (which may change), the health of the project, you have to know how they respond to defects being discovered etc. You have to do this for every single piece of third party code if the code you work on is critical to your business. My real-world experience is that third party code carries a much higher risk than whatever you depend on from a standard library and you can make mistakes that end up being extremely costly.
    - traceroute66 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. What on earth are you on about ? An assertion was made that Go stdlib was somehow "a slippery slope though and causes maintinence nightmares for mature projects". It is a rather bizarre assertion to make, especially in relation to Go. I am therefore merely asking for evidence of that assertion. Because, frankly, it smells of FUD and you know it. But instead you are the one looking to shut down the conversation by not answering the perfectly reasonable questions I posed.
- bborud 3y ago
  I'd be tempted to think that if an application is designed in a way where switching your TLS implementation has consequences for the concurrency model, you have some serious design challenges. That being said, a good reason for using Go and its standard library is that they have been very good in terms of keeping important things in good shape and they put a lot more care into smoothing upgrades than is usually the case for random libraries. That's much of the motivation for using standard libraries: they have to be maintained in a manner that doesn't blow up billions of lines of running code. Third party libraries tend to be a far more mixed bag. As for crypto: I shudder to think what it was like to use SSL/TLS in the C/C++/Java world. Horrific implementations that are fiddly to work with so you won't be inclined to mess with them more than you absolutely need to in regimens that rarely, if ever, pushes you to improve security as algorithm preferences shift over time. We've made heavy use of the crypto parts of Go to build our own PKI solution for an IOT platform and it was a lot easier than in any language we've used before. By a good margin. I think you inadvertently made the argument for using Go and its standard library :-) (Of course, 10 years down the road, perhaps people have abandoned Go and it has become a wasteland and there's some other language with a better stdlib you should be using. But ask yourself this: how much of the code you have written in the past is still running unchanged? You'll have to evolve, develop and adapt over time no matter what so if Go were to fade away, it isn't going to happen overnight and you'll have plenty of time to move on)
  - everforward 3y ago
    > I'd be tempted to think that if an application is designed in a way where switching your TLS implementation has consequences for the concurrency model, you have some serious design challenges. I think you're misunderstanding OP's theoretical. If TLS is in the stdlib, that means its version is tied to the version of the language you're using. I.e. if you want to upgrade to a newer TLS, you need to upgrade your entire language version (compiler, interpreter, whatever). So you can end up in a spot where you need to go from v1 of a language to v2 to get a modern TLS implementation. However if v2 of the language also contains changes to how the language handles threading, you now need to rewrite your app's threading to be compatible with v2 of the language, just so you can get a safe TLS implementation. Basically because TLS is in the stdlib, TLS can force you to upgrade your language version. If TLS was 3rd party, you could upgrade the library without upgrading your language version (presuming the TLS library supports your language version).
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.