Java vs Go

• A Hello world needs package, class, static method and the actual printf.
• Reading a line from input requires instatiating 5 objects in the right order.
• Exceptions are everywhere, particularly since all values are nullable.
• Java has a getter/setter culture, but without native syntax support.
• portable Java code lacks anonymous functions, and continues to lack good support for partial application, compensating instead with verbose design patterns, kludges like anonymous inner classes, or just inline code.
• It is statically typed without type inference, with a culture that promotes long class names.
• Poor support for sum-types and pattern matching leads to overuse of inheritance for dynamic dispatch and chains of nested conditionals

Especially for beginners, this can make reading Java code feel overwhelming; most Java courses tell students to simply copy, paste, and ignore a significant percentage of the code until they've learned enough to understand what it means.

For experienced programmers, this makes Java feel tedious, especially without an IDE, and actively discourages some solutions and some forms of abstraction.

Some features in Java can be quite confusing for beginners.

Encapsulation is needlessly obfuscated with a confusing access control model. As an example, the "protected" keyword not only grants access to child classes, but to the entire package. Since small programs are written as one package, it becomes functionally equivalent to "public".

In OOP, everything is supposed to be an object, but, in Java, primitive types such as integers, booleans and characters are not, and must be handled as special cases.

Java continues to lack many high-level features, and, particularly prior to Java 7, compensated by adding confusing Java-only features, such as anonymous subclasses. Some example code is unreadable without knowing a special-case feature, libraries differ in style based on when they were released or what platform they target(e.g., Android vs. Desktop), and some solutions just aren't available on some platforms.

Overly focuses on class-based OOP to the detriment of programmer freedom or alternative paradigms that are better for various problems. Traps programmers into an always use class-based OOP mindset.

Type erasure means it doesn't even exist at runtime. The whole generics system is confusing for beginners.

Too far from the machine hardware.

I've been developing in Java for 20 years and I love this language, I've never used a better designed one over the last 30+ years. However, starting with version 6, the number of really useful features in each release has steadily decreased. There is now too much marketing in Java's evolution and too few concern about developers' needs (the functionalities of the applications we develop haven't changed and enterprise application architecture is much simpler than 20 years ago). I'm deeply sad to say that today, learning Python is a much wiser choice.

Java is a garbage collected language and it does not force programmers to think about memory allocation and management for their programs. This is fine most of the time. However, it may cause some difficulties in adjusting to a non-GC language (such as C for example), where memory management needs to be done manually. But if good coding practices and habits are followed, this shouldn't be much of a problem.

It's just barely good enough to make decent IDEs, but it's not at the level of Idris or even Haskell. For large enterprise projects, the IDE support is important, but the static typing in Java just gets in the way for the smaller projects beginners would start with.

Python is duck typed and this makes small programs easy to develop quickly, but the price is that you have to write unit tests to avoid breaking larger programs. In contrast, you can be reasonably certain that a program that actually compiles in Idris does what you want, because assertions are built into the powerful type system. Java can't make that claim and still requires unit tests. Java has the worst of both worlds because of its poor static type system.

The type system gets in your way more than it helps. Heavy IDE support is absolutely required for reasonable productivity. This means beginners have to learn not just the language, but eventually a complex, heavyweight IDE too.

Java evolves very slowly - lambda expressions weren't available until Java 8 (which is not available on Android), and despite getters/setters being a long-time convention, the language still doesn't have native accessor syntax (a la C#'s properties). It's unlikely newer, popular features like list comprehensions or disjoint union types will be available anytime soon. While not strictly required for novice programmers, these make problems more complicated and tedious than they need to be - for example, when a simple local function would do, (portable) Java demands anonymous inner classes, an interface and a class, or worse, no abstraction at all.

Since C# came later, it could avoid the blatant mistakes made in Java.

Java utilizes principles that primarily organize code into "classes" as the central concept, instead of more familiar organizational methods.

Checked exceptions add significantly to the cognitive load of the beginner. The more rules unrelated to the actual task that you pile onto the beginner, the slower he gets. Exponentially. And for what? Sure, they look good on paper, but checked exceptions are useless in the real world. They don't scale.

When you're calling APIs five levels deep and your method's throws clause balloons to 80 exceptions you might see, it gets kind of ridiculous. So you just say throws Exception, which defeats the whole feature, but is more pointless boilerplate in an already tediously verbose language.

Or worse, while developing you can't be bothered and just catch{} and silently swallow them all. Then you forget about it. Now you don't even have exceptions. The cure is worse than the disease!

So the wiser Java programmers will wrap all checked exceptions into a runtime exception, effectively making exceptions unchecked. That's at the cost of more boilerplate, but it's the lesser of evils. Unfortunately, Java doesn't even have macros to do this part for you. Maybe your IDE can write code templates for you, but that doesn't make it any easier to read.

Solves Google problems, which might not be your or the majority of user's problems. Was created for the benefit and purposes of Google, so is less flexible in language direction and options.

Go is famously regarded as very simple. However, this simplicity becomes problematic in time. Programmers who use Go find themselves over and over again writing the same thing from a very low point of view. Domains not already served by libraries that are easy to glue are very difficult to get into.

Golang developers were extremely short-sighted and biased by forcing the K&R style, which should never have happened. Basically kicking Allman style users out of their language.

Golang does weirdness with const versus having real enums, like other languages. This reflects the stubbornness and shortsightedness of the core developers, similar to the issue with generics, where it was denied that it was needed until it became too obvious that it should have been added years ago.

Makes it harder to have functions of different parameters types in a non OOP language. Thus messy generics and interfaces, and more confusion, where sum types could have solved a number of issues.

Newer languages that could threaten Golang (or other Google controlled languages) appear to have suppressed search results on Google and YouTube. Dangerous situation where large company can manipulate user choice and market share. The freedom to freely choose and user rights need to be protected.

Go was designed for large team projects where many contributors may be incompetent. That Go can still get things done under these conditions is a testament to its utility in this niche. Go's infamously weak abstraction power is thus a feature, not a bug, meant to prevent your teammates from doing too much damage. This also means any team member can be easily replaced by another code monkey at minimum cost. Good for the company, bad for you. The more talented programmers, on the other hand, will be very frustrated by having one hand tied behind their back.

Due to single character only difference, declare and assign statement can easily shadow variable from outer scope unconsciously. Example:

err := nil
if xxx {
  err := somefunctionthatreturnsanerr
}
return err // always return nil

Those who are used to Visual Studio can feel the lack of a forms designer for rapid development.

Only way to prevent something from being mutated is to make copies of it, and to be very careful to not mutate it.

Practically no meaningful Go application can be written without indirect function calls and garbage collection, these are central to Go's core infrastructure. But these are major impediments to achieving good performance.

Finding out what interfaces are implemented by a struct requires a magic crystal ball. They are easy to write, but difficult to read and trawl through.