421–430 of 555 posts
Earlier quoted context omitted.
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.
Also Groovy kinda sucks
Earlier 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.
Earlier quoted context omitted.
> 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?
It favors as a culture. A little copying is better than a new dependency
Just like Java has culture to setup a single http endpoint one typically adds 50-60 little jar files of Spring Boot starter.
Earlier quoted context omitted.
> 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?
NIO solved the problems with threads on the network in Java 1.5 (seminal cornerstone API that also had the concurrency package and rewrote the entire JVM memory model), but only in 1.7 the epoll solution became stable. 2004 -> 2011, 7 years! Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. Many nuclear power plants wasted on the kernel.
> Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. Can you expand on this a little? Are you referring to the necessity to copy between kernel memory and user-space memory, or something else?
Earlier quoted context omitted.
We were talking about PL features, and now you bring up a style of writing said language (which by the way comes from very different times and is no longer the norm)? Composition over inheritance has been a mantra in Java circles for a very long time now. The important difference is for example that Go can’t have proper error handling no matter how good the developer is, due to the language not having a proper abstra…
That's a feature not a bug. Go intentionally forgoes abstractions of that sort. I personally prefer well written Java exception handling, but often Java exception handling code is a bolted on afterthought. Go's approach is to make error handling something you have to think about for virtually every line of code, rather than a superstructure built around the code. This can feel slow and painful to write, but it guides…
But that doesn’t work, and you can’t handle every error at the place of its origin.
NIO solved the problems with threads on the network in Java 1.5 (seminal cornerstone API that also had the concurrency package and rewrote the entire JVM memory model), but only in 1.7 the epoll solution became stable. 2004 -> 2011, 7 years! Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. Many nuclear power plants wasted on the kernel.
> Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. How does this work around the kernel? This lets you write java code that uses async IO but make it look nice, like golang code. But this isn't DPDK.
Bypassing the kernel. Java is already sandboxed we don't need the kernel unless the net/ssd drivers crash completely.
It's a huge task/risk, but 30% is alot.
Earlier 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.
Irrational Fear of Java is one of the most confusing things among startup stage companies.
In this case, it's an "irrational fear" of Java to have preferences beyond Java.
Earlier quoted context omitted.
> Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. How does this work around the kernel? This lets you write java code that uses async IO but make it look nice, like golang code. But this isn't DPDK.
The JDK would have access to network card and SSD directly. Bypassing the kernel. Java is already sandboxed we don't need the kernel unless the net/ssd drivers crash completely. It's a huge task/risk, but 30% is alot.
Earlier quoted context omitted.
In ALGOL it was more like a thousand dollar mistake. It didn't become a billion dollars until Java caused NPEs on 3 billion devices
Java's got like the safest most soft-punching NPEs in any language that's got them though. They're so safe you can use them as flow control devices.