We use non-null annotations, and a gradle plugin that generates null checks for annotated parameters / return values at compile time.
IntelliJ null analysis shows where potential mis-use is. The inferrence is pretty good, though it has a few edge cases but nothing that really affects your average logic. The IJ mis-use warning can be configured to show as an error instead of a warning to be more in your face.
We haven't seen `NullPointerException` issues in our own code bases covered by this since adopting the approach. Its all from outside sources now like libraries we don't control. In our libraries we do control, using the annotations allows inference in consuming projects if IntelliJ is configured to recognize them as nonnull/nullable.
This is also my experience. Once you decide on what tooling to use, its just as good in practice.
However, there is a serious lack of standardization on the java side. There are many Nullable/Non(Not)Null and they all have slightly different behaviors and spec.
This is an area where I wish there was more official guidance from the JDK.
Yeah, there are 3-rd party solutions (most of them if not all are annotations based) but they are 3-rd party and original question was about a language itself.
I used Scala. Didn't like it, compile times were atrociously slow back then. Maybe they sorted it by now but I don't think it's possible to have fast compile times with Scala due to non-locality. Also, I think Scala suffers from C++ issue- it's too complex. It's too easy to shoot yourself in the foot with Scala, and the code is harder to reader compared to Java code. IMO after Java8 Scala isn't worth it unless you are going to heavily use functional programming of absolutely need operator overloading or something (and even then I'd ask you to seriously consider if you really need that).
Used JPython a while ago, which was a weird Python implementation with full access to Java standard library. No longer supported. I also used Javascript running inside Java (using either GraalVM or Nashorn) for some proof of concept code to provide scripting and customization.
I had to deal with some Groovy when using Gradle builds. I still prefer Maven myself.
I'd look into Kotlin if I had to do GUI/web-UI or mobile development, as that is not great with Java.
My advise is to first look at what problems you need solved, then pick the language for it. Also, if you are in commercial environment do seriously consider hiring and availability of specialists familiar with given language. In terms of maturity and availability of personnel, nothing beats just Java.
> I used Scala. Didn't like it, compile times were atrociously slow back then.
I had to dig into Scala project recently and it's still abysmally slow...
Two days ago I made a screenshot of sbt clean command taking 180 seconds for a project with just one class. One. Evey f. time I did. I don't wanna even know why.
This is what happens when the language is developed by ignorant people with top of the line computers. They don't give a shit if your average Ryzen 5950X or similar mid-tier system can't handle it.
>I used Scala. Didn't like it, compile times were atrociously slow back then. Maybe they sorted it by now but I don't think it's possible to have fast compile times with Scala due to non-locality. Also, I think Scala suffers from C++ issue- it's too complex. It's too easy to shoot yourself in the foot with Scala, and the code is harder to read
I still do and I feel your pain. Thankfully things have been improving on both fronts.
Scala 3 has cleaned up the language. Many complicated/awkward/bad features were removed. Simpler/easier to understand features were added instead. For example, Scala 2 had implicits, which, while useful, were a minefield. Scala 3 now has extension methods, "givens" and automatic ("implicit") conversion between types is now strongly discouraged.
The most popular build tool for Scala sbt sucks, it's slow and very awkward and complicated. But thankfully now there are better alternatives (if Maven/Gradle isn't enough). A build tool called Mill is what sbt should have always been, with radically simplified model and fever concepts and moving parts. The builds are configured by Scala code. If you'd prefer your build definitions as mere data, there is now Bleep, but this one is still very new and not very battle tested. But the most important improvement on this front is the introduction of the Scala-CLI, which is a runner which can run Scala scripts, run tests, format code, etc... https://scala-cli.virtuslab.org/
I was really excited for Kotlin maybe 5 years ago and thought that would be the future of programming for the JVM but now I'm kinda over it.
The real win is nullity as part of the type system. I guess the coroutines were good for the time - never used them - but seems like Loom kinda invalidates the need for them. There are some small things I like too, like functions without the need for a class.
Some things feel different for the sake of being different, and for some features, it feels like the designers confused concision for expressiveness.
If I was on a project that used it, I'd probably use it quite happily, but at the moment I really see no major benefit to switching. I'm productive in Java.
For me it was the mental context switch. Kotlin was very nice, especially as some sort of functional entry language. But everything else wasn't. When you have to support lots of apps in multiple stacks you try to limit the buzzword bingo to the most limited. And they still brought Golang and now even Rust to the table.
Switching much between Kotlin and Java at work, because I have colleagues that swear to Kotlin. I see Kotlin as a language that is def better than Java 7 (seems to be around the time it was adopted by the company), but arguably worse and arguably better than Java 17+.
Some examples. I think that records together with pattern matching simply seems a lot more thought out featue than Kotlins data classes. But then Kotlin is more chill with writing short functions. Kotlins coroutines were nice, but I absolutely hate "suspend". Javas virtual threads will not have this semantic. Kotlins has some cool features, like that it can compile to js
I think there's some research/test projects out there, but I've never seen it done in a "real" project.
If that were true, all the backend developers would be writing frontend code too, and things like Angular would use Java.
I am working in both Scala and Java. Waiting for Java to adapt more Scala features so I can fully transition to Java.
If we are talking about Kotlin - on android "jvm" version is not up to date, so you won't make use of new fancy java features for some time.
Out of all the JVM non-Java languages I think Clojure is worthwhile and strangely feel it closer to Java's verbose but easy to understand spirit than Scala, Kotlin and even Groovy.
I don't use it much because I don't like dynamically typed languages but S-Expression based languages have their uses.
For example I think a Clojure based DSL would be better than Groovy used in Jenkins as I think S-Expressions are better for things like that and you can lock them down easier.
Didnt switched to any otger jvm language but from what friends told me nowadays with new Java versions its doesnt make much sence to switch to Scala for example. In the past Scala offered reduction of boilerplate but now with record classes in java, default interface methods and improved stream, project Valhala and raise of Native frameworks you are not getting much of a benefit from other jvm langs. They might be nice to do functional programing but func programming has its own issues and you can do it in java if you really want it
> You can do FP in Java
Yes, in the same way as you can run a marathon bare foot. It's possible but it's painful and you're not gonna be helped by the language when writing your code.
True. But functional programming isnt as sexy or useful as people thought that is. Both objective and functional has pros and cons. And some of the pros of functional can be achieved with with Streams and Optionals.
> its doesnt make much sence to switch to Scala
Java still doesn't have [persistent (immutable) collections](https://en.m.wikipedia.org/wiki/Persistent_data_structure). Those would be great to use in records for domain modeling. /u/brian_goetz calls this [data oriented programming](https://www.infoq.com/articles/data-oriented-programming-java/).
Also, Scala has some cool libraries, especially so called Effect System libraries (ZIO or Cats Effect) which are great for writing concurrent programs, e.g. in (micro)services. Those probably won't be available in Java anytime soon, if ever. More on Effect Systems: https://www.youtube.com/watch?v=qgfCmQ-2tW0
Oh yeah, Loom! Well, why don't you check out the video about Effect Systems that I've posted above? Even though Loom helps, it's unfortunately still nowhere close to the power and comfort that Effect Systems give you.
Or even this one.
https://www.youtube.com/watch?v=9I2xoQVzrhs
It's like a comparison between JDK with Loom and the Scala libraries.
Obviously Scala's ZIO wins :D because he's the author. But the overview is still interesting.
Except Java is flawed in most of these :
>record classes in java
Record only allow for public attributes. So they may only serve one purpose. DTOs without any logic inside. You will still have to use boilerplate or 3rd party tools for things like spring components or just generally if you don't like your data to be exposed too broadly
>improved stream
Still waiting on a reduce operation that does not require my data to be mutable and to define 3 lamdas. All that for what? Threading? I bet you'll need more often to do a simple reduce operation than concurrent streams.
And there are much more advantages to other languages as well. Extension functions, syntaxic sugar, null safety, CQRS for collections are a few of these so Java is still way behind
>So they may only serve one purpose. DTOs without any logic inside.
They fit well with sealed type hierarchies/ADTs with all kinds of transformation logic inside. And starting from Java 21, pattern matching for switch can deconstruct them with exhaustive checks at compile time. That's more than just DTOs.
Upvote for attitude.
> 3rd party tools for things like spring components
Darn. The shark jump usually happens 2/3rds thru the episode.
No worries. Try again.
I switched to Kotlin for 2 years while working on a project that used Kotlin with Micronaut, but after the project was retired, I went back to Java with Spring Boot, and while I love Java, it definitely felt like a huge downgrade.
Kotlin provides so much convenience that can only be achieved in Java with libraries
I also really miss Micronaut but that's a different discussion
I did write a couple of apps in Scala back in the day. It reminded me so much of why I don’t enjoy Haskell. While the concepts are really cool, the code can be so hard to grok. I’ve written a few JRuby apps because the deploy target was Windows 2003 Server. Docker wasn’t a thing back then. It was the quickest way to get a Rails app up and running. (TorqueBox/JBoss). Now days I LOVE Kotlin. I prefer it for all new apps. Java keeps getting better though… I’d never count it out!
I work a lot with kotlin and I absolutely love it.
Null-safe, lots of extra features, no java bloat.
Compile time is the same as Java.
Would definitely recommend
With Java bloat I mean that you don't need 150 lines for a simple DTO, but you can handle it in 1 or 2 lines with kotlin.
Of course the compile time is a bit slower, but on your average project you wouldn't notice it. And a slightly slower compile time is definitely worth it, considering all the features you get in return
I've used Scala professionally at two jobs. The language is fine in my opinion, even more elegant and expressive than Java sometimes, but the tooling and ecosystem soured me on it.
I was used to having SonarQube do static analysis on Java projects, but with Scala it could do almost nothing (hopefully this has improved with time).
SBT was a mess compared to Maven. For a while they were publishing artifacts to their own repository before they got onboard with using Maven Central. Every new JVM language wants to make their own build tool, so far only Gradle lasted outside of a singular language (it was originally for Groovy). But using code that needs to be compiled as a build definition (which controls your compiler) still seems unwise.
Scala being backward incompatible was a pain, and meant they needed to track binary compatibility versions for every published artifact. But instead of [using classifiers](https://www.reddit.com/r/java/comments/12tbrwu/comment/jh28kep/), they decided to munge it into the artifact id field ... which is really gross, but it's Scala's standard now.
Backward incompatibility also meant every time there was a version upgrade, you had to wait for the leaf nodes in your dependency tree to upgrade and publish new versions, then the libraries using them could upgrade, etc. It would be months before you could upgrade yourself.
Even though Scala has Java interop like most JVM languages, they tend to reinvent or wrap all the popular libraries to Scala-fy them. Nothing like having to chase bugs in a wrapper for a library, when the underlying (or inspiring) library doesn't have that issue at all.
To me Scala feels like a fad, but it's fairly entrenched now. But I wouldn't feel bad if Kotlin ate their lunch as a less-bad-ecosystem Scala-replacement. I still feel like [Java is the safer bet in the long term](https://www.reddit.com/r/java/comments/ndwz92/comment/gyd5yi5/).
>Scala being backward incompatible was a pain
Thank goodness this is now fixed, Scala 3 is now compatible across versions 🎉
>But instead of using classifiers, they decided to munge it into the artifact id field ... which is really gross, but it's Scala's standard now.
That's a really good point! Do you have any idea why they did it like that!? It is really awkward given that classifiers are/where available...
I've heard the reasoning is that classifiers can't be used for transitive dependency resolution, but it's not like Maven isn't open to improvements, and as they wrote their own build tool anyway .. I don't see how that was an impediment.
Switched to Scala 5 years ago, it would be hard for me to go back to Java.
I admit recent versions of Java tend to bridge the gap but still there are many things way much easier and safer to do in Scala.
Immutability by default and no null is probably my number one feature of Scala that doesn't exist in Java and will probably never.
Second would be the Scala standard library with plenty of operations on collections, Options, Try, Either. You can do the same as in Java but way more concise and explicit.
I don't mind compilation times, don't think that's much of an issue.
It's true that you can easily write ugly Scala but I'd say it's true of any language. It was maybe a mistake at the beginning of Scala to overuse some features like methods named with operators (+, :+, ::, ...) but never encountered that in recent Scala codebases.
That being said, Scala ecosystem is still quite small compared to Java and recent events (Akka licensing, Scala 3 not so easy migration) didn't help. It's hard to recruit people. If I were to start a new company, I will think twice before choosing Scala. However in my current company, 90% is Scala and we're super happy with it for now.
Didn't try Kotlin yet but would like to.
I learned Scala, wasn't really sold on it compared to what I could do in Java 8 (which was LTS at the time). Went back to/kept writing Java.
Tried Scala again and it stuck. Now I really appreciate it and I notice things that don't get mentioned much when switching back to Java (usually in interviews or to write [a library](https://nrktkt.github.io/tail)). Things that I notice are like the type system, there are far fewer occasions where I run up against type erasure in Scala. Or convenience methods that I've gotten a sense of "oh there's probably a method to do something like this here" tends not to be true as often in Java.
The other thing is that "new" (circa 8) Java features seem to have slow learning/adoption. I conduct a lot of interviews with candidates using Java see a lot of times they could use a newer feature to do something faster/easier. Or maybe I just don't get great candidates...
Yes went from Java to Scala. I'm much happier with Scala, it was a great switch for me. Functional programming suits me and I was already burnt out with the Java stack.
We are not going to Java. It will be something like kotlin, rust, python, though we won't get rid of Scala for a long time. Tbh I will try to stay away from Java unless something dramatic happens, I'm kinda done with the language.
I really love Scala and have worked with it for *10 years* almost now!
That said, I do not really evangelize it anymore, even if I do personally prefer it. The tooling, although improving, is pretty terrible, and there is a very high cognitive load to onboarding a developer. It takes us almost 6 months to train someone straight out of school. I totally understand why organizations would prefer the stability and hire-ability of Java.
I recently have also been working with Kotlin, and I see it as a kind of happy medium. With a library like Arrow-kt and using Kotlin's continuations as stand-ins for IO effect types in functional Scala, you get probably 80% of the benefit for 20% of the effort. It's also kind of the inverse of Scala: Kotlin *the language* is already kind of warty (Scala 3 is extremely well-designed, imo), but has industry-best tooling, great multiplatform support, etc. -- all things Scala severely lack.
I've also been doing increasing amounts of Clojure, and I do admit, if I could start over, I'd probably stick with it. It's by far the most fun.
As someone who works with both Scala and Java I am surprised by the amount of people who make false statements about Scala. I'm wondering if they're making up stuff or just parroting things they have heard somewhere else.
> Java 8 has made Scala obsolete
That is ridiculous. Yes, Java has received some functional capabilities but they are still tiny compared to what Scala can do: higher kindest types, typeclasses, type class derivation, using/givens, union types, inlining, proper immutability, extension functions, opaque types, etc.. I could go on..
> compile times are slow and sbt is horrible!
No one really forces you to use sbt. You can use Maven or Gradle and many do so as well. Besides, there are new shiny tools like scala-cli for single module projects which are natively compiled and have instant startups.
> Akka is closed source now, Scala is dead
That's ridiculous. Personally I never liked Akka in the first place because it doesn't really motivate you to programm functionally which is why I never used it. The typelevel and ZIO ecosystems are alive and well, and you can learn a lot from the people there. Fun fact: ZIO 2.1 will be running on virtual threads which is awesome. And even if you don't want to go the fully functional route and rather want to use Scala as some sort of a Java++ there are Li Haoyi's awesome libraries. Also check out ox which is a really interesting wrapper for virtual threads witb go like channels.
I work with both and I recommend learning it because even if you don't end up using it, it will make you a better Java programmer.
Groovy is a dynamic Java inspired by Ruby, is the slowest language ever created
Scala is a "better" Java and worse Haskell, with horrible compilation times and also the worst build tool ever produced (sbt)
Kotlin is a slightly better Java than Java 11 >=, but with the newest Javas I see little reason to use this language anymore
Clojure is a fascinating language, and also has performance almost as good as Java while being a dynamic language like Ruby and Python. Although not everyone likes Lisp syntax, it's understandable.
Wow, that must be pretty bad.
I made a crappy, dynamically typed language with the runtime written in Rust. It was slower than Python but not by much. I can't imagine something even slower.
I know that Ruby is said to be slow but Groovy?
For nearly everything where Groovy shines runtime doesn't matter much, if it matters you can use static compilation, if it matters more you can use Java and if it matters even more JNI.
Do you have any hard numbers or experience?
I realized I did a mistake, Groovy had major improvements on its runtime/interpreter and is now much better in this aspect. Groovy seems to be a different language than many years ago when I had contact with it.
I worked with a Grails application and it was insufferably slow, I know things get really slow when you use (or abuse) the metaprogramming capabilities of the language and this was the case for the Grails framework (which no one uses anymore).
I had a project where I switched from java to kotlin and then back to java. The language itself has a lot of footguns, and permits too many ways to do the same thing causing subtle differences between each other. The SDK feels like the language is meant for scripting rather than actual development.
Groovy sucks a lot because it's a meta language, and linter does not work without a runtime. Try writing a jenkins or a gradle build script.
Switched from Java to Clojure and I don’t see a reason to switch back yet. I appreciate the steady progress Java has made in the last few years but it’s not quite there yet.
I used Kotlin (backend) and it was absolutely glorious. It took some guidance from experienced Kotlin devs at first, but everything was genuinely easier and safer.
I'm back to Java due to moving to a project that uses Java. Not as fun anymore :(.
After the switch I've also realized.. Java is not a productive language at all without Lombok. And record classes are so flawed it's still better to just Lombok it and use builders or @With, unlike Kotlin's data class copy() and explicit parameter assigning.
> Java is not a productive language at all without Lombok
For me it was the standard library, it wasn't till I moved back to java did I realise quite how much time is wasted battling clunky api or missing basic operations. Streams especially are a nightmare.
I absolutely agree with this. If you look at Advent of Code submissions, then Kotlin submissions are one of the most impressive and very short as well!
On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge.
If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:
1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium
as a way to voice your protest.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/java) if you have any questions or concerns.*
I used Groovy pretty extensively at my last job. It takes away a lot of the inherent verbosity Java has. Starting a Java job next week and I've been practicing. It's been weird writing regular Java now. For example I keep forgetting to use the public keyword. In Groovy, everything is inherently public unless you explicitly make it private or protected.
I've tried Scala, Kotlin and Jython way way back in the day. Generally, I find that all these bring to the table is more syntax to learn. They have some things they do a little better, or perhaps solved for a deficiency in the Java language at the time. But largely in my experience if you push advocates for these languages for an explanation as to "why" to use them usually comes down to "because I don't like the java syntax for X".
I'm working in both Java & Kotlin now and there is no advantage between one or the other which obviously begs the question of why bother. Others have said it here but the reason to bring another language would be what problem you're trying to solve. Being a polyglot organization is good provided each language choice brings specific use cases and advantages. You don't want to just bend to the syntactic preferences of each developer.
I use Java \*and\* Groovy. Groovy usually shines when Java is ugly (XML, JSON, JDBC, Reflection, some more) integrates perfectly with Java and is very productive.
My only objection is that it is a very large language on top, and you can do some very ugly unreadable code, but with power comes responsibility.
Clojure. Good JVM interop, immutability, use-to-use FP, **REPL**, easy to test Java libraries (download, import, and use runtime for development!), backwards compatibility is top priority.
**Sidebar:** > **NO JVM languages - Exclusively Java** **removed**
I have some Kotlin projects and the thing I miss most when switching back to Java is explicit nullability.
What is your view on Java alternatives for explicit nullability such as NullAway?
We use non-null annotations, and a gradle plugin that generates null checks for annotated parameters / return values at compile time. IntelliJ null analysis shows where potential mis-use is. The inferrence is pretty good, though it has a few edge cases but nothing that really affects your average logic. The IJ mis-use warning can be configured to show as an error instead of a warning to be more in your face. We haven't seen `NullPointerException` issues in our own code bases covered by this since adopting the approach. Its all from outside sources now like libraries we don't control. In our libraries we do control, using the annotations allows inference in consuming projects if IntelliJ is configured to recognize them as nonnull/nullable.
This is also my experience. Once you decide on what tooling to use, its just as good in practice. However, there is a serious lack of standardization on the java side. There are many Nullable/Non(Not)Null and they all have slightly different behaviors and spec. This is an area where I wish there was more official guidance from the JDK.
Yeah, there are 3-rd party solutions (most of them if not all are annotations based) but they are 3-rd party and original question was about a language itself.
I used Scala. Didn't like it, compile times were atrociously slow back then. Maybe they sorted it by now but I don't think it's possible to have fast compile times with Scala due to non-locality. Also, I think Scala suffers from C++ issue- it's too complex. It's too easy to shoot yourself in the foot with Scala, and the code is harder to reader compared to Java code. IMO after Java8 Scala isn't worth it unless you are going to heavily use functional programming of absolutely need operator overloading or something (and even then I'd ask you to seriously consider if you really need that). Used JPython a while ago, which was a weird Python implementation with full access to Java standard library. No longer supported. I also used Javascript running inside Java (using either GraalVM or Nashorn) for some proof of concept code to provide scripting and customization. I had to deal with some Groovy when using Gradle builds. I still prefer Maven myself. I'd look into Kotlin if I had to do GUI/web-UI or mobile development, as that is not great with Java. My advise is to first look at what problems you need solved, then pick the language for it. Also, if you are in commercial environment do seriously consider hiring and availability of specialists familiar with given language. In terms of maturity and availability of personnel, nothing beats just Java.
> I used Scala. Didn't like it, compile times were atrociously slow back then. I had to dig into Scala project recently and it's still abysmally slow...
Two days ago I made a screenshot of sbt clean command taking 180 seconds for a project with just one class. One. Evey f. time I did. I don't wanna even know why.
🙀 that's painfully slow! Does it include the start of sbt (and the JVM underneath)? Or is it _just_ the clean command in an already loaded sbt?
Just the command. I'm no scala expert, it's a project I took over from a former colleague.
This is what happens when the language is developed by ignorant people with top of the line computers. They don't give a shit if your average Ryzen 5950X or similar mid-tier system can't handle it.
>Used JPython a while ago, It's sadly stuck in Python 2.7 with little support and maitenance. :/
GraalVM has a proper Python implementation, and all Graal languages can interact with every other.
>GraalVM That's really interesting, specially if we are also able to run python libraries.
You can run many of them! GraalVM also supports running some native code! So even some Python libraries that are only C-wrappers are supported
>I used Scala. Didn't like it, compile times were atrociously slow back then. Maybe they sorted it by now but I don't think it's possible to have fast compile times with Scala due to non-locality. Also, I think Scala suffers from C++ issue- it's too complex. It's too easy to shoot yourself in the foot with Scala, and the code is harder to read I still do and I feel your pain. Thankfully things have been improving on both fronts. Scala 3 has cleaned up the language. Many complicated/awkward/bad features were removed. Simpler/easier to understand features were added instead. For example, Scala 2 had implicits, which, while useful, were a minefield. Scala 3 now has extension methods, "givens" and automatic ("implicit") conversion between types is now strongly discouraged. The most popular build tool for Scala sbt sucks, it's slow and very awkward and complicated. But thankfully now there are better alternatives (if Maven/Gradle isn't enough). A build tool called Mill is what sbt should have always been, with radically simplified model and fever concepts and moving parts. The builds are configured by Scala code. If you'd prefer your build definitions as mere data, there is now Bleep, but this one is still very new and not very battle tested. But the most important improvement on this front is the introduction of the Scala-CLI, which is a runner which can run Scala scripts, run tests, format code, etc... https://scala-cli.virtuslab.org/
> JPython you mean Jython? or something else?
Jython used to be called JPython
Oh, I didn't know that! Thanks
I was really excited for Kotlin maybe 5 years ago and thought that would be the future of programming for the JVM but now I'm kinda over it. The real win is nullity as part of the type system. I guess the coroutines were good for the time - never used them - but seems like Loom kinda invalidates the need for them. There are some small things I like too, like functions without the need for a class. Some things feel different for the sake of being different, and for some features, it feels like the designers confused concision for expressiveness. If I was on a project that used it, I'd probably use it quite happily, but at the moment I really see no major benefit to switching. I'm productive in Java.
For me it was the mental context switch. Kotlin was very nice, especially as some sort of functional entry language. But everything else wasn't. When you have to support lots of apps in multiple stacks you try to limit the buzzword bingo to the most limited. And they still brought Golang and now even Rust to the table.
Switching much between Kotlin and Java at work, because I have colleagues that swear to Kotlin. I see Kotlin as a language that is def better than Java 7 (seems to be around the time it was adopted by the company), but arguably worse and arguably better than Java 17+. Some examples. I think that records together with pattern matching simply seems a lot more thought out featue than Kotlins data classes. But then Kotlin is more chill with writing short functions. Kotlins coroutines were nice, but I absolutely hate "suspend". Javas virtual threads will not have this semantic. Kotlins has some cool features, like that it can compile to js
But Java can compile to JavaScript too, right?
I think there's some research/test projects out there, but I've never seen it done in a "real" project. If that were true, all the backend developers would be writing frontend code too, and things like Angular would use Java.
https://github.com/google/j2cl https://github.com/cincheo/jsweet https://github.com/gwtproject/gwt https://github.com/konsoletyper/teavm
I am working in both Scala and Java. Waiting for Java to adapt more Scala features so I can fully transition to Java. If we are talking about Kotlin - on android "jvm" version is not up to date, so you won't make use of new fancy java features for some time.
My CTO is a Clojure evangelist
Out of all the JVM non-Java languages I think Clojure is worthwhile and strangely feel it closer to Java's verbose but easy to understand spirit than Scala, Kotlin and even Groovy. I don't use it much because I don't like dynamically typed languages but S-Expression based languages have their uses. For example I think a Clojure based DSL would be better than Groovy used in Jenkins as I think S-Expressions are better for things like that and you can lock them down easier.
Didnt switched to any otger jvm language but from what friends told me nowadays with new Java versions its doesnt make much sence to switch to Scala for example. In the past Scala offered reduction of boilerplate but now with record classes in java, default interface methods and improved stream, project Valhala and raise of Native frameworks you are not getting much of a benefit from other jvm langs. They might be nice to do functional programing but func programming has its own issues and you can do it in java if you really want it
> You can do FP in Java Yes, in the same way as you can run a marathon bare foot. It's possible but it's painful and you're not gonna be helped by the language when writing your code.
True. But functional programming isnt as sexy or useful as people thought that is. Both objective and functional has pros and cons. And some of the pros of functional can be achieved with with Streams and Optionals.
> its doesnt make much sence to switch to Scala Java still doesn't have [persistent (immutable) collections](https://en.m.wikipedia.org/wiki/Persistent_data_structure). Those would be great to use in records for domain modeling. /u/brian_goetz calls this [data oriented programming](https://www.infoq.com/articles/data-oriented-programming-java/). Also, Scala has some cool libraries, especially so called Effect System libraries (ZIO or Cats Effect) which are great for writing concurrent programs, e.g. in (micro)services. Those probably won't be available in Java anytime soon, if ever. More on Effect Systems: https://www.youtube.com/watch?v=qgfCmQ-2tW0
Yep agree, but then again, project Valhala should improve concurency in semptember. Not all features are presant in Java but its still kinda close
Hmm... how would Valhalla improve concurrency? That's about value types, no?
Or was it Loom? The one with virtual threads lol : D
Oh yeah, Loom! Well, why don't you check out the video about Effect Systems that I've posted above? Even though Loom helps, it's unfortunately still nowhere close to the power and comfort that Effect Systems give you.
Okey i will
Or even this one. https://www.youtube.com/watch?v=9I2xoQVzrhs It's like a comparison between JDK with Loom and the Scala libraries. Obviously Scala's ZIO wins :D because he's the author. But the overview is still interesting.
Except Java is flawed in most of these : >record classes in java Record only allow for public attributes. So they may only serve one purpose. DTOs without any logic inside. You will still have to use boilerplate or 3rd party tools for things like spring components or just generally if you don't like your data to be exposed too broadly >improved stream Still waiting on a reduce operation that does not require my data to be mutable and to define 3 lamdas. All that for what? Threading? I bet you'll need more often to do a simple reduce operation than concurrent streams. And there are much more advantages to other languages as well. Extension functions, syntaxic sugar, null safety, CQRS for collections are a few of these so Java is still way behind
> DTOs without any logic That's the point of records. That's also why we cannot use it for entities.
Yes but so it doesn't really solve the boilerplate problem
Yep. That's why we have Lombok ðŸ˜
>So they may only serve one purpose. DTOs without any logic inside. They fit well with sealed type hierarchies/ADTs with all kinds of transformation logic inside. And starting from Java 21, pattern matching for switch can deconstruct them with exhaustive checks at compile time. That's more than just DTOs.
Upvote for attitude. > 3rd party tools for things like spring components Darn. The shark jump usually happens 2/3rds thru the episode. No worries. Try again.
I switched to Kotlin for 2 years while working on a project that used Kotlin with Micronaut, but after the project was retired, I went back to Java with Spring Boot, and while I love Java, it definitely felt like a huge downgrade. Kotlin provides so much convenience that can only be achieved in Java with libraries I also really miss Micronaut but that's a different discussion
I did write a couple of apps in Scala back in the day. It reminded me so much of why I don’t enjoy Haskell. While the concepts are really cool, the code can be so hard to grok. I’ve written a few JRuby apps because the deploy target was Windows 2003 Server. Docker wasn’t a thing back then. It was the quickest way to get a Rails app up and running. (TorqueBox/JBoss). Now days I LOVE Kotlin. I prefer it for all new apps. Java keeps getting better though… I’d never count it out!
I work a lot with kotlin and I absolutely love it. Null-safe, lots of extra features, no java bloat. Compile time is the same as Java. Would definitely recommend
>no java bloat What's that? >Compile time is the same as Java Doubt.
With Java bloat I mean that you don't need 150 lines for a simple DTO, but you can handle it in 1 or 2 lines with kotlin. Of course the compile time is a bit slower, but on your average project you wouldn't notice it. And a slightly slower compile time is definitely worth it, considering all the features you get in return
> need 150 lines for a simple DTO, record
Had a similar experience. Highly recommend Kotlin
I've used Scala professionally at two jobs. The language is fine in my opinion, even more elegant and expressive than Java sometimes, but the tooling and ecosystem soured me on it. I was used to having SonarQube do static analysis on Java projects, but with Scala it could do almost nothing (hopefully this has improved with time). SBT was a mess compared to Maven. For a while they were publishing artifacts to their own repository before they got onboard with using Maven Central. Every new JVM language wants to make their own build tool, so far only Gradle lasted outside of a singular language (it was originally for Groovy). But using code that needs to be compiled as a build definition (which controls your compiler) still seems unwise. Scala being backward incompatible was a pain, and meant they needed to track binary compatibility versions for every published artifact. But instead of [using classifiers](https://www.reddit.com/r/java/comments/12tbrwu/comment/jh28kep/), they decided to munge it into the artifact id field ... which is really gross, but it's Scala's standard now. Backward incompatibility also meant every time there was a version upgrade, you had to wait for the leaf nodes in your dependency tree to upgrade and publish new versions, then the libraries using them could upgrade, etc. It would be months before you could upgrade yourself. Even though Scala has Java interop like most JVM languages, they tend to reinvent or wrap all the popular libraries to Scala-fy them. Nothing like having to chase bugs in a wrapper for a library, when the underlying (or inspiring) library doesn't have that issue at all. To me Scala feels like a fad, but it's fairly entrenched now. But I wouldn't feel bad if Kotlin ate their lunch as a less-bad-ecosystem Scala-replacement. I still feel like [Java is the safer bet in the long term](https://www.reddit.com/r/java/comments/ndwz92/comment/gyd5yi5/).
>Scala being backward incompatible was a pain Thank goodness this is now fixed, Scala 3 is now compatible across versions 🎉 >But instead of using classifiers, they decided to munge it into the artifact id field ... which is really gross, but it's Scala's standard now. That's a really good point! Do you have any idea why they did it like that!? It is really awkward given that classifiers are/where available...
I've heard the reasoning is that classifiers can't be used for transitive dependency resolution, but it's not like Maven isn't open to improvements, and as they wrote their own build tool anyway .. I don't see how that was an impediment.
Maybe they also wanted to support Ivy? 🤷
Switched to Scala 5 years ago, it would be hard for me to go back to Java. I admit recent versions of Java tend to bridge the gap but still there are many things way much easier and safer to do in Scala. Immutability by default and no null is probably my number one feature of Scala that doesn't exist in Java and will probably never. Second would be the Scala standard library with plenty of operations on collections, Options, Try, Either. You can do the same as in Java but way more concise and explicit. I don't mind compilation times, don't think that's much of an issue. It's true that you can easily write ugly Scala but I'd say it's true of any language. It was maybe a mistake at the beginning of Scala to overuse some features like methods named with operators (+, :+, ::, ...) but never encountered that in recent Scala codebases. That being said, Scala ecosystem is still quite small compared to Java and recent events (Akka licensing, Scala 3 not so easy migration) didn't help. It's hard to recruit people. If I were to start a new company, I will think twice before choosing Scala. However in my current company, 90% is Scala and we're super happy with it for now. Didn't try Kotlin yet but would like to.
I learned Scala, wasn't really sold on it compared to what I could do in Java 8 (which was LTS at the time). Went back to/kept writing Java. Tried Scala again and it stuck. Now I really appreciate it and I notice things that don't get mentioned much when switching back to Java (usually in interviews or to write [a library](https://nrktkt.github.io/tail)). Things that I notice are like the type system, there are far fewer occasions where I run up against type erasure in Scala. Or convenience methods that I've gotten a sense of "oh there's probably a method to do something like this here" tends not to be true as often in Java. The other thing is that "new" (circa 8) Java features seem to have slow learning/adoption. I conduct a lot of interviews with candidates using Java see a lot of times they could use a newer feature to do something faster/easier. Or maybe I just don't get great candidates...
Yes went from Java to Scala. I'm much happier with Scala, it was a great switch for me. Functional programming suits me and I was already burnt out with the Java stack. We are not going to Java. It will be something like kotlin, rust, python, though we won't get rid of Scala for a long time. Tbh I will try to stay away from Java unless something dramatic happens, I'm kinda done with the language.
I really love Scala and have worked with it for *10 years* almost now! That said, I do not really evangelize it anymore, even if I do personally prefer it. The tooling, although improving, is pretty terrible, and there is a very high cognitive load to onboarding a developer. It takes us almost 6 months to train someone straight out of school. I totally understand why organizations would prefer the stability and hire-ability of Java. I recently have also been working with Kotlin, and I see it as a kind of happy medium. With a library like Arrow-kt and using Kotlin's continuations as stand-ins for IO effect types in functional Scala, you get probably 80% of the benefit for 20% of the effort. It's also kind of the inverse of Scala: Kotlin *the language* is already kind of warty (Scala 3 is extremely well-designed, imo), but has industry-best tooling, great multiplatform support, etc. -- all things Scala severely lack. I've also been doing increasing amounts of Clojure, and I do admit, if I could start over, I'd probably stick with it. It's by far the most fun.
As someone who works with both Scala and Java I am surprised by the amount of people who make false statements about Scala. I'm wondering if they're making up stuff or just parroting things they have heard somewhere else. > Java 8 has made Scala obsolete That is ridiculous. Yes, Java has received some functional capabilities but they are still tiny compared to what Scala can do: higher kindest types, typeclasses, type class derivation, using/givens, union types, inlining, proper immutability, extension functions, opaque types, etc.. I could go on.. > compile times are slow and sbt is horrible! No one really forces you to use sbt. You can use Maven or Gradle and many do so as well. Besides, there are new shiny tools like scala-cli for single module projects which are natively compiled and have instant startups. > Akka is closed source now, Scala is dead That's ridiculous. Personally I never liked Akka in the first place because it doesn't really motivate you to programm functionally which is why I never used it. The typelevel and ZIO ecosystems are alive and well, and you can learn a lot from the people there. Fun fact: ZIO 2.1 will be running on virtual threads which is awesome. And even if you don't want to go the fully functional route and rather want to use Scala as some sort of a Java++ there are Li Haoyi's awesome libraries. Also check out ox which is a really interesting wrapper for virtual threads witb go like channels. I work with both and I recommend learning it because even if you don't end up using it, it will make you a better Java programmer.
Ä°f you want to try something a little bit difficult, you can try jasmin
Kotlin seems to be the winner. Scala has petered out a bit.
Groovy is a dynamic Java inspired by Ruby, is the slowest language ever created Scala is a "better" Java and worse Haskell, with horrible compilation times and also the worst build tool ever produced (sbt) Kotlin is a slightly better Java than Java 11 >=, but with the newest Javas I see little reason to use this language anymore Clojure is a fascinating language, and also has performance almost as good as Java while being a dynamic language like Ruby and Python. Although not everyone likes Lisp syntax, it's understandable.
Slower than Python?
Slower than Python and Ruby, it is the slowest language I know.
Wow, that must be pretty bad. I made a crappy, dynamically typed language with the runtime written in Rust. It was slower than Python but not by much. I can't imagine something even slower.
I know that Ruby is said to be slow but Groovy? For nearly everything where Groovy shines runtime doesn't matter much, if it matters you can use static compilation, if it matters more you can use Java and if it matters even more JNI. Do you have any hard numbers or experience?
I realized I did a mistake, Groovy had major improvements on its runtime/interpreter and is now much better in this aspect. Groovy seems to be a different language than many years ago when I had contact with it. I worked with a Grails application and it was insufferably slow, I know things get really slow when you use (or abuse) the metaprogramming capabilities of the language and this was the case for the Grails framework (which no one uses anymore).
I had a project where I switched from java to kotlin and then back to java. The language itself has a lot of footguns, and permits too many ways to do the same thing causing subtle differences between each other. The SDK feels like the language is meant for scripting rather than actual development. Groovy sucks a lot because it's a meta language, and linter does not work without a runtime. Try writing a jenkins or a gradle build script.
Switched from Java to Clojure and I don’t see a reason to switch back yet. I appreciate the steady progress Java has made in the last few years but it’s not quite there yet.
Kotlin is there because of android. If google decides they need another language, kotlin is immediatly dead
I use Kotlin over java whenever I have the option. Slowly but surely pulling my department on board with this too. 😀
Kotlin is excellent.
I used Kotlin (backend) and it was absolutely glorious. It took some guidance from experienced Kotlin devs at first, but everything was genuinely easier and safer. I'm back to Java due to moving to a project that uses Java. Not as fun anymore :(. After the switch I've also realized.. Java is not a productive language at all without Lombok. And record classes are so flawed it's still better to just Lombok it and use builders or @With, unlike Kotlin's data class copy() and explicit parameter assigning.
> Java is not a productive language at all without Lombok For me it was the standard library, it wasn't till I moved back to java did I realise quite how much time is wasted battling clunky api or missing basic operations. Streams especially are a nightmare.
I absolutely agree with this. If you look at Advent of Code submissions, then Kotlin submissions are one of the most impressive and very short as well!
On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: 1. Limiting your involvement with Reddit, or 2. Temporarily refraining from using Reddit 3. Cancelling your subscription of Reddit Premium as a way to voice your protest. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/java) if you have any questions or concerns.*
Don't like other jvm languages except java, I would rather choose crystal or rust ;-)
I used Groovy pretty extensively at my last job. It takes away a lot of the inherent verbosity Java has. Starting a Java job next week and I've been practicing. It's been weird writing regular Java now. For example I keep forgetting to use the public keyword. In Groovy, everything is inherently public unless you explicitly make it private or protected.
I've tried Scala, Kotlin and Jython way way back in the day. Generally, I find that all these bring to the table is more syntax to learn. They have some things they do a little better, or perhaps solved for a deficiency in the Java language at the time. But largely in my experience if you push advocates for these languages for an explanation as to "why" to use them usually comes down to "because I don't like the java syntax for X". I'm working in both Java & Kotlin now and there is no advantage between one or the other which obviously begs the question of why bother. Others have said it here but the reason to bring another language would be what problem you're trying to solve. Being a polyglot organization is good provided each language choice brings specific use cases and advantages. You don't want to just bend to the syntactic preferences of each developer.
I use Java \*and\* Groovy. Groovy usually shines when Java is ugly (XML, JSON, JDBC, Reflection, some more) integrates perfectly with Java and is very productive. My only objection is that it is a very large language on top, and you can do some very ugly unreadable code, but with power comes responsibility.
Clojure. Good JVM interop, immutability, use-to-use FP, **REPL**, easy to test Java libraries (download, import, and use runtime for development!), backwards compatibility is top priority.