5 ms·

I discontinued using Java about 5 years ago after using it for what seems 20 years. Everyone was sold on Java for making beautiful, very well organized code bas

I discontinued using Java about 5 years ago after using it for what seems 20 years. Everyone was sold on Java for making beautiful, very well organized code bases that are VERY easy to understand, debug, and edit. And of course run-everywhere. I know a lot of people dispute that, but it's pretty much true with some various exceptions. Sun held it's promises. It's a damn beautiful language. I stopped using it because I stopped wanting to write 10000 lines for doing simple things. I want to write less code now. I know it's not as beautiful but it's definitely easy enough to read, easy enough to debug and edit. I don't want to make a new file for every, little, thing. I just want to process some data here and make a script there and handle problems, not code. This is just my perspective.

k__ 5y ago
Interesting. From an outside perspective, I had the impression Java devs would migrate to Kotlin.
- dehrmann 5y ago
  Kotlin is nice, but setting up the build system can be a bit clunky, stack traces aren't quite as clear, it's more of a moving target, and important things like record classes are making it into Java. I tried it, but realized the code ended up being similar, just with less boilerplate, and switched back to Java. I feel like Scala went through a similar lifecycle. It looked amazing, supported lots of coding paradigms, but had a lousy build system. Once Java added lambdas, it was good enough, and Scala wasn't worth the hassle. Also, remember Groovy?
  - k__ 5y ago
    I see. I had the impression the Java build system was rather convulted.
    - rhacker 5y ago
      It had a reputation for this in the days of ANT. However Maven (and to some degree gradle) kinda made it a non-issue.
      - pjmlp 5y ago
        Gradle is Ant for devs that never lived through Ant build hell.
      - k__ 5y ago
        I heard that years ago, but I never worked with ANT. My "convulted build system" experiences all came from Maven and Gradle.
        Alupis 5y ago
        Then I dare say you do not know the meaning of "convoluted build system". Thousands, or tens of thousands of lines of semi-proprietary/non-standard XML is what made up ANT build scripts... mostly or entirely hand written for each and every project. Even small hobby projects had build scripts in the thousands of lines... there was no such thing as dependency management, and nothing came "for free". Every single thing had to be hand written into the script because ANT didn't have any inkling what you might want to do... build targets layered upon each other until rationalizing about what happens when during the build becomes a full time job all in it's own. Maven is amazing. With a few lines of XML you can successfully build nearly every project, manage all dependencies, etc. The trade-off? It's extremely opinionated in how your project is managed and how it's laid out. Worth while in most cases.
        k__ 5y ago
        Good point. I guess, for me, everything that is XML is just convulted legacy stuff.
        Alupis 5y ago
        I can understand, although I find modern tooling makes XML painless, at least for me.
  - dangets 5y ago
    I'm sold on Kotlin and have been working professionally in it for a few years (mixed Kotlin/Java projects server-side), so take my opinion for what it's worth. Integrating with Java's existing build systems (Gradle, Maven) was one of JetBrains initial design goals to avoid the separate ecosystem requirement that initially came with Scala. I admit building Kotlin has some quirks, notably around annotation processors - but overall it is very seamless. I am happy Java is adding new stuff (records, switch expressions, sealed classes), but I worry it is increasing overall language complexity vs. the fresh start that Kotlin was able to take. Supporting the legacy patterns in the language adds to the complexity any given Java developer is supposed to know. Overall I think the sane defaults and nudges towards the right patterns Kotlin pushes are a much bigger deal than just reducing boilerplate - though that is nice too.
- vips7L 5y ago
  Personally I'm not sold on Kotlin. I don't think it offers much for me over Java 17. Maybe nullable types? But I haven't had problems with null in years.
  - deepsun 5y ago
    It's just a syntactic sugar. E.g. allowing last functional parameter to be specified after the closing parentheses makes possible to create interesting structures that look more like config file than procedural code. But in general it's just the same Java, e.g. you would search for "how to do that in Java", not "in Kotlin".
    - NoSorryCannot 5y ago
      Kotlin has more compilation targets than Java, so I don't know that you can say that.
      - deleted 5y ago
        [deleted]
    - zorr 5y ago
      It started out that way but in my eyes it has evolved to much more than just syntactic sugar. While Kotlin closures, receiver arguments, "it", extension functions, nullability operator, var/val, "when" pattern matching, sealed classes and smartcasts are mostly implemented as syntactic sugar, combining all of the above enables some interesting programming patterns. Some examples are Compose for building reactive/functional UI and TornadoFX for declarative UI on top of JavaFX. Coroutines and suspend functions provide structured concurrency and an async paradigm that interopts well with the "old" Java CompletableFuture apis and existing libraries. Kotlin Flow is the answer for observability and rx-like reactive programming. Kotlin multiplatform (while still in early development) allows sharing code between JVM, web and native targets (even iOS) with a decent-ish build system. I'm very bullish on the future of Kotlin and have been using it for years as my goto language for backend apis, MPA's, Android and JVM desktop projects. I'm excited to expand that into some combined web/iOS/android/desktop projects in the very near future.
- pjmlp 5y ago
  That is like saying UNIX would migrate away from C. Kotlin got lucky with Android, Google should have all the fun with their own version of .NET.
  - k__ 5y ago
    "That is like saying UNIX would migrate away from C." Isn't exactly this happening now with Rust?
    - pjmlp 5y ago
      None of the tiny OSes written in Rust are UNIX. https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/ Note that ISO C is part of POSIX certification.
    - deleted 5y ago
      [deleted]
    - Koshkin 5y ago
      The userland at least seems to be moving more and more towards C++.
      - deleted 5y ago
        [deleted]
      - pjmlp 5y ago
        Kind of, although C++ does have an advantage that others lack, it also shares the same symbiotic relationship with UNIX, by having been born on the same place as UNIX and C, by the same group of people of Bell Labs employees and initially started as C pre-processor. Which is also a reason why it cannot get rid of the flaws it inherited from such relationship.
- bcrosby95 5y ago
  As a long time Java dev, if I could pick a language to migrate to it would be Clojure, Erlang, Elixir, or Golang. In roughly that order.
qqtt 5y ago
I feel teased by this comment in the fact that you didn't indicate which language (or languages) you moved to that give you those benefits? Personally I moved from Java to Go, and couldn't be happier with it. Easy to use, easy to understand, similar advantages for debugging, but had some of the same proliferation of files at times. I've injected a bit of python into my workflow too if I just want to do a quick data-oriented task.
UncleOxidant 5y ago
> It's a damn beautiful language. Beauty is in the eye of the beholder. My list of beautiful languages does not include Java. Yours does.
jaytaylor 5y ago
> *I stopped using it because I stopped wanting to write 10000 lines for doing simple things. I want to write less code now. Java 11, with the introduction of lambdas, makes it trivial to express what used to require 10-15+ lines in 1-3 lines. The syntax can be a little tricky at first, and without an auto-complete IDE it's still damn near impossible to figure out what the correct 1-3 lines should be unless you're really up to date on the streaming collections APIs. The bottom line is, things are still improving with every release on the developer quality-of-life front. I've been pleasantly surprised! Caveat emptor, all languages have their ideal use-cases and tradeoffs. There is no holy grail (yet). > ftware engineers around the world to join our team, there's never been a better time to join than now! The most I can reveal here is that our cloud service is very popular. AI / ML / automatic speech recognition / NLP / chatbots are our bread and butter.
- wwweston 5y ago
  > Java 11, with the introduction of lambdas, makes it trivial to express what used to require 10-15+ lines in 1-3 lines. Makes this bit from the OP shine: "Bill Joy ... was often comparing [Oak/Java] to more complicated and elegant languages like Python and Beta. He would often go on at length about how great [Oak/Java] would be if he could only add closures and continuations and parameterized types." I'm sure they faced tradeoffs and Java's industry story is near unmatched so it's hard to argue they made categorically wrong tradeoffs, but imagine an alternate universe in which lambdas/closures and a few other features tamed verbosity and enabled python-comparable succinctness in Java back in the 90s.
  - kitd 5y ago
    IIRC Java had green threads and coroutines in its initial implementations. Imagine if they had kept them. People would probably complain they're unnecessary bloat. Never got all the complaints about Java. It's a very versatile "good enough" language with a great ecosystem.
- vips7L 5y ago
  Lambdas were Java 8 in 2014
stickfigure 5y ago
Five years ago (depending on your company) you might not have even been using closures. Java has come a long ways since then, and lombok has eliminated most of the boilerplate. Modern Java can be pretty pleasant! Of course, there's a lot of crap code out there, but there's a lot of crap code everywhere.
thesuperbigfrog 5y ago
>> I want to write less code now. Try Clojure: https://clojure.org/guides/learn/syntax https://clojure.org/guides/learn/syntax It runs on the JVM, but is far more concise, easy-to-use, and even beautiful.
zelphirkalt 5y ago
I wouldn't call Java especially beautiful. When I learned about Java, I thought: "Hey, everything has its place! It is clear what kind of concepts to use. Interfaces, abstract classes, classes, enums ..." and I thought it was beautiful. This was however my own limited view on programming languages at the time. In hindsight, this system was quite stunted and held me back, by forcing everything into that shape. Later I learned other languages, which include language concepts for things, which I needed to write extra files and classes for in Java. One such example: Decorators. Java has moved on nowadays, to include concepts, which other languages have had for decades, finally coming around to it. It did "modernize" a bit, one could say. Lambda expressions, namespaces, not having to put everything in a class (how silly that would be, to still have to do that). However, that doesn't make it beautiful, because those concepts are bolted on, for backwards compatibility reasons. It is not like there has been a redesign of the language or anything. It is going a similar way C++ is or has been going. Adding new syntax. It has to go that way, because there is no good extensible concept of Java syntax. Its syntax is always only a snapshot of the current state, that says "this is what is valid syntax right now", instead of offering a flexible way to extend the language. I want to use languages, which have incorporated concepts, which traditionally Java did not even have or use alternative concepts, which make things possible and in this way shorten my code significantly. Then I don't have to write 10000 lines for simple things. No language, however beautiful it may be, will solve a problem of overlooked use-cases, which cannot be solved using the concepts implemented in a library or program. For me beautiful code is code, which implements the simplest concept one can think of, in the simplest way, to make all intended use-cases possible. This is what I call flexibility. It is about implementing the least amount of limitations, not hard-coding assumptions, which are not justified, but all invariants, which are necessary. Not programming oneself into a corner.
pharmakom 5y ago
> It's a damn beautiful language. > I stopped using it because I stopped wanting to write 10000 lines for doing simple things. My definition of beauty includes expressing simple things concisely.
deleted 5y ago
[deleted]
- deleted 5y ago
  [deleted]
freedomben 5y ago
What did you switch to instead of Java?

k__ 5y ago

Interesting. From an outside perspective, I had the impression Java devs would migrate to Kotlin.

dehrmann 5y ago
Kotlin is nice, but setting up the build system can be a bit clunky, stack traces aren't quite as clear, it's more of a moving target, and important things like record classes are making it into Java. I tried it, but realized the code ended up being similar, just with less boilerplate, and switched back to Java. I feel like Scala went through a similar lifecycle. It looked amazing, supported lots of coding paradigms, but had a lousy build system. Once Java added lambdas, it was good enough, and Scala wasn't worth the hassle. Also, remember Groovy?
- k__ 5y ago
  I see. I had the impression the Java build system was rather convulted.
  - rhacker 5y ago
    It had a reputation for this in the days of ANT. However Maven (and to some degree gradle) kinda made it a non-issue.
    - pjmlp 5y ago
      Gradle is Ant for devs that never lived through Ant build hell.
    - k__ 5y ago
      I heard that years ago, but I never worked with ANT. My "convulted build system" experiences all came from Maven and Gradle.
      - Alupis 5y ago
        Then I dare say you do not know the meaning of "convoluted build system". Thousands, or tens of thousands of lines of semi-proprietary/non-standard XML is what made up ANT build scripts... mostly or entirely hand written for each and every project. Even small hobby projects had build scripts in the thousands of lines... there was no such thing as dependency management, and nothing came "for free". Every single thing had to be hand written into the script because ANT didn't have any inkling what you might want to do... build targets layered upon each other until rationalizing about what happens when during the build becomes a full time job all in it's own. Maven is amazing. With a few lines of XML you can successfully build nearly every project, manage all dependencies, etc. The trade-off? It's extremely opinionated in how your project is managed and how it's laid out. Worth while in most cases.
        k__ 5y ago
        Good point. I guess, for me, everything that is XML is just convulted legacy stuff.
        Alupis 5y ago
        I can understand, although I find modern tooling makes XML painless, at least for me.
- dangets 5y ago
  I'm sold on Kotlin and have been working professionally in it for a few years (mixed Kotlin/Java projects server-side), so take my opinion for what it's worth. Integrating with Java's existing build systems (Gradle, Maven) was one of JetBrains initial design goals to avoid the separate ecosystem requirement that initially came with Scala. I admit building Kotlin has some quirks, notably around annotation processors - but overall it is very seamless. I am happy Java is adding new stuff (records, switch expressions, sealed classes), but I worry it is increasing overall language complexity vs. the fresh start that Kotlin was able to take. Supporting the legacy patterns in the language adds to the complexity any given Java developer is supposed to know. Overall I think the sane defaults and nudges towards the right patterns Kotlin pushes are a much bigger deal than just reducing boilerplate - though that is nice too.
vips7L 5y ago
Personally I'm not sold on Kotlin. I don't think it offers much for me over Java 17. Maybe nullable types? But I haven't had problems with null in years.
- deepsun 5y ago
  It's just a syntactic sugar. E.g. allowing last functional parameter to be specified after the closing parentheses makes possible to create interesting structures that look more like config file than procedural code. But in general it's just the same Java, e.g. you would search for "how to do that in Java", not "in Kotlin".
  - NoSorryCannot 5y ago
    Kotlin has more compilation targets than Java, so I don't know that you can say that.
    - deleted 5y ago
      [deleted]
  - zorr 5y ago
    It started out that way but in my eyes it has evolved to much more than just syntactic sugar. While Kotlin closures, receiver arguments, "it", extension functions, nullability operator, var/val, "when" pattern matching, sealed classes and smartcasts are mostly implemented as syntactic sugar, combining all of the above enables some interesting programming patterns. Some examples are Compose for building reactive/functional UI and TornadoFX for declarative UI on top of JavaFX. Coroutines and suspend functions provide structured concurrency and an async paradigm that interopts well with the "old" Java CompletableFuture apis and existing libraries. Kotlin Flow is the answer for observability and rx-like reactive programming. Kotlin multiplatform (while still in early development) allows sharing code between JVM, web and native targets (even iOS) with a decent-ish build system. I'm very bullish on the future of Kotlin and have been using it for years as my goto language for backend apis, MPA's, Android and JVM desktop projects. I'm excited to expand that into some combined web/iOS/android/desktop projects in the very near future.
pjmlp 5y ago
That is like saying UNIX would migrate away from C. Kotlin got lucky with Android, Google should have all the fun with their own version of .NET.
- k__ 5y ago
  "That is like saying UNIX would migrate away from C." Isn't exactly this happening now with Rust?
  - pjmlp 5y ago
    None of the tiny OSes written in Rust are UNIX. https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/ Note that ISO C is part of POSIX certification.
  - deleted 5y ago
    [deleted]
  - Koshkin 5y ago
    The userland at least seems to be moving more and more towards C++.
    - deleted 5y ago
      [deleted]
    - pjmlp 5y ago
      Kind of, although C++ does have an advantage that others lack, it also shares the same symbiotic relationship with UNIX, by having been born on the same place as UNIX and C, by the same group of people of Bell Labs employees and initially started as C pre-processor. Which is also a reason why it cannot get rid of the flaws it inherited from such relationship.
bcrosby95 5y ago
As a long time Java dev, if I could pick a language to migrate to it would be Clojure, Erlang, Elixir, or Golang. In roughly that order.

qqtt 5y ago

I feel teased by this comment in the fact that you didn't indicate which language (or languages) you moved to that give you those benefits? Personally I moved from Java to Go, and couldn't be happier with it. Easy to use, easy to understand, similar advantages for debugging, but had some of the same proliferation of files at times. I've injected a bit of python into my workflow too if I just want to do a quick data-oriented task.

UncleOxidant 5y ago

> It's a damn beautiful language. Beauty is in the eye of the beholder. My list of beautiful languages does not include Java. Yours does.

jaytaylor 5y ago

> *I stopped using it because I stopped wanting to write 10000 lines for doing simple things. I want to write less code now. Java 11, with the introduction of lambdas, makes it trivial to express what used to require 10-15+ lines in 1-3 lines. The syntax can be a little tricky at first, and without an auto-complete IDE it's still damn near impossible to figure out what the correct 1-3 lines should be unless you're really up to date on the streaming collections APIs. The bottom line is, things are still improving with every release on the developer quality-of-life front. I've been pleasantly surprised! Caveat emptor, all languages have their ideal use-cases and tradeoffs. There is no holy grail (yet). > ftware engineers around the world to join our team, there's never been a better time to join than now! The most I can reveal here is that our cloud service is very popular. AI / ML / automatic speech recognition / NLP / chatbots are our bread and butter.

wwweston 5y ago
> Java 11, with the introduction of lambdas, makes it trivial to express what used to require 10-15+ lines in 1-3 lines. Makes this bit from the OP shine: "Bill Joy ... was often comparing [Oak/Java] to more complicated and elegant languages like Python and Beta. He would often go on at length about how great [Oak/Java] would be if he could only add closures and continuations and parameterized types." I'm sure they faced tradeoffs and Java's industry story is near unmatched so it's hard to argue they made categorically wrong tradeoffs, but imagine an alternate universe in which lambdas/closures and a few other features tamed verbosity and enabled python-comparable succinctness in Java back in the 90s.
- kitd 5y ago
  IIRC Java had green threads and coroutines in its initial implementations. Imagine if they had kept them. People would probably complain they're unnecessary bloat. Never got all the complaints about Java. It's a very versatile "good enough" language with a great ecosystem.
vips7L 5y ago
Lambdas were Java 8 in 2014

stickfigure 5y ago

Five years ago (depending on your company) you might not have even been using closures. Java has come a long ways since then, and lombok has eliminated most of the boilerplate. Modern Java can be pretty pleasant! Of course, there's a lot of crap code out there, but there's a lot of crap code everywhere.

thesuperbigfrog 5y ago

>> I want to write less code now. Try Clojure: https://clojure.org/guides/learn/syntax https://clojure.org/guides/learn/syntax It runs on the JVM, but is far more concise, easy-to-use, and even beautiful.

zelphirkalt 5y ago

I wouldn't call Java especially beautiful. When I learned about Java, I thought: "Hey, everything has its place! It is clear what kind of concepts to use. Interfaces, abstract classes, classes, enums ..." and I thought it was beautiful. This was however my own limited view on programming languages at the time. In hindsight, this system was quite stunted and held me back, by forcing everything into that shape. Later I learned other languages, which include language concepts for things, which I needed to write extra files and classes for in Java. One such example: Decorators. Java has moved on nowadays, to include concepts, which other languages have had for decades, finally coming around to it. It did "modernize" a bit, one could say. Lambda expressions, namespaces, not having to put everything in a class (how silly that would be, to still have to do that). However, that doesn't make it beautiful, because those concepts are bolted on, for backwards compatibility reasons. It is not like there has been a redesign of the language or anything. It is going a similar way C++ is or has been going. Adding new syntax. It has to go that way, because there is no good extensible concept of Java syntax. Its syntax is always only a snapshot of the current state, that says "this is what is valid syntax right now", instead of offering a flexible way to extend the language. I want to use languages, which have incorporated concepts, which traditionally Java did not even have or use alternative concepts, which make things possible and in this way shorten my code significantly. Then I don't have to write 10000 lines for simple things. No language, however beautiful it may be, will solve a problem of overlooked use-cases, which cannot be solved using the concepts implemented in a library or program. For me beautiful code is code, which implements the simplest concept one can think of, in the simplest way, to make all intended use-cases possible. This is what I call flexibility. It is about implementing the least amount of limitations, not hard-coding assumptions, which are not justified, but all invariants, which are necessary. Not programming oneself into a corner.

pharmakom 5y ago

> It's a damn beautiful language. > I stopped using it because I stopped wanting to write 10000 lines for doing simple things. My definition of beauty includes expressing simple things concisely.

deleted 5y ago

[deleted]

deleted 5y ago
[deleted]

freedomben 5y ago

What did you switch to instead of Java?