5 ms·

Can you convince me to use Java? I’ve never used it (only C++, Python, CL) but it feels bloated and dirty.

zapnuk 3y ago
What feels bloated and dirty? Because there is plenty of bloated and dirty stuff in C++ and Python too.
hmottestad 3y ago
You don’t have to use Java. All the languages you’ve mentioned are fine. If you think that using Java to solve a particular problem is a good idea, then you should definitely use Java.
justrealist 3y ago
How could you possibly like C++ but feel that Java is bloated? Like I academically understand disliking Java but this just makes no sense.
- Jensson 3y ago
  C++ allows for much more terse code than java when you do small projects. It is popular in competitive programming for that reason, not just because it runs fast but also because it is really fast to write algorithms in it.
- jjnoakes 3y ago
  I think of Java as more bloated than C++ at runtime - with C++ I can make smaller executables that start up faster, use less memory, etc. But if you are talking about the source code itself, then things are quite different.
- loxias 3y ago
  ??? I'll answer your question with a question: Have you seen https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... ? :) I'm guess that to those of us who remember when Java came out, "FizzBuzz: EE" is what we think of when we think of Java. :P In Java I have to type a bazillion characters to get anything done! And make all these useless directories and files and InterfaceClassFactoryProtocolStreamingSerializer BS. And worry about how that executes. C++? No bloat*, just speed *Yes, there's some _optional_ bloat. But compared to Java? no contest.
  - deleted 3y ago
    [deleted]
  - bcrosby95 3y ago
    When java came out? So mid 90s c++ vs mid 90s java?
  - justrealist 3y ago
    > In Java I have to You have to do literally none of these things to write working Java.
- OJFord 3y ago
  I think people are understanding 'bloated' differently. I agree C++ is bloated in a 'just make it a setting' / 'add this feature' / 'kitchen sink' sort of way. I agree Java is bloated in a boilerplate, empty directories, maybe except for another directory, 'oh god the boilerplate' sort of way.
  - loxias 3y ago
    > I agree C++ is bloated in a 'just make it a setting' / 'add this feature' / 'kitchen sink' sort of way. Interesting. Can you expand on this, explain more? I honestly don't know what you mean or are referring to -- and I'm a heavy modern c++ advocate -- but suspect if I did it might expand my mindset/viewpoint a bit. :)
    - OJFord 3y ago
      Honestly I haven't actually used it since C++14 was new, but it's a common complaint IME that each 'edition' (as Rust would call it, I don't know remember the term, standard?) adds too much, there's too many ways of doing things, variations of pointers, boost, and so on. I think a lot of people wish it had stayed at say C++7, a mature C superset, but that's enough now. I probably should have said 'I understand' rather than 'I agree' - I don't feel strongly, I don't use either of them.
      - loxias 3y ago
        Ohhh, I get what you mean now, thank you! I understand (and mildly disagree). :) Yeah, C++ is a living language, I can respectfully see that bothering some people. I viewed c++98->c++11 as essentially a new language with c++14 and c++17 being "bug fixes" for the "new language" that is c++11. But certainly, it can require more learning about every decade now.
- deaddodo 3y ago
  I mean...Java is run through a VM while C++ is compiled to native code. I can see that being used as a reasonable argument for bloat.
  - kaba0 3y ago
    > run through a VM This is just incorrect use/understanding of Java’s execution model. It does have a runtime, but it is definitely not a VirtualBox VM.
    - deaddodo 3y ago
      What are you talking about? No one brought machine/platform virtualization into this conversation other than you. The bytecode interpreter for Java (and other similar languages) is literally called a Virtual Machine, due to the way it functions: https://en.m.wikipedia.org/wiki/Java_virtual_machine https://en.m.wikipedia.org/wiki/Java_virtual_machine It would seem your understanding of the Java execution model is flawed.
Blackthorn 3y ago
Bloat is a meaningless word. One person's bloat is another's essential.
belter 3y ago
None of the memory problems of C++, the speed of C++ most of the time. Thousands of high quality libraries, a JVM that is a marvel of engineering after 20 years, tooling for development, monitoring and introspection of exceptional quality. Many of the internal tools at the largest Cloud developed in Java. Most enterprise level software. NASA extensive use of Java. A team behind the development who has stunning common sense in resisting the latest fads. Support for IEEE 754 that took years. AOT compilation...The infra behind most internet banking sites out there. Use in high speed trading. What else do you want from the ecosystem?
- hutzlibu 3y ago
  What would be a modern IDE for Java? I remember programming Java in Eclipse. And it was powerful for the time, but everytime I read bloated, I automatically think Eclipse since then..
  - jayd16 3y ago
    IntelliJ is very good.
  - belter 3y ago
    https://www.jetbrains.com/idea/ https://www.jetbrains.com/idea/
    - mdaniel 3y ago
      and also FOSS (Apache 2): https://github.com/JetBrains/intellij-community https://github.com/JetBrains/intellij-community (as well as PyCharm found in the "python" subdirectory)
  - iddan 3y ago
    Another rather new option is VSCode + the Java plugin
  - hugi 3y ago
    Eclipse has seen vast development in the last few years and is fast and easy to use these days.
matsemann 3y ago
What's dirty is trying to get a python project reliably running on all dev computers. Pyenv, venv, wheels, suddenly you need a complete rust or c toolchain etc. With java I haven't had those kind of issues the last decade, it just works. With python it's still a big hassle and everything breaks every update.
- jessekv 3y ago
  To be fair, getting all those scientific library binaries compiled and installed was a huge pain even before python came around. Python's toolchain made it better, but only marginally in some cases.
  - TheFlyingFish 3y ago
    Sadly this isn't just the case for scientific Python. E.g. some widely-used web library (I forget which) recently switched to using a Rust implementation of TLS, and suddenly you needed a working Rust tool chain available to install it. This caused a lot of grief. I love Python, and I've been experimenting with Rust and enjoying it so far, but this situation could have been better handled, I think. I agree 100% about scientific Python though. It's a whole new level of horrible when it comes to dependency management.
cbarrick 3y ago
Throughput in Java can be quite high, and latency can be quite low. You still occasionally get latency spikes from the GC, but these days that's not so bad. (If you are extremely latency sensitive, stick to C++). Dependency injection frameworks are your bread-and-butter in server-side Java, and some can take a while to grok, but Java can be very productive after the chosen framework "clicks" for you. Typically, this means you'll be writing constructors or factory classes that construct your dependencies per request. The way you wire your factories into the system differs by framework, but it often involves using Java's annotation syntax. Not having to worry about memory management is a huge win for productivity over C++. Likewise, constructors in Java are much more sane than in C++. Classical object-oriented programming is intuitive, and Java tends towards the "one obvious way to do something" paradigm. I find it pretty easy to hop into legacy code bases, if I already know the framework being used. The collections API in the standard library is one of the best classical OO APIs out there. The JVM provides great visibility into the performance of your system. A lot of instrumentation comes "for free". I'm not sure where you get the "dirty" and "bloated" feeling from. By any definition I can think of for those words, Python would be in the same bucket.
- Horffupolde 3y ago
  Yes, I agree that Python can feel “dirty”, although not necessarily “bloated.”
  - cbarrick 3y ago
    urllib... getopts... There's as much useless junk in Python's standard library as there is in Java's.
- riku_iki 3y ago
  > Java can be very productive after the chosen framework "clicks" for you. you can chose to not use DI frameworks at all..
  - cbarrick 3y ago
    DI buys you maintainability. Without DI, there's too much flexibility in how objects get constructed. If you want to add new functionality to a legacy code base, it can be difficult to track down the different integration points and slow to plumb through your dependencies. These projects can turn into spaghetti very quickly. DI solves this with a simple recipe: define your functionality, define your dependencies, wire it up to the injector. The pattern is useful in all OO languages, Python and C++ included.
whartung 3y ago
I’m a fan, long time fan, but I can honestly say that I feel Java is one of the most pragmatic development systems on the planet. It can do most anything. It can do it most anywhere. And you can code in it using several different paradigms. It’s easy to install, it’s easy to be instal several versions, the footprint, by today’s standards, is not enormous. It’s easy to deploy, especially server side. While you can certainly do all of that modern stuff with containers and what not, it’s not really necessary for Java. Drag and drop a JDK install, anywhere. Plonk your Java server code, anywhere, and point it at your JDK, and. . .that’s it! Fire it up. The JDK is remarkably light on dependencies. And since most Java apps are “pure Java”, the apps rarely have a dependency outside of the JDK. And since Java apps routinely bundle their Java dependencies, the apps don’t stomp on each other either. Even SQLite bundles it’s binaries in the Java Jar file. So wherever that jar goes (again, and typically bundled with your app), SQLite goes. No floating dependencies. Desktop bundling requires a bit of search engine research, but it’s doable. And the runtimes can dwarf something like Electron installs. As a language is Java ELEGANT? Not particularly. It has its own elegance in some areas but that can break down or get overrun in others. But, boy howdy, it sure is practical. The ecosystem is so huge. It compiles really fast. I marvel at the stories folks tell about their dev cycles in other languages. How do they get anything done, besides sword fighting? I love Java, but I’m very comfortable in it. But the Maven based dependency system works, it’s huge, it makes use and reuse simple. The IDEs are powerful and mature. And, finally, Java’s not dead. Hardly. Oracle has been a surprisingly good steward (with warts, as always). The language has been on a rocket of development and shows no sign of slowing down. Server side is still very hot with all the frameworks and all the different approaches. Things like GraalVM taking the JVM in a whole new direction. And, yea, that. I’ve only been talking Java the language, not the JVM itself per se. That’s a whole other thread.
EdwardDiego 3y ago
I work on a Python codebase now after years of JVM and here's what I miss, static typing taken as read. * Threads that can use more than one core. * The best approach to package management I've ever seen, no-one worries about typosquatting or "someone already registered all the cool crate names" because every package has at least two coördinates - a group id based on a DNS entry you must be able to prove you have access to, then the package name. So I can publish my malicious package gauva, but as I can't register it with the group id "com.google.guava" or even "com.google.gauva", no-one is going to mistakenly use my package. * No fucking dance of the C libs. Or Rust these days. I want to use a Python package that wraps a C lib, but there's no binary wheel built for my version of Python and/or platform arch, so build from source it is. Which I'll figure out when pip install -r breaks, and then I get to a) apt-get/brew/etc. install the lib and/or headers b) install any compiler toolchain needed buy not yet present c) export compiler flags and header locations d) all of the above, and then run my pip install again. Until the next library breaks. * Intersection types for generic bounds. I don't need it that often but when I do, I really miss being to say that for `def foo(ex: T) -> Z`, T must implement interfaces A and B. * Logging. Occasional horrible security holes aside, Java's logging story is one of the best I've ever worked with, compared to it, Go's sucks, Python sucks more, like how you can't set your preferred timestamp format AND include millis without writing a custom formatter (seriously, go look at the source code of logging.Formatter.formatTime...) * JMX and MBeans. Having detailed VM performance metrics and the ability to change exposed values or execute an exposed method at runtime built into the VM is amazing. Want to have a quick look at what's happening with the GC? JConsole in. Want to set one logger in particular to DEBUG to see what's going on in prod without having to restart anything? JConsole or jmxterm and away you go. Want to experiment with your batching parameters under prod load to find the sweet spot for throughput? Expose them via an MBean. * No need for pyenv, virtualenv, etc. Although being fair, if you're working with different incompatible JDK versions, you'll usually end up using SDKMan like Python uses pyenv, and Maven needs a little bit of additional configuration to locate your toolchains, but Gradle is smarter about finding your available JDKs. * Libraries with type signatures, makes for far easier code reading, and if you pass **kwargs 5 levels down, I hate you. Yes you, sentry-sdk... * Libraries with correct type signatures, looking at you confluent-kafka, either publish type stubs to typeshed, or update your goddamn doc-string type hints so my IDE doesn't think that confluent_kafka.Message.value() is missing a parameter. * The ecosystem. I really really really miss the ecosystem of JVM FOSS packages. * The speed, in general. I'm sure there's more, but these are the pain points I've been having of late.
signaru 3y ago
What convinced me to consider Java just recently is GraalVM. I don't know about the "dirty" part, but at least GraalVM might solve the "bloated" part. Compiling to native standalone executables makes a big difference to what Java is traditionally known for (portable bytecode but requiring the JVM). Been using C++ and C# for a long time now, and my pet peeves with these languages were also only just addressed relatively recently (C++ getting modules and native AOT for C#). Java being able to get natively compiled makes it worth considering among these. Now, for me, it's a matter of what other frameworks/libraries available for the respective languages would get the job done while I only have to rewrite little to switch among them if I try my best to stay within their syntax overlap.
speed_spread 3y ago
Java itself is a nice language that can be lean and mean but has long been culturally bloated by early tooling and conventions. Since Java 8 (~10 years) the tide has reversed and it now mostly accepted to write terse code that is to the point. The language gets updated regularly and is managed very competently. Although it may seem to trail on some aspects vs other langs, it benefits from second mover advantage - new features are done right, for the right reasons. Any Java code ever written is essentially eternal, both in text and compiled bytecode form. Compiler and VM compatibility guarantees are unmatched. You can stumble upon 20 year old code and just use it. The platform is mature and robust. The JVM itself is a marvel of engineering. The ecosystem is extremely rich. There isn't a problem that wasn't addressed by a library or a stack overflow question. The tooling is unequalled. IDEs can reliably perform large code transformations because there is no preprocessor or macros and the type system is relatively sane. If you know Java you'll never be out of a job.
deleted 3y ago
[deleted]
wscp-dev 3y ago
Id rather say use kotlin. It comes with a better type system with explicit nullable types, proper closures, and syntactic sugar to easily enavle beneficial programming patterns. Nd it is very compatible with Java itself, interop is dead simple

What feels bloated and dirty? Because there is plenty of bloated and dirty stuff in C++ and Python too.

You don’t have to use Java. All the languages you’ve mentioned are fine. If you think that using Java to solve a particular problem is a good idea, then you should definitely use Java.

justrealist 3y ago

How could you possibly like C++ but feel that Java is bloated? Like I academically understand disliking Java but this just makes no sense.

Jensson 3y ago
C++ allows for much more terse code than java when you do small projects. It is popular in competitive programming for that reason, not just because it runs fast but also because it is really fast to write algorithms in it.
jjnoakes 3y ago
I think of Java as more bloated than C++ at runtime - with C++ I can make smaller executables that start up faster, use less memory, etc. But if you are talking about the source code itself, then things are quite different.
loxias 3y ago
??? I'll answer your question with a question: Have you seen https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... ? :) I'm guess that to those of us who remember when Java came out, "FizzBuzz: EE" is what we think of when we think of Java. :P In Java I have to type a bazillion characters to get anything done! And make all these useless directories and files and InterfaceClassFactoryProtocolStreamingSerializer BS. And worry about how that executes. C++? No bloat*, just speed *Yes, there's some _optional_ bloat. But compared to Java? no contest.
- deleted 3y ago
  [deleted]
- bcrosby95 3y ago
  When java came out? So mid 90s c++ vs mid 90s java?
- justrealist 3y ago
  > In Java I have to You have to do literally none of these things to write working Java.
OJFord 3y ago
I think people are understanding 'bloated' differently. I agree C++ is bloated in a 'just make it a setting' / 'add this feature' / 'kitchen sink' sort of way. I agree Java is bloated in a boilerplate, empty directories, maybe except for another directory, 'oh god the boilerplate' sort of way.
- loxias 3y ago
  > I agree C++ is bloated in a 'just make it a setting' / 'add this feature' / 'kitchen sink' sort of way. Interesting. Can you expand on this, explain more? I honestly don't know what you mean or are referring to -- and I'm a heavy modern c++ advocate -- but suspect if I did it might expand my mindset/viewpoint a bit. :)
  - OJFord 3y ago
    Honestly I haven't actually used it since C++14 was new, but it's a common complaint IME that each 'edition' (as Rust would call it, I don't know remember the term, standard?) adds too much, there's too many ways of doing things, variations of pointers, boost, and so on. I think a lot of people wish it had stayed at say C++7, a mature C superset, but that's enough now. I probably should have said 'I understand' rather than 'I agree' - I don't feel strongly, I don't use either of them.
    - loxias 3y ago
      Ohhh, I get what you mean now, thank you! I understand (and mildly disagree). :) Yeah, C++ is a living language, I can respectfully see that bothering some people. I viewed c++98->c++11 as essentially a new language with c++14 and c++17 being "bug fixes" for the "new language" that is c++11. But certainly, it can require more learning about every decade now.
deaddodo 3y ago
I mean...Java is run through a VM while C++ is compiled to native code. I can see that being used as a reasonable argument for bloat.
- kaba0 3y ago
  > run through a VM This is just incorrect use/understanding of Java’s execution model. It does have a runtime, but it is definitely not a VirtualBox VM.
  - deaddodo 3y ago
    What are you talking about? No one brought machine/platform virtualization into this conversation other than you. The bytecode interpreter for Java (and other similar languages) is literally called a Virtual Machine, due to the way it functions: https://en.m.wikipedia.org/wiki/Java_virtual_machine https://en.m.wikipedia.org/wiki/Java_virtual_machine It would seem your understanding of the Java execution model is flawed.

Blackthorn 3y ago

Bloat is a meaningless word. One person's bloat is another's essential.

belter 3y ago

None of the memory problems of C++, the speed of C++ most of the time. Thousands of high quality libraries, a JVM that is a marvel of engineering after 20 years, tooling for development, monitoring and introspection of exceptional quality. Many of the internal tools at the largest Cloud developed in Java. Most enterprise level software. NASA extensive use of Java. A team behind the development who has stunning common sense in resisting the latest fads. Support for IEEE 754 that took years. AOT compilation...The infra behind most internet banking sites out there. Use in high speed trading. What else do you want from the ecosystem?

hutzlibu 3y ago
What would be a modern IDE for Java? I remember programming Java in Eclipse. And it was powerful for the time, but everytime I read bloated, I automatically think Eclipse since then..
- jayd16 3y ago
  IntelliJ is very good.
- belter 3y ago
  https://www.jetbrains.com/idea/ https://www.jetbrains.com/idea/
  - mdaniel 3y ago
    and also FOSS (Apache 2): https://github.com/JetBrains/intellij-community https://github.com/JetBrains/intellij-community (as well as PyCharm found in the "python" subdirectory)
- iddan 3y ago
  Another rather new option is VSCode + the Java plugin
- hugi 3y ago
  Eclipse has seen vast development in the last few years and is fast and easy to use these days.

matsemann 3y ago

What's dirty is trying to get a python project reliably running on all dev computers. Pyenv, venv, wheels, suddenly you need a complete rust or c toolchain etc. With java I haven't had those kind of issues the last decade, it just works. With python it's still a big hassle and everything breaks every update.

jessekv 3y ago
To be fair, getting all those scientific library binaries compiled and installed was a huge pain even before python came around. Python's toolchain made it better, but only marginally in some cases.
- TheFlyingFish 3y ago
  Sadly this isn't just the case for scientific Python. E.g. some widely-used web library (I forget which) recently switched to using a Rust implementation of TLS, and suddenly you needed a working Rust tool chain available to install it. This caused a lot of grief. I love Python, and I've been experimenting with Rust and enjoying it so far, but this situation could have been better handled, I think. I agree 100% about scientific Python though. It's a whole new level of horrible when it comes to dependency management.

cbarrick 3y ago

Throughput in Java can be quite high, and latency can be quite low. You still occasionally get latency spikes from the GC, but these days that's not so bad. (If you are extremely latency sensitive, stick to C++). Dependency injection frameworks are your bread-and-butter in server-side Java, and some can take a while to grok, but Java can be very productive after the chosen framework "clicks" for you. Typically, this means you'll be writing constructors or factory classes that construct your dependencies per request. The way you wire your factories into the system differs by framework, but it often involves using Java's annotation syntax. Not having to worry about memory management is a huge win for productivity over C++. Likewise, constructors in Java are much more sane than in C++. Classical object-oriented programming is intuitive, and Java tends towards the "one obvious way to do something" paradigm. I find it pretty easy to hop into legacy code bases, if I already know the framework being used. The collections API in the standard library is one of the best classical OO APIs out there. The JVM provides great visibility into the performance of your system. A lot of instrumentation comes "for free". I'm not sure where you get the "dirty" and "bloated" feeling from. By any definition I can think of for those words, Python would be in the same bucket.

Horffupolde 3y ago
Yes, I agree that Python can feel “dirty”, although not necessarily “bloated.”
- cbarrick 3y ago
  urllib... getopts... There's as much useless junk in Python's standard library as there is in Java's.
riku_iki 3y ago
> Java can be very productive after the chosen framework "clicks" for you. you can chose to not use DI frameworks at all..
- cbarrick 3y ago
  DI buys you maintainability. Without DI, there's too much flexibility in how objects get constructed. If you want to add new functionality to a legacy code base, it can be difficult to track down the different integration points and slow to plumb through your dependencies. These projects can turn into spaghetti very quickly. DI solves this with a simple recipe: define your functionality, define your dependencies, wire it up to the injector. The pattern is useful in all OO languages, Python and C++ included.

whartung 3y ago

I’m a fan, long time fan, but I can honestly say that I feel Java is one of the most pragmatic development systems on the planet. It can do most anything. It can do it most anywhere. And you can code in it using several different paradigms. It’s easy to install, it’s easy to be instal several versions, the footprint, by today’s standards, is not enormous. It’s easy to deploy, especially server side. While you can certainly do all of that modern stuff with containers and what not, it’s not really necessary for Java. Drag and drop a JDK install, anywhere. Plonk your Java server code, anywhere, and point it at your JDK, and. . .that’s it! Fire it up. The JDK is remarkably light on dependencies. And since most Java apps are “pure Java”, the apps rarely have a dependency outside of the JDK. And since Java apps routinely bundle their Java dependencies, the apps don’t stomp on each other either. Even SQLite bundles it’s binaries in the Java Jar file. So wherever that jar goes (again, and typically bundled with your app), SQLite goes. No floating dependencies. Desktop bundling requires a bit of search engine research, but it’s doable. And the runtimes can dwarf something like Electron installs. As a language is Java ELEGANT? Not particularly. It has its own elegance in some areas but that can break down or get overrun in others. But, boy howdy, it sure is practical. The ecosystem is so huge. It compiles really fast. I marvel at the stories folks tell about their dev cycles in other languages. How do they get anything done, besides sword fighting? I love Java, but I’m very comfortable in it. But the Maven based dependency system works, it’s huge, it makes use and reuse simple. The IDEs are powerful and mature. And, finally, Java’s not dead. Hardly. Oracle has been a surprisingly good steward (with warts, as always). The language has been on a rocket of development and shows no sign of slowing down. Server side is still very hot with all the frameworks and all the different approaches. Things like GraalVM taking the JVM in a whole new direction. And, yea, that. I’ve only been talking Java the language, not the JVM itself per se. That’s a whole other thread.

EdwardDiego 3y ago

I work on a Python codebase now after years of JVM and here's what I miss, static typing taken as read. * Threads that can use more than one core. * The best approach to package management I've ever seen, no-one worries about typosquatting or "someone already registered all the cool crate names" because every package has at least two coördinates - a group id based on a DNS entry you must be able to prove you have access to, then the package name. So I can publish my malicious package gauva, but as I can't register it with the group id "com.google.guava" or even "com.google.gauva", no-one is going to mistakenly use my package. * No fucking dance of the C libs. Or Rust these days. I want to use a Python package that wraps a C lib, but there's no binary wheel built for my version of Python and/or platform arch, so build from source it is. Which I'll figure out when pip install -r breaks, and then I get to a) apt-get/brew/etc. install the lib and/or headers b) install any compiler toolchain needed buy not yet present c) export compiler flags and header locations d) all of the above, and then run my pip install again. Until the next library breaks. * Intersection types for generic bounds. I don't need it that often but when I do, I really miss being to say that for `def foo(ex: T) -> Z`, T must implement interfaces A and B. * Logging. Occasional horrible security holes aside, Java's logging story is one of the best I've ever worked with, compared to it, Go's sucks, Python sucks more, like how you can't set your preferred timestamp format AND include millis without writing a custom formatter (seriously, go look at the source code of logging.Formatter.formatTime...) * JMX and MBeans. Having detailed VM performance metrics and the ability to change exposed values or execute an exposed method at runtime built into the VM is amazing. Want to have a quick look at what's happening with the GC? JConsole in. Want to set one logger in particular to DEBUG to see what's going on in prod without having to restart anything? JConsole or jmxterm and away you go. Want to experiment with your batching parameters under prod load to find the sweet spot for throughput? Expose them via an MBean. * No need for pyenv, virtualenv, etc. Although being fair, if you're working with different incompatible JDK versions, you'll usually end up using SDKMan like Python uses pyenv, and Maven needs a little bit of additional configuration to locate your toolchains, but Gradle is smarter about finding your available JDKs. * Libraries with type signatures, makes for far easier code reading, and if you pass **kwargs 5 levels down, I hate you. Yes you, sentry-sdk... * Libraries with correct type signatures, looking at you confluent-kafka, either publish type stubs to typeshed, or update your goddamn doc-string type hints so my IDE doesn't think that confluent_kafka.Message.value() is missing a parameter. * The ecosystem. I really really really miss the ecosystem of JVM FOSS packages. * The speed, in general. I'm sure there's more, but these are the pain points I've been having of late.

signaru 3y ago

What convinced me to consider Java just recently is GraalVM. I don't know about the "dirty" part, but at least GraalVM might solve the "bloated" part. Compiling to native standalone executables makes a big difference to what Java is traditionally known for (portable bytecode but requiring the JVM). Been using C++ and C# for a long time now, and my pet peeves with these languages were also only just addressed relatively recently (C++ getting modules and native AOT for C#). Java being able to get natively compiled makes it worth considering among these. Now, for me, it's a matter of what other frameworks/libraries available for the respective languages would get the job done while I only have to rewrite little to switch among them if I try my best to stay within their syntax overlap.

speed_spread 3y ago

Java itself is a nice language that can be lean and mean but has long been culturally bloated by early tooling and conventions. Since Java 8 (~10 years) the tide has reversed and it now mostly accepted to write terse code that is to the point. The language gets updated regularly and is managed very competently. Although it may seem to trail on some aspects vs other langs, it benefits from second mover advantage - new features are done right, for the right reasons. Any Java code ever written is essentially eternal, both in text and compiled bytecode form. Compiler and VM compatibility guarantees are unmatched. You can stumble upon 20 year old code and just use it. The platform is mature and robust. The JVM itself is a marvel of engineering. The ecosystem is extremely rich. There isn't a problem that wasn't addressed by a library or a stack overflow question. The tooling is unequalled. IDEs can reliably perform large code transformations because there is no preprocessor or macros and the type system is relatively sane. If you know Java you'll never be out of a job.

deleted 3y ago

[deleted]

wscp-dev 3y ago

Id rather say use kotlin. It comes with a better type system with explicit nullable types, proper closures, and syntactic sugar to easily enavle beneficial programming patterns. Nd it is very compatible with Java itself, interop is dead simple