Hacker News Reader

Comment by rightbyte | Hacker News Reader

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.

View on HN

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.

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.

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

I was surprised to see six months described as "never, in all that time".

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.

No one is forcing you to update.

> Look at Java, the king of BC, even they've started deprecating packages in the JDK for removal.

There is a reason plenty of organizations are still on Java 8, which is the last major release before they started doing that...

They have only removed packages that was quite literally not used by anyone after being deprecated for years (deprecation doesn’t break compatibility).

The reason 8 is preferred for many is due to a) not understanding the new model b) depend on a dependency that does some shady things with JVM internals it should have never done in the first place, this did get “sealed” by the module system. Most of these deps actually have already migrated to 8+, and even if not, access to internals can still be allowed with a command line flag.

Java 8 is not when they started doing that

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

pip is older than go lol

Nope

> Initial release: 4 April 2011 (10 years ago)

Source: Wikipedia, pip (package manager).

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.

> 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

wikipedia is wrong

https://pypi.org/project/pip/0.2/

Released: Oct 28, 2008

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

[2] https://golang.org/doc/devel/weekly

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.

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.

What's the relevance of it being older than `pip`?

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.

Why is this being downvoted? It was literally just answering the asked question!

Reply on news.ycombinator.com