8 ms·

There are a few reasons to avoid Java today. - The programs are very verbose for the functionality they provide. There are countless lines of getters, setters,

• dbt00 6y ago
  Is the Scala language finally stable? I looked at it and discarded it multiple times over the last decade because every significant language revision required changing source code.
  • MrPowers 6y ago
    It's more unstable that ever with Scala 3 around the corner (which is basically a new language) and the May 1st Bintray shutdown that'll be massively breaking for the ecosystem. SBT builds were failing the other day from the Bintray brown-out cause all SBT plugins are still in Bintray: https://www.reddit.com/r/scala/comments/mph43t/sbt_build_failing_bintray_brownout_today_april_12/ https://www.reddit.com/r/scala/comments/mph43t/sbt_build_fai...
    • Jaxkr 6y ago
      I like Scala but that Bintray situation sounds like a nightmare.
      • MrPowers 6y ago
        Yea, JFrog announced the May 1st shutdown of Bintray on Feb 3rd: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocen... 3 month warning that they'd blow up the ecosystem. I have no idea why a company that builds products for devs would take such an aggressively anti-dev approach to shutting down a core service.
  • esarbe 6y ago
    I've been working with Scala professionally for the last 8 years and I consider it pretty stable. Code I've written for Scala 2.10/2.11 still compiles with 2.13. I think the biggest change for me was the redesigned collections-library, but that was rather simple migration. That said; there are a few breaking changes with the migration to 3.0 - especially if you rely on unsupported features of the compiler, namely macros. Macros have been widely used in the past and will not be supported anymore.
• mjevans 6y ago
  Another reason to avoid: Oracle owns Java. This automatically puts Java on my list of tools I'd prefer to avoid for new serious projects. (Legacy projects; if it's working and it isn't an issue yet, maintenance.)
  • eitland 6y ago
    Use OpenJDK! Never touch anything from Oracle. Then you will be fine. Oracle is the company that wants you to buy a license for your MariaDB(!) instance running on a small AWS instance! Yep, that happened. Source: have worked with Java for years, three of those around Oracle products.
    • severino 6y ago
      > Use OpenJDK! Never touch anything from Oracle. But OpenJDK is Oracle's. They are the primary contributors to the project, and they really made it 100% open-source.
      • ivan_gammel 6y ago
        It is not a big deal as long as it’s still run as independent project. There are plenty of other big players interested in keeping reference implementation vendor-neutral.
      • pulse7 6y ago
        You can use any other fork/build like AdoptOpenJDK or any other. It is open-source like Linux Kernel...
        • severino 6y ago
          You can use AdoptOpenJDK or Azul or whatever, but you will be using code largely from Oracle. I don't think there is any problem with that, but the OP said "never touch anything from Oracle".
      • skeeks 6y ago
• cosmotic 6y ago
  As a Java developer: - I have no trouble reading java and have a hard time reading the 'less verbose' languages. There's way too much implied meaning and information only gleamed through tooling or backtracing, like determining the type of a variable that is declared with var - IDE support for Scala is half as good as Java and I suspect a good reason is the language. The auotcomplete in intelliJ is almost as bad as it is for python and the IDE really struggles to understand the code; CPU usage when scala is open is MUCH higher than Java. - On all the Java apps I've worked on, I've never tuned the JVM. Tuning the VM sounds like focusing on the wrong part of a bottlenecked system. I've never tuned Python or PHP either but they aren't as performant. Regardless, GC gets better every release. It sounds like your negative views are more about the applications you've worked on than the language or technology.
  • mypalmike 6y ago
    Yup. As a C++ developer back in the day, I had no trouble reading Java when I first started using it. Indeed it was immediately easier to read than the language I'd spent around a decade with.
  • deleted 6y ago
    [deleted]
  • esarbe 6y ago
    > IDE support for Scala is half as good as Java and I suspect a good reason is the language. The auotcomplete in intelliJ is almost as bad as it is for python and the IDE really struggles to understand the code; This is not my experience. I found the IntelliJ autocompletion to work very well with Scala. There are nice code-suggestions, highlights for implicit parameters, refactoring works as a breeze. What exactly are you missing? > CPU usage when scala is open is MUCH higher than Java. That is true. MUCH higher.
    • cosmotic 6y ago
      The Scala autocomplete list often loads with a huge list of awful suggestions then moments later adds a bunch of useful options. We are using scala exclusively to write tests for our java code; we are using scalatest for this. The autocomplete for a lot of the (to me, as a non-seasoned scala developer) screwy operator overloaded 'syntax' just doesn't work at all. IDEA does show compile errors etc in 'realtime' (I put that in quotes because it takes a lot longer to catch up with bad scala code than it does bad java code).
• deleted 6y ago
  [deleted]
• cies 6y ago
  > If you do want to use Java ecosystem, there is Scala. Scala has a whole slew of problems of it's own. IMHO, Kotlin is where all the Java refugees on the JVM continent are at.
  • travisgriggs 6y ago
    I use Kotlin so that I don't have to use Java. But it's still far from the "This is the Language I want to commit the rest of my career to." Language development looks a lot like the startup path anymore. Claim you fill a need. Focus on growth growth growth by adopting features from as many communities as possible as fast as possible. If it's trendy, add it! Have a flashy web page. Find some venture capital by getting a big org to underwrite/champion you. Figure out how to really solve problems and fix everything once you've got critical community.
• twic 6y ago
  > Scala [is] easier to read and write that Java You either haven't used Scala, or you haven't used Java.
  • hocuspocus 6y ago
    Plenty of things are simpler and easier to read in Scala really: lambdas, constructors, case classes, named and default arguments, for comprehensions, collections, operators on non-primitive types, ... Sure, you can find libraries using complex type-level machinery, macros and so on. But wading through complex Java libraries that overuse OO design patterns isn't particularly approachable either.
• thu2111 6y ago
  The GC comment was true of older versions of the JVM but newer versions are much better. And by newer I mean versions released in the last 5 years or so. So not that new. There are one or two knobs left but those are fundamental to GC technology and it's not even obvious they're bad to have. GC lets you trade off memory against CPU time in ways manual memory allocation does not. You can throw memory at your program and it'll run faster, or you can constrain it and it'll run slower, but that's not a decision the developer can always reasonably make. It's in some ways inherently an ops/deployment/end user thing. Other GCd languages either: 1. Have knobs too (Go/.NET both have knobs), just usually not very good ones. or 2. Are so slow (Ruby, Python) that GC tuning is really the least of your worries and they just don't expose it at all. or 3. Are JavaScript, in which case everyone pretends that running a VM designed exclusively for laptops and mobile phones on the server isn't a giant waste of resources. V8 doesn't do GC tuning because its only real customer is web browsers where users can't do that, and heaps are small anyway. Java ended up getting a totally unfair rap about GC because it actually was fast enough that GC performance mattered, and was interested in power users on the server where exposing knobs can make sense. Other competitors don't even try, but this doesn't make them better. After all, nothing stops you just ignoring the knobs and plenty of users do exactly that.
• coldtea 6y ago
  >- The programs are very verbose for the functionality they provide. That's true for 2005, not 2021, with var, type inference, closures, streams, and other such features. And since forever getters/setters are auto-generated by the IDE (including Emaca and Vim) and can just be ignored, and Java today has Records which don't need them. >- If you do want to use Java ecosystem, there is Scala. Now you have exponential problems. Scala has less support, slower builds, and features Scala-devs are eager to abuse to make the code unreadable. >- Finally, if you have to run medium to large java programs, you need to constantly tune the JVM. No, you really don't.
  • twic 6y ago
    > No, you really don't. Production algorithmic trading app, 100k LOC, 8 GB heap, 258 threads, right now only using 105% CPU; Java 11, and this is the complete extent of JVM tuning we have done: -Xmx8g -XX:+ExplicitGCInvokesConcurrent Back in the Java 1.x days, you often did need to do careful JVM tuning. But for the past few years, you haven't. The ergonomics are enough for a very broad range of workloads.
    • coldtea 6y ago
      Yep. And to add to what you wrote for those that are not familiar with those types of apps: "Production algorithmic trading apps" is among the worst case regarding to peformances / pauses / and tuning needs.
    • blandflakes 6y ago
      Yeah G1GC has been a marvel for us as well (high traffic streaming video)
  • esarbe 6y ago
    > Now you have exponential problems. Scala has less support, slower builds, and features Scala-devs are eager to abuse to make the code unreadable. Unfortunately, the Scala compiler is quite a bit slower than javac. In practice this doesn't hurt quite so much anymore; incremental builds make working even with large code bases quite snappy. Full-rebuild; get a coffee. The build tools for Scala have _massively_ improved in the last 5 years. IntelliJ support is superb and VS Code with metals is shaping up very nicely. I agree that since Scala is a unopinionated language, you need to be strict in what you allow your devs to do. Code reviews and agreements on levels of abstraction and concepts used is mandatory. I've worked with multiple teams in the last 8 years and this discipline is important when working with Scala. Doing so will give you the opportunity to write clean, maintainable and readable code in a very powerful language.
• chriswarbo 6y ago
  I think of Java as hitting an 'anti-sweet-spot': - It forces us to go through the ceremony and verbosity of static typing, yet blows away lots of the benefit by pervasive use of `null` and `Object`. Compare this to ML or Haskell, where there's less ceremony (Hindley-Milner type inference) yet more safety (no `null` or down-casting) - Checked exceptions have a similar ceremony and verbosity problem, yet the pervasiveness of unchecked exceptions prevents us actually having much confidence that calls will succeed. Compare this to effect systems, even rudimentary ones like Haskell's (`Maybe`, `Either`, `IO`, etc.): if a function doesn't return one of these 'effect actions', we can be pretty sure that it will succeed (the only unchecked exceptions I've encountered in Haskell are pretty catastrophic things like OutOfMemory). - It needs to be compiled ahead-of-time, which requires more tooling, makes automated testing more annoying (we have three different failure-reporting mechanisms: app compile error, test compile error, test failure), tools like REPLs are second-class afterthoughts, etc. Yet the resulting bytecode still requires an interpreter (JVM), which takes a while to spin up, and makes deployment and packaging harder (we don't have a self-contained binary). - It pushes an OOP style, but requires that we keep subverting it; e.g. pervasive use of using structured-programming constructs like `for` (which other OO languages like Smalltalk avoid in favour of method calls), which requires we break encapsulation/implementation-hiding (e.g. if we loop with an 'Iterator', we need to know whether anything we call will use that same Iterator). - It seemingly pushes a high-level, highly-abstracted design (methods calling other methods, classes maintaining their invariants, etc.); but then throws threading into the mix, which breaks things into such low-level pieces that even 'i++' needs to be thought of in terms of constituent parts (read, increment, write, return). I agree that Scala's better (e.g. reducing a lot of the typing ceremony; making it easier to remain high-level/abstracted (e.g. encouraging 'map' and friends rather than effectful loops), etc.); it inherits some of Java's problems (and doesn't even flag checked exceptions!), but it's nice enough to tilt the balance in many cases.
  • twic 6y ago
    > pervasive use of `null` and `Object` Who is pervasively using Object? You are talking about a language that hasn't existed for a decade.
    • 6y ago