
Brad Fitzpatrick on the future of Go - sylvinus
http://dotgo.sourcegraph.com/post/99652962343/brad-fitzpatrick-on-the-future-of-the-go-programming
======
Animats
Well, it's good to have a hard-compiled language that's (almost) memory safe.
Three problems with Go:

\- The Go mantra is "share by communicating, not by sharing". Then look at all
the thread examples in "Effective Go". They all share memory, while trying to
construct locks using message passing. Multi-threaded Go programs are not
memory-safe. That's why Google won't let you use them on their AppEngine.
Compare Erlang, which takes message passing seriously.

\- The lack of exceptions is resulting in hacks using the "panic" mechanism to
create an exception mechanism. This is where we were with "longjmp" in C. I
know someone at Google who has constructed a language on top of Go mostly to
deal with exceptions.

\- The lack of generics is resulting in hacks using the reflection mechanism
to create generics. This is painful and slow. Go has generics for built-in
objects; channels and maps are parameterized types, so there's already syntax
for instantiating a parameterized type. Extending that to user-defined types
would not be too bad. Fear of the C++ template mess seems to have been the
problem.

~~~
kyllo
Rust addresses all of these problems. It's memory safe through compile-time
reference counting and borrow checking (not garbage collected), and it has
exceptions and generics. It also has a more powerful type system with type
inference.

Having tried out both Go and Rust I don't see any reason to prefer Go, at
least once Rust has a 1.0 release, which is supposed to happen the next 2-3
months.

Both languages were designed to replace C++, but only Rust has the features to
actually succeed at that, IMHO.

~~~
higherpurpose
I think at this point Go is more of a replacement for Java than C++.

~~~
tptacek
People love to say this, but the observation falls apart quickly under
scrutiny. People working in Java are doing so to retain access to the JVM and
to the zillion libraries built on it. The JVM with its ecosystem is a colossal
asset for Java; one of the greatest in all of commercial software development.
(I say this as someone who does not enjoy Java).

Meanwhile: Golang neatly fills in a sweet spot just "below" Python and Ruby,
where finer-grained control of memory and more predictable performance
characteristics are required, but bare-metal performance isn't. That sweet
spot actually describes a huge fraction of all the use cases for C/C++ in
Internet software.

So this is a meme I'd like to see die. It somehow manages to simultaneously
get Golang, Java, _and_ C++ wrong all at the same time. The only way to make
it worse would be to work in some kind of Lisp comparison, based on Golang's
parsimony with parenthesis.

~~~
threeseed
Couldn't agree more.

Anyone who thinks Go will ever be a replacement for Java is frankly clueless
about enterprise software development. Go has almost non-existant integration
with enterprise systems e.g. SAP, Hadoop. It lacks operational management
capabilities e.g. JMX. And seriously the range of libraries on the JVM covers
pretty much everything e.g. banking/finance use cases.

And concerningly there is not a single reasonably sized Go project to get an
understanding of how it works with 20, 50, 100 or 500+ developers working on
the same codebase.

~~~
kyrra
Docker is fairly large, cloc output:

    
    
       ----------------------------------------------------------
       Language             files     blank    comment       code
       ----------------------------------------------------------
       Go                     750     14601       9901     115877
       CSS                      8       107        194      10010
       HTML                    11       362         21       3594
       Bourne Shell            28       391        323       2044
       Bourne Again Shell      25       249        185       1475
       Javascript              12       111         48        756
       Python                   1        23         24        192
       C                        1        20         19        179
       YAML                     4        25         13        162
       XML                      1         6          2         60
       make                     2        27          5         60
       Perl                     1        11         37         29
       vim script               2         8          3         13
       ----------------------------------------------------------
       SUM:                   846     15941      10775     134451
       ----------------------------------------------------------
    

And I believe there are a number of projects internally within Google but they
tend not to talk about internal product technologies (at least at how large
they are).

~~~
threeseed
No Docker is not fairly large. It's tiny. 1M - 10M LOC is the size of most of
the codebases I've worked on.

Most people simply don't have an understanding of enterprise applications. The
majority of the apps are single codebase, Servlet/Spring type monstrosities.
They are 10+ years old and have had hundreds of contract developers who come
in, add a few new features and then go onto the next contract.

And my point is that I am yet to see what Go would be like in these
situations.

~~~
tptacek
It seems a little unfair to ding Golang for not providing evidence of
something Golang was designed to avoid. "Where's all the boilerplate? Where
are all the 10 layers of XML mapping? What would an AbstractStrategyFactory
even look like?"

~~~
pjmlp
Rest assured, if Go manages to become a success in the enterprise you will get
them.

It happened to every language without exception.

~~~
mlvljr
But will it happen to one without exception _s_ , as well?? :)

~~~
placeybordeaux
Panic/Recover will be used as expections.

------
cies
Reading this I feel Go is boring, and that's an asset. Let me explain.

Seeing [what's happening in Haskell
(GHC)]([https://www.haskell.org/pipermail/ghc-
devs/2014-October/0065...](https://www.haskell.org/pipermail/ghc-
devs/2014-October/006518.html)), which is soooo much more exciting; but then I
totally understand that "exciting" is what you want to stay away from in some
cases. In these cases a Go is a much better choice I guess.

~~~
laumars
I often describe Go as being boring as a positive asset. For example, when
people what makes Go special, I say " _it 's not better than any specific
language at specific things, but generally better than most languages at
general things._" Which is extremely dull, but most of the time you do just
want something straightforward, stable and ordinary when you have normal
development projects.

So I think Go is an extremely dull language - but personally I think that's
what makes it so good.

~~~
pmelendez
I tend to think like that about C#, the thing is I feel like there are already
many dull, private company managed, programming languages out there to make me
curious enough to use it in real life.

~~~
jff
Reminds me of how I described C# to someone the other day: "If you really want
to write Windows programs, I'd rather do C# than the alternatives."

~~~
pjmlp
And with .NET Native even more so.

------
sqs
Here's an interesting portion of a Q&A panel from the same dotGo 2014
conference ([http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-
de...](http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-dependency-
management-design-philosophy))

Q: There are several dependency management tools in the wild: godep, gpm, etc.
Are there any plans to provide this functionality in the core?

Brad Fitzpatrick: We don’t want to dictate a policy, so we hope the community
fights it out and a victor emerges. Then maybe we’ll bless that one. Then if
everyone likes it and it has been stable for a couple of years, maybe we’ll
add it to the core.

Brad Fitzpatrick: Part of the reason why we don’t care as much about
dependency management inside Google is that we don’t use the go tool inside
Google.

Andrew Gerrand: The lack of versioning built into the Go tool incentivizes
library authors to provide good, stable APIs.

~~~
erikb
This is quite interesting, because after the Python fiasco in 2012/13 I
thought a new language like Go would have learned from that and done that
right from the beginning and I always thought Go did it. "We don't care" is
even worse than "we just don't know how, yet".

~~~
_ak
Different people have different requirements. It makes no sense to declare
some tool to be THE STANDARD(TM) if it's of no use for a large proportion of
their users.

The way $GOPATH works and dependencies are managed is well-documented.
Everybody is free to develop their own tooling. Right now, many people flock
towards godep, but that might change in the future. Also, since this is only
relevant during development and for compilation, getting it right is not as
important as if you had to deploy every single one of your dependencies. With
Go, you get one binary, and that's what you deploy.

~~~
ansible
And there are people like me who think that the programming language tooling
shouldn't have to be tracking dependencies. If, for no other reason, than it
is common to use multiple languages for a single project, and then a language-
agnostic method should be used.

I've leaned towards just having everything it our DVCS (git in our case).
External libraries are handled using git subtree.

~~~
erikb
It is also using a defined way to handle dependencies. I have no problem with
that either.

------
jgrahamc
This is a summary of a talk from the dotGo conference in Paris last week. Lots
of good stuff was presented there. Recommend reading the other posts by
sourcegraph on this and watching the videos when they come out.

[http://dotgo.sourcegraph.com/](http://dotgo.sourcegraph.com/)

------
melling
How about a better optimizing compiler? I've been using Go and everything
feels quite snappy. Justifying it use over Java on the server-side, for
example, might require a little more supporting data.

~~~
bradfitz
That's the plan, after the compiler is converted to Go and there's an internal
SSA form, etc.

Also, gccgo is a very good optimizing compiler but is held back by lack of
escape analysis, which I mentioned is being worked on.

------
kingmanaz
Regarding the article's mention of GopherJS: The Google Dart project should
adopt Go as its language and reboot. Dart hasn't gone anywhere. GopherJS is a
great low-budget transpiler and its source could be incorporated into a Go-
based Dart.

It would be great to see what could be accomplished with a big-budget
GopherJS.

~~~
lmm
The big advantage of Dart over JS is the type system. Switching to Go would
mean throwing that away.

~~~
nickik
PureScript and ClojureScript all have type systems better then the one in
Dart. The simplest ways to get a type system is TypeScript. Not sure how I how
it compares.

~~~
lmm
"Better" is subjective (and I certainly wouldn't consider any dynamic system
to be better than dart's) - Dart hits a certain sweet spot IMO, being simpler
than a typeclass-based approach but far more usable than Go or Java.
TypeScript is pretty nice but gradual, which is its own set of tradeoffs.

Dart has other selling points than the type system, sure, but degrading it to
Go-style types would be a serious loss.

------
higherpurpose
Go 2.0 should be highly optimized for Android (and as a potential _main_
language for Android) and should get even better ARMv8A support.

~~~
king_jester
Without generics I don't really see how that's feasible, since the Android
framework leverages that feature of Java so heavily.

~~~
codeflo
If this is the reason to finally add generics to Go, all the better, and a lot
of people puzzled by the community's copy&paste attitude to code reuse might
reconsider the language.

Also, this would require Google to finally polish up the Android NDK, which
would be great even for non-Go users.

------
hendry
Will there be a proper debugger I wonder?

~~~
ganarajpr
This is the highest and most important thing I want from go. A proper debugger
that is not insanely hard to setup ( on any machine! ). Gives a complete stack
trace and such info. I am not sure how people can live without a debugger in
2014. GDB is not the answer to this - for sure. There are soo many things that
can be done ( tooling wise! ) and this one is , I personally think, the first
things the golang guys need to do .

~~~
LukeShu
Why do you say that GDB is not the answer? In my experience, GDB (and DDD)
works great with Go!

~~~
ganarajpr
You are probably pretty awesome at setting things up. I am not. I tried GDB,
golang and windows as a combination and its an exercise in torture.

~~~
LukeShu
That's true, I am great at setting things up... but Go+GDB was _zero_ set up.
`go build` then `gdb ${executable_file}`, and nothing else. I suspect that
it's Windows being in the mix that gave you trouble?

~~~
lprez
In Mac at least you can't just do that, you need to create yourself a
certificate and sign GDB. Took me a while too.

~~~
module0000
Just an FYI, you can use MacPorts to `sudo port install gdb`, and it installs
gdb as 'ggdb' without the signing mess. To use with ddd invoke as `ddd
--debugger ggdb` and it works like a charm.

~~~
lprez
thank you!

------
niix
I've been writing Go for the past couple weeks and have really enjoyed it. My
day jobs is in JavaScript land all day long, and while I really love JS I was
looking for something more. Go has helped me think differently about how I
approach my code in JS now and continues to be a great source of knowledge.

~~~
mariusmg
With the risk of sounding like a asshole...if you only know JS any other
language will make you think differently.

~~~
Argorak
Given that the parent wrote that his job is exclusively JS, not that the
parent only ever learned JS or never had a job where this was otherwise:

I wouldn't have taken that risk.

~~~
alexyes
Have a look at this compiler from Go to JS. Could be useful
[https://github.com/gopherjs/gopherjs](https://github.com/gopherjs/gopherjs)

~~~
Argorak
Care to explain how that is relevant to the point at hand?

~~~
alexyes
Because we were talking about JS and GOLang. I'm not affiliated to whoever
created the compiler. I had found it on HN

------
robmccoll
Anybody up for backporting Go's stdlib to C? Doing so in an automated way
would be all the better.

There are just so many things in Go that feel like 80% solutions - they make
great demos but in every day use you have to fight them (looking at you import
system and the GOPATH, magical make() function, magical overloaded accessors,
lack of expressions or at least ternary if, pre and post increment are hacks
not expressions, lack of coercion to more precise types, no templating /
generics / preprocessing, needs an equivalent to realloc, having to go through
reflect / unsafe to get things done, lack of proper type resolution for
complex types).

There are many things I do like about Go, but much of the time it feels like a
very pretty prison compared to the (admittedly less pretty) freedom of C.

~~~
pjmlp
I rather use Go's pretty prison, than enjoy the freedom of buffer overruns and
dagling pointers.

------
schmichael
> GOTRACE: emits Chrome trace viewer and will allow for us to visualize
> scheduler actions and more in Chrome

I'm very excited about this, but I wonder if it will scale to visualize
hundreds to thousands of goroutines in a useful way. That's where existing
inspection tooling like logging and snapshotting goroutine dumps fall apart.

~~~
SeanDav
I see anything that ties Go to a specific browser as a bad thing. Surely they
should be browser agnostic if they want to encourage universal adoption of
their language (or perhaps they don't really care about this)?

~~~
groby_b
1) It doesn't "tie" Go to anything - it uses Chrome for visualization
purposes. You can write Go fine without ever touching Chrome.

2) Large parts of the trace viewer are separate from Chrome:
[https://github.com/google/trace-viewer/wiki](https://github.com/google/trace-
viewer/wiki)

3) The event format is documented, so you're free to write an alternate
viewer:
[https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQt...](https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/edit)

------
GFK_of_xmaspast
"at the time there was very little exotic hardware support (such as ARM). "

How is ARM "exotic hardware"?

~~~
AnimalMuppet
Remember that Go is coming out of Google, and therefore was initially run
almost exclusively on desktops and servers. For a desktop or server, ARM is in
fact exotic hardware.

------
bigtunacan
I see he mentions "beginnings of Android support". This is something I would
love to see. Does anyone know if there is a product roadmap that provides a
timeline on this?

~~~
pjmlp
This is a community driven effort to use Go in the NDK.

Android team only cares about Java as stated at Google IO 2014.

~~~
enneff
That's not true. The Go on Android support is being driven by David Crawshaw
who works at Google.

~~~
pjmlp
Thanks for clarifying.

Are you allowed to say anything regarding support from the Android team?

The way Android team spoke at Google IO, I got the idea Go will only have an
unofficial place on the NDK.

------
joe_momma
Android and iOS support!

------
trungonnews
Will Go ever get an interactive debugger that is comparable to Java?

~~~
module0000
Look at GDB or DDD+GDB, they are more full-featured than JDB, but do not have
the IDE integration and GUI-ness that you will find in Eclipse/Netbeans.

LiteIde for golang is the closest to the IDE+debugger combination you would
expect if you were coming from an Eclipse/Netbeans background.

