Hacker News Reader

A person who has written programs in Java or C can probably learn Go in about a day.

I really wish people would stop saying this. There is more to Go than just the syntax. I'm a Go dev on a team of php and Java devs, and just the opinionated philosophy of Go is hard to get across to them. They bypass the Go interview only to create the mess interviews intend to prevent. They are junior/mid devs again, except that because everyone keeps saying Go can be learnt in a day they think they've already mastered it. Go is easy to get started, but there is somewhat more than a day's worth of learning, I see this daily.

I don't think a day is reasonable either, but 2 weeks is. You get to a point where you just sort of run out of concepts to learn... it's a weird feeling at first, to be honest with you.

What about for a Python developer with no experience in static/compiled languages?

I did a simple port of Python program to go a while back.

The python program is web backend for JQuery+html Single page web app for front end. It built its own database in the backend on top of SQlite.

It is not that hard to part a few features over, ~1-2 weeks including learning time. There are lot of examples on how to do most of typical web programs with REST/AJAX for golang.

The REST/JSON in golang is a lot of verbose than python. Go need to define all JSON fields via marshalling which is none-trivial amount of boiler place template code code. It does very strict type check on all incoming JSON structures. I have full functional regression test coverage from my frontend code to the all the python REST APIs /JSON structures. The more stricter type check in REST/JSON in the Golang requires a lot of work while provide little value for me.

The error handling the go compare to pyhon is an "acquire taste". (I have to acquire that taste yet.)

I was used to the code style of raise/catch exceptions. Python provides extremely good stack trace feedbacks on those error cases. Recover from exceptions in python are trivial.

My python code needs to build/handle 10-25 GBytes database. I spent non-trivial amount of time in the low level API of python/C code to optimized/debug memory related issue at that scale. All the issues in python backend were worked out already. The backend python all used very little memory in building and using 20+GB of DB.

For Golang, I can not get pass that barrier. Building a DB of about 2-4GB cause the golang app to completely slow down. (Most likely GC kick in, memory hogs on system level.) I spent a few more weeks on golang and can't get enough info to fixed that issue and put that porting from python->Golang project on the shelf. In python I can force a GC operations in certain point of my app to see the memory usage clearly drop down. I can't find a way to do that in golang. There were documented API in golang that supposes to do that. But it just doesn't works for me.

That's > 1 years ago.

I don't agree. After two weeks people are still unaware of lint, vet, -race, haven't even begun exploring how error values can be managed, ... Interviewees with 6 months of Go are regularly rejected - how is that possible if it's so quick and easy to learn?

Most interviewees are rejected anyway.

If they have the fundamentals down and are creating a "mess" that sounds like a failure of the existing project leads. A little code review and direction goes a long way.. It doesn't take long to run lint, vet, -race by someone. Establishing best practices and engineering principles for the project/team can help tremendously with on-boarding too.

Java programmers also know a thing or two about java.util.concurrent, parallel streams, futures and Quasar.

The only thing Go concurrency has over them is that it is easier to start with, but it isn't easier to use any other pattern, because Go doesn't allow library code to be first class in the type system.

Go also has much lower RAM overhead with that concurrency.

Assuming a JIT/AOT compiler that doesn't do escape analysis, which varies across JVM vendors.

Also Go's advantage in using value types will vanish when Java finally gets to have them, although we still need to wait for Java 10 for them, while Go is available now. So Go does have a few more years to gain developer mindshare.

Still Java isn't the only game in town, and there are other alternatives with GC, value types, more expressive type systems and battle tested concurrency frameworks.

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

How the mighty have fallen. A language with more than decade over Go and billions in investment by top tech companies and literal monopoly over enterprise usage need to even think of user share of a marginal language.

Except you are off base giving too much value to Go.

What is driving value types in Java is HPC and HPT companies in places like stock exchanges and biology research that want to move away from C++ into JVM land, but still need to keep some C++ around due to value types or make use of com.sun.unsafe tricks.

Nothing to do with Go.

Well, the thing about Go concurrency is that it has been with the language since the beginning. How much library code is compatible with concurrent or streams or futures or Quasar? If you choose one over the others, are you limiting yourself to only libraries compatible with others that made the same choice as you? How much of the standard library is compatible with each of those?

The same thing goes for value types. In Go, everything uses value types. The standard library is littered with them. Will it be the same for Java? It seems unlikely, given that they have to keep backwards compatibility.

Granted, this is all from the point of view of an outsider who only dabbled in Java, so I may be way off base.

The java.util.concurrent was introduced with Java 1.5, so 2004.

And there were alternatives available before for Java 1.4.

Which means most Java libraries had lots of time to adapt to it.

Also threads and concurrent queues are there since the early days.

Java already has a kind of pseudo-value types, but it is JVM specific. Some JIT and AOT compilers do convert final classes with only accessors (think Point) to value types.

But yeah, it is a JDK vendor specific optimization that one cannot control.

Likewise you cannot control if a value type in Go gets stack or heap allocated, if I remember correctly. Hence why the compiler options to debug how the compiler decided to do it.

Java value types will take time to get adopted surely, but in many type of applications it doesn't really matter that much.

The use cases driving value type's adoption are related to HPC and HPT, many of which are trying to move away from C++ into Java, but still find themselves have to make use of com.sun.unsafe for that last mile.

At least as presented by IBM and Azul on their talks about their approaches to value types in Java.

Why not just use Elixir if you need concurrency?