
Why Go? - lerax
http://neowaylabs.github.io/programming/why-go/
======
outworlder
> Compare for example the explicit Go concurrency model, that enables you to
> design a concurrent system, with Java synchronized methods, that for me
> represents “I have no idea of what is wrong with this messy multi-threaded
> stuff, so let the must lock all this stuff up”. That is not truly simple and
> it assumes you are stupid and have no idea of what you are doing.

This may sound inflammatory, but it actually matches my experience in multiple
companies.

With one caveat. There are programmers that will learn just enough to be
dangerous, who have ingrained the thought that "threads == speed", and will
try to sprinkle multi threaded code everywhere. Said code will misbehave,
which will cause them to spray "synchronized" keywords all over the codebase –
until it stops misbehaving. Or, at least, until bugs cannot be reliably
reproduced anymore. Now you have bottlenecks everywhere, even if it did make
sense to spread the workload across cores, or when you'd be waiting for I/O
otherwise.

So many people do not actually know what they are doing. And the prevalent
concurrency model in Java doesn't help make sense of what is going on. Over
time, cargo culting develops and there will be one single accepted solution
codified in company policy. Usually, a sub-optimal one.

Go actually gives you better abstractions, so you can rely less on shared
memory and more on message passing. Not only that, it makes it simpler to use
this approach, vs. a Mutex and shared memory. Which means people will reach
out for that first.

Go is not alone in this. There are languages that provide even better
abstractions(Erlang for one). But Go features tend to be 'good enough'.

~~~
candiodari
1) Go code has the same locks that java synchronized code is, they're also
used a lot

2) Go encourages more threads than java does because of the M:N threading
model

3) Go's concurrency primitives (channels and select) is actually more complex
than the java equivalents

4) Go's concurrency gives the programmer less control (e.g. how do you say, I
want max 40% cpu time spent on X ?)

In my opinion the big thing that protects Go is twofold:

a) Go is still not very common among bad programmers. Java is.

b) it is much harder to write large Go programs than it is to write large Java
programs. That doesn't make those big Java programs bad. Some problems are big
and require big solutions, say, CAD, or a company platform. Go is frankly
unfit for those problems. Especially because Java has tooling that makes
analyzing and working on large programs feasible and Go has at best the very
beginnings of such tooling.

------
dom96
Needs a "2016" in the title.

I've mostly skimmed this article but based on what I'm seeing it's more of the
same, "Concurrency", "Simplicity", "Simple deployment" etc.

I would really like to learn something else about Go now, when is Python a
better choice? When is Rust a better choice? What are the negatives of using
Go?

~~~
apta
For your last point:

[https://www.reddit.com/r/programming/comments/an33mo/aspnet_...](https://www.reddit.com/r/programming/comments/an33mo/aspnet_core_saturating_10gbe_at_7_million_rps/efrvn0e/)

~~~
stunt
>
> [https://www.reddit.com/r/programming/comments/an33mo/aspnet_...](https://www.reddit.com/r/programming/comments/an33mo/aspnet_core_saturating_10gbe_at_7_million_rps/efrvn0e/)

There are plenty of articles comparing Rust and Go. Easy to find.

When it comes to Go itself, You have both those pros listed in this article
and repeated everywhere, and these cons listed in Reddit and again repeated
everywhere. In my opinion cons will weight more and becomes annoying when you
are working on a large projects/code-base, Otherwise for smaller projects you
don't notice them much and performance and goroutines are the main reasons for
MOST not ALL projects choosing Go over Python or Ruby in that scale.

~~~
apta
I find it ironic that golang was supposedly created for "large scale"
programming, but nothing really in the language supports that notion (no
dependency management, import system sucks, verbose error handling, and so
on). I just see the claim without anything to back it up.

~~~
dragonwriter
I'm pretty sure “large scale” was meant specifically in the sense of a single
shop with a gigantic code base in a monorepo.

Or, more directly, it means “Google”.

~~~
apta
Yes, that's what I meant, and it does a bad job at it (the examples I gave).
Java/C#/Kotlin/etc. are strictly superior when it comes to managing large code
bases.

I think what they had in mind is just quick compilation times, even at the
expense of convenience, safety, terseness, etc.

------
apta
Nothing new here. Same reiteration you'd expect from someone coming from
Javascript/Python/etc.

Nothing that Java, C#, etc. wouldn't give you (other than hype based
development perhaps).

------
RickJWagner
Also, Go makes for _tiny_ containers. Very important these days.

~~~
covermydonkey
Not only tiny on disk (startup time, pulling etc) but also tiny memory
footprint. I'm comparing to a Java Spring app and Golang is absurdly light on
memory.

~~~
apta
[http://august.nagro.us/small-java.html](http://august.nagro.us/small-
java.html)

------
SkidanovAlex
If anyone used both rust and go, are there any big advantages of go over rust
(besides simplicity)?

~~~
lerax
OP here, I used in the past Go (2015~2016) and Rust (2017~2018) at few years
ago, my experience in favor of Go was:

\+ Faster compilation time (really more faster!)

\+ Concurrency model embedded in the language as built-in features

\+ Language stability

My main job in Go was done in the Google project u-root:
[https://review.gerrithub.io/q/owner:manoel_vilela%2540engine...](https://review.gerrithub.io/q/owner:manoel_vilela%2540engineer.com)

My experience with Rust was just toy projects like this:

\+ [https://github.com/ryukinix/conway-rs](https://github.com/ryukinix/conway-
rs)

\+ [https://github.com/ryukinix/xim](https://github.com/ryukinix/xim) (small
contrib & design)

