Hacker News Reader

Comment by konart | Hacker News Reader

In my personal opinion it's a great language to solve problems _I_ have to deal with in course of my work. Can I solve them with Java?

Sure.

Difference is go does not have the complexity you can find in Java and quite opinionated. So you don't have to spend as much time working with the language inself and can focus on getting the job done.

Go is not as expressive and some other languages and does not have the same abstractions that make other languages more suited to be used while developing comlex software.

Thing is - in many cases you simple do not need any of it, but need a fast verbose language with good tooling.

Call it Java Light or something.

View on HN

Java is absolutely not a complex language. The “enterprise java” style is an unfortunate one that can actually be traced back to C++, but it is not a necessity at all, and due to the sheer size of the java ecosystem you will find plenty of examples of a more barebones approach — also supported by the language developers.

I fail to see why I would go with go over java, besides.. perhaps some CLI app? With Graal even that can be implemented in Java.

>The “enterprise java” style is an unfortunate one >but it is not a necessity at all

The thing is in real life you have to deal with this kind of code most of the time. Because most of the time you deal with the old code or people who are used to some patterns you have to use too because you are part of the team.

Go enforces (kind of) a more barebones approach by default.

PS: I think it's poinless to compare two languages. We should rather compare real practices and read examples.

Ad absurdum than a new language will always be better, because usage patterns change and the new language doesn’t yet have any existing code bases using the old ones.

Could you elaborate on exactly what complexity in Java you're referring to?

By having an overly simplistic language, you end up pushing more complexity onto the programmer and into the code base. There is no free lunch.

I find it much more sane to solve and express code in Java. You get terser, more to the point code that reflects the underlying logic more clearly, compared to having to read many lines or pages to understand what's going on.

>By having an overly simplistic language, you end up pushing more complexity onto the programmer and into the code base. There is no free lunch.

Sure, I just don't see this as a problem.

As a result you have

a) a number of third party packages to chose from depending on your needs\opinions

b) you have a more verbose codebase, some people find it harder to deal witih while I find it easier to deal with.

>compared to having to read many lines or pages to understand what's going on.

Different people different ways of thinking I guess.

In my eyes Java code looks to much like a specification in for of a code. Easier to do a code review but harder to actually understand how it works. And I personally need this dive into internals to actually feel confident about the code.

>Could you elaborate on exactly what complexity in Java you're referring to?

I don't have too much experience in Java, but from what I've seen - Java has too many abstractions and OOP for the sake of paradigm and nothing else.

UPD: adezxc's comment is a good addition to mine

It is frustrating to read Java code. I don't want to understand your abstractions or class definitions like final, static and whatever.

I don't want to learn about Gradle or Maven to understand how a package is working, I'd rather do it in code.

Consider even the current "Hello, world" example in Java (Yes, I know about the proposal about simplifying it), it is tedious, why would I need to understand public/private and classes before launching a simple program?

I fully agree it is a terrific piece of software, especially for industry-grade applications, yet it just isn't attractive.

Main thing IMO, is that you can start out writing pretty good Go code after 24 hours and just improve on your skills as a general programmer. With Java, after a few months you would still need to know about some methods or OOP tips/tricks, design patterns etc. to become proficient.

There is no going around abstraction, that’s a necessary part of any non-trivial program as that’s the only method we have to control complexity. Your struct is also an abstraction, you could have defined another one, use it differently, etc.

Many of the design patterns are useless bullshit, that is long superseded by a language feature, so that point doesn’t stand imo.

Go also has public/protected, it is just case-specific. If anything, that makes it harder to understand, how should I knew that Asd is different from asd beforehand?

>If anything, that makes it harder to understand, how should I knew that Asd is different from asd beforehand?

By reading docs or some kind of "Go by Example"? The same way you learned the difference between `private` and `protected`.

It is easier to know that lowercase is package-specific, uppercase is exported, than knowing which field is private/public by default.

Go reserved keywords: break, default, func, interface, select, case, defer, go, map, struct, chan, else, goto, package, switch, const, fallthrough, if, range, type, continue, for, import, return, var

Java reserved keywords: abstract, continue, for, new, switch, assert, default, goto*, package, synchronized, boolean, do, if, private, this, break, double, implements, protected, throw, byte, else, import, public, throws, case, enum, instanceof, return, transient, catch, extends, int, short, try, char, final, interface, static, void, class, finally, long, strictfp, volatile, const, float, native, super, while.

You have conveniently left out types from go’s list.. with those removed it is hardly longer, and as has been shown (case-sensitive identifiers), not all language complexity lives within keywords.

the parent's point was to compare the set of reserved keywords in the two languages

types do not enter the discussion

They do if 1/3 of java’s keywords are there due to types.

some keywords are types, but not all types are keywords, right?

like, it's not as if the go type `float64` is also a go keyword

but i guess the java type `byte` is a java keyword? according to https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k...

https://go.dev/play/p/71I57QCycTr This works, so how exactly did I leave them out?

This is why you can do

const true = false

in golang

The number of reserved keywords is not a bad thing. For example, I constantly missed `final` when I worked in golang. Just because a keyword doesn't exist does not make its usecase disappear. Same with other features like `enum` (extremely useful) and visibility rules. golang only has package private and public, not nearly as granular as one needs in practice, not to mention generating large CL's when changing the visibility rules of a function, as opposed to simply having a 1 line change. Sure you can ignore those use cases, but it doesn't mean that their usefulness disappears.

> The number of reserved keywords is not a bad thing.

I'm not saying reserved keywords are bad. I'm saying there's much more to learn about Java to learn programming, Go is limited with its' keywords and 'features', which often results in more LoC, but makes it super easy to get going, run into general programming problems like using a variable instead of a reference to it, etc.

In Java, you spend much more time learning the features of the language itself, even simple things like (s)Strings are not easy to understand, then add classes, inheritance, UTF-16, adding other libraries, build tools, JUnit and many, many other things that are given to you with Go.

When I had to learn golang, picking up the syntax was easy, but it has many gotchas that you end up having to spend time to learn them anyway, which don't exist in Java (e.g. the Java compiler requires final or effectively final vars to be passed into lambdas, golang happily complies ending up with race conditions).

I don't see why learning language features is an issue. The language offers features to provide more correct and more expressive code.

golang does not solve the variable vs reference issue at all by the way, and in fact, introduces weird edge cases, such as nil interface not being equal to nil.

Why do you say Strings not easy to understand?

We should optimize for clear and concise code between experts. You’re going to be an expert for most of your career, and that’s when your time has the greatest value. A small learning curve is bad because you quickly run out of ways for tools to help you. I want to use the most powerful language I possibly can; the time investment pays off.

Sure, but it doesn't change the fact that I don't like reading Java code and prefer Go.

I want to learn programming before becoming an expert in the language. I feel like it's easier to do using Go. In Java you have to become a bit of both to be efficient.

A number of years ago, I decided to try out this Java monster. Figured I'd add it to the tool belt. Opened the first hello world tutorial Google game me. It started with xml files to define string content. I noped out.

It sounds you're conflating an older framework with Java the language.

Reply on news.ycombinator.com