8 ms·

Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unneces

Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unnecessary use of getters/setters, interfaces, and AbstractFactoryImpls. Hiding almost every piece of functionality behind 10+ layers of indirection. Dependency Injection with Spring. They all make it feel like Java draws folks who actually __enjoy__ writing bloated, over-engineered garbage. YMMV, of course, and yes, there are modern frameworks other than Spring (Play is supposedly pleasant to work with), but life is too short to try to sort out that mess. I plan to stick to Elixir as much as I can, for as long as I can. When the language clicked for me, it was the biggest breath of fresh air since I decided to pursue programming as a profession, and even cooler than when I discovered Python/Django. Edit: obviously, Java is not all bad, and not all (or even most) people who use it fit the description above. But something about the ecosystem seems to draw those types (no pun intended) disproportionately.

i386 4y ago
All my new Java projects don’t use spring for that very reason. Nothing wrong with the new keyword.
- geodel 4y ago
  Excellent!. Its good to hear about places where Spring nincompoops do not shove their crap framework down everyone's throat.
pwinnski 4y ago
I don't think this is an issue with Java, it's an issue with Spring. I'm baffled by the popularity of Spring.
- ralmidani 4y ago
  I’ve seen similar patterns with tech that’s older than Spring (Servlets/JSP). Also, wasn’t it EJB that promoted getters and setters everywhere?
  - nick__m 4y ago
    JavaBeans in general promoted that convention. I first learned about Beans using Swing (the ui toolkit) since it makes heavy use of them.
- geodel 4y ago
  But this article specially mentions Spring as some next generation rocket fuel to send Java even higher. The problem I see is as far Java ecosystem goes Spring is big, respected dev framework to be used liberally anywhere. So if a developer like me call Spring a revolting piece of shit software it is just me asking to become jobless.
- snewman 4y ago
  I think it depends a lot on where you work and what sorts of projects you work on. I've been programming professionally in Java for the last 16 years and I have never encountered Spring. Nor do I typically see the stereotypical sort of FactoryFactoryManagerImpl complexity bloat. It is something you need to watch out for and steer clear of, in particular when selecting frameworks / libraries, but you can definitely live in the Java ecosystem without being pulled too far down this road. (The introduction of lambdas helped.) (Those 16 years are four years at Google, 10 years in a pair of startups, now 1.5 years at a medium-sized acquirer.)
  - sangnoir 4y ago
    > I think it depends a lot on where you work and what sorts of projects you work on Correct. These frameworks are synonymous with "Enterprise Java", which you're unlikely to encounter at startups on one end, or Google at the other, but at many places in-between
  - KronisLV 4y ago
    > I think it depends a lot on where you work and what sorts of projects you work on. Agreed, even if my experience has been the exact opposite of yours. I've seen Spring be used in my country a lot, although recently Spring Boot. On one hand, I really dislike how code is sometimes exchanged for annotations that cannot be debugged with breakpoints easily (unless you dig in to the code where the breakpoint is defined and then come up with breakpoint conditions that are triggered exactly for your code, but not the other 500 places in your app where that annotation is used) and don't allow for easy customization (vs just changing a few lines of code in the actual method body), or sometimes just don't work altogether (e.g. trying to log method execution times with something like AOP, which didn't work with Spring calls sometimes). On the other, it's better than some of the in-house frameworks that I've seen, with sparse comments written in Lithuanian (which I really don't speak) and just bad in most respects. Honestly, most off the shelf open source frameworks/libraries that are actively supported should be good enough, be it Quarkus, Dropwizard, or something else entirely. Though at least something that's widely known and has lots of questions and answers surrounding common use cases in places like the documentation and StackOverflow. Otherwise, you're in for a bad time.
- nick__m 4y ago
  Old school xml based Spring is horrible and if that was your only exposure, I understand your aversion. But spring-boot has an almost zen like quality once you get that it favor convention over configuration. When I was a Java developer, I'd usually use spring-boot with the following dependencies to make the experience better: - lombok: to generate the boilerplate: constructors, getters, setters, equals, hashcode... - mybatis-spring-boot-starter: mybatis is a sql resultset mapper, you write the sql and it maps the results. I find that ORM like Hibernate or Eclipselink are a complexity trap: easy things are really easy but hard things are incredibly complicated, mybatis avoid that.
  - ralmidani 4y ago
    Sorry, but the popularity of tools which generate boilerplate for you is, in my opinion, one of the biggest indictments of the whole ecosystem.
    - ledauphin 4y ago
      agreed. every time I see static code generation I think "this is why people invent and use properly powerful languages".
      - Spivak 4y ago
        Rails, Django? Surely Ruby and Python have as much power as anyone could ask for but still use codegen.
    - deleted 4y ago
      [deleted]
    - KronisLV 4y ago
      > Sorry, but the popularity of tools which generate boilerplate for you is, in my opinion, one of the biggest indictments of the whole ecosystem. I couldn't disagree more. I can understand disliking the fact that we need getters/setters in the first place, or perhaps dynamic things like annotations which aren't "normal" code, but static code generation is something that the industry absolutely should embrace. Model driven development should be more common. For example, if you can just draw a few ER diagrams and have MySQL Workbench forward engineer SQL migrations for you to check them over (especially if you need to change 20 tables), why shouldn't you take advantage of that? Having a model of your schema that you can generate from the live schema and then transform it into either a set of fresh migrations or just a delta for bringing an older schema version up to date. I've actually used these two approaches to save bunches of time for personal projects in the past, even though I took the SQL output and put it into dbmate migration tool. Reverse engineer: https://dev.mysql.com/doc/workbench/en/wb-reverse-engineer-create-script.html Forward engineer: https://dev.mysql.com/doc/workbench/en/wb-forward-engineering-sql-scripts.html But databases are just one example. Remember SOAP? Despite being hard to use, one of the best points of SOAP was WSDL - Web Services Definition Language files which allowed you to have a fully functional description of a particular API contained in a single file. Back when REST started replacing it, there was also WADL, but that didn't really go anywhere. The claim that web service endpoints (REST or otherwise) should be largely dynamic/schemaless is basically a lie, because in most languages you'll indeed want to work with particular fields for the objects that you expect to be returned, or domain classes that shouldn't be that different in practice from what you expect. The beauty of WSDL was that you could get the file from a live version of an API, feed it into something like SoapUI and get a fully working API client, upon which you could build a test suite. Or even better, generate client code for your language of choice, so instead of making HTTP calls and wondering about how to initialize the client, you could start using library code much sooner, with parameters and methods already created for you. Some time later, OpenAPI came along, but the wisdom of SOAP was basically lost, since it took a while for projects like OpenAPI Generator to pop up and even now the approach of generating client (or even server!) code based on some specification seems to be utterly lost on the industry. WSDL: https://en.wikipedia.org/wiki/Web_Services_Description_Language WADL: https://en.wikipedia.org/wiki/Web_Application_Description_Language SoapUI: https://www.soapui.org/ OpenAPI: https://en.wikipedia.org/wiki/OpenAPI_Specification OpenAPI Generator: https://openapi-generator.tech/ Want more examples? What about database schemas and mapping them to your ORM/other persistence layer solution? I think if you're writing your own model code, you're doing something wrong, regardless of the language that you use. You'll probably mess up or miss relation mapping with something like Hibernate, will miss out on some comments for autocomplete in Laravel and just generally will have an inconsistent persistence layer that will make you waste time. In most cases, starting with the schema first and using one of the available generation solutions to fill in the application side of the persistence layer seems like the only sane options. Sure, some might prefer to handle migrations in the app side, like Ruby's Active Record Migrations, or something like Liquibase, which are also passable approaches, as long as you don't create a bad schema just so it fits your application. Java JPA entity generator example: https://github.com/smartnews/jpa-entity-generator Java generator to get DDL from JPA: https://github.com/Devskiller/jpa2ddl PHP (Laravel) generator to get models from schema: https://github.com/krlove/eloquent-model-generator Ruby Active Record Migrations: https://guides.rubyonrails.org/active_record_migrations.html In most cases, when you integrate two systems, APIs or just bits of code, one side should be the source of truth and the other should match it as closely as possible (problems with data types aside). Somehow the industry doesn't really know how to do this well, though thankfully projects like gRPC prove that it's perfectly doable in a modern setting. When this isn't done, you end up with either technologies that are a bit too green to be used successfully (e.g. picking GraphQL to supposedly deal with dynamic data and then being a month late with actually shipping), or having to waste your own time writing "boilerplate" that you will actually need, because although it could and should be generated, it is actually needed (to query that API, access that database, migrate that schema). I do agree in regards to the pointless Spring XML boilerplate, which is indeed useless.
- oftenwrong 4y ago
  I have worked with Spring and Spring Boot extensively, and I also don't understand why people like it. It is convenient when it works, but otherwise it's a hindrance. It adds a significant layer of complexity to understanding how an application works, and to debugging.
- fulafel 4y ago
  It's an issue with Java culture I think, lots of stuff is patterned like this and people expect or at least tolerate it.
- peterashford 4y ago
  Yeah, I've used Java on and off for years and never used any of that enterprise stuff.
type0 4y ago
Java is the perfect example of software "bureaucracy" for the sake of bureaucracy
- cutler 4y ago
  That also goes for Java's imitators - C# and PHP5+.
api 4y ago
The problem with Java is much more with the ecosystem than the language, for all the reasons you describe. Clean, straightforward software can be written in Java but it seldom is.
butterNaN 4y ago
I have been learning Elixir for past couple of months. After a long time, I am in love with programming+design again. It has honestly given my brain a much needed refresh. Of course, it can definitely be attributed, at least partly, to just moving to functional programming. Every day I look forward to 6'o clock, so I can stop working and continue on my own projects.
- afhammad 4y ago
  You will also find Clojure just as refreshing / enlightening. My company uses Elixir but I’ve also done a lot of Clojure, give it a shot if you haven’t.
  - cutler 4y ago
    Seconded. Clojure was a real turning point for me but be warned - once you have the veil lifted re OOP you'll not want to work with Java/C# ever again.
    - vizzier 4y ago
      I feel this so much, been working with F# in some sub projects. C# is hard to go back to. Though Microsoft's route of stealing wholesale from the former is making it gradually more palatable.
    - hiepph 4y ago
      Clojure is such a joy in my programming life. Even though I don't use it in my job, learning it made me change partially my programming style in Java, such as functions decomposition. Sadly I don't see any chance that I'm going to use it for real job in the future. The market is too narrow for this language. Hard fact that If I don't use it for the job, I cannot reach to its full potential. Guess it should stay as my hobby language for now.
tomohawk 4y ago
Java has reached the status of Cobol - it is immortal because it is everywhere and has been around a long time. Because of that, there are a lot of Java devs. Our team works in Go, and so we get a few Java devs in once in a while as new positions open up. The biggest change for them is to get out of archonaut mode and stop overdesigning everything. After going through a 3-6 month cleanse, it's fun to see them complain about the legacy Java stuff and how overly complicated it is and how slow it is to build and test compared to Go.
- ralmidani 4y ago
  We use Elixir at work, but a lot of us either did a Java bootcamp, or came over from Java jobs, and in some places the codebase reflects that. I love your use of the word “cleanse”.
- kaba0 4y ago
  That’s funny because Go is much less expressive than even Java. If anything, their overdesign seems to come from their juniority and badly ingrained “best-practices”, nothing inherent in the language.
  - al_mandi 4y ago
    Having used both at different employers, I agree. The golang code I've seen was much worse on almost every level than other code I've seen.
- SureshG 4y ago
  Modern java (check this - https://www.infoq.com/articles/data-oriented-programming-java/ https://www.infoq.com/articles/data-oriented-programming-jav...) is really not that bad. Golang is like far more verbose than even JDK 8 (9 old release) for most parts. The issue is, many java users have only experience with spring ecosystem for doing most of the stuffs. There are far better alternatives in java ecosystem. There are other JVM languages like Kotlin with provides 100% interop with the ecosystems and is far better language than go.
- peterashford 4y ago
omegalulw 4y ago
What's your take on Kotlin? Neatly solves a ton of these issues.
- ralmidani 4y ago
  I’ve looked at Kotlin but haven’t used it. It seems like it was designed carefully, and conceptually, I think Jetpack Compose is pretty cool. Is there a (non-Spring-like) Kotlin server-side framework you would recommend taking a look at?
  - cutler 4y ago
    The main Kotlin framework is Ktor.
  - origin_path 4y ago
    https://ktor.io/ https://ktor.io/ for Kotlin server side. It's not as large/complete as Spring Boot but you may find it preferable.
mdesq 4y ago
FizzBuzz Enterprise Edition [1] is an oldie but a goodie worth a re-mention. 1. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- pelagicAustral 4y ago
  The Issues in that repo are hilarious
  - Banana699 4y ago
    >package com.seriouscompany.business.java.fizzbuzz.packagenamingpackage >Issue #597 : It's written in java but doesn't support my blu-ray player
bgro 4y ago
I'm exactly the opposite! I hated Java in school. I was going to switch careers because of it. I eventually graduated and my second job was a Java SWE. I realized it's not just you sitting in a void on a theoretical BS questions. You have a team to talk to and get help from. If you forget what a HashMap is called, you don't get stuck trying to declare a HashArray with an automatic fail grade on the same level as someone who did literally nothing and handed in literally nothing. Then I got a few years experience as a SWE and I realized my original assumption WAS correct. You are stuck in a void answering BS leetcode questions, and you DO automatically fail if you get stuck declaring a HashArray with otherwise perfect logic. Indeed, technical interviews are so fun. Especially the fully automated ones, but honestly even the ones with interactive humans they still can't comprehend how somebody could POSSIBLY mistake a HashMap as a HashArray unless you were literally fake trash.
cutler 4y ago
I'm not really a fan of Java but isn't a comparison with Elixir and Python a bit apples to oranges?

i386 4y ago

All my new Java projects don’t use spring for that very reason. Nothing wrong with the new keyword.

geodel 4y ago
Excellent!. Its good to hear about places where Spring nincompoops do not shove their crap framework down everyone's throat.

pwinnski 4y ago

I don't think this is an issue with Java, it's an issue with Spring. I'm baffled by the popularity of Spring.

ralmidani 4y ago
I’ve seen similar patterns with tech that’s older than Spring (Servlets/JSP). Also, wasn’t it EJB that promoted getters and setters everywhere?
- nick__m 4y ago
  JavaBeans in general promoted that convention. I first learned about Beans using Swing (the ui toolkit) since it makes heavy use of them.
geodel 4y ago
But this article specially mentions Spring as some next generation rocket fuel to send Java even higher. The problem I see is as far Java ecosystem goes Spring is big, respected dev framework to be used liberally anywhere. So if a developer like me call Spring a revolting piece of shit software it is just me asking to become jobless.
snewman 4y ago
I think it depends a lot on where you work and what sorts of projects you work on. I've been programming professionally in Java for the last 16 years and I have never encountered Spring. Nor do I typically see the stereotypical sort of FactoryFactoryManagerImpl complexity bloat. It is something you need to watch out for and steer clear of, in particular when selecting frameworks / libraries, but you can definitely live in the Java ecosystem without being pulled too far down this road. (The introduction of lambdas helped.) (Those 16 years are four years at Google, 10 years in a pair of startups, now 1.5 years at a medium-sized acquirer.)
- sangnoir 4y ago
  > I think it depends a lot on where you work and what sorts of projects you work on Correct. These frameworks are synonymous with "Enterprise Java", which you're unlikely to encounter at startups on one end, or Google at the other, but at many places in-between
- KronisLV 4y ago
  > I think it depends a lot on where you work and what sorts of projects you work on. Agreed, even if my experience has been the exact opposite of yours. I've seen Spring be used in my country a lot, although recently Spring Boot. On one hand, I really dislike how code is sometimes exchanged for annotations that cannot be debugged with breakpoints easily (unless you dig in to the code where the breakpoint is defined and then come up with breakpoint conditions that are triggered exactly for your code, but not the other 500 places in your app where that annotation is used) and don't allow for easy customization (vs just changing a few lines of code in the actual method body), or sometimes just don't work altogether (e.g. trying to log method execution times with something like AOP, which didn't work with Spring calls sometimes). On the other, it's better than some of the in-house frameworks that I've seen, with sparse comments written in Lithuanian (which I really don't speak) and just bad in most respects. Honestly, most off the shelf open source frameworks/libraries that are actively supported should be good enough, be it Quarkus, Dropwizard, or something else entirely. Though at least something that's widely known and has lots of questions and answers surrounding common use cases in places like the documentation and StackOverflow. Otherwise, you're in for a bad time.
nick__m 4y ago
Old school xml based Spring is horrible and if that was your only exposure, I understand your aversion. But spring-boot has an almost zen like quality once you get that it favor convention over configuration. When I was a Java developer, I'd usually use spring-boot with the following dependencies to make the experience better: - lombok: to generate the boilerplate: constructors, getters, setters, equals, hashcode... - mybatis-spring-boot-starter: mybatis is a sql resultset mapper, you write the sql and it maps the results. I find that ORM like Hibernate or Eclipselink are a complexity trap: easy things are really easy but hard things are incredibly complicated, mybatis avoid that.
- ralmidani 4y ago
  Sorry, but the popularity of tools which generate boilerplate for you is, in my opinion, one of the biggest indictments of the whole ecosystem.
  - ledauphin 4y ago
    agreed. every time I see static code generation I think "this is why people invent and use properly powerful languages".
    - Spivak 4y ago
      Rails, Django? Surely Ruby and Python have as much power as anyone could ask for but still use codegen.
  - deleted 4y ago
    [deleted]
  - KronisLV 4y ago
    > Sorry, but the popularity of tools which generate boilerplate for you is, in my opinion, one of the biggest indictments of the whole ecosystem. I couldn't disagree more. I can understand disliking the fact that we need getters/setters in the first place, or perhaps dynamic things like annotations which aren't "normal" code, but static code generation is something that the industry absolutely should embrace. Model driven development should be more common. For example, if you can just draw a few ER diagrams and have MySQL Workbench forward engineer SQL migrations for you to check them over (especially if you need to change 20 tables), why shouldn't you take advantage of that? Having a model of your schema that you can generate from the live schema and then transform it into either a set of fresh migrations or just a delta for bringing an older schema version up to date. I've actually used these two approaches to save bunches of time for personal projects in the past, even though I took the SQL output and put it into dbmate migration tool. Reverse engineer: https://dev.mysql.com/doc/workbench/en/wb-reverse-engineer-create-script.html Forward engineer: https://dev.mysql.com/doc/workbench/en/wb-forward-engineering-sql-scripts.html But databases are just one example. Remember SOAP? Despite being hard to use, one of the best points of SOAP was WSDL - Web Services Definition Language files which allowed you to have a fully functional description of a particular API contained in a single file. Back when REST started replacing it, there was also WADL, but that didn't really go anywhere. The claim that web service endpoints (REST or otherwise) should be largely dynamic/schemaless is basically a lie, because in most languages you'll indeed want to work with particular fields for the objects that you expect to be returned, or domain classes that shouldn't be that different in practice from what you expect. The beauty of WSDL was that you could get the file from a live version of an API, feed it into something like SoapUI and get a fully working API client, upon which you could build a test suite. Or even better, generate client code for your language of choice, so instead of making HTTP calls and wondering about how to initialize the client, you could start using library code much sooner, with parameters and methods already created for you. Some time later, OpenAPI came along, but the wisdom of SOAP was basically lost, since it took a while for projects like OpenAPI Generator to pop up and even now the approach of generating client (or even server!) code based on some specification seems to be utterly lost on the industry. WSDL: https://en.wikipedia.org/wiki/Web_Services_Description_Language WADL: https://en.wikipedia.org/wiki/Web_Application_Description_Language SoapUI: https://www.soapui.org/ OpenAPI: https://en.wikipedia.org/wiki/OpenAPI_Specification OpenAPI Generator: https://openapi-generator.tech/ Want more examples? What about database schemas and mapping them to your ORM/other persistence layer solution? I think if you're writing your own model code, you're doing something wrong, regardless of the language that you use. You'll probably mess up or miss relation mapping with something like Hibernate, will miss out on some comments for autocomplete in Laravel and just generally will have an inconsistent persistence layer that will make you waste time. In most cases, starting with the schema first and using one of the available generation solutions to fill in the application side of the persistence layer seems like the only sane options. Sure, some might prefer to handle migrations in the app side, like Ruby's Active Record Migrations, or something like Liquibase, which are also passable approaches, as long as you don't create a bad schema just so it fits your application. Java JPA entity generator example: https://github.com/smartnews/jpa-entity-generator Java generator to get DDL from JPA: https://github.com/Devskiller/jpa2ddl PHP (Laravel) generator to get models from schema: https://github.com/krlove/eloquent-model-generator Ruby Active Record Migrations: https://guides.rubyonrails.org/active_record_migrations.html In most cases, when you integrate two systems, APIs or just bits of code, one side should be the source of truth and the other should match it as closely as possible (problems with data types aside). Somehow the industry doesn't really know how to do this well, though thankfully projects like gRPC prove that it's perfectly doable in a modern setting. When this isn't done, you end up with either technologies that are a bit too green to be used successfully (e.g. picking GraphQL to supposedly deal with dynamic data and then being a month late with actually shipping), or having to waste your own time writing "boilerplate" that you will actually need, because although it could and should be generated, it is actually needed (to query that API, access that database, migrate that schema). I do agree in regards to the pointless Spring XML boilerplate, which is indeed useless.
oftenwrong 4y ago
I have worked with Spring and Spring Boot extensively, and I also don't understand why people like it. It is convenient when it works, but otherwise it's a hindrance. It adds a significant layer of complexity to understanding how an application works, and to debugging.
fulafel 4y ago
It's an issue with Java culture I think, lots of stuff is patterned like this and people expect or at least tolerate it.
peterashford 4y ago
Yeah, I've used Java on and off for years and never used any of that enterprise stuff.

type0 4y ago

Java is the perfect example of software "bureaucracy" for the sake of bureaucracy

cutler 4y ago
That also goes for Java's imitators - C# and PHP5+.

api 4y ago

The problem with Java is much more with the ecosystem than the language, for all the reasons you describe. Clean, straightforward software can be written in Java but it seldom is.

butterNaN 4y ago

I have been learning Elixir for past couple of months. After a long time, I am in love with programming+design again. It has honestly given my brain a much needed refresh. Of course, it can definitely be attributed, at least partly, to just moving to functional programming. Every day I look forward to 6'o clock, so I can stop working and continue on my own projects.

afhammad 4y ago
You will also find Clojure just as refreshing / enlightening. My company uses Elixir but I’ve also done a lot of Clojure, give it a shot if you haven’t.
- cutler 4y ago
  Seconded. Clojure was a real turning point for me but be warned - once you have the veil lifted re OOP you'll not want to work with Java/C# ever again.
  - vizzier 4y ago
    I feel this so much, been working with F# in some sub projects. C# is hard to go back to. Though Microsoft's route of stealing wholesale from the former is making it gradually more palatable.
  - hiepph 4y ago
    Clojure is such a joy in my programming life. Even though I don't use it in my job, learning it made me change partially my programming style in Java, such as functions decomposition. Sadly I don't see any chance that I'm going to use it for real job in the future. The market is too narrow for this language. Hard fact that If I don't use it for the job, I cannot reach to its full potential. Guess it should stay as my hobby language for now.

tomohawk 4y ago

Java has reached the status of Cobol - it is immortal because it is everywhere and has been around a long time. Because of that, there are a lot of Java devs. Our team works in Go, and so we get a few Java devs in once in a while as new positions open up. The biggest change for them is to get out of archonaut mode and stop overdesigning everything. After going through a 3-6 month cleanse, it's fun to see them complain about the legacy Java stuff and how overly complicated it is and how slow it is to build and test compared to Go.

ralmidani 4y ago
We use Elixir at work, but a lot of us either did a Java bootcamp, or came over from Java jobs, and in some places the codebase reflects that. I love your use of the word “cleanse”.
kaba0 4y ago
That’s funny because Go is much less expressive than even Java. If anything, their overdesign seems to come from their juniority and badly ingrained “best-practices”, nothing inherent in the language.
- al_mandi 4y ago
  Having used both at different employers, I agree. The golang code I've seen was much worse on almost every level than other code I've seen.
SureshG 4y ago
Modern java (check this - https://www.infoq.com/articles/data-oriented-programming-java/ https://www.infoq.com/articles/data-oriented-programming-jav...) is really not that bad. Golang is like far more verbose than even JDK 8 (9 old release) for most parts. The issue is, many java users have only experience with spring ecosystem for doing most of the stuffs. There are far better alternatives in java ecosystem. There are other JVM languages like Kotlin with provides 100% interop with the ecosystems and is far better language than go.
peterashford 4y ago

omegalulw 4y ago

What's your take on Kotlin? Neatly solves a ton of these issues.

ralmidani 4y ago
I’ve looked at Kotlin but haven’t used it. It seems like it was designed carefully, and conceptually, I think Jetpack Compose is pretty cool. Is there a (non-Spring-like) Kotlin server-side framework you would recommend taking a look at?
- cutler 4y ago
  The main Kotlin framework is Ktor.
- origin_path 4y ago
  https://ktor.io/ https://ktor.io/ for Kotlin server side. It's not as large/complete as Spring Boot but you may find it preferable.

mdesq 4y ago

FizzBuzz Enterprise Edition [1] is an oldie but a goodie worth a re-mention. 1. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

pelagicAustral 4y ago
The Issues in that repo are hilarious
- Banana699 4y ago
  >package com.seriouscompany.business.java.fizzbuzz.packagenamingpackage >Issue #597 : It's written in java but doesn't support my blu-ray player

bgro 4y ago

I'm exactly the opposite! I hated Java in school. I was going to switch careers because of it. I eventually graduated and my second job was a Java SWE. I realized it's not just you sitting in a void on a theoretical BS questions. You have a team to talk to and get help from. If you forget what a HashMap is called, you don't get stuck trying to declare a HashArray with an automatic fail grade on the same level as someone who did literally nothing and handed in literally nothing. Then I got a few years experience as a SWE and I realized my original assumption WAS correct. You are stuck in a void answering BS leetcode questions, and you DO automatically fail if you get stuck declaring a HashArray with otherwise perfect logic. Indeed, technical interviews are so fun. Especially the fully automated ones, but honestly even the ones with interactive humans they still can't comprehend how somebody could POSSIBLY mistake a HashMap as a HashArray unless you were literally fake trash.

cutler 4y ago

I'm not really a fan of Java but isn't a comparison with Elixir and Python a bit apples to oranges?