3
kiki
277d

why java sucks?

Comments
  • 4
    Because people don't know how to use it right
  • 9
    Java.VerboseJavaMode.setJavaVerboseMode(this.muchVerbose())
  • 3
    No custom value types, NRE, callback based concurrency, obsession with OOP.
  • 4
    It doesn’t. Neither does any other language. Shit devs can write bad code in any language
  • 2
    @TeachMeCode yeah but some languages make it more easy to write shit code than others.
  • 2
    @Lensflare we have ValueType albeit it is newer, not a clue what NRE means, not sure what is wrong with callback based concurrency as a whole nor why its object oriented approach would be bad.

    I would rather deal with Java or C# projects than many other things as they are in the wild. But that is just me tho. I like strictness, what I do dislike is over engineered shit, which does lends itself to the two languages I mentioned rather frequently
  • 2
    not a clue, pays the bills and does what I want it to do. Has libraries or frameworks for damn near everything.

    So do many other languages for that matter. Say no to being a neckbeard lads, languages are just tools. As long as they are not TCL or bash then everything is good
  • 1
    @Lensflare what's NRE? Missspelled NPE? If so - I don't see how that's different from unassigned refs in other languages

    what's a custom value type? Isn't a custom class a custom type...?
  • 1
    @netikras NullReferenceException. Sorry I was confusing it with how it’s called in C#. Java calls it NPE, even though it uses references and not pointers 🤡.
    Look at how Kotlin, Swift or Rust solved it.
    C# tried but failed because it was too late in its development.

    A class lets you define a custom type but it’s a type with reference semantics. C# has structs which have value semantics. In java you only have primitive types which have value semantics and you can‘t define your own (custom).
  • 1
    @AleCx04 see previous post for NRE and custom value types.

    Callback based concurrency is archaic. There are much better solutions in other languages now. Like async/await and structured concurrency. The advantages are obvious: Less nesting (no callback hell), more safety (can‘t forget to handle or provide a callback), more clarity (easier to reason about the code)

    Obsession with OOP:
    Everything must be a class or an instance of a class: Callbacks, enums, annotations, everything. This is just too much boilerplate, especially for callbacks. Java clearly tries to make you use OOP wherever possible. But sometimes OOP is not the best tool. So it’s better to be more general like C#, Kotlin, Swift, Rust, …
  • 0
    @Lensflare ahhh got you, mostly just preferences
  • 0
    @AleCx04 I have to disagree. Mostly objective shortcomings. OOP obsession maybe being the single exception and actually a preference. Maybe.
  • 0
    @Lensflare I can see it
  • 3
    I'm on my way to a Java gig. The spring tutorial says enough why it sucks - all that freaking work including xml for a freaking endpoint?

    Edit: but I won't do lame webstuff. I turnover millions worth of recycling monehh weekly with this project
Add Comment