`Executors.newVirtualThreadPerTaskExecutor()`. Java verbosity is alive and well.
Yeah that part is not great. OTOH, I know exactly what it does :)
Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
221–230 of 555 posts
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#222`Executors.newVirtualThreadPerTaskExecutor()`. Java verbosity is alive and well.
Any other naming here would be worse.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#223Earlier quoted context omitted.
Have you seen the two languages, like.. ever? I’m sorry for the harsh language, but Go is literally much much more verbose than java, and not just recent Java that has since improved, even Java 8.
Citation needed; first off, verbosity is not the problem, verbosity is NEVER the problem; any significant codebase will end up with millions of LOC (and tokens) regardless of language choice. Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything. Third, it depends. You can set up a HTTP server in two or…
To be clear, you think this (using the web server built into the JDK):
HttpServer server = HttpServer.create(new InetSocketAddress(8000), 0);
server.createContext("/test", http -> http.sendResponseHeaders(200, -1));
server.start();
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#224`Executors.newVirtualThreadPerTaskExecutor()`. Java verbosity is alive and well.
[deleted]
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#225So 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…
A few counterpoints:
- Modern Java requires heavy use of Decorators
- JSON handling is tiresome
- As soon as you are using Spring you aren't actually coding Java anymore
- Many mature libraries have dated APIs
- Similar functionality is often implemented multiple times in multiple different libraries. Can be confusing if you start out.
- Java requires a well configure IDE
- However, IDE Support won't matter in a year or two when we have IDE integrated AI support
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#226While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: ht…
You can even use a million native threads without an issue on Linux. But unless they are mostly idle you probably won't be able to serve a million concurrent clients, wether you use threads or not.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#227Earlier quoted context omitted.
I started with Java and I will most likely never go back. I mainly use Go now. People want to learn/write Go. It's hard to find anyone that wants to learn/write Java. People probably prefer Kotlin over Java today. It's a much better language and you can keep using JVM libraries. Go is very simple language that is just as powerful as Java, if not more powerful due to not having to rely on the JVM. That's why it's so p…
It’s not hard to find people who want to write Java. I do it all the time. We have been hiring and writing Java code for fifteen years and have not seen a decline in the interest.
I'm not talking about people that have been writing Java for years. I'm talking about new programmers. If you asked a new programmer out of college which job they would rather have I job programming Go applications or Java. I would bet 90% of them would pick Go.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#228Earlier quoted context omitted.
As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 fo…
> I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder. I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a conf…
> m2 is just a cache, it has pretty much zero impact on whether your stuff will build
Well… the cache can be broken. I’m not a Java dev so have no horse in this race but “it’s just a cache” doesn’t mean “it can’t ever be a problem”
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#229So 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…
It would be great to have a language that is a love child of Erlang and Rust. All I need is: repl, message passing, actor model, lightweight-threads and strong types. :)
Are you looking for pony (https://www.ponylang.io/discover/#what-is-pony) ? Never tried it, but it does have actors, reference capabilities (in short, "who can get this piece of memory and what can they do with it") but sadly no repl. There is a playground though (https://playground.ponylang.io/).
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#230Earlier quoted context omitted.
Have you seen the two languages, like.. ever? I’m sorry for the harsh language, but Go is literally much much more verbose than java, and not just recent Java that has since improved, even Java 8.
Citation needed; first off, verbosity is not the problem, verbosity is NEVER the problem; any significant codebase will end up with millions of LOC (and tokens) regardless of language choice. Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything. Third, it depends. You can set up a HTTP server in two or…
"Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything."
I have always wondered why Java is hammered for this while Apple is celebrated for this.
CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications(allocator:sourceDescription:metadataSpecifications:formatDescriptionOut:)