Given how well the language is defined, they could almost certainly compile Jv1 classes to Jv2 classes anyhow with minimal impact probably.
They could fix a couple other things along the way.
It took python what, over a decade to get people to switch from 2 to 3 didn’t it?
I’m just not sure you could ever pull it off. It seems way harder than that. Even with some sort of compatibility layer. I think you’d really end up in more of a perl 6 situation where it’s a different language that would eventually have to be renamed due to confusion.
A lot of isolated Java could remain V1 no problem.
Allow new starts, separate modules, and those that want to port a J2.
Python 3 was a disaster because they never bothered to think about it, provided no facility for it, didn't care about collisions at the platform level.
Oracle could literally pay for the most important OSS modules to be ported, give architectural guidance scripts to transform old codebases, special test units, training.
Python and Javascript are ironically two of the biggest messed in all of tech, that gain popularity and drag everything into the mud with them.
Unfortunately the more compatible you are with "V1" the more compromises you have to make. See: Kotlin, F#, TypeScript bending over backwards to maintain compatibility with the dominant language of their respective platforms. Not to mention C++. You have to admire the hutzpah of Python 3 level of changes. Some software should simply have a "sell by" date and be thrown out when it starts to stink.
That said I'm surprised more languages haven't attempted the approach of Rust with 'editions'.
> There are times, however, when it is useful to be able to make small changes to the language that are not backwards compatible. The most obvious example is introducing a new keyword... Editions are the mechanism we use to solve this problem. When we want to release a feature that would otherwise be backwards incompatible, we do so as part of a new Rust edition.
[https://doc.rust-lang.org/edition-guide/editions/index.html]
Two major initiatives for many years in Java have been Loom and Valhalla. A cynical take on that is that Java is attempting to copy something that Go and C# (and others) have had and excelled at for a decade or more, and were designed to do from the start. Sometimes, at some point the expense and complexity of dragging decades of code forward (with all accumulated mistakes, design assumptions made based on now obsolete hardware, backwards compat constraints, etc.) outweighs the cost of going back to the drawing board to start again.
(Also, do note that we still rely heavily on numerical libraries written in fortran)
State of the art GCs are incredible - but there is a reason you see Java pioneering the GC area, that being that Java has the most to gain because of its tendency to create enormous amounts of garbage, which is a problem other language designs do not suffer from nearly as much, letting them get away with simpler GC while maintaining high performance.
And Fortran isn't the only game in town for high performance numerical libraries ;) There is large incentive to reinvent there, as legacy doesn't matter if the new thing has more performance - Eigen, cuBLAS/CUDA, and others are in C++, not Fortran as far as I'm aware. Fortran has momentum no doubt, but it has been on its way out for a long time.
Also, due to the JVM’s flourishing multi-language support all these changes will greatly benefit all the other JVM languages as well. So in that view, I do think that the JVM has quite a future ahead of it because Valhalla will further improve the already killer performance.
For Kotlin and TypeScript, compatibility with the dominant language is the main reason for their success. For Typescript especially, the reason that it's so popular is how easy it is to migrate from JS to TS: JS is valid TS. I don't think the same is true for Kotlin. That combined with less "game changing features" in general (Java is already statically typed for example) probably explain why TS is way more popular in the JS world compared to Kotlin in the Java world.
> You have to admire the hutzpah of Python 3 level of changes.
You mean breaking backwards compatibility and dividing the ecosystem for relatively small changes? While I admire the self-confidence that it takes, I'm happy other languages are more reasonable in their approach. And the Python people seem to be more reasonable these days. Async was added without needing Python 4, and they're talking about performance improvements and multicore too. The rolling release probably helps a lot here, they can deprecate stuff slowly but surely.
> That said I'm surprised more languages haven't attempted the approach of Rust with 'editions'.
Editions can only affect some part of the language. From the Editions Guide [1]:
> The requirement for crate interoperability implies some limits on the kinds of changes that we can make in an edition. In general, changes that occur in an edition tend to be "skin deep". All Rust code, regardless of edition, is ultimately compiled to the same internal representation within the compiler.
Of course, a way to easily make skin deep changes is better than no way of making changes at all. But often, when a language changes, idioms do too and thus code has to be changed. For example, OCaml 5.0 will have effects for direct asynchronous IO. This will be backwards compatible, current monadic asynchronous code will still work, but people might want to rewrite their code in direct-style. C# introduced nullable reference types in C# 8.0. It's backwards compatible too, but you might want to update your code here too.
[1]: https://doc.rust-lang.org/edition-guide/editions/index.html
Rust editions are no different from selecting language versions, on their current state they require compiling from source with the same compiler, a very tiny set of language changes that might be supported.
> Each project can opt in to an edition other than the default 2015 edition. Editions can contain incompatible changes, such as including a new keyword that conflicts with identifiers in code. However, unless you opt in to those changes, your code will continue to compile even as you upgrade the Rust compiler version you use.
Now granted it’s entirely possible that a given compiler version accidentally broke comparability when building in a different mode - that’s a bug. It’s also possible that this model does have a limit as to how breaking of a change the editions can have (eg probably the ownership model can’t change drastically) which is maybe what you’re trying to say? Certainly if I recall correctly there have been breaking changes in editions.
[1] https://hkalbasi.github.io/mdbook-ra/appendix-05-editions.ht...
Other languages, like Java, C, C++, C#, F#…, also embrace binary libraries and multiple implementations.
Rust editions currently don't have an answer for such scenarios.
Which isn't really much of a problem given that the ecosystem is built around cargo compiling from source.
Aren't they? Can you choose to compile Java 17 with Java 7-8 syntax, but still make use of Java 17's other features which don't break backwards compatibility? As far as I have understood, that's possible with Rust (though I might be wrong, I've never really tried using an older edition).
One lesson for Borland days is that I rather use the languages that are on the box than dealing with extra complexity of third parties in the platform.
My point of view is not always what wins out, and there is good to learn new approaches in programming that can be latter applied to the daily tools, but that is how I see things.
The Borland example is confusing. The way I remember it their Pascal and C++ support was equally official. BC++3 was comparable to TP6 though the latter was less resource hungry (and at <700KB fit a single FD). Then for many years Delphi was well ahead of C++ Builder. But in the end professionally C++ skills were much more valuable.
Ten years ago I hoped that ORCL would acquire Typesafe and make Scala supported officially the way MSFT did with F#. Instead they left the space open for Kotlin to appear. And then antagonized GOOG into making it a juggernaut. There must be some Innovator's Dilemma-style explanation here but as a developer I regret it.
As a side-note I believe Martin made a huge mistake by allowing Haskell fans to highjack the narrative. His original strategy reminds me Elon's a little. Make industry finance and popularize high-impact type system research by using its impressive end result. Investing in Scala ten years ago prepared me well for Kotlin and modern Java (not to mention a few years of data engineering jobs around Spark and ML).
It's production tested in the largest and hardest java ecosystem out there - android apps.
The most unique Scala feature seems to be implicits. While I'm not convinced by their usefulness, the feature will be available in Kotlin in a few months: https://github.com/Kotlin/KEEP/issues/259 I'd even argue it is more useful in Kotlin since the language is state of the art regarding it's ability toward making DSLs.
The major features that Scala 3 has that Kotlin does not that I can identify are: 1) Pattern matching -> Kotlin is almost there, it has destructuring, a when control structure, and can express ADTs via sealed classes/interfaces. The limitations are: name based destructuring is not implemented. No destructuring in when blocks. However since java will be getting extensive pattern matching support in jdk 19/20 I expect Kotlin to catch up there and I recognize pattern matching can be a very useful feature.
2) union types and intersection types. While those are useful in a structurally typed language such as typescript, I don't see much usefulness for them in Kotlin. You can express union types via sealed classes somehow. The compiler plugin arrow meta brings union type support but I haven't tested it yet. As for intersection types it is on the roadmap. The main usefulness of union types I can see are the union of exceptions in catch blocks, that BTW Java supports, surprisingly.
3) higher kinded types I don't see much usefulness in higher kinder types What else could their use be beyond abstracting over collections? Every Kotlin collection implement the interface Collection<T> which enable this use case. Again, higher kinded types are supported by the arrow-meta compiler plugin.
To me the very few pain points of Kotlin have nothing to do with functional features but are: 1) Inability to deflare a function parameter as mutable. Inability to declare for loop element as mutable. Which in fact are because of IMHO religious functional toxic beliefs about immutability everywhere. 2) no package private modifier (although java 9 modules are supported and they are working on the issue)
I really don’t see the point of coroutines, especially when a) project loom is on the horizon, b) higher kinded types make it quite trivial to implement as a library (answering your 3rd point)
I’m not sure about reified generics, they are very seldom a problem and frankly, type erasure is most often just misunderstood. Also, with pattern matching overloading is used less often so it is even less of a win.
Regarding compile time safe recursion, I’m pretty sure that Scala was actually the first bigger language implementing that (with an annotation), so it definitely has that.
So don’t get me wrong, Kotlin is a great language with some nice features, I just don’t see it doing anything novel to be honest (and that’s not a bad thing! Non-research languages rarely do anything truly novel!). I just feel like Scala does all of those with less special cases (eg. extension functions can be done with implicits so you get one feature doing many things)
I am merely pointing out that Kotlin has a much larger community adoption. and it was never backed by corporates.
Ultimately - adoption matters.
https://spring.io/guides/tutorials/spring-boot-kotlin/
in fact, this data is fairly accurate - check out the stats on rise of Kotlin's popularity.
https://www.developernation.net/blog/infographic-programming...