401–410 of 555 posts
Virtual threads to the rescue!
The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.
But in general it's best to write async code from the get-go because that forces the programmer to compress application state rather than inefficiently smear parts of it on the stack. Better state compression (because smaller stacks) -> smaller memory footprint per-client (or whatever) -> faster (because of higher cache hit ratios because of less cache thrashing because fewer memory accesses).
Earlier quoted context omitted.
You don’t really need anything, they just make forking and subsequent joining+exception handling easier. You can just use the decades old thread api over virtual threads as is if you wish, but this “structured concurrency” concept, similar to goto vs structured control flow will make it much more productive and easier to reason about.
Also true, but "use the decades old thread api" shouldn't count as a simplification, right?
Earlier quoted context omitted.
> PicoCLI for argument parsing is one Doesn’t it generate every additional code at compile time? I didn’t notice it slowing down my startup times, it’s mostly every other lib (which you usually have, as what’s the point of a hello world cli app)
I've timed it, it's very slow because it uses reflection to generate the model. The annotation processor doesn't let you avoid this step unfortunately. Native images do.
From the documentation:
> The picocli-codegen module includes an annotation processor that can build a model from the picocli annotations at compile time rather than at runtime.
> Enabling this annotation processor in your project is optional, but strongly recommended. Use this if you’re interested in
I think you didn’t use it.
Earlier quoted context omitted.
Version numbers are extremely arbitrary, and Java has a new number every 6 months. If you compare Java 6 (2006) and Java 20 (2023), and then look at C# 3.0 (2007) versus C# 11 (2022), C# has gained many more features and improvements than Java did over the years.
Including copying Java features like tiered compilation, default interface methods, compiler plugins, AOT compilation, being able to run UNIX systems, failing on having phone OS written in C#. Anyone that misses C# on the JVM can use Kotlin or Scala. And best of all, due to Microsoft's lack of investment on VS4Mac and VSCode versus VS proper, the best .NET IDE outside Windows runs on Java/Kotlin.
> best .NET IDE outside Windows runs on Java/Kotlin.
I would argue “in the world”. And it does not matter in the slightest to a user. The best Python IDE is PyCharm, also written in Java/Kotlin. I don’t know which PHP IDE is the best, but I’m pretty sure none of them are written in PHP, and the same probably applies to Ruby.
While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: ht…
Earlier quoted context omitted.
Don't be confused by the example, which semantically just shows a thread pool. It is hard to give an example in code as virtual threads ideally are purely an implementation detail and otherwise just look like normal threads. In a typical thread pool if you schedule more long running tasks than you have worker threads, you either have to queue your tasks waiting for a free worker or you have to spawn a new worker. If…
Oh so jvm virtual threads will suspend execution and yield without cooperation, just like an OS scheduler? That's a big difference to "just a task scheduler" which just queues tasks and distributes N tasks on M threads.
Earlier quoted context omitted.
I understand that you mastered producing a single binary with your favorite build tool. In my experience if a language does not have an official way to build projects it does end well. Go, Rust and Zig are the prime example that a language should not be separated from its build system. How to produce a single binary: go build cargo build zig build ... org.apache.maven.plugins maven-shade-plugin 3.4.1 package shade cl…
Yes, one is a command line command, the other is a part of a build description file, so false equivalents.
Earlier quoted context omitted.
As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 fo…
> I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder. I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a conf…
Earlier quoted context omitted.
I think you can with 3rd party tools, as with Python, but why would you? If your app is literally a single executable with no additional resources, maybe it makes sense, but otherwise, just bundle the JVM like jetbrains does. And as you mostly use Java on the backend, you're probably running Linux where a free and open jre is packaged, so just target that and not worry about it ever.
> And as you mostly use Java on the backend, you're probably running in a container.
If you use 200x images based on, say, `FROM docker.io/library/eclipse-temurin:17-jdk`, you only use 230MB + all other JAR/overlay layer sizes.