5 ms·

The problem with Java since Java 8 has never been Java. It's been about the appalling ecosystem that infected it with reflection frameworks. It was bonkers that

The problem with Java since Java 8 has never been Java. It's been about the appalling ecosystem that infected it with reflection frameworks. It was bonkers that "POJO" was ever a thing that had to be defined. It feels like these frameworks are now just falling away, which is great. I'm not even hearing about Spring anymore, and if there is any reason to not use it, it would be this cringe "how do you do fellow kids?" blurb I just saw on their front page: > Level up your Java™ code > With Spring Boot in your app, just a few lines of code is all you need to start building services like a boss. I personally would reach for Go by default, but I have no ill-will to Java.

MattPalmer1086 2y ago
Ahhhhh, yes. Java itself isn't bad and has been getting better. The frameworks made me want to scream.
- arez 2y ago
  which ones specifically? I like Spring Boot tbh
  - MattPalmer1086 2y ago
    Hibernate mostly. Spring too, but it has been a while. Mostly I just find the abstraction isn't worth it .
    - Alupis 2y ago
      The way you write this makes be think you rawdog'd Hibernate and Spring Framework. Don't do that... you will hate yourself. Boot is something entirely different. You write very little code and get a ton done. The trade off is you are firmly now a "Boot" codebase, but once you learn how Boot works it's not a big deal.
      - fiddlerwoaroof 2y ago
        I've had to maintain a couple Spring Boot apps and I absolutely cannot stand them: they pull in a whole pile of random dependencies and do weird things to your build with little explanation. Then, all the functionality involves a ton of classpath scanning and annotation-based DI that makes it hard to figure out how all the things fit together.
        gf000 2y ago
        I mean, have you learnt the framework before attempting to do that? Frameworks are frameworks, not libraries. You can't just start writing/understanding them - frameworks are different from libraries precisely because they call your code, not the reverse.
        lproven 2y ago
        That's a great explanation. Thanks for that.
        fiddlerwoaroof 2y ago
        Yes, the problem is exactly that the framework calls your code instead of being called by you code.
        Alupis 2y ago
        That's how all frameworks work though. This is not a criticism of Spring Boot. You are criticizing the use of a framework at all. Some people hate to write the same basic things over and over. That's where a framework excels. Write only the glue/logic you need to make your app work. The way you have described your experience with Spring Boot seems to imply you did not take the time to learn it at all, and therefore its' unsurprising to us you had a hard time of it.
        fiddlerwoaroof 2y ago
        Not writing the same thing over and over again is a feature of abstraction. A framework is a user-hostile way to abstract because it makes the source code opaque to developers. There's no reason why a library-based approach has to be more repetitive than frameworks.
    - Terr_ 2y ago
      I find pretty much every ORM in any language is problematic. The best you can hope for is a certain amount of internal design consistency, so that even if you can't do what you want it's at least clear what you are doing.
    - cryptos 2y ago
      Since I had the "joy" to use TypeORM (node.js stuff), I really value Hibernate, although there are some little corner cases I'd like to be better. But ORMs solve a really hard problem and I haven't seen anything better than Hibernate so far (and don't come up with JOOQ or MyBatis!).
qsort 2y ago
> The problem with Java since Java 8 I agree with the sentiment, but I'd move up to a version with type inference at least. I have nothing against static types and in fact in a vacuum I prefer them, but the particular brand of OO and "weak" generics that Java and C# have feels like filling forms in triplicate. "var" alleviates that significantly.
- neonsunset 2y ago
  Generics in Java and C# are _vastly_ different. .NET has true generics with full type information and struct type parameter monomorphization which works the same way generics do in Rust. Edit: C# does have type inference for generics, just not the full HM one. It is also quite more capable for lambdas which is a bit frustrating because it does not resolve nested generics otherwise. I miss it - F# does it the way it always should have been. There are many other differences small and big that arise from the way Java does generics and the fact that primitives can't participate - you will never see `IntStream` kind of workarounds in C#. Some libraries abuse and misuse generics for no profit (looking at you Azure SDK), but it's not as widespread. Shallow generic types are always inferred from arguments.
  - qsort 2y ago
    yes, this is true. I was talking more about the UX of how to use them, which in both cases is quite painful without type inference.
  - throwaway03452 2y ago
    > you will never see `IntStream` kind of workarounds in C#. You may not see that in Java in the future either. Java will have value objects from the Valhalla project, and part of the plan is to replace Integer with a value object. Then there will be less of a reason to use raw int primitives, because the JVM can treat value objects much more efficiently than normal objects.
    - neonsunset 2y ago
      The difference is that C# has been designed with proper generics since version 2 (pushed by F# research group with Don Syme) and is now on version 13. At the same time, structs have been present since version 1. All APIs and collection types build on this foundation, with standard library leveraging generic monomorhpization for zero-cost abstractions. Code that would have needed C++ implementation in the past is naturally expressed in pure C#. Generics are fully integrated into the type system at IL level, avoiding special-cased types or bespoke compiler handling (besides monomorphization). This enables numerous zero-cost features: tuples (unnamed/named), structs with controlled mutability and record structs, pattern matching, stack buffers that do not rely on escape analysis, structs with byref pointers for slice types (Span<T> and friends) which a good two thirds of the standard library accepts. Numeric and vector primitives are used in a simple way without setup requirements like Panama Vectors. While project Valhalla will get Java's foot in the door in some domains, it will remain a less optimal choice than C#, C++, Rust, etc. Java's evolution primarily serves its ecosystem's needs, whereas C# benefits from being a newer language that learned from both Java and C++ and got influenced by F# and other research projects inside MS. This makes C# more idiomatic and terse. The historical drawbacks - platform lock-in, being closed-source, and having relatively weak compiler - have been resolved over the past ~9 years.
gf000 2y ago
Spring boot is itself also very different than Spring, so depending on what was your last experience with these frameworks, you might be surprised. Given, they are still quite reflection-heavy and full of POJOs and annotations, it supports compile-time resolution for many things now. Also, you would be hard-pressed to find a more productive developer than a well-versed Spring boot guru for typical backend jobs. You might dislike the framework, but credit where it's due, it is a workhorse and the amount of time someone makes a POC, you can make it with spring properly, in a way that you can build your prod app on top. Like, it's easily as productive as RoR and similar.
- p2detar 2y ago
  Serious question - what could Spring Boot give me for POC/prototyping that Javalin or Micronaut couldn't? I really struggle to understand why most of Java shops out there have set themselves on the Boot path. Is it technology-based decision or politics?
  - Alupis 2y ago
    Boot has an "app" (err, lib) for everything. It's fully featured, and highly opinionated. Pretty much any modern computing problem you have, Boot has you covered[1]. So while you may not have ever used a Streaming library before, if you know Boot, then the Spring Boot Streaming library will already be familiar. [1] https://spring.io/projects/spring-boot https://spring.io/projects/spring-boot
  - ivan_gammel 2y ago
    It‘s established patterns. Javelin or Micronaut are probably great, but not a lot of people understands how to build a real project with them. With Spring Boot you don’t even think about it.
  - le-mark 2y ago
    I’m not familiar with either of those frameworks so can’t comment on them specifically, but 10+ years ago not using spring/boot entailed glueing together a lot of disparate libraries to do things spring boot had built in. Spring boot includes pretty much everything. Plus reliability, battle tested, easy to hire people with experience using it.

MattPalmer1086 2y ago

Ahhhhh, yes. Java itself isn't bad and has been getting better. The frameworks made me want to scream.

arez 2y ago
which ones specifically? I like Spring Boot tbh
- MattPalmer1086 2y ago
  Hibernate mostly. Spring too, but it has been a while. Mostly I just find the abstraction isn't worth it .
  - Alupis 2y ago
    The way you write this makes be think you rawdog'd Hibernate and Spring Framework. Don't do that... you will hate yourself. Boot is something entirely different. You write very little code and get a ton done. The trade off is you are firmly now a "Boot" codebase, but once you learn how Boot works it's not a big deal.
    - fiddlerwoaroof 2y ago
      I've had to maintain a couple Spring Boot apps and I absolutely cannot stand them: they pull in a whole pile of random dependencies and do weird things to your build with little explanation. Then, all the functionality involves a ton of classpath scanning and annotation-based DI that makes it hard to figure out how all the things fit together.
      - gf000 2y ago
        I mean, have you learnt the framework before attempting to do that? Frameworks are frameworks, not libraries. You can't just start writing/understanding them - frameworks are different from libraries precisely because they call your code, not the reverse.
        lproven 2y ago
        That's a great explanation. Thanks for that.
        fiddlerwoaroof 2y ago
        Yes, the problem is exactly that the framework calls your code instead of being called by you code.
        Alupis 2y ago
        That's how all frameworks work though. This is not a criticism of Spring Boot. You are criticizing the use of a framework at all. Some people hate to write the same basic things over and over. That's where a framework excels. Write only the glue/logic you need to make your app work. The way you have described your experience with Spring Boot seems to imply you did not take the time to learn it at all, and therefore its' unsurprising to us you had a hard time of it.
        fiddlerwoaroof 2y ago
        Not writing the same thing over and over again is a feature of abstraction. A framework is a user-hostile way to abstract because it makes the source code opaque to developers. There's no reason why a library-based approach has to be more repetitive than frameworks.
  - Terr_ 2y ago
    I find pretty much every ORM in any language is problematic. The best you can hope for is a certain amount of internal design consistency, so that even if you can't do what you want it's at least clear what you are doing.
  - cryptos 2y ago
    Since I had the "joy" to use TypeORM (node.js stuff), I really value Hibernate, although there are some little corner cases I'd like to be better. But ORMs solve a really hard problem and I haven't seen anything better than Hibernate so far (and don't come up with JOOQ or MyBatis!).

qsort 2y ago

> The problem with Java since Java 8 I agree with the sentiment, but I'd move up to a version with type inference at least. I have nothing against static types and in fact in a vacuum I prefer them, but the particular brand of OO and "weak" generics that Java and C# have feels like filling forms in triplicate. "var" alleviates that significantly.

neonsunset 2y ago
Generics in Java and C# are _vastly_ different. .NET has true generics with full type information and struct type parameter monomorphization which works the same way generics do in Rust. Edit: C# does have type inference for generics, just not the full HM one. It is also quite more capable for lambdas which is a bit frustrating because it does not resolve nested generics otherwise. I miss it - F# does it the way it always should have been. There are many other differences small and big that arise from the way Java does generics and the fact that primitives can't participate - you will never see `IntStream` kind of workarounds in C#. Some libraries abuse and misuse generics for no profit (looking at you Azure SDK), but it's not as widespread. Shallow generic types are always inferred from arguments.
- qsort 2y ago
  yes, this is true. I was talking more about the UX of how to use them, which in both cases is quite painful without type inference.
- throwaway03452 2y ago
  > you will never see `IntStream` kind of workarounds in C#. You may not see that in Java in the future either. Java will have value objects from the Valhalla project, and part of the plan is to replace Integer with a value object. Then there will be less of a reason to use raw int primitives, because the JVM can treat value objects much more efficiently than normal objects.
  - neonsunset 2y ago
    The difference is that C# has been designed with proper generics since version 2 (pushed by F# research group with Don Syme) and is now on version 13. At the same time, structs have been present since version 1. All APIs and collection types build on this foundation, with standard library leveraging generic monomorhpization for zero-cost abstractions. Code that would have needed C++ implementation in the past is naturally expressed in pure C#. Generics are fully integrated into the type system at IL level, avoiding special-cased types or bespoke compiler handling (besides monomorphization). This enables numerous zero-cost features: tuples (unnamed/named), structs with controlled mutability and record structs, pattern matching, stack buffers that do not rely on escape analysis, structs with byref pointers for slice types (Span<T> and friends) which a good two thirds of the standard library accepts. Numeric and vector primitives are used in a simple way without setup requirements like Panama Vectors. While project Valhalla will get Java's foot in the door in some domains, it will remain a less optimal choice than C#, C++, Rust, etc. Java's evolution primarily serves its ecosystem's needs, whereas C# benefits from being a newer language that learned from both Java and C++ and got influenced by F# and other research projects inside MS. This makes C# more idiomatic and terse. The historical drawbacks - platform lock-in, being closed-source, and having relatively weak compiler - have been resolved over the past ~9 years.

gf000 2y ago

Spring boot is itself also very different than Spring, so depending on what was your last experience with these frameworks, you might be surprised. Given, they are still quite reflection-heavy and full of POJOs and annotations, it supports compile-time resolution for many things now. Also, you would be hard-pressed to find a more productive developer than a well-versed Spring boot guru for typical backend jobs. You might dislike the framework, but credit where it's due, it is a workhorse and the amount of time someone makes a POC, you can make it with spring properly, in a way that you can build your prod app on top. Like, it's easily as productive as RoR and similar.

p2detar 2y ago
Serious question - what could Spring Boot give me for POC/prototyping that Javalin or Micronaut couldn't? I really struggle to understand why most of Java shops out there have set themselves on the Boot path. Is it technology-based decision or politics?
- Alupis 2y ago
  Boot has an "app" (err, lib) for everything. It's fully featured, and highly opinionated. Pretty much any modern computing problem you have, Boot has you covered[1]. So while you may not have ever used a Streaming library before, if you know Boot, then the Spring Boot Streaming library will already be familiar. [1] https://spring.io/projects/spring-boot https://spring.io/projects/spring-boot
- ivan_gammel 2y ago
  It‘s established patterns. Javelin or Micronaut are probably great, but not a lot of people understands how to build a real project with them. With Spring Boot you don’t even think about it.
- le-mark 2y ago
  I’m not familiar with either of those frameworks so can’t comment on them specifically, but 10+ years ago not using spring/boot entailed glueing together a lot of disparate libraries to do things spring boot had built in. Spring boot includes pretty much everything. Plus reliability, battle tested, easy to hire people with experience using it.