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

141–150 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#141

Post by ender341341 »

britch wrote: post #111
bagels wrote: post #30

Earlier quoted context omitted.

I love this solution. Now you have two kinds of nulls.

I disagree. The problem with Null in my opinion is that it is the default and can easily be created accidentally. There's nothing inherently wrong with an "absence of value, value" Optional.empty is not null, it's no-value

But java has the worst of both worlds cause with an optional you now have 3 cases, Optional.empty, !Optional.empty, & null instead of just 2 cases.

In our code base this means we have a the rule that Optional is only allowed for returns so we aren't adding 3rd cases all over the place.

Re: Retrofitting null-safety onto Java at Meta

#142

Post by eternalban »

Retric wrote: post #137
pron wrote: post #113

Earlier quoted context omitted.

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…

I know vastly more programmers that have abandoned Java than swapped to it. That’s not to say it failed. Java is one of the most popular languages, but it does suggest real issues with the current approach.

I think you are jumping to your desired conclusion here. Even if we take your vastly at face value, there are so many reasons people switch languages, and problematic language evolution is not the only possible reason.

Re: Retrofitting null-safety onto Java at Meta

#143

Post by krzyk »

islon wrote: post #110
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 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.

Re: Retrofitting null-safety onto Java at Meta

#144

Post by krzyk »

ender341341 wrote: post #141
britch wrote: post #111

Earlier quoted context omitted.

I disagree. The problem with Null in my opinion is that it is the default and can easily be created accidentally. There's nothing inherently wrong with an "absence of value, value" Optional.empty is not null, it's no-value

But java has the worst of both worlds cause with an optional you now have 3 cases, Optional.empty, !Optional.empty, & null instead of just 2 cases. In our code base this means we have a the rule that Optional is only allowed for returns so we aren't adding 3rd cases all over the place.

I have never came up to a code that would pass null in place of Optional, why?

Re: Retrofitting null-safety onto Java at Meta

#145

Post by krzyk »

melling wrote: post #40
sanedigital wrote: post #24

Earlier quoted context omitted.

Don't people use @NonNull everywhere now? It's been a few years since I've programmed in Java but even then I feel like that was common practice.

“Unannotated types are considered not-nullable” Defaulting to not-nullable is a great idea. Much less boilerplate.

Depends on code base, at the beginning you would prefer the opposite, (not annotated are nullable).

Re: Retrofitting null-safety onto Java at Meta

#146

Post by StevePerkins »

hn_throwaway_99 wrote: post #117
pron wrote: post #31

Earlier quoted context omitted.

What do you mean by had a chance? That chance isn't gone. This area is under investigation, and when we have a solution we like, we'll implement it. We can't address all issues at once. Optional isn't half-assed because it was never envisioned as a general solution to the null problem. It's simply an interface that's useful in streams and other similar cases for method return values, and it does the job it was intend…

I have definitely come to the conclusion, especially after doing a lot of work in Typescript, that class Optional is a big mistake, whether from the JDK or other libraries that preceded it. First, because exactly the type of code that the parent commenter showed. I've actually seen this in production code (and shrieked). The fact is that without language-level support, you can end up getting the worst of all worlds.…

I miss the pre-Rust days. When Haskell was HN's cool pet language, and you had to obtain at least some vague familiarity with the term "monad" to understand half the discussion threads here.

I'm sorry, but I don't think you understand the purpose that "Optional" was intended to serve. And are unduly dismissive simply because it does not serve some larger purpose that was not intended.

Re: Retrofitting null-safety onto Java at Meta

#147

Post by krzyk »

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.

OK, so when valhalla lands I assume Optional will become value type (or we will have another class for that, to avoid issues with backward compatibility)

Re: Retrofitting null-safety onto Java at Meta

#148

Post by RedNifre »

Oh yeah, I wrote one of those, too, complete with safe navigation through type aligned sequences etc. https://github.com/cosee/null4j

If I were still writing Java I would throw in some exception throw/catching based Haskell style do notation for binding nullables, i.e.

  var nullableResult = nullable(() -> {
    var a = bind(getNullableA());
    var b = bind(getNullableB());

    doSomethingRequiringBothNotBeingNull(a,b);
  });
In my experience, Java developers don't want null safety though (the ones that do switched to Kotlin anyway).

Re: Retrofitting null-safety onto Java at Meta

#149

Post by ben7799 »

Traubenfuchs wrote: post #69

I have been writing Java for money for more than ten years and never ever have I had non-trivial problems with null. Less than one percent of the bugs I fixed were caused by nullpointers, less than one percent of write-deploy-test loops were caused by it. I either have code that can't be null (e.g. getters of lists that create a list if the field is null, outright validation before usage), code where null has a desir…

Way too many developers are lazy and haven't actually studied the language they're using to adapt their code. So instead you get discussions where the tools are blamed.

Obviously there are a lot of lazy/bad developers and the larger the company/team the more likely you have some of them. The irony is when this comes up in discussions about places like Google and Facebook that have built up a cult of believing they are better than everyone else while seemingly having lots of trouble dealing with these kinds of issues.

I don't hate Optional, but what I find is the same people who can't handle using null also fall into the Optional anti-patterns.

Re: Retrofitting null-safety onto Java at Meta

#150

Post by krzyk »

driggs wrote: post #21

It's so sad that Java 8 had the chance to really fix the null problem, but gave us only the half-assed `java.util.Optional `. Rather than implementing optional values at the language level, it's just another class tossed into the JRE. This is perfectly legal code, where the optional wrapper itself is null: Optional getMiddleName() { return null; }

One can abuse everything, but should one? (and that error should be catched by any IDE or some static analysis).

Optional are quite nice and we use it where appropriate, they play nice with streams which is a nice bonus.

Post reply on HN