4 ms·

I recently started a side new project in Java targetting GraalVM with language version 17. Aside from Java's innate finickyness, it has been an unexpected plea

I recently started a side new project in Java targetting GraalVM with language version 17. Aside from Java's innate finickyness, it has been an unexpected pleasure. I think a lot of it has to do with its static typing (I typically work in dynamic languages, and it's nice knowing that if the program compiles it likely works), and how simple the language keeps its primitives. But you need really good tooling to use it, like a powerful IDE with good autocompletion and refactor support. It is way too verbose to type everything out yourself, and the verbosity means manually refactoring takes lots of changes around the program to manifest. The sheer amount of code out there to import is immense, there seem to be libraries for anything and everything! So far, it seems like the time I lose to its pickiness, I gain back with IDE features, static typing, and the ease of understanding it (because it is so verbose). I'm also not hot on how it seems to steer everything into a factory pattern, but so far I've been able to avoid that for most things.

binkHN 4y ago
Have you explored Kotlin? It's really not just for Android.
- nerdponx 4y ago
  I've heard from a few corners that Kotlin is "Java but better", but I've also heard that the tooling is pretty lacking if you aren't using JetBrains stuff. True?
  - dboreham 4y ago
    Successfully used VSCode for Kotlin projects.
  - deleted 4y ago
    [deleted]
- pdntspa 4y ago
  I have, it's a nice language but I didn't like the mental tax of translating Java code to Kotlin in my head whenever I had to read up on how to do something I do intend to dig into it a bit more once I feel like I have mastered Java
  - binkHN 4y ago
    I hear you, and had to do the same for a while. Eventually your brain migrates over and it becomes second nature. The ability to copy Java code and paste it as Kotlin helps tremendously, especially in the beginning.
  - KronisLV 4y ago
    > I have, it's a nice language but I didn't like the mental tax of translating Java code to Kotlin in my head whenever I had to read up on how to do something You can always let your IDE also do some of the work, at least for a quick reference: https://www.jetbrains.com/help/idea/get-started-with-kotlin.html#1550a751 https://www.jetbrains.com/help/idea/get-started-with-kotlin.... Of course, when you get into slightly different idioms or design pattern implementations, things might require a bit more mental effort and manual work.
dehrmann 4y ago
> But you need really good tooling to use it, like a powerful IDE with good autocompletion and refactor support. It is way too verbose to type everything out yourself, and the verbosity means manually refactoring takes lots of changes around the program to manifest. One of the ironies of Java has been that its strictness and verbosity can make it hard to develop, but that strictness also enabled the development of powerful IDEs. What feels like a hassle for a 100 line file becomes an asset for a million-line project because of the safety, discoverability, and refactoring it enables.
- pdntspa 4y ago
  Indeed; I haven't seen a ton of bad code in it (not saying that it's not out there, just that I haven't been exposed to much of it), but when I needed to dig into how something works, so far it has been very easy to scan and mentally parse what's going on.
- gorjusborg 4y ago
  > What feels like a hassle for a 100 line file becomes an asset for a million-line project This is true and hard to communicate to people that haven't lived it.
- kuboble 4y ago
  Yes. I worked many years in both Java and C#. In Java every project and codebase I saw was pretty much the same. In c# when I look at other people's projects I often feel like it's a foreign language. You can make it look like C++ with unsafe blocks. You can nake it look like ruby with dynamic variables. You can write sql-like statements. As much as I love writing in C#, I prefer reading other people's Java.
hedora 4y ago
My main problem with Java is that it's picky, and has some static typing, but it also has heaps and heaps of loopholes in the type system (that turn into runtime exceptions), so it's this weird compromise where everything is substandard. I've found that Go "feels" a lot more like a dynamically typed language, but still has the good IDE support that you're talking about. If you want to see how much progress there has been in production-quality statically typed languages, write some multithreaded code in Rust. In addition to being memory safe without a GC, the compiler also confirms that your code is threadsafe. Both those guarantees can be violated using the "unsafe" keyword; Java has similar mechanisms that break memory safety. Java doesn't provide meaningful thread safety, in the same way that C's malloc/free don't provide meaningful memory safety -- it's possible to write thread- and memory-safe programs in both languages, but the Java compiler doesn't really help out much with thread safety, just like the C compiler doesn't typically check for use-after-free, etc. Go's thread safety semantics are closer to Java's than Rust's (though multithreaded programming in Go is more ergonomic than in the other two languages).
- pdntspa 4y ago
  I've read enough critiques of Rust to be put off from trying it out at this time. And there's a lot of things I don't like about Go. (Zig is interesting though) Unfortunately Rust doesn't have the kind of library support that Java does, and I don't really want to roll my own on some things (the side project will never get done if I get lost in the weeds) For this project the choice fell between Java and C#, and Java won because I was familiar with the library code that does what I want to do. Besides, Java has Swing, which is about the only cross-platform GUI toolkit I can stand to work with (GTK as a close second) > but it also has heaps and heaps of loopholes in the type system (that turn into runtime exceptions) I've yet to run into this in places where I don't really expect it. Do you have some examples of where this becomes a problem? I wrote a bunch of reflection code that triggered a lot of RuntimeErrors, but that was foreseeable as its reflection, the whole point is to figure out types and whatnot during runtime. And at that point, I just fall back to how I write code in dynamic languages.
- kaba0 4y ago
  > In addition to being memory safe without a GC, the compiler also confirms that your code is threadsafe. No, not at all. Rust verifies that your code has no data-races. That is an absolutely tiny subset of all race conditions, that are simply not verifiable statically.

binkHN 4y ago

Have you explored Kotlin? It's really not just for Android.

nerdponx 4y ago
I've heard from a few corners that Kotlin is "Java but better", but I've also heard that the tooling is pretty lacking if you aren't using JetBrains stuff. True?
- dboreham 4y ago
  Successfully used VSCode for Kotlin projects.
- deleted 4y ago
  [deleted]
pdntspa 4y ago
I have, it's a nice language but I didn't like the mental tax of translating Java code to Kotlin in my head whenever I had to read up on how to do something I do intend to dig into it a bit more once I feel like I have mastered Java
- binkHN 4y ago
  I hear you, and had to do the same for a while. Eventually your brain migrates over and it becomes second nature. The ability to copy Java code and paste it as Kotlin helps tremendously, especially in the beginning.
- KronisLV 4y ago
  > I have, it's a nice language but I didn't like the mental tax of translating Java code to Kotlin in my head whenever I had to read up on how to do something You can always let your IDE also do some of the work, at least for a quick reference: https://www.jetbrains.com/help/idea/get-started-with-kotlin.html#1550a751 https://www.jetbrains.com/help/idea/get-started-with-kotlin.... Of course, when you get into slightly different idioms or design pattern implementations, things might require a bit more mental effort and manual work.

dehrmann 4y ago

> But you need really good tooling to use it, like a powerful IDE with good autocompletion and refactor support. It is way too verbose to type everything out yourself, and the verbosity means manually refactoring takes lots of changes around the program to manifest. One of the ironies of Java has been that its strictness and verbosity can make it hard to develop, but that strictness also enabled the development of powerful IDEs. What feels like a hassle for a 100 line file becomes an asset for a million-line project because of the safety, discoverability, and refactoring it enables.

pdntspa 4y ago
Indeed; I haven't seen a ton of bad code in it (not saying that it's not out there, just that I haven't been exposed to much of it), but when I needed to dig into how something works, so far it has been very easy to scan and mentally parse what's going on.
gorjusborg 4y ago
> What feels like a hassle for a 100 line file becomes an asset for a million-line project This is true and hard to communicate to people that haven't lived it.
kuboble 4y ago
Yes. I worked many years in both Java and C#. In Java every project and codebase I saw was pretty much the same. In c# when I look at other people's projects I often feel like it's a foreign language. You can make it look like C++ with unsafe blocks. You can nake it look like ruby with dynamic variables. You can write sql-like statements. As much as I love writing in C#, I prefer reading other people's Java.

hedora 4y ago

My main problem with Java is that it's picky, and has some static typing, but it also has heaps and heaps of loopholes in the type system (that turn into runtime exceptions), so it's this weird compromise where everything is substandard. I've found that Go "feels" a lot more like a dynamically typed language, but still has the good IDE support that you're talking about. If you want to see how much progress there has been in production-quality statically typed languages, write some multithreaded code in Rust. In addition to being memory safe without a GC, the compiler also confirms that your code is threadsafe. Both those guarantees can be violated using the "unsafe" keyword; Java has similar mechanisms that break memory safety. Java doesn't provide meaningful thread safety, in the same way that C's malloc/free don't provide meaningful memory safety -- it's possible to write thread- and memory-safe programs in both languages, but the Java compiler doesn't really help out much with thread safety, just like the C compiler doesn't typically check for use-after-free, etc. Go's thread safety semantics are closer to Java's than Rust's (though multithreaded programming in Go is more ergonomic than in the other two languages).

pdntspa 4y ago
I've read enough critiques of Rust to be put off from trying it out at this time. And there's a lot of things I don't like about Go. (Zig is interesting though) Unfortunately Rust doesn't have the kind of library support that Java does, and I don't really want to roll my own on some things (the side project will never get done if I get lost in the weeds) For this project the choice fell between Java and C#, and Java won because I was familiar with the library code that does what I want to do. Besides, Java has Swing, which is about the only cross-platform GUI toolkit I can stand to work with (GTK as a close second) > but it also has heaps and heaps of loopholes in the type system (that turn into runtime exceptions) I've yet to run into this in places where I don't really expect it. Do you have some examples of where this becomes a problem? I wrote a bunch of reflection code that triggered a lot of RuntimeErrors, but that was foreseeable as its reflection, the whole point is to figure out types and whatnot during runtime. And at that point, I just fall back to how I write code in dynamic languages.
kaba0 4y ago
> In addition to being memory safe without a GC, the compiler also confirms that your code is threadsafe. No, not at all. Rust verifies that your code has no data-races. That is an absolutely tiny subset of all race conditions, that are simply not verifiable statically.