Comment by marwis | Hacker News Reader

Comment by marwis | Hacker News Reader

Parent Full thread

> They just released a proposal that effectively side-steps the problem of checked-exceptions-in-lambdas. Here is a link -- https://inside.java/2023/12/15/switch-case-effect/

This is fine but removes only about 10% of the pain of mandatory exception handling inside typical lambda.

Nothing short of making exceptions transparent to lambda receivers will cut it for me.

> Kotlin is using an annotation to disambiguate between Java style records and Kotlin style records

This is inherent risk of building on top of something you don't control. Don't really see this as fair comparison. It's a known design constraint. The only way to avoid it is to not build on top of Java or not adding any features on top of Java.

> To give another example with C#, there has been a lot of recent discussion about finding potential alternatives to their async-await concurrency model. They cite the level of effort it takes to maintain the async await style code and the costs that come from this.

I had a very different take-away. They did PoC with virtual threads and decided it's not worth the switch now and async-await that they have is good enough.

https://github.com/dotnet/runtimelab/issues/2398

> Some of the languages it gets compared too aren't even that old yet.

C# is more than old enough to drink and Scala just had its 20th birthday this weekend :) Java is only 4 years older than C#.

> Nothing short of making exceptions transparent to lambda receivers will cut it for me.

If your wish is to have Checked Exceptions be throwable from the lambda, then I understand your point. Still, I stand by argument, which is that they are actively addressing these pain points, but doing so slowly in ways that minimize intrusion.

> Kotlin

If it's not a fair comparison in your eyes, I'll leave it.

> async await in C#

I'd be more willing to accept your point of view if there wasn't so much discussion online about how painful async await is via color-my-function. And that's ignoring the fact that languages such as Go and Erlang have been garnering a big following, in large part due to their concurrency model and how simple it is.

I have had my share of async await too. I think it's no coincidence that many language designers are looking more and more into moving away from async await, thus prompting these PoC's and experiments.

As for the C# link specifically, I interpreted that to be that they felt the pain of async await strongly, and did the PoC in response. However, the PoC did not play well with their async await world, and trying to change the world to make room for it would be too much of a lift. Therefore, they stick with async. I did not interpret it to be that async await was good enough for them, but rather, that improving async await is the best option available to them for now.

> Age of languages

Sure, there are some languages that are a similar age to Java. But those are the languages where I believe the costs for the decisions they made are becoming more apparent. I already gave 1 example with C#. And I think we can both agree that Scala's design philosophy served as a great learning experience for other languages, but was a poor survivability tactic as a language. It feels like the language is buckling under its own weight.

Either way, I am not trying to say that these other languages are bad. Merely that their design philosophies benefit them in the short term, but show cracks in the long term. Java's philosophy, meanwhile, minimizes intrusion, and thus, allows it to sidestep alot of the problems that these other languages are trying to get out of.

Reply on news.ycombinator.com