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

Retrofitting null-safety onto Java at Meta

engineering.fb.com

Post reply on HN
Print view View original

161–170 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#161

Post by pharmakom »

pjmlp wrote: post #125
tehlike wrote: post #112

Earlier quoted context omitted.

"Java generics is superior to C#" - That's a first for me. C# generics don't have to do boxing of types like java does, and overall have much better type safety between library boundaries, etc...

The guys from Scala.NET did mention .NET generics as one of the reasons they gave up on porting Scala to .NET. That is also a reason why .NET needed the whole effort to create DLR and the dynamic keyword, while Java only needed to add one additional bytecode invokedynamic.

.NET has F# and Clojure so not convinced by this

Re: Retrofitting null-safety onto Java at Meta

#162

Post by Nullabillity »

pron wrote: post #109
BoorishBears wrote: post #99

Earlier quoted context omitted.

Can you point a couple of cases where Java got a better version? Generics? Value Types? Lambdas? Null Safety? Async/Await? Also do you just have to assign all the value the features provide in interim 0 value? Like Async/Await has provided a 10 years of value, and I'm guessing you mean Project Loom... so how much better than Async/Await does Loom have to be to justify an entire decade of just straight up missing the…

I can! Generics, virtual threads, and records. Java is unburdened with the prevalent and obsolete features of async/await, properties, and its generics allow a flourishing ecosystem in exchange for a minor inconvenience.

.NET's async is far from great, but Loom/vthreads is an impressive achievement in distilling all of the mistakes that .NET made, while learning from none of the good ideas that it (or future promise/async/await) had.

Re: Retrofitting null-safety onto Java at Meta

#163

Post by jayd16 »

pron wrote: post #113
jayd16 wrote: post #105

Earlier quoted context omitted.

I'd rather have the decade of increased productivity.

Increased productivity comes in various ways. A more popular language often has a better ecosystem that helps productivity, and adding lots of language features quickly is a hindrance to huge popularity. This might not be the case for many here, but most programmers prefer fewer features than more, and the most popular languages are also often those that can be taught as a first language, which also requires restrain…

What is this argument exactly? We're arguing against the concept of features? Why are we talking hypothetically?

Async/await provides immediate user value. If people didn't like it they could just use threads in a Java-like style. While some dislike the features, and other push against the sour grapes, its a popular feature found in many languages used by many developers.

Java is popular and so is C# and Javascript, so I can't see how we can draw any conclusions on async/await.

Re: Retrofitting null-safety onto Java at Meta

#164

Post by guelo »

csunbird wrote: post #82
mrkeen wrote: post #32

Earlier quoted context omitted.

Yes, it's always been possible to check for nulls at runtime. Personally I use notNull(..) over @NonNull since it actually fires when you expect it to (as opposed to whether your framework dispatcher interceptor trigger decided to invoke it)

isn't @NonNull just a syntactic sugar for adding checkNonNull() call as first statement to the function declaration in compile time, or am I mistaken? Just like lombok, it is supposed to generate code that checks null arguments, from what I know.

@Nullable/@NotNull is great when the IDE shows the warnings, basically dev time checking. There are also tools to integrate it into your builds for compile time checking.

Re: Retrofitting null-safety onto Java at Meta

#165

Post by dheera »

masklinn wrote: post #119
dheera wrote: post #94

Earlier quoted context omitted.

I'm not a Java person but isn't this just very similar to std::optional in C++? https://en.cppreference.com/w/cpp/utility/optional

No, because in C++ bare types are not nullable. In java, reference types are nullable, Optional being a reference type, Optional can be null, Empty, or have a value, whereas T can be null or have a value. Also because std::optional does essentially the opposite. It’s a more efficient _ptr rather than a safer one. Optional is strictly less efficient as it implies an additional allocation.

> Optional can be null, Empty, or have a value, whereas T can be null or have a value

Thanks for the explanation. Wow, this sounds like a a bit of a mess, one because of the allocation, and also because it seems there are multiple ways something can be semantically null.

Re: Retrofitting null-safety onto Java at Meta

#167

Post by mrkeen »

guelo wrote: post #164
csunbird wrote: post #82

Earlier quoted context omitted.

isn't @NonNull just a syntactic sugar for adding checkNonNull() call as first statement to the function declaration in compile time, or am I mistaken? Just like lombok, it is supposed to generate code that checks null arguments, from what I know.

@Nullable/@NotNull is great when the IDE shows the warnings, basically dev time checking. There are also tools to integrate it into your builds for compile time checking.

I get a little green tick in the top right of my IDE window with the following:

    @Test
    public void foo() {
        final Map map = new HashMap();
        map.put("present", 1);
        bar(map.get("missing"));
    }

    void bar(@NotNull Integer param) {
        System.out.println(param);
    }
"No problems found"

Re: Retrofitting null-safety onto Java at Meta

#168

Post by pharmakom »

krzyk wrote: post #143
islon wrote: post #110

Earlier quoted context omitted.

I guess he's talking about project loom (fibers, go style concurrency) which IMHO is a much better solution than async/await, but yeah... took some 10 years to arrive.

And saved millions of developer minds not having to deal with mind bending async/await. Thanks, I prefer to wait.

Do-notation is much simpler than callback hell

Re: Retrofitting null-safety onto Java at Meta

#169

Post by Nullabillity »

krzyk wrote: post #143
islon wrote: post #110

Earlier quoted context omitted.

I guess he's talking about project loom (fibers, go style concurrency) which IMHO is a much better solution than async/await, but yeah... took some 10 years to arrive.

And saved millions of developer minds not having to deal with mind bending async/await. Thanks, I prefer to wait.

You could have had the Loom experience 20 years ago by just spawning OS threads. Of course, there's a reason that this was discouraged... threads quickly turn into a nightmare to manage safely, especially when they need to interact.

Re: Retrofitting null-safety onto Java at Meta

#170

Post by BoorishBears »

pron wrote: post #106
BoorishBears wrote: post #95

Earlier quoted context omitted.

It's like when people say Java had the chance to do generics right (like C#) and then didn't Yeah technically tomorrow morning Java could fix it, but there have been kingdoms built on the current situation. C# took its lumps years back on breaking things and so there were fewer kingdoms to demolish. And if you fix it, it'll be years before it trickles down to a large portion of devs who don't get to work at the bleed…

First of all, Java's generics are already superior to C#'s. We've exchanged the minor inconvenience of not being able to have overloads that erase to the same type with the ability to support multiple variance strategies rather than one that's baked into the runtime. That's why Java has Clojure and Kotlin and Scala and Ruby running on top of it with such great interop. And, as it turns out, when specialisation is rea…

> First of all, Java's generics are already superior to C#'s. We've exchanged the minor inconvenience of not being able to have overloads that erase to the same type with the ability to support multiple variance strategies rather than one that's baked into the runtime.

Working on the JDK I'm sure you're aware just how revisionist that take is: we got the version of generics that landed because of backwards compatibility concerns.

One of the key selling points going from Pizza to GJ was that the result ran on then current JVM targets without modification.

https://jcp.org/en/jsr/detail?id=14

> C1) Upward compatibility with existing code. Pre-existing code must work on the new system. This implies not only upward compatibility of the class file format, but also interoperability of old applications with parameterized versions of pre-existing libraries, in particular those used in the platform library and in standard extensions.

> C2) Upward source compatibility. It should be possible to compile essentially all existing Java language programs with the new system.

Interop came at the expense of Java (not the JVM) having a worse generics story, since the incredibly onerous constraint of "works with parameterized versions of pre-existing libraries" forced other languages to then go and reinvent the exact same wheel in different ways.

-

> We've also added virtual threads years after C# had async/await, and now they're the ones stuck with that inferior solution, which we'll remain in the ecosystem even if and when they add user-mode threads.

"Kingdoms to demolish" refers to changing generics, but there are "kingdoms" have been built that wouldn't be demolished: they still represent a lot of throwaway work from putting off attacking the problem. Case in point, the post we're commenting under.

Nullability specifically is much more subject to the part you left out: "And if you fix it, it'll be years before it trickles down to a large portion of devs who don't get to work at the bleeding edge, or even near the edge."

-

At the end of the day it's always been a tradeoff between backwards compatibility, timeliness, and correctness, but when I switch between Java specifically and C# specifically (not the JVM and the CLR) I find C# did an amazing job providing value upfront rather than hand wringing, and is not nearly as worse off for it as this comment would imply.

I mean you're looking down on async/await, but it came out a decade ago while Loom is just landing. I guess you're trying to paint that decade of development as "weighing down" whatever .NET comes out with because it'll still exist, but that seems like a stretch at best.

Java had no async/await story and will get a very good alternative. C# had an async/await story and will get an improved alternative (it's already in the experimentation stage according to the .NET team). I'd just much rather have the latter?

Post reply on HN