Yeah. this is one of the main reasons I use Java for most of my work. The time spent putting out fires caused by framework- and library churn is time not building something useful.
My personal diff against most languages goes something like:
1. Stuff rots a lot less fast than in python and js. Code keeps working for longer, dependency goofiness happens a lot less, etc.
2. It's just less clunky than golang - but this is mostly my own preferences. I often describe go as if someone designed a language, and then had this list of hard language design problems, and were I to look at this list, I would go "hmm yes these are hard problems where all the options have drawbacks", and then for EVERY SINGLE ONE OF THEM they picked the compromise I would not have picked. So it's just death by a thousand little things that annoy me. My current job is golang though so I'm wondering if I'll come around to it or something. We shall see.
3. Java just doesn't encourage such terrible cleverness that Scala (and to a lesser extent python and js) invites. This might be cultural too where Scala has this functional programming fanatics segment who love the cats library a little too much. But never have I ever before seen so much code that's just intractable to junior devs, and requires far too much brain-CPU for mids and seniors to read. Sure you can get into a lot of trouble with Java's reflection, but IME many java devs are suitably reluctant to go reflection crazy.
4. Damn is it fast by default. And can be REALLY fast if you specifically focus on a specific path.
5. The tooling is so mature. Does python or go even have anything like VisualVM? And as I understand it, even VisualVM is old hat compared to JFR, though I've not looked closely there.
6. The library ecosystem. It's even more expansive then npm but 10x less thrashy and churny. I particularly like that there's this interesting niche of academic libraries that end up out there that you might find yourself bumping into now and then.
7. Packaging. People use maven. Even people who use gradle still basically are just using maven with extra steps. Sure it's XML but aside from adding dependencies, you hardly touch it. And if your build system truly needs to be weird (like, say, android), then gradle is right there for you. 2 tools for the whole ecosystem. How many does python have again? I find I have little patience for packaging problems and I suspect some of it stems from the fact that if I were using Java, I wouldn't be having packaging problems.
I'm sure I could go on, but I'll cut it here. For a million reasons, I find stuff built in Java just works and keeps working (both dev-environment and in prod) far more probably and for longer than in other languages and stacks. And it's fast enough to develop that I'd say it's well within range of python and ruby and such, for anything that bigger than a couple files.
Java has improved significantly in this regard, but Java used to be the poster child for overly clever intractable code. It mostly been relagated to memes and legacy code, but AbstractFactoryFactory used to be the way of writing Java code, where everything was supposed to happen through a dozen layers of indirection.
I started in Java land, and to me, the idea that you would run a command to add a dependency has always seemed a bit weird. The file with dependencies in is part of the source code, and i don't want to modify it at arm's length with a command any more than i want to write code that way.
Is it as slick as 1 command? No. But it's certainly not rocket science, and most libraries github readmes even provide you the maven <dependency /> blob, so it's not usually confusing imo. And also, I do want to point out that "just npm -i mything" comes with problems like typosquatting, which is a lot less common in java afaik.
But with npm you can still modify the package.json and it feels simpler than than the Maven XML still (though I have no idea what’s going on with the package_lock file, but I don’t think you’re meant to edit that manually)
Would you also avoid generating client types for type-safe API consumption because you have to run a command to do that instead of writing the client yourself? After all, the client is source code for the client
My package.json is part of source code. I can manually write it myself and run `npm install` afterwards; or I can do both steps via a command. The end result is identical: my package.json has a new package, and my local machine has a copy of that package somewhere too.
Why wouldn't I use the command, exactly?
Citation needed.
Installing npm dependencies in different orders is not garanteed to be deterministic due to npm's package flattening and, before npm 8, plain broken dependency resolution strategy.
The package-lock.json is essential to get the same mess that the initial developer got on the same order as his install.
> and my local machine has a copy of that package somewhere too.
On maven/gradle, like on pnpm, you get one copy of each library. Not 3000x copies of lodash spread around your disk.
> Citation needed.
What do you mean? You cited it yourself:
> Installing npm dependencies in different orders
Fortunately, there is no difference in order between running it as a command and adding it and running `yarn install`, since you already had all the other packages locally either way.
Anyways, these complaints are ridiculous, I'm sure I could dig into the past and find some broken Maven or Gradle resolutions. Let's see, 10 second time limit:
> gradle.lockfile
LOL wow.
> 3000x copies of lodash spread around your disk
LOL
Silly absolutes are a big no-no. You don't use automatic code formatting!?
Using commands to modify a literal list is fine.
For my JS projects (obviously actually TS these days), I use the exact same config, it's parametrizable to take in one argument - the private registry to use.
It's amazing for really using. Unlike Java package managers.
Gradle is not too liked (android's overly complex builds probably give it a bad name), but it is an absolutely capable build system.
For something to be "absolutely trivial", you would expect the average user to be able to produce trivial-looking configuration. It is certainly not the case with any Java program I've seen which has to handle two build environments.
On the other hand, all my NodeJS projects show absolutely no sign they had to be "adapted" to the second+ environment.
But sure, we can pretend Java package management is up to snuff, just throw some more "it's trivial"-type aphorisms around
I was stuck under very old (and deprecated) versions of node and NPM, and at my $OLDJOB lockfiles were respected with a CI under restrictive proxy service and alternative npm repo.
"delete lockfile, npm install everything again with correct repository under VPN" was a very recurring thing on every project where someone thought "it's just a npm install, what could go wrong?".
Maven supports build profiles.
Spring and other frameworks also supports runtime profiles, where you can have a YAML file for each profile/environment
Meanwhile, you are having to tell me Java package management is actually better because... it has profiles
I think that Java guys might have their heads too far up their asses
Oh, did you know that maven wasn’t hit by those dependency confusion attacks, being almost alone in that? Also, I can literally build a million lines repo faster than the frontend which is relatively small and just outputs goddamn js and css files..
My UI type-checks, transpiles, and stores itself as an NGINX container or a static bundle on my CI in 1min10, so I'm going to go ahead and press X to doubt.
> windows
There's your problem!
The parent comment asserts, without evidence, that "NPM being easy to use is a double-edged sword that will swing back at you".
I have never seen any evidence of this in action. What would it even mean!? Something being easy to use being casted as a negative in-and-of-itself sounds like Stockholm Syndrome.
If you'll downvote a long-time NPM user for questioning what's wrong with NPM given how much better it is at navigating the complex corporate environment I sit in than Gradle or Maven, at least leave an anecdote.
First of all, the context was:
my initial comment's GP: "I do really like how easy the packaging is in Python and JS is", "Maven and Gradle are a bit of a pain to configure in comparison"
my initial comment's parent: "True but beyond hobby projects this becomes a double-edged sword that swings back at you."
This comment CONTINUES to be a naked assertion based on nothingness. The negative points about NPM I've heard are:
* You should never touch human-readable files with CLIs (like package.json)
* NodeJS imports make many files because it's interpreted code
* running a command to install a package is "weird" and doing it manually is better
* Something about module resolution that was fixed half a decade ago but still didn't impact most shops that avoided drowning in libraries
You can't be serious that this is meaningful feedback.
Whatever the subject, I expect people who like a certain tech to express their distaste about other techs. I just, you know, let it slide cause otherwise it's never over. If you're looking for a bone to chew, I'd suggest you go to Reddit. Seriously.
(Conversely, I really really wish I'd done my personal project in Scala rather than C#. It manages to be good and horrible at the same time)
So I also blame Scala when people over-use implicits and go functional-mad because Scala encourages it.
It really is not a sarcastic comment, but Python is just not that fast to make GC the performance bottleneck in ordinary usage. It uses ref counting, which trades off performance to a more deterministic deallocation (plus there is also the GIL).
This wasn't Scala's only mistake though. It seems to have a history of implementing features that then die out due to a combination of lack of support and of never being implemented well in the first place, including:
* specialized types
* macros
* delimited continuations
* Scala reflection
* Eclipse IDE support
* Scala native (technically still going but only whenever there is funding at a university to pay a student to work on it)
* Multiple collections library rewrites (this one is pretty core!)
* other half-baked bundled libraries that have been deprecated/removed over time
Not to mention the number of community-owned frameworks that have been discontinued or declined in usage over time. Anyone remember Lift? That used to be the most popular web framework in Scala! And how are Play Framework and Akka doing nowadays?
I also firmly believe that Scala has hands-down the very best collections API out of any single language I have used, so there is that.
I remember loving it and saw a plenty of other community libraries leaning on it. I had some simple reflection based code I rewrote using macros for a big performance bump. The API was awkward and forced me to learn more of the magic under the covers, but in the end I was happy with it. I figured it would be too deeply ingrained and useful to just go away.
https://docs.scala-lang.org/scala3/guides/macros/macros.html
However, the macros changed enough that it can be a significant effort to port macro-heavy code to Scala 3 from 2.x. I see comments about this in the issue trackers of some libraries I use.