5 ms·

"Java 2" is already out - it's Kotlin (or Scala if you're so inclined) ;) Unfortunately the more compatible you are with "V1" the more compromises you have to

"Java 2" is already out - it's Kotlin (or Scala if you're so inclined) ;) 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 https://doc.rust-lang.org/edition-guide/editions/index.html]

kaba0 5y ago
As mentioned in the article, “A growable language” shows us that a programming language has to evolve. I think Java does an excellent job of not including everything and the kitchen sink right away, but wait a bit for the hype to die off and usually implements new features when they are worthy, often in a superior way. This “last mover advantage” was even part of the initial ideas behind Java.
- kinjba11 5y ago
  The last movers advantage is a tradeoff. It becomes increasingly difficult to make major paradigm shifting changes the further you go. Being conversative increases the length of the runway and Java has benefited from that. Though, the superiority of Java's version when it finally gets some feature is often debatable. 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.
  - kaba0 5y ago
    But Java attempts to “copy” those with an order of magnitude larger ecosystem, with the benefit of all the other optimizations/state of the art GCs that went into the OpenJDK project, and with true backwards compatibility of the billions of lines of code out there. I don’t think that reinventing the wheel would really put us forward. According to the ‘No silver bullets’ article, there is no significant (that is, order of magnitude) productivity improvement in language design since high level languages. The only such bullet is reusing existing libraries. (Also, do note that we still rely heavily on numerical libraries written in fortran)
    - kinjba11 5y ago
      I agree the order of magnitude improvement is no more. Programming in C is much the same as Java. Both are high level curly brace languages. But there is room for improvement still, quite a bit. The fact that Kotlin, Go, etc. were created and became popular supports the fact that large numbers of folks believed that Java's design direction has run it's course to some degree. I may be proven wrong, Valhalla and Loom could be smashing successes and everyone will flock back to Java. But more likely it will take a decade to reap the benefits of the features Valhalla and Loom would provide, benefits already being reaped by other ecosystems right now. 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.
      - kaba0 5y ago
        I would not put kotlin anywhere close to “popular” languages, and go is only getting into that category now. We will see whether they will continue to have support/interest 25 years down the line. 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.
pjmlp 5y ago
Kotlin is not Java vnext, first of all because Jet Brains is "married" with Google's fellowship of Kotlin, secondly because they seem to be focused into creating their own Kotlin based platform, finally OpenJDK will never be rewritten in Kotlin. 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.
- vlovich123 5y ago
  Rust is quite different to my knowledge. You can mix n match libraries each using a different language version. I don’t know that the art of language changes is tiny either as some of these can be mutually incompatible [1]: > 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.html https://hkalbasi.github.io/mdbook-ra/appendix-05-editions.ht...
  - pjmlp 5y ago
    The limit being that the whole program, including all dependent crates need to compiled from source with the same compiler. 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.
    - vlovich123 5y ago
      Totally different ecosystem that’s built around the concept of building from source. Binary libraries and alternate compiler implementations haven’t been a priority. In fact, multiple compiler implementations generally don’t exist until the language is much older than Rust is now. It’ll happen.
Zababa 5y ago
> 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. 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 https://doc.rust-lang.org/edition-guide/editions/index.html

kaba0 5y ago

As mentioned in the article, “A growable language” shows us that a programming language has to evolve. I think Java does an excellent job of not including everything and the kitchen sink right away, but wait a bit for the hype to die off and usually implements new features when they are worthy, often in a superior way. This “last mover advantage” was even part of the initial ideas behind Java.

kinjba11 5y ago
The last movers advantage is a tradeoff. It becomes increasingly difficult to make major paradigm shifting changes the further you go. Being conversative increases the length of the runway and Java has benefited from that. Though, the superiority of Java's version when it finally gets some feature is often debatable. 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.
- kaba0 5y ago
  But Java attempts to “copy” those with an order of magnitude larger ecosystem, with the benefit of all the other optimizations/state of the art GCs that went into the OpenJDK project, and with true backwards compatibility of the billions of lines of code out there. I don’t think that reinventing the wheel would really put us forward. According to the ‘No silver bullets’ article, there is no significant (that is, order of magnitude) productivity improvement in language design since high level languages. The only such bullet is reusing existing libraries. (Also, do note that we still rely heavily on numerical libraries written in fortran)
  - kinjba11 5y ago
    I agree the order of magnitude improvement is no more. Programming in C is much the same as Java. Both are high level curly brace languages. But there is room for improvement still, quite a bit. The fact that Kotlin, Go, etc. were created and became popular supports the fact that large numbers of folks believed that Java's design direction has run it's course to some degree. I may be proven wrong, Valhalla and Loom could be smashing successes and everyone will flock back to Java. But more likely it will take a decade to reap the benefits of the features Valhalla and Loom would provide, benefits already being reaped by other ecosystems right now. 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.
    - kaba0 5y ago
      I would not put kotlin anywhere close to “popular” languages, and go is only getting into that category now. We will see whether they will continue to have support/interest 25 years down the line. 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.

pjmlp 5y ago

Kotlin is not Java vnext, first of all because Jet Brains is "married" with Google's fellowship of Kotlin, secondly because they seem to be focused into creating their own Kotlin based platform, finally OpenJDK will never be rewritten in Kotlin. 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.

vlovich123 5y ago
Rust is quite different to my knowledge. You can mix n match libraries each using a different language version. I don’t know that the art of language changes is tiny either as some of these can be mutually incompatible [1]: > 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.html https://hkalbasi.github.io/mdbook-ra/appendix-05-editions.ht...
- pjmlp 5y ago
  The limit being that the whole program, including all dependent crates need to compiled from source with the same compiler. 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.
  - vlovich123 5y ago
    Totally different ecosystem that’s built around the concept of building from source. Binary libraries and alternate compiler implementations haven’t been a priority. In fact, multiple compiler implementations generally don’t exist until the language is much older than Rust is now. It’ll happen.

Zababa 5y ago

> 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. 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 https://doc.rust-lang.org/edition-guide/editions/index.html