Ask HN: Do you see the future in Go? - watermel0n
======
inconshreveable
No, unless the language evolves substantially. I love Go. I've written a
fairly widely-used, large-ish application with it. Go shines in the following
respects:

1\. They got concurrency right. Writing ostensibly blocking code and letting
the runtime yield in the background is The Future.

2\. Implicit interfaces and formalizing "composition over inheritance" is the
right way to think about reusing functionality.

3\. Deployment is stupidly easy with zero-dependency binaries.

4\. The cross-compilation tool chain is dead simple. (excepting CGo)

5\. The tooling around Go's handling of code (godoc, go vet, go fmt, etc) is
_superb_. Enforcing a one-true coding style makes foreign code easier to
understand.

That being said, Go is missing the expressiveness that you expect coming from
higher level languages like Haskell/Python/Scala. In many cases, it is a
unnecessary step backwards on the thought-to-code spectrum. Not having things
like generics and list comprehensions makes my code more verbose and more
difficult to understand.

Certainly Go will evolve, although the authors often seem perhaps a little too
resistant to change. I suspect that Go's popular successor ten years from now
will have stolen Go's best qualities and iterated faster to include the
higher-level language niceties that we expect.

I have a longer blog post to expand on this later.

~~~
mseepgood
> I suspect that Go's popular successor

You mean a Go++, designed by committee with all language features known to man
thrown together, ranging from meta-programming to dependent types, trying to
please everyone, and as a result pleasing no one, and everybody will wish for
a simpler language?

~~~
qznc
It worked for C++.

Lots of C++ programmers do NOT wish for a simpler language.

~~~
yati
Upvoted. But personally, I (am a C++ programmer) would not use C++ wherever I
can make do with Python(which is orders of magnitude simpler).

------
6ren
Go is to C as plan 9 is to unix.

Not better _enough_ \- and no new platform to carry it unlike JS, Perl, Ruby,
Python, PHP, Java (web); Objective-C, Java (mobile); Java, Ruby, Python
(cloud).

The problem is that people don't like to switch. They'd prefer their present
tool to improve, and they'll support that. So the only way a language can
achieve ascendency is when users _don 't switch_. That is, new users. During
rapid adoption of a platform, a significant majority can be new users. And
that is the only time a new language can take over.

NOTE: it may appear there's an exception with flavour-of-the-month frameworks
etc, but this is a combination of rapid turnover of developers/projects in
specific areas, plus the enthusiast/techie kind of developers who _love_ to
switch (the ones always excited about the newest tech for its own sake, not
for its long-term practical benefits: think inventor, not investor). These
developers cannot form the basis of language's future, because they will
quickly switch to the next new thing.

~~~
nealabq
I agree that a new language has a much better chance of survival if it's part
of a new platform. And it's interesting to think about what exactly a
"platform" is in this context: an OS, a form factor, a VM, a scriptable tool,
a technology stack, a service, a sandbox, a consumer app, a game, new users, a
new industry, something that nobody's thought of.

But C++ suggests another path to language survival: present it as an "easy-to-
learn" (it started that way) superset of an existing language that addresses a
weakness. It's C! With classes!

------
pavlov
I see the present in Go. It's a language that's highly useful for solving
server software problems today.

The future may not be particularly interested in Go. It doesn't open
interesting new research avenues. If it becomes a proverbial "100-year
language", it's going to be the legacy mess that some poor soul will hate to
maintain in 2110.

I'm not going to be around in 2110 and I'm not a researcher, so I like using
Go.

~~~
trailfox
Static typing + type inference is a powerful combination. Go, Scala and Rust
are particularly appealing as the mix expressiveness with good performance.

------
Mikeb85
No, I don't see a future in Go. It's not going to replace C or C++ for
anything, and it's not going to displace Java. It's not fast enough to be a
systems language, and it's not as easy to use as a scripting language.

I personally see much more of a future with Rust, since it actually has a
chance of replacing C++.

~~~
kibwen
C++ no and Java probably not, but attracting a huge chunk of devs away Python
isn't just plausible, it's already happening. I fully expect Go to appeal to
anyone who's ever had reason to gripe about Python's GIL.

~~~
trailfox
I expect Go to take a large bite out of Ruby and Python and a nibble of of
Java.

~~~
kibwen
If you've already chosen Ruby over Python then you're probably a big fan of
the sort of expressiveness that Go eschews, so I doubt that very many Rubyists
will flock to Go. I expect Ruby devs who want speed and concurrency to make an
attempt at Scala first.

------
w_t_payne
Great for server-side apps. Configuration management is a breeze with its
single-large-executable approach. I agree with a lot of the design decisions;
and find it a nice language to work with.

It suffers a bit from the fact that dynamic languages like Python are (and
will always be) nicer and more productive for hacking around in when
performance is not a concern; and from the fact that you cannot (yet) beat C
for (single-thread) performance.

So, if productivity is everything: use Python, or your dynamic language of
choice. If performance is everything, use C (or C++, if you really must).If,
on the other hand, you want a nice balance between (good-enough) productivity
and (good-enough) performance, Go is a great bet.

I bet that in 10 years time, once the hype has died down, Go will be seen as a
middle-of-the-road language for middle-of-the road applications. A low-risk,
conservative, sensible, and ultimately boring choice.

Which is great, because that is _exactly_ what Go is trying to achieve.

~~~
threeseed
No. In 10 years time it will sadly be forgotten like many of Google's
experiments.

The low-risk, conservative, sensible and boring choice exists today. It's
Java.

And as enterprises adopt functional programming via Scala/Clojure it will only
cement those characteristics.

~~~
threepipeproblm
I dislike Google for pulling the plug on consumer products as well, but this
is a product designed for use at Google and I understand they are
writing/converting a lot of code in it. So I think you underestimate Google's
backing in this case, which is probably the reason Go has seen one of the
fastest rises in popularity of any language, ever -- if not the fastest.

Go has made me enjoy programming again -- I find it very freeing not to have
to use Java or .NET and memorize 40,000 builtin classes. Yes, Go is similar to
Java in terms of its being a "middle of the road" conservative language. But
(a)it's conservative for the 21st Century, rather than the 20th, and
(b)ditching the virtual machine and bloat of Java is a good thing IMO.

~~~
gngeal
I don't think it's the fault of the VM. There have been other languages that
worked with intermediate code, and they weren't inefficient. It's just that
fixing old stuff after you get millions of users leaves you with a very
strange language, even a stranger one than if you add completely new stuff
along the way. The latter is inevitable, but the former ought to be avoided.
The Java people probably didn't realize in the beginning what they were
building. (Well, of course, who would have, in their place?)

------
threeseed
I see it being useful for server utility apps. The sort of thing you might in
the past have done using Bash, Python, Perl etc. The barebones nature of the
language and the ability to package everything into a single executable is
incredibly handy for these use cases.

For everything else no. The JVM is going to continue to dominate for medium to
large apps with Scala and Clojure offering something new and original whilst
allowing for existing code to be reused. And for smaller apps it's hard to
look past Javascript.

------
solomatov
I don't see any future for it. Authors concentrated too much on "simplicity".

It's the language which doesn't have important modern language features, like
generics, and I won't ever use it unless these feature are added which is
highly unlikely.

Languages like Mozilla Rust seem to me to be a more adequate replacement for
C++.

~~~
mseepgood
Parametric polymorphism is not a "modern" language feature, it has been known
for many decades. When language designers opt against the inclusion of
generics in the year 2007, then you can be sure that they don't do so because
they are too stupid to see the benefits of "generics", but because they also
consider the downsides. Language design is decision-making in hundreds of
trade-off situations.

~~~
solomatov
> When language designers opt against the inclusion of generics in the year
> 2007, then you can be sure that they don't do so because they are too stupid
> to see the benefits of "generics", but because they also consider the
> downsides.

Authors of Java didn't include closures and generics despite the fact that
they were aware of them. They thought that these features are too complicated
for ordinary developers. Look what this lead to, we now have generics and
closures, but they made the language much more complicated and hacky than it
would be if they would have integrated into it from scratch.

~~~
mseepgood
The people who designed Java are not the same who "extended" it later on.

------
ams6110
Right now it's a fad. It will be proven or not over the course of time. But
realize that unless you write in something REALLY established like C or Java
you have a certain risk with any language will fall by the wayside in 5 or 10
years time.

I personally think that Python is starting to go the way of perl. It's
becoming more and more of a mess (perl was a mess to start with, but that was
actually touted as a benefit). The last python project I worked on had over 60
separate "pip" requirements, many with specific versions, and deploying on
anything but one specific version of one specific linux distro was an exercise
in pain. I realize that's just an anecdote but if python wasn't starting to
get uncomfortable there would not be so much buzz around Go.

~~~
fauigerzigerk
The choice between DIY and depending on third party libraries isn't exactly a
language problem, unless you're saying that a language that doesn't have many
third party libraries takes that choice away from you. I don't find that very
convincing.

------
Tichy
I kind of gave up on it when I realized how complicated it is to sort a list.
Hopefully they'll improve that in future versions.

Still could see myself using it for specific use cases.

But for the future I'd wish for something cooler to win :-)

Edit: check out the sort module and decide for yourself
[http://golang.org/pkg/sort/](http://golang.org/pkg/sort/)

It has some interesting, if confusing, properties. But why not just let me
write

list.sort(function(a,b){ return 1, 0 or -1...}) like JavaScript does?

While the examples in the sort module are perhaps more generic than necessary
(hence the interesting but confusing properties), any sort still requires the
definition of 3 functions, and they can't be defined inline (on the fly)
either, afaik.

~~~
gatestone
How is it complicated to sort a list? The only challenge is to provide a
corresponding swap function for your list (or for any ordinal "collection" you
need), like in this example for arrays, when it is trivial:

func (s Organs) Swap(i, j int) { s[i], s[j] = s[j], s[i] }

[http://golang.org/pkg/sort/#example_Interface](http://golang.org/pkg/sort/#example_Interface)

Also note two things:

\- This is the efficient and type safe way to handle polymorphism in Go

\- The standard packages documentation is very nice with live, runnable
examples

~~~
Tichy
But you also have to implement Len() and Less(), don't you?

Maybe you can create a better way, but it is not implemented in the sort
package by default.

Also I suppose you need to "convert" your list to some other type with the
said functions provided (dervied from the standard go lists, forgot the name).
Maybe that is a standard go mechanism, but it still amounts to more lines of
code.

Maybe complicated is the wrong word, longwinded might be better?

------
drtse4
Easy to use and learn, good standard library, it gets the work done.

Does it have a future outside google? I'd say yes, even in the enterprise
world, mostly in mixed architectures where it could be used to build a lower
layer that handles networking/transaction processing/jobs handling (replacing
python,ruby,etc...) while upper layers could be built with a functional
language (based on the jvm? clojure?).

------
iand
I think it will stand the test of time. The simplicity and explicitness of its
syntax means anyone can understand a Go program within minutes. That's going
to be a huge positive for code maintenance in situations where the original
application team has moved on and code has to be maintained by 2nd or 3rd
generation programmers.

------
Jare
I wish Go was not just a "server language". I know you can write command line
apps and there are opengl bindings and SDL and other GUI and client-y things,
but that side doesn't get enough attention and in my experience has been very
inconvenient (good luck if you're on windows).

~~~
rogpeppe1
You should check out github.com/niemeyer/qml

~~~
Jare
Yeah that's the most promising effort yet.

------
aldanor
I don't see much future in Go either -- unless Google takes some steps to
promote a certain niche for it like Android integration (which they most
likely won't).

Since someone mentioned Python here.. my go-to language has always been Python
lately, but large Python projects tend to often converge into a wtf mess; and
there's also all kinds of performance issues... I've recently (to my shame)
discovered D language which is kinda like C/C++ on steroids without all the
ugliness and verbosity, with a mix of Scala/Python. Type inference,
concurrency, first class functions/arrays/maps, runtime reflections, mixing,
templating, compile-time evaluation, it's got it all. Kinda like Go, it also
falls inbetween C++ and Python, but much closer to C++.

~~~
swah
Unfortunately I don't think Facebook will invest in D anywhere as much as
Google is investing in Go...

------
harel
Give it a go (excuse the pun). I did a small project using Go, and I was
surprised to see how easy it was to pick up and just roll with it. The syntax
makes it feel like you're writing in C and therefore your muscles harden
expecting direct impact and physical harm, but its all a rather pleasant
experience. So after trying it, reading other people's experiences with it and
seeing who is currently using it in production - I'd say its got a potential
of a bright future.

------
Zenst
Yes, pedegree aside it I see many old and new programmers loving it.

Now if I was Google I would be seriously looking at getting it into the
android ecosystem so people can develop in GO as well as C for low level
system codeing above the abilities of java on android.

That said I'm a shell prompt type of chap and with that somewhat biased and
blinkered in languages that you can code in vi. Certainly visual programming
interfaces will have there day one day. After all much code is down to string
libarys together and then stringing those functions/modules together until
your pretty much coding lego style using off the shelf bricks with rare
occasions of custom bricks being needed. That is still a way off from
mainstream acceptance and closest break out into mainstream would of been the
old mac card stack system (which was neat in its days though well dated now).

So methods and approaches to coding change over time and languages adapt and
some better designed to handle changes. C been good and the same could be said
for GO by definition.

But another way to look at this is what out of COBOL or GO will be around in
years from now and you then get down to the main crux - is it used in
production and needing code to be maintained and with that yes it is. Though
different area's and platforms GO easily available for and known are different
from COBOL (mainframe legacy bias) systems. If you asked a Linux dev to
install GO then they would just do it, ask them to do the same with COBOL and
they will be hitting google with a bewildered face. Yet both exist and are
available, just different mentalities keep them going.

------
cliveowen
If Google were to provide an Android SDK for Go I bet the usage would grow
exponentially and that would assure a bright future.

~~~
saljam
I see this request very frequently, but I wonder how feasible it really is.
The Android API is very Javasque, a 1:1 mapping to Go would just be unnatural.

Or are you suggesting they rewrite the API for Go? My knowledge of the
internals of the Java parts of Android is limited, so I could be wrong, but
that feels like a huge task.

~~~
jdiez17
Mapping a Javaesque (strange word, but I know what you mean) is not super
hard. Encapsulate the Java stuff as opaque pointers and provide a functions
that act on the objects. I actually think you could represent the Android API
as a Go API fairly elegantly, although it would require a fair amount of glue
code with some nontrivial hooks into the Go runtime.

------
optymizer
What I don't think has been mentioned so far is the Go Library. You get a lot
out of the box: encryption, archiving, web server, json/xml/etc, arg parser,
md5/sha1 hashing, templates, POSIX and trivial concurrency!

Channels and blocking until a result is ready is really a big plus.

Overall, I am very pleased with switching from Node.js to Go, but YMMV.

------
Baliw
I think a lot of people are beginning to see a bright future for Go.

Word seems to be spreading. There's certainly a growing interest.

[http://www.google.com/trends/explore?q=golang#q=golang&cmpt=...](http://www.google.com/trends/explore?q=golang#q=golang&cmpt=q)

------
behrendtio
I'd say go does have a future. I'm a long time php developer who switched over
to ruby a while ago and I've to say that go is pretty nice, even coming from a
ruby background.

The syntax might look weird in the first place, but once you get used to it,
it's actually somewhat sexy, given the fact it's compiled and statically
typed.

Since go has a very good solution for concurrency, compiling takes seconds and
it's already adopted in a few well known companies besides google (heroku,
canonical, shopify and more), I think it will gain even more traction (already
under top 20 languages on github).

Plus: The standard library is very impressive and huge. You can build many
different web apps and daemons without any external library involved.

I kinda miss class based inheritance tho.

------
yati
I think people will(I would) use Go more for writing services than doing
actual systems programming. It is a very nice language and I hope it succeeds,
but I am personally betting for Rust.

~~~
mseepgood
Depends on your definition of "systems programming". I personally consider
writing services (web servers, database servers, load balancers etc.) systems
programming.

------
miloshadzic
It's probably the best language for writing small unix programs. I personally,
wouldn't write very large software in it but obviously there's a lot of people
doing just that. It's statically typed with a rather simple type system and
doesn't do functional programming very well. Those things aren't appealing to
me. What it has is a great toolchain, fast compilation and is a lot like a
nicer C.

------
yeukhon
Do you see a future in Perl in 2006, 2007? Apparently people are taking it
seriously again (think DuckDuck Go). I can't tell but I think it has a good
promise. The language has been out like three years and many HN posts have
been on migrating to Go from X language. I probably will be skeptical about
Rust. It won't be stable for another year or two and the adoption will
probably be slower.

------
LocalMan
It's easier to evaluate the language than to predict human behaviour.

The language is very good and has excellent support and libraries.

People, though, are somewhat mysterious...

------
mortdeus
Im pretty confident that Go will be around for at least as long as C/C++,
python, and java remain relevant.

------
marcus_holmes
yeah, I do see a future in it. Love coding in it, it solves all the problems I
have without the learning cliff usually required. I think the direction for Go
is shown by the fact it doesn't have a UI library, but has a really easy route
to making web servers: it's a language for writing servers in, and html/js is
the UI. The only other language I can see threatening this space is Rust,
though obviously the corporate boys will carry on coding in Java and there's
always going to be a ton of old C/C++ code kicking around that needs
maintaining. But language choice is personal. I'm really enjoying coding in
Go, but I get why others prefer other languages. Diversity is good, we get
better results that way :)

------
neals
Have been using it as a tool for parsing and generating content for our game
engine. I can parse all the vertices and polygons in our entire game world in
under 22 seconds where our other toolchain required 10+ minutes.

We will be using GO in our toolchain in the future aswell.

------
tapank
Go lang will reach a tipping point when a good book becomes available for
newbies to learn this language. Yes, fewer programmers read books these days,
but a good book does get a lot of readers, and helps spur adoption of a
language.

~~~
latch
I've considered it, but I find Effective Go (1) a more than adequate
introduction. It's never been clear to me what I'd add on top of it. The
Little GoLang Book? Meh.

(1) -
[http://golang.org/doc/effective_go.html](http://golang.org/doc/effective_go.html)

------
pymonks
Can Go, the so called future systems-language be used for writing device
drivers ? if not why ?

~~~
qznc
Mandatory garbage collection.

So far, no mainstream operating system includes garbage collection and there
seems to be nobody who considers it a good idea.

(except the Oberon guys, maybe)

