4 ms·

> 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

> 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.

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.