Rust and Go are so completely different that I don't see how they're similar. OTOH, I write most of my code in Java, and a little bit in Go, and can hardly tell the difference between the two (their goals, design philosophy and levels of abstraction are nearly identical). I use Go for small command-line apps, where it shines, and Java for more serious server-side software, where I can't do without its unparalleled monitoring and tooling and more, uhm, grownup approach towards dependencies and project management (unless you work like Google). I know some people don't like Java, but I'm puzzled when the same people like Go (I can understand how you can like neither, or, like me, both). I agree that the onboarding experience for Go is better and more familiar to people coming over from Python (perhaps to the point that to people coming from Python, Java and Go appear very different), but if you're used to Java, Go feels like Java-lite. You use it when you need something more quick-and-dirty (or for command-line apps; Go is a much better fit than Java for those), but you stick with the "full" version for the serious stuff.

The only reason I will stick with Java is because business applications are in Java and there is no reason to use any other language.

> their goals, design philosophy and levels of abstraction are nearly identical

I think it could not be more different. Java APIs (including libs by Sun/IBM/Oracle) is a manifestation of more is less which is exactly opposite of Go.

> Java for more serious server-side software

The seriousness part is only because serious folks (the one who fund projects) prefer Java. I too think this is very important if not the most important part.

> unparalleled monitoring and tooling and more,

I too would need lot of monitoring and tooling if Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us.

> Java APIs (including libs by Sun/IBM/Oracle) is a manifestation of more is less which is exactly opposite of Go.

For example?

> The seriousness part is only because serious folks (the one who fund projects) prefer Java.

I disagree. There are plenty of design decisions in Go that make it less optimal for very large projects (e.g. dependencies, error handling, generics), but most of all lack of hackability. Go is one of the least hackable languages I've ever encountered, i.e. the only escape-hatch you have when you realize, 5 years into the project, that you need to circumvent some runtime semantics are either source-code instrumentation or hacking on the runtime itself.

> Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us.

There is no way Go's GC wouldn't crap out on you sooner (except maybe in the circumstances that are now addressed as part of Valhalla).

Having said that, I think Go is great, and is a natural fit for anyone who likes the Java philosophy (which is also the Go philosophy)[1]. Some design decisions and some implementation circumstances just make it less suitable for really big stuff.

[1]: Namely, reading comes before writing, no too-clever tricks, and no cutting-edge PL ideas; a "blue collar" language, as Gosling referred to it.

> I use Go for small command-line apps, where it shines

I'm curious. Is there empirical evidence proving that Go is better than Java for small command-line apps, or did you just use your personal judgement to reach this conclusion?

> Is there empirical evidence proving that Go is better than Java for small command-line apps

Sure. It doesn't require warmup, it's a little easier to deploy as a standalone executable, and performance is comparable to compiled Java code in programs of this size (you can easily confirm all three claims); those are pretty much the relevant requirements from many command line programs. It's not a property of the language but of its implementation choices (AOT compilation, statically linked runtime), which match the requirements of those kinds of applications better.

I actually think Go's simplicity is a weakness because it will only get you so far. Take web development for example, all the tutorials show json.Unmarshall, but this one stackoverflow post says I should use json.Decode. Oh shoot now I'm having all sorts of problems because I don't really understand json.Decode.

Furthermore I think most people reach for Golang in the beginning because they want performance. However I've found it incredibly easy to write unperformant Go.

I think Golang will ultimately be a very important stepping stone in language development in terms of concurrency, type systems, standard libraries, deployability, and many other categories. I think a lot of important programs will be written in it. And ultimately I look forward to how future languages draw from it.

"I actually think Go's simplicity is a weakness because it will only get you so far."

Some may argue that Go's simplicity is a strength. Adding moving parts doesn't always help.

> I think Golang will ultimately be a very important stepping stone in language development in terms of concurrency, type systems

"stepping stone" usually implies progress and Golang was a regression on both fronts, and while its deployment story is ok that's in no small part because it just opts to statically link everything by default, which the field has been going back and forth on basically since the beginning.

"Take web development for example, all the tutorials show json.Unmarshall, but this one stackoverflow post says I should use json.Decode."

Plenty of JSON libraries in plenty of languages have both a function to decode JSON and an object that allows you to decode JSON with some settings. That's not really a Go-specific issue.

Your issue here (obviously), is going to stack overflow for advice.

The days of Java being verbose are over with Lambdas and Method References. I don't know what you mean by "getting in the way".

If you have time to spare read this: http://blog.paralleluniverse.co/2014/05/01/modern-java/

he may have meant this:

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

One just can't write this shit in Go. The language itself precludes it.

> The language itself precludes it.

It really doesn't, and you could write the exact same thing. Java code doesn't look like that, either (certainly not modern code).

In particular, it's preposterous to call Java verbose in comparison with Go when Go has the error handling that it does.

Hi, could you elaborate on you comment about Go's "less than stellar type system"?

Lack of generics (stick, meet dead horse) is at the forefront.

Lack of very basic functions (map, filter, reduce) against slices.

map[string]interface{} is pain to work with (one of the moderately popular libraries I mentioned helps: https://github.com/karlseguin/typed)

Lack of immutability.

I don't want to get into errors vs exceptions, but I've never heard a pro-errors argument that wasn't hand waving. I think the decision makes sense given Go's genesis (system programming), but given how Go's actually being used, it's a step backwards.

What I struggle to understand is: If that functionality is considered useful or even impeding the development process for those developing in Go, why has nobody forked the language to add them?

Many of the points you mention are fairly low hanging fruit for inclusion if you are willing to accept the tradeoffs that official Go maintainers are not willing to.

I think the trouble there is just that many other modern languages haven't taken the extreme stance on typing that Go has. It's much easier to learn say, Rust or Scala, than it is to fork and maintain a branch of Go, and there's certainly nothing so special or attractive about Go to tip the balance in the latter's favor.

The issue with that is that anyone invested in Rust or Scala have no reason to want a better type system in Go. Fixing Go is as important to them as fixing COBOL, and I don't see HN full of threads on what needs to change in COBOL.

What we have here is people who are already heavily invested in Go to the point where its type system is a real problem for them, yet they do not want to fix the problems, even in light of the relative ease at which at least some the problems can be solved (again, if you are willing to accept the tradeoffs).

Check the gonuts archives to see how welcoming the community is to such ideas.

Yes, exactly.

You could fork Go and add generics support, but you'd be maintaining that fork forever. The Go core team would never allow it to go back upstream.

It is rather surprising if not outright shocking that experienced developer get heavily invested in a language when other mature/ better alternatives are there.

> What I struggle to understand is: If that functionality is considered useful or even impeding the development process for those developing in Go, why has nobody forked the language to add them?

The group of people who are able to fork, change and maintain their own Go variant are usually not the people who would ever consider using Go in the first place.

Have a look how long it took PHP to get an AST (instead of the broken mess of reading&executing). Those who are able aren't those who would ever deal with PHP.

I've sometimes wondered a bit about this myself. But consider what you'd end up with if you wanted to keep most of go's benefits, but add on such bits. And consider that you could just use Ada, Nim or OCaml. Or maybe Rust (I really like Rust, I'm not sure how much overlap there is in any subjective list of "Go the good parts" and "Rust the good parts" though).

I think some of the best parts of Go is the central model: "go get", "go fmt" along with the standard library - if you fork, the burden falls on the fork keep all that stuff working in a sensible way too.

Go' success is not a mere coincidence:

- OCaml is great but parallelism is still limited by its "Global Interpreter Lock" (like Python or Ruby).

- Rust is great but ownership/borrowing is not for everyone and people sometimes prefer relying on a good garbage collector.

- Nim is great but it's a "small" project compared to Go and most people prefer relying on a large ecosystem like the one offered by Go.

- Ada was a major milestone in the history of programming languages, but it's considered by most as an "old" language, compared to Go/Rust/OCaml/Haskell/Scala/etc.

Thanks. Right, generics is a big one. But isn't Go actually being used for system programming? At least that what I think of when I think of Golang. Maybe the scales have tipped and writing api/microservices is the larger use case now?

I don't know. All I know is this [possibly dated] quote from Rob Pike:

"Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++"

Maybe Python and Ruby programmers are adopting Go to do system programming, but that isn't my impression.

While this may not be a popular opinion, I find Go's type system to mainly benefit the compiler in optimization and be of minimal benefit to the safety or correctness of the program.

Any non-trivial Go project will have interface{} sprinkled all over [1], which effectively gives you the guarantees of a dynamic language with the syntactic overhead of a typed language. Truly the worst of both worlds. While I realize it's a tired argument, Go desperately needs generics in some form or another. It would remove most criticism from the language while substantially improving the correctness of programs.

[1] Here's an example with an LRU cache. Just search for interface{} : https://github.com/hashicorp/golang-lru/blob/master/simplelr...

> It would remove most criticism from the language while substantially improving the correctness of programs.

You seem to assume that people who do not like generics complexity will not complain then.