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

What Future Java Might Look Like

blog.codefx.org

Post reply on HN
Print view View original

51–60 of 105 posts

Re: What Future Java Might Look Like

#51

Post by rootlocus »

dschuetz wrote: post #18
mixedCase wrote: post #14

Earlier quoted context omitted.

You're being downvoted, but really, the only saving grace in Java is the occasionally useful tooling that can't be used in the other two actually good JVM languages: Kotlin and Scala. And right now the only one I can think of is j2objc. Java should absolutely die.

Isn't this upvote-downvote thing somehow linked to confirmation bias? I'm getting downvoted for having issued an opinion which opposes that of the others? This sounds so horribly wrong to me...

> I'm getting downvoted for having issued an opinion which opposes that of the others? This sounds so horribly wrong to me...

You haven't issued an opinion. Moreover, what people mean with their downvotes is subjective. You're not on trial, and your karma doesn't affect your life in any way, so I don't see how this is "so horribly wrong".

Re: What Future Java Might Look Like

#52

Post by fauigerzigerk »

matrix wrote: post #26

While these would be welcome improvements to Java, the future of Java is not about these sorts of tweaks. What Java really needs to revitalize their ecosystem is a sustained focus on improving developer experience with modern applications. That means elevating languages like Kotlin and Clojure, and producing modern libraries for basic web development so that there's a foundation of high quality components that people…

Value types are not a tweak. They are foundational for all JVM languages and the entire ecosystem. Their importance can hardly be overstated.

Re: What Future Java Might Look Like

#53

Post by rootlocus »

unclebucknasty wrote: post #37
odabaxok wrote: post #29

Earlier quoted context omitted.

It is because you do not comment according to the guidelines, which encourage people to start conversation with reasoning etc. Points done bad in your comments: Avoid gratuitous negativity. When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." Please avoid introducing classic flamewar topics unless you have something…

> It is because you do not comment according to the guidelines, which encourage people to start conversation with reasoning Not strictly. The guidelines encourage people to start conversation with reasoning, but also encourage people to downvote for disagreeing. So, there's some dissonance in there as it says, effectively: "make well-reasoned arguments with which everyone can agree."

The guidelines aren't there to help you get upvotes. Moreover, it says nothing about how / why to downvote, much less encourage people to do so. The fact that it's ok to downvote when disagreeing is something that pg once wrote in a comment (don't have the link).

Re: What Future Java Might Look Like

#54

Post by fauigerzigerk »

cbdfghh wrote: post #46

What I would personally like (and I'm kind of surprised all projects which tried to implement it died) is a Java -> static exe/elf compiler (sort of like Go) or at least java -> exe/elf +libjava.so . I hate that deploying Java requires that everything has to be configured _exactly_ right, and write once run anywhere turns into write once debug everywhere.

IntelliJ or maven can at least create a fat runnable jar that includes all dependencies. So once you have a JVM on the target machine that jar is all you need to deploy.

But I agree with you that an entirely static compilation target that includes the JVM and excludes everything that isn't necessary would be very desirable.

Re: What Future Java Might Look Like

#55

Post by rootlocus »

dschuetz wrote: post #47
odabaxok wrote: post #29

Earlier quoted context omitted.

It is because you do not comment according to the guidelines, which encourage people to start conversation with reasoning etc. Points done bad in your comments: Avoid gratuitous negativity. When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." Please avoid introducing classic flamewar topics unless you have something…

Sounds great, really, but it didn't work once when I tried to put up well-reasoned arguments. Why would I follow guidelines any further when everyone seems to interpret them as they well damn please? So, basically 'upvote' is for the popular opinion, and it doesn't matter if it's well reasoned or not. And the 'downvote' is for preventing flame wars by suppressing the unpopular opinion, no matter if well reasoned or n…

> Sounds great, really, but it didn't work once when I tried to put up well-reasoned arguments.

I went through your comment list out of curiosity, and I have to say, your arguments weren't well-reasoned at all.

> Why would I follow guidelines any further when everyone seems to interpret them as they well damn please?

Why do you care about your karma?

Re: What Future Java Might Look Like

#56

Post by paulddraper »

sixbrx wrote: post #45
tomp wrote: post #8

Earlier quoted context omitted.

Exactly. That's the primary reason I use Scala these days - all that's good in Java (libraries, JVM) but with a much nicer surface language! The only thing that's missing, really, is fast for loops (either Java-like, or automatic optimisation when looping over things like arrays or ranges). Conversely, a major thing missing in the post above is some sort of implicits, or at least C#-like extension methods.

Is the excessive virtual dispatch still really slowing down simple for loops in Scala? I thought Paul Phillips did a special-case fix for that. That's very disappointing if that's still a problem. When I programmed in Scala, I felt like this sort of thing showed that priorities weren't quite right in the leadership somehow. For-loops are pretty basic and their performance is important - simple ones shouldn't have eve…

You can have local variables in the constructor.

The discussion you linked to shows you how.

Re: What Future Java Might Look Like

#57

Post by user5994461 »

tormeh wrote: post #12

Languages cannot get better, only bigger, without dropping backwards compatibility. This is why Java needs to die. Not because it's particularly horrible, but because we can do better now.

Or we can keep Java so the entreprisey outsourced projects use that, while the hype 3lit3 tech use something else.

That makes it easier to self select jobs and to recruit =)

A win win.

Re: What Future Java Might Look Like

#58

Post by user5994461 »

cbdfghh wrote: post #46

What I would personally like (and I'm kind of surprised all projects which tried to implement it died) is a Java -> static exe/elf compiler (sort of like Go) or at least java -> exe/elf +libjava.so . I hate that deploying Java requires that everything has to be configured _exactly_ right, and write once run anywhere turns into write once debug everywhere.

Other languages don't do much better once you start to have a few dependencies.

Re: What Future Java Might Look Like

#59

Post by sixbrx »

paulddraper wrote: post #56
sixbrx wrote: post #45

Earlier quoted context omitted.

Is the excessive virtual dispatch still really slowing down simple for loops in Scala? I thought Paul Phillips did a special-case fix for that. That's very disappointing if that's still a problem. When I programmed in Scala, I felt like this sort of thing showed that priorities weren't quite right in the leadership somehow. For-loops are pretty basic and their performance is important - simple ones shouldn't have eve…

You can have local variables in the constructor. The discussion you linked to shows you how.

Which post # in the discussion did you have in mind? There's some misdirections in that thread with ideas that didn't survive the javap test (which I think rather makes my point). I may do Scala again in the future and would like to know how to avoid this (without factory methods as I mentioned).

If you mean Paul P/extempore's self described "if you can handle a little perversion" method then - "no thanks", that's pretty bad, I'd rather just do factories.

Re: What Future Java Might Look Like

#60

Post by nradov »

xaduha wrote: post #49
nradov wrote: post #16

Earlier quoted context omitted.

By that standard every language needs to die. Or to put it another way, how long should languages be permitted to survive as we figure out better ways of doing things?

Some languages have official versions than you need to declare right at the start. As in specification version, not implementation versions.

I'm not convinced that's any better than specifying the language version as a compiler command line argument.
Post reply on HN