4 ms·

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

by 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.
cesarb 5y ago
> 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...
- kaba0 5y ago
  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.
- slver 5y ago
  Java 8 is not when they started doing that

by slver 5y ago

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.

cesarb 5y ago

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

kaba0 5y ago
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.
slver 5y ago
Java 8 is not when they started doing that