Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency • Hacker News Board

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#381

Post by jayd16 » Wed, Apr 12, 2023, 1:59 PM UTC

kabes wrote: post #176

TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 fo…

Don't use ambiguous dependencies and you won't need to flush your cache to get a newer version.

I would say the culture is not an issue of Java but of popularity. If Go became the shovelware language of choice, you'd see a lot more bad Go.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#382

Post by noisy_boy » Wed, Apr 12, 2023, 2:02 PM UTC

doctor_eval wrote: post #336

jeroenhd wrote: post #43

Earlier quoted context omitted.

I think Java is an ugly language riddled with roundabout ways of implementing modern features, but I can't fathom why anyone would pick Go over Java. It's slightly worse in almost every way other than writing shell scripts or massively parallel workloads from scratch. In my experience, Java's problem is the same as C++'s when Java began to take over: you usually encounter it in projects stuck at ancient runtime versi…

I wrote Java code for 20+ years and I can tell you exactly why I prefer Go: it produces native binaries. I mean, it’s also less verbose, easier to start a new project, faster to startup, has far fewer configuration knobs, has native dependency management, is far easier to build CI/CD for, compiles more quickly, has very few NPEs gotchas, has value types, and avoids idiomatic boilerplate. Go is far from perfect, but i…

> I mean, it’s also less verbose

Are we talking about the same language? Or maybe you consider writing "if err != nil" every few seconds as good exercise for your fingers...

I think we shouldn't point fingers at Java when it comes to Go's verbosity.

I can simply do dict.contains("foo") in Java vs having to go through a verbose hoop:

    if val, ok := dict["foo"]; ok {
        //do something here
    }

Common operations like filtering/transforming collections are very concise in Java - I'm certain doing so in Go will be a bunch of more boilerpate:

    collection.stream().filter(...).map(...).collect(...)

Don't get me started on having to go through iota hoops to declare enums.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#383

Post by kaba0 » Wed, Apr 12, 2023, 2:03 PM UTC

layer8 wrote: post #333

lenkite wrote: post #182

Earlier quoted context omitted.

If you wish to avoid JRE, you can use Graal VM and compile to native AOT executables. Just takes a few minutes to download and play-around. (Even timed it with another Java disbeliever here on HN) https://www.graalvm.org/latest/reference-manual/native-image...

You can’t use anything reflection-based I think.

You can, you just have to have a config file that lists files that might get reflected upon.

This is available for some of the more common libraries (there is definitely more work to do here), and you can also use an agent, run your code on a regular JVM and it will collect the runtime accesses and create that config file for you.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#384

Post by jayd16 » Wed, Apr 12, 2023, 2:04 PM UTC

rakoo wrote: post #212

TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

> So with this, the last thing Go had going for it over Java is gone, right? Go still has composition over inheritance, which is vastly more flexible. Go favors explicit (verbose copy-paste, redundancy, use stdlib first, libraries second) over implicit (magic annotations, frameworks everywhere) and I like when I can understand what's happening without holding 10 files in my brain context. Go's memory usage doesn't tr…

How does a language favor copy/pasting? Do you mean it makes code reuse harder?

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#385

Post by layer8 » Wed, Apr 12, 2023, 2:05 PM UTC

royjacobs wrote: post #377

layer8 wrote: post #317

> However, due to the large number of virtual threads that can be created, developers should use thread-local variables with caution. What is the problem here? Just the per-virtual-thread memory consumption by the variable when it is used (which would be expected)?

Typically ThreadLocals are used whenever something is costly to initialize per-request. The rule of thumb is usually: you might want to use some heavy object without locking, so you stick into a ThreadLocal. However, if suddenly you have a million threads then this optimization doesn't work anymore. Sure, the concept of ThreadLocal still works, but in practice you'll end up creating a million of these heavy objects -…

Expensive to initialize doesn’t imply large. And wanting to avoid expensive initialization (runtime) is orthogonal to wanting to avoid a larger memory footprint. So I don’t quite buy your argument.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#386

Post by jayd16 » Wed, Apr 12, 2023, 2:06 PM UTC

DaiPlusPlus wrote: post #49

pharmakom wrote: post #31

Earlier quoted context omitted.

C# already had all the advantages of Go (more or less) and more, yet Go is still growing. This has nothing to do with the technical capabilities of the languages.

C# doesn’t really have an equivalent for Go’s channels syntax though. Also, Go doesn’t have inheritance, but does have interface forwarding and structural (as opposed to nominative) type-system - those both very significant factors that influence final program design.

Go literally has a Channel class with the same functionality. The major difference is async/await syntax vs goroutine syntax, no?

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#387

Post by kaba0 » Wed, Apr 12, 2023, 2:06 PM UTC

datadeft wrote: post #334

lenkite wrote: post #191

Earlier quoted context omitted.

"..and the amount of effort needed to produce a single binary." A couple of minutes ? Even timed this with another HN Java disbeliever who said its too much effort.

I understand that you mastered producing a single binary with your favorite build tool. In my experience if a language does not have an official way to build projects it does end well. Go, Rust and Zig are the prime example that a language should not be separated from its build system. How to produce a single binary: go build cargo build zig build ... org.apache.maven.plugins maven-shade-plugin 3.4.1 package shade cl…

Yes, one is a command line command, the other is a part of a build description file, so false equivalents.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#388

Post by jayd16 » Wed, Apr 12, 2023, 2:13 PM UTC

fear91 wrote: post #86

pharmakom wrote: post #31

Earlier quoted context omitted.

C# already had all the advantages of Go (more or less) and more, yet Go is still growing. This has nothing to do with the technical capabilities of the languages.

Writing everyday code, Go compiled binaries are on average more performant than C#.

Not really true.

...but the .NET runtime has a higher memory floor. It's a lot easier to write very small apps in Go. New versions are working on stripping in AOT builds but it's still very much a work in progress

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#389

Post by jayd16 » Wed, Apr 12, 2023, 2:14 PM UTC

kaba0 wrote: post #371

jayd16 wrote: post #367

Earlier quoted context omitted.

They added the structured concurrency package because you still need some kind of async framework for concurrency. Maybe the confusion is just the term "framework" as opposed to API? I don't mean a third party library is needed. The built in JDK alone is sufficient but you're still juggling promises/futures and the like.

You don’t really need anything, they just make forking and subsequent joining+exception handling easier. You can just use the decades old thread api over virtual threads as is if you wish, but this “structured concurrency” concept, similar to goto vs structured control flow will make it much more productive and easier to reason about.

Also true, but "use the decades old thread api" shouldn't count as a simplification, right?

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#390

Post by avodonosov » Wed, Apr 12, 2023, 2:14 PM UTC

Rapzid wrote: post #205

avodonosov wrote: post #185

Earlier quoted context omitted.

In javascript the analogue is async / await, only without the need to manually mark code "async"

If you want to return a future you'll need to note that in the return type.

It's not about feature / promise return types. Consider:

    int someFunc() {
      doA();
      doB();
      byte data[] = readFromSocket();
      return doC(data);
    }

    int callerFunc() {
      doX();
      System.out.println(someFunc());
      doY(); 
    }

when we invoke the callerFunc() in a virtual thread, it executes till the potentially blocking socket reading, creates a callback or future -like object containing doC(), System.out.println(), doY() - such object is called a "continuation", see "continuation passing style". Then the socket reading is iniitated in an async way, with continuation registered as a callback to be invoked upon completion. Then the native OS thread is freed to do any other work.

In javascript approach we would need to manually mark some places `async` and use `await`.

    @async 
    int someFunc() {
      doA();
      doB();
      byte[] data = await readFromSocket();
      return doC(data);
    }

    @async
    int callerFunc() {
      doX();
      System.out.println(await someFunc());
      doY(); 
    }

So async / await is a poor man's continuation passing style. The need to differentiate between 'async' and non 'async' code makes it more difficult to refactor or mix code between 'async' and non 'async' domains.

Some people argue that it's better to have the explicit distinction. I personally don't see benefits of this.