What Future Java Might Look Like • Hacker News Board

Re: What Future Java Might Look Like

#101

Post by Roboprog » Thu, Dec 08, 2016, 4:39 PM UTC

tormeh wrote: post #73

overgard wrote: post #68

Earlier quoted context omitted.

As much as I think immutable-by-default is a good idea for code correctness, it does have a really big performance penalty since it means a LOT of GC pressure (since you have to make a lot of allocations). Side effect free is great, but, at the moment anyway you can't really do it in real time systems where a GC pause is a huge problem

A lot of those deallocations should be easy to figure out by a compiler, though. Maybe the JVM can accommodate a delete instruction? If I say list(1,2,3).par.map(x=>x*x) there's a couple of intermediate objects that can immediately be deallocated. The GC shouldn't be bothered with cases that are so obvious.

Beside generational GC, I also forgot to mention escape analysis, which sounds like what you are leading up to.

Re: What Future Java Might Look Like

#102

Post by Roboprog » Thu, Dec 08, 2016, 4:45 PM UTC

nradov wrote: post #63

Roboprog wrote: post #41

To me, most of the JVM languages have 2 similar problems with the "defaults": references are optional, rather than mandatory; objects are mutable, rather than immutable. It's past time for a language that makes it's references mandatory unless you explicitly indicate "optional" / "maybe" or whatever. Slapping "Optional " on stuff when "mandatory" isn't enforced seems to just make things worse. Similarly, classes/obje…

You can enforce most of those rules through static analysis and annotations. Of course it won't be as solid as having it in the core language specification but you can achieve most of the same benefits.

Oh, I know. @Nullable, @NonNull (@Pure/@Function - something like that ???), etc. I'd like to see a bit less clutter in Java, though.

I mean, thanks for mentioning it, but Java 1.x has really gotten out of hand in terms of unreadable logorrhea filling the screen for trivial things.

Re: What Future Java Might Look Like

#103

Post by cle » Thu, Dec 08, 2016, 7:33 PM UTC

chei0iaV wrote: post #98

cle wrote: post #96

Earlier quoted context omitted.

These existed long before Kotlin.

But was there source-level compatibility with Java?

What does that have to do with anything? My comment was mainly a protest of what appeared to be Kotlin fanboyism, which I see a lot lately on HN. There is nothing special about these features in Kotlin, they are common features in many popular languages preceding Kotlin, and have been on Java developers' radars long before Kotlin.

Re: What Future Java Might Look Like

#104

Post by chei0iaV » Thu, Dec 08, 2016, 9:28 PM UTC

cle wrote: post #103

chei0iaV wrote: post #98

Earlier quoted context omitted.

But was there source-level compatibility with Java?

What does that have to do with anything? My comment was mainly a protest of what appeared to be Kotlin fanboyism, which I see a lot lately on HN. There is nothing special about these features in Kotlin, they are common features in many popular languages preceding Kotlin, and have been on Java developers' radars long before Kotlin.

My point is that you can take an existing Java codebase, stick in a Kotlin file, and use those "future Java" features right now, in your Java project.

But the fact that those features might have existed in Haskell or Algol68 or whatever is largely irrelevant since we're taking about Java.

Re: What Future Java Might Look Like

#105

Post by voddan » Sat, Dec 17, 2016, 4:35 PM UTC

estefan wrote: post #19

bdavisx wrote: post #7

Earlier quoted context omitted.

And Kotlin as well, with java interop considered a top priority.

Is anyone actually using Kotlin outside jetbrains? Seems like it doesn't have much mindshare or any high profile projects using it.

Netflix, for example. 3/4 of all Kotlin presentations are done by people outside of JetBrains who use Kotlin at work. And there are a lot of them.