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

11–20 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#11

Post by justin_oaks »

The null problem has been around a very long time. It's been a huge source of errors in programming. I'm glad to see it actively being worked on, even if it is awkwardly being retrofitted on an old language.

I can only look on with disappointment when new (or newish) languages include null as part of the language instead of doing something more sensible like having an Option/Either type. Of course, I won't name names... cough Go cough

Re: Retrofitting null-safety onto Java at Meta

#12

Post by yamtaddle »

iLoveOncall wrote: post #7
djinnandtonic wrote: post #3

Or use Kotlin, it's near perfectly interoperable with Java and the acclamation period is measured in weeks if you're a Java dev

I can't think of any popular language that would take more than a few days to get acclimated to as an experienced developer, so that's not a very compelling argument.

It's always the (usually quite bad) tooling, learning about platform/SDK shittiness and pitfalls, and figuring out which parts of the open-source library ecosystem you want to engage with, that takes like 90+% of the time getting decent with a new language, in my experience. Getting comfortable with the language per se takes low tens of hours at most, as you wrote.

Re: Retrofitting null-safety onto Java at Meta

#13

Post by anyonecancode »

djinnandtonic wrote: post #3

Or use Kotlin, it's near perfectly interoperable with Java and the acclamation period is measured in weeks if you're a Java dev

> the acclamation period is measured in weeks

Ah, "acclimation" -- thought at first you were saying that Java devs love it for a few weeks and then hate it lol.

Re: Retrofitting null-safety onto Java at Meta

#14

Post by mhoad »

pjc50 wrote: post #4

Related work: https://devblogs.microsoft.com/dotnet/nullable-reference-typ... C# has made it possible to gradually roll out stricter nullability checking as well. The static analysis gets integrated into the regular language analyzers. Incremental migration is the only way to go.

In a similar fashion I was extremely impressed with how Dart approaches this as well and was able to move the entire ecosystem along in about 18 months. https://dart.dev/null-safety

Re: Retrofitting null-safety onto Java at Meta

#15

Post by twawaaay »

revskill wrote: post #8

OK, then i realize GoF design patterns lack the single most important pattern: Option data structure.

Nobody ever claimed that GoF is a complete set of patterns. It is just a subset of patterns from infinite variety of possible solutions to problems.

Re: Retrofitting null-safety onto Java at Meta

#16

Post by mdaniel »

pjc50 wrote: post #5
djinnandtonic wrote: post #3

Or use Kotlin, it's near perfectly interoperable with Java and the acclamation period is measured in weeks if you're a Java dev

As they point out, they already have some Kotlin and use it interoperably, but "rewrite existing code in Kotlin" is not a realistic demand.

My experience has been that "migrate on touch" is a reasonable strategy, so if you have to make a change to a file, use the "Code > Convert Java to Kotlin" (control-alt-shift-k)

Re: Retrofitting null-safety onto Java at Meta

#17

Post by endtime »

mhoad wrote: post #14
pjc50 wrote: post #4

Related work: https://devblogs.microsoft.com/dotnet/nullable-reference-typ... C# has made it possible to gradually roll out stricter nullability checking as well. The static analysis gets integrated into the regular language analyzers. Incremental migration is the only way to go.

In a similar fashion I was extremely impressed with how Dart approaches this as well and was able to move the entire ecosystem along in about 18 months. https://dart.dev/null-safety

Yeah, I did a bit of Dart null safety migration work at Google and I thought they did a good job. (The auto migration tool sometimes made things nullable unnecessarily, and so you had to carefully review its output, but you could always just not use the tool.)

Re: Retrofitting null-safety onto Java at Meta

#18

Post by exabrial »

This is just covering up design problems. NPEs show you were you have design deficiencies.

If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"

Re: Retrofitting null-safety onto Java at Meta

#20

Post by afandian »

iLoveOncall wrote: post #7
djinnandtonic wrote: post #3

Or use Kotlin, it's near perfectly interoperable with Java and the acclamation period is measured in weeks if you're a Java dev

I can't think of any popular language that would take more than a few days to get acclimated to as an experienced developer, so that's not a very compelling argument.

I can't think of many other languages that will compile into a Java codebase, and be interoprable in both directions, as well as Kotlin. It's a lot quicker to pick up than e.g. Scala IMHO.
Post reply on HN