Java 21 makes me like Java again • Hacker News Board

Re: Java 21 makes me like Java again

#421

Post by pjmlp » Sun, Sep 17, 2023, 7:34 AM UTC

impulser_ wrote: post #187

northern-lights wrote: post #31

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.

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 co…

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.

Re: Java 21 makes me like Java again

#422

Post by pjmlp » Sun, Sep 17, 2023, 7:36 AM UTC

chii wrote: post #278

synergy20 wrote: post #262

Earlier quoted context omitted.

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…

> 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. i think it's a flaw that wasn't considered properly in the standard java toolchain to not produce an embedded java runtime into a final packaged artifact that is self-executable. You end up with third party tooling like: https://www.ej-technologies.com/res…

It has existed for 20 years, and already started with Sun.

Having AOT compilers as commercial offerings, was seen as one way to capture value in the Java market, in a culture where most compilers were still commercial, GCC being the exception.

Re: Java 21 makes me like Java again

#423

Post by pjmlp » Sun, Sep 17, 2023, 7:38 AM UTC

ashishb wrote: post #275

synergy20 wrote: post #262

Earlier quoted context omitted.

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…

Fully compiled languages have another huge advantage. If you write a tool in Python and targeted say Python 3.10 then people using Phython 3.9 might not be able to use it. So, you really can't use latest and greatest features of Python 3.11 or 3.12. However, with Go, you can build your tool in Go 1.21 or whatever, and the user does not even need a Go toolchain on their machine. I was planning to write a small side-pr…

Unless dynamic linking is used, or OS APIs change between version, or specific OS files change location.

Re: Java 21 makes me like Java again

#424

Post by pjmlp » Sun, Sep 17, 2023, 7:39 AM UTC

mariusor wrote: post #384

palata wrote: post #341

Earlier quoted context omitted.

How do you distribute a Go library? How do you distribute a Go library that has dependencies?

I'm not sure if your question is rhetorical, but Go doesn't have the concept of compiled library that you can link to another binary. So in Go you make available the library's source code, and the end-user will download it at build time, or vendor it in the source tree.

Which is a non starter for businesses that don't ship source code.

Re: Java 21 makes me like Java again

#425

Post by ArandomAccount2 » Sun, Sep 17, 2023, 7:39 AM UTC

quelltext wrote: post #326

iopq wrote: post #321

Earlier quoted context omitted.

Checked exceptions are gross, they get in the way when you're prototyping, and you end up just ignoring them anyway (since you're prototyping)

The ergonomics of checked exceptions may be debatable but compared to golangs explicit error handling at essentially each function call is definitely worse.

[dead]

Re: Java 21 makes me like Java again

#426

Post by pjmlp » Sun, Sep 17, 2023, 7:41 AM UTC

neonsunset wrote: post #226

arein3 wrote: post #197

Earlier quoted context omitted.

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 lik…

Java is an inferior language to C#. To get a superior language you would likely have to go for Kotlin. There is no comparison, because Java gets features today that C# had for years. Not even mentioning having to retrofit green threads because adopting async/await (used by TS, Rust, Swift and other languages) is impossible at this point.

C# is turning into C++, sadly.

It appears every six months there must be new language features being added.

The last one, for declaring fixed size arrays in structs, with an annotation instead of proper grammar change is getting ridiculous.

Re: Java 21 makes me like Java again

#427

Post by pjmlp » Sun, Sep 17, 2023, 7:43 AM UTC

neonsunset wrote: post #343

bad_user wrote: post #337

Earlier quoted context omitted.

C# does not have virtual threads. What C# has is async/await. Which was nice for its time, but at the same time it's an error prone design, as computations should never start async by accident, blocking should be the default. C# also has no useful interruption model. Java's interruption model is error prone, but at least you can work with it. Async/await also splits the standard library and the ecosystem in 2 (blocki…

Do give async/await in C# a try, it has all the structured concurrency features other languages have to invent APIs and special syntax for :) (if you want to take a look at good structured concurrency, you might be interested in Swift implementation)

And don't forget to bookmark David Fowler guidelines to avoid all the gotchas that everyone falls into while using async/await.

Re: Java 21 makes me like Java again

#428

Post by pjmlp » Sun, Sep 17, 2023, 7:45 AM UTC

neonsunset wrote: post #368

bad_user wrote: post #362

Earlier quoted context omitted.

I worked with C# professionally. The async/await syntax works with the language's other statements, but for a long time it had gotchas. It doesn't qualify as "structured concurrency", and it has the aforementioned issues — it's (accidentally) error-prone, it splits the ecosystem in two, and has no interruption model. I am not familiar with Swift, but I think you can hardly beat Kotlin's implementation. This is a good…

What do you mean by "it splits the ecosystem in two"? I never observed such split, certain methods intentionally offer sync and async variants. Interruption is achieved through cancellation tokens and has to be handled by consuming methods. There is no way around it because interrupting execution at an arbitrary point would lead to all kinds of issues regardless of the language (unless it implements some form of tran…

Except when there is only one version and someone has to write the transition code.

Re: Java 21 makes me like Java again

#429

Post by pjmlp » Sun, Sep 17, 2023, 7:45 AM UTC

neonsunset wrote: post #417

kaba0 wrote: post #385

Earlier quoted context omitted.

You can’t decide language superiority by the number of features. While C# indeed has many cool features, I do think it has already went into C++ territory where all the different, independently cool features have very non-trivial interactions that make it very hard to reason about. Also, async-await is not a good thing — virtual threads are superior in every way in case of a managed language.

Why async/await is not a good thing? What makes green threads better? Do you know the difference, the issues async/await addresses that green threads simply do not?

Read David Fowler's guidelines.

Re: Java 21 makes me like Java again

#430

Post by adrianmsmith » Sun, Sep 17, 2023, 7:46 AM UTC

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".