181–190 of 292 posts
It is so bad, that in julia functions are not first class. Instead, I would love to use scala 3 for machine learning since this is the perfect type system for such a task, but linear algebra support is not good enough.
N-dimensional arrays in Scala 3. Think NumPy ndarray, but with compile-time type-checking/inference over shapes, ndarray/axis labels & numeric data types.
Earlier quoted context omitted.
More importantly, you can use the mature ecosystem around Java (tools, libraries and so on).
Then again, considering the JVM's disastrous recent trajectory (Loom, JPMS, renewed wasted focus on Java-the-language, and so on) that doesn't seem like such a great upside anymore.
Earlier quoted context omitted.
Kotlin becomes the default on Android, more people are writing Kotlin, there's more pressure on Java to adopt the best Kotlin features. If you look at most of the recent additions to Java, they were in Kotlin from the beginning. This is no coincidence.
And they were in Scala, Groovy, C# ... before Kotlin was even a thing. There's zero evidence people on the OpenJDK governing board care about Android at all, rather the opposite.
Kotlin absolutely nailed the "meaningfully better than Java while staying pedantically true to the existing semantics" in a way that none of the alternatives did even if they did come first.
I think the best evolution of a programming language is when some features are removed and replaced by a unifying concept which makes the language both smaller and and more expressive. Has that happened in Scala 3?
In some areas it is explicitly the opposite that happened, and in a way that is for the best — see implicits. Scala 2 is a very flexible language and a lot of outsider complaints seem grounded in this flexibility. Scala 3 is more opinionated in some ways: "Opinionated: Contextual Abstractions One underlying core concept of Scala was (and still is to some degree) to provide users with a small set of powerful features…
Earlier quoted context omitted.
I think apart from streams it was Kotlin that did the trick.
Kotlin doesn't sound like a good language to bet on since most suitable(for jvm) features it has will be integrated by Java now that it has picked up pace. I guess it only has decent marketshare because of google's android support(they are throwing stuff on the wall to move away from Oracle IP i guess) and Jetbrains being very popular among java devs.
1) Jetpack Compose is very loudly Kotlin-first
2) I did a survey of Android developer job postings. Literally ALL of them were for Kotlin, with Java mentioned as a nice-to-have roughly 50% of the time.
On a technical note, I don't see Java fixing NPEs, checked exceptions, or general verbosity any time soon. Java gets to live with its legacy of bad choices, Kotlin is able to stay clean while still providing backward support by integrating with old Java code .
Or is it more impressive that they have walls of text without saying what scale is?
Also why would they wear an old product like Scala like a skin suit ?
Earlier quoted context omitted.
With dependent types, each `e.key` has it's own and separate type. So, if you have two `e`s, the type of the first e's key will not match the type of the second e's key. So, with: def process(p: Path, key: p.Key): Something = ??? this will not compile: val p1: Path = ??? val p2: Path = ??? process(p1, p2.key) <- compile-time-error
Interesting. Thanks! I've been using a lot of Swift lately, and they have a generic type roadmap that talks about "existential types" and being able to "open" an existential. This looks very similar.
[0] https://stackoverflow.com/questions/292274/what-is-an-existe...
Earlier quoted context omitted.
Of course none of this is new, but the lead time from Kotlin adoption to Java adoption of all of them is near identical.
That’s irrelevant. It’s not like the language team didn’t know about these features. The change to the shorter release cycle and increased funding is much more behind the speed up of updates regarding Java.
That's not accurate.
Popularity of a feature and enterprise demand drive it's adoption.
It doesn't really matter what the language team knows, it matters what the average developer knows since their collective wants are in large part what drives the language team.
There are hundreds of thousands of Java devs who only ever wrote Java and suddenly had to write Kotlin, and are now clambering for these feature improvements in Java.
Earlier quoted context omitted.
What are you talking about? Java release notes look like a list of Kotlin features these days. Sealed classes, data classes, multiline strings, coroutines -> project loom, switch statement improvements to resemble Kotlin when statement, improvements to Streams to match Sequences.
These aren’t ‘Kotlin features’ they’re just normal language features. I really struggle to see Kotlin as being part of the debate here. These features are being driven by enterprise Java user pain points. And those people aren’t looking at Kotlin.
By Java devs who only ever wrote Java, and suddenly had to write Kotlin for Android. They're now aware of these features as a result and are demanding them in Java.
Earlier quoted context omitted.
That’s irrelevant. It’s not like the language team didn’t know about these features. The change to the shorter release cycle and increased funding is much more behind the speed up of updates regarding Java.
You keep claiming that the language team's knowledge of a feature drives that feature's adoption. That's not accurate. Popularity of a feature and enterprise demand drive it's adoption. It doesn't really matter what the language team knows, it matters what the average developer knows since their collective wants are in large part what drives the language team. There are hundreds of thousands of Java devs who only eve…
If anything, the acceptance of more parts of the FP paradigm into all major languages (like C#, JS/TS, C++) starting with lambdas likely have pushed Java, but to single out the all-around very niche Kotlin language as a source is imo a non sequitur.