8 ms·

Honest question: How often do people upgrade their production language? Me: once in a decade, maybe. I'm still perfectly happy (and productive) with C# 3.5, Ja

by euske 8y ago

Honest question: How often do people upgrade their production language? 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.

cdoxsey 8y ago
With Go: every release. Free performance improvements and backwards compatibility. It also doesn't require anything installed on the server, so it's just updating a ci script.
- bearhall 8y ago
  Same for us for Go. The releases have never caused any trouble and the performance improvements are nice to have. For us it’s just changing one base containers version. That being said we still use mostly Python 2 for our Python services.
  - jkaplowitz 8y ago
    If those Python services are going to last beyond 2020 and there's much risk of attackers probing for security vulnerabilities, I suggest you plan a transition to Python 3 during the remaining ~2-year support lifespan of Python 2. 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.
- eftychis 8y ago
  Go is kind of special, as it is new relatively and the initial implementation of every feature is usually the most basic possible. Thus, every new version there is space for a lot of improvements. What I mean: the garbage collector is/was for all intents and purposes Dijkstra's late 70s ('78) tricolor algorithm. 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-eliminate-rescan.md 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.
  - majewsky 8y ago
    > So Go is by no means state-of-the-art performance wise. Yet Go is blazingly fast compared to most other languages that are widely used for web server development (except, maybe, Java).
    - Recurecur 8y ago
      Well, that's a heavily caveated statement. 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...
peanutz454 8y ago
Imagine you are a software developer that sells a hospital management system built on Java. You need to prove your software is built on secure technology. So if you are using Java 11, and suppose it is known that there are no more security updates, you cannot claim security. 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.
- jamie_ca 8y ago
  > Imagine you are a software developer that sells a hospital management system built on Java Then you're probably earning enough to pay Oracle for continued support. 6mo is just the no-cost timeframe.
gwbas1c 8y ago
Not that I rush into using the newest C# language features... But C# > 3.5 has some great changes that are very easy to learn and worthwhile. The new string interpolation feature is so good I don't even allow old-style string.Formats in code reviews.
- int_19h 8y ago
  > The new string interpolation feature is so good I don't even allow old-style string.Formats in code reviews. 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.
mamcx 8y ago
I was burned, badly, when try to port a huge ERP from .NET 1.1 to 2.? (if I remember the numbers correctly). Other projects get the slowdon, but that was truly a nightmare. That my brain trauma make forget much of it. 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.
- orbitingpluto 8y ago
  That is bonkers that someone signed off on a huge project with .NET 1.1. Early .NET is so off. It feels like two teams of programmers at Microsoft weren't talking to each other but working on features for the same language.
  - mamcx 8y ago
    Back in the day, MS was the gospel in my country (Colombia). We take everything them say, expect programming in Visual C++.
MBCook 8y ago
Is a Java developer I’ve always been happy moving up as soon as possible, if I see a benefit. I was quite happy to move up to 1.5 for generics. Java eight was fantastic because you got streams and lambdas. Some of the updates in 10 and 11 will take bigger changes to the codebase to take advantage of. 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.
- tannhaeuser 8y ago
  More breakages are expected going forward, though. That's the whole idea of releasing early and oftenly (and having customers to pay for backward-compat). Note I'm not saying Oracle has no right to monetize Java, though it could be said what makes Java valuable is the (mostly OSS) ecosystem around it, rather than Java the language itself or the JVM. > 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.
  - ArloL 8y ago
    Actually I don't think there will be more breaking changes than there were in the past due to the new release cadence. Mark Reinhold gave a great talk about the values they try to follow when moving the platform forward: https://m.youtube.com/watch?v=HpbchS5kmio https://m.youtube.com/watch?v=HpbchS5kmio This applies to the new release cadence as well. But time will tell if they will achieve their goals.
shados 8y ago
In the JavaScript world people use those holiday chocolate calendar things to count the days until a new version of their favorite compiler will come out and can't sleep the night before because they want to be sure they can update at the very instant the release is dropped (and then proceed to complain that their favorite framework didn't update for the quirks of the new compiler in a timely manner). I wish I was completely joking.
- gear54rus 8y ago
  Yep, and that's why JS is moving and everyone else is biting the dust lol. 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)
  - no_wizard 8y ago
    Not to pick a fight but even with all the recent improvements I am of the opinion that it has a long way to go. There’s no explicit Abstract Base Classes, there are base objects you can’t transparently inherit from (Thinkging of promises here in particular. Why can’t I transparently override built in promises for customization? I know you can inherit from it but you can’t modify a parents constructor) and it lacks lazy class invocation (looking at you `new` keyword) 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.
    - gear54rus 8y ago
      That's a bit dangerous. There's good in both functional approach and type systems but I'd rather see them where they are - in TypeScript and lodash and have vanilla be as vanilla as possible. Time will tell, there's already been a case where things from framework were pulled into ES (coffeescript).
smudgymcscmudge 8y ago
I’m always an early adopter for new language features on personal projects. I love playing with new things. But I use boring, reliable technology when somebody is paying me for it. As much as I like playing with shiny new things, I’m not going to bet my professional reputation on them.
greglindahl 8y ago
I don't know about "people", but I know that the companies and organizations that I've worked for and with for stay reasonably close to the leading edge for security and feature reasons. 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.
facorreia 8y ago
My company runs its Scala apps on Java 8. That's the version officially recommended by the Scala project: > For most users, we still recommend using Java 8 for compiling (and running) Scala code. https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html https://docs.scala-lang.org/overviews/jdk-compatibility/over...
no_wizard 8y ago
We upgrade rolling release style all the time. New features can make us very productive and honestly I don’t regret the aggressive approach
IloveHN84 8y ago
Fast: from C++11 to C++14 to C++17 soon.. 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??)
- majewsky 8y ago
  > if you stay on old language versions, you're doomed soon or later (see the world moving to [...] Go 2) 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.
  - int_19h 8y ago
    It's not a "learned" thing. Go can pull it off, because it's much younger, and doesn't have so much accumulated cruft. Eventually they will - and then they would either have to make the decision to break compatibility in some future major release - or become the next Java in a sense that there are parts of the language and the library that are warts upon warts, that no new code will ever use, and that confuse new developers, but which are needed for old code to run.
on_and_off 8y ago
I work in kotlin, I update the language several times a year, with each new stable release.
TheAceOfHearts 8y ago
Multiple times a year. If your system is well designed it should be trivial to move between different versions. As languages evolve they tend to get faster and fix more bugs. Your tests should catch any bugs if the new version breaks anything. 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.
- MetalBuddha 8y ago
  > If your system is well designed it should be trivial to move between different versions. Not many systems are well designed.
sixothree 8y ago
3.5 does not support tls 1.2 hence our move
mnm1 8y ago
It's insane, a complete waste of time, and a sign that the software is turning to garbage, releasing major api breaking changes just for their own goals, but to meet the goals of the user. Same goes for frameworks to a lesser extent. If one can't point out any real advantage of upgrading to a major version other than the developers want you to, that's the sign of broken software that's about to be insecure because the developers can't stop or even slow down with it for it to be practical. At my current job, I've been working on a few apps for almost five years and they are all version one. It's almost impossible to keep up with all the upgrades and deprecated packages. The only way to justify it to the business is to point out that the only reason we need to upgrade is because the original developers have abandoned the software and therefore we cannot get security packages. The new versions for the most part, offer nothing new but demand days of research, upgrading, and testing. Ironically the language was the waist l easiest to upgrade in our case (php) because it's one of the few that values backwards compatibility and has sane major version upgrades. The frameworks ... Angular 1 is all I need to say and it just goes on from there. I wish the original developers had thought about this. Finding decent open source software to write apps that will live for more than a couple years is extremely difficult. If only we had some reputation system that rated developers and companies on long term support, that would help.
- arthurcolle 8y ago
  Part of the issue here is likely the pressure that dev teams feel to be outputting <italics>something</italics> rather than nothing at all. There definitely seems to be a huge overemphasis on quantity over quality.
  - mnm1 8y ago
    Yup. I'm convinced this is the reason 95% of updates exist today. If it ain't broke don't fix it has been totally forgotten and it shows in today's broken ass software.
    - gulperxcx 8y ago
      Lol, this cracked me up
oliwarner 8y ago
Successive versions of Python have some really great features that keep pulling me in. Pathlib for scripting, asyncio for concurrency, f-strings for everyone. Similar in Django. 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.
yoz-y 8y ago
Swift every year or so. C++ every 3 years.
TurboHaskal 8y ago
Our stack is quite "boring" in that regard. Common Lisp (SBCL), Free Pascal, Perl and Go. They all run the latest versions and we never had an issue upgrading these.
TheCoelacanth 8y ago
Not upgrading your language every time a stable version is released seems crazy to me. 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.

by euske 8y ago

cdoxsey 8y ago

With Go: every release. Free performance improvements and backwards compatibility. It also doesn't require anything installed on the server, so it's just updating a ci script.

bearhall 8y ago
Same for us for Go. The releases have never caused any trouble and the performance improvements are nice to have. For us it’s just changing one base containers version. That being said we still use mostly Python 2 for our Python services.
- jkaplowitz 8y ago
  If those Python services are going to last beyond 2020 and there's much risk of attackers probing for security vulnerabilities, I suggest you plan a transition to Python 3 during the remaining ~2-year support lifespan of Python 2. 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.
eftychis 8y ago
Go is kind of special, as it is new relatively and the initial implementation of every feature is usually the most basic possible. Thus, every new version there is space for a lot of improvements. What I mean: the garbage collector is/was for all intents and purposes Dijkstra's late 70s ('78) tricolor algorithm. 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-eliminate-rescan.md 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.
- majewsky 8y ago
  > So Go is by no means state-of-the-art performance wise. Yet Go is blazingly fast compared to most other languages that are widely used for web server development (except, maybe, Java).
  - Recurecur 8y ago
    Well, that's a heavily caveated statement. 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...

peanutz454 8y ago

Imagine you are a software developer that sells a hospital management system built on Java. You need to prove your software is built on secure technology. So if you are using Java 11, and suppose it is known that there are no more security updates, you cannot claim security. 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.

jamie_ca 8y ago
> Imagine you are a software developer that sells a hospital management system built on Java Then you're probably earning enough to pay Oracle for continued support. 6mo is just the no-cost timeframe.

gwbas1c 8y ago

Not that I rush into using the newest C# language features... But C# > 3.5 has some great changes that are very easy to learn and worthwhile. The new string interpolation feature is so good I don't even allow old-style string.Formats in code reviews.

int_19h 8y ago
> The new string interpolation feature is so good I don't even allow old-style string.Formats in code reviews. 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.

mamcx 8y ago

I was burned, badly, when try to port a huge ERP from .NET 1.1 to 2.? (if I remember the numbers correctly). Other projects get the slowdon, but that was truly a nightmare. That my brain trauma make forget much of it. 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.

orbitingpluto 8y ago
That is bonkers that someone signed off on a huge project with .NET 1.1. Early .NET is so off. It feels like two teams of programmers at Microsoft weren't talking to each other but working on features for the same language.
- mamcx 8y ago
  Back in the day, MS was the gospel in my country (Colombia). We take everything them say, expect programming in Visual C++.

MBCook 8y ago

Is a Java developer I’ve always been happy moving up as soon as possible, if I see a benefit. I was quite happy to move up to 1.5 for generics. Java eight was fantastic because you got streams and lambdas. Some of the updates in 10 and 11 will take bigger changes to the codebase to take advantage of. 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.

tannhaeuser 8y ago
More breakages are expected going forward, though. That's the whole idea of releasing early and oftenly (and having customers to pay for backward-compat). Note I'm not saying Oracle has no right to monetize Java, though it could be said what makes Java valuable is the (mostly OSS) ecosystem around it, rather than Java the language itself or the JVM. > 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.
- ArloL 8y ago
  Actually I don't think there will be more breaking changes than there were in the past due to the new release cadence. Mark Reinhold gave a great talk about the values they try to follow when moving the platform forward: https://m.youtube.com/watch?v=HpbchS5kmio https://m.youtube.com/watch?v=HpbchS5kmio This applies to the new release cadence as well. But time will tell if they will achieve their goals.

shados 8y ago

In the JavaScript world people use those holiday chocolate calendar things to count the days until a new version of their favorite compiler will come out and can't sleep the night before because they want to be sure they can update at the very instant the release is dropped (and then proceed to complain that their favorite framework didn't update for the quirks of the new compiler in a timely manner). I wish I was completely joking.

gear54rus 8y ago
Yep, and that's why JS is moving and everyone else is biting the dust lol. 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)
- no_wizard 8y ago
  Not to pick a fight but even with all the recent improvements I am of the opinion that it has a long way to go. There’s no explicit Abstract Base Classes, there are base objects you can’t transparently inherit from (Thinkging of promises here in particular. Why can’t I transparently override built in promises for customization? I know you can inherit from it but you can’t modify a parents constructor) and it lacks lazy class invocation (looking at you `new` keyword) 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.
  - gear54rus 8y ago
    That's a bit dangerous. There's good in both functional approach and type systems but I'd rather see them where they are - in TypeScript and lodash and have vanilla be as vanilla as possible. Time will tell, there's already been a case where things from framework were pulled into ES (coffeescript).

smudgymcscmudge 8y ago

I’m always an early adopter for new language features on personal projects. I love playing with new things. But I use boring, reliable technology when somebody is paying me for it. As much as I like playing with shiny new things, I’m not going to bet my professional reputation on them.

greglindahl 8y ago

I don't know about "people", but I know that the companies and organizations that I've worked for and with for stay reasonably close to the leading edge for security and feature reasons. 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.

facorreia 8y ago

My company runs its Scala apps on Java 8. That's the version officially recommended by the Scala project: > For most users, we still recommend using Java 8 for compiling (and running) Scala code. https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html https://docs.scala-lang.org/overviews/jdk-compatibility/over...

no_wizard 8y ago

We upgrade rolling release style all the time. New features can make us very productive and honestly I don’t regret the aggressive approach

IloveHN84 8y ago

Fast: from C++11 to C++14 to C++17 soon.. 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??)

majewsky 8y ago
> if you stay on old language versions, you're doomed soon or later (see the world moving to [...] Go 2) 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.
- int_19h 8y ago
  It's not a "learned" thing. Go can pull it off, because it's much younger, and doesn't have so much accumulated cruft. Eventually they will - and then they would either have to make the decision to break compatibility in some future major release - or become the next Java in a sense that there are parts of the language and the library that are warts upon warts, that no new code will ever use, and that confuse new developers, but which are needed for old code to run.

on_and_off 8y ago

I work in kotlin, I update the language several times a year, with each new stable release.

TheAceOfHearts 8y ago

Multiple times a year. If your system is well designed it should be trivial to move between different versions. As languages evolve they tend to get faster and fix more bugs. Your tests should catch any bugs if the new version breaks anything. 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.

MetalBuddha 8y ago
> If your system is well designed it should be trivial to move between different versions. Not many systems are well designed.

sixothree 8y ago

3.5 does not support tls 1.2 hence our move

mnm1 8y ago

It's insane, a complete waste of time, and a sign that the software is turning to garbage, releasing major api breaking changes just for their own goals, but to meet the goals of the user. Same goes for frameworks to a lesser extent. If one can't point out any real advantage of upgrading to a major version other than the developers want you to, that's the sign of broken software that's about to be insecure because the developers can't stop or even slow down with it for it to be practical. At my current job, I've been working on a few apps for almost five years and they are all version one. It's almost impossible to keep up with all the upgrades and deprecated packages. The only way to justify it to the business is to point out that the only reason we need to upgrade is because the original developers have abandoned the software and therefore we cannot get security packages. The new versions for the most part, offer nothing new but demand days of research, upgrading, and testing. Ironically the language was the waist l easiest to upgrade in our case (php) because it's one of the few that values backwards compatibility and has sane major version upgrades. The frameworks ... Angular 1 is all I need to say and it just goes on from there. I wish the original developers had thought about this. Finding decent open source software to write apps that will live for more than a couple years is extremely difficult. If only we had some reputation system that rated developers and companies on long term support, that would help.

arthurcolle 8y ago
Part of the issue here is likely the pressure that dev teams feel to be outputting <italics>something</italics> rather than nothing at all. There definitely seems to be a huge overemphasis on quantity over quality.
- mnm1 8y ago
  Yup. I'm convinced this is the reason 95% of updates exist today. If it ain't broke don't fix it has been totally forgotten and it shows in today's broken ass software.
  - gulperxcx 8y ago
    Lol, this cracked me up

oliwarner 8y ago

Successive versions of Python have some really great features that keep pulling me in. Pathlib for scripting, asyncio for concurrency, f-strings for everyone. Similar in Django. 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.

yoz-y 8y ago

Swift every year or so. C++ every 3 years.

TurboHaskal 8y ago

Our stack is quite "boring" in that regard. Common Lisp (SBCL), Free Pascal, Perl and Go. They all run the latest versions and we never had an issue upgrading these.

TheCoelacanth 8y ago

Not upgrading your language every time a stable version is released seems crazy to me. 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.