The "Kotlin cost" - from my perspective, is that I already pay Java developers. Why do I need them to go through the cognitive complexity of learning a new syntax, if we're just going to run it inside a JVM anyway?
That, and Graal looks really interesting, as soon as MS sort out SQL JDBC compatibility, though I know that's on their roadmap. I haven't a clue what native compilation would look like in Kotlin, and the benefits of native compile far outweigh the niceties that Kotlin may bring to the table... though, that's diverging from the topic a little... and Graal will likely force us to stay a little behind the JVM release cycle.
LTS - for us, at least - isn't about "can I run this in Production." It isn't even about the level of support offered. It's more about buying time to weigh up options when avoiding vendor lock-in situations.
For an example there, we still have a large number of projects that run in a very specific build of Java 8. At least one of them, for reasons I haven't yet fathomed, will happily compile in 9... but then it refuses to run. Even when you ask javac to give Java 8 compatible bytecode. Then, during the our future migration of that project, I need to worry about reflection API changes within the JVM over time, etc etc. Plus we have dependencies to worry about, like our Tomcat version and which Servlet API it's using, or can work with and not break other dependent projects...
Sometimes, it simply makes more sense for legacy projects to stick with an LTS. Then when that's approaching EOL, we can look at "is it more beneficial to just bin that project, and re-write it?" - which also opens options for "should we do this in Kotlin/dotnet/Java/JS/C++ etc and which of those options gives the best ROI? Which team has the skillset to do that before EOL? What new features of these languages do we want to benefit from?"
Equally, our build pipeline is really simple to switch between Java versions and see if a project works in a different version... but that's why, ultimately, the language & version is a decision based on what's best for the business, not what makes developers feel cozy & warm (there's better ways to make developers happy, rather than chasing the latest tech all the time).
I mean, I still read the JVM release notes and geek out about upcoming changes, and share those around the business...
Jepp, and as Java gets more features anyway, many things will get better. So personally we have not switched although I do from a developer perspective like what Kotlin has done, but from a broader view we have not swapped although some people want to, with the same reasoning as you have combined with the fact that Java is moving along rather fast now (and many of the small things can be fixed with frameworks/libs anyway).
Okey, I understand the premise with LTS for your sake then, thanks for clearifying.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The "Kotlin cost" - from my perspective, is that I already pay Java developers. Why do I need them to go through the cognitive complexity of learning a new syntax, if we're just going to run it inside a JVM anyway?
That, and Graal looks really interesting, as soon as MS sort out SQL JDBC compatibility, though I know that's on their roadmap. I haven't a clue what native compilation would look like in Kotlin, and the benefits of native compile far outweigh the niceties that Kotlin may bring to the table... though, that's diverging from the topic a little... and Graal will likely force us to stay a little behind the JVM release cycle.
LTS - for us, at least - isn't about "can I run this in Production." It isn't even about the level of support offered. It's more about buying time to weigh up options when avoiding vendor lock-in situations.
For an example there, we still have a large number of projects that run in a very specific build of Java 8. At least one of them, for reasons I haven't yet fathomed, will happily compile in 9... but then it refuses to run. Even when you ask javac to give Java 8 compatible bytecode. Then, during the our future migration of that project, I need to worry about reflection API changes within the JVM over time, etc etc. Plus we have dependencies to worry about, like our Tomcat version and which Servlet API it's using, or can work with and not break other dependent projects...
Sometimes, it simply makes more sense for legacy projects to stick with an LTS. Then when that's approaching EOL, we can look at "is it more beneficial to just bin that project, and re-write it?" - which also opens options for "should we do this in Kotlin/dotnet/Java/JS/C++ etc and which of those options gives the best ROI? Which team has the skillset to do that before EOL? What new features of these languages do we want to benefit from?"
Equally, our build pipeline is really simple to switch between Java versions and see if a project works in a different version... but that's why, ultimately, the language & version is a decision based on what's best for the business, not what makes developers feel cozy & warm (there's better ways to make developers happy, rather than chasing the latest tech all the time).
I mean, I still read the JVM release notes and geek out about upcoming changes, and share those around the business...
Jepp, and as Java gets more features anyway, many things will get better. So personally we have not switched although I do from a developer perspective like what Kotlin has done, but from a broader view we have not swapped although some people want to, with the same reasoning as you have combined with the fact that Java is moving along rather fast now (and many of the small things can be fixed with frameworks/libs anyway).
Okey, I understand the premise with LTS for your sake then, thanks for clearifying.