4 ms·
Go has concurrency features that the other languages you mentioned don't have. The select construct is a very nice language feature and allows a surprising amou
by echlebek 11y ago
Go has concurrency features that the other languages you mentioned don't have. The select construct is a very nice language feature and allows a surprising amount of power.
Go's compiler is very fast, which saves a lot of time in aggregate.
Go exhibits good design in many areas, including the core language, the compiler toolchain, and the standard library. You can write a complete server-side web application using only the standard library, and it won't be terrible.
Go is generally easier to learn than C++ or Java, and requires fewer concepts and fewer steps to produce a working program. A person who has written programs in Java or C can probably learn Go in about a day. Go's spec can be read in one or two sittings. The way to write "good" code in Go is usually obvious.
I've spoken to some detractors of Go and can understand where they're coming from. Erlang and Elixir users tend to not find Go's concurrency features compelling. Functional programmers will not find that Go provides much in the way of expressive power. Java programmers have expressed concerns about the Go garbage collector, although I think a lot of those concerns are now at rest.
For those that enjoy the set of tradeoffs that Go makes, it's a nice way to engineer software.
edit: typo
- pjmlp 11y agoJava 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.
- brightball 11y agoGo also has much lower RAM overhead with that concurrency.
- pjmlp 11y agoAssuming 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.
- geodel 11y ago> 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.
- pjmlp 11y agoExcept 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.
- NateDad 11y agoWell, 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.
- pjmlp 11y agoThe 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.
- hordeallergy 11y agoA 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.
- wiremine 11y agoI 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.
- mangeletti 11y agoWhat about for a Python developer with no experience in static/compiled languages?
- tkinom 11y agoI 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.
- dimgl 11y agoWhy not just use Elixir if you need concurrency?