6 ms·

I am happy I changed job from DevOps so I don't have to deal with stuff like this breaking all the time for no good reason at all (on more computers than mine).

I am happy I changed job from DevOps so I don't have to deal with stuff like this breaking all the time for no good reason at all (on more computers than mine). Backwards compatibility is gold.

laumars 5y ago
‘go get’ is older than ‘pip’. The way Go packages are versioned and referenced has evolved massively since then. I get the need for backwards compatibility, I really do, but if you can’t modernise 11 year old tech then I think you’re on the road to much bigger problems. Edit: correction, Pip is older than Go. But for those downvoting me, the dates were just an illustration and don’t really matter to the point I’m making. That point being: after 11 years it should be safe to update a legacy interface.
- jcelerier 5y ago
  pip is older than go lol
  - laumars 5y ago
    Nope > Initial release: 4 April 2011 (10 years ago) Source: Wikipedia, pip (package manager).
    - forgetfulness 5y ago
      It was a rebranding of the 2008 pyinstall as the same Wikipedia article states in the first section. Like other things in Go, the antiquated feel is actually the pursuit of retro more than the product of age.
      - laumars 5y ago
        > It was a rebranding of the 2008 pyinstall as the same Wikipedia article states in the first section. Fair point. I’m on my phone so missed that section when scrolling through for the summary box. > Like other things in Go, the antiquated feel is actually the pursuit of retro more than the product of age. I’m really not sure the point you’re trying to make here but it feels like a baseless cheap shot rather than a constructive comment
    - jcelerier 5y ago
      wikipedia is wrong https://pypi.org/project/pip/0.2/ https://pypi.org/project/pip/0.2/ Released: Oct 28, 2008
  - deleted 5y ago
    [deleted]
- abryzak 5y ago
  According to [1], version 0.2 of pip was released 2008-10-29. The 1.0 release which added Python 3 support was 2011-04-04 (which is what Wikipedia lists). The earliest release I can find for Go at [2] is 2009-12-09, with 1.0 being released 2012-03-28. [1] https://pypi.org/project/pip/#history https://pypi.org/project/pip/#history [2] https://golang.org/doc/devel/weekly https://golang.org/doc/devel/weekly
- mfer 5y ago
  The new behavior could easily have been `go mod get`. There are many ways to design things to not break people. When it comes to the tools, the Go team isn't concerned with breaking people. Their docs even note that.
  - laumars 5y ago
    You’re missing the point because ‘go mod get’ would cause the same deprecation notice. The complaint isn’t what the new command looks like, it’s that the old one is being deprecated.
- cryvate1284 5y ago
  What's the relevance of it being older than `pip`?
  - laumars 5y ago
    It’s just an illustration to help conceptualise the point. Like when people talk about larger distances using comparisons like “lengths of a football field”. The purpose was just demonstrating that the tooling in question is as old as many of the other common tooling used in other languages, rather than some recent thing that’s prone to frequent changes.
    - laumars 5y ago
      Why is this being downvoted? It was literally just answering the asked question!
slver 5y ago
Platforms that are not willing to deprecate parts of themselves in order to spur innovation and keep complexity low, eventually get deprecated as a whole. Look at Java, the king of BC, even they've started deprecating packages in the JDK for removal. It's inevitable. Otherwise it's like a brain that can't forget even the most useless piece of information. About an organism that just eats, but can't expel the waste. There's a way to do change slowly, gradually and reasonably, but change is inevitable. If you don't want small changes, big changes will come for you.
- superkuh 5y ago
  No one is arguing for no change. The problems here are the new single corporation languages from this past decade that behave like 6 months is a long time. It isn't. Every ~4 years is more the cadence of everything before.
  - jodrellblank 5y ago
    HN person a few days ago: "It's pretty common that I have to deal with support issues that were fixed six months ago, but the client has never taken an update in all that time..." - https://news.ycombinator.com/item?id=27492147 https://news.ycombinator.com/item?id=27492147 I was surprised to see six months described as "never, in all that time".
- rightbyte 5y ago
  Ye I understand that, but from a DevOp or system admin perspective all these small things adds up. 6 months deprecation is way too short to first realize this is changing and then fix all the scripts - and most likely still keeping backwards compability with older Go versions in the scripts for projects stuck in older versions. The remedy in practice is pinning versions by project or even worse org. wide to be able to concentrate on the actual problem being solved if things are breaking too much.
  - icholy 5y ago
    No one is forcing you to update.

I am happy I changed job from DevOps so I don't have to deal with stuff like this breaking all the time for no good reason at all (on more computers than mine). Backwards compatibility is gold.

laumars 5y ago

‘go get’ is older than ‘pip’. The way Go packages are versioned and referenced has evolved massively since then. I get the need for backwards compatibility, I really do, but if you can’t modernise 11 year old tech then I think you’re on the road to much bigger problems. Edit: correction, Pip is older than Go. But for those downvoting me, the dates were just an illustration and don’t really matter to the point I’m making. That point being: after 11 years it should be safe to update a legacy interface.

jcelerier 5y ago
pip is older than go lol
- laumars 5y ago
  Nope > Initial release: 4 April 2011 (10 years ago) Source: Wikipedia, pip (package manager).
  - forgetfulness 5y ago
    It was a rebranding of the 2008 pyinstall as the same Wikipedia article states in the first section. Like other things in Go, the antiquated feel is actually the pursuit of retro more than the product of age.
    - laumars 5y ago
      > It was a rebranding of the 2008 pyinstall as the same Wikipedia article states in the first section. Fair point. I’m on my phone so missed that section when scrolling through for the summary box. > Like other things in Go, the antiquated feel is actually the pursuit of retro more than the product of age. I’m really not sure the point you’re trying to make here but it feels like a baseless cheap shot rather than a constructive comment
  - jcelerier 5y ago
    wikipedia is wrong https://pypi.org/project/pip/0.2/ https://pypi.org/project/pip/0.2/ Released: Oct 28, 2008
- deleted 5y ago
  [deleted]
abryzak 5y ago
According to [1], version 0.2 of pip was released 2008-10-29. The 1.0 release which added Python 3 support was 2011-04-04 (which is what Wikipedia lists). The earliest release I can find for Go at [2] is 2009-12-09, with 1.0 being released 2012-03-28. [1] https://pypi.org/project/pip/#history https://pypi.org/project/pip/#history [2] https://golang.org/doc/devel/weekly https://golang.org/doc/devel/weekly
mfer 5y ago
The new behavior could easily have been `go mod get`. There are many ways to design things to not break people. When it comes to the tools, the Go team isn't concerned with breaking people. Their docs even note that.
- laumars 5y ago
  You’re missing the point because ‘go mod get’ would cause the same deprecation notice. The complaint isn’t what the new command looks like, it’s that the old one is being deprecated.
cryvate1284 5y ago
What's the relevance of it being older than `pip`?
- laumars 5y ago
  It’s just an illustration to help conceptualise the point. Like when people talk about larger distances using comparisons like “lengths of a football field”. The purpose was just demonstrating that the tooling in question is as old as many of the other common tooling used in other languages, rather than some recent thing that’s prone to frequent changes.
  - laumars 5y ago
    Why is this being downvoted? It was literally just answering the asked question!

slver 5y ago

Platforms that are not willing to deprecate parts of themselves in order to spur innovation and keep complexity low, eventually get deprecated as a whole. Look at Java, the king of BC, even they've started deprecating packages in the JDK for removal. It's inevitable. Otherwise it's like a brain that can't forget even the most useless piece of information. About an organism that just eats, but can't expel the waste. There's a way to do change slowly, gradually and reasonably, but change is inevitable. If you don't want small changes, big changes will come for you.

superkuh 5y ago
No one is arguing for no change. The problems here are the new single corporation languages from this past decade that behave like 6 months is a long time. It isn't. Every ~4 years is more the cadence of everything before.
- jodrellblank 5y ago
  HN person a few days ago: "It's pretty common that I have to deal with support issues that were fixed six months ago, but the client has never taken an update in all that time..." - https://news.ycombinator.com/item?id=27492147 https://news.ycombinator.com/item?id=27492147 I was surprised to see six months described as "never, in all that time".
rightbyte 5y ago
Ye I understand that, but from a DevOp or system admin perspective all these small things adds up. 6 months deprecation is way too short to first realize this is changing and then fix all the scripts - and most likely still keeping backwards compability with older Go versions in the scripts for projects stuck in older versions. The remedy in practice is pinning versions by project or even worse org. wide to be able to concentrate on the actual problem being solved if things are breaking too much.
- icholy 5y ago
  No one is forcing you to update.