12 ms·

Java is not the most appealing programming language, but you've got to love the JVM, the standard library, all the libraries and frameworks, plus the tooling ar

Java is not the most appealing programming language, but you've got to love the JVM, the standard library, all the libraries and frameworks, plus the tooling around the ecosystem.

smallerfish 4y ago
Hence, Kotlin.
- pjmlp 4y ago
  So when are we getting Kotlin Virtual Machine, designed for Kotlin?
  - MattPalmer1086 4y ago
    Does the JVM impose heavy constraints on Kotlin? I ask because the JVM is an amazing bit of technology that has been battle tested for decades. Would be hard to beat I would think.
    - vips7L 4y ago
      One of the major issues that Kotlin faces is that it’s hard for them to change the VM to provide a feature they want while Java and the OpenJDK developers have the freedom to either change the VM or the language to provide something.
      - MattPalmer1086 4y ago
        Sounds like Kotlin and other JVM languages need greater representation in OpenJDK then, if that would be possible.
      - tadfisher 4y ago
        I don't think it's too burdensome, because they can emulate features until the JVM gets support. I can think of several: - Data classes can become JVM records with the @JvmRecord annotation and some additional type constraints. - Inline classes will certainly become Valhalla value types (hence the required @JvmInline annotation). - Nullable types are supported with compile-time checks and additional runtime checks inserted by the compiler at time-of-use, and if Valhalla adds a nullability marker to the bytecode, Kotlin can support it. - Coroutines/structured-concurrency already uses Executors under the hood, so it's likely that we'll have Loom thread support without any changes to the coroutines APIs (though the standard dispatchers will need to use virtual threads themselves). Coroutines themselves are CPS-transforms of ordinary code and don't need VM support. - Tail-call elimination is supported by transforming to trampolines, something which the JVM will probably never support until Java needs it.
        vips7L 4y ago
        Right but, in my opinion, those all come with ergonomic issues from not being able to change the VM. In general the quality of the feature provided by Java will be better because of their ability to mold the VM to the language. For example syntactic cooperative coroutines vs preemptive coroutines provided by the VM. Kotlin is now stuck with the colored function problem and has the stack trace issues that the Java team is able to avoid by not only being able to change the language. That being said, I think they're both fine languages with different goals.
        tadfisher 4y ago
        I'm not convinced colored functions are a problem, personally. You either color an async function with a Continuation argument and place yields, or you can mark it as a CPS function with a keyword, so it's not like coloring goes away by omitting the keyword. And making async pre-emptive introduces a different kind of complexity that can be just as hard, if not harder, to reason about for anything more complex than "park this thread for IO".
- kaba0 4y ago
  Or Scala, Groovy, Clojure, Ceylon.. we have heard it a few times already.
  - deleted 4y ago
    [deleted]
- derriz 4y ago
  I've a couple of years of experience of using Kotlin. In many ways I loved it, and it would have become my JVM language of choice but over time I've started feeling uncomfortable about recommending it. The language is completely closed and controlled by a single commercial software company and there is no community process involved in its evolution and design. I had believed that this business model of programming language design/ownership died decades ago when everyone abandoned all the bespoke commercial languages/IDEs of the 1980s and early 1990s. The way Jetbrains have scuppered the attempt to provide a reasonable vscode plugin feels like reliving the 1990s where the single company providing the language spec, compilers, IDE and tooling for "their" language and aggressively prevented others from providing alternative tools and compilers. Also compile times are horrendous - even with modern hardware, the compiler barely seems to be able to manage much more than a few 1000 lines/sec. Again, my age means I remember decades ago when compilers/IDEs advertised their performance in terms of 100,000s of lines per second. This means edit/compile/debug workflow is very painful once your project grows to non-toy sizes. I also grew to dislike the ethos of the "community" which basically seemed to involve condescension and passive aggressive responses to to any questions regarding the design of language features particularly by Jetbrains employees. Kotlin is undoubtably a more "modern" feeling of development than Java (or C++ for example) but I'm not sure such vendor lock-in is worth it given many other languages are catching up (including Java) or exceed it. Also I used C# for about a year subsequently and realised that Kotlin stole most of its best features from C#. Languages like Rust, Zig, Swift, etc. are just as "modern".
  - re-thc 4y ago
    It's also a bit all over the place. Kotlin seems to be afraid that Java is catching up and so is branching out to Multiplatform. All in all there are less resources on Kotlin but too many things they want to do. Not only are they building the language but they have to reinvent everything because they don't work on Multiplatform. It used to be simple - a better Java (so it claims). Now I'm not so sure what the direction is.
thangalin 4y ago
Here's a real-world example of using C# to create a set of file paths, aiming to eliminate duplicates. I'd've written this in Java as: Set<File> s = new HashSet<File>(); s.add( new File( "c:/temp" ) ); s.add( new File( "c:/temp" ) ); System.out.println( s.size() ); This prints 1. The C# code: ISet<FileInfo> s = new HashSet<FileInfo>(); s.Add( new FileInfo( "c:/temp" ) ); s.Add( new FileInfo( "c:/temp" ) ); Console.WriteLine( s.Count ); This prints 2. They are line-for-line identical. IMO, Java prints the correct result. C# may have reasons for this behaviour, but when you're looking at the code, it's not obvious that two FileInfo objects for the same paths are not equal. When I wrote KeenWrite[0], I chose Java because of all the reasons you mentioned, plus JavaFX. JavaFX is one of the richest cross-platform GUI libraries available for desktop applications, although it does have quirks. [0]: https://github.com/DaveJarvis/keenwrite https://github.com/DaveJarvis/keenwrite
- mrkeen 4y ago
  I aimed to eliminate duplicates of URLs using that approach in Java. Do they resolve to the same IP? Same URL.
  - electrum 4y ago
    Yeah, URL is from the first release of Java and should be avoided. You want to use URI instead.
- mastax 4y ago
  C# FileInfo uses reference equality, because that's the default for objects and they didn't override it. Why? I suppose they thought of it as a helper to get information about a file (or open it), rather than being a file handle itself. Or perhaps it wasn't clear what value equality meant for FileInfo. If two FileInfo point to the same file, but use different paths (relative paths, case insensitivity, hard links, etc.) should they compare as equal? Java just string-compares the two paths, but that's not what I'd want it to do. (I wouldn't want reference equality either. I'm not a big fan of reference equality, personally, and C# has gotten more value-equality oriented over time.) Doesn't Java also have things that use reference equality? Arrays?

Java is not the most appealing programming language, but you've got to love the JVM, the standard library, all the libraries and frameworks, plus the tooling around the ecosystem.

smallerfish 4y ago

Hence, Kotlin.

pjmlp 4y ago
So when are we getting Kotlin Virtual Machine, designed for Kotlin?
- MattPalmer1086 4y ago
  Does the JVM impose heavy constraints on Kotlin? I ask because the JVM is an amazing bit of technology that has been battle tested for decades. Would be hard to beat I would think.
  - vips7L 4y ago
    One of the major issues that Kotlin faces is that it’s hard for them to change the VM to provide a feature they want while Java and the OpenJDK developers have the freedom to either change the VM or the language to provide something.
    - MattPalmer1086 4y ago
      Sounds like Kotlin and other JVM languages need greater representation in OpenJDK then, if that would be possible.
    - tadfisher 4y ago
      I don't think it's too burdensome, because they can emulate features until the JVM gets support. I can think of several: - Data classes can become JVM records with the @JvmRecord annotation and some additional type constraints. - Inline classes will certainly become Valhalla value types (hence the required @JvmInline annotation). - Nullable types are supported with compile-time checks and additional runtime checks inserted by the compiler at time-of-use, and if Valhalla adds a nullability marker to the bytecode, Kotlin can support it. - Coroutines/structured-concurrency already uses Executors under the hood, so it's likely that we'll have Loom thread support without any changes to the coroutines APIs (though the standard dispatchers will need to use virtual threads themselves). Coroutines themselves are CPS-transforms of ordinary code and don't need VM support. - Tail-call elimination is supported by transforming to trampolines, something which the JVM will probably never support until Java needs it.
      - vips7L 4y ago
        Right but, in my opinion, those all come with ergonomic issues from not being able to change the VM. In general the quality of the feature provided by Java will be better because of their ability to mold the VM to the language. For example syntactic cooperative coroutines vs preemptive coroutines provided by the VM. Kotlin is now stuck with the colored function problem and has the stack trace issues that the Java team is able to avoid by not only being able to change the language. That being said, I think they're both fine languages with different goals.
        tadfisher 4y ago
        I'm not convinced colored functions are a problem, personally. You either color an async function with a Continuation argument and place yields, or you can mark it as a CPS function with a keyword, so it's not like coloring goes away by omitting the keyword. And making async pre-emptive introduces a different kind of complexity that can be just as hard, if not harder, to reason about for anything more complex than "park this thread for IO".
kaba0 4y ago
Or Scala, Groovy, Clojure, Ceylon.. we have heard it a few times already.
- deleted 4y ago
  [deleted]
derriz 4y ago
I've a couple of years of experience of using Kotlin. In many ways I loved it, and it would have become my JVM language of choice but over time I've started feeling uncomfortable about recommending it. The language is completely closed and controlled by a single commercial software company and there is no community process involved in its evolution and design. I had believed that this business model of programming language design/ownership died decades ago when everyone abandoned all the bespoke commercial languages/IDEs of the 1980s and early 1990s. The way Jetbrains have scuppered the attempt to provide a reasonable vscode plugin feels like reliving the 1990s where the single company providing the language spec, compilers, IDE and tooling for "their" language and aggressively prevented others from providing alternative tools and compilers. Also compile times are horrendous - even with modern hardware, the compiler barely seems to be able to manage much more than a few 1000 lines/sec. Again, my age means I remember decades ago when compilers/IDEs advertised their performance in terms of 100,000s of lines per second. This means edit/compile/debug workflow is very painful once your project grows to non-toy sizes. I also grew to dislike the ethos of the "community" which basically seemed to involve condescension and passive aggressive responses to to any questions regarding the design of language features particularly by Jetbrains employees. Kotlin is undoubtably a more "modern" feeling of development than Java (or C++ for example) but I'm not sure such vendor lock-in is worth it given many other languages are catching up (including Java) or exceed it. Also I used C# for about a year subsequently and realised that Kotlin stole most of its best features from C#. Languages like Rust, Zig, Swift, etc. are just as "modern".
- re-thc 4y ago
  It's also a bit all over the place. Kotlin seems to be afraid that Java is catching up and so is branching out to Multiplatform. All in all there are less resources on Kotlin but too many things they want to do. Not only are they building the language but they have to reinvent everything because they don't work on Multiplatform. It used to be simple - a better Java (so it claims). Now I'm not so sure what the direction is.

thangalin 4y ago

Here's a real-world example of using C# to create a set of file paths, aiming to eliminate duplicates. I'd've written this in Java as: Set<File> s = new HashSet<File>(); s.add( new File( "c:/temp" ) ); s.add( new File( "c:/temp" ) ); System.out.println( s.size() ); This prints 1. The C# code: ISet<FileInfo> s = new HashSet<FileInfo>(); s.Add( new FileInfo( "c:/temp" ) ); s.Add( new FileInfo( "c:/temp" ) ); Console.WriteLine( s.Count ); This prints 2. They are line-for-line identical. IMO, Java prints the correct result. C# may have reasons for this behaviour, but when you're looking at the code, it's not obvious that two FileInfo objects for the same paths are not equal. When I wrote KeenWrite[0], I chose Java because of all the reasons you mentioned, plus JavaFX. JavaFX is one of the richest cross-platform GUI libraries available for desktop applications, although it does have quirks. [0]: https://github.com/DaveJarvis/keenwrite https://github.com/DaveJarvis/keenwrite

mrkeen 4y ago
I aimed to eliminate duplicates of URLs using that approach in Java. Do they resolve to the same IP? Same URL.
- electrum 4y ago
  Yeah, URL is from the first release of Java and should be avoided. You want to use URI instead.
mastax 4y ago
C# FileInfo uses reference equality, because that's the default for objects and they didn't override it. Why? I suppose they thought of it as a helper to get information about a file (or open it), rather than being a file handle itself. Or perhaps it wasn't clear what value equality meant for FileInfo. If two FileInfo point to the same file, but use different paths (relative paths, case insensitivity, hard links, etc.) should they compare as equal? Java just string-compares the two paths, but that's not what I'd want it to do. (I wouldn't want reference equality either. I'm not a big fan of reference equality, personally, and C# has gotten more value-equality oriented over time.) Doesn't Java also have things that use reference equality? Arrays?