
Seven years of Go - 0xmohit
https://blog.golang.org/7years
======
gtrubetskoy
I have decided to get proficient in Go about 3 years ago and I am glad I did.
One of the discoveries in the process was that Go enables you to do things
that previously were extremely difficult and you'd typically not even consider
as options.

Many of the "old" ways of thinking do not apply to Go, and I had to get over
the phase of looking for an ORM or webapp or testing frameworks - they don't
exist because they are not necessary, and those that do aren't any good
really.

I ended up inventing my own challenge - a time-series database backed by
PostgreSQL ([http://github.com/tgres/tgres](http://github.com/tgres/tgres)),
because I needed a difficult problem. Tgres is still not fully baked, but what
it does couldn't possibly be done in e.g. Python, and not in C in as little
time (even though it's been two years in development).

Contrary to what the blogs say, Go is _not_ an easy language to learn.
Interfaces, goroutines, channels, selects, etc. will take a long while to
become second nature, and if you're not using them then you're not really
getting anything out of Go.

With respect to all the criticism Go is getting out there, e.g. lack of
generics - I honestly can't say there is anything that bugs me at all. Some
things may take getting used to, but usually in the end you're glad to have
done so.

As someone who has done a lot of programming in my life (in Python, C
(remember mod_python?) and also Ruby, and (with displeasure) Java) I can say
that Go is a big deal in the language landscape and will not long from now be
as big as Python - in fact I think it is Python developers who are most likely
to switch over to Go for their next project.

~~~
tptacek
Strong, strong disagree on the idea that ORMs aren't necessary because of some
property of Golang itself. Lack of decent ORMs is probably my biggest
complaint about Go, and I think if you look at a lot of large web app packages
you'll find people are all writing their own 40-60% of an ORM.

~~~
didip
Wrapper functions are not the same as full blown ORM.

For every heavily used ORM features, there's an opportunity to fall into a
trap, e.g N+1, because the surface area of an ORM is wide.

In contrast, wrapper functions are low cost, easy to write, and recognizable
because you write them yourself.

~~~
pcwalton
> In contrast, wrapper functions are low cost, easy to write, and recognizable
> because you write them yourself.

Isn't saying that you should use functions that are "recognizable because you
write them yourself" basically saying "you shouldn't use libraries?" This
seems like the obvious NIH fallacy.

~~~
fauigerzigerk
Not necessarily. It could also mean that these functions are more specific,
have names that make sense in the concrete context and don't have any
unnecessary parameters you need to think about. When it comes to ORMs it's
even worse. They are often not libraries but frameworks with tons of non-local
settings and state you need to know about (or else...).

Not invented here also means not invented for the specific task at hand but
for a much more general set of use cases. In my view it's a trade-off, not a
fallacy.

------
drej
My 2c: Go is incredibly convenient for non-programmers. I don't make a living
writing software, I make a living answering quantitative questions, using
computers. I use Python for most tasks, but when I need extra performance
and/or portability, I grab Go every single time.

The main appeal is the quality standard library that covers most things I get
in contact with. I could get immersed in it right away, because I didn't spend
weeks trying to read the spec - the spec itself is so trivial it's
mindblowing. The standard library feels very Pythonic in terms of reach. I've
built tiny servers, parsed plethora of file formats, calculated maths, wrote
data, (de)compressed stuff, encrypted things, ... The joy of not having to
worry about 3rd party dependencies for all these is quite refreshing. And the
appeal of few runtime issues thanks to static compilation is oh so excellent.

Sure, Go didn't invent any of these practices and sure, it doesn't have
generics, runtime assembly, it's opinionated in a few places, its vendoring is
subpar, ... But when you're someone who isn't really a programmer, these
things don't matter much. I'm not here for the hype, I'm here for the
productivity and ease of use.

~~~
sqrt
> I've built tiny servers, parsed plethora of file formats, calculated maths,
> wrote data, (de)compressed stuff, encrypted things, ...

If you've written code to do all those things, I think you'd be justified in
calling yourself a programmer, even if software isn't your main gig. :)

~~~
misiti3780
just curious, why write file parsers in go rather than say, python

i would think python would be easier.

------
be_erik
Go isn't a perfect language, but it strikes the right balance for me between
productivity and safety. There are few other languages right now with the same
ease of deployment, good tooling, excellent standard lib, and raw performance.
Here's to another seven years.

~~~
72deluxe
Out of interest, can you point me to any GUI bindings or native Go GUI
toolkits etc.? I would like to take a look, as I am normally writing native
C++ GUI desktop apps.

EDIT: Thanks for all the info everyone. I hope my responses don't appear
argumentative - I am genuinely curious.

~~~
Klathmon
I'm not sure if this would work for you, but using something like Electron and
having your go program output HTML/JS/CSS as your UI works really well with go
(or have your go program output JSON or something to communicate with the
front end)

If you throw something like react on there, you'll have a pretty simple
functional UI, but if you don't want that there's nothing wrong with HTML/CSS
and as little JS as you can get away with.

~~~
72deluxe
That sounds an interesting concept and useful for creating instantly-usable
web apps but in effect isn't your Go app being relegated to a HTTP server? eg.
how would I do callbacks without doing them as some request back to the Go
"server" app? How would you create custom controls in this method? eg. if I
wanted to do my own pie chart control/widget with popups etc.

It sounds like a long way around in comparison to what you can do in C/C++, ie
native calls depending on the platform, or use an abstraction toolkit like
wxWidgets. (Oddly C++ has done well without any native GUI toolkit of course,
but at least there was native C ones to use).

~~~
Klathmon
Ideally you would put as much of the "business logic" in the go code as
possible, and have it "render" to something like JSON which the front end just
reads in and displays. Interactions with the front-end just send a new request
to the go code to handle and respond with what is needed.

It is a lot more work for small applications compared to something like
wxWidgets, but for larger applications the decoupling of the front end from
the "back end" can help in a bunch of ways.

It lets you develop them somewhat separately, it gives you a uniform look-and-
feel across platforms (could be a pro or a con depending on how you feel about
it), and allows you to do something like replace the web-front-end with a
native system later if you want (and you could write the front-end in the
platform's native GUI widget library for best performance and integration
while keeping the backend code identical).

So your go code is basically an HTTP server at that point, but it frees you up
to let go do what it does best without worrying about how you will display it,
and it lets javascript/html/css do what it does best (display stuff).

I've had great success doing this once before, and if you have some experience
with React, it works out really "beautifully" as the front-end can be
completely stateless. So what was pushed to it from go is what is displayed.
Easy to test, easy to develop, and easy to replace if needed.

------
0xmohit
What's Coming in Go 1.8 [0] lists some upcoming changes in Go 1.8 (scheduled
for release on February 1, 2017).

[0] [https://blog.tylerchr.com/golang-18-whats-
coming/](https://blog.tylerchr.com/golang-18-whats-coming/)

------
fizzbatter
So, i was a Go developer for ~4 years, then for the last 4 months or so i've
been learning and using Rust. The pure joy of some things with Rust was
astounding.

Now, i joined a new job and they're in need of a new language for some backend
tasks - the choice was mine. Rust or Go? The backend tasks were heavy API
servers - nothing amazing, we don't do groundbreaking work. Python was their
existing language, but they weren't too happy with it.

For weeks (literally) i mulled it over, i really really really wanted to use
Rust. Rust gives me a peace of mind that Go never came close to.
Unfortunately, Rust does not fit the development speed nor developer
experience[1] that this shop has.. and i really felt Go would be the best
choice for this place.

My point to this post isn't to make a Rust vs Go comparison.. but rather, a
wishlist for the hopefully eventual Go 2.0. I have no idea if/when that will
ever be made.. but i hope it will, and i hope they adopt some things from
Rust.

1\. Channels without panics. Channels are awesome, but Go's design of them
means that you have to learn special ways to design your _usage_ of channels
so that it does not crash your program. This is asinine to me. So much type
safety exists in Go, and yet it's so easy for a developer to trip over
channels and crash their program.

2\. Proper error handling. I love error checking - i love it in Rust
especially. It's very explicit, and most importantly, very easy to check the
type of things. Recently i was reading an article about Go errors[2] and it
made me realize how messy Go errors are. There are many (three in that
article) ways to design your error usage, and worst of all your design doesn't
matter because you have to adapt to the errors returned by others. There is no
sane standard in use that accounts for the common needs of error checking.

3\. Package management. It's a common complaint, i know. But Rust & Cargo is
so excellently crafted.. Go just got it wrong. Recently i've been using Glide,
and while it's a great tool, there is only so much it can do. It's a tool
built to try and put some sanity in a world where there is next to no
standardization. We need a Go package manager.. hell, just copy Cargo.

4\. Enums. My god, Enums. Such a simple feature, but so insanely welcome and
useful in Rust.

You'll note that i didn't list Generics. I know that's high on peoples list,
but not mine. To each their own.. please don't start a holy war. _(this is
likely due to me using Go for ~4 years. I 'm quite comfortable without
Generics)_

[1]: By experience, i mean what they desire/expect. They're a Python shop
after all, i didn't want to make a choice that would cause them to spend
weeks/months feeling unproductive. [2]:
[http://dave.cheney.net/2016/04/27/dont-just-check-errors-
han...](http://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-
gracefully)

 _edit_ : minor text fixes.

~~~
jerf
"Channels without panics. Channels are awesome, but Go's design of them means
that you have to learn special ways to design your usage of channels so that
it does not crash your program. This is asinine to me. So much type safety
exists in Go, and yet it's so easy for a developer to trip over channels and
crash their program."

I've solved this in my programming by finally coming to grips with the fact
that channels are unidirectional, and if you want any bidirectional
communication whatsoever, up to and including the client telling the source
for whatever reason it has closed, even that one single bit, that _must_ occur
over another channel of its own. Clients must never close their incoming
channels. This does mean that many things that Go programmers sometimes try to
bash into one channel need to be two channels.

But I agree it's a problem.

~~~
fizzbatter
I don't know how, but frankly i'd love to eliminate all simple panics. Nil
pointers and channels seem two big culprits, offhand.

Granted, i left out nil pointer/interface panics because it seems unrealistic
given how difficult it was for Rust to get rid of nil pointers. I'm not sure
Go 2.0 could do it and still be considered Go.

~~~
jerf
I agree; I want non-nillable types in Go. This despite the differences in Go
that makes nil values more "valid" than they often are in other languages.

I still faintly hold out hope. Unlike many of the complaints about Go that
would require fundamental restructuring, C# showed that actually can be
retrofitted onto a language without breaking it.

~~~
pcwalton
> Unlike many of the complaints about Go that would require fundamental
> restructuring, C# showed that actually can be retrofitted onto a language
> without breaking it.

C# added _nullable_ types. Not _non-nullable_ types.

In Go, the concept of zero values is so fundamentally baked into the semantics
that non-nil pointers can never really be added to it.

------
kawsper
Is there a recommendable (and somewhat recent) book on how to get started with
Go?

~~~
mseepgood
"The Go Programming Language" by Alan Donovan and Brian Kernighan:
[http://gopl.io](http://gopl.io)

~~~
Mr_T_
Highly recommendable. It's the next modern classic after K&R's 'The C
Programming Language'.

------
mmmBacon
I've had a little exposure to Go and seen how rapid development in Go can be
while still maintaining decent performance.

Is anyone aware of scientific stack development in Go? Specifically, does HN
think thee will be a Numpy or Scipy equivalent in Go or does this not make any
sense?

~~~
psiclops
There are people who are working on this. There is an active data science
community using go. I would start here:

[https://github.com/gopherds/resources](https://github.com/gopherds/resources)

------
tbarbugli
Go is really getting to a point that is not just the new cool thing in town,
but a language that makes sense to use in production.

~~~
cdelsolar
I think that it was at that point a long time ago.

------
pvsukale3
Question : Is there a possibility that when Go package management is launched
there will be a good opinionated framework like rails for GO . Because for new
learners ORM , authentication etc things matter a lot. I know Go promotes use
of native HTTP package instead of frameworks but it is a large barrier for
newcomers and have risk of writing error-prone web applications.

~~~
mixedCase
Doing ORMs and auth without knowing what you're doing imply a huge risk out of
itself, which Go tries to avoid.

If you have relational data the solution is not to use an ORM to half-abstract
it away, it's to learn SQL. ORMs can be useful tools to avoid boilerplate, but
they _will_ show their ugly internals when SHTF, and those are always harder
to understand than plain SQL.

As for auth, it's very easy to add to any web application or HTTP API using
one of the many middleware solutions out there.

~~~
aikah
> Doing ORMs and auth without knowing what you're doing imply a huge risk out
> of itself, which Go tries to avoid.

And implementing it yourself the wrong way is also a huge risk.

~~~
mixedCase
Exactly the point I explained. You have to learn how it's done rather than try
to look for a way out. The solution is not to have a magic tool that allows
you to poorly work around the problem until it doesn't.

------
krylon
I remember reading the initial announcement. I looked at the language briefly,
and found some of the syntax too weird.

A few years later, I looked again and discovered I actually liked it very
much. Still do. I mostly use it for toy programs I write in my free time, but
I find that Go is very compatible with the way my mind works. I am currently
trying to use Go at work for some of the tasks I usually would use Perl for.
The fact that it comes with a relatively nice templating engine in the
standard library makes it very attractive to replace the CGI scripts that have
piled up over the years.

Interestingly, I had pretty much the same experience with Python - at first, I
disliked the syntax ("no Dutch person is telling _me_ how to indent my
code!"), but then I came back a couple of months later and found that I really
liked the language. (wrt indentation, Python only forces me to do something I
would do anyway, it just took me a while to understand that.)

------
sdsk8
I absolutely love go, it made my life and projects way better in many ways.
Thank you go team, you are really awsome!

------
joshbaptiste
As a Pythonista , I tried small projects in Go and Rust but ended up liking
Nim overall. Compiles to C and the syntax just feels like I'm writing Python.

------
sandGorgon
has anybody evaluated building an api in Go vs Kotlin ? We are considering
moving our financial tool api from python to either Go or
JVM/Kotlin/JavaLombok+lambda .

I really like Kotlin as a language.. but im really worried about the future.
Jetbrains isnt Google....

I like Kotlin also because we are an app-based startup.. and we have been
considering Kotlin on the app side as well. That would be a nice crossover of
engineering !

~~~
aikah
> has anybody evaluated building an api in Go vs Kotlin ? We are considering
> moving our financial tool api from python to either Go or
> JVM/Kotlin/JavaLombok+lambda .

Obviously, take a second to compare Go ecosystem with Java's and you'll get
the answer. Furthermore even if Jetbrains discontinue Kotlin, your libraries
are still compatible with the rest of the JVM languages. So you loose really
nothing.

Again what you should consider is the ecosystem and not the language. I
wouldn't try to do data science in Go for instance, when Python or Java have
stronger libraries in that domain.

Go is a nice outsider who is growing in spite of its issues because it's easy
to pick up. But you should really try it out and see for yourself if its
limitations aren't an hindrance for your domain problem.

------
epynonymous
go is my favorite language period, apps that i write in go seem more stable,
easy to maintain because the syntax is quite concise, and the performance of
the code seems quite good.

my language history is basic, turbo pascal, c, java, perl, python, javascript,
ruby, nodejs, go, swift.

what i really dont like about go or havent mastered yet about the language are
error handling and interfaces. error handling forces these oblong parts of
code where you check if err is not nil and then do something, that part makes
the code look a bit verbose, but i like most other things about the language
where i bear and grin.

gobyexample.com is an excellent resource for learning go. i have used go as a
restful api backend, a websocket service, and static site generator, all
pretty solid code with no errors. i used to run ror and found that not having
a good orm at first made programming db apps annoying, but i learned sql
syntax long before using orm's and it was just fine.

i have to admit that html templating languages are not that great (ace,
amber), but workable.

go apps when written correctly run fast and efficiently.

------
ohstopitu
I've always gotten into go on a high level and would love to delve in deeper.
Coming from a java/js background, my pointers are a bit rusty (and I try to
avoid them as much as possible). Would it be possible to use go without the
use of pointers at all?

~~~
tptacek
No, but pointers in Go are _much_ gentler than pointers in C (for instance:
there's no pointer math, and no pointer casting). If you understand the
difference between passing by value and passing by reference (something you
already have to understand to use Javascript), you've got all the background
you need.

------
amelius
Just wondering: Are people using Go as a target-language for compilation?

~~~
kodablah
I have been toying around with doing this for a JVM AOT [0], but it's in early
days and there are so many limitations (e.g. no circular deps, can't jump over
var decls, no easy overrides or overloads, etc) that it is quite difficult.
There are still a lot of changes I need to do to the way I'm handling things.

0 - [https://github.com/cretz/goahead](https://github.com/cretz/goahead)

------
keymone
seven years of go and they still don't have a ternary operator.

~~~
jamescun
This is a conscious decision. I believe the reasoning was readability. Ternary
operators have a habit of being used in some really nasty nesting.

[https://golang.org/doc/faq#Does_Go_have_a_ternary_form](https://golang.org/doc/faq#Does_Go_have_a_ternary_form)

~~~
keymone

        a = flag ? b : c
    

is much more readable and concise than

    
    
        if flag {
          a = b
        } else {
          a = c
        }
    

battling habits by making useful code inconvenient is just sad

~~~
cdelsolar
It's more concise, but certainly not more readable. You lose a few seconds
writing it the second way. It's fine.

~~~
the_af
To me the ternary operator is more readable. It has way less extraneous
symbols, it is expression-oriented and lets you focus on what's really
happening: that something gets assigned to _a_ based on some condition. It
expresses _intent_ better than the _if-else_.

Sure it can be abused and nested beyond human comprehension... just like _if-
else_! So that's a non-argument.

~~~
candiodari
This is the typical operator vs programmer argument. If you're working with
difficult concepts compactness trumps simplicity. Plus Go makes it such an
enormous chore to write programs with a lot of features.

If you're the one trying to figure out what went wrong in production, both
properties are big plusses. Simplicity means scanning code quickly will yield
an answer. And the fact that Go makes writing code a chore means there usually
isn't that much code.

And of course the fact that Go is so young, means there aren't that many
libraries that behave differently. People actually use the standard library
features, unlike in Java/C#/C++/Python/... It's becoming less true for
net/http, less true for log (all companies I know have their own version, I
wonder if Google has it's own version internally too). Go's still in it's
honeymoon stage where the standard libraries can actually be used for real
projects because they're so young they could implement modern web features
without having legacy cruft, nor have they made wrong choices yet, like
supporting a dead-end standard or practice.

~~~
keymone
i don't get what is not simple about ternary operator?

why is if statement that necessitates multiple assignment statements, involves
scoping rules and is objectively bloated for trivial cases, why is it
considered simpler?

it sure is easier to get than an operator due to proximity to natural
language, but why tend to people that can't grasp that a statement can be
represented as an expression?

~~~
candiodari
As a general principle, everything else being equal, less information density
is simpler. Ternary operator is quite dense.

Think about it: algebra (most of it) is just simple concepts incredibly
densely written down and recursively applied. There are very few really
complex parts in it, by which I mean there's very few individual steps that
take long to understand, there's just so bloody many of them and they link
together so incredibly tightly.

~~~
the_af
But everything else is not equal; the _if-else_ construct is less clear, more
error prone, and you must read it fully to make sure all branches are
assignments and that it's therefore logically equivalent to an assignment.

------
barrystaes
These big funny logos, illustrations, and memes appearing in todays technology
websites & videos really dont help for office environments. :( Colleagues
should not visit websites littered with memes and cute drawings, but i do.

~~~
zeveb
I love the look of the Go gopher, but you're not wrong. There's nothing wrong
with having a little fun, but there is something wrong with prolonged
immaturity. Where's that line? I don't know. Is the Go's use of the gopher on
one side or the other of that line? I honestly don't know.

~~~
petre
I think the Perl/OCaml camels or the Swift swallow logo are that line. They're
not cartoon characters or a cute looking animals like the Go gopher which is
both a cartoon and a cute animal.

