>The sheer verbosity of Java is just unbearable when you're used to Python/Go/Swift/etc.

I'm used to Python (and some Go) for decades, and the verbosity of Java is a non-issue to me.

I'd rather have the speed, type safety, and refactoring tools support, over Python... (not to mention the much better packaging situation).

I'd still prefer Python for smaller programs, basically because of the startup time and quick write/try cycle. But for larger stuff, I'm not so sold, and I've been doing them (in Python) for decades...

Or you could say nobody who has ever had a working IDE setup could ever go back to Python.

Saying this as someone who Java after Python and other languages.

I honestly don't know how anyone could think Go is less verbose than Java.

Manual for loops? No generics?

I am sorry, Go? That can’t be right. I even doubt it’s any more verbose than python or swift. You CAN make it verbose that’s for sure.

>You CAN make it verbose that’s for sure.

No true scotsman? Even if you want to argue that Java CAN be made more terse, the vast majority of Java that exists today is incredibly verbose. Even running a Java program is verbose. Java is the only language I've used where it's more common to have a shell script that starts your Java program than just running ./helloworld.

And yes, Go is less verbose than Java. Go might require some boilerplate, but it is certainly much less verbose than Java.

Verbosity is not a problem in large code bases. Speed of understanding and debugging of what somebody else wrote is.

So, less magic is better. I will take Java codebase over Scala or Python every time, unless it is a toy script which is 100 lines

Every significant Java codebase I've worked in has had incredible amounts of magic. Between AOP, DI frameworks, APT, reflection, proxies, SPI, Lombok compiler hacks, dynamic classloaders, etc., there is a LOT of magic flying around and it can be quite hard to understand what will happen at runtime.

I’m not a backend java dev but whenever I take a look at java web projects which use spring/jsf/jsp etc frameworks, docs say to handle a request, write a method with that signature, we’ll call it when there is a http request. I always want to know enterence/exit points of a network message but that is impossible with these fancy frameworks. It is pure magic.

Don't forget XML DSLs. Or are we past that?

This is what drove me away from Java; the ungodly amount of magic that's required to make it economic. If it all works, it's fine. But as soon as something fails... Get yourself ready from some frustrating hours.

This. Java communities tried to solve redundant code problem by complex, hard to recognize way.

Still got PTSD from a Hinernate codebase that had all sorts of initialization magic afoot.

Who needs CPP macros when you've got reflection?

I’m talking about the language, not frameworks.

AOP sucks because it is paaaain to debug, proxies are magic. There is Dagger that solve some stuff

ALL Java developers should be required to watch this course (it's Free):

https://software-mastery.teachable.com/p/uncommon-sense

FYI: I am NOT an author of this course.

Java style verbosity hurts readability. That’s the most important issue with Java imho.

Take a look at a http server one in Java and one in C. Readability difference is crazy.

My company is in transition from Java to C, for bunch of stuff just for performance reasons. So, I debug similar projects time to time both in Java and C, http server, in memory cache, iot server etc. After seeing both, I just think although Java has great tooling, it drives developers to write unreadable code.

I mentioned C as a language of choice. Cool kids are picking node js and esoteric Closure, not C

> And yes, Go is less verbose than Java

No, this is utter, utter nonsense. I have written plenty of both, and it's not even close.

If you are going to press this extraordinary claim, you need to supply at least some evidence for it.

We should keep in mind the kind of features, performance, observability the jvm can provide, compare that with the other runtimes and then see if the script to execute is too much :)

Go's error handling is painfully verbose. Go's lack of generics leads to passing empty interfaces everywhere (come on proposal!). Don't act like go doesn't have it's warts. If it wasn't backed by google it wouldn't be nearly as popular as it is.

Perhaps verbosity isn't the right word, but having to put every function in a class (in a correspondingly-named file) feels extremely cumbersome to people who grew up with languages that just have functions and weren't exposed to Java early on.

Nobody who has ever written error handling in Go could possibly downvote this comment. Holy moly, the error checking after EVERY interesting method call. Talk about verbose.

It's useful verbosity. Java's verbosity is misplaced, which is worse.

That’s just false

Go's error checking is the 2020's equivalent of "Python's significant whitespace". Both are pretty common and rather shallow critiques of a language.

You can write verbose code in any language, but most other languages don't consider it normal to name a class LangDetectLanguageIdentifierUpdateProcessorFactory. (Random example from an open source framework.)

Eh, any sufficiently large or complex codebases will get ridiculously long names at some point. Here are some from a famous C API (Windows):

    CoMarshalInterThreadInterfaceInStream

    D3D12_GPU_BASED_VALIDATION_SHADER_PATCH_MODE_UNGUARDED_VALIDATION 

    RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext

Or how about:

    GtkColorSelectionChangePaletteWithScreenFunc

The alternative is things having names that aren't actually descriptive at all, which is not clearly better.

Or have a good package system... If you use a language with import with aliases, you don't need all that noise.

Java has such a system but people write long class names anyway, because people don't like to have too many types with identical names distinguished only by namespace. You can do it but it's a bit questionable to what extent you should.

But how else will your app automatically detect and inject its enterprise LangDetectLanguageIdentifierConfligurator at startup?

I just got some flashback reading that long string, and my heartbeat raised. The namespacing system is also a nightmare

Com.prout.shit.lol...

Namespacing in reverse dns order is something Java got right. It naturally segments things and you can immediately see the relative provenance of classes.

It’s just impossible to use without editor support. Nobody who cares for their sanity can type out those package names manually. I think even Gosling said as much.

Just trying to find files relevant to some functionality is incredibly difficult without full-text searching all the files. Namespacing is fine but why must the entire path be reflected in directory structures?

To prevent half assed refactoring in the first place where only namespaces and classes get refactored while folders and filenames remain as they were. It would just further confuse new devs on the project.

or as the saying goes, "you can write java in any language".

Making JavaScript turn into Java bytecode is not a magical experience.