Hacker News Reader

Comment by bluejekyll | Hacker News Reader

“… it has the more ambitious agenda to heal the rift between primitives and objects.”

I have been waiting for these fixes to the language since I was first introduced to Rust which got the type system “correct” where Java had left a lot to be desired.

The big thing that Java will get beyond generics and such being cleaned up for all types, is true Optional types. That is, a stack based Optional that is itself not null, but tracks something that might be null in the interior.

It will take a long time to update the ecosystem to correct this, but when it comes it will make Java a much “safer” language to develop in, that is a class of runtime errors can be avoided and caught at compile time. This will be great, and I look forward to the day when it comes.

View on HN

The main thing of Rust that Java can’t provide even after Valhalla is compile time thread safety guarantees. I find those in the meantime one of the biggest advantages of using Rust - and miss it in all other programming languages. Questions like „can I refactor this code to make it parallel und use the database client / IO stream / etc from multiple threads simply answer themselves.

Apartment from that I think the type system power of Java/Kotlin in the near future is good enough and a nice blend of complexity and getting things done. And with Valhalla, Loom and modern GCs a lot of performance concerns should also be removed

Rust can only guarantee that no data race will happen. Other race conditions are still possible, so I don’t really see Rust that much safer than Java. Concurrency is hard everywhere.

Indeed. I recommend using tsan for java.

https://wiki.openjdk.java.net/display/tsan/Main

But the types of races I struggle with in java I suspect are similarly hard in Rust.

Here's two pieces of concurrent code I struggled with:

https://github.com/google/guava/blob/master/guava/src/com/go...

I'm not sure reasoning about the correctness of those would be easier in Rust, but if there are any rust experts reading this I'd love your perspective.

Thanks, I haven’t seen tsan before. Java also has JML but I don’t know how much does it help regarding concurrency.

Interesting - didn’t knew tsan is now available for Java. Which JDK version is it available for? The linked wiki isn’t super clear on this. But given it seems a 2020 Addition I guess only for rather recent ones.

While that is the only guarantee it can provide - in practice it ends up being a lot more powerful. Eg most multithreading issues in Java occur due to totally missing synchronization - because developers either didn’t think about threads or didn’t have enough experience to apply correct synchronization. In Rust the compiler would already have complained about these cases, and eg the design of the Mutex type - which wraps data instead of standing next to it - makes it hard to abuse.

Have you ever tried kotlin? I've found it to be an encoding of best practices from Java with nullability pinned down. Really made me enjoy working in a most OO/procedural language again after fleeing to scala for a few years.

Yes. Kotlin is good, but there is a lot of Java out there that needs to be supported.

Have you experimented with converting entire projects of Java to Kotlin?

Why would you convert the entire project to Kotlin? It’s trivial to mix the two languages, and in fact most Kotlin applications depend on Java libraries.

Jet Brains seems to want ot create an ecosystem of their own, Kotlin still depends on Java is more accurate.

I don’t think that’s true. One of the biggest use cases for Kotlin is Android development. Interop between Kotlin, Java libraries, and the Android SDK is completely seamless.

It's hard to be certain but we have seen this story in Scala. Among the advantages advertised early was interoperability with Java and access to its huge ecosystem. In practice the Scala ecosystem is completely different (well, Akka is a special case popular in Java projects too).

As a trivial example people would rather use ScalaPB instead of officially supported Java library. When I worked on a Kotlin-based system people were adamant to use github.com/JetBrains/Exposed. Which had a couple pages of documentation and was missing features.

And then again there's politics. Big/successful companies always end up re-inventing PL wheels. The whole GOOG/ORCL mess gave GOOG incentive to fragment the Java ecosystem too.

Ok that’s Scala… Kotlin is already the primary language for all new Android applications. The interop story with Java is unambiguous: Kotlin works well with Java. For instance, Android didn’t rewrite most of their SDK in Kotlin, yet it works just fine. Popular Java libraries like Spring and Dagger work with Kotlin. It really “just works”.

Until the language tears over whether they should support android’s “java 8”, openjdk’s java 17+ with modern features, js, or multiplatform.

That’s just random speculation.

I switched from Scala because I found the interior to be so good. Calling Java from kotlin is easy, and - unlike Scalia - the inverse is also true.

I’ve converted several projects from Java to kotlin incrementally and it’s been very smooth.

Scala 3 has an optional non-null compilation mode which will turn Null into a separate type not subset of every class. In my opinion it is a much more elegant solution than Kotlin’s.

It's exactly as elegant for nulls. Kotlin's T? == Scala 3's T | Null. In both Scala 3 and Kotlin, you can't call a method it.

Kotlin does have the !! operator for practical purposes like Java interop. Equivalent to this Scala 3 code:

   extension (t: T)
     def !!: T = if(t != null) t else throw NullPointerException()

I haven't checked after release, how is Scala 3 smart-casting now? E.g. Kotlin and Typescript convert a T? to a T inside an if(t != null) branch, and Scala's left much to be desired when I checked.

Scala's and Typescript's union & intersection + smartcasting approach is much more general than Kotlin's T? of course, but Kotlin could introduce that backwards-compatible if they wanted.

  > "I haven't checked after release, how is Scala 3 smart-casting now? E.g. Kotlin and Typescript convert a T? to a T inside an if(t != null) branch, and Scala's left much to be desired when I checked."

See: https://docs.scala-lang.org/scala3/reference/other-new-featu...

It works perfectly well in a number of ways (IE, you can use "=="/"!=" null, use a "match")

https://scastie.scala-lang.org/s853XsLoQEKTVosebJHelA

Kotlin is still a better experience when interacting with Java because of inbuilt interop with Java types like "List" though, in my opinion.

In Scala you need to use ".asScala", ".asJava" etc.

I had a look at Kotlin and it's definitively an huge improvement with regards to Java. It is free of all the ceremony and boilerplate of Java and null values are so much less of an issue. Still, coming from Scala I'm a bit underwhelmed.

Don't get me wrong - Kotlin is a very fine language with lot of promise and the comparison to Scala is not exactly fair - Scala is just a completely different league.

I really like what Odersky and the Scala community did with Scala 3; they lifted the language onto a sound new theoretical framework, streamlined the way implicits are used and got rid of puzzling irregularities. Did I mention the new sound macro system? But I'll stop fawning now.

I'm currently working on a project where we use Kotlin instead of Java. Probably wouldn't have taken the job if it was with Java and Kotlin makes it quite fun. But damn - I do miss Scala.

I have unfortunately, given the Fellowship of Kotlin at Mountain View dungeons, that even misuses Java features to sell their agenda.

I rather use the platform languages without extra tooling and wrapper libraries.

No JVM language can solve problem of memory layout. I don't care about nullability in my code (to be honest, I don't remember when I seen NullPointerException last time), but I need good performance. At $job we use "arrays of primitives" instead of "array of structs" to have good performance, but such code is very ugly and hard to support.

True "primitive" objects which are packed densely in memory and generics over such objects (to use ArrayList or equivalent instead of bare array[]) is main reason what allows .NET code to be faster than JVM code, though .Net compiler (JIT) and VM are much less optimized. But JVM (HotSpot) doesn't have choice now :-( Valhalla, when fully implemented, will gibe a huge and long-awaited performance boost.

All these hyped non-nullable Option<> maybe good, but is not a show-stopper. Performance is.

Edit: for grammar.

I second that. I don't see NPEs in real life outside of early stage development of a new service. You inject all dependencies in constructors (Preconditions.checkNotNull if you're paranoid enough), make all fields final, and that's about it. I have got very mixed feelings about the extend to which Kotlin goes on null safety for this reason.

In traditional/non-FP code bases it's not a problem at all to check for null when a data structure uses it to signify "missing". There are usually not that many places where it's necessary.

Getting Java on par with C++/STL would be great though. No need for trove4j/colt. Anything that reduces memory usage without making people think hard would also be great to compete with golang.

Due to backwards compatibility Optionals will be value classes, not primitives so null will be a possible value for them as far as I know. But it will be possible to optimize it at many places (mostly as return types perhaps).

I’d be interested in a new type in that case. Option…

If I understand the Valhalla proposed design [0], every primitive reference type `X` will have an associated primitive value type `X.val`, while every primitive value type `X` will have an associated primitive reference type `X.ref`. Which one gets to be called `X` is a function of how you declare it -- `primitive class X.val {}` gives primacy to the reference type.

So, if `Optional` will continue to be a reference type, you should be able to use `Optional.val` to use the associated value type.

[0] https://openjdk.java.net/jeps/401

I believe JEP 401 has not yet been updated to the new model, there is no .val anymore, instead there are nullable value types and non nullable primitive types, only the latter has a .ref box because the former is a reference.

Optional will be retrofitted to a value class not a primitive class, you get flattening but only on stack (parameter type or return type) not on heap (field).

I don't really understand the end of the part3 (the VM model), so i may be wrong.

a null Optional will be pretty disappointing

if (opt != null && opt.isPresent() && opt.get() != "")

It's possible in current Java

It already is :)

Optionull

Reply on news.ycombinator.com