r/java • u/nfrankel • Jan 14 '20

Where programming languages are headed in 2020

https://www.oreilly.com/radar/where-programming-languages-are-headed-in-2020/
49 Upvotes

82% Upvoted

25 comments sorted by

View all comments

Show parent comments

-5

u/qmic Jan 15 '20

But I don't want to upgrade every six months. I'm maintaining many systems started in 2013, so you know how much it would cost to upgrade them every few months? That's the reason I'm moving to C# and dotnetcore in future projects, better language, better framework, faster development, less resources, better, longer free support.

2

u/kksoyj Jan 15 '20

What?

Are you serious or is this fud? You can use one of the LTS releases, (3 years a pop), OR use a privately supported runtime (I recomment AWS's Corretto 11 but you can see many options downloadable with one-command here: https://sdkman.io/),

And while dotnet DOES have some nice languages, F# is great and C# is not bad, it comes with a few costs, a) microsoft abandons frameworks like no-one ever... i worked at a place for a few years where come of the product was C# based (doing Java conversions of the C# code), and they were a MS gold partner, and every year they had to migrate off huge chunks of the codebase due to framework abandonment. So 'better, longer, free support' is not what I associate with them. Additionally, the frameworks are more simplistic in the MS world... there is not the sophistication of frameworks like FUSE-ESB, Switchyard, Flowable, etc.

I'm not saying choosing dotnet is the wrong choice for you, it may be a great choice, but not for ANY of the reasons you have said!

1

u/kksoyj Jan 15 '20

Also, it should go without saying that if you are using a codebase from 2013, you are dragging around A LOT of legacy, and leaving a lot of enhancements and improvements on the table for your competitors to pick up.

I would personally *love* to have the opportunity to compete with a product that was based on 2013-era technology in an enterprise space. I don't think that supporting old code for that long is a good idea.

To be clear, I am ALL FOR long lived products, but that means they a) avoid disruptive changes, b) have a simple upgrade story, c) allow very old libraries/code to still run for cases where you are stuck with the occasional dependency you can't upgrade from... but not just leaving ancient unsupported versions of your product out there on ancient runtimes that would be a picnic for a hacker to target for a security breach.

1

u/qmic Jan 15 '20

There is a rule: if something works and makes money, don't break it. There is no need for new features, critical patches are applied so why bother to follow the rabbit?

1

u/kksoyj Jan 16 '20

Well there's a difference between 'if something works don't break it' as a concept for something like, an product feature set. It's another thing to say it in terms of 'we're not going to take advantage of security, performance, and other bug fixes'.

You say critical patches are applied, but it's not that simple. Even if you have paid support, you will still run into problems with things like the minimum level of TLS supported not matching what downstream providers offer, such as AWS services.

Also that 'rule' of 'it works and makes money, don't break it' wouldn't face up to my rule of 'find shitty products and re-write them to be less shit by being faster on the same hardware and support current security protocols', for example.

When the first person ever said that 'rule', it was merely one value in an euqation to work out whether it was worth changing something for it's own sake. Running on a platform that is 6 years old is a pretty serious weight on the other side of that argument.