[HN Gopher] Java 21 VirtualThreads vs. Clojure Lazy Seqs
___________________________________________________________________
Java 21 VirtualThreads vs. Clojure Lazy Seqs
Author : grzm
Score : 151 points
Date : 2023-10-06 15:44 UTC (7 hours ago)
(HTM) web link (clojure.org)
(TXT) w3m dump (clojure.org)
| theanonymousone wrote:
| Still waiting for VS Code to support Java 21. Java is not the
| language to use without an IDE.
| [deleted]
| avodonosov wrote:
| What in the java language makes you think it is less suitable
| to be used without an IDE than other languages?
| jillesvangurp wrote:
| The fact that IDEs are just unusually smart specifically for
| that languages relative to relatively dumb editors like vs
| code, which lack most of the conveniences in the form of auto
| complete, a wide variety of refactorings, auto fixes, etc.
| Opting out of all that is not something a lot of people do.
| Botttom line, you are missing out on so many good tools by
| not using a proper IDE with Java that it's borderline
| negligent to opt out of that. It's negligent because you
| start opting into preventable issues (formatting, warnings,
| common bug patterns, dead code, etc.) and generally end up
| wasting a lot of time fixing things manually that you
| shouldn't have to deal with because your IDE should be doing
| those things. For example imports are not a thing I ever type
| manually. Not a thing. Most warnings are addressed with a
| simple alt+enter, which will typically suggest a usable fix.
| With and IDE you see those warnings and can act on them.
|
| Kotlin has the same advantage and is developed by Jetbrains
| who also develop intellij and of course know what they are
| doing on this front. Support for other languages in intellij
| is also nice but typically a lot more limited than the
| support for Java and Kotlin. E.g. pycharm is alright for
| python but not that much different from what you get in vs
| code. You get a handful of refactorings and that's about it.
| Dynamically typed languages are just a lot harder to support
| with proper tools. Too much uncertainty about what does what
| or even what types things are.
| lern_too_spel wrote:
| Class-level imports and lots of classes.
| paulddraper wrote:
| It's verbose to write and read.
|
| You need an assist for both.
| palata wrote:
| > You need an assist for both.
|
| I don't. Do you?
| collinvandyck76 wrote:
| Obviously GP think it's helpful? Just because you're in
| the minority that doesn't need IDE or LSP assist writing
| Java, I think that most people would argue that assist
| for Java is beneficial even if you personally don't need
| it and there's no sense in flexing about it.
|
| I personally always use IDE/LSP for Java, even though
| it's been many years since I've written it, because it
| helps me deliver business value faster.
| matsemann wrote:
| It used to be lots of boilerplate. Like
|
| MyClassType myClassType = new MyClassType()
|
| And then it was nice to use an IDE to help write some of
| that. Or generate java beans etc.
|
| But with that said, I don't think it's much you _need_ an IDE
| for, it 's more that java enables IDEs to do much more than
| it can for certain other languages.
| vips7L wrote:
| You haven't had to declare the type since Java 10.
| var myThing = new MyThing();
| matsemann wrote:
| Yup, hence "used to", but I could be clearer it's no
| longer an issue.
| palata wrote:
| That's a thing I don't get. Maybe I am doing something
| completely wrong, but the vast majority of my time as a
| developer, I am not typing code. I can afford 5s typing
| `MyClass myClass = new MyClass()`.
| vips7L wrote:
| Things take time. If you want you can contribute resources to
| the vs code plugin and the eclipse language server.
| matsemann wrote:
| I can't imagine doing Java in VS Code instead of Intellij. Is
| there something I'm missing out on?
| jcadam wrote:
| No idea. I use IntelliJ for Java/Kotlin and emacs for
| everything else (Clojure, Python, JS, etc). I still encounter
| the occasional lunatic who uses eclipse or netbeans.
|
| I know VSCode is the "standard" editor for front-end devs,
| and so I assume some of them are trying to keep their code
| editor when moving into backend work. I have to believe it's
| not as good - for a time I really, really tried to make emacs
| work for Java development, but it just.... doesn't :)
| bafe wrote:
| How's the Kotlin language server performance for you? When
| I last tried it was using up so much resources for the
| simplest Kotlin file. I gave up and moved to intelliJ
| (which incidentally offers plenty of refactoring features
| you don't get in vscode)
| mey wrote:
| Kotlin is horrible in every IDE other than
| IntelliJ/AndroidStudio and JetBrains has little
| motivation to fix that.
| Phelinofist wrote:
| At my job a lot of people hate on Eclipse, but honestly I
| find it quite nice. I use IntelliJ for my private projects
| and think both are on par.
| zmmmmm wrote:
| fellow eclipse die hard here ...
|
| It's definitely a very complex beast but once you do
| master that complexity it is such a power tool. Even
| though I routinely do work in IntelliJ I miss various
| things enough from Eclipse that I always go back.
|
| I just wish it had proper Kotlin support.
| theanonymousone wrote:
| The reason I use VSCode is Code Server[0]. It is certainly
| not as powerful as IntelliJ, but the I have to get used to
| it because the web-based IDE is a must for me.
|
| By the way, unless my English is terribly bad, calling
| someone lunatic for their choice of IDE may not be a great
| idea.
|
| [0] https://github.com/coder/code-server
| ilikehurdles wrote:
| Lunatic meaning maniac or fool.
| jcadam wrote:
| I was being facetious, of course :)
| specialist wrote:
| Though I prefer IntelliJ, VS Code is fine.
|
| I sometimes switch to VS Code just to use Lischke's terrific
| ANTLR plugin.
|
| https://marketplace.visualstudio.com/items?itemName=mike-
| lis...
| jgon wrote:
| Brian Goetz just gave a talk about all the stuff that's been
| delivered up to Java 21 that announced they'd be rolling out a
| fully supported VS Code plugin for Java that should be better
| than the current language support. It should be out within the
| next week or two.
|
| Timestamp for the announcement:
| https://youtu.be/eXCx2hW_xNI?t=1955
| mike_hearn wrote:
| The Clojure devs should be aware that the synchronization pinning
| problem is intended to be temporary and doesn't apply at all with
| GraalVM native images. One of the Loom developers talks about it
| here:
|
| https://mail.openjdk.org/pipermail/loom-dev/2023-September/0...
|
| So they could also just choose to ignore this problem for now.
| [deleted]
| puredanger wrote:
| We are aware, and that is one of the options. :)
| puredanger wrote:
| The other thing I didn't mention is that the change to remove
| biased locking a while back has also had an impact in some
| places that do almost always uncontended locking, so we're
| kind of considering that too.
| fnordsensei wrote:
| A lot of Clojure projects choose to stick with the LTS releases
| though, so it might take a while before this problem disappears
| on its own, even if fixed in the JVM.
| vips7L wrote:
| As pron always says.. that's a risk of staying on an LTS
| release. You're choosing to not receive updates.
| geodel wrote:
| It seems to me by design or by indifference Java is now
| tired of JVM ecosystem languages at large who claim
| innovation by surface level changes while relying heavily
| on JVM bedrock.
|
| Now Java is moving fast and they are taking JVM compiler,
| runtime, class metadata etc along where _Java, the
| language_ is headed.
| Tainnor wrote:
| And many developers are tired of Java making minuscule
| improvements to developer ergonomics while pretending to
| be progressing, when even now, it doesn't have features
| that other languages have had for 30 years.
| kaba0 wrote:
| Based on pure statists about the number of important,
| business critical java-applications that run most of the
| internet, it seems like it just straight doesn't matter
| in any significant way.
| Tainnor wrote:
| Maybe it doesn't matter to you, but it does matter to me.
|
| All the power to people who enjoy working in Java, but
| that doesn't have to make me like it.
| pjmlp wrote:
| Not only Java, that is the fate of all guest languages,
| as they don't evolve alongside the platform, always
| require additional tooling and most language cultures
| than start making their own little islands of idiomatic
| libraries instead of directly using platform libraries.
|
| Since most platforms are leaky, one ends up needing to
| master two ecosystem in parallel, eventually it gets
| tiring and always cost extra in development.
|
| C++, Objective-C and Typescript get around this problem
| in UNIX and Web, as they are extensions of the platform
| languages, not something completely different.
| geodel wrote:
| Yep agree with all you said. Nowadays _new job every
| year_ people at work are scaring me with their enthusiasm
| to replace decades old solid Java applications which are
| performant and working fine with Kotlin and what not.
| Alupis wrote:
| I wouldn't advocate for replacing/re-writing old stuff -
| but you _should_ try out Kotlin for backend work. It 's
| amazing.
|
| Java programmers will have only a small learning curve
| before feeling productive, and can gradually get more
| comfortable with idomatic Kotlin as they progress through
| their journey.
|
| Kotlin, as a language, was very well through out, letting
| you use as much or as little of it as you are comfortable
| with.
| vips7L wrote:
| For me personally Kotlin does not bring that much to the
| table over a modern version of Java. Sure if you're stuck
| in Java 8 it can be a win, but compared to Java 21 it
| just doesn't bring enough to warrant the switch for me.
| skwirl wrote:
| I've seen this sentiment a lot and I don't understand it.
| I actually feel like very little has been added between
| Java 8 and Java 21. Virtual threads is probably the
| biggest thing, and it looks very promising, but the
| language itself is still a chore to use, and Kotlin does
| a good job at cleaning a lot of that up.
|
| I think Kotlin is at risk, though, of having the JVM
| force them to support two competing models to accomplish
| the same thing - coroutines and virtual threads is a good
| example (although Java still doesn't have language level
| structured concurrency). This could really make things
| messy.
| vips7L wrote:
| > I've seen this sentiment a lot and I don't understand
| it.
|
| I just don't think any feature of the language of Kotlin
| is that much better than Java's implementation. I'm also
| a big supporter of brevity != clarity when it comes to
| code.
|
| What language feature in Kotlin do you think is that much
| better?
| Alupis wrote:
| I was you not that long ago. I've had the same
| conversation with a lot of other Java developers too -
| they/we always say the same things.
|
| It's weird being on the other side of the fence now -
| hearing the same things I used to say.
|
| Kotlin was a gateway drug out of not just Java, but
| OO/Solid and into FP for me (FP being another thing I
| used to not "get"). The beauty of Kotlin is you don't
| have to ever write FP code if you don't want to - but you
| will want to before too long.
|
| I would recommend trying it out for yourself. It's Spring
| integration is amazing, and you'll have a great time.
| Write even a little Kotlin and you'll have an "ah ha!"
| moment and everything will forever be different.
|
| It's one of those things where you need to experience it
| for yourself before you actually understand how great it
| is. There is no argument you will hear that will convince
| you, sadly. I was the same once...
| sitta wrote:
| > I actually feel like very little has been added between
| Java 8 and Java 21.
|
| var, records, sealed types, and pattern matching make a
| huge difference in how Java is written. A lot has changed
| since 8.
| Alupis wrote:
| The issue with these new structures is they're
| necessarily clunky, to maintain interoperability with
| non-modern Java. Java's backwards compatibility is
| legendary, but is also why some of it's newer features
| are often criticized as not being as good as they could
| be.
| jcadam wrote:
| Kotlin is the closest thing to a "better Java" that I've
| found. I've used it with Spring Boot and the
| interoperability with Java is fantastic. A Java dev would
| have no problem picking it up quickly (as opposed to
| Clojure and even Scala).
|
| I say this as a Clojure fan, there are many instances
| where I'd probably choose Kotlin nowadays. You can also
| mix JVM languages within the same application; I've found
| it rather useful to sprinkle some Clojure into a
| Java/Spring application for certain tasks. Maven and
| Gradle both have tooling to handle it :)
| Alupis wrote:
| If you're into FP stuff, using Arrow within Kotlin takes
| you to that next level. It even works with Spring/Boot.
| bafe wrote:
| Couldn't agree more! It's particularly disappointing when
| you need to work on an older java codebase after
| finishing a Kotlin project. You'll constantly miss
| features
| ahoka wrote:
| Even C# seems like something stuck in the 1990s compared
| to Kotlin. (I know it's not a high bar).
| pjmlp wrote:
| Not kept up with the times in regards to C# 12 features?
| Alupis wrote:
| C#'s problem is it's quickly becoming C++ in that it
| doesn't just have the kitchen sink, it has three kitchen
| sinks...
|
| Unlike C++ though, one day the powers that be will just
| remove features as part of yet-another framework rewrite
| and you'll just have to deal with it.
|
| The other issue is just how tightly coupled C# as a
| language is to the .NET framework/platform. Some of the
| things people like C# for are actually framework things
| and they don't realize it because that separation isn't
| as clear as with Java and say, JavaEE or Spring or $X.
|
| If you talk to a C# developer - of course they're using
| .NET and of course they're using Entity Framework - to
| them, there's no other way. It's inconceivable that any
| other library or framework might do it _better_ than
| Microsoft 's official offering... and then you'll find
| the official offering to be lacking in fundamental ways.
|
| Talk with a Java developer and you'll find there's a lot
| more diversity of frameworks and libraries being used -
| so there's a lot more differing opinions on priorities
| and a lot more good ideas being tried out or implemented
| everywhere. The communities are vastly different in that
| regard.
| pjmlp wrote:
| It is still another syntax, with idioms moving away from
| JVM, their own little islands of Kontlin only libraries,
| and only works on InteliJ/Android Studio.
|
| I don't see any value in Kotlin outside Android shops.
| jcadam wrote:
| > I don't see any value in Kotlin outside Android shops.
|
| Developer experience is important to some people - not
| just devs, but those who seek to recruit and retain good
| ones.
|
| Of course, if you're looking to hire massive numbers of
| butts-in-seats (gov work, large enterprise shops, etc) I
| suppose Java is probably the ideal choice.
| Alupis wrote:
| While true it has it's own syntax, the syntax is better
| than Java and more ergonomic. With that said, you can
| write Java in Kotlin - and by that I mean Kotlin code
| that looks almost exactly like Java. Heck, you can have
| .java and .kt source within the same project all mixed
| together if you want.
|
| Kotlin libraries are interoperable with Java and vice
| versa. In some specific cases, a Kotlin library needs a
| little syntactic sugar to make it work with Java like a
| Java developer would expect, but it's easy to do. Going
| the other direction though - Java library used in Kotlin,
| zero issues, it just works. Some Java developers don't
| even realize they're already using Kotlin - take a look
| at OKHttp and friends...
|
| Lastly, there's Kotlin support is all major IDE's,
| including IntelliJ of course, but also Eclipse and likely
| whatever editor/ide you prefer. Kotlin is basically just
| a bunch of libs.
|
| I would argue Kotlin is better outside of Android than in
| Android. For backend work, particularly when coupled with
| Spring/Boot, it's freaking amazing. The Spring team has
| put in an impressive amount of work to make Kotlin a
| first-class language within the ecosystem, and it really
| shows.
| pjmlp wrote:
| Try to call Kotlin co-routines from Java.
|
| Telling me there is Kotlin support in Eclipse only tells
| me you never actually tried it, specially after JetBrains
| ramped down the team that was doing the now stale plugin.
| Alupis wrote:
| You should look harder before saying it doesn't work.
| Updated 10/6/2023[1]
|
| Coroutines are a specific paradigm within Kotlin, and
| should not be in library code anyway. With the addition
| of JVM Virtual Threads, the need for Coroutines is
| significantly diminished anyway.
|
| It's anecdata, yes, but I've written a lot of Kotlin code
| and do not use coroutines. Kotlin really just lets you do
| what you want - as much or as little idomatic code as you
| need.
|
| Kotlin on the backend is amazing. You really should give
| it a try. Java sucks badly, in comparison (I say that as
| a former Java nerd...)
|
| [1] https://marketplace.eclipse.org/content/kotlin-
| plugin-eclips...
| pjmlp wrote:
| And you should read before posting random links,
| After installation of the Kotlin plugin the Java plugin
| is not running anymore. I cannot open a Java project
| anymore. The log file says:
| !MESSAGE org/eclipse/jdt/internal/ui/refactoring/actions/
| RenameJavaElementAction$AjcClosure1 !STACK 0
| java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/
| ui/refactoring/actions/RenameJavaElementAction$AjcClosure
| 1 at org.eclipse.jdt.ui.actions.RenameAction.<ini
| t>(RenameAction.java:60) at org.eclipse.jdt.ui.ac
| tions.RefactorActionGroup.<init>(RefactorActionGroup.java
| :372) at org.eclipse.jdt.ui.actions.RefactorActio
| nGroup.<init>(RefactorActionGroup.java:206) at or
| g.eclipse.jdt.internal.ui.packageview.PackageExplorerActi
| onGroup.<init>(PackageExplorerActionGroup.java:139)
| at ...
| Alupis wrote:
| You copy/pasted an error some random person on the
| internet had in June due to using an incompatible Eclipse
| & plugin versions?
|
| The beauty of Eclipse is the ecosystem. If that official
| Jetbrains plugin doesn't do it for you for some reason,
| then use another one[1].
|
| [1] https://marketplace.eclipse.org/content/enhanced-
| kotlin-ecli...
| pianoben wrote:
| I've worked in several JVM backend projects, and Kotlin
| has been a stark improvement over Java (at least up
| through version 17, the most recent with which I've
| worked directly). Compose, and Compose UI, are
| tremendously promising technologies; I've shipped desktop
| apps with Kotlin for multiple platforms, and compared to
| just about every other desktop UI framework, it's a clear
| winner in terms of productivity and an ability to GSD.
|
| All that to say, I believe that Kotlin has a _lot_ of
| value, independently of Android.
| Tainnor wrote:
| "Only works on IntelliJ" is patently false. Stop
| spreading FUD.
| pjmlp wrote:
| Where is Kotlin support for Eclipse and Netbeans?
|
| Prove me wrong.
| Alupis wrote:
| Do you use Eclipse? Have you looked at the available
| plugins?
|
| There's nothing special about Kotlin. It's a bunch of
| libraries for runtime and compile time... like anything
| else you use.
| pjmlp wrote:
| It is my main Java IDE.
|
| There is a difference between supporting a language with
| a Notepad++ like experience, and what JetBrains was doing
| before ramping down the Eclipse plugin team, as means to
| sell more InteliJ licenses instead.
| Alupis wrote:
| What do you believe you are missing?
|
| It compiles fine with Maven or Gradle, it provides auto-
| prompt/complete/hints. It just works.
| pjmlp wrote:
| Same experience as in InteliJ, which JetBrains no longer
| provides.
|
| And above all, no crashes left and right.
| Alupis wrote:
| I'll ask again more clearly - what is the "same
| experience" you are missing?
|
| Kotlin is plugins for Maven/Gradle, and classpath
| libraries. There is no magic going on here...
| never_inline wrote:
| That's an interesting hypothesis. Is that applicable to
| platforms other than programming languages?
| vemv wrote:
| To be entirely fair, there's arguably little overlap between
| devs that stick to LTS, and devs that will play with JVM
| virtual threads on Clojure (before the Clojure team has any
| particular, public stance on them).
| fulafel wrote:
| Yes, especially since the use case for virtual threads is
| so niche.
| weatherlight wrote:
| Is this sarcasm, or just generally true in the java
| community?
| fulafel wrote:
| Neither for me (I'm in the Clojure camp), it just seems
| to me there aren't many situations where you'd need
| millions of threads. Plus we've got core.async to reach
| for to multiplex many control flows on one OS thread -
| though I feel it's more needed when targeting JS
| (ClojureScript) and the single-threaded world there.
| weatherlight wrote:
| I'm coming at this from a Erlang/Elixir background ,
| Where we basically have "virtual threads" but they aren't
| at the OS level. It's easy to use and making things
| concurrent (or parallel) is often trivial. Whether it's 1
| extra virtual thread or millions of virtual threads, the
| code (and the horizontal scaling of that code is the
| same)
| [deleted]
| bcrosby95 wrote:
| I can't think of a project I've worked on in the past 10
| or so years that couldn't benefit from virtual threads.
| Right-sizing your thread pools in an environment with a
| lot of IO is/was a pain in the ass.
|
| Many of the core concurrency constructs in Clojure has
| separate functions for when you are doing something that
| is blocking vs not blocking. If it were all virtual
| threads this distinction generally wouldn't matter.
| Alupis wrote:
| Not just that - the kicker is everything that already
| exists (libraries, JDBC drivers, etc) are now just
| automagically non-blocking too if you seed the thread
| pool with a virtual thread factory.
|
| I can't remember the last time such a transparent, drop-
| in-able change was so impactful for just about
| everything.
|
| While it doesn't remove the need for the
| event/reactive/async paradigm in all cases, it does
| removes the need for async code just for the sake of
| being non-blocking.
|
| Code can now be written much more clearly, and still be
| non-blocking. That's huge.
| [deleted]
| koito17 wrote:
| In fact, the officially supported Java releases for Clojure
| are all LTS releases. This is also reflected in their CI. At
| the moment, that means 1.8, 11, 17, and 21.
|
| I would also like to mention, for non-Clojure users: it took
| _ages_ for Clojure to finally get off Java 1.5. The compiler
| was still emitting 1.5 compatible bytecode as late as 2018.
| Since the release of Clojure 1.10 (17 December 2018), the
| minimum Java version was bumped up to 1.8, in the sense that
| the compiler now emits 1.8-compatible bytecode.
|
| There is a strong emphasis on moving slowly and NOT breaking
| things in the Clojure community. Likewise, if you look at the
| most recent Clojure survey results, the vast majority of
| people were still on 1.8 and 11 releases.[1]
|
| [1] See Q24 in https://www.surveymonkey.com/stories/SM-_2BH3b
| 49f_2FXEkUlrb_...
| tombert wrote:
| I actually do feel like this is partly what's responsible
| for Clojure's relative success in industry. If you have a
| company with a ton of Java 5 code, and you want some of the
| sexy functional programming features, your options
| basically boil down to "upgrade everything to the newer
| Java 8 to get maps and optionals and whatnot" or "just
| write this new service in Clojure that will happily interop
| with our Java 5 code".
|
| I'm not making a judgement on which decision is better, but
| I can totally see the appeal, at least in the short term,
| for people choosing Clojure, especially if they think that
| Clojure's API will be largely unchanged in the Java 8
| update. It doesn't hurt that Clojure is just broadly a
| really pleasant to work with, at least in my opinion.
| Quekid5 wrote:
| > If you have a company with a ton of Java 5 code...
|
| You are in deep deep trouble already, just process-wise.
| If you're making money hand over fist you might be able
| to afford to do that, but choice of language is not even
| on the radar in terms of what needs fixing.
|
| Now, if you mean in terms of digging out of that hole...
| just upgrade to newer dependencies, newer JDK versions,
| etc. That's the way to better performance, better memory
| usage, better GC, better everything... and _THEN_ think
| about the language you 're using.
___________________________________________________________________
(page generated 2023-10-06 23:00 UTC)