I wish I was completely joking.
Progress needs to be made and those who can't follow don't have the right to complain really. Old tools are always available because language compatibility is preserved (which, imo should also be dropped, we would have much better language as a result).
We also stick to LTS (in my case node LTS)
Honestly I wish the ECMAScript board would have just went he other way and doubled down in making JS a function language instead of trying to push more OOP approaches would have been a lot better. It’s always been a little wonky as a Prototype based OO language anyway.
If you mean going into a functional paradigm I’d say it’s definitely a matter if taste.
However my biggest gripe is that the ECMAScript board seems intent on being all things to all people. So they half implemented classes. And they added some neat data types. But god for bid you want to override their constructors yet if I make a class I can override my constructors as one would expect in a class based language. Though forcing the new keyword onto classes wasn’t a great paradigm to keep imo. Nor do I like how static methods and properties are treated.
Also decorators are only for classes? Why does that make any sense?
It’s really screwy.
At least going the opposite direction would’ve forced correctness on a baseline.
If they want to be an OOP langsuge with classes the Standards need to embrace it more fully and I see little evidence of that
The reason that's critically concerning for the language and its ecosystem is that since 'vanilla JS' has no opinion, all the libraries created for it tend to have to form their own opinion. This then means that when binding to many ES libraries, you're torn between a hundred flavors of functional, half-baked OO, procedural, or just bit buckets of inconsistency.
If the language can't make up its mind, you're guaranteed to see fragmentation by its users.
The generally thought is that you technically only need them for classes (and really, only for class members and properties). For anything else you can just use a higher order function. Not as pretty, but JS decorator arent about syntax sugar, they're about filling one of the bazillion gaps in the language that opens when you introduce a class keyword.
Of course, the spec for decorator has been thrown away and started over once already (so basically no one using typescript/angular/mobx/whatever with decorators are actually spec compliant these days), and the new spec has been in limbo for years. Decorators aren't part of JS at all right now.
I think that Go and ECMAScript has shown that language compatibility is critical. The language changes that really improve quality of life change the way that you write code in that language, which mean you have to rewrite your existing code to opt-in to them. Small languages changes may not actually be worth the cost of adoption.
This just creates two different languages. The older language only dies when everyone stops using it. The Ruby community managed to do that with 1.9 but Python 2 still exists alongside Python 3.
If you have performance concerns you can update a single server and see how it performs relative to the others. Once you're comfortable that everything is working well you can gradually migrate more servers until everything is running the new version.
Each service should have its language version pinned instead of relying on a single global version. That way you can upgrade projects incrementally.
If you're really worried you can keep both versions of the language installed at the same time so you can quickly revert in case something goes wrong.
Not many systems are well designed.
But even if you weren’t using the new features, there was basically no downside to upgrading the run time. The newer version is usually ran much better thanks to improvements in threading or garbage collection. And you knew you’d get security patches, even if you ended up getting stuck on that version for a while.
As you said, libraries and frameworks can be a big issue to upgrade.
But the backwards compatibility promises of Java have been so incredibly strong it hasn’t been an issue.
The one time breakage in Java 9 is basically the first I’ve experienced in my career.
> As a Java developer, ...
I've been developing Java for a living since almost the beginning (since 1997), but I'd seriously recommend not tying yourself to a particular language as in "Java developer". Java is but a tool among others, and I generally can work better with devs that know more than just Java, for the pragmatism and utilitarism they bring, rather than Java devs dogmatizing and bragging about the latest fad in Java idioms and libs.
This applies to the new release cadence as well. But time will tell if they will achieve their goals.
They eliminated re-scanning of the stack on Go 1.7 by adding a hybrid write barrier which is 90's work (found the proposal: https://github.com/golang/proposal/blob/master/design/17503-...). So Go is by no means state-of-the-art performance wise. That is not bad and has its benefits, one of them being that you can improve with every release.
Yet Go is blazingly fast compared to most other languages that are widely used for web server development (except, maybe, Java).
It seems, given the end of Moore's "Law", as well as environmental concerns, that language efficiency will get more attention. It'll be interesting to see if languages like Swift, Rust, and Julia can gain traction for web development.
I wonder how uptake has been for IBM Kitura so far...
That being said we still use mostly Python 2 for our Python services.
It's a lot easier of a transition than it used to be. Any other support replacement language would of course also work to keep you secure, but honestly might be more transition work.
If you're a low-value target running unimportant stuff on an airgapped machine, this might not matter.
String interpolation doesn't fully replace String.Format, because it does not provide a way to re-arrange where the placeholders go in the format string, which is important for localization.
After that, I move very very fast. I prefer to hit "small" pains in short-term that try to do a huge jump later.
This mean that as long as I'm coding in a project (I'm contractor and do freelancing) I upgrade to whatever stable version my tools trow at me ASAP. And even minor versions or sometimes betas.
Not only language(s) - I keep at the same time different codebases in different languages, one main active plus maintenance-, I try to move everything: OS, RDBMS, IDEs, Editors, Frameworks, Libraries, etc. I probably hit "upgrade" every few days per week!
ONLY after the project stabilize and I do a few changes per-year, I stop doing that. And if the project somehow accelerate again I try to port ASAP.
How crazy is this? If the ecosystem I'm doing is nuts (ie: js) very clearly this reckless behavior show that.. QUICKLY.
...and then I need to pay more attention to my depencencies (keep them small) and choses only stable stuff.
I hit breaking changes not as often. And when see something painfull then I pin versions and keep them for a while.
This mean that I move ASAP and stay current as much as possible. I slow down when enter production, and slow down/stop again when the customer(s) stop requesting work.
This demand to use logging and have some testing, fast deployment/rollback, automate backups and use source control, very soon in the project, but this is good things anyway. (and maybe have a few VM or dockerized stuff but not as many despite more than 20 years doing crazy).
So far, this have work great for me, and never get stuck for months in rewrites like in the past. I get use to rewrite fast, that compensate to the fact that I'm a slow developer.
You can do actual *italics* like this.> For most users, we still recommend using Java 8 for compiling (and running) Scala code.
https://docs.scala-lang.org/overviews/jdk-compatibility/over...
And if you have a reasonable testing environment, it's not rocket surgery to figure out how much of a problem a new version might be.
Eventually you are going to have to upgrade, and if you are 10 years behind it's going to be a huge, painful migration. If you upgrade every six months, each upgrade is easy and barely noticeable.
What you are doing seems to me like deciding not to change the oil in your car. You might save you a bit in the short term, but it could come back to hurt you in a big way.
I'm sure if I had to deploy anywhere else than a server I ultimately control, I'd be a lot more conservative, but until then, this stuff makes things fun.
What I understand from the article - Oracle is not supporting it Oracle 11 after 6 months, but other still will, so nothing to worry about.
Then you're probably earning enough to pay Oracle for continued support. 6mo is just the no-cost timeframe.
The problem is that if you stay on old language versions, you're doomed soon or later (see the world moving to Python 3.7, Java 11, C#7, Go 2,..).
If you consider then JavaScript, things are moving at speed of light. Today's framework might be ancient in a couple of months (React version??)
Go 2 is notable on that list because the Go developers have already promised that all Go 1 code will continue to compile and work with Go 2. It's not a 2.0, it's more like 1.15 or 1.20.
I guess they learned from the Python 2->3 transition.
New features can make us very productive and honestly I don’t regret the aggressive approach
Me: once in a decade, maybe. I'm still perfectly happy (and productive) with C# 3.5, Java 7 and Python 2. I'm grudgingly moving forward because the old toolchains are being deprecated now, but my codes aren't significantly improved because of a few fancy idioms available in a new language, and it barely affects the design decisions. Upgrading your library or framework can be more often, but I tend to still be fairly conservative. Upgrading your language for production twice a year sounds crazy to me.