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

Don’t call it a comeback: Java is still champ

github.com

Post reply on HN
Print view View original

431–440 of 557 posts

Re: Don’t call it a comeback: Java is still champ

#431

Post by vizzier »

cutler wrote: post #414
afhammad wrote: post #335

Earlier quoted context omitted.

You will also find Clojure just as refreshing / enlightening. My company uses Elixir but I’ve also done a lot of Clojure, give it a shot if you haven’t.

Seconded. Clojure was a real turning point for me but be warned - once you have the veil lifted re OOP you'll not want to work with Java/C# ever again.

I feel this so much, been working with F# in some sub projects. C# is hard to go back to. Though Microsoft's route of stealing wholesale from the former is making it gradually more palatable.

Re: Don’t call it a comeback: Java is still champ

#432

Post by wiradikusuma »

stiray wrote: post #59
bullen wrote: post #27

The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…

https://go.dev Experienced C developers have switched to it. Actually it gets even better, they are extremely productive in it. Don't trust me, check github. I wonder why. /s

It's two letters shorter. We programmers too lazy typing long variable names.

Re: Don’t call it a comeback: Java is still champ

#433

Post by [deleted] »

hackerlight wrote: post #410
_gabe_ wrote: post #151

Earlier quoted context omitted.

> Not as fast as C++ at sub 5 micros. Try sub 5 nanos. I was curious awhile ago at how fast C++ hash set lookup was compared to C#, and it consistently performed a lookup at 1 nanosecond. I tested with up to 6GB of data and then stopped because it was taking longer to generate random data then it was to run the benchmark 10,000 times. C++ benchmarks here[0]. It's a bit more complicated then just a pure lookup since I…

I'm talking about an end to end HFT system in C++.

[deleted]

Re: Don’t call it a comeback: Java is still champ

#434

Post by cutler »

Here's a typical example of the pain of Java language evolution. As an ex-Perl developer and frequent user of Ruby and Python I am accustomed to being able to write a regex without having to escape metacharacters such as \d (digit) and \w (word character) as is necessary in Java where regular expressions are merely strings fed into the Pattern.compile() method. So imagine my elation when I discovered that raw string literals were being previewed in Java 13. Then imagine my horror when I discovered that regex metacharacters somehow missed the party and STILL had to be escaped inside raw string literals. WTF!?

Re: Don’t call it a comeback: Java is still champ

#435

Post by cutler »

baldfat wrote: post #261
falcolas wrote: post #5

Java's adequate. It's like a Toyota Corolla (insert your boring car of choice here if you don't feel this one works for the analogy). Not the prettiest, not the fastest, not the most efficient. But it gets you from point A to point B with little fuss or muss. I totally get why companies adopt and standardize on it. Do I use it for personal projects? Nope. Because it's not fun to "drive". For that, I pick the equivale…

I personally use Racket (Lispish) just because it is so much fun to build whatever I want and customize it. It just feels good to have my small projects just fit me perfectly.

What's the relevance with respect to Java, though, which is designed for managing projects in large teams?

Re: Don’t call it a comeback: Java is still champ

#436

Post by andrekandre »

haspok wrote: post #173
lliamander wrote: post #133

Earlier quoted context omitted.

Erlang is not as peformant as Java, but there are plenty of reasons to prefer the former to the latter: - a much better concurrency model, that gets you parallelism for free just by adding cores - no global gc pauses, low-latency - fantastic operational tools (trace debugging, remote shell, etc.) - Erlang/OTP gives you great middleware out of the box, including including queues, pub-sub, service monitoring, database,…

All that said, Erlang is a very sharp knife, built for one specific purpose. This is just not true: "a much better concurrency model" If your program is CPU-bound, where real threads are king, then Erlang is a pretty poor solution. Because you cannot have real threads in Erlang, even if you wanted to. Number crunching or string processing are not its forte. Also, most enterprise software does not really benefit from…

  > CSPs, for example, which in many ways are superior to actors
how is csp superior to actors?

Re: Don’t call it a comeback: Java is still champ

#437

Post by wildrhythms »

treis wrote: post #101
sabareesh wrote: post #21

Earlier quoted context omitted.

Weird Spring is the reason why i am sticking to Java

I just can't get past annotations as a thing. Seems like a crime against programming to me.

Agreed. I hate digging through a mountain of annotations to try and decipher what additional side effects some method might have (additional to any existing side effects). I have never seen a codebase where annotations were some necessary compromise; I feel like whatever crucial parameters is being passed through an annotation could have just as easily been put into the arguments and made a part of the method signature like they're supposed to be. Annotations were a mistake.

Re: Don’t call it a comeback: Java is still champ

#438

Post by kentonv »

kelnos wrote: post #430
kaba0 wrote: post #404

Earlier quoted context omitted.

Finalizers are deprecated (though are still used of course in existing programs), so just a heads up: Cleaner API is the replacement

Sure, I mean, finalizers have been deprecated as long as I can remember. But -- as you say -- they still work, and I expect will continue to work for quite a while. And, as you suggest, probably forever for existing bytecode that targets older JVM versions.

I do very much appreciate that "deprecated" in Java only means "there's a better way to do this" and absolutely does not mean "this will go away". Serious platforms never break backwards compatibility.

Re: Don’t call it a comeback: Java is still champ

#439

Post by chii »

skybrian wrote: post #163
falcolas wrote: post #5

Java's adequate. It's like a Toyota Corolla (insert your boring car of choice here if you don't feel this one works for the analogy). Not the prettiest, not the fastest, not the most efficient. But it gets you from point A to point B with little fuss or muss. I totally get why companies adopt and standardize on it. Do I use it for personal projects? Nope. Because it's not fun to "drive". For that, I pick the equivale…

I wouldn’t use Java again because I am done dealing with the brokenness of Maven and Gradle. They are the opposite of “little fuss and muss.” The Go build tools fit your analogy better.

> dealing with the brokenness of Maven

people shit on maven, but i say it's much better than many other built tooling - npm, make, or custom scripts.

The only thing need getting used to is that you cannot and should not stray from the maven model - fit your project's built into the maven model, rather than try to twist maven to do your bidding.

Re: Don’t call it a comeback: Java is still champ

#440

Post by javcasas »

gavinray wrote: post #348
dunefox wrote: post #302

Earlier quoted context omitted.

This is destructuring but not pattern matching.

How is this not pattern matching? In Scala, I would write: enum Expr: case INT(value: Int) case ADD(left: Expr, right: Expr) case MULT(left, Expr, right: Expr) def eval(e: Expr): Int = e match case INT(value) => value case ADD(l, r) => eval(l) + eval(r) case MULT(l, r) => eval(l) + eval(r) This "match" syntax is the example given in the Scala docs for Pattern Matching: https://docs.scala-lang.org/tour/pattern-matchin…

Can you pattern match deeply? Can you make a case for ADD where the first param is a MULT with the second param of the MULT being INT(5)?
Post reply on HN