4 ms·
I was involved in a Scala point version migration (2.x) migration a few years ago. I remember it being painful. Although I recall most of the pain was around
by derriz 10mo ago
I was involved in a Scala point version migration (2.x) migration a few years ago. I remember it being painful. Although I recall most of the pain was around having lots of dependencies and waiting for libraries to become available.
At the time Scala was on upswing because it had Spark as its killer app. It would have been a good time for the Scala maintainers to switch modes - from using Scala as a testbed for interesting programming-language theories and extensions to providing a usable platform as a general commercially usable programming language.
It missed the boat I feel. The window has passed (Spark moved to Python and Kotlin took over as the "modern" JVM language) and Scala is back to being an academic curiosity. But maybe the language curators never saw expanding mainstream usage as a goal.
- hylaride 10mo agoOutside of Android work, has Kotlin really taken over? My understanding is that Java added a lot of functional programming and that took a lot of wind out of Scala's sails (though Scala's poor tooling certainly never helped anything).
- esafak 10mo agoJava's new features are always going to be on paper. The ecosystem, with all its legacy code, is always going to be a decade behind. And if you are starting a new project, why would you pick Java over Kotlin?
- hylaride 10mo agoThat's kind of what I'm asking. I did have a former co-worker write a micro service in Kotlin around 2018. He said that as nice as the language is, the ecosystem was (at the time, not sure how it is today) so utterly dominated by Android development, that he said he wouldn't recommend using it again - half the time he was calling out Java anyways.
- esafak 10mo agoI use kotlin and I do not feel oppressed by Android in any way. And I'd rather call Java libraries from Kotlin than Java. Many have Kotlin wrappers.
- dtech 10mo agoThat's a weird take. Even if true, kotlin has perfect interop with calling Java libs so there's not really a downside to keep using Java libs. There's not that much demand for kotlin-specific libs outside multiplatform which includes Android. For what it's worth, Spring has first tier Kotlin support, I haven't noticed this bias.
- gavinray 10mo agoKotlins "ecosystem" is all of Java, and then all of Kotlin. Put another way: Java only has access to a subset of the ecosystem Almost all of the backend libraries I use are Java libs. Some of them have additional Kotlin extension libs that add syntax sugar for more idiomatic code.
- adrianN 10mo agoIt’s a lot cheaper to hire for Java than for „modern“ languages.
- blandflakes 10mo agoHave you ever heard the expression "you get what you pay for?"
- still_grokking 10mo agoPeople on HN down-voting facts? And yes, "you get what you pay for" is part of this.
- frje1400 10mo ago> And if you are starting a new project, why would you pick Java over Kotlin? Because in 5-10 years you'll have a Java project that people can still maintain as if it's any other Java project. If you pick Kotlin, that might at that point no longer be a popular language in whatever niche you are in. What used to be the cool Kotlin project is now seen as a burden. See: Groovy, Clojure, Scala. Of course, I recognize that not all projects work on these kinds of timelines, but many do, including most things that I work on.
- wrathofmonads 10mo agoClojure has never been a popular language, nor has it aimed to be mainstream. That is the Lisp curse. It has never positioned itself as a "better Java". It shines in applications where immutable, consistent, and queryable data is crucial, and it has found another niche in UIs through ClojureScript.
- fulafel 10mo agoI don't think Clojure belongs there. It was never as big as Kotlin, but it's got great community, longevity and takes backwards compatibility very seriously, and 10 year old Clojure projects seem to be aging at least as well as 10 year old Java projects.
- esafak 10mo agoKotlin has already been around for ~10 years and it's in the TIOBE top 20. https://www.tiobe.com/tiobe-index/kotlin/ https://www.tiobe.com/tiobe-index/kotlin/
- still_grokking 10mo agohttps://nindalf.com/posts/stop-citing-tiobe/ https://nindalf.com/posts/stop-citing-tiobe/ https://medium.com/@ankushroy7/tiobe-is-trash-why-it-gets-more-credit-than-it-deserves-what-to-use-instead-afccc415b978 https://medium.com/@ankushroy7/tiobe-is-trash-why-it-gets-mo... Tiobe bullshit unfolding looks like: https://news.ycombinator.com/item?id=24997496 https://news.ycombinator.com/item?id=24997496
- pjmlp 10mo agoBecause the Java Virtual Machine is designed for Java, and that is what all vendors care about. Kotlin is Google's C#, with Android being Google's .NET, after Google being sued by coming up with Google's J++, Android Java dialect. Since Google wasn't able to come up with a replacement themselves, Fuchsia/Dart lost the internal politics, they adopted the language of the JetBrains, thanks to internal JetBrains advocates.
- bhawks 10mo ago| Android being Google's .NET, after Google being sued by coming up with Google's J++, Android Java dialect. The Oracle v Google was specifically over copyright infringement concerning the Java APIs used in Android's original implementation (Dalvik/ART), not about creating a "J++" dialect. Android never ran a JVM on mobile because it cannot be optimized for resource constrained devices a solution like DalvikVM was necessary. If you want to level critiques about creating fragmented dialects of Java I would recommend starting with J2ME. The only nice thing I can say about J2ME is at least it died. The Android ecosystem was far too mature for Fuchsia/Dart to be successful without a very compelling interop story that was never produced. As a technology Kotlin met Android's platform and community needs. Advocacy and politicking played a minimal, if any, role.
- pjmlp 10mo agoLies sold by Google. Nokia and Sony Ericsson were using J2ME perfectly fine, as did Blackberry. I should know ad ex-Nokian. Kotlin met nothing, it was pushed by Kotlin heads working on Android Studio, telling lies comparing Kotlin to Java 7, instead of Java was already offering at the time. To this day they never do Kotlin vs Java samples, where modern Java is used, rather the version that bests fits their purpose to sell why Kotlin. Fragmentation, what a joke, the fragmentation got so bad in Android, that JetPack libraries, previously Android X, exist to work around the fragmentation and lack of OEM updates. Gosling said it better, regarding Google's "good" intentions https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be&t=57m42s https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
- 10mo ago
- spicybbq 10mo ago> And if you are starting a new project, why would you pick Java over Kotlin? I've written multiple production services in Kotlin Spring Boot. Now, we're building a new system and using Java 21 (25 soon). Why? Kotlin the language is great, but there are corresponding tradeoffs in interop. Meanwhile, Java the language has improved to the point that it's good enough, and Java feels like it's headed in the right direction. In my opinion, AI models are better at Java than Kotlin. If you prefer a weaker claim, the models are trained on more Java code than Kotlin code. Finally, from an enterprise perspective, it is a safer long-term investment for a Java shop to own an application written in Java rather than in Kotlin.
- vips7L 10mo agoThe ecosystem is perfectly fine. You’re more than likely using the ecosystem when you choose Kotlin, that’s the whole point. This comment doesn’t make any sense.
- aarroyoc 10mo agoAt least where I work, writing new Java code is discouraged and you should instead use Kotlin for backend services. Spring Boot which is the framework we use, supports Kotlin just fine, at the same level as Java. And if you use Jetbrains tools, Kotlin tooling is also pretty good (outside Jetbrains I will admit it is worse than Java). Now, even in new Java projects you can still be using Kotlin because it is the default language for Gradle (previously it was Groovy).
- dtech 10mo agoSort of true, but I often hear this take from Java programmers and it feels like "Blub" [1]/Stockholm syndrome to me. Personally, I'm extremely glad to not have had to write .toStream().map(...).collect(Collectors.list()) or whatever in years for what could be a map. Similar with async code and exception handling. For me one of the main advantages of Kotlin is that is decreases verbosity so much that the interesting business logic is actually much easier to follow. Even if you disregard all the things it has Java doesn't the syntax is just so much better. [1] https://paulgraham.com/avg.html https://paulgraham.com/avg.html
- wrathofmonads 10mo agoJava 16+ stream.map(...).toList() https://bugs.openjdk.org/browse/JDK-8180352 https://bugs.openjdk.org/browse/JDK-8180352
- lmm 10mo agoSo only 2 bullshit boilerplate calls instead of 3? I guess that's progress.
- mystifyingpoi 10mo ago> My understanding is that Java added a lot of functional programming This is true, but needs more context. Java 8 added Stream API, which (at this time) was a fantastic breath of fresh air. However, the whole thing felt overengineered at many points, aka - it made complex things possible (collector chaining is admittedly cool, parallel streams are useful for quick-and-dirty data processing), but simple everyday things cumbersome. I cannot emphasize how tiring it was to have to write this useless bolierplate customers.stream().map(c -> c.getName()).collect(Collectors.joining(", ")) for 1000th time, knowing that customers.map(c -> c.getName()).join(", ") is what users need 99.99999% of the time.
- bvrmn 10mo agoIt bothers me that majority of languages ignores a nice python approach. `', '.join(any_str_iterable)`. Instead of supporting join for myriads of containers there is a single str method.
- still_grokking 10mo agoPython's approach is one of the most confusing ways to possibly do it. Not having proper, discoverable methods is super annoying, and I need to look it up every time anew I use Python because it's so unintuitive. Of course you can write a generic version of `mkString` (as this method is called in Scala), so it's also just one method no matter the container count. The Python weirdness is actually a direct result from the language lacking generics…
- bvrmn 10mo agoFrom typing perspective there is no sense to have Container[T].join() -> str for any T.
- mystifyingpoi 10mo agoI agree, but from convenience perspective there is a lot of sense. Java Streams is actually a good example of a "correct" design, but not very convenient.
- gavinray 10mo agoMy org had to write a pivotal backend service on the JVM, due to JDBC having the largest number of data source adapters. The choice was Kotlin. Scala is too "powerful" and can be written in a style that is difficult for others, and Java too verbose. Kotlin is instantly familiar to modern TypeScript/Swift/Rust etc devs. The only negative in my mind has been IntelliJ being the only decent IDE, but even this has changed recently with Jetbrains releasing `kotlin-lsp` for VS Code https://github.com/Kotlin/kotlin-lsp https://github.com/Kotlin/kotlin-lsp
- kelnos 10mo agoJava did indeed add more FP to the language, but Java's type system is still fairly primitive compared to Scala's.
- pjmlp 10mo agoKotlin is an Android language, because Google says so, and they stiffle Java support on purpose (Java 17 LTS subset currently). Outside Android, I don't even care it exists. If I remember correctly, latest InfoQ survey had it about 10% market share of JVM projects.
- wrathofmonads 10mo agoKotlin hasn’t made much of an impact in server-side development on the JVM. I’m not sure where this perception comes from, but in my experience, it’s virtually nonexistent in the local job market.
- still_grokking 10mo agoScala is broadly used by the biggest companies in existence. https://business4s.org/scala-adoption-tracker/ https://business4s.org/scala-adoption-tracker/ The stuff currently cooking in Scala 3 will once more revolutionize the whole programming language landscape. https://softwaremill.com/understanding-capture-checking-in-scala/ https://softwaremill.com/understanding-capture-checking-in-s... https://www.youtube.com/watch?v=p-iWql7fVRg https://www.youtube.com/watch?v=p-iWql7fVRg