I’m a backend developper, working on medium to big Spring Boot apps. Two years ago, we introduced Kotlin in our code base with really good results on code quality.
With Java 17, the gap is narrowing between Kotlin and Java. Kotlin has still unique features that I love (extension methods for instance), but the big one is nullability. You can use @Nullable/@NotNull annotations in Java but I largely prefer having nullability backed in types with Kotlin. Some people say nullability is not a problem: with 30 developers of various quality, I can ensure it is a problem. I don’t see Java addressing nullability in a better way in the near future, so I’m going to stick with Kotlin.
Currently using SonarQube at the company where i work - since the scanning is async, the CI builds typically don't wait for it to be finished, otherwise the lead time for changes would grow (e.g. not one of those places where a server farm would run integration tests overnight either) and additional configuration would be necessary, for which there are no resources at the time.
> Only users who subscribe themselves will get notifications. With only one exception, there is no admin functionality to proactively subscribe another user. If you believe a user should be receiving notifications, then it's time to practice the gentle art of persuasion.
So everyone is also free to ignore the e-mails that they may or may not receive. This isn't made any easier by the default quality profiles being problematic to deal with, e.g. SonarQube asking you to add HTML tags which would break XHTML templating in certain frameworks, such as PrimeFaces, thus having to spend a lot of time marking stuff as false positives, since that actual check might be sometimes useful except for your particular circumstances, of which it is not aware.
So perhaps it's a good idea to indeed utilize a language or another integrated solution (versioned/shared IDE code style preferences are also pretty cool), since other solutions, although workable with a bit of effort, wouldn't necessarily thrive in all environments. Unless, of course, you want to find a different environment, but that's a slightly different discussion.
Well, that is what Kotlin is all about, putting another tooling on top of Java, forcing everyone to jump into InteliJ, adopting Kotlin idiomatic libraries wrapping Java ones, additional effort creating wrappers when Java code needs to call into those Kotlin modules, when things go wrong in Java libraries having to debug if the Kotlin to JVM byte translation messed up or it is really a library bug,...
Well the way things go in companies, by the time it all turns to turd original authors would have gone to other companies to create next generation software.
I work at place where these architects, devs wouldn't know how to go beyond SpringBoot 1.x and Java 1.8 but from up there they are introducing Kotlin thinking it would relieve us of all Java development woes.
> I work at place where these architects, devs wouldn't know how to go beyond SpringBoot 1.x and Java 1.8 but from up there they are introducing Kotlin thinking it would relieve us of all Java development woes.
I actually migrated a number of apps from Spring Boot 1.X to 2.X and also older Spring versions to newer ones, as well as a variety of apps from Java 8 to Java 11 (17 might be in the cards, but perhaps not anytime soon) - it was a total mess and a pretty nightmarish experience.
From what i can tell, all software, with every framework and every stack rots with time. I've actually written more about it (in an absurdist fashion) in my blog post "Never update anything": https://blog.kronis.dev/articles/never-update-anything
Other interesting writing that i've seen online in regards to this is "Green Vs. Brown Programming Languages": https://earthly.dev/blog/brown-green-language/ which posits that our enjoyment and sentiment towards languages depends on how old they are and also how many bad legacy projects need to be maintained in them.
> Well the way things go in companies, by the time it all turns to turd original authors would have gone to other companies to create next generation software.
Ergo, this actually seems like what most developers should optimize for on an individual level: you don't want to stick around for 5-10 years and see your project get corrupted into an ill maintained piece of trash due to ever changing requirements, new features needing to be tacked on but not enough effort being put into refactoring, testing or keeping up to date with dependency releases.
Instead, you might want to stay around long enough so that you can start to feel the consequences of your actions, learn from the experience as much as you can and move on to other interesting and new projects, which will also be nice to put on your CV due to "CV driven development" sometimes being almost a must (or having plenty of personal projects, or just being able to network well instead, which is not attainable for all).
Because of this, i'd advise most to avoid doing what i did - migrating legacy code isn't nearly as flashy as working with new tech would be like. It was also very painful and demotivational at times, especially when the code quality wasn't great to begin with, nor was the documentation.
It would be interesting to see qualitative surveys of new Java code that appears eg on Github that would give information about whether the real-world practice in Java is converging toward expressivity of higher level languages and reduced incidental complexity.
As someone who moved from Java to C# around 2013, I always felt that C# was close to Java but with less bad parts and more good parts. Looks like Java's now borrowing a lot of the nicer features which is good to see.
There are still so many nice exclusive features in C# that I definitely wouldn't want to go back to Java any time soon though (properties, powerful tuples, null coalescing, interpolated strings, ...).
I feel similarly - though I think it's more the case that Java considers things a lot longer and considers the implications before simply adding them.
Java needed string interpolation forever before _finally_ getting something. There are parts of C# that I think are going to look like a good idea at the time, but turned out not so great. Extension methods is one, and async/await is another. In fact, if Project Loom ever, finally, actually ships it'll make the whole c# code colouring thing look like the abomination that it is.
I actually like the code colouring. It is clear indication that the function is optimized for asynchronoty and that I need to take care how to properly integrate then to achieve the goal. Is the Async suffix stupid: yes. Is a clear indication needed: imho yes
With Java 17, the gap is narrowing between Kotlin and Java. Kotlin has still unique features that I love (extension methods for instance), but the big one is nullability. You can use @Nullable/@NotNull annotations in Java but I largely prefer having nullability backed in types with Kotlin. Some people say nullability is not a problem: with 30 developers of various quality, I can ensure it is a problem. I don’t see Java addressing nullability in a better way in the near future, so I’m going to stick with Kotlin.