5 ms·

Compare writing Java professionally with writing Kotlin professionally. It's like night and day. Same projects, same VM, all that's different is the language.

Compare writing Java professionally with writing Kotlin professionally. It's like night and day. Same projects, same VM, all that's different is the language. Distaste for Java isn't elitism or arrogance, it's just that the language is so damn painful to write. If you start your career with Java (as I did), dipping your toe into another[0] language for the first time feels like Neo being ejected from the matrix and waking up to reality. You realize your eyes are finally open, you're awake, and you can see that all that pain was just what Java saddles you with, and wasn't "the way programming is done (TM)". [0] depends on which language, of course. Java to C# isn't a big jump.

ajuc 5y ago
Could you write your top 3 Java pain points? I started working in C++, moved to Java, used several other languages commercially (Python, JS, PHP, Groovy, Kotlin), and about dozen other languages for personal projects including the hip ones like Clojure, Prolog, Ruby. My first programming languages were C64 BASIC and Turbo Pascal. I've written some Ada and SML. And I just don't understand the Java hate.
- ArnoVW 5y ago
  Haven't upgraded Java since version 9, so take this with a cube of salt (my suspicion is that many hardcore Java haters were created by Java 5, 6 etc).. but my general issue is the readability. The idioms used to perform 'standard' things are verbose. The worst for me is that it's impossible to catch exceptions in lambdas. The absence of named or optional parameters. Mind you, I'm only saying that after having spent 2 years in Kotlin. The Stockholm syndrom is real: you don't realize how much better things can be from the inside. Programming has become enjoyable again, my work 'feels' cleaner, more readable. Null safety makes reasoning about code that much easier. I can switch to functional programming when it's convenient. I keep all the tooling from Java, including the amazing IntelliJ IDE. At the end of the day, choices are a matter of arbitration. Do I want the speed of C, the ecosystem and resource pool of Java, the locality / mathematical guarantees of functional languages, and the IntelliJ IDE? Sure. But they don't exist in one language. So when I'm programming embedded, it's C. When I'm creating a complex data treatment pipeline for machine learning, it's Scala. And when I'm making a CRUD application that will have to support a team of 15 developers hacking on it for a decade, I'll go with Kotlin.
  - blazespitfire 5y ago
    All the problems here are solved till Java 15 in every iteration. A lot of opinion in Java is based on comparing old versions of Java with latest version of other languages
  - smitty1e 5y ago
    Java, in my experience of having to puzzle out a couple of large codebases in my career (that is, not having been a serious developer) is what happens when a couple of idioms run amok. Inversion of control, interfaces, and OO make wandering a codebase feel like being lost in a bureaucracy. Then we het to the issue of projects being coupled to IDEs. "Oh, this is an Eclipse project." "Oh, this is IntelliJ". All of that chrome and tailfin leads to projects that take longer to boot than the OS. The disdain for Java may be less about the language per se than the attendant mindset.
    - Viliam1234 5y ago
      > Then we het to the issue of projects being coupled to IDEs. "Oh, this is an Eclipse project." "Oh, this is IntelliJ". We use Maven projects, and edit them in whatever people prefer to use.
      - ajuc 5y ago
        Yeah that's a weird complaint. Java build system situation is better than most other languages. Especially C++ is in stone age comparatively.
        smitty1e 5y ago
        Maybe it was more historically true. Then there was the Ant vs. Maven vs. Gradle thing. This would not be such a complaint (look at the explosion of build systems everywhere) if Java were less touted as "write once, run anywhere". Build systems and configuration management are two hard problems.
        5y ago
- austincheney 5y ago
  I have worked in Java shops my entire career (Travelocity, Orbitz, Expedia, Southwest, Bank of America) and have lots of pain points. In these cases Java is used to prop up a web server and typically with Spring. Pain points: * Stack traces seem to run to 500+ lines and nobody reads them. * The processes, release management, and integration of code in a Java environment is glacial slow and obtuse featuring very low automation and many large teams of dev ops. The very idea continuous deployment is absent. Code releases occur at regular intervals quarterly or monthly if you are super fast and it feels like moving a continent. All of that slowness and super man power also applies to everything else not written in Java like riding on the back of a retardant elephant. * Java applications running enterprise web servers are monolith beasts like the Great Wall of China wrapping the Pacific. Refactoring in those applications feels like inventing a new language while sinking in quicksand. Writing a JavaScript application in a massive MVC framework feels like that too but Java is orders of magnitude worse. * What I really don’t understand is that Java is such a fast language but large enterprise web server applications written in Java always feel so slow in user experience in production. It just feels like something from the late 90s. That slow becomes the baseline experience to internal development by which all user experience ultimately suffers. There is no reason pages from these servers should take 5-20 seconds to fully load in the browser even though the page is a light smattering of static text with sprinkles of CSS and JS. I have an application in TypeScript that emulates the front half of an operating system and it fully loads in the browser in 0.3-0.8 seconds (averaging around 0.65 seconds).
  - js8 5y ago
    > What I really don’t understand is that Java is such a fast language but large enterprise web server applications written in Java always feel so slow in user experience in production. It just feels like something from the late 90s. My personal suspicion is that the programming style used in Java (OOP and patterns) together with the fact that everything is a reference, and everything is implemented in Java itself way down, kills the cache locality, which is the thing that makes modern computers fast. Yes, you can write fast Java programs, if you keep abstractions to a minimum, use arrays rather than objects when allocating, and take advantage of the JIT compiler. But these are more lab conditions (which are great for benchmarks) rather than the real world conditions. I think finally having a proper record type in Java will help to fix this.
- nmfisher 5y ago
  Bear in mind that I've written almost no Java since 8, so this may well be out-of-date. With that in mind, though, the biggest gripe I have, by far, is its needless verbosity. It always feels like I need a huge amount of boilerplate and repeated keystrokes to get things done. My fingers literally get more sore writing Java than anything other language. Lack of extension methods is probably my next complaint, because you end up fumbling about writing a lot of code to address what should be Lack of null-safety would be the next one, too. I'd say around 90% of my runtime errors are due to improper null handling, so this would cut down a huge source of errors. On par would be painful deployment (and to a degree, package management). For some reason Java always felt like it needed an industrial-size team to get anything actually up and running, and needed more hardware than any other language. That might not be fair, but I think it's definitely fair to say that deployment is not Java's strong point.
  - denton-scratch 5y ago
    "more hardware than any other language" It doesn't, in fact; but configuring a Java application to run well with minimal resources is a problem that isn't a programming problem, it requires a separate skillset. So you end up with build specialists, and deployment specialists, which in turn results in long deployment timetables.
  - bluefirebrand 5y ago
    > With that in mind, though, the biggest gripe I have, by far, is its needless verbosity. It always feels like I need a huge amount of boilerplate and repeated keystrokes to get things done. This is my biggest complaint about OOP development in general and languages like Java and C# that are heavily invested in OOP paradigms are miserable for me as a result.
deleted 5y ago
[deleted]

ajuc 5y ago

Could you write your top 3 Java pain points? I started working in C++, moved to Java, used several other languages commercially (Python, JS, PHP, Groovy, Kotlin), and about dozen other languages for personal projects including the hip ones like Clojure, Prolog, Ruby. My first programming languages were C64 BASIC and Turbo Pascal. I've written some Ada and SML. And I just don't understand the Java hate.

ArnoVW 5y ago
Haven't upgraded Java since version 9, so take this with a cube of salt (my suspicion is that many hardcore Java haters were created by Java 5, 6 etc).. but my general issue is the readability. The idioms used to perform 'standard' things are verbose. The worst for me is that it's impossible to catch exceptions in lambdas. The absence of named or optional parameters. Mind you, I'm only saying that after having spent 2 years in Kotlin. The Stockholm syndrom is real: you don't realize how much better things can be from the inside. Programming has become enjoyable again, my work 'feels' cleaner, more readable. Null safety makes reasoning about code that much easier. I can switch to functional programming when it's convenient. I keep all the tooling from Java, including the amazing IntelliJ IDE. At the end of the day, choices are a matter of arbitration. Do I want the speed of C, the ecosystem and resource pool of Java, the locality / mathematical guarantees of functional languages, and the IntelliJ IDE? Sure. But they don't exist in one language. So when I'm programming embedded, it's C. When I'm creating a complex data treatment pipeline for machine learning, it's Scala. And when I'm making a CRUD application that will have to support a team of 15 developers hacking on it for a decade, I'll go with Kotlin.
- blazespitfire 5y ago
  All the problems here are solved till Java 15 in every iteration. A lot of opinion in Java is based on comparing old versions of Java with latest version of other languages
- smitty1e 5y ago
  Java, in my experience of having to puzzle out a couple of large codebases in my career (that is, not having been a serious developer) is what happens when a couple of idioms run amok. Inversion of control, interfaces, and OO make wandering a codebase feel like being lost in a bureaucracy. Then we het to the issue of projects being coupled to IDEs. "Oh, this is an Eclipse project." "Oh, this is IntelliJ". All of that chrome and tailfin leads to projects that take longer to boot than the OS. The disdain for Java may be less about the language per se than the attendant mindset.
  - Viliam1234 5y ago
    > Then we het to the issue of projects being coupled to IDEs. "Oh, this is an Eclipse project." "Oh, this is IntelliJ". We use Maven projects, and edit them in whatever people prefer to use.
    - ajuc 5y ago
      Yeah that's a weird complaint. Java build system situation is better than most other languages. Especially C++ is in stone age comparatively.
      - smitty1e 5y ago
        Maybe it was more historically true. Then there was the Ant vs. Maven vs. Gradle thing. This would not be such a complaint (look at the explosion of build systems everywhere) if Java were less touted as "write once, run anywhere". Build systems and configuration management are two hard problems.
        5y ago
austincheney 5y ago
I have worked in Java shops my entire career (Travelocity, Orbitz, Expedia, Southwest, Bank of America) and have lots of pain points. In these cases Java is used to prop up a web server and typically with Spring. Pain points: * Stack traces seem to run to 500+ lines and nobody reads them. * The processes, release management, and integration of code in a Java environment is glacial slow and obtuse featuring very low automation and many large teams of dev ops. The very idea continuous deployment is absent. Code releases occur at regular intervals quarterly or monthly if you are super fast and it feels like moving a continent. All of that slowness and super man power also applies to everything else not written in Java like riding on the back of a retardant elephant. * Java applications running enterprise web servers are monolith beasts like the Great Wall of China wrapping the Pacific. Refactoring in those applications feels like inventing a new language while sinking in quicksand. Writing a JavaScript application in a massive MVC framework feels like that too but Java is orders of magnitude worse. * What I really don’t understand is that Java is such a fast language but large enterprise web server applications written in Java always feel so slow in user experience in production. It just feels like something from the late 90s. That slow becomes the baseline experience to internal development by which all user experience ultimately suffers. There is no reason pages from these servers should take 5-20 seconds to fully load in the browser even though the page is a light smattering of static text with sprinkles of CSS and JS. I have an application in TypeScript that emulates the front half of an operating system and it fully loads in the browser in 0.3-0.8 seconds (averaging around 0.65 seconds).
- js8 5y ago
  > What I really don’t understand is that Java is such a fast language but large enterprise web server applications written in Java always feel so slow in user experience in production. It just feels like something from the late 90s. My personal suspicion is that the programming style used in Java (OOP and patterns) together with the fact that everything is a reference, and everything is implemented in Java itself way down, kills the cache locality, which is the thing that makes modern computers fast. Yes, you can write fast Java programs, if you keep abstractions to a minimum, use arrays rather than objects when allocating, and take advantage of the JIT compiler. But these are more lab conditions (which are great for benchmarks) rather than the real world conditions. I think finally having a proper record type in Java will help to fix this.
nmfisher 5y ago
Bear in mind that I've written almost no Java since 8, so this may well be out-of-date. With that in mind, though, the biggest gripe I have, by far, is its needless verbosity. It always feels like I need a huge amount of boilerplate and repeated keystrokes to get things done. My fingers literally get more sore writing Java than anything other language. Lack of extension methods is probably my next complaint, because you end up fumbling about writing a lot of code to address what should be Lack of null-safety would be the next one, too. I'd say around 90% of my runtime errors are due to improper null handling, so this would cut down a huge source of errors. On par would be painful deployment (and to a degree, package management). For some reason Java always felt like it needed an industrial-size team to get anything actually up and running, and needed more hardware than any other language. That might not be fair, but I think it's definitely fair to say that deployment is not Java's strong point.
- denton-scratch 5y ago
  "more hardware than any other language" It doesn't, in fact; but configuring a Java application to run well with minimal resources is a problem that isn't a programming problem, it requires a separate skillset. So you end up with build specialists, and deployment specialists, which in turn results in long deployment timetables.
- bluefirebrand 5y ago
  > With that in mind, though, the biggest gripe I have, by far, is its needless verbosity. It always feels like I need a huge amount of boilerplate and repeated keystrokes to get things done. This is my biggest complaint about OOP development in general and languages like Java and C# that are heavily invested in OOP paradigms are miserable for me as a result.

deleted 5y ago

[deleted]