
Six years of Go - jaxondu
http://blog.golang.org/6years
======
matthewmacleod
I have a bit of a love-hate relationship going on with Go.

On one hand, it addresses many of the pain points I've experienced with other
languages. It's easy to build and deploy, reasonably performant, and has a
powerful and consistent standard library.

On the other… developing in it feels like a total slog. It manages to be
simultaneously far too anal and overly forgiving about syntax. Visibility
definition using upper/lowercase is a shite idea. Package names (and packaging
generally) are a mess. Magical built-in globals are a huge design smell. The
lack of generics, as cliché a complaint as it is, results in loads of
duplicated or generated code when building anything more complex than the
simplest app. And so on.

I find the whole experience of using it to be unpleasant (rather like using a
blunt knife), and yet it fits a set of requirements that mean I keep
developing new projects using it – particularly high-performance small
services that do things like fling JSON around, for which the built-in HTTP
libraries + Gin are brilliant.

I'm looking forward to the point that a (trans|com)piler which smooths over
the bad parts is available.

~~~
lobster_johnson
I'm in the same boat. Go's simplicity is initially refreshing, then a huge
pain once you find yourself writing the same thing over and over again.

A good example is errors being values — which is a great idea. But then you
realize every single function needs to be littered 1-10 cases of

    
    
      if err != nil {
        return nil, err
      }
    

It's an _extremely_ common pattern. It's tiring to write, over and over.
Tiring to refactor, too: If you change a signature (to add an error, or add
another return value, for example), every error check has to be updated.

Unfortunately, Go doesn't offer any abstractions that might allow you to avoid
such boilerplate. Functions that return errors cannot ever be chained, for
example: If you have "func bar() (MyStruct, error)", you cannot do
"foo(bar())". You must always assign the result to an intermediate variable.
You could embed the error in the MyStruct struct instead, but that goes
against Go's grain.

I find myself wishing for some magic macro that is smart enough to extract a
value and return the error for me. Something like:

    
    
      try! value, err := bar()
    

...would expand to:

    
    
      value, err := bar()
      if err != nil {
        return
      }
    

I'm with you on upper/lower-case names. It results in schizophrenic-looking
programs. Unless I'm writing a library, I tend to just export anything that
isn't obviously an internal implementation detail, for consistency.

I'm also up in arms about ":=" assignment behaviour. I've run into several
bugs caused by shadowing inside blocks. You have to be careful when
refactoring so as not to cause shadowing issues; really, editors should have
their syntax highlighting set to highlight ":=" in blinking bright yellow or
something. It's so hard to miss.

It's also inconsistent with how you (or, at least, I) _want_ it to behave. It
will shadow existing variables by default if there is at least one new
variable on the left-hand side, but that's the _least_ conservative behaviour,
and feels contrary to Go's strictness — a language, after all, that considers
unused imports to be a compilation error. Recently I've started avoiding ":="
in favour of vars, just to avoid falling into that trap by accident.

To be fair, I love many aspects of Go: Compilation speed, relative
performance, ease of concurrency, static strictness. But after working with Go
for a while and being quite productive with it, I'm at the same time seriously
pining for a better language to replace it.

~~~
jonesb6
If there a paradigm for handling multiple potential errors in a function?

I'm usually stuck using:

    
    
      reply, err := redis.Givemethevalue(key)
    
      if err != nil {
        return err
      }
    
      thing, err2 := postgres.getById(reply)
    
      if err2 != nil {
        return err2
      }

~~~
forgotAgain
I use

    
    
      var err error
    

at the beginning of the function if needed.

~~~
jgome
This helps prevent variable shadowing when using :=, which is yet another
weird feature of the language...

BTW, if you really want to make sure you don't make mistakes, use the compiler
tools, or, better yet,
[https://github.com/alecthomas/gometalinter](https://github.com/alecthomas/gometalinter)
.

------
aws_ls
It was early 2013, when we adopted Go as a default language for all our server
side (micro or not) services. Before that we had been using Java for some
years. The reason for the move were few:

1) Ambivalence on Java roadmap, in my understanding (gradual build up, since
after the Oracle's Sun acquisition). Even the earlier clean java docs,
suffered from Oracle branding efforts. Downloading older versions were
confusing via a long chain of navigation between sites.

2) Boredom after nearly a decade with Java programming.

3) Memory usage of Java in our conditions was much higher compared to other
languages (C, C++, Go)

4) Not Java's problem, but whenever one thinks of hosting a HTTP service in
Java, thinks of using a container (e.g. tomcat, jetty, Jboss etc.). Go
_seemed_ to have made making services very easy. Its possibly just a
perception issue, but its there in my experience.

So we wanted to move, and Go looked stable at the time from all my HN
readings. C was too bare bones(even string handling was a pain to me, after a
gap), and even C++ would not have matched some of the things which Go has
inbuilt. Few examples:

1) Json/XML parsing is the easiest with no work (or minimal) required, you can
just have the field names capitalized (or use stereotypes) and it gets done,
with a line of code.

2) Great HTTP client and server libraries, which make very easy to write your
own standalone services, as well as write http crawlers. (I am quite excited
that Go 1.6 will have HTTP/2 support for both, as per this birthday blog).

So, in nearly three years of usage, with largely no regrets[1]. It is what
they say it is: a bare-bones, fast (both compile & run) and stable (hardly get
any errors after you have coded stuff, one of the stablest programming
paradigms in error handling, etc).

Thank you, Go team! Hoping to use it for many years, as default server side
language.

[1] Some of the 3rd partly libraries, we use are still not ported over to Go.
They have Java, C++/C versions.

~~~
coldtea
> _It was early 2013, when we adopted Go as a default language for all our
> server side (micro or not) services. (...) The reason for the move were few:
> 1) Ambivalence on Java roadmap_

So, because there was some "ambivalence for the Java roadmap", a language with
multiple implementations, a huge community (including open source), and so
entrenched in the industry that will be there in 2100 too, you switched to a
3-4 year old language with tiny adoption compared to it (outside of echo
chambers), an arbitrary roadmap as set by the core team which might involve
anything coming the time for a 2.0 release, and whose majority of development
depends on a handful of people Google pays their salaries?

~~~
drumdance
Ha. I built my first company on Java back in 1996. It was a terrible decision.
Very buggy, lots of BS from Sun & Oracle that was really more about Ellison
and McNealy envying Bill Gates. Netscape made a similarly bad decision when
they tried to create a pure Java version of the browser.

I'm sure Java is 10x better now, but I'm not convinced it will be here in
2100.

~~~
bdamm
It will be, because there is now more Java running business processes than
there is Cobol, and Cobol is surprisingly still with us.

Profitable code dies hard.

~~~
drumdance
I don't think there's any 85 year old Cobol though. Most of the S&P 500 is
less than 50. It's entirely conceivable the companies that embrace new
technologies starting today will, within 50 years, extinguish or acquire most
of the of the companies using technologies from 1995.

------
codygman
I wish the gdb support were better or that delve were more stable. I also had
some weirdnesses using cgo on osx. Then I went into #go-nuts on freenode, and
I got told I was wrong and there was no problem.

Back in 2009 #go-nuts seemed to be a much different place.

I write Go at work, and I admire many of the same things in Go I admire about
Python.

I still wish generics were part of the language and will say their excuses
about not being able to do it in a performant way seem to just be away of
avoiding the subject.

Ocaml for instance, has a performant generics implementation.

Sometimes the Go community can have an anti-programming language research and
anti-intellectual feeling which can be annoying, since in addition to Go I
write a good amount of Haskell.

The tooling is nice as people say, however I think more maturing of the
platform needs to be done. It's also never talked about how much slower Go's
claim to fame of fast compilation got much slower after the 1.3-1.4 switch to
a compiler totally in Go. In all fairness, I could be wrong about the last one
since I haven't benchmarked it... but I can say it feels much slower than it
was around 1.1/1.2.

Concurrency in Go is easy, however I feel like many erroneously think that
channels or concurrency primitives like it only exist in Go. There are other
languages with rich concurrency and parallelism options as well.

Using lots of interfaces and casting everywhere gets on my nerves since I like
to have the strongest guarantees possible via static typing.

Overall though, I can't say I've had a bad experience with Go. I can say it
feels like I'm using an okay tool (great in some places) with maintainers who
put their hands over their ears to potential improvements (see the generics
proposals over the years).

~~~
tptacek
I've been yelled at on #go-nuts too; I ran into what turned out to be an
authentic limitation of Go's I/O scheduling, and was instead chided for _'ing
out error results in my minimized example code.

~~~
placeybordeaux
Yeah I have been bitten by the _'ing errors thing in the go community.

~~~
fixermark
Given other aspects of Go's design, I'm actually a little surprised that Go
makes it as easy to drop errors on the floor as it does. It feels like the
language's strict checking of unneeded or missing imports and its lack of
checking for capture of return values are philosophically at odds.

~~~
rdtsc
If compiler did it, how else would they get to chide people in people on bad
style ;-)

But yes, good point. I think a better type system should handle it and make it
harder to drop errors on the floor. But that kind of asks for Rust's like sum-
type which is too close to generics for their comfort.

------
japhyr
I've never used Go before, so I went to the project's home page. There's an
editing window on the home page with a sample program showing, and a few other
programs available in a drop down list. I couldn't help but start playing with
the language.

I wonder how much the simple presence of an editing window on a language's
home page contributes to overall adoption of the language. It sure lowers the
bar to "I'll just write a few lines of code and see how this language feels."

~~~
ionforce
Does anyone know how it works? Like does it make requests to a service or is
it running in the browser, JS style?

~~~
japhyr
There's a section called A Tour of Go [0] which has a series of code samples
with explanations. The last part of the introduction to the tour says a little
about what they call the Go playground [1]:

"This tour is built atop the Go Playground, a web service that runs on
golang.org's servers.

The service receives a Go program, compiles, links, and runs the program
inside a sandbox, then returns the output."

[0] - [https://tour.golang.org/welcome/1](https://tour.golang.org/welcome/1)
[1] - [https://tour.golang.org/welcome/4](https://tour.golang.org/welcome/4)

------
no1youknowz
I've been working on a huge monolithic project (for 1 person) for the better
part of 2 years now. It is in PHP, but the backend segments ported over to
various other languages like python, javascript(nodejs), and now to Go.

Having now developed 30 micro-services for Go, which all utilise channels and
thus run much faster than any other language I used is just amazing.

Not only has my productivity increased majorly, but also my support time has
rapidly decreased.

These micro-services which run in the background just work:

\- With PHP they don't run out of memory or the database connection doesn't
time out.

\- With Python I don't get random crashes due to pool.map.

\- With NodeJS I don't have to run multiple instances to get the speed.

I've looked at web frameworks like beego, gin, revel and others. But I'm
waiting till something comes out that's more inline with what I have used with
PHP. Something like slim framework.

If it ever does come out, it will give me the push to switch 100% to Go. Can't
wait really.

~~~
placeybordeaux
I tried gin, martini and revel and found myself reaching to go back to largely
the stdlib after about 6 months of development.

The stdlib with a couple convience functions really is quite good.

~~~
elcct
Me too. I found that most frameworks actually get in a way instead of helping.
stdlib FTW

------
domrdy
I love Go. It helped me so much, not only career wise but also on a more
personal level, bringing back the excitement in programming I missed so dearly
from my early days. Drop by at one of our Golang meetups if you're in the
Munich area. [http://www.meetup.com/Munich-Gophers-Go-User-
Group/](http://www.meetup.com/Munich-Gophers-Go-User-Group/)

------
Sphax
Congrats to the team. Go has never let me down in my work and my personal
projects, it's just awesome.

------
kriro
Go seems like a fun language that has been sitting on my "look into it list"
for a while, can't belive it's already six years old.

Since the TensorFlow video post is currently on the frontpage as well...as
someone who uses neither C++ nor Go (I can write FizzBuzz level of code in
both and read both well enough to get what's going on) I have to wonder how
much internal buyin Go really has at Google if the core of such a project is
implemented in C++. It's a project they see as valuable in the future and it
would lend itself really well to Go as these calculations are done distributed
and yet they picked C++.

[I'm not sure how much of the old framework they reused but if the will to Go
was really strong I'm sure that wouldn't have been an issue]

~~~
tptacek
Go is a language designed by Google people, but it is very much not the
standard Google language. _Most_ things Google does aren't done in Go.

~~~
jgrahamc
Having said that Rob Pike told me that Go is now one of Google's "official
languages".

~~~
tptacek
... which just means developers at Go now have permission to use it, along
with Python, Java, and C++, to build things, right?

~~~
jgrahamc
I believe so.

------
kitd
Go is a great language. Building REST servers in Go is a doddle and the
related tools have obviously been designed to work well together from the
outset which is unusual.

That said, I started learning D at about the same time as Go, and for some
reason D has attracted me more. Possibly the C ABI compliance (I was doing
some JNI work at the time).

One question that I haven't found the answer to yet though is how well Go apps
perform for long running processes, eg weeks or months? Have there been any
issues around memory usage or resource handling? Any need for restarts?

~~~
pdappollonio
Go websites are essentially long running processes. I have several websites
built in Go, all of them running for about 2 months already with no hiccups.

~~~
spotman
I can echo this. Have some go processes that have currently been running for
over 6 months.

------
kris-s
I picked up the new Go book (gopl.io) and have had a lot of fun going through
it. The prevailing feeling of Go is "getting things done".

I also write a little Go program every day as practice. If you want a sample
of some Go. [https://github.com/kris-s/daily-
go](https://github.com/kris-s/daily-go)

~~~
kasey_junk
> The prevailing feeling of Go is "getting things done".

This is a common refrain amongst go proponents and I find it quite
distasteful. It either implies those of us who prefer other languages aren't
"getting things done" or those who feel productive in Go aren't smart/hard-
working/educated/etc enough to "get things done" in other languages. I don't
think either is true.

I think a more accurate way to look at Go is that the language, tools, and
standard library make decent design trade-offs when your target software is 1)
simple 2) network daemon-y or a CLI and 3) going to be worked on by a wide
variety of developers. There are lots of problems that fall into that problem
set, and it is very nice to have a language targeted at it, but Go is
certainly not a good fit for a huge number of software projects. You will be
less productive in those cases using it.

~~~
woah
It's true though. Go has a small number of language features, and they are
only the simplest ones. It can be learned in a day. Other languages like JS,
Ruby, and Python have a big fixation on figuring out the prettiest syntax for
stuff (JS promises and chaining etc, "Pythonicness", and Ruby's incessant
cuteness). In Go, you can't really make things pretty, so you just bang out
code.

~~~
aryehof
>> It can be learned in a day.

The syntax perhaps. In reality there are a large number of concepts and idioms
to learn on the never-ending road to really becoming proficient.

~~~
Niten
Yes, but there's a kernel of truth there. I wouldn't say I managed to learn Go
in a day, but after perhaps six months using it I was much closer to mastering
Go than to mastering other languages I'd been using for years. Go's road to
proficiency is a shorter one, there's just less stuff to cover.

Take initialization for example: look at all the edge cases belabored in
section 8.5 of the C++14 spec, or even the intricacies of initialization in a
simpler language like Python. Now contrast this with how much lexical and
conceptual space it takes to describe zero initialization in Go's spec:
[https://golang.org/ref/spec#The_zero_value](https://golang.org/ref/spec#The_zero_value)

As in other areas, Go's approach here has downsides. (Possibly major ones.)
But those tend to be conscious design decisions to minimize the total number
of concepts and idioms present in the language.

------
fixermark
I recently implemented a RESTful resource mapper in go, which just accepts
some basic parameters and an exemplar of a storable structure and wires up all
the HTTP endpoints necessary to give users CRUD access to the resource.

I'm honestly very happy with how straightforward it was, even lacking generics
---I solved the problem of no generics by basing the resource creation and
management on JSON and a "Storable" interface that just defines key() and
newEmpty() methods (so I have to write five lines of boilerplate for every
struct that will be a resource... _shrug_ ). I didn't parameterize the storage
logic, basing it on only a single NoSQL backend (BoltDB); however,
parameterizing that side shouldn't be harder than wrapping the database access
behind another interface.

I like the ability to switch between tight static typechecking and freer
runtime typechecking on-the-fly, without having to build a large, complicated
framework for either within the language. It may not be the most innovative
language of the decade, but I think it's a pretty good combination of features
for practical, high-performance web server development.

~~~
jstoiko
Would you care to share some code example?

~~~
fixermark
Happy to; I'll share the whole thing.

[http://pastebin.com/qBh6NRXc](http://pastebin.com/qBh6NRXc)

It's not cleaned up for easy reading (hell, I haven't even run `go fmt` on it
;) ). But it has unit tests and seems to work. ;)

One thing worth noting is that it relies on the Storables to also be tagged
with necessary JSON. It occurs to me that I could also have used tags instead
of the key() function in the interface to specify which field in the Storable
should be the resource name; key() is a bit more flexible in that the function
could calculate the name using any method though.

~~~
TheDong
Just for you, I did a code review. The code review has two revisions, one
where I gofmt'd it because I can't read non-go-fmt'd code anymore, and a
second where I added comments expressing some concerns. I'll be honest, I gave
up on a few bits just because it wasn't fun to do; I strongly suggest
rethinking the use of a storable interface vs taking an 'interface{}' value
for both gets and puts akin to how the json stdlib does it.

You can see the comments here:
[https://gist.github.com/TheDong/ce1d7b86b88c86d972b6/revisio...](https://gist.github.com/TheDong/ce1d7b86b88c86d972b6/revisions?diff=split)

You should never post code without a copyright license or disclaimer attached
and I'd appreciate if you rectified that forthwith.

~~~
fixermark
Thanks for the review! I appreciate the feedback. One key piece that might
have been unclear: since this code is part of a larger module (note package
main), some of its parts live elsewhere. If I were to publish this, I'd
consolidate those parts and build some proper module isolation here. OnStore
is there purely because one of my resources needs to notify another part of
the program that it has been stored; if I ever clean this up for public
consumption, I'd probably want to add both pre- and post-handler hooks (along
with the ability to add more rules and change the defaults, as Angular's
$resource gives the client).

The advantage to the Storable is that other parts of the program can create
and store those resources without needing knowledge of how keys are
constructed. I also can't think of a way to do what empty() does without
making it an interface function; "I need another copy of this unknown
interface type" isn't something go has a clear solution for. Hypothetically, I
could make empty() into a function that returns interface{}, take the key()
suggestions you've given (though that leaks key-making knowledge), and then
the whole thing would operate on interface{} type... Doable and more flexible,
but not quite as clear on what resource will actually be stored and retrieved.
Good tradeoffs.

A bit of feedback on feedback: avoid adjectives like "dumb" and "stupid." The
signal-to-noise ratio is too low on them, and it makes for a harsher community
(as other commenters in this topic have mentioned on their experiences trying
to get help).

------
GrandTheftR
Thanks you, Go team!

Have been using Go for the last few years, from backend, tools, and even
complex scripting type of tasks (for things more than I would like to do in
Bash). Start using Go for game development as sideline projects recently, it
is fun.

Granted there are things I would like to see may not on the road map, but I am
very happy with what we have now, the great tools, and the great community.

Keep up good work and looking forward to the future releases!

------
johnydepp
I tried Goland for two of my personal projects. Initially I thought I will get
used to the new syntax, but it never happened. It may have certain
performance-edge over other languages but I wouldn't call it a modern
language. I find coding in C more fun than Golang..

~~~
hahainternet
I picked up Go because C frustrated me so much. Can you give some examples as
to why you prefer C?

~~~
agentultra
Not the author...

I prefer C99. A smattering of features I like:

    
    
      * Variable Length Arrays
      * Variadic Macros
      * Designated Initializers
      * Anonymous Structs
      * Compound Literals
    

Some of the meta-"features" I like:

    
    
      * No built-in runtime or GC
      * A choice of dynamic vs static compilation
      * A good libc is wonderful but not necessary to get work done fast
      * The tooling is mature and plentiful
    

I'm sure Go is a fine language. I probably suffer from some sort of first-
language bias as I've been using C for a long time and only know a smattering
of Go from toy programs, blog posts, and reading the source to interesting
projects like CockroachDB.

~~~
voidlogic
I just want to point out:

1\. Variable Length Arrays: Go has slices 2\. Anonymous Structs: Go has these
3\. No built-in runtime (in C): This is not true unless you are compiling
-ffreestanding -nostdlib, etc. I have done this in C, but such programs have
to call system-calls directly and provide their own malloc, etc.

~~~
agentultra
Not for every project but it does have it's uses (re: -ffreestanding
-nostdlib, etc)

------
dejawu
Started using Go for my latest project (a successor to Evernote). It feels
like such a relief, especially having just come out of a node.js project. It's
everything I wanted in a (web-app) programming language, and for the first
time I can say that a language has actually made my code better. I've never
had a codebase this clean before.

~~~
cubano
I don't mean to be snarky and I'm definitely showing my age here, but isn't
that exactly what devs were saying about node.js two years ago?

~~~
zaphar
I can't remember anyone ever claiming javascript/node made their code cleaner.
Speed and throughput were claims but not code quality.

~~~
dilap
I've been coding since forevs, and I really do feel like Go pushes you to keep
clean code. Maybe the language, but a lot of it's just culture and leading by
example.

Every time I peak into the source of a standard Go package, I'm blown away by
how clean and simple the code is -- and it's a fantastic way to gain a deeper
understanding of the language.

That has mostly not been my experience diving into std C library code, or
quasi-standard stuff like boost...

------
lsllc
I've used Golang extensively for a few years now anywhere from ARM/Linux to
x64/cloud based containers (and I admit, occasionally on Windows!). It's
really a great platform, very robust and has an excellent ecosystem. I can't
recommend it more highly.

------
jinst8gmi
I find it curious that virtually any negative or critical comments about Go
get downvoted.

~~~
penetrarthur
Because you don't insult someone when it's his birthday!

~~~
lobster_johnson
On the other hand, honouring people by roasting [1] them is also tradition.
Maybe if the criticisms were funnier.

[1]
[https://en.wikipedia.org/wiki/Roast_(comedy)](https://en.wikipedia.org/wiki/Roast_\(comedy\))

------
benreic
I'm surprised to not see any mention in the comments about the biggest change
coming in 1.6: the package vendoring mechanism. This has been a big missing
piece for awhile and I'm glad they're addressing it in an official way.

I was super excited for the cross compilation abilities on Go 1.5 and now I
have something else to be super excited for in Go 1.6, can't wait!

~~~
dilap
I was confused by that. Is this going to be any different than
GO15VENDOREXPERIMENT which we have now?

~~~
benreic
I guess I was hoping for a composer-like versioning system, but I suppose
that's not a given?

~~~
dilap
It would be a surprise to me, but we'll see. I haven't seen much discussion
since the vendor experiment, weirdly. (But I haven't been looking, either.)

------
acomjean
I've started working in Bioinformatics. The languages in use and libraries
seem to by Perl/Python and some java. Except for the stuff that needs to be
fast, then its C. Although I notice some movement to use Rust instead of C
(having installed some C based tools having package management would be
glorious).

It would seem the concurency model of go would be a great fit for a lot of
those existing python/perl tools. My searchingg for projects show it hasn't
really taken off in this domain. I might start rolling my own packages.

How is the package management in Go? Data structures and String manipulation?
And is does that concurency scale across nodes (al la MPI)?

~~~
biomcgary
I'm a computational biologist that recently ported our webserver
(genestation.org) from Tripal (PHP/Drupal) to Go. The performance gains were
huge, but the simplicity of development and deployment was even better. I'd
strongly recommend Go for a biology web server. However, Biogo is not remotely
as far along as Biopython or Bioperl. Also, Perl beats Go for ease of string
handling. Unfortunately, there is no equivalent to Numpy/Scipy in Go. Despite
these areas of weakness in the ecosystem, I have switched to Go entirely
except for one-liners and one-off parsing in Perl.

~~~
acomjean
Thanks. They new site is snappy.

Tripal I had never heard of. It uses "Chado" db schema which I have heard of
(though flybase) which while flexible isn't always performant.

Performance gains and simplified development are so appealing (I have 12 tools
to maintain in Java/perl/php)..

Biogo is what I was looking for.
[https://github.com/biogo/biogo](https://github.com/biogo/biogo)

~~~
howeman
You said above you 'may start rolling your own packages'. If you're interested
in helping develop the numeric ecosystem, please come join us at gonum
[https://groups.google.com/forum/#!forum/gonum-
dev](https://groups.google.com/forum/#!forum/gonum-dev) github.com/gonum.

Dan (the lead developer of biogo) is very competent and I'm sure would love
bug reports and PRs in biogo as well.

------
ogezi
Golang and I have had a mainly wonderful relationship. I think that the
performance and concurrency features that it brings to the table are
unparalleled. No that Golang is just 6 years old and probably has a few more
decades of relevance. Although they need to do something about the compilers
as the compiled binaries get more bloated with each release.

------
elcct
I have written tons of services in Go. What I love about it is stability.
Services written in Go are rock solid.

------
jonesb6
I've used Go for a couple years but am only just writing my first production
system in Go. I think one of the major complaints is that it's use-cases are
ambiguous to beginners. Go, IMO, is a systems language and should not be the
first thing you pull out when someone says "write a web app".

I think Go has a very limited use case, but it is incredibly good for that use
case. If I had to define it right now it would be along the lines of "Highly
concurrent micro-services (re: small code bases) that requires decent
performance (memory + speed) in a somewhat distributed fashion". Obviously
it's not perfect but it's the feeling I've developed recently.

~~~
aikah
Go started as a niche language and worked well for that niche, but like all
niche techs that become dependencies, they tend to get bigger overtime. Go
success is undeniable and is reaching a critical mass where there will be no
going back.

There are alternatives but most of them aren't backed by a big corp like
Google, so they will have to succeed in their respective niche before getting
widely adopted. I wish that wasn't the case cause languages like D,Nim or
Crystal are really good and way more enjoyable to write in my opinion. Out of
all of these(including Go) one will be the next big language, no question as
people move from dynamic or VM backed languages (for good reasons).

------
cdnsteve
I would have used Go for an API recently until I found out the AWS SDK for Go
isn't production ready. Libraries still have some catching up to do but will
only get better with more time and testing.

------
vegancap
Go made me excited about programming again. Love it.

------
xenihn
Anyone happen to have a link to a good guide/tutorial for building a mobile
backend in Go with gin? Or know of a public github repository with a good
sample project. I've never done any backend work, and I'd like to build a
backend for a simple iOS app to start.

------
nodivbyzero
Happy anniversary.

I replaced python with go in my projects and i'm so happy!!!

------
pythonist
Thank you! Go has made me enjoy programming once again.

------
baconizer
All I can say in words is - thank you.

------
adrianlmm
Despite the hype in the beginning, it never caught my attention.

------
lilinmeng
呵呵

------
chrshawkes
I'd say after 6 years adoption rate has been rather lackluster

~~~
csears
Compared to what other new language?

~~~
chrshawkes
maybe not specific to language, but compared to projects like Angular, React
etc... Go has much less traction. Swift is a new language and is already much
more widely used.

~~~
woah
Not going to debate your claim, but Swift is an unfair comparison, as it is
practically forced upon you if you want develop for one of the most important
platforms today (you can of course still write stuff in objC, but Apple has
made it clear that you'd better learn Swift).

~~~
hollerith
>[Swift] is practically forced upon you if you want develop for one of the
most important platforms today

>Apple has made it clear that you'd better learn Swift

Can anyone point to any statments to this effect by a leader at Apple? I
haven't found any with a web search.

------
mojuba
Feel free to downvote me if you want, but I'm skeptical about Go and what
caught my attention in this linked article is the picture. Pretty much what I
feel about Go. Was it a (sub)conscious choice?

