Java 21 makes me like Java again

https://wscp.dev/posts/tech/java-pattern-matching/

by wscp-dev • 3 years ago

412 636 3 years ago

kaashif3• 3 years ago

Nice article as someone familiar with sum types but not sum types in Java.

I don't know if sum types alone are enough to get me to like Java, pervasive nullability is still around and even rears its head multiple times in this article.

pharmakom2• 3 years ago

It's also not expression orientated yet.

kaba048• 3 years ago

Fortunately switch has now an expression variant. But I would die for an if-else expression (very subjective, but I would prefer a more verbose if-else to ternaries), and especially a try-catch expression!

leapis3• 3 years ago

Nullable is a huge issue in Java, but annotation-based nullability frameworks are both effective and pervasive in the ecosystem (and almost mandatory, IMO).

I'm really excited about https://jspecify.dev/, which is an effort by Google, Meta, Microsoft, etc to standardize annotations, starting with @Nullable.

wayfinder4• 3 years ago

I hope they succeed. So many people have tried.

kaashif3• 3 years ago

This can never be as effective as changing the default reference type to be not nullable, which would break backwards compatibility, so you can never really relax.

I know Kotlin is basically supposed to be that, it has a lot of other stuff though, and I haven't used it much.

mrkeen7• 3 years ago

I was just writing about nullability annotations!

https://news.ycombinator.com/item?id=37534184

netheril96• 3 years ago

Nullable annotations don’t work with well with generics, or at least those tools I use.

wscp-dev15• 3 years ago

With valhalla, we will have explicit nullability as well, so that problem will also be handled.

acheron• 3 years ago

In other news, we have an upgrade path at work to go from Java 8 to Java 11 pretty soon.

hmottestad4• 3 years ago

Going from 11 to 21 is a lot easier.

leapis3• 3 years ago

Depends- one of the hardest parts of the 11-20 upgrade for us was that cms gc was removed.

If you run a bunch of different microservices with distinct allocation profiles, all with high allocation pressure and performance constraints, and you've accomplished this w/ the help of a very fine-tuned CMS setup, migrating that over to G1/ZGC is non-trivial

taf2• 3 years ago

do/i/still/need/to/create/sub/directories/for/the/things/i/want/namespace?

mdaniel3• 3 years ago

Only if you're using vim like someone from the 70s, otherwise any sane IDE handles those things for you

But, yes, namespaces are still mapped to paths, it's not like they rewrote the JVM to use blockchain or something

chii7• 3 years ago

better_than_having_just_a_single_file_that_have_lots_of_functions_without_namespacing

paulddraper3• 3 years ago

Yeah, just like Python, Ruby, JavaScript.

wscp-dev15• 3 years ago

Yes/you/do/but/the/ide/does/it/for/you/so...

kyawzazaw2• 3 years ago

8 to 17 for us

minhtran• 3 years ago

Try with 8 --> 11 first then 11 --> 17

MBCook• 3 years ago

We (finally) upgraded last year from 8 to 17. Lots of nice things, I’m so glad we were finally able to. But it was a big project due to some dependencies and how some things were done internally.

I can’t wait for 21, but I’m not sure when we’ll switch. At least it will be trivial compared to leaving 8.

rendaw• 3 years ago

What were the backward incompatibilities preventing that move? I thought Java was pretty backward compatible, but I've heard this a lot.

chii7• 3 years ago

It's more likely that there's some dependency that is not easy to upgrade, because the upgrade also includes api changes (from the dependency, not from the jdk).

Compound this with multiple dependencies that exhibit this issue. If you have a "legacy" application that does not require active development, there's zero business incentive to invest into the upgrade. Unless you could prove value in having the upgrade, it just doesn't get prioritized.

wscp-dev15• 3 years ago

Java has in recent times actually removed some apis from the standard library, and made some inaccessible (undocumented internal apis especially) so any advanced frameworks that use them would have been affected.

sebazzz• 3 years ago

7 -> 8, but JBOSS 6 is a pain to migrate away from.

approxim8ion• 3 years ago

We made the jump from 8 to 17 this year! Some of our developers of course still write 1.6 level code, of course

Horffupolde2• 3 years ago

Can you convince me to use Java? I’ve never used it (only C++, Python, CL) but it feels bloated and dirty.

zapnuk• 3 years ago

What feels bloated and dirty?

Because there is plenty of bloated and dirty stuff in C++ and Python too.

hmottestad4• 3 years ago

You don’t have to use Java. All the languages you’ve mentioned are fine. If you think that using Java to solve a particular problem is a good idea, then you should definitely use Java.

justrealist2• 3 years ago

How could you possibly like C++ but feel that Java is bloated?

Like I academically understand disliking Java but this just makes no sense.

Jensson• 3 years ago

C++ allows for much more terse code than java when you do small projects. It is popular in competitive programming for that reason, not just because it runs fast but also because it is really fast to write algorithms in it.

jjnoakes• 3 years ago

I think of Java as more bloated than C++ at runtime - with C++ I can make smaller executables that start up faster, use less memory, etc.

But if you are talking about the source code itself, then things are quite different.

loxias4• 3 years ago

???

I'll answer your question with a question: Have you seen https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... ? :)

I'm guess that to those of us who remember when Java came out, "FizzBuzz: EE" is what we think of when we think of Java. :P

In Java I have to type a bazillion characters to get anything done! And make all these useless directories and files and InterfaceClassFactoryProtocolStreamingSerializer BS. And worry about how that executes.

C++? No bloat*, just speed

*Yes, there's some _optional_ bloat. But compared to Java? no contest.

OJFord2• 3 years ago

I think people are understanding 'bloated' differently.

I agree C++ is bloated in a 'just make it a setting' / 'add this feature' / 'kitchen sink' sort of way.

I agree Java is bloated in a boilerplate, empty directories, maybe except for another directory, 'oh god the boilerplate' sort of way.

deaddodo2• 3 years ago

I mean...Java is run through a VM while C++ is compiled to native code.

I can see that being used as a reasonable argument for bloat.

Blackthorn• 3 years ago

Bloat is a meaningless word. One person's bloat is another's essential.

belter3• 3 years ago

None of the memory problems of C++, the speed of C++ most of the time. Thousands of high quality libraries, a JVM that is a marvel of engineering after 20 years, tooling for development, monitoring and introspection of exceptional quality. Many of the internal tools at the largest Cloud developed in Java. Most enterprise level software. NASA extensive use of Java. A team behind the development who has stunning common sense in resisting the latest fads. Support for IEEE 754 that took years. AOT compilation...The infra behind most internet banking sites out there. Use in high speed trading.

What else do you want from the ecosystem?

hutzlibu5• 3 years ago

What would be a modern IDE for Java?

I remember programming Java in Eclipse. And it was powerful for the time, but everytime I read bloated, I automatically think Eclipse since then..

gabereiser2• 3 years ago

” None of the memory problems of C++”

I’m sorry, I’m calling BS here. You can still leak memory in Java.

loxias4• 3 years ago

None of the memory problems of C++

Every time I see something like this I roll my eyes... C++ doesn't have any "memory problems".

There are sometimes human problems, such as thinking one is capable of coding without understanding the (basic programming) concept of a pointer. But that's because the human's dumb, not a language problem. (This argument also sometimes comes from those who do understand basic programming, but are only familiar with C++98.)

Thousands of high quality libraries a JVM that is a marvel of engineering after 20 years

I reluctantly have to agree. :)

matsemann4• 3 years ago

What's dirty is trying to get a python project reliably running on all dev computers. Pyenv, venv, wheels, suddenly you need a complete rust or c toolchain etc. With java I haven't had those kind of issues the last decade, it just works. With python it's still a big hassle and everything breaks every update.

jessekv• 3 years ago

To be fair, getting all those scientific library binaries compiled and installed was a huge pain even before python came around. Python's toolchain made it better, but only marginally in some cases.

cbarrick3• 3 years ago

Throughput in Java can be quite high, and latency can be quite low. You still occasionally get latency spikes from the GC, but these days that's not so bad. (If you are extremely latency sensitive, stick to C++).

Dependency injection frameworks are your bread-and-butter in server-side Java, and some can take a while to grok, but Java can be very productive after the chosen framework "clicks" for you. Typically, this means you'll be writing constructors or factory classes that construct your dependencies per request. The way you wire your factories into the system differs by framework, but it often involves using Java's annotation syntax.

Not having to worry about memory management is a huge win for productivity over C++. Likewise, constructors in Java are much more sane than in C++.

Classical object-oriented programming is intuitive, and Java tends towards the "one obvious way to do something" paradigm. I find it pretty easy to hop into legacy code bases, if I already know the framework being used. The collections API in the standard library is one of the best classical OO APIs out there.

The JVM provides great visibility into the performance of your system. A lot of instrumentation comes "for free".

I'm not sure where you get the "dirty" and "bloated" feeling from. By any definition I can think of for those words, Python would be in the same bucket.

Horffupolde2• 3 years ago

Yes, I agree that Python can feel “dirty”, although not necessarily “bloated.”

riku_iki4• 3 years ago

Java can be very productive after the chosen framework "clicks" for you.

you can chose to not use DI frameworks at all..

whartung• 3 years ago

I’m a fan, long time fan, but I can honestly say that I feel Java is one of the most pragmatic development systems on the planet.

It can do most anything. It can do it most anywhere. And you can code in it using several different paradigms.

It’s easy to install, it’s easy to be instal several versions, the footprint, by today’s standards, is not enormous.

It’s easy to deploy, especially server side. While you can certainly do all of that modern stuff with containers and what not, it’s not really necessary for Java. Drag and drop a JDK install, anywhere. Plonk your Java server code, anywhere, and point it at your JDK, and. . .that’s it! Fire it up. The JDK is remarkably light on dependencies.

And since most Java apps are “pure Java”, the apps rarely have a dependency outside of the JDK. And since Java apps routinely bundle their Java dependencies, the apps don’t stomp on each other either. Even SQLite bundles it’s binaries in the Java Jar file. So wherever that jar goes (again, and typically bundled with your app), SQLite goes. No floating dependencies.

Desktop bundling requires a bit of search engine research, but it’s doable. And the runtimes can dwarf something like Electron installs.

As a language is Java ELEGANT? Not particularly. It has its own elegance in some areas but that can break down or get overrun in others.

But, boy howdy, it sure is practical. The ecosystem is so huge. It compiles really fast. I marvel at the stories folks tell about their dev cycles in other languages. How do they get anything done, besides sword fighting?

I love Java, but I’m very comfortable in it. But the Maven based dependency system works, it’s huge, it makes use and reuse simple. The IDEs are powerful and mature.

And, finally, Java’s not dead. Hardly. Oracle has been a surprisingly good steward (with warts, as always). The language has been on a rocket of development and shows no sign of slowing down. Server side is still very hot with all the frameworks and all the different approaches. Things like GraalVM taking the JVM in a whole new direction.

And, yea, that. I’ve only been talking Java the language, not the JVM itself per se. That’s a whole other thread.

EdwardDiego3• 3 years ago

I work on a Python codebase now after years of JVM and here's what I miss, static typing taken as read.

* Threads that can use more than one core.

* The best approach to package management I've ever seen, no-one worries about typosquatting or "someone already registered all the cool crate names" because every package has at least two coördinates - a group id based on a DNS entry you must be able to prove you have access to, then the package name. So I can publish my malicious package gauva, but as I can't register it with the group id "com.google.guava" or even "com.google.gauva", no-one is going to mistakenly use my package.

* No fucking dance of the C libs. Or Rust these days. I want to use a Python package that wraps a C lib, but there's no binary wheel built for my version of Python and/or platform arch, so build from source it is. Which I'll figure out when pip install -r breaks, and then I get to a) apt-get/brew/etc. install the lib and/or headers b) install any compiler toolchain needed buy not yet present c) export compiler flags and header locations d) all of the above, and then run my pip install again. Until the next library breaks.

* Intersection types for generic bounds. I don't need it that often but when I do, I really miss being to say that for `def foo(ex: T) -> Z`, T must implement interfaces A and B.

* Logging. Occasional horrible security holes aside, Java's logging story is one of the best I've ever worked with, compared to it, Go's sucks, Python sucks more, like how you can't set your preferred timestamp format AND include millis without writing a custom formatter (seriously, go look at the source code of logging.Formatter.formatTime...)

* JMX and MBeans. Having detailed VM performance metrics and the ability to change exposed values or execute an exposed method at runtime built into the VM is amazing. Want to have a quick look at what's happening with the GC? JConsole in. Want to set one logger in particular to DEBUG to see what's going on in prod without having to restart anything? JConsole or jmxterm and away you go. Want to experiment with your batching parameters under prod load to find the sweet spot for throughput? Expose them via an MBean.

* No need for pyenv, virtualenv, etc. Although being fair, if you're working with different incompatible JDK versions, you'll usually end up using SDKMan like Python uses pyenv, and Maven needs a little bit of additional configuration to locate your toolchains, but Gradle is smarter about finding your available JDKs.

* Libraries with type signatures, makes for far easier code reading, and if you pass **kwargs 5 levels down, I hate you. Yes you, sentry-sdk...

* Libraries with correct type signatures, looking at you confluent-kafka, either publish type stubs to typeshed, or update your goddamn doc-string type hints so my IDE doesn't think that confluent_kafka.Message.value() is missing a parameter.

* The ecosystem. I really really really miss the ecosystem of JVM FOSS packages.

* The speed, in general.

I'm sure there's more, but these are the pain points I've been having of late.

signaru• 3 years ago

What convinced me to consider Java just recently is GraalVM. I don't know about the "dirty" part, but at least GraalVM might solve the "bloated" part. Compiling to native standalone executables makes a big difference to what Java is traditionally known for (portable bytecode but requiring the JVM). Been using C++ and C# for a long time now, and my pet peeves with these languages were also only just addressed relatively recently (C++ getting modules and native AOT for C#). Java being able to get natively compiled makes it worth considering among these. Now, for me, it's a matter of what other frameworks/libraries available for the respective languages would get the job done while I only have to rewrite little to switch among them if I try my best to stay within their syntax overlap.

speed_spread• 3 years ago

Java itself is a nice language that can be lean and mean but has long been culturally bloated by early tooling and conventions. Since Java 8 (~10 years) the tide has reversed and it now mostly accepted to write terse code that is to the point.

The language gets updated regularly and is managed very competently. Although it may seem to trail on some aspects vs other langs, it benefits from second mover advantage - new features are done right, for the right reasons.

Any Java code ever written is essentially eternal, both in text and compiled bytecode form. Compiler and VM compatibility guarantees are unmatched. You can stumble upon 20 year old code and just use it.

The platform is mature and robust. The JVM itself is a marvel of engineering.

The ecosystem is extremely rich. There isn't a problem that wasn't addressed by a library or a stack overflow question.

The tooling is unequalled. IDEs can reliably perform large code transformations because there is no preprocessor or macros and the type system is relatively sane.

If you know Java you'll never be out of a job.

wscp-dev15• 3 years ago

Id rather say use kotlin. It comes with a better type system with explicit nullable types, proper closures, and syntactic sugar to easily enavle beneficial programming patterns.

Nd it is very compatible with Java itself, interop is dead simple

xyst• 3 years ago

Big firms I have worked at still using Java 8.

Dead.

avbanks• 3 years ago

A lot of Apache projects still use Java 8 :(

bombcar• 3 years ago

At least you can now run Minecraft 1.7.10 on Java 17 - https://github.com/GTNewHorizons/lwjgl3ify

wscp-dev15• 3 years ago

What a marvel of engineering.

Phelinofist2• 3 years ago

We have an app that also needs to be able to run on Android, so we are held back by the shitty Java Google implements for Android.

guideamigo_com3• 3 years ago

You can use [limited] Java 17 with Google's Android. The compiler converts Java 17 -> Java 8 bytecode.

tleilaxu• 3 years ago

I agree that many companies are “stuck” (through their own choice really)… but at least Java is moving now.

In many ways Java’s boringness is a feature that keeps it easily maintainable, at a low - easily recruitable - skill level.

insanitybit16• 3 years ago

The problems with Java can't be fixed by adding new things, you can't undo decades of ecosystem development, training, and ideology built on top of the idea that inheritance is really good idea and belongs everywhere.

edit: I will say that as a Java developer I am grateful every day for the improvements to the language. Java is a very impressive language and I have a lot of respect for the people working on it.

matsemann4• 3 years ago

I rarely see inheritance used in practice in java code bases. Except where I would use a union type or sealed class in other languages anyways. I don't feel what youre describing is a real issue.

xxs3• 3 years ago

Inheritance used to be extremely common, look at AWT/Swing - however more or less it finished there, e.g. more than 20y back.

There are still lots of folks who love 'protected' and deep hierarchies, of course. There is stuff like spring that uses way too many interfaces with a single implementation, doing something a bit off the regular road ends up implementing tons of the said interfaces anew.

However the 'hate' part is mostly the internet (well esp. Hacker news)warrior topic

sisve2• 3 years ago

Sorry, what? Is not java toghether with Ruby maybe the most hardcore OOP enthusiasts that uses inheritance for "most stuff".

Has the java culture move so far the last decade ?

insanitybit16• 3 years ago

I rarely see inheritance used in practice in java code bases.

That seems absurd to me and I have a hard time understanding it, honestly.

tail_exchange• 3 years ago

You must be really lucky then. In my previous job, inheritance and abstract classes were everywhere. Coupled with dependency injection frameworks that "worked like magic", it was really hard to follow the code inside that big, monolithic app. It made me never want to work with Java ever again.

rerdavies2• 3 years ago

HtmlElement. AST. Socket. Stream. Window. Closable. Runnable.

hutzlibu5• 3 years ago

There is nothing wrong with inheritance. But sure, there is usually something wrong with deep inheritance or using it, where better solutions exist.

insanitybit16• 3 years ago

No, there's a lot wrong with inheritance. It leads to all sorts of issues and while theoretically one can keep the tree 1 level deep, in practice it's too tempting to expand the hierarchy.

This is one of Java's big issues. The other is reference equality as a default, pretty horrible. Records help but records are also limited in when they can be used.

lelanthran2• 3 years ago

ideology built on top of the idea that inheritance is really good idea and belongs everywhere.

Those are two different ideas.

insanitybit16• 3 years ago

I used the word "and" to indicate that, yes.

wslh• 3 years ago

Please ELI5 what is wrong with inheritance and/or how Java have it wrong. Do we need to go back to a new object oriented undegraduate course? Genuinely asking.

insanitybit16• 3 years ago

Inheritance provides "is a" relationships between classes. At a time when people would spend months designing their software upfront, building big diagrams of classes, etc, this was not so bad. You'd have a very clean system design that maps directly to your class design.

The problem is when things change. A simple example - you build a classification of all life and it is built upon the idea that everything "is a" plant or animal. And then one day it turns out there are fungi. This is not a fun situation to deal with and inheritance makes it a lot harder because the "is a" relationship is driving a ton of your logic.

IDK I don't want to get to into it beyond that, many people have written quite a lot on the topic.

sirk390• 3 years ago

With compositions A uses B but B can never use A. With inheritance Child can use the Parent, but Parent will also call the Child (virtual methods) which in turn can call the Parent again etc.., so the code can become difficult to follow. It can become very complicated with multiple inheritance and multiple levels.

preommr• 3 years ago

Inheritance is fine. It helps to avoid code duplication for logic that requires encapsulated data (private, protected fields).

The problem is what if you have a class that needs to derive behavior that's in two (or more) classes? Multi-inheritance is terrible because it becomes a nightmare of which class overrides which.

If there's a shallow level of inheritance (1-2 levels deep), then there's nothing wrong with it. Things like composition for most use cases has been common advice since forever.

What happened with java was that there was a massive movement for enterprise code that way over-complicated everything based on ideas that didn't pan out. There were all these auxiliary patterns, and ideas that people had to learn to be onboarded onto projects, and so many people poorly understood them that it led to even more spaghetti code, too many people that developed using dogma instead of common sense.

ickyforce• 3 years ago

"What OOP users claim" -> https://i.imgur.com/KrZVDsP.png

nsajko• 3 years ago

"Prefer composition over inheritance" is actually a well-known mantra and appears in, for example, the Design Patterns book from 1994, which is basically the OOP bible. And this is within the OOP bubble, you won't even find inheritance outside of it.

https://en.wikipedia.org/wiki/Design_Patterns

Don't take undergraduate OOP courses seriously.

bbkane3• 3 years ago

If you want to see how codebases work without inheritance in practice, I suggest checking out Go, which features polymorphism through interfaces, but not full-fledged inheritance

kaba048• 3 years ago

Prefer composition over inheritance has been a common mantra for at least a decade, if not more. Maybe you should undergo the last decade of development and training.

There will always be shitty devs, and since java is one of the biggest languages, it definitely has more than some ultra niche academic language no one uses. I don't think it is the fault of the language though, or if that somehow were a reason to choose a different language. Should a decent BMW driver sell their car, because plenty assholes buy that car also?

insanitybit16• 3 years ago

Just because everyone has been saying "composition over inheritance" doesn't mean that that's how things get done. Jump into any Java codebase and you're 99% likely to see inheritance used as one of the primary abstraction mechanisms.

Should a decent BMW driver sell their car, because plenty assholes buy that car also?

A better analogy would be "Should you drive on the street where all of the shitty drivers do donuts and street races?"

mrkeen7• 3 years ago

Prefer composition over inheritance has been a common mantra for at least a decade, if not more. Maybe you should undergo the last decade of development and training.

What are some other well known mantras? The null reference is a billion dollar mistake? Minimise mutability?

Maybe the language designers and library writers could catch up too.

packetlost2• 3 years ago

Yeah, I think this is the part that gets me. To be fair, I think well designed Java is flexible in exactly the right ways for an enterprise development. The trouble is that enterprises don't typically pay well enough to get people who are really good and the popular ways of building Java applications are not great.

KillenBoek• 3 years ago

The problem with Java is not Java. It is Oracle and no amount of new features is going to fix that.

ant6n• 3 years ago

But, you know, Java too.

riku_iki4• 3 years ago

I am wondering if Oracle is really playing significant role in Java evolution, they have some open process with many other companies contributing.

kaba048• 3 years ago

They are responsible for like 95+% of all OpenJDK commits.

kaba048• 3 years ago

Can this fkin FUD finally die? Java is pretty much the safest bet on a longevity, stability, risk aversion spectrum. Also, Oracle just has a particularly bad PR, but it is not at all worse than any other similarly sized company.

wscp-dev15• 3 years ago

Oracle has definjtely done bad things; mismanagement of java is not one of them. They got a pile of crap and turned it into something competent.

northern-lights• 3 years ago

The biggest feature in Java 21 is the release of Virtual Threads: https://openjdk.org/jeps/444

For some reason, this is missing from the article. If there was any feature that would sway existing Golang developers to switch to Java, it would be this. It would perhaps also convince the haters of the reactive-style concurrency patterns.

mongol• 3 years ago

I wonder what will happen with these patterns now. They seem to have been invented to work around the problems with regular threads. Will new patterns emerge, or will the reactive patterns be ported to run on virtual threads?

bberrry2• 3 years ago

The reactive patterns are now obsolete and will die. And good riddens I say.

insanitybit16• 3 years ago

`Executor.newVirtualThreadPerTaskExecutor` versus `go` really gets to the heart of why I think that Go developers aren't going to be switching.

edit: Sorry, it's actually:

    try (var executor = 
        Executors.newVirtualThreadPerTaskExecutor()) {
       executor.submit(...)
    )

instead of `go`

kaba048• 3 years ago

So basically executor.submit(). And you still have a language that is significantly less verbose than go, objectively.

ivan_gammel2• 3 years ago

Wrap it in class Go { static void go(…) } and it will look better with “import static”

erik_seaberg3• 3 years ago

You’re likely to need a lot of boilerplate that “go” statement won’t generate: pass and wait for completed results, report errors, timeouts, cancellation, bounded parallelism, pushback, service monitoring.

mattbee• 3 years ago

Starting a virtual thread in Java isn't that clumsy:

   Thread.ofVirtual().start(() -> System.out.println("Hello"))

zaphirplane• 3 years ago

The go example is missing the channels, select, wait group, context, cancellation

Doesn’t sound like a fair comparison thou the Java version is missing things

foolfoolz2• 3 years ago

go will always lose vs java when it comes to code verbosity

lenkite5• 3 years ago

Extend that to a full function and the Go code will be 2x more verbose than Java with all the `if err != nil` stuff.

mike_hearn7• 3 years ago

If you want to use that with more concise syntax, there is Kotlin for that. In which case abstracting that is one line of code tucked away in a utility file:

    fun <T> go(body: ExecutorService.() -> T): T =
        Executors
            .newVirtualThreadPerTaskExecutor()
            .use(body)

Now you can write:

    val result = go {
       val result1 = submit { slowOp() }
       val result2 = submit { blockingOp() }
       result1.get() + result2.get()
    }

or words to that effect. You can also reduce it a lot in Java too, as mentioned by another commenter.

    class Shortcuts {
        static <R> R go(Function<ExecutorService, R> task) throws RuntimeException {
            try (....) { return task.apply(service) }
        }
    }

and then you can write:

    var result = go(service -> {
        var result1 = service.submit(() -> slowOp());
        var result2 = service.submit(() -> blockingOp());
        result1.get() + result2.get();
    });

using static imports.

Now if you're making a cultural point then sure, Java APIs tend to be named quite explicitly. It has advantages when searching or auto-completing, and it's easy to wrap with aliases if you want to abstract a boilerplate pattern away.

jayd163• 3 years ago

I don't think Golang devs are waiting to switch to Java if only making a lot of threads was easier.

Honestly, its way too early. Virtual Threads will need a a "killer app" (in this case a killer framework) to pull in devs.

kaba048• 3 years ago

Like Helidon Nima, Micronaut, Quarkus or recently, Spring?

bcrosby954• 3 years ago

The great thing about virtual threads is they're basically a drop in replacement for threads.

cgh• 3 years ago

Java 21 also previews structured concurrency (https://openjdk.org/jeps/453), which uses the virtual thread implementation. It seems really nice, at least from reading the examples, and removes a number of pain points when dealing with thread-based concurrency.

impulser_• 3 years ago

I don't think any existing Go developer is going back to Java.

I worked with Java for 10 years and switched to Go and I will never go back.

This is mostly because applications and libraries are so hard to reason about and understand due to inheritance, packaging, OOP, build tools ect compared to Go.

Go is simple. It's easy to understand, read, and maintain. The packaging is like how you would package files on your computer in single folders. The tooling is built into the language. You don't need a IDE like IntelliJ just to make it feel reasonable to work with.

Maybe all of this has changed, but most of the libraries I see in Java today still look like this.

kaba048• 3 years ago

This is mostly because applications and libraries are so hard to reason about and understand due to inheritance, packaging, OOP, build tools ect compared to Go.

You are just at the early phase of the project.

Go is simple. It's easy to understand, read, and maintain

My opinion is that Go is too simple, to the point that it hinders understanding and readability. 4 nested loops with random mutability is much worse than a clear Stream api "pipeline". The 31st if err check will not be actually handling the underlying problem, while you can't forget about Exceptions -- even if they do bubble up to the main app, you will clearly get an actionable stacktrace.

The tooling is built into the language

This has benefits, I will give you that. At the same time, I think all these new build tools are anemic and can't be used for anything more complex than interacting with the same language's standard dependencies. Gradle is not sexy, but is actually capable of doing any kind of build.

arein32• 3 years ago

Exception handling and generics are missing key pieces from go. But adding them will make go look like java.

I just wish java would add null safety in the type system in a first citizen way.

For enterprise use java has no competitors. You have c# which is microsoft trying to estabilish nash equilibrium fu*ing the developers. I am a bit worried about ever increasing complexity and a steep learning curve, but seems like this is a problem on all fronts.

totallywrong• 3 years ago

Go is simple. It's easy to understand, read, and maintain.

Matter of taste I guess, to me Go code looks ugly, it's too verbose with all that error handling every other line which hurts readability. Also the docs are often so cryptic and unhelpful, one needs to rely on examples elsewhere. I do use it though, when I need something fast in a single binary.

anoy88883• 3 years ago

This is correct. It is about culture too. Java is the kind of language that attracts some mediocre programmers who produce mediocre code based on the wrong ideas of object oriented programming. of course, there are great Java programmers. It is just that a better programming language would help average programmers like us to achieve more

hota_mazi• 3 years ago

Go gives you the illusion of simplicity because it gets rid of guard rails and error checking. If you remove all error checking, of course your code is going to look a lot simpler. It's also going to be a lot more wrong and crashy.

Wait until your code base grows, your team grows to >10 developers, and you will understand what I mean.

Java (and preferably Kotlin) are a lot more serious about making sure your code is robust before it compiles.

whateveracct• 3 years ago

Go also sucks. It's so easy to leak threads.

synergy2010• 3 years ago

Go's major selling point to me is that you can ship one binary, nothing beats that.

Python, Node, Java all have to pre-install lots of dependencies before you can use them, fine for developers, not so great if you want to distribute software for people who are not software savvy, who typically just wants to download one file, install and start using it.

c and c++ can also do one executable, but, it is not as portable as Golang, and not as static-link friendly as Golang.

iampivot• 3 years ago

Coming from Spring Boot with it's 17+ level deep abstractions to Go / gin-gonic was such a breath of fresh air!

nradov• 3 years ago

I never understood some of the objections to inheritance. It always made it easier for me to reason about the code, not harder.

pjmlp14• 3 years ago

Go is Java 1.0, nowadays 1.5, as they thankfully finally at least added some support for generics.

I am not touching Go, other than on the projects I have some customer or higher up telling me to do so.

nine_k2• 3 years ago

Go has made many decisions that i'm not happy about.

If they did one thing exactly right on the language level, it's the [lack of] OOP: interfaces in their implementations, and no inheritance, overridden methods, covariance / contravariance games, etc.

You can of course write in Java in that style: only extend interfaces, never inherit classes. But many libraries, including the standard library, actively refuse to cooperate.

jpgvm5• 3 years ago

I did. Did Go professionally for ~5 years and went to JVM.

Go is easy, but it's surface level easy. Building and maintaining large applications in Go if you don't have a huge team is a giant pain.

JVM (especially paired with Kotlin) for me atleast has meant regaining the expressivity I was missing from Ruby and Python when I moved to Go whilst retaining (well actually usually beating) it on performance and scalability.

I lost absolutely nothing to go to JVM but gained so many things.

sgt3• 3 years ago

This is also the killer argument for going Python, by the way. Go is going to be much faster, of course, but you can still scale quite well with just going Python. And sometimes / most often you don't need scale.

datavirtue• 3 years ago

Lol...you use the language most appropriate for the given situation. What's appropriate in the browser....hmmm. Can't slam your foot down on that one.

mx_022• 3 years ago

The packaging is like how you would package files on your computer in single folders

How does that vary from Java?

aarbor9893• 3 years ago

I use Go and Java every day, and Java is way more enjoyable to use

imetatroll• 3 years ago

No thank you. There is limited time in the day and go fills my needs.

Go, Rust, Ruby. These three cover all cases.

quickthrower23• 3 years ago

Add Python to that list (for the ecosystem) and JS (for front end web dev)

g9yuayon• 3 years ago

If there was any feature that would sway existing Golang developers to switch to Java, it would be this.

Not sure about this, but a trajectory question: why does the Go community have so few concurrent containers but Java community does? I mean, even `sync.Map` is specialized for two specific use cases instead of like Java's ConcurrentMap that is of general purpose. And In Java there are concurrent sets, queues, barriers, phasers, fork-join pools, and etc. I'd assume that even with Go's go routines, we can find great use of such containers, right? At least fork-join is not that trivial to implement. And using mutex everywhere seems just so... low level.

I understand that there are 3rd-party implementations, but concurrency is so tricky to get right that I would be really hesitant to adopt a 3rd-party package, unless it is as mature as Java's JCTools or Google Guava, both of which are also backed by a large number of users and developers.

segfaltnh4• 3 years ago

Because the predominant patterns are to do concurrency with message passing, so having multiple goroutines trying to mutate the same container is the exceptional case (though as you say, mutexes are the answer when needed). Another reason is containers are embedded features not stdlib, which has huge implications to how willing someone is to go against the grain, for better and worse.

throwaway20378• 3 years ago

What concurrent data structures that Google Guava offer than the standard library does not?

adamsb6• 3 years ago

Will that also make existing Sway developers go?

waffletower2• 3 years ago

From my vantage as a Clojurist, virtual threads on the JVM seem to have very minimal benefits. All I can think of at the moment, is that we could have thread-safe JDBC connectors: https://medium.com/oracledevs/introduction-to-oracle-jdbc-21...

eduction• 3 years ago

I mean couldn’t you have the performance equivalent of core.async’s go except with the ability to take across cross function boundaries? That seems pretty huge.

kryptonomist• 3 years ago

Go almost instant build time is a huge productivity boost when compared to Java. You get both the solidity of a typed language, and the development speed of interpreted languages (py, js).

troupo8• 3 years ago

Java's build times are very fast. Java's build tools are anything but. And I'm surprised no one is doing anything about it.

brightball3• 3 years ago

Java 21 has me anticipating the next JRuby release because of Virtual Threads. Charles Nutter gave a talk about JRuby in August where he showed a demo of the impact on Ruby fibers and it’s pretty significant.

There’s a lot that I really like about the JVM and it’s tooling, I just don’t like writing Java code anymore. JRuby kinda gives the best of both worlds.

Here’s the talk. Virtual thread demo is around the 45 minute mark.

https://youtu.be/pzm6I4liJlg?si=GtxQ4MThEaNDfC67

ksec• 3 years ago

Wondering if anyone is using JRuby on Rails in production.

kaba048• 3 years ago

How does jruby relate to truffleruby?

kaycey2022• 3 years ago

I loved this. Is there any post comparing Ruby performance with JRuby?

osigurdson3• 3 years ago

I once posted an Ask HN: what are your build times. A golang developer stated their 25 million line project compiles in less than half a second. If that is really the case, I must say, this is very impressive and potentially a reason to switch from other languages.

kaba048• 3 years ago

Java compiles very fast especially with a running gradle daemon, definitely on comparable levels. It also supports hot reloads to a degree.

Also, was that a clean build?

lenkite5• 3 years ago

Isn't this an exaggeration ? I have a 100k line go project and it takes several seconds to compile. No idea how a 25m line project compiles in less than half a second.

peterashford2• 3 years ago

I work on a product written in Go which is considerably smaller than 25 million lines and our compile times are... really... really long. I really don't believe that claim at all. If it's true, I would love to see how it's done because that is SOOO far away from my daily experience.

jjav3• 3 years ago

The biggest feature in Java 21 is the release of Virtual Threads

Is there a good honest writeup on why is this interesting? Very curious.

The earliest JVMs had this, green threads. Performance was terrible so it was eventually dropped.

I want to fully utilize every CPU and every core I have, why do I want green/virtual threads again?

kaba048• 3 years ago

The JVM automagically swaps out blocking network calls executing in a virtual thread to a non-blocking implementation, so potentially many other requests can be served in the same time.

So you get the benefit of async frameworks, with none of the negatives: the blocking model is trivial to reason about, read, maintain, and works perfectly with tooling (you won’t get an exception in some WhateveScheduler, but at the exact line where it actually happened. Also, can step through with a debugger).

tommiegannert• 3 years ago

For me, it's the difference between code structure and resource usage.

Green threads are for a cleaner code structure. async/await comes quite close, but requires function coloring, creating high coupling. The threads have to have low overhead, so that I don't have to think about whether I should create a new one or not.

Kernel threads are for parallelism and scaling across cores.

mike_hearn7• 3 years ago

It's not the same. The earliest JVMs weren't really thread safe at all but machines were single core so it didn't matter, you could just cooperatively multi-task.

Later HotSpot became thread safe (and fast - a rare achievement), so started using real OS threads so it could go multi-core.

Virtual threads are M:N threading. There are multiple native threads so you can exploit all the cores, and also user-space runtime managed stacks so you can pack way more threads into a process.

okeuro49• 3 years ago

I want to fully utilize every CPU and every core I have, why do I want green/virtual threads again?

If your task is CPU bound, then virtual threads don't gain you anything.

On the other hand, if your task is IO bound, e.g. for a webserver, virtual threads make it trivial to spin up a new thread per request, for massive workloads.

https://en.m.wikipedia.org/wiki/C10k_problem

wscp-dev15• 3 years ago

That is true, but there are many who have discussed that. I wanted to bring some attention to the new syntactic changes Java brings that can help with implementing better logic.

winter_blue2• 3 years ago

I wonder: are virtual thread at the JVM level? If so, would Kotlin (and other JVM languages) be able to leverage virtual threads to improve (e.g. produce more optimal JVM bytecode) for their async functionality?

midoBB• 3 years ago

It is a JVM level feature but the Scala guys at ZIO are not that excited about it IIRC.

krzyk• 3 years ago

It depends what one needs. VT are nice, but I don't use threads much, so it is a cool feature I won't use.

For me bigger feature is pattern matching for switch and records.

logicchains3• 3 years ago

I can't wait 'til Project Valhalla is complete and Java finally gets value types. Then with sum types, value types and goroutines it'll be one of the nicest languages out there.

mathisfun1233• 3 years ago

any advice on a book/tut to learn "modern" java?

Tomte2• 3 years ago

Core Java for the Impatient by Horstmann.

msgilligan8• 3 years ago

Manning's Modern Java in Action is outstanding. It assumes you already know basic Java.

https://www.manning.com/books/modern-java-in-action

mathisfun1233• 3 years ago

both suggestions here are for books that cover java 8. how is it possible that java 8 is modern relative to java 21?

aranchelk• 3 years ago

Why do we call them product types anyway?

Answer in the piece is not wrong, but put more intuitively and succinctly: the total number of possible value (inhabitants) in a product type is the product of the quantity of inhabitants of the constituent types.

Replace the “product”s with “sum”s and it works too.

Interestingly, the total number of unique functions (judged only in terms of input and output) from a -> b can be found by exponentiation, (inhabitants of b) ^ (inhabitants of a).

wscp-dev15• 3 years ago

Ill add that in, somehow forgot about that golden bit of info

trenchgun2• 3 years ago

Answer in the piece is not wrong, but put more intuitively and succinctly: the total number of possible value (inhabitants) in a product type is the product of the quantity of inhabitants of the constituent types.

More intuitively and succintly: product type is equivalent to a cartesian product of sets

tubthumper8• 3 years ago

Maps (and lists) are other examples of exponential types. Intuitively this should make sense that these are the same as functions because any pure function could be (theoretically) replaced with a map lookup of pre-computed values. In this context, list is a special map where the keys are integers.

Writing it out mathematically, given a List of Bool, the left-hand side is the number of elements and the right-hand side is the total possibilities.

- 0 : 1

- 1 : 2

- 2 : 4

- 3 : 8

- 4 : 16

- 5 : 32

and so on

jjtheblunt4• 3 years ago

Is there an Ocaml vatiant for the JVM (similar to F# for dotnet)?

satvikpendem• 3 years ago

I know of Scala for an FP variant but nothing that's ML-like specifically.

trenchgun2• 3 years ago

Well, one could argue thay Scala is a ML for JVM with Java syntax

iddan2• 3 years ago

You could say Kotlin to some extent..

Tmpod• 3 years ago

Yeah, it has nice funcional capabilities and libraries (like Arrow[0]).

[0] https://arrow-kt.io

jjtheblunt4• 3 years ago

I just found this:

https://flix.dev/

neonsunset9• 3 years ago

Sad this gets to front page while a blog post which documents that .NET 8 has 200 A4 pages worth of performance improvements gets absolutely ignored.

C# keeps being the language people are looking for but don't know about.

romanovcode• 3 years ago

C# keeps being the language people are looking for but don't know about.

Every time I point out about C# most programmers are saying about evil Microsoft and being locked in the ecosystem. Most programmers I've met do not even know that .NET Core is MIT open-source and runs on any device.

I really wish C# would be more widely used because it is amazing, and for sure 10 times better then Java.

mu53• 3 years ago

Its a good language, but the corporate sponsor and community is suspect. Microsoft has a long history of user hostile actions. The types of companies that use C# often treat SWE as second class. Learning and using C# limits career options to low salary, high stress jobs.

neonsunset9• 3 years ago

I'm going to vouch for this comment but not because it is correct but rather it presents good opportunity to address the concern.

C# and .NET are most heavily invested in by Microsoft which owns and steers its development, that is true. It is also true that JVM world sees investment from multiple MSFT-sized corporations.

And yet, despite the above, it keeps moving forward and outperforming Java on user experience, performance and features despite being worked on by much smaller teams. I think it stands on its own as a measure of a well-made technology.

In addition, you can look at source code and contribute yourself, 90% of what makes .NET run is below. Almost all development happens in the open:

    https://github.com/dotnet/runtime
    https://github.com/dotnet/installer
    https://github.com/dotnet/roslyn
    https://github.com/dotnet/aspnetcore

Could Microsoft do a better job at making it even more community-facing and attempting to make the .NET foundation as a sole owner and steering committee of the language itself? Sure. But it's not that bad either today. Quick reminder - Oracle is not exactly a saint, perhaps even worse (MSFT has never gotten into any litigation even remotely related to .NET or C#).

As for career opportunities, as other commenters would note, this is highly specific to a region and does not translate globally. Again, we are discussing the "how good the language/platform is" first and foremost. I don't see startups adopting Go because of the market or trusting Google not to rug pull them...so perhaps we can do a better job so the next language of choice they pick is C#, which has much higher ROI in the hands of the good developers (for example, it can be very easy to adopt as a second language if you are well versed in Rust).

Bognar2• 3 years ago

Microsoft uses C# internally and has a vested interest in making it better for all of its own developers, as well as making it good to increase industry adoption so it has a larger pool of skilled developers to hire from. Your arguments about who backs the language don't hold water.

paradite5• 3 years ago

We live in bubbles.

In my limited 6 years of professional experience as a software engineer, I have never met a single person who writes C# or .NET.

paulddraper3• 3 years ago

It's because C# only "recently" became cross platform in a reasonable way.

Hard to overstate the mindshare that it lost for that

5e92cb50239222b2• 3 years ago

And it's still not as cross-platform as Java is, or pretty much all other tech stacks. FreeBSD and commercial UNIXen are not supported at all. If you prefer to develop on macOS or Linux (hi there), you don't get access to many Windows-only tools (mostly for debugging and performance measurement). Microsoft only cares about other operating systems to inasmuch as you can host the resulting application there, but really expects you to develop on Windows. Which makes sense... for them.

devjab3• 3 years ago

It’s because C# is only really nice on the surface. As soon as you actually do something with it that takes it beyond its cozy CRUD, it becomes such a nuisance to work with.

We have an ODATA client that we build our selves to use in our React frontend. Now, this would obviously not have been something we also used on the backend if we knew what we know now, but it’s the perfect example to illustrate my decades of experience with C#. We had the client because we use a lot of Office365 and BC36 APIs and they are ODATA, and since we had the client we figured we might as well use ODATA on our internal APIs. Which was all well and good until we tried mixing EntityFramework, ASP versioning and ODATA together. These are all Microsoft packages mind you, and they just don’t work together. They each use the Model builder magic that C# comes with, but they each use it differently enough that things become a nightmare. Which basically sums up why C# has been a terrible language for its entire existence.

If you never get to those breaking points, then C# is fine. But when you use it for what you’d assume it was intended for, well… At least the ODATA experience sort of triggered my C# PTSD from back when I wrote an admin system to maintain all the thousands of school printers and computers in a municipality, which was hefty Active Directy work and an absolute nightmare to the point where I literally had to either extend or rewrite half the Microsoft packages because they either weren’t finished or outright terrible (again likely because they weren’t finished). Similar to how the ODATA, ASP versioning and EntiryFramework packages aren’t really finished right now. I mean, I can look at the road map for EF and see some of our issues as planned fixes on who knows when. Anyway, since those days more than a decade ago, it’s become obvious that if you want to do anything AD related then you need to use PowerShell and not C#, really, C# doesn’t even run in Azure runbooks and Python does so it’s obvious that Microsoft themselves don’t really use a whole lot of C# for that part of IT operations internally. And I think it’s frankly the same with a lot of things. The ODATA package seems to fall in that same “not used by Microsoft” box. Because it appears to be some sort of “fork” that’s mostly maintained by a single employee in China.

So yes, if you just use regular ASP and EF without versioning or ODATA to do very standard CRUD monolith APIs it’s a language that’s both fast and productive. Sure you’ll still need to do all sorts of silly things with your Azure DevOps pipelines to get EF migrations for Microsoft’s own SQL server to work, but hey, you can. But if you’re actually going to be doing things that takes it beyond it’s “basics” then no, C# is really not the language people are looking for but don’t know about.

I’m also partly in the “Java is sort of 10 years late with 21” club, but it’s not like anyone has switched away from Java in those 10 years, and really, it’s not like it was a fun experience to go through the .Net -> .Net Core -> .Net, .Net Standard and .Net Core -> .Net years, so maybe Java did it right?

zigzag3122• 3 years ago

Your issue seems to be with packages provided by Microsoft, not C# language itself. Model builder magic is part of those packages, not C# language. These types of libraries often make simple things quick and easy, but complex things (or just simple customization) much harder or even impossible.

kaba048• 3 years ago

Since it is a Java thread, I’m gonna mention that ecosystem-wise, the JVM is just much much bigger and of higher quality - you very often see copied JVM packages in C# with much less features, less stability, and often even being paid.

With that said, it is a cool language and platform, that is indeed underhyped.

olavgg2• 3 years ago

This 100x, C# and Java are also very similar programming languages. C# may be a better language, but the difference is minimal. Most C# developers claiming that C# is a better language often don't know Java. I remember one C# guy telling me that Java didn't have closures before Java 8, which was not quite true. Java developers had access to Groovy which had closures. Groovy may be another programming language, but it has always had 99% Java syntax compatibility and they both compile to the same byte code and work seamlessy together. Groovy 4 also has LINQ if you like that. And using Groovy is no harder than including it as a dependency in Gradle/Maven.

Java eco system is so vast, and of top notch quality, with excellent documentation available for free. It enables businesses to move faster, at a pace most other languages cannot offer. It's not perfect, especially I find data sciene libraries lacking in Java compared to what the Python eco system offers. But depending on the task I try to choose the right tool for the job, not the same language for every job.

mrkeen7• 3 years ago

I've written in C#. It's Java. If they're not the same language to you, you need to learn more languages.

equasar• 3 years ago

Second this. But here in hacker news, C# is hated for no reason, just the old Microsoft mantra and NET Framework

switch007• 3 years ago

Are you feigning ignorance about why people don’t like Microsoft?

We all know C# exists

ahoka• 3 years ago

Both are horrible languages and while Java libraries are abundant, most are horribly over-engineered, archaic stuff from the 2000s, where everything was about forcing OOP on every problem. Log4j executed code from an ldap server. Insane.

slotrans• 3 years ago

This set of changes allows Java to express one of the foundations of functional programming that the language never could before - Algebraic data types, along with idiomatic ways of using them.

And here I thought the foundation of functional programming was functions, which Java still doesn't have.

Seriously, functional programming is about functions, not types.

chii7• 3 years ago

functional programming is about functions

different people mean different things when referring to functional programming.

Some people believe that functional programming are using higher-order functions like `map`, `reduce`, `forEach`, etc, which takes a function as a parameter, instead of doing imperative loops.

Some people, in addition to above, believe that functional programming is about creating functions that take a certain 'shaped' parameters, to allow for automatic checking.

And lastly, the "real" functional programmers are people who believe in referential transparency in your functional program.

kaba048• 3 years ago

How is Math::sqrt not a function in Java? Sure, it’s called a static method and it lives in a class - but is it meaningfully different from the same being a function in a Math namespace in say, C++? You can static import it even and use it as a function. This is just needless hair splitting imo.

mrkeen7• 3 years ago

And here I thought the foundation of functional programming was functions, which Java still doesn't have.
Seriously, functional programming is about functions, not types.

Well it does have methods and it does have "Functions" (not to mention "Bifunctions", whatever those are). And there's certainly nonsense around exceptions and referring to outer variables. And no currying.

But if I understand you correctly, you real complaint is about not having effect-free functions, right? But then it becomes about the type system again, because that would be the mechanism to prevent effects.

billfruit• 3 years ago

Does it add value types?

wscp-dev15• 3 years ago

Thatll probably come in about a year or so going by the pace of valhalla's completion.

ArandomAccount2• 3 years ago

Has anyone used virtual threads? I tried to migrate my app over to VT's and kept experiencing random deadlocks and I couldn't figure out what was causing them. I tried moving all the synchronized blocks to reentrant locks, but that didn't work. I also tried turning on the TV debugging system properties, but none of them printed the problem.

adrianmsmith• 3 years ago

The "Sealed classes" feature, as described here, just feels all wrong to me.

They are saying that if you have a (normal) interface, anyone can create a new class implementing it. So if you do

    if (x instanceof Foo) {
        ...
    } else if (x instanceof Bar) {
        ...
    } ...

then your code will break at runtime if someone adds a new class, as that code won't expect it. So the article is saying the solution is to use the new "sealed" interfaces feature, so nobody can create any new classes implementing that interface, and your "if" statement will not break.

Surely object-oriented programming already thought about that and already solved that? (I know object-oriented programming is out of vogue at the moment, but Java is an object-oriented language.)

The solution there is to add a method to the interface, and all your classes implement that. Then rather than having a massive if/switch statement with all the options, you call the method.

That is better than preventing people from extending your code, it allows them to extend your code. They just have to implement the method. And the compiler will force them to do that, so they can't even accidentally forget.

The example given of color spaces (RGB, CMYK etc.) is a great example. I can absolutely imagine writing code which uses color spaces, but then some user or client having a need to use a weird obscure color space I haven't thought of. I wouldn't want to restrict my code to saying "these are the color spaces I support, due to this massive if/switch statement listing them all, the code is written in such a way that you can't extend it".

nine_k2• 3 years ago

There are valid use cases for that.

Consider a security interface of some sort, e.g. such that validates a security token.

With a normal interface, it is easy to implement it and ignore the token (allow all), siphon off the token, add a backdoor, etc. If a class doing that is somehow injected where a security check is done, it can compromise security.

Now with a sealed interface, there cannot be new, unanointed implementations. If you get an object that claims to implement that interface, it's guaranteed to be one if the a real, vetted implementation that does the actual security check, not anything else. You've just got rid from a whole class of security bugs and exploits.

pkolaczk4• 3 years ago

The solution with sealed classes also allows anyone to extend the code, but in a different dimension than the solution with an interface method.

The solution with interface method and virtual call is very inflexible when you want to add new operations instead of adding new classes. If you want to just add one new operation, then you have to go to all the implementations and add new methods. And you possibly break the implementations you don't have access to. And all those methods must be defined in a single class, even if they are unrelated to each other. This seriously degrades code readability (and performance as well - those vcalls are not free either).

The sealed class extends much better in this case. You just add a new switch in one place and done. No breaking of backwards compatibility.

This is the famous expression problem.

https://pkolaczk.github.io/in-defense-of-switch/

andrekandre2• 3 years ago

  > If you want to just add one new operation, then you have to go to all the implementations and add new methods.

not necessarily, if you have extension methods (kotlin, swift) you have the option to extend the interface and only override the specific implementation when needed

kaba048• 3 years ago

It doesn't always make sense to allow extending -- String is `final` for a reason (and one might even argue that final should be the default, and one should explicitly mark with `open` classes that can be subclassed).

The stereotypical FP example for sum types are a List -- there you only have an Element<T>(T head, List<T> tail) and a Nil(). There is no point extending it, it would, in fact, result in incorrect code in conjunction with all the functions that operate on Lists.

Also, the Visitor pattern, which is analogous to pattern matching is very verbose and depends on a hack with the usual method dispatch semantics of Java. I do think that pattern matching is several times more readable here.

erik_seaberg3• 3 years ago

In a world of untrusted code and SecurityManagers, it was critical that strings be immutable so a data race couldn’t bypass a policy decision. The JVM doesn’t have immutable arrays, so string methods carefully protected the embedded array from tampering, and couldn’t be overridden.

Most classes don’t have this problem. The original authors of a class don’t know what I’m trying to do, and they don’t bear consequences if I (a consenting adult) get it wrong.

mrkeen7• 3 years ago

I understand what you're recommending, and I've seen Bob Martin talk about it extensively (polymorphic dispatch instead of instanceof), but it's something I disagree with.

To do this kind of polymorphic dispatch, objects have to deal with multiple concerns within themselves.

In a video game, a Car might have .render(), .collide(), .playSound(). Later on you can add a Dog, which also has those three methods, and you don't need to edit/recompile the Renderer, the PhysicsEngine, and the SoundEngine. And other programmers can add additional entities like this without introducing bugs into my precious code! What's there not to love?

Well, now both my Car and my Dog need to know about graphics, physics, and sound. And these entities don't exist in isolation. Cars and Dogs need to be rendered in the right order (maybe occluding one another). They'll definitely need to check for collisions with each other. And (something which has actually happened to me in a Game Jam) my sound guy is going to need to step into all my objects to add their sound behaviours.

I would much rather work in the Physics.collideAll() method, and have it special-case (using instanceof) when I'm thinking about physics, and work in the Graphics.renderAll() method when I'm thinking about graphics.

A more common example I see in day-to-day backend Java web dev: when I'm sitting in the (REST) Controller deciding how to convert my Java objects into HTTP responses, I much prefer it if I can consider them all in one method, and map out {instanceof Forbidden} to 403, {instanceof NotFound} to 404, etc., rather than putting getCode() (and other REST-specific stuff) into the Java classes themselves.

jppittma2• 3 years ago

The OO solution is to have a PhysicalObject class that dog and car both inherit from (or use via composition).

valenterry2• 3 years ago

The solution there is to add a method to the interface, and all your classes implement that.

What if you don't know all methods that you will need in advance?

That is the problem and this problem is solved by sealed classes. However, by doing so they introduce a new problem: what if you need more extending classes and you don't know all of them in advance? Which raises the question: is there a way to achieve both?

This problem is called expression problem. [1]

There are (statically typed) languages that are able to solve the expression problem, Java is one of them [2]. However, unfortunately the way to do that in Java is (still) very complex and unergonomic, hence rarely used. Languages like Haskell or, if you want to stay in the JVM world, Scala do much better here.

[1] https://en.wikipedia.org/wiki/Expression_problem [2] https://koerbitz.me/posts/Solving-the-Expression-Problem-in-...

valenterry2• 3 years ago

Finally Java catching up with some basic features that Scala has for 10 years or so. Hoping that more good stuff from Scala will get into Java soon, maybe at some point I can try to use Java again. :-)

lakomen3• 3 years ago

The biggest problem with Java is... the walled garden, the snob society, the elitist, exclusive culture.

Go isn't like that, or at least wasn't when G+ was still around.

Nowadays I don't get in touch much with people, but when I create issues Go people are usually not as unfriendly as Java/JVM people.

bsdnoob• 3 years ago

Imo problem with Java is... JVM because it's quite a resource intensive application itself, memory usage is orders of time magnitude worse than most of the language I've used.

sz4kerto• 3 years ago

Interesting. A Spring Boot webapp (with the runtime dependency injection framework, etc. etc.) serving some static content and exposing some REST endpoints works fine with 32 MB RAM. Is it really orders of magnitude more than other languages, e.g. will a Go-based webapp consume less than 300 kBytes of RAM?

belfthrow• 3 years ago

Forgot that our computers were so resource constrained these days...

SpaghettiCthulu2• 3 years ago

That's almost always a consequence of poor engineering. You need to consider the runtime when developing any program. With Java, that runtime is more than just your CPU and OS, it's the JVM too.

xxs3• 3 years ago

The biggest problem with Java is... the walled garden, the snob society, the elitist, exclusive culture.

No idea how you have managed to come to such a conclusion, or what kind of experienced you might have had. I have been part of some of the core JSR/groups, as rather independent/unaffiliated (not oracle/google/hp/ibm/twitter) - there was no gate keeping, elitism or anything alike.

I'd consider mailing lists extremely professional, respectful, even nice.

gorjusborg• 3 years ago

Agreed, I have never seen a pattern of elitist behavior unique to the Java ecosystem.

There are always people like that when groups get big enough.

The thing I love about the JVM ecosystem is the engineering culture. The quality of the platform and most libraries is very high, and well designed.

I don't love the Java language, but it can get the job done.

boxed• 3 years ago

Rudeness scales mostly with the size of the community. If you go to something like Nim you will immediately find them way more nice than Go, just from this.

raincole• 3 years ago

Java? Elitist...?

Maybe it's true for Haskell or Rust. But Java?

ahurmazda• 3 years ago

My favorite go feature (not exclusive to go) is `implicit` interface. Once I drank from that cup there is no going back!

andrea76• 3 years ago

I hate Java because the docker containers based on it take too much RAM. The smallest Spring JAR takes about 70-120 MB for a single container!

jiehong• 3 years ago

Hate spring instead ;)

pharmakom2• 3 years ago

the argument for Java seems to be that it's gradually gaining features we already have in Scala, Kotlin, OCAML, F#, etc... so why not use the languages that have those features today?

msgilligan8• 3 years ago

One thing about "gradually gaining features" is that the Java language architects do a very good job with backward-compatibility. This means that your application/library will be easier to migrate to newer versions of the language and you will continue to have a large number of 3rd-party libraries available. The Scala community is currently migrating to Scala 3 and many libraries have not been ported (Scala experts correct me if I'm wrong.) Kotlin also seems to be less stable at the API level than Java (but I may be wrong here, Kotlin experts please correct me.)

This backward-compatibility does comes with costs (e.g. non-reified generics)

Also, if you're a library developer and you want to create a JVM library that can be used by Scala, Kotlin, etc. developing in Java is often the best choice. For one thing it avoids any dependencies on the standard libraries of those other languages.

Disclaimer: I like Kotlin and Scala, but mostly use Java.

agrounds• 3 years ago

Inertia. There are still a ton of Java shops out there, and many of them will not switch even partially to another language anytime soon. The hope is that these orgs might find it easier to upgrade to Java 21+ than to learn and start using Kotlin/Scala/etc. I fully expect I might find myself working at such an org again, and when I do I’ll be grateful for newer Java features.

Signed, a dev who would never willingly choose Java over Kotlin for anything ever again.

MagicMoonlight2• 3 years ago

Because Java will still exist in 5 years

truth_seeker2• 3 years ago

Golang is simple, smart and opinionated subset of Java/C#.

Everything moves slowly in corporate world. It will take another at least 2-3 years for large community of Java ecosystem and average devs to adopt Java 21 and capabilities.

kaba048• 3 years ago

Go is just a dumb subset hyped up as simple, but it is useless and slowly it will have to introduce all the remaining pieces in some ugly way as they didn’t plan with them ahead of time - see generics.

truth_seeker2• 3 years ago

That is exactly what I used to think when I started with it. But I changed my opinion after 6 months with Go and eco-system. It's not ugly, it's different and much more concise.

msgilligan8• 3 years ago

The title of the blog post is IMO a poor choice. The (hidden) subtitle of the post is "Algebraic data types in Java" which is much more descriptive of the content. A better title would have been "Algebraic data types in Java 21".

Perhaps because of the title, many/most of the comments here are off-topic. I was hoping to see more discussion about algebraic data types, strengths and weaknesses of the Java implementation, technical comparisons to other languages, etc.

fatfingerd• 3 years ago

Yes, I'm also not really sure I want to see algebraic types in Java even though I would prefer if a language that focused on algebraic types was more popular.

All the existing Java code doesn't go away, so is it really going to be nicer to have code like this mixed randomly into that?

owlstuffing2• 3 years ago

Of all the features most Java devs (and ex-Java devs) desire, algebraic types are near the bottom.

How about intersection and union types? (NO, sealed classes are not a substitute for unions).

But, yeah, in my view JDK 21 is a a disappointment. I rarely want pattern matching, but I would like properties please and records are nice, but actual tuples are more useful. Etc.

msgilligan8• 3 years ago

Well hopefully it won't be mixed in _randomly_.

I have some use cases in mind and think it will be very helpful. I have been converting a 10+ year-old code base to modern, functional-style Java and believe that sealed types and pattern matching will help us further simplify our code and eliminate more usages of nullable values.

A challenge for us will be that we need the core library to stay on JDK 8 for a while. But, in general, I am finding that you can implement a JDK 8 library that works well with newer JDKs if you are careful (and willing to write more verbose code using the older syntax/libraries to support the newer paradigms)

wscp-dev15• 3 years ago

I did title it that way at first but ended up changing it at the last second, ended up shunting it off course.

msgilligan8• 3 years ago

It's a great post. Thank you for writing it!

earthboundkid• 3 years ago

道生一，一生二，二生三，三生萬物。萬物負陰而抱陽，沖氣以為和。

The Function gives birth to the Unit type. The Unit type gives birth to the Boolean. The Boolean gives birth to the Value type. The Value type gives birth to the Top type. Each Top type contains 0s and 1s, thereby bringing harmony to the computation.

dzonga2• 3 years ago

java was never really a bad language.

the people were. if not massive over-engineering. too many abstract concepts that make it hard to grasp a codebase.

code voodoo - in the form of reverse GOTO statement i.e annotations

DI frameworks .

what needs fixing is not the language but the ecosystem. there needs to be a "reformation" movement within the java ecosystem.

yeah people migrating to kotlin or clojure or scala isn't enough.

_gabe_2• 3 years ago

100% agree. You can create a HammerFactoryFactory to churn out HammerFactories in any language. But the ecosystem in Java (and C# is similar imo) promotes and encourages this type of problem solving.

The one thing Java really does need is free standing (or namespaced) functions though. Sometimes I don’t want a class, what’s wrong with a function in a module or namespace in that case?

MagicMoonlight2• 3 years ago

A class is a module/namespace. You can make a class just to have functions in it.

jjtheblunt4• 3 years ago

Is there any widespread concern over lack of unsigned int native types?

kaba048• 3 years ago

Not really. With valhalla they can be user-implemented efficiently, although without syntactic sugar like +.

jjtheblunt4• 3 years ago

Does that mean addition would look like

  Uint32 a,b,c;
  c = a.plus(b);

in what you describe, once project valhalla is complete?

YetAnotherNick• 3 years ago

Java was always a great language. It's the enterprisy ecosystem that make me want to throw up. To implement a line of logic, I have seen dozen classes and interfaces.

michaelcampbell• 3 years ago

What a weird title change.

wscp-dev15• 3 years ago

did that to make it a bit clearer what I was really optimistic about, but I unfortunately can't edit the hn post itself.

fooyc• 3 years ago

The author cites this to justify the need for Records:

Most Java objects set every field to be private and make all fields accessible only through accessor methods for reading and writing.
Unfortunately, there are no language enforced conventions for defining accessors; you could give the getter for foo the name getBar, and it’ll still work fine, except for the fact that it would confuse anybody trying to access bar and not `foo'.

Scala supports pattern matching on objects implementing the `unapply` method.

Is this considered harmful? Why didn’t Java follow this route?

wscp-dev15• 3 years ago

it's a matter of standardisation again. Java's standard is like C++; ponderous. The record pattern jep indicates in final footnotes that something like unapply may be in the works, so all hope is not lost.

Java 21 makes me like Java again

Related Stories