
Go 2018 Survey Results - wardn
https://blog.golang.org/survey2018-results
======
ilovecaching
Go and Rust are actually a great combo with only a little overlap. What’s
great is that they are both C family and have some shared principles and flow.

When you need a decent concurrency story, moderate speed, and have a problem
that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby,
JavaScript, and smaller Java projects.

Rust is better if you need maximum performance, are building a large project
where more abstraction where parametric polymorphism can help, or need thread
safety. It’s a replacement for larger Java projects, C++, and C.

Generally I write more Go projects, but my Rust projects tend to be bigger and
are doing very complex things like user space networking or wringing maximum
performance out of a kernel subsystem or running in a very low resource
environment.

Both languages have made my teams enjoy their work more. We also have
empirically measured a decrease in time spent fixing bugs and other production
issues, as well as reduced resource consumption (mostly from getting rid of
Python for Go) and snappier cli tools that are saving us $$$$$$ in terms of
time and hardware). Both languages are built for modern problems and getting
stuff done.

Also Go and Rust position us to hit Wasm hard. I can’t understate how
important Wasm support is and how both of these languages are already miles
ahead of the competition. This is containers right before Docker. Your company
should be pivoting or have a strategy to get on deck with these languages.

~~~
rlander
> Your company should be pivoting or have a strategy to get on deck with these
> languages.

That’s a bold blanket statement. Besides the fact that I would die inside a
little if I had to use Go every day of my life, Go is in no position to
replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone
all of them, not by a mile.

~~~
ilovecaching
Not C++, but definitely the other languages outside of some non standard SWE
domains like ML, where Python is going to be an obvious winner. Otherwise Go
beats them by having a type system but still supporting duck typing through
interfaces, having a modern concurrency story, being easier to learn (the Go
spec can be read in one evening), having less features to abuse, faster
development loops with lightning fast compile times and catching more errors
at compile time, and just generally being faster and having a garbage
collector that is tuned for low latency (a good fit for web services). We can
also start faster which is really important for container workloads, idle with
less memory which is important for horizontal scaling, and use less CPU which
means smaller machines and more colo.

Go also favors libraries over frameworks and is super thoughtful about using
too many untested dependancies which means we don’t get stuck in frameworks
that become legacy (rails) or use stuff that has security holes or that will
change out from under us (npm).

~~~
treis
>Go also favors libraries over frameworks and is super thoughtful about using
too many untested dependancies which means we don’t get stuck in frameworks
that become legacy (rails)

The Go standard library doesn't come close to replicating the functionality of
Rails, let alone the gem ecosystem of Ruby/Rails. If you don't need it, great!
Otherwise, you're spending time re-implementing what already exists and
probably doing a worse job of it.

~~~
ilovecaching
> The Go standard library doesn't come close to replicating the functionality
> of Rails

Why would it? It's the standard library. Go has a massive ecosystem of third
parties libraries, and unlike Ruby, which was a one trick pony, Go has
libraries for pretty much anything you could want to do. It's exceedingly
versatile and it has _better_ integration into modern infra. Why? Because it's
all written in Go. Prometheus, Kubernetes, etcd, terraform, docker, caddy,
fleet, influxDB, synthing, coachroachDB, gogs, mino... all written in Go. Go
is cloud first, and has first class support for multicloud abstractions
written by the go team. It's got great support for rpc through grpc and
protocol buffers both of which are much easier to use in a statically compiled
C like language that resembled the protocol buffers primitives.

Rails literally offers nothing you can't get from Go, and it doesn't make you
pay for the stuff you aren't using. With Go you don't write in a DSL based on
the language, you just write regular Go code. You aren't a rails developer,
you're a Go developer.

~~~
aprdm
Err, both Python and Ruby have a much bigger ecosystem than Go. Not only that
but you're speaking as if Python or Ruby were usually used in the context of
building infrastructure-level services (k8s, dbs, consul, docker, etc.)
instead of business logic / applications kind of services ( gitlab, shopify,
your usual startup CRUD).

Why would you even compare both? You wouldn't want to create gitlab V1 with Go
just like you wouldn't want to write Kubernetes in Ruby.

~~~
Zancarius
> You wouldn't want to create gitlab V1 with Go

Does Gitea[1] count (fork of Gogs)?

I understand your point (I love Python, too), but I can't help finding some
amusement in it since it _has_ been done. :)

[1] [https://github.com/go-gitea/gitea](https://github.com/go-gitea/gitea)

------
Insanity
Moving to Go at work has made me incredibly happy. It really is a fun language
and I tend to use it for my side-projects as well

Coming from Java, I find that I don't miss generics and exceptions as much
anymore as I thought I would :)

------
zeroxfe
I'm a big fan of both Go and Rust, and it's really interesting to see Rust
ranked #3 in preference but #17 in expertise.

Rust is not a simple language by any means -- it's a great replacement for
C++, but I'd be pretty surprised if it displaced the popular general purpose
languages (which Go has actually managed to do.)

~~~
pjmlp
Go has not displaced anything around here.

Still plain old Java, .NET and C++ as always.

~~~
vardump
Where I'm located, .NET has died years ago. Just Java, Go and C++ now. I guess
these things are regional.

Unity is increasing C# popularity, though. So maybe .NET is not going away, at
least yet.

~~~
raxxorrax
Same here... .net core is around but the APIs and runtimes MS created aren't
really loved by anyone. With WPF seemingly abandoned and UWP being ... itself,
there isn't much enthusiasm left. A little sad, since I believe C# to be
superior to JAVA, but I haven't used it for anything for about two years now.

It maybe won't go away, but I think it lost a lot of relevance.

~~~
pjmlp
WPF is one of the corner stones of .NET Core 3.0, and one of the UI frameworks
mostly used in life sciences device management UIs.

UWP isn't going anywhere, as much as haters would like to.

~~~
raxxorrax
Maybe not. But users might go somewhere else. I have yet to meet anyone in
real life that developed anything with UWP because it allegedly (has been a
while) still lacks very basic features relating to UI at least (i know it is
not restricted to that). I have nothing against WPF, although I am not a fan
of XAML. But I think MS isn't really focusing on it. We will see.

I used WPF in medical applications like you said, but that was around 4-5
years ago.

Currently I believe UWP will never significantly take off on the desktop
outside of Microsoft.

~~~
pjmlp
Yeah, I guess Adobe, startups creating HoloLens content, might be told
otherwise then.

------
leshow
I'm not surprised that the official Go survey showed: "..Go is the top
language they'd prefer to use..."

It doesn't really say much given the selection bias.

~~~
ntnn
The question on its own is useless given the audience - yes. However if you
combine that question with the - e.g. - primary field a person works in it
gets interesting.

Say a person said they're mostly writing finance software and Go isn't a
language they'd prefer to use for their next project. Those two data points on
their own also don't tell much - but if multiple people answer with that
combination the Go team knows that they aren't covering the needs of the
finance sector appropriately. With that knowledge they can e.g. request more
information from those people and start working to fix those issues.

~~~
mynegation
As a person who is mostly writing finance software I can tell that Go is not
very well suited for any kind of rich application domain (which finance
definitely is). OOP and Java + C# in particular have a very strong hold in
finance. We can argue whether composition is an adequate substitute for
inheritance, but the lack of generics is pretty much a non-starter.

Go works very well in domains with a well-defined and limited set of entities.

~~~
chessturk
Sincere questions, I don't come from a OOP background, and do have plenty of
Go! experience, so I feel like I'm missing the nuance of this post.

What causes OOP to be well suited for finance's use case?

What are the short-comings of structs/interface methods that Go! provides in
the financial space?

If Go! had generics, would that change it's suitability for finance?

I would think that first-class concurrency would be useful in that space, is
it?

~~~
mynegation
> What causes OOP to be well suited for finance's use case? What are the
> short-comings of structs/interface methods that Go! provides in the
> financial space?

“Things” in finance are amenable to the classical PIE of OOP. Many concepts,
e.g. financial instruments are extended version of something that was invented
earlier. E.g. you have an abstract concept of an interest rate swap and
specific versions of it (like fixed-fixed, foxes floating, cross-currency
etc). This works pretty well with inheritance and polymorphism.

When you talk about money, finance is very particular about what you can do
and what you cannot do. E.g. if money are subtracted from one account, they
should appear in another, or balance cannot go negative. It is easier to
enforce rules like that on a language level with encapsulation.

> If Go! had generics, would that change it's suitability for finance?

I believe so. You have built in “generics” for most popular collections like
maps and arrays, which is fine for command like utilities and lots of system-
level software. But in finance (an other problem domains tbh) you often need a
generic version of a more complicated data structure, e.g. dataframe, tree,
implementation of flyweight pattern, or data cube.

> I would think that first-class concurrency would be useful in that space, is
> it?

Good support of first class concurrency is useful everywhere. Just so it
happened that given that C++, Java, and C# together reign in different domains
of finance, we are already quite comfortable with concurrency primitives of
these languages (usually some kind of multithreading)

~~~
imetatroll
You can define methods on structs which is not unlike classes.

You can define an interface with methods that allow objects to be processed in
a more generic fashion.

I think that more than anything it would require a change of mindset that
people understandably don't want to deal with.

~~~
alexkavon
There's also always a package to handle that issue. [0][1][2]

As well as other options. [3]

I like to imagine that the "no generics, no way" crowd would never use the
stairway in their building if the elevator broke down.

[0] [https://github.com/clipperhouse/gen](https://github.com/clipperhouse/gen)
[1] [https://github.com/cheekybits/genny](https://github.com/cheekybits/genny)
[2] [https://github.com/cosmos72/gomacro](https://github.com/cosmos72/gomacro)
[3] [https://appliedgo.net/generics/](https://appliedgo.net/generics/)

~~~
pjmlp
Ah, but the generics building was conceived with an elevator to start with,
and it will eventually be repaired.

Go's building architects decided an elevator was superfluous, as everyone
should walk 20 stores high every single day, it is good for their health.

~~~
alexkavon
More like Go’s building comes building-agnostic, whether you have 20 stories
or not. Anything you need (such as a generic elevator) can be added on. No
need to walk 20 stories every day because you can just add what you need in
through reusable packages.

~~~
pjmlp
Actually no, because in the end it will look like an Escher building.

------
alexkavon
> VS Code and GoLand are surging in popularity and are now the most popular
> code editors among survey respondents.

I wish the package situation for Go was better for SublimeText. Currently most
of the worthwhile golang packages that add vet, goimports, fmt, etc support
are either abandoned or buggy. Margo bailed on using Package Control so it's
difficult to install, not to mention buggy.

I've used VSCode for a while but it chokes sometimes and you can't beat the
speed, ease, and power of SublimeText.

~~~
frou_dh
At the end of last year, a great systematic rewrite of Sublime's Go grammar
was merged. So at that (admittedly surface-) level, it's doing very well.

I just maintain my own on-save hooks, build systems and plugins to integrate
various quality-of-life Go tools. With the benefit of being able to tailor any
such functionality to exactly the way you like to work and nothing more, it's
far less effort than it would be to create the all-singing-all-dancing
comprehensive package that is absent.

~~~
alexkavon
Agreed, this is actually on my todos, just haven't executed yet.

------
qlk1123
Off topic but it's quite interesting to see that on HN, a great amount of the
comments of a GO post talk about Rust, and vice versa.

As a system guy, I am also happy to follow two OS projects in these two:

[1] [https://github.com/mit-pdos/biscuit](https://github.com/mit-pdos/biscuit)
[2] [https://github.com/redox-os/redox](https://github.com/redox-os/redox)

~~~
pyrale
Probably because these two communities are the most involved in flinging
propaganda about their language. Of course, sometimes their courses collide.

------
Groxx
I'd be particularly interested in seeing a low-expertise / high-expertise
comparison on satisfaction / desired improvements. It takes a while to learn
(in every language) what's going to bite you and how to deal with it / how
well it works.

------
ousta
unrelated but the charts are very nice what lib is used to render those?

~~~
saagarjha
Given the mix of Arial and Roboto as well as the style, I think they used
Google Sheets.

~~~
minxomat
Or Google Data Studio.

