341–350 of 555 posts
While 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…
2. The Jetty experiment measured the wrong thing as they misunderstood the origin of the "million thread" scenario. What happens in a real application is that you have some number of threads with deep stacks servicing incoming requests -- say 50K concurrent sessions -- and then each of those fans out to, say, 19 micro services in parallel, each of those outgoing requests is done on a virtual thread with a very small stack, and that's how you get to 1M threads. I.e. when you have a high number of threads, only a small minority of them (5% in this example) have a deep stack.
3. I don't think anyone would claim anything is a silver bullet. All virtual threads do is let a server service the same throughput as asynchronous code does, but the code is much simpler and it is observable, i.e. easily debuggable and profitable, something that async code can't do.
`Executors.newVirtualThreadPerTaskExecutor()`. Java verbosity is alive and well.
Earlier quoted context omitted.
I'm not sure what you mean. Why should I settle for less performance than my hardware can deliver?
Are you writing everything with a so-called superoptimizer (because mind you, not even your hand-written assembly will be the fastest, hell, C++/Rust will likely beat it in the general case)? Because it has always been a tradeoff between programmer’s sanity-correctness-maintainability-productivity-performance, at the least. Java does very well on most of it, including performance — it will JIT compile code comparable…
Earlier quoted context omitted.
So is Apple/Swift, but Apple always gets a smile instead of a smirk here on HN. func CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications( allocator: CFAllocator?, sourceDescription: CMMetadataFormatDescription, metadataSpecifications: CFArray, formatDescriptionOut: UnsafeMutablePointer ) -> OSStatus
Wow. Where did you find that specimen?
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…
Also, how so wonderfully and utterly balanced of you to give an old-school Maven pom.xml file with the maven-shade-plugin and exclusion lists, but omit the Cargo.toml and go.mod files.
Also, its as simple in Java as:
Gradlefile:
apply plugin: 'java'
gradle build
EDIT: Ok you were asking about creating single all-in-one fatjar ? Add the below to your Gradlefile:
Gradlefile:
plugins {
id 'com.github.johnrengelman.shadow' version '8.1.1'
}
apply plugin: 'com.github.johnrengelman.shadow'
gradle shadowJarEarlier quoted context omitted.
My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.
The younger generation chose Go because they're dumb and fell for the Google marketing hype. Most of them have never even used Java outside of school.
But what would I know? I only worked in Java for 20+ years…
How is a system of virtual threads different from typical "a pool of tasks and a pool of threads to perform them on" systems like e.g. the .NET TPL?
Conceptually, these are all variations of the same thing. The difference is in how you use them and how much boiler plate you need to use them. Funnily enough, the first versions of Java did not support OS threads and only had green threads for a while. Supporting real threads was a big deal at the time as it allowed you to use more than 1 processor. Of course, processors were single core at the time and most compute…
Since Java uses very little FFI, it will benefit greatly from this automagical “no more blockingness”, of course only when there is some other available work in the meanwhile. Servers are the best fit for that.
Earlier 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…
Gradle is a better build tool from a purely architectural point of view (though it is quite disliked, I believe mostly due to the ultra-complex android build system being built on top and giving it a bad name), but the Maven repo system is absolutely better than most contemporary repositories, proved by its comparably rare side-chain attacks.
Earlier quoted context omitted.
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:formatDescriptionOu…
https://developer.apple.com/documentation/coremedia/1489454-...
"Creates a metadata format description by extending an existing description with the values you specify."
The description doesn't sound so bad...