Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 21 makes me like Java again

wscp.dev

Post reply on HN
Print view View original

471–480 of 777 posts

Re: Java 21 makes me like Java again

#471

Post by imtringued »

speedgoose wrote: post #413
classabove wrote: post #316

Earlier quoted context omitted.

Are you specifically referring to method function receiver type annotations? Those are often left shorthand but shouldn't exist out of the type definition file anyway eh?

I’m referring to this guideline: > Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex. https://github.com/golang/go/wiki/CodeReviewComments#variabl...

One of those is not like the other...

lineCount is literally perfect meanwhile sliceIndex could be anything.

Re: Java 21 makes me like Java again

#472

Post by imtringued »

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.

Java 21 doesn't retrofit green threads though. Quasar [0] is a library that implemented fibers for Java and the main developer pron has joined the OpenJDK development team. All that was necessary for first party support is to make the JDK libraries yield when blocking.

Adopting async isn't impossible at all, there is very little demand for it.

[0] https://docs.paralleluniverse.co/quasar/

Re: Java 21 makes me like Java again

#473

Post by ivan_gammel »

bedobi wrote: post #386
ivan_gammel wrote: post #350

Earlier quoted context omitted.

To build a good product you don’t need a kid with Hollywood star complex, for whom the choice of programming language or tools matters that much. If Java repels such self-proclaimed “best talent”, good, because the team will be healthier without them. There’s enough engineers willing to learn and write a good code on Java to solve a business or an user problem, and they are absolutely not mediocre. There’s even no su…

> To build a good product you don’t need a kid with Hollywood star complex Agree 100%. > for whom the choice of programming language or tools matters that much Programming languages do matter. Serious, mature professionals critically evaluate and compare tools and pick the best one for the job. Kotlin is a) not some fad b) objectively better than Java for pretty much every imaginable use case. Kotlin avoids entire ca…

As a mature professional who stopped counting learned programming languages and frameworks long ago (I’m familiar with Kotlin too), I can tell you that Java is a modern tool by all measures. It may lack some features of other languages and platforms, but it is not features what defines relevance for modern applications. Your advocacy is important, we of course need progress and testing new concepts. Yet what ultimately matters is business value and user experience. Java is pretty good in delivering it and many professionals choose it for that reason, leaving new stuff to pet projects at home. It is not diehard conservatism that lets us make this choice, but a mere pragmatism. For me it is not obvious that Kotlin is better. There are risks associated with less mature platform that already costed one of my teams a couple of wasted sprints. Productivity and quality impact isn’t really noticeable (the biggest factor in those two measures is always communication, not tools).

Re: Java 21 makes me like Java again

#474

Post by orra »

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)

But async/await is special syntax. I agree it's a nice improvement over using Task APIs directly.

Re: Java 21 makes me like Java again

#475

Post by kaba0 »

romanovcode wrote: post #464
kaba0 wrote: post #407

Earlier quoted context omitted.

It’s almost like there is even a CS law for this exact scenario.. but Java 8 will be around and will still work 10 years from now, plus it is not an insurmountable task to bump it up to the latest version at all. Tell me literally any platform that has a better backwards compatibility story, because honest to God there is simply absolutely none.

Java 8 will be out of support in 7 years. It might seem like a lot but for enterprise systems it's nothing.

Which gives you a lifetime support of 16 years for a single version, with an absolutely sane and doable upgrade path.

Re: Java 21 makes me like Java again

#476

Post by kaba0 »

ashishb wrote: post #469
pjmlp wrote: post #465

Earlier quoted context omitted.

Hence my 2nd and 3rd points. Also DNS uses dynamic linking unless configured otherwise, while being OS specific, then that are the libraries that rely on cgo.

Yeah, you can list 100 such cases. Let me tell you the most common scenario. I have a fairly popular FOSS CLI tool written in Python. I cannot use the features from the latest version of Python or else I will alienate ~50% of the userbase. This problem does not exist with Rust or Go. This problem would have existed for Java on Android except Google took the burden of "desugaring" the Java 17 code -> Java 8 compatible…

Google dug their own grave here, Java is as backwards and forward compatible as it gets.

Re: Java 21 makes me like Java again

#477

Post by nvm0n2 »

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…

There is jpackage and jlink, which don't do single files but make single directory apps.

These days there's also GraalVM native image which does produce Go-like results. But with everyone using Docker on the server anyway it doesn't matter anymore. People who talk about single binaries are confusing to me. What are you doing where shipping one file is so much simpler than shipping a container?

Re: Java 21 makes me like Java again

#478

Post by wice »

threeseed wrote: post #174
xxs wrote: post #50

Earlier quoted context omitted.

Java sort of suck for microservices (microservices suck on their own) as it has relatively high bootstrap cost. High allocation rate feels weird with micro services - I suppose that depends a lot on the coding style. G1GC is meant for generally large setups, with several cores at least. E.g. the default setup of 2048 areas on 2GB heap means, allocations over 1MB require special care.

If you GraalVM Native Image or one of the frameworks based on it then bootstrap cost disappears: https://quarkus.io

GraalVm is great, it made our Spring REST API app go from 10+ seconds to 0.5 seconds on startup (not to mention the lower mem and cpu requirements).

Except… when we try to build it with Jenkins on a Kubernetes cluster, this happens: https://github.com/oracle/graal/issues/7182

Re: Java 21 makes me like Java again

#479

Post by paradite »

caskstrength wrote: post #382
paradite wrote: post #287

Earlier quoted context omitted.

You mentioned "distribute software" but did not consider Electron for Node. You can make an Electron app with JavaScript and ship the binary (or installer) on any platform. It's not a single executable file, but the user experience is the same. I don't think there's an equivalent in Go that allows you build a desktop app like that (with frontend and backend both written in Go)?

> You mentioned "distribute software" but did not consider Electron for Node. Sorry for the snark, but users will undoubtedly be very grateful to them for not considering Electron.

I'm not so sure if the users of VS Code, Discord, Slack, etc would agree.

Yes it's bulky and sometimes slow, but it offers a lot of features and allow developers to ship features and updates really fast, while only needing one codebase for all platform.

Re: Java 21 makes me like Java again

#480

Post by kaba0 »

javcasas wrote: post #438
hota_mazi wrote: post #248

Earlier quoted context omitted.

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…

> Java (and preferably Kotlin) are a lot more serious about making sure your code is robust before it compiles. You are making great points for Rust, Ocaml and Haskell.

There isn't all that many plus in their type systems that is not expressible in Java. OCaml and Haskell has Monads, sure. There is Scala for that on the JVM.
Post reply on HN