
The State of Go - dotmanish
https://talks.golang.org/2017/state-of-go.slide#1
======
joaodlf
I don't share some of the opinions I see in the comments here.

I've recently started programming in Go and I am having a blast. Plus, I am
making my systems faster and simpler with Go. I love concurrency in Go. I love
the concept of Goroutines, the simple and intuitive use of Select. Channels
still present a few mysteries here and there... But I'll get it at some point.

But the n#1 thing for me in Go is: It's written in Go. It's refreshing to
drill into the language details, I feel like I have learned so much from
seeing the Go source code (and having it readily available with a Ctrl+click
in VS Code).

Maybe it's because I don't have the "depth" of some of the HN users, but Go
feels great to me.

~~~
chimeracoder
> Maybe it's because I don't have the "depth" of some of the HN users, but Go
> feels great to me.

I've been writing Go full-time as my primary language for nearly five years.
Before that, my languages of choice were Lisp[0] and Python, with R as a very
distant third choice[1]. I have always been a polyglot and enjoyed
experimenting with any new language I could try out - you'd be hard pressed to
name a non-esoteric language that I haven't written more than a "Hello, World"
in at some point.

I still write other languages and appreciate them for what they are, but Go is
what I reach for when I need to crank something out. The language gets out of
my way and doesn't distract me - and as an added bonus, I can be reasonably
confident that I can quickly refactor the code 6 months later and still have
it run[2]. Go is not a scripting languages, but I sometimes even write small
applications in Go that I would have previously written as shell scripts, just
because it's easier and less thorny than remembering to avoid all of the
pitfalls of shell scripting.

You might say that this is because I've been writing the language for so long
- and yes, I'm definitely more comfortable with it today than I was in 2012.
But everything I just said was still true even when I was only a few weeks
into learning the language. It was like putting on glasses for the first time
in my life - yes, I could "see" before, but somehow everything was just a
little bit crisper, and I felt incomprehensibly more powerful and capable when
writing Go compared to Lisp, Python, Scala, Java, Perl... despite having far
more years of experience in those other languages.

If some people don't want to use Go, that's fine with me. But I strongly
reject the criticisms that Go is meant for "mediocre" programmers, for
programmers without experience in functional languages, or somehow an inferior
language because it lacks feature X or Y from language Z.

[0] Common Lisp (via SBCL) or Racket, depending on the project and
collaborators

[1] It's a language with a lot of warts, but even Python couldn't touch R for
completeness in statistical libraries.

[2] Seriously, I have never found a language that made refactoring as easy -
or, dare I say _fun_? - as Go.

~~~
cookiecaper
>If some people don't want to use Go, that's fine with me. But I strongly
reject the criticisms that Go is meant for "mediocre" programmers, for
programmers without experience in functional languages, or somehow an inferior
language because it lacks feature X or Y from language Z.

I think such complaints are the predictable backlash that's correlated with
the final stage of its hype-cycle. Tech hipsters always need a hot new thing
to tout so that they can pretend to know what they're talking about.

Now that we have a new iteration of hyped languages in Swift, TypeScript, and
Elixir, Scala, Go, and node.js are on the hipsterdom downtrend (which often
also means they're on the mature user uptrend). That prior generation of
languages are now at least semi-widely known, so they no longer serve the
purposes of the talentless hipsters, who base their self-worth on the esoteric
nature of their preferences and need something that most people don't yet know
much about to hide their ineptitude.

I think Python is a great example of a community that built a real niche for
itself and legitimately earned the respect of mature, senior engineers by
repeatedly proving and improving its utility and stability for many years.
Giving Go the opportunity to develop this same type of sustainable,
consistent, healthily growing ecosystem without a flood of 0.1x programmers
and other hipsters is really the best thing for it. I'm optimistic for Go in
the long term.

~~~
eeZah7Ux
At the beginning of the Java and the XML hype cycles few people called that
out the new toys weren't as shiny as they looked on the box. It took 10, maybe
15, years for others to catch up.

Look behind hype cycles and often you'll find $company marketing department.

------
DrBazza
Given some of the comments, I'll make the same comment I've made before:
Stroustrup is right, there are languages that people complain about, and
languages that no-one uses. Go is now firmly in the former camp.

I'm a C++ dev, and I really enjoy using Go. If you don't like what it does or
how it does it, it's not for you. Either way, people are out there using it,
making systems from it, and generally getting on with it.

~~~
mattnewton
Idk if that's such a clean binary, one of my favorite languages is Haskell,
and people both complain about that and don't use it :)

~~~
ice109
I'm starting a backend job tomorrow that's all Haskell. what are people's
complaints?

~~~
shard972
The main one I see is that it is too hard for programmers who don't fully
understand haskell/functional programming.

I see people complain at times about it's performance but there is always
someone there to rebut that it's fast at some things but not others.

~~~
ice109
yea compile times are killing my ability to iterate.

------
didibus
Go's success is attributable to the fact that it is the first compiled
language in a long time which is backed by a major company and has managed to
deliver a simple and enriched experience compared to the old company backed
compiled languages.

1\. Fast compilation is a killer feature.

2\. Ease of deployment, as a self contained executable (static linked), is a
joy.

3\. Channels are a revolutionary concept to every programmer who had only
touched mainstay languages.

4\. Type inference is a revolutionary concept to every programmer who had only
touched mainstay languages.

5\. Go's syntax is less verbose than all other earlier mainstay languages.
Such as how public/private is handled through casing, and not having to type
public or private.

6\. Go's structural typing is a revolutionary concept to every programmer who
had only touched mainstay languages.

7\. Everything that's new in Go to a programmer who had only touched mainstay
languages before it is not there in Go as an extra set of features, but the
only thing for them to use. This greatly focuses them on learning those new
features. Also, non of the features are too radical to throw them off
completely.

8\. All the tools for Go, are built by the team behind Go.

9\. Go's battery included, and has a great selection of modern standard libs.

When compared to Java, Go lacks very little, and brings a lot to the table.
Generics are probably the biggest omission, but that's probably going to make
it in the language eventually.

------
grabcocque
The best summary I read recently is that go isn't a bad language, nor is it a
particularly good one. What fascinates me is the way the Golang community have
concretised that essential middle-of-the-roadness as the language's prime
virtue. That, of course, has long been Java's prime virtue as well. (see Blub
Paradox)

By putting "we're okay with being okay" as your Big Thing you're clearly
pitching for that vast bulk of mid-quality developers that make up the huge
middle chunk of corporate devs, the space where Java reigns supreme.

~~~
dilap
Nah. I like Go because the language itself is minimal yet powerful, and
because the quality of engineering is extremely high. I am so tired of having
to deal with bullshit because of poorly-thought-out and poorly-engineered
tools; Go minimizes that.

An excellent example is the handling of this bug report(§):

[https://github.com/golang/go/issues/12914](https://github.com/golang/go/issues/12914)

which resulted in this language-change proposal:

[https://github.com/golang/proposal/blob/master/design/12914-...](https://github.com/golang/proposal/blob/master/design/12914-monotonic.md)

And then these commits:

[https://go-review.googlesource.com/#/c/36255/](https://go-
review.googlesource.com/#/c/36255/)

I feel like any other language I've used would've just added a "monotonicTime"
function and called it a day; the Go solution is impressive, elegant, and
shows an exceedingly high level of care for the end-outcome results for the
users of the language.

To me, that's what makes Go special.

(§After a rocky start; it took the core devs a bit to realize it was a real
issue because within Google's special environment it isn't.)

~~~
solipsism
_I am so tired of having to deal with bullshit because of poorly-thought-out
and poorly-engineered tools_

Seems to be some cognitive dissonance (in the modern erroneous sense of the
word) going on. This was a hack necessary because the design of the library
wasn't fully thought out. Imagining the world would one day become Google is
not thinking things out.

~~~
geodel
> This was a hack necessary because the design of the library wasn't fully
> thought out.

Easy to say 'not fully thought out'. It took Java from version 1.2 to 1.8 to
fix its date/time library.

~~~
AdieuToLogic

      It took Java from version 1.2 to 1.8 to fix
      its date/time library.
    

That is incorrect[0]. When spreading FUD[1], expect assertions such as these
to be fact checked by others.

0 - [http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22joda-
time...](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22joda-
time%22%20AND%20a%3A%22joda-time%22)

1 -
[https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt](https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt)

------
ptero
IMO the Go goal is to be an enhancement of C. It is not as expressive as some
existing languages (i.e., Go programs may be longer), but it is very good for
translating clearly thought through logic into efficient machine code.

It supports some of the features that original C lacks (networking,
parallelism, channels, etc.), which to me is a very good thing. With minimal
forethought this allows writing programs that can be massively scaled later
without impeding initial checkouts at small data sets.

Eventually the success or failure may be determined by the libraries developed
by the user community. For example, fortran survived so long not because it
was a good language, but because it had freely available, easy to use world
class libraries for numerical computation. Many grad students kept using
Fortran given the choice of an existing, working, ugly-ish code that they
could use for their PhD projects vs redeveloping and retesting the same
functionality from scratch.

~~~
Taek
In my experience writing go is very fast and reading go is also very fast. The
language was designed to be very comfortable, and they did a great job with
that. You sit down to write something and you don't have to think too much
about the best way to tackle the problem, the lines of code just flow from
your fingertips. There's mostly one way to do everything, which makes doing
things easy.

Code review is much the same.

~~~
tejasmanohar
I feel the same. Go is a different type of terse. I think terseness goes
beyond the number of lines. When I skim Go code, I can grasp the meaning of it
very quickly.

~~~
sjellis
I've seen talks where Rob Pike describes Go as being "light on the page" vs.
"noisy", meaning (I think) that it doesn't have lots of sigils and annotation
bits around the code.

------
j2kun
I'm concurrently learning Go and Node, which might not be a fair comparison
but I'm going to make the comparison anyway.

Node feels like a flesh wound with delicately layered bandaids. The ecosystem
is a mess, you have to jerry rig basic packages to work together, the syntax
and semantics of closures and context is ridiculous, and despite that callback
mania is like this cool-aid that's supposed to feel great once you drink it
(but hasn't yet for me).

Go just...works.

~~~
JepZ
Hehe, I have to underline this aspect as npm killed half an hour of my work
yesterday, when I redownload some package in a sibling directory (for diff
purposes).

Never had this experience with go. The comparison is a little emotional for
me, but when I realized npm just killed my code, I was emotional...

Nevertheless, Javascript/Ecmascript is the result of years of development in a
living environment (the web) while go was designed from scratch, by some of
the most capable programming language designers on this planet, to enhance
their previous work. Who wonders about the result?

------
greg7mdp
My impression is that Go is a language that was cobbled together to simplify
the coding of some specific applications, such as simple servers. It lacks any
kind of purity, is not the best choice for any specific task, but is just good
enough for some (many?) tasks. And poor type safety!

Frankly, I can't help being disappointed by how bland this language is, and I
have zero interest in using it. Maybe because I like coding, and the IMHO
using Go or Java would totally kill the fun of it.

~~~
aczerepinski
But if you like typing `if err != nil` it's actually the _most_ fun language.

~~~
rpercy
Heh, it does feel repetitive. But after ~10 years with Java, I'm happy to
avoid the cognitive load from deciding how to most politely generate/propagate
an exception. Obviously, there's no perfect solution, and preference is
subjective.

~~~
candiodari
In reality Go makes it worse, if you truly keep track of all possible cases.
After calling a method, in Go you have to

1) "if err != nil" after every statement

2) give some serious thought to whether the previous statement could panic or
not

Good luck if it's a library call that may get updated or call other libraries
!

3) Think about the non-error error cases that can't be abstracted out. Go is
like C, in the sense that there is an ERETRY "error" (unsurprisingly, you
should simply try again, you should NOT fail)

And there are cases where there can be an error and yet error is nil. Easy
example of this would be sscanf.

And we now see practical Go code published online : how these problems are
dealt with, real world edition:

1) either mindlessly putting "if err != nil { return err }", which is a very
bad information-erasing exception system, or just outright ignoring errors.
Don't you know you can also use "_" as the error variable ? Maybe they should
make that implicit like in perl. Of course perl is likely to tell you this
happened ... unlike C and Go.

(really brings back the C days doesn't it ?)

2) most people either don't know or just deny this. Thankfully panics at least
do list where they occur. They also kill your program and print stacktraces.
Pages and pages and pages of stacktraces.

3) very few people even know about these problems ... so they're ignored, and
the standard Go tools themselves don't behave according to unix
specifications.

~~~
cube2222
Panic is pretty much never used (so you don't really have to think if the
previous statement can panic. If it does it means something is SO wrong that
your application can't continue anyways because it's broken)

You should really use a library like github.com/pkg/errors so you get to wrap
the error you return with additional information. Errors are just a worse
Either monad after allm they're much more pleasant to use than exceptions.

~~~
leshow
> Errors are just a worse Either monad after allm they're much more pleasant
> to use than exceptions.

How are errors in Go at all monadic? They just have a convention where you
return a tuple and manually check if something isn't nil. Either type will
inhabit one variant or another, not both with one having a value of nil.

The 'monadic' part of Either (or Result in something like Rust, where try! is
sort of like >>= if you squint) is the ability to chain Either types together
and have the boilerplate abstracted, that feature is completely absent from
Go. Errors in Go are neither the Either type nor monad, IMO.

~~~
cube2222
As I said, in practice they're a worse either monad. With which I meant ->
they were inspired by them, but lack the monad part and having the value with
the error in one object interchangeably. It's the same treating errors as
values though.

~~~
leshow
It's really just a worse Either type, if anything, there's nothing monad about
it. Although it's sort of hard to be close to an Either without being an
algebraic data type. But I see what you're trying to say.

------
inblueredgreen
[https://tip.golang.org/pkg/sort/#Slice](https://tip.golang.org/pkg/sort/#Slice)

ouch compile time type safety... even Go maintainers have abandoned it. Go
pundits can't expect developers not to do the same thing in their own codebase
at that point.

Can't wait for aliases though.

~~~
bostik
The ability to provide inline comparison function for Sort() is welcome. It's
one of those infrequently needed language niceties that have (at least for me)
made perl and python so slick to use.

Sorting arrays of objects or small hashes, based on arbitrary properties/keys,
is quite useful.

~~~
yxhuvud
You are not really responding to the comment you are replying to, though. Yes,
being able to do custom sorting is nice, but no-one challenged that claim. The
type system really doesn't look very nice when it won't even manage type
safety in such a simple case as this. Also, compared to other languages that
is in sort of a similar spot[* ], such as Swift or Crystal that both manage
type safe custom sort functions, it looks even worse.

[*] That is, modern languages that compile down to native code while having
some basic way of avoiding manual memory management.

------
JacksonGariety
I'm in a pretty weird place with Go.

On the one hand, I really cannot stop using it. I can build an small web
applications in a day or two, I can write them in just slightly more lines
than Rails, and the applications I can build are much speedier than Rails
applications.

On the other hand, I really, really hate using Go. It's tremendously boring
and I never feel the code is that elegant.

I've tried Haskell, but I end up messing around monads too much because
there's so much IO.

Rails is fantastic, but I'd prefer to experiment. I never grow as a developer
when I use Rails.

Node.js is great. But if I don't need to write a lot of JavaScript on the
frontend I end up asking myself: why am I writing JavaScript on the backend?

Racket or Chicken Scheme look like good directions for me. Erlang looks
interesting. Maybe I should give Clojure another shot?

~~~
JackMorgan
Your comment is similar to how I feel about Clojure. It's "good enough" for me
for most things. Whenever I need something fast, that's what I grab for first.
But, it feels "mushy" after +10k lines of logic, and I'm wishing it was F# or
Haskell. I think I just need to bite the bullet and only use Haskell from now
on. If it's slower at first, meh, it'll catch up when it grows.

------
naaaaak
Awful to try to read on mobile. Regular page anywhere?

~~~
sambe
Completely unusable, perhaps the worst in recent memory of any front page
article. Strange thing is that previous Go presentations have looked almost
identical aesthetically but worked well.

------
throwaway91111
Man I really wish they would stop using whatever crappy presentation software
this is; it NEVER works well on mobile.

~~~
shurcooL
It's `present`, a very simple tool. Written in Go, open source.

Using it is a choice.

I agree its ability to work on mobile is limited and that could use a CL (or a
few) to improve.

[https://godoc.org/golang.org/x/tools/cmd/present](https://godoc.org/golang.org/x/tools/cmd/present)

~~~
Cyph0n
A beautiful example of NIH syndrome in the real world.

~~~
enneff
Can you suggest another presentation tool that makes it as easy to author and
maintain slides? Nothing like this existed when Rob and I wrote present.

~~~
Cyph0n
I'm not sure what your exact requirements were, but I immediately thought of
the following:

* Beamer: write slides in LaTeX, maintainable for a long time to come and easy to build.

* Reveal.js: use JS and HTML to author slides, easy to present, and pretty maintainable I think.

* Pandoc[1]: use Markdown or RST to write your slides, then compile to HTML (e.g., Reveal.js) or LaTeX (Beamer).

* Google Slides

I'm not sure if any of these (except Beamer) were available back when you
wrote the tool, but given some of the complaints in this thread (e.g., not
mobile-friendly), wouldn't it make sense to migrate to some other tool going
forward?

[1]: Absolutely fantastic tool all-round, and written in Haskell to top it
off. I used it a few years back to write a LaTeX report in Markdown. It's
definitely not as good as writing LaTeX directly, but it's a great place to
start. I can't praise Pandoc enough.

~~~
enneff
Reveal wasn't a thing when I wrote present. I probably would have used it as a
front end, had it existed.

Tools like Keynote and Google Slides were exactly the kind of thing we were
trying to improve upon. They're great for making pretty slides, but a total
PITA for authoring and editing technical content.

Can any of those tools execute code from within the slides?

[https://youtu.be/f6kdp27TYZs?t=380](https://youtu.be/f6kdp27TYZs?t=380)

[https://talks.golang.org/2012/concurrency.slide#16](https://talks.golang.org/2012/concurrency.slide#16)

And do they let us store our code snippets in actual testable (or at least
buildable) source files?

~~~
Cyph0n
> Can any of those tools execute code from within the slides?

> And do they let us store our code snippets in actual testable (or at least
> buildable) source files?

Not that I'm aware of, no. That's a pretty cool feature actually!

As you kindly said, Reveal.js may probably work for you as a frontend for your
tool.

~~~
enneff
Those features were the impetus for the tool, and as far as I'm aware they
were Not Invented Anywhere at the time. :-)

~~~
Cyph0n
I guess I missed those features at first glance. I apologize for that.

------
spraak
I'm yearning for the Golang of functional programming. That is, excellent std
lib, clear documentation, awesome tooling, active community.. and after typing
this, maybe that's Elixir? Though I do love static typing.

~~~
yawaramin
You may be interested in
[https://facebook.github.io/reason/](https://facebook.github.io/reason/)

They have an active community that is _very_ engaged in improving the entire
developer experience. Plus ReasonML is just OCaml under the (new syntax) hood
so you have decades of OCaml expertise and libraries to draw on. In case
that's not enough, it also deploys to JavaScript and targets the npm
ecosystem, so you _also_ have the entire npm package collection at your
disposal.

~~~
spraak
Wow, thanks very much for sharing that!

------
gw
I'm at FOSDEM where this talk was just given. Francesc was hilarious.

~~~
campoy
well thanks

~~~
spraak
I love your Just For Func videos! I wondered if you could make one explaining
pointers in Go. No explanation I've found really settles in for me, and while
I'm getting a 'feel' for them writing more code and getting feedback from the
compiler, I'd like to find a good explanation of them. I'm asking you
specifically because you have a really great way of explaining things, and a
warm presentation style. Either way, thanks for all you've given through your
talks and videos!

------
zirtec
Definitely the talk I enjoyed the most at FOSDEM today. Both instructive,
relevant and pleasant to listen to. Glad to see things like sort.Slice or JSON
rendering. When you're spoiled with python or groovy, you miss them them
badly.

~~~
vorg
Always good to see features from the likes of Python and Apache Groovy make it
into Go.

------
amelius
How is Go as a compiler-target? I'm asking because I've heard that Go has a
very good concurrent garbage collector.

------
zalmoxes
There's a worldwide Go 1.8 Release Party on Feb 16th. If you're interested in
Go, or want to discuss changes in 1.8, find a meetup near you.

[https://github.com/golang/go/wiki/Go-1.8-Release-
Party](https://github.com/golang/go/wiki/Go-1.8-Release-Party)

------
rusbus
I was glad to find they made it much easier to define custom sorts for slices.
But! Why on earth does what should really be syntactic sugar make sorting
nontrivially slower?

It speaks to the lack of expressiveness in golang that you can't make sorting
less egregiously verbose without adding a performance penalty.

~~~
zzzcpan
> what should really be syntactic sugar

They probably use run time reflections, not a compile time syntactic sugar
a.k.a. generics. As Go doesn't have those, so anything like that would require
a compiler hack and nobody likes hacks.

~~~
DougBTX
Syntax sugar is extra syntax to make an existing feature easier to use, syntax
sugar has no runtime impact.

Generics are not syntax sugar, they add functionality such as stricter
compile-time type checking and improved run-time performance (e.g., C# can use
unboxed primatives in generics)

------
camperman
I shall be moving my codebase to Go this year. I'm very impressed at how
readable it is, how much thought has gone in to the tooling and support
environment and how fast the GC is now. I also must be one of the few people
who likes the assembler :)

------
bokertov
I'm on my iPhone and the slides are terrible to navigate on a mobile browser.

~~~
spraak
Yeah I came here to comment about that, too. It's surprising to me - I would
have expected the Go team to have implemented/fixed that

------
YZF
Most of my work is C++ but I've also used Go a fair bit since Go 1.5. I like
Go a lot. The C++ crowd (including myself) keeps trying to make things that
are trivial in Go easier in C++ but the best efforts still look like a mess. I
think the lightweight/green threads model of concurrency wins over others
(threads, processes) and is incredibly difficult to get right in C++. Channels
are also very useful and difficult to get right in C++. While C++ with some
aid from Boost can be a very safe language it ends up being a lot harder to
write and read with all sorts of [](){} -> hacked up conventions that are a
result of backwards compatibility. I find the test infrastructure in Go to
also be very pleasant and easy to use. Stuff you need to go to extremes of C++
to test are just trivial to do in Go.

Things I would like to see improved:

\- Package management. I think "go get" was an interesting idea that is
basically a fail for anything except the most trivial of situations. Vendoring
is not a great solution either IMO. Perhaps some idea that manages package
versions through local git repositories can work better since a git repository
is a better representation of the version history of packages.

\- I didn't like the compile speed loss we took when the compiler code base
moved to Go. I'm not quite sure where it stand right now but one of the things
that I liked about Go from the beginning is lightning quick builds.

\- In my usage there seem to a few quirks in the language including the
various scoping weirdness and the declare and assign operator := ... I
frequently end up with code that re-uses the same variable such that the first
instance is := and the next are = which makes refactoring a pain. The compound
if statement also suffers from this.

The uppercase/lowercase public/private convention is also odd. You get used to
it but it seems like a hacky afterthought.

------
coldcode
I for one will be more interested in using Go when Jetbrains finishes their
IDE. Clearly not everyone cares to develop in an IDE but after 33 years of
doing it, I prefer the idea. Give Swift (my current work) as many years as Go
has had (10 years), and maybe I won't find Go that interesting any more.

~~~
geoka9
To each their own, but Go is probably the only mainstream language that has
first class integration with text editors. So I wouldn't let that stop me from
using it, unless you can't see yourself using a text editor at all.

~~~
solidsnack9000
What is the first class integration? My experience using Ruby, Python and Rust
(via Racer) with Vim+Syntastic has been pretty good.

~~~
ovidnis
In my Emacs I've got 1) eldoc (displaying signature of function at point), 2)
function source lookup, 3) function documentation lookup, 4) flycheck (display
compiler err/warn on save), 5) auto-completion. Among a few other things like
go-guru integration which I haven't used much yet but I can see its use.

All of those features come from editor agnostic golang tools.

~~~
josteink
Typescript has thee same. Ditto with C#. Python is pretty close. Same with
most LISPs.

In Emacs too. I'd hardly say this is a unique selling point of Go.

~~~
geoka9
Do they do static analysis of code? The problem is that with other languages
they all work "sort of". For example, for Elpy:

"the backends can not always identify what kind of symbol is at point.
Especially after a few indirections, they have basically no hope of guessing
right, so they don’t"

With go guru it just works, always, no matter how deep you drill into the
graph (that's what I meant by "first class").

~~~
josteink
With C# and TypeScript and all LISPs I've worked with, they work hand in hand
with the compiler/runtime to provide absolute correctness at all levels.
Absolutely first class. (And I agree Elpy does not qualify for that term)

And while we're on the subject: Only Microsoft had the foresight (or
hindsight, insight, whatever) to realize this was a _general_ problem and
propose a solution which applies to _all_ editors and _all_ languages:

[https://github.com/Microsoft/language-server-
protocol](https://github.com/Microsoft/language-server-protocol)

[https://github.com/Microsoft/language-server-
protocol/wiki/P...](https://github.com/Microsoft/language-server-
protocol/wiki/Protocol-Implementations)

You'd think Google, with their tons of resources could put together a few
resources and join a new, future-proof non-NIH standard for Go, but so far
they seems to be lagging.

~~~
geoka9
I agree, a common standard would be good. That said, experience taught me to
distrust any proposed standard that comes out of Microsoft. Besides, I find
that with the programming editor communities, such standards are not that
important - as long as a language has the tooling, it'll be integrated,
standard or no standard.

~~~
josteink
This protocol is about reducing the N languages and M editors = N*M
client/server implementations with a much better N+M solution, where we don't
have to reinvent 200 wheels every time someone makes a new editor or language.

And the protocol is open. Seriously what do you have to lose, besides a shit-
ton of redundant work?

Distrust? Distrust exactly what? Are you sure you aren't being your own worst
enemy?

See here for a list of fully open source and MS-independent implementations:
[http://langserver.org/](http://langserver.org/)

~~~
josteink
Too late to edit, so replying to self.

Looking at that list, I see Go is actually doing pretty well these days. I
retract my criticism.

That said, as the page shows, having full editor support these days is getting
pretty common.

------
niftich
Conversion rules seem like an awfully specific language feature to introduce
just to scratch a very particular itch.

The rest of the slides are pretty standard-fare, and that's a good thing.
Would've liked a reference to the lack of monotonic time, though; either an
acknowledgment that it's a problem (because it's now fairly widely known), or
a mention that a new proposal to fix it [1] is in the works.

[1]
[https://news.ycombinator.com/item?id=13566110](https://news.ycombinator.com/item?id=13566110)

~~~
cetxcz
The conversion feature is in fact very convenient.

We often keep different types for what we get from the user (JSON) and what we
write on the database (e.g: BSON). Having the ability to convert between them
without having to re-type everything is useful for a lot of code out there.

~~~
calcifer
To be fair, you can do that right now with unsafe.Pointer, but of course it's
better to have a compile time checked version of it.

------
cft
Go is better for applied tasks. Currently there is no faster way to write or
simpler language than Go to write a highly scalable internet server that can
handle 100-1000k concurrent clients on the commodity hardware. I suspect this
applies to some big data analysis tasks in bioinformatics, that can be
parallelized.

~~~
fnl
As a bioinformatician, I can tell you: no. Hardly anywhere you have that
concurrency need. You have a few clients only, typically, but with very highly
parallel work-loads (as opposed to concurrent ones). Go is a bad for there.

------
wtbob
This slideshow doesn't work on narrow browsers: a narrow browser window clips
the text, despite there being more than enough window space to display all the
information on the slide.

Remember when the Web was automatically adaptive? Remember when we preferred
HTML to PDF _because_ it adapted?

------
knodi
I think Go is an amazing lang, its simple yet powerful. I have been using it
in production for over 3 years.

~~~
fnl
Mind to elaborate on what? Writing servers/services, and devops tasks, or
something different?

------
neonkiwi
Looks like the video is here, but YouTube is having trouble with it at the
moment:

[https://www.youtube.com/watch?v=pwIOmKZBuVI](https://www.youtube.com/watch?v=pwIOmKZBuVI)

------
riprock
I've never used Go, but would you write your customer facing REST service
using Go? Or would it only be used for back-end microservices? What's a
recommended library for writing a customer facing REST API?

------
widdma
Video here:
[http://video.fosdem.org/2017/H.1302/](http://video.fosdem.org/2017/H.1302/)
(go_state.*)

~~~
kyrra
Already on the Go channel on Youtube:

[https://www.youtube.com/watch?v=tY4UKkgb5IY](https://www.youtube.com/watch?v=tY4UKkgb5IY)

------
bokertov
I'm on my iPhone and the slides don't work well.

------
Hydraulix989
Why are we getting rid of OSX 10.8 and some of ARM6? Are they _really_ that
much extra work to support? I have a hard time believing so.

~~~
enneff
Well Apple stopped supporting 10.8, so why should Go continue to support it?

ARM6 support is a lot of work, actually, as IIUC a lot of stuff that the chip
doesn't support needs to be done in software, and we don't have a reliable
platform for testing against ARM6.

~~~
4ad
> Well Apple stopped supporting 10.8, so why should Go continue to support it?

I don't know, but Microsoft stopped supporting Windows XP many years ago, and
it's still supported by Go. (Not that I care about Go on Darwin 10.8; just
making an observation...)

~~~
enneff
Microsoft puts more effort into keeping things working than Apple does. Go
works on XP as a result of the work Microsoft has done, not the Go project.
Apple change subtle things in each OS X release making it onerous to support
the older ones.

~~~
4ad
This is not true, Go "keeps working" on Windows because on Windows Go is ABI
compliant and uses stable interfaces. In particular, on Windows Go interacts
with the system through kernel32.dll and uses the standard Windows ABI.

Same is true for Solaris, where Go interacts with the system only through
libc.so.1, and uses the System V ABI for the calling convention and thread-
local storage.

On Linux the system call interface is stable (unlike Windows and Solaris), so
on Linux Go "keeps working" too (albeit I will note that we don't use an ABI-
compliant method for determining the current time...).

Darwin is just like Windows and Solaris, and unlike Linux. The system call
interface is not stable, but unlike Windows and Solaris we use it anyway, and
the method we use for thread-local storage is unportable and system-dependent.
However, Darwin still has a stable interface through its own libc, and there's
an ABI-compatible method to do thread-local storage as well. If Go would use
the standard system interfaces on Darwin (like it does on Windows and
Solaris), Go would just "keep working" on Darwin too and would not require
changes each time a new macOS release is made.

It is true that Microsoft is very committed to forward and backwards
compatibility, but only for its stable and documented interfaces (which Go
uses), undocumented interfaces break all the time; Darwin's forward and
backwards compatibility guarantees might not be as strong as Microsoft's over
large periods of time, but they are still pretty good _as long as you use the
supported interfaces_.

------
tehwalrus
Impossible to read on an iPhone SE. Landscape or portrait, slides cut in half
and jumping around when you try to scroll.

------
Bino
Is there a youtube view available?

------
mrcactu5
i love languages and i am enjoying seeing Go mature as a language. At the
moment I do have my hands tied with Elm and Haskell.

Originally I am a Python programmer. Any advice for people transitioning for
Python? What are some of the advantages of Go?

~~~
aryehof
My advice is be demand rather than supply driven. Be driven by what paradigm
and language is suited to a problem, rather than just what can I apply my new
silver-bullet language to.

------
Keyframe
One thing I never understood with Go was what's the deal with multiple return
values in functions? Why would you do this? What was the reasoning?

~~~
twic
One of Go's other design decisions is signalling failures by returning errors.
Multiple return values makes it possible to do that and also return a real
value.

If you didn't have multiple return values, you would have to do something
ugly: C-style pseudo-return via a passed-in pointer, or returning an error or
a value as an interface{} and requiring the caller to type-switch on it. Or
add a special case to the language to somehow allow an error return alongside
a normal return. Multiple return makes this straightforward and uniform.

~~~
Keyframe
Alright, that actually makes sense. Thanks.

------
kmicklas
And yet no generics still. What a joke.

~~~
grzm
Is go something you'd like to use? Are you happy with the stack you're
currently using? What is that stack?

There are clearly people who are getting things done using go, and finding
generics aren't something they require. Dumping on a language you don't like
is boring and gratuitously negative.

------
notforgot
Question: who is going to remember all these conversion rules? By the second
bullet you lost me.

 _Simply run the command below:_

    
    
       go tool fix -diff -force=context state-of-go/tools/gofix.go
    

How is typing 59 characters simple?

~~~
shurcooL
`staticcheck` will statically analyze your code and suggest all places where
the new conversion rule can be applied.

All the other rules are same as the last 7 years, you know them through
experience after using Go for a week. Way simpler than most other languages.

That go fix command can be typed once and update millions of lines of code.
Pretty simple.

~~~
notforgot
These rules intimidate me (I don't know Go).

You also meant to say the go fix command does a lot (which is great), not that
calling it is simple (which is not great).

------
fnl
Golang really seems to have come a long way. But what holds me back from using
it are the dangers of deadlocks and segfaults (due to forgotten error
handling) that might be introduced even inadvertedly if applied to industrial-
scale projects (say, 1M+ LOC, 10+ developers). That is, I see many small
(server/microservice) projects flourish with Golang, and it seems an excellent
replacement for certain types of C projects, but I wonder how Go enthusiasts
believe it could scale to compete with Java or C++, due to the way it does
error handling, and deadlocking issues with channels.

~~~
Strom
It's even easier to mishandle errors and get deadlocks in C++. That is in
addition to all sorts of other fun like buffer overruns. If the team is
capable of not messing these things up in C++, then they are more than capable
of not messing up in Go.

~~~
fnl
Modern C++14 provides quite good support on those fronts, and modern Java8 has
lost most of its "code notoriety".

But that's just arguing back and forth. Here's the real argument: What popular
OSS projects of noteworthy scale are being developed in Go? I know a few
dozens in either Java or C++, and even a few fairly noticable Scala projects
(Spark, Flink, Play, ...), but I yet have to see anything written in Go that
can be called "industrial sized".

~~~
sjellis
If you want examples of "industrial-sized" Go projects right now, you may have
to look at case studies for proprietary cloud infrastructure, e.g. CloudFlare,
Fastly, DigitalOcean, SoundCloud, and SendGrid. These companies obviously
don't open up their product code, but they've been happy to share some
information about their use of Go.

~~~
fnl
Yes, I've noticed for years that Go gets heavily used in web service-oriented
startups with many concurrent users (plus, its easier to pick up than Erlang
:-)).

But what I would really hope to see is Go being used for anything _else_ than
servers/services. I understand this is all the rage for certain companies, but
none of that directly touches my own interests. Is Go only good for that
niche, or will we see Go being adopted outside that "web services world"?
E.g., for building old-school desktop apps, Go's concurrency features might be
pretty cool - if its not too low-level for that?

