131–140 of 243 posts
Earlier quoted context omitted.
I wish we just had non-nullable types...
With checker framework, you can basically have it (and much much more, I believe no other language comes close to that level of static analysis). It is annotation-based and not a fancy keyword, but it is there.
Earlier quoted context omitted.
Perhaps this example will make it more obvious: boolean truthy = false; truthy = null; // compilation failure, type mismatch vs. the Boolean type Boolean truthy = new Boolean(false); truthy = null; // compiles just fine The reason Boolean (and other boxed primitive types) exist is because it is an Object (a reference type) and that allows them to be used in things like collections that expect Objects and not primitiv…
So you are really looking for compiler checks for null? Kind of like kotlin? var truthy = null; // Compile fails var nullable? = null; // Compile passes You don't need value types for this?
Additionally, the type is also lighter weight than an Object and should be stack allocated, so there are memory advantages to not having to use boxed types as well.
Earlier quoted context omitted.
Those features (except for nullability types) predate Java, let alone Scala and Kotlin, by a couple of decades. Those three -- like all programming languages -- get inspiration from similar sources. Java is just the most conservative of the three with regards to language features.
I think it's disingenuous to deflect by saying that Scala didn't invent those concepts. I think it's pretty clearly significant that Scala and Kotlin are JVM languages, specifically. If we just said "Well, StandardML had XYZ feature 30 years ago," you could reasonably wonder whether implementing those features on the JVM was a legitimate hurdle to not including them. But the fact that the guy who wrote generics for J…
It is possible that Java platform languages might indicate the palatability of certain features to Java programmers more than non-Java platform languages, and the Java language designers do have a closer relationship with the designers of other Java platform languages. But overall, these effects are not particularly big. Knowing the current designers of the language, I can say with certainty that Haskell has served as a bigger inspiration than either Kotlin or Scala on recent features and their design (inspiration, not direct source).
Is it in the realm of possibilities that Java will someday have runtime generics support (instead of type erasure)? It's the most frustrating aspect of the language because you can't use basic Java features like method overloading with them. Also, I don't understand how people use the `Optional `..? Is there a way to use method overloading with it? `ErasedType` could be _anything_ at runtime, doesn't sound fun. Besid…
When exactly would you benefit from overloading based on a generic type? How come it is never brought up with Haskell for example, or the other majority of languages that employ type erasure?
All the backend projects I work on were originally written in Java. I'll admit that Streams and Lombok make it a somewhat pleasant experience to work with, at least compared to when I used it in college (I think Java 8 was newest?). But that said, I once tried writing a new feature in Kotlin, and now all our code is Kotlin. I don't really see how Java can compete with the non-nullable types, data classes, and type-in…
I write a lot of Kotlin code but still tend to use Java a lot. All of the features you mention are not really an advantage for Kotlin anymore. Java has had tools to deal with nulls for a long time, we tend to assume everything is non-null unless annotated with `@Nullable` and let tools check correct usage at compile time... data classes are very similar to Java 16's records. Type-inference since Java introduced `var`…
Oh yeah, nothing like creating Frankenstein's monster instead of using a tool that was designed for the purpose. And no, it's not the same. You'll never beat Kotlin compiler , no matter how many annotation you use - you will always miss something.
> data classes are very similar to Java 16's records.
You mean Java 16's records are similar to data classes, since those were first.
> Type-inference since Java introduced `var` is pretty much on-par with Kotlin.
Not even close. Can't use it outside of functions, clunky final var instead of val.
> Some people have already started talking seriously about Kotlin now just adding friction, as you need to keep updating its version and the Gradle plugin (which is not compatible with some versions of Gradle if you're stuck with some old Gradle plugins).
My favorite kind of people. 'Some'.
> Java 17 should probably stabilize sealed classes, which is one of the biggest advantages of Kotlin at the moment...
Nice!
Let's wait until you'll upgrade to Java 17 while Kotlin has everything already and much more with compilation to JS and native in the future.
Earlier quoted context omitted.
If I remember correctly, it's fairly easy to use @Nullable and still end up with nulls there, even without an IDE warning. I'll have to double check to see if I can still reproduce that. But, to be fair, it's actually fairly easy to break Kotlin's null safety, too: https://blog.haroldadmin.com/circular-refs-kotlin/ But I basically agree with what you've said. Kotlin is certainly still a much more ergonomic language,…
Value classes cannot provide the performance/memory flatness that Valhalla will bring though. So I'm not really sure what benefit does "values classes" bring. Just to make sure, you are talking about the inline class which is just a wrapper around single property? inline class Password(val value: String)
"value class" is the next step for inline classes. They are going to behave very much like Swift's struct and its "mutating methods". And they are going to be "Valhalla ready" so we'll get the performance improvements automatically when it lands.
In a sense, they are an upgraded data class with a much more precise and controlled form of mutation. Rather than a `var` field meaning the object will mutate in-place, it will basically automatically call a kind of (implicit) "copy()" method. Further, you may only mutate these `var` fields inside of class methods that are marked with a new keyword: `mutating`.
Read through the KEEP. It's pretty interesting stuff. At first it kind of rubbed me the wrong way, but the more I thought about it, the more excited I got about it- especially after thinking about how Swift does it and it works well there.
Java gets a bad rap from people that used it late 90's through early 2000's and got burned out by XML and design pattern heavy frameworks but its a lovely language that with a little discipline can be used to create very lean looking code. Go is one of the HN darling languages and I work in Go everyday for work (and generally like it), but I really wish I could reach for Java most days.
I disagree that it's a lovely language. I think, as developers, we very quickly develop Stockholm syndrome. Once you "learn" a language, it's really easy to churn out code and apply idioms without even realizing that you're constantly writing workarounds and kludges for your language's deficiencies. As a polyglot dev, the following are my gripes with Java: * null - we all know, so I'm not going to bother expanding ex…
I think that's a mixed blessing. I believe Java did this deliberately to avoid the trouble that C and C++ have with signed and unsigned integer types having to coexist. Personally I've never been inconvenienced by Java's lack of unsigned integer types, but I'm sure it can be annoying in some situations.
I'm quite fond of Ada's approach to integer types, but I suspect I'm in a minority.
> Silent integer overflow/wrap-around. It's not C- did it really have to copy this insanity?
Curiously this cropped up 10 days ago. [0] You're not alone. The great John Regehr put it thus: [1]
> Java-style wrapping integers should never be the default, this is arguably even worse than C and C++’s UB-on-overflow which at least permits an implementation to trap.
> The fact that arrays got type variance wrong.
At least Java has the defence that they didn't know how it would pan out. C# has no such excuse in copying Java.
> No concept of `const` or immutability.
I recall a Java wizard commenting that although a const system is the sort of feature that aligns with Java's philosophy, it's just too difficult to retrofit it.
Earlier quoted context omitted.
How does making Optionals allocated on the stack (value types) prevent this? Or rather why do you need value types to accomplish this?
Perhaps this example will make it more obvious: boolean truthy = false; truthy = null; // compilation failure, type mismatch vs. the Boolean type Boolean truthy = new Boolean(false); truthy = null; // compiles just fine The reason Boolean (and other boxed primitive types) exist is because it is an Object (a reference type) and that allows them to be used in things like collections that expect Objects and not primitiv…
JEP 401 won't cover it quite yet, note this from the "Non Goals" section:
> An important followup effort, not covered by these JEPs, will enhance the JVM to specialize generic classes and bytecode for different primitive value type layouts.
It wasn't until recently that I understood for myself just how large the surface area of the "value types" problem is - it will be delivered incrementally. JEP 401 and 402 are the first steps (if I were to guess they will show up as previews soon? maybe JDK 17 or 18?), but there is more to come.
Waiting for project loom [1] [1] https://openjdk.java.net/projects/loom/
I am unreasonably excited by Loom, for two reasons: 1. I cannot wrap my head around library-based reactive systems. I have tried and tried and continue to try. But they're like some of the original Go4 design patterns: they exist to solve the language , not the problem . Loom's promise to make steam-powered linear code behave mostly like a fully-dressed reactive library system is extremely welcome. 2. Structured conc…
Earlier quoted context omitted.
The hype around Rust is largely justified. There. I said it. Rust is nowhere near perfect. It's also supposed to be a systems language- it was probably not originally intended to replace languages like Java for general "app" development. But it's so much better of a language than most of the higher level languages you see in popular use: Java, PHP, JavaScript, Python, etc, that people are actually willing to deal wit…
It surprises me that we don’t yet have an applications language with an ultra-modern type-system. It’s so strange that the current leaders are a scripting-transpiler (TypeScript) and a systems language (Rust) - but not an apps language in-between. ...then again it’s understandable when you see how the traditional apps languages (C#, Java, etc) are severely hobbled by their VM/runtime, because that’s usually the sourc…
To be fair, I think that a decent amount is possible on JVM and CLR. Scala, for as much hate as it gets, has a much stronger type system than Kotlin/Java.
And Swift has its own backwards baggage! It has to work with Objective-C. There's actually a few weird things in Swift that I've bumped into that I'm pretty sure are only there because of Objective-C.
The Rust devs certainly take backwards compatibility very seriously and they guarantee backwards compatibility forever. There will be no breaking changes in Rust except in extreme cases of finding unsoundness or whatever.
There are currently ZERO good high level app-building languages, IMO.
Rust isn't it because of the lack of garbage collection (which is not a point against Rust- just for the "domain" of optimizing for user-space app development).
Swift would probably be it, but it's pretty much Apple-only and I don't expect that to change.
TypeScript is close, but it's held back by needing to work with JavaScript and the JavaScript standard library and ecosystem suck. It also can't do threads.
Kotlin/Java are decent, but not good at concurrency, and having things like different sized integer types is really silly for a high-level language where everything goes on the heap anyway...
Python is slow and can't do threads.
Some languages like Lisps and MLs might be good for building apps if they just had the ecosystem around it. Haskell would be a giant pain the ass because real apps are full of "IO".
So, yeah. It's kind of a miracle that we can get anything done. I guess that's why we get paid so well...