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

211–220 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#211

Post by Deukhoofd »

AtNightWeCode wrote: post #200
Deukhoofd wrote: post #74

Earlier quoted context omitted.

> That people will just init nonsense objects to get around the warnings. You technically can do "= null!", which means assign null by default, but assume it is not null. This is currently the recommended way to do deserialization, where you know the value is not null, but you have not explicitly filled it.

No, you get a nullable warning for that as well. You also need to change the reference type to nullable. I am convinced that some people will just init the properties with new(). And by that hide the null errors. Easily the hardest bugs to track down is when things fails long after the real error occur. I think they could have come with a better solution to the problem.

If you assign it with "= null", you get the warning. If you assign it with "= null!" (note the exclamation mark, the null-forgiving operator), you do not.

Re: Retrofitting null-safety onto Java at Meta

#212

Post by pron »

pron wrote: post #209
unscaled wrote: post #205

Earlier quoted context omitted.

> First of all, Java's generics are already superior to C#'s. That's... highly controversial to say the least. You didn't just lose the ability to overload List and List . You've also lost run-time type information and type-safety when doing reflection. And reflection-based metaprogramming cannot be ignored in Java (and to a lesser degree in Kotlin): So much is based on it! It also makes interfacing with primitives (…

> And reflection-based metaprogramming cannot be ignored in Java (and to a lesser degree in Kotlin): So much is based on it! Its prevalence has been going down, and we're trying to encourage that trend. > Allowing different variance strategies could be a boon for a language-agonstic runtime, but, as other comments mentioned, that's just rewriting history. I don't see how this matters, and I never claimed that support…

P.S.

Re "I believe we can fix that, and quite elegantly" -- I believe erasure may well come to the rescue there once again.

Re: Retrofitting null-safety onto Java at Meta

#213

Post by Retric »

pron wrote: post #206
Retric wrote: post #198

Earlier quoted context omitted.

Several languages had similar levels of dominance. Fortran was even more dominant in the late 1960’s, then C in the early 90’s followed by Java in the 2000’s all had clear dominance. It’s possible though harder to verify if Pascal reached that level and we might see Python hitting it soon.

> Several languages had similar levels of dominance. I don't think Fortran was ever quite that dominant, but we can certainly agree that no language has been as dominant since Java. > It’s possible though harder to verify if Pascal reached that level and we might see Python hitting it soon. Not even close for either one of these. I was already programming in Pascal's heyday, and it was mostly used in education. It wa…

The thing is even Java’s heyday was far more fragmented than Pascal’s.

Despite what HN suggest sever side programming isn’t that big. Android is currently a major component of it’s position, if you don’t include Android then Java isn’t the most popular language.

Java is practically non existent on client side web, system programming, desktop applications, iOS, scientific computing etc. So only something like 20% of programmers are using Java as their primary language and it might have topped 35% at it’s peak.

Re: Retrofitting null-safety onto Java at Meta

#214

Post by pron »

Retric wrote: post #213
pron wrote: post #206

Earlier quoted context omitted.

> Several languages had similar levels of dominance. I don't think Fortran was ever quite that dominant, but we can certainly agree that no language has been as dominant since Java. > It’s possible though harder to verify if Pascal reached that level and we might see Python hitting it soon. Not even close for either one of these. I was already programming in Pascal's heyday, and it was mostly used in education. It wa…

The thing is even Java’s heyday was far more fragmented than Pascal’s. Despite what HN suggest sever side programming isn’t that big. Android is currently a major component of it’s position, if you don’t include Android then Java isn’t the most popular language. Java is practically non existent on client side web, system programming, desktop applications, iOS, scientific computing etc. So only something like 20% of p…

> Despite what HN suggest sever side programming isn’t that big. Android is currently a major component of it’s position, if you don’t include Android then Java isn’t the most popular language.

Quite the opposite. If you look at the hiring labs data, iOS and Android combined make up less than 1/3 of the Java market alone. That's not surprising. There are lots of mobile apps, but they don't require that many hours of work.

> So only something like 20% of programmers are using Java as their primary language and it might have topped 35% at it’s peak.

But no other single language has better prospects, with only JS and Python in the same game. Java is not as super-dominant as it once was, but it is more dominant than almost any other language in existence. Everyone else is doing worse (or about as well in the case of Python and JS). Moreover, there currently aren't languages that are seriously threatening Java's position as PHP and Ruby (and maybe JS with Node.JS) once were.

The observation that the market is more fragmented than before with all languages commanding smaller portions than some did in the past is true. But if you're worried about Java's position, you need to be much more worried about, say, Go's.

Re: Retrofitting null-safety onto Java at Meta

#215

Post by jayd16 »

pron wrote: post #180
jayd16 wrote: post #163

Earlier quoted context omitted.

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,…

First let me say that since it's established that different programmers have different preferences, the fact that some programmers might prefer a different evolution strategy is no reason to change it, because that will always be true. A reason to change strategy is if some other one has fared better, and none has. The only languages that have arguably fared better than Java are Python and JS, and they have fewer, no…

I think Java really dropped the ball on UIs (and other paradigms where you need to pass data across threads) and this is partly because of the terrible threading hoops that need to be jumped for lack of async/await. Kotlin gained traction exactly because Java didn't solve this.

I think it's pretty depressing to hear that you're numb to this.

TBH, I don't think virtual threads even address this use case in a way that isn't just async/await but less sugared syntax. (Although I'm willing to be pleasantly surprised once new libraries pop up)

Re: Retrofitting null-safety onto Java at Meta

#216

Post by krzyk »

mohaine wrote: post #154
krzyk wrote: post #144

Earlier quoted context omitted.

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

Pretty much every JSON parser in java does this by default. Why? Because they were all written before Optional existed. I have to agree with the Optional hate. I loved it in Scala but after a few months on Kotlin I don't think I can go back.

Jackson does it well.

Any sane json library has to support newer Java idioms, if not it is not worth using.

Re: Retrofitting null-safety onto Java at Meta

#217

Post by pron »

jayd16 wrote: post #215
pron wrote: post #180

Earlier quoted context omitted.

First let me say that since it's established that different programmers have different preferences, the fact that some programmers might prefer a different evolution strategy is no reason to change it, because that will always be true. A reason to change strategy is if some other one has fared better, and none has. The only languages that have arguably fared better than Java are Python and JS, and they have fewer, no…

I think Java really dropped the ball on UIs (and other paradigms where you need to pass data across threads) and this is partly because of the terrible threading hoops that need to be jumped for lack of async/await. Kotlin gained traction exactly because Java didn't solve this. I think it's pretty depressing to hear that you're numb to this. TBH, I don't think virtual threads even address this use case in a way that…

Not only am I not numb to this, Oracle is now renewing investment on the client. But client side programming does have a clear winner -- JS. Not only Java, but everyone else lost. But whatever Java does, it's clear that no single language is currently on a path to dominance across multiple domains. Java is dominant on the server, JS on the client, and Python in ML and smaller programs. When we compare Java to its historically anomalous dominance in the early oughts, its position today is no doubt worse. But when we compare it to how other languages are doing, no one else seems to be doing much better, and most are doing significantly worse.

Re: Retrofitting null-safety onto Java at Meta

#218

Post by pron »

unscaled wrote: post #208
pron wrote: post #109

Earlier quoted context omitted.

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.

> 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. I don't quite get the "unburdened" part. C# now has records as well[1], and it always had List . It may also get stackful coroutines as an alternative to stackless coroutine. You could say that C# now has to deal with a lot of legacy code that'…

> I don't quite get the "unburdened" part.

Then let me explain. Some programmers (~10% by my educated guess) like languages with lots of features, but most don't; really don't. It seems that being able to serve as a first language is a prerequisite for being super-popular (and Java, Python and JS serve in that role), and having more features is a big hindrance to that. We are more concerned with Java having too many features than too few (and teachers complain about that).

Every additional significant language feature has a cost, and often for every experienced developer it gains, it loses several beginners. The trick is balancing the benefit and the cost, and in Java we do this by adding features slowly, and trying to pick only the ones that give a lot of bang for the buck (which means we often add features relatively late, after they've proven themselves elsewhere). This strategy -- originally laid out by James Gosling in the mid-90s -- works, and no other strategy has so far proven to work better.

> That's strictly worse.

It really isn't for languages seeking to be at the top for the reason I just explained. But even if you think there's some subjectivity there, the objective fact is that no language with a strategy of adding features quickly has performed better in the market than Java. The only languages in the same tier have even fewer features. So there is no objectively measurable metric by which it is worse: languages that add more features more quickly don't fare better (in fact, they seem to fare worse), and no significant differences in productivity or correctness have been found (despite trying).

> and the Java legacy solutions are usually quite a lot uglier

I think they're usually quite a lot nicer, but people have different preferences.

> But I disagree with the stance that stackful coroutines are superior.

Okay. There aren't many things all developers agree on.

Re: Retrofitting null-safety onto Java at Meta

#219

Post by Retric »

pron wrote: post #214
Retric wrote: post #213

Earlier quoted context omitted.

The thing is even Java’s heyday was far more fragmented than Pascal’s. Despite what HN suggest sever side programming isn’t that big. Android is currently a major component of it’s position, if you don’t include Android then Java isn’t the most popular language. Java is practically non existent on client side web, system programming, desktop applications, iOS, scientific computing etc. So only something like 20% of p…

> Despite what HN suggest sever side programming isn’t that big. Android is currently a major component of it’s position, if you don’t include Android then Java isn’t the most popular language. Quite the opposite. If you look at the hiring labs data, iOS and Android combined make up less than 1/3 of the Java market alone . That's not surprising. There are lots of mobile apps, but they don't require that many hours of…

The data I looked at suggests without Android Java falls behind JavaScript. Also, Python is starting to take over at CS schools which is usually a sign it’s going to be even more popular in the future.

I suspect Python is going to take over from Java fairly soon, even if it might not reach Java’s mid 2000 dominance. That said, Java never reached the dominance of C, and C never reached the dominance of Fortran so I don’t think such arbitrary benchmarks mean much. In absolute numbers we have far more programmers so the next dominant language is likely to surpass past peaks by that metric.

Re: Retrofitting null-safety onto Java at Meta

#220

Post by pron »

Retric wrote: post #219
pron wrote: post #214

Earlier quoted context omitted.

> Despite what HN suggest sever side programming isn’t that big. Android is currently a major component of it’s position, if you don’t include Android then Java isn’t the most popular language. Quite the opposite. If you look at the hiring labs data, iOS and Android combined make up less than 1/3 of the Java market alone . That's not surprising. There are lots of mobile apps, but they don't require that many hours of…

The data I looked at suggests without Android Java falls behind JavaScript. Also, Python is starting to take over at CS schools which is usually a sign it’s going to be even more popular in the future. I suspect Python is going to take over from Java fairly soon, even if it might not reach Java’s mid 2000 dominance. That said, Java never reached the dominance of C, and C never reached the dominance of Fortran so I do…

I don't know if Android matters that much (it's quite small), but regardless, as I've said several times, JS and Python are indeed the only languages with arguably better prospects than Java at the moment. Those who want Java to remain in that top tier should at least understand why, if we'd emulate anyone in any way, we'd try to emulate them rather than languages that are doing so much worse than Java.

But it's also good to remember that both JS and Python have their own issues, that are by no means smaller than Java's, and neither of them currently threatens Java's dominance on the server, and no one else does either (although PHP and Ruby did in the past).

Post reply on HN