
Why Go is doomed to succeed - dawkins
https://texlution.com/post/why-go-is-doomed-to-succeed/
======
vezzy-fnord
Go is doomed to succeed because it extends the mental model of C with a
concurrency model that finds a decent compromise between power and ease of
use, makes the typing less prone to subversion, adds memory safety via GC,
uses a structural subtyping system through interfaces that brings many OO-like
benefits while still keeping to the C struct way of thinking, first-class
functions, various syntactic rough edges cleaned up and so forth.

Because the Unix system programming world (and POSIX particularly) is very
much built with the conventions and semantics of C in mind, most serious POSIX
programming outside of C means you have to deal with painful FFIs, lousy
wrappers, overly abstracted APIs that hide details like certain lower level
flags and so forth. Some are better at this than others, of course (OCaml is
one of the better ones)... but, nonetheless.

So it's unsurprising that many infrastructure developers are jumping to Go.
There's just enough new things to incentivize a switch, but not _too_ much
that it dissuades from it.

~~~
tptacek
I'm a 90's C programmer and a Golang programmer now, and while there's some
truth to this, it's reductive. A 2000s-era C programmer would not write socket
code that worked the way net.Conn does. While C code gave us the "pipes and
filters" abstraction of Unix, they are not an idiom in C code --- in fact,
Golang's reader/writer interfaces feel more like a refinement of Java than a
modernization of C.

Golang feels very much like an offspring of Java and Python to me.

~~~
vezzy-fnord
Yes, Go has a heavy focus on interfaces and structural subtyping, as I said.
It reflects the trend behind Pike's languages: C-like + some form of CSP + key
abstraction.

But, even the net package has a noticeable Plan 9 legacy, like the use of
dial/listen, as opposed to the clumsy Berkeley socket way. You might recall
this was a central complaint of Pike's in his famous presentation "Systems
Software Research is Irrelevant".

Obviously it's nowhere near as pure as ndb, but that's the reality of being in
Unix.

~~~
tptacek
I certainly can't deny the Plan9-ism.

------
Animats
It's very clear what Go is for. Go is for the kind of stuff Google runs on
their servers. C++ is too complex, too unsafe, and too hard to maintain, and
Python is too slow. (Remember that "slow" at that scale means "we have to add
another acre of servers.")

Go is an OK language for server-side stuff. It's not perfect. The concurrency
isn't as airtight as its proponents originally claimed. Reflection and type
"interface{}" tend to be needed too often. Other than that, there are few
killer problems with the language when doing server-side stuff.

The libraries for doing web server type stuff are available and well debugged.
When you use a Go library that came from Google, you're probably using code
that's executing a few million times a second on Google servers. (As I
mentioned on here a few months back, I recently ported a medium-sized
production Python program from Python 2 to Python 3. I found library bugs
which would have been found long ago were the code heavily used.)

So yes, Go is doomed to succeed. That's not a bad thing.

As for Rust, while I like Rust personally, it may be too complex. The borrow
checker concept is brilliant, and a huge advance in understanding how to avoid
a big class of bugs. We'll see that again in future languages. The type and
generic system, though, pick up where C++ left off, and seem to lead library
developers to develop very complex interfaces.

Rust is for people who debate language semantics on Lambda the Ultimate and
program in Haskell for fun. Go is for people who have a job to do.

~~~
pcwalton
That last paragraph is ridiculous. Name one feature in Rust that you think is
too much complexity and I'll tell you where I need it _to get my job done_ in
Servo.

Without generics and traits, for example, there would literally be no reason
for Servo to exist, because it would be too slow. Performance is _not
optional_. Safety is _not optional_. They are _my job_. If I opposed language
features that are needed for competitive performance or safety on the grounds
of complexity, _I would be failing to do my job._

I'm responsible for a lot of Rust's features. I have never posted on LTU, and
I've never written more than 50 lines of Haskell. I find most of the Rust
community's philosophical language debates tiring and pointless; languages to
me are tools, not philosophies. The entire core team is largely with me here.
I think you have a deep misunderstanding of the language design if you believe
Rust has features "just because".

~~~
mentat
I don't read his/her criticism that way. It's that users of Rust tend to make
over complex systems.

~~~
kibwen
Can you provide an example of Rust users making overly-complex systems? Rust
is a systems language, and systems themselves have intrinsic complexity that
language designers must either choose to ignore or tackle. Scripting languages
have the luxury of removing complexity by ignoring systems concerns so you
don't have to care that your language is, say, copying strings around like a
maniac behind your back. But somebody has to compete at the bottom of the
stack, and while you can still seek ergonomic wins there's an enormous amount
of essential complexity that can't be abstracted away.

------
spopejoy
Go succeeds because Google's behind it.

Go certainly doesn't succeed because of smug/boring articles like this one.
The potshot at Erlang early on (also cf. slurs on Rust and Haskell in some of
these comments) betrays the same old "we like it here in our cave" bias of Go
boosters whenever confronted with its glaring warts.

Go is a great choice for certain workloads, is reasonably fun to code in, and
has great doc support on the web. I suspect however it's popular also because
it _isn 't_ FP and doesn't favor immutability. It plays well with the haters
who refuse to understand how good GC/list fusion/stronger types/better
abstraction can make code _easier_ to understand and _way_ faster.

But the bottom line is no Google, no Go. Just like no Sun, no Java. It's
simply unbeatable to have a mega tech corp paying folks to write docs libs and
patches. But it doesn't save it from being yet another turing tarpit.

~~~
freyr
Right, Google just needs to will something to succeed, and _poof_ , the world
rallies around it. Like Dart, and Google Wave, and Google+, and Google Glass,
and Google Answers, and Google Buzz. It doesn't matter if it's good or bad,
because if it has Google's stamp on it, it's destined to be a wild success.

Certainly, having a big corporate sponsor doesn't hurt, but it's clearly
neither a necessary nor a sufficient condition.

~~~
seanp2k2
Yes, but Go solves a real problem for many people and isn't attempting to turn
a profit. I wonder when it would be at the point where it could sustain
relevance without further funding.

------
gamesbrainiac
> TL;DR Golang was explicitly engineered to thrive in projects built by large
> groups of programmers with different skill levels, and there is no larger
> such group than the open source community.

Very true.

This article hits the nail on the head. Most people say that they cannot
"express" certain things in go, or have to jump through hoops to do it. The
point of go is not to create a highly expressive language, but rather to
create one that has a high enough abstraction to be productive but simple
enough so that people coming from different backgrounds can acquaint
themselves with it quickly.

In other words, it is a language for teams.

~~~
bkeroack
I would word it slightly differently--in Go you are free to express yourself
in exactly one way: the idiomatic Go way. Anything else will be painful (a
good clue is if you find yourself using reflection frequently).

~~~
tptacek
That's true, but it's also (sometimes) liberating. In extremely flexible
languages, you can find yourself burning lots of time finding the most
"elegant" way to express simple concepts, like "how am I going to write this
SQL column to this series of DIVs".

Not coincidentally, Golang sucks at this problem.

But there is something about writing in Golang that makes it easier to dive
into meatier code. For instance: I've written programmable assemblers in Ruby
and in Golang. With Ruby, I kept refining the assembler until the DSL looked
identical to normal X86 assembly (I even hooked the bracket operators to make
them behave like dereferences). With Golang, I quickly moved past the
assembler into an IR and a compiler.

~~~
danieldk
_With Ruby, I kept refining the assembler until the DSL looked identical to
normal X86 assembly (I even hooked the bracket operators to make them behave
like dereferences). With Golang, I quickly moved past the assembler into an IR
and a compiler._

Same experience here. I am working on a neural net dependency parser and
pretty much started C++ and Go implementations in parallel, because this was
one of my first larger Go projects and I had my doubts about using Go for
this.

In the meanwhile, the Go implementation is a complete and fast parser (the
number crunching is done using OpenBLAS via gonum), which I now use for
research. In C++ I am still tweaking the abstractions for the basic stuff
(word embeddings, transition systems). Of course, I could make a simple,
straightforward implementation in C++, but the language encourages you to
finetune the abstractions and you have to the choice between template-
heavy/light code (with its respective downsides).

I also found that Go encourages me more to break stuff up more in different
packages. In C++, every separate library means new build machinery, some way
to roll it out on systems, etc. In Go it's as simple as creating a new
repository and adding imports.

------
latch
I'm a fan of Go and have been using it for a [relatively] long time across
various large and small systems.

I really like it.

To me, what's been abundantly clear is that: it's a horrible choice for types
of apps a lot of people are using it for. Specifically, systems where
ror/django/express/php have traditionally excelled at. I'd say "CRUD", but
that's too narrow. The expressiveness and productivity of dynamic languages
continues to awe me. This is particularly true for web systems that, on one
end, deal with the object-relational mismatch and on the other transforms and
outputs json or html.

Go's great, but it feels like we've forgotten some of the pain-driven lessons
Hibernate and their ilk taught us.

~~~
jjawssd
Please tell me more about the pain-driven lessons Hibernate and their ilk
taught us

~~~
latch
We learned that you can't configure your way out of impedance mismatches. You
can certainly make your life easier, but only at the cost of also making it
harder.

You essentially need language-level support for dealing with data at your
boundaries. Even with Java's strong reflection (Go's reflection is horrible)
capabilities and generics (and C# extending that with lambdas and expression
trees), there's still tremendous friction and boilerplate configuration and
code.

Consider Dependency Injection, an ilk. In most (all?) dynamic languages, DI is
a language concern, as opposed to a library concern. By having support for it
within the language, the problems DI frameworks attempted to solve in Java (or
C#) via messy configurations, legalese-like unit tests and quantities of code
dedicated to nothing but the infrastructure of the codebase, simply vanishes.
Now people are going to Go and discovering the awesomeness of interfaces.

------
coldtea
> _To understands why Go is the way it is you need to know why it came to
> exist in the first place: "The goals of the Go project were to eliminate the
> slowness and clumsiness of software development at Google, and thereby to
> make the process more productive and scalable. The language was designed by
> and for people who write—and read and debug and maintain—large software
> systems. source"_

The problem with this idea is that, for the exact same goals, there could be a
much better design for the language and much better implementation of various
details.

You don't need to be Haskell or anything. Just Go + generics for example would
result in a much cleaner language (no special casing for things like "make"
for example), a vastly improved code library and data structures story, etc.
This horse has of course been beaten to death (including by people working
extensively with Go, so it's not like some "outsider's misconception" as some
dismiss it).

If Go succeeds is because noone else with the same kind of visibility and
resources tried to compete in this space (easy concurrency, static builds,
fast compiles, static, fast-ish, decent batteries included etc).

You have e.g. Rust which is incomplete and too complex, Nim which is too
niche, from very small vendor (a guy) and has some bizarro ideas, and that's
pretty much it. That said, Swift might make a dent in this area when its Open
Sourced if it has nice tooling.

~~~
pcwalton
How is Rust incomplete and too complex (especially "incomplete")?

Compiler-enforced-correct manual memory management may not be the right choice
for every project, of course, but I think "too complex" is too strong of a way
to say that. That implies there was a simpler way Rust could have achieved the
same goals, and I've never seen anyone suggest one that works.

~~~
coldtea
Well, it's a very common complaint (and I found it to be true when I tried my
hand at Rust) that the lifetimes and general scope management can make your
life hard -- and certainly harder than conventional GC languages. Rust, as a
core language, has a lot more concepts to grok compared to Go or even Java.

As for incomplete, I mostly refered to the tooling and the available library
ecosystem. Even Go lacks there, and Go is an order of magnitude better there
than Rust. That said, despite the recent 1.0, the language is also heavily
worked upon in several aspects (internals etc) and it doesn't seem that it's a
"complete" offering that just happens to do incremental improvements, but a
"we got an 1.0 out of the door, but we've got work to do to make it more
mature".

~~~
pcwalton
> Well, it's a very common complaint (and I found it to be true when I tried
> my hand at Rust) that the lifetimes and general scope management can make
> your life hard -- and certainly harder than conventional GC languages.

Yes, there is more of a learning curve, but I think that's a problem with
manual memory management in general. To me, that doesn't mean that the
language is "too complex"; rather it means that the space Rust is playing in
(and which those other languages are _not_ playing in) is complex.

> As for incomplete, I mostly refered to the tooling and the available library
> ecosystem.

I've never found Rust lacking in tooling, with the notable exception of the
lack of rustfmt (which is being worked on by Nick Cameron and others). I use
native profilers and GDB with Rust almost every day, and Cargo is getting
pretty mature. The library ecosystem isn't very mature yet, sure, but I
wouldn't say that makes the language incomplete.

~~~
pjmlp
For many of us a complete language means the whole lot, e.g. IDEs, visual
debuggers, a library for any use case, books.

This is most likely the why of the incomplete remark of the OP.

------
coldtea
> _Many critics I find though, fall into the second bucket. The answer to
> those critics is always the same: “Go is just not for you”. Some people see
> this attitude as stubbornness from the community, aversion to improve which
> will doom Go in the long run. They just don’t realize that some people want
> different things._

This trivializes all critique to "to each his own".

That some people "want different things" doesn't mean all things people want
are equally valid.

------
pron
Go seems to be attracting a lot of developers from Python, Ruby and Node
because Go offers them the easy path to getting started that they place a
premium on, combined with speed, but relatively few people from the order-of-
magnitude-larger JVM world. Coming from Java I like that there's a very
similar language that I can use for command line applications (a JVM sore-
spot) or a simple daemon -- both because it doesn't require warmup and can be
delivered as a single native binary -- but I just can't think of giving up the
JVM's deep monitoring, low-overhead deep profiling[1], polyglotism[2], dynamic
code loading and hot-swapping, and the awesome hacking power that comes with
runtime bytecode manipulation[3] for long-running, important server
applications.

[1]: Java Flight Recorder is the most powerful low-overhead profiler I've ever
seen.

[2]: We use Java, Kotlin and Clojure all in the same project.

[3]: The ability to inject ad-hoc tracing code into your server and then take
it out -- all while the server is running at full speed -- or to shadow binary
dependencies so they don't clash, or to use (or write) a time-travelling
debugger is like having magic powers. Bytecode manipulation is ultimate
hackability.

~~~
dsymonds
It's not hard to find people switching from Java to Go (e.g.
[http://www.infoworld.com/article/2608571/application-
develop...](http://www.infoworld.com/article/2608571/application-
development/article.html), which I found within 10 seconds of searching).

It's true that Go doesn't have a lot of those powerful JVM features that you
listed, but as with any engineering trade-off there are lots of people who
judge the benefits of Go to be worth the loss of those things.

~~~
pron
Of course there are people making the switch, but the numbers are not nearly
as substantial at as people switching over from scripting languages (even in
nominal figures, let alone percentage) -- which perfectly makes sense.

You'll also note that since that article was published, all the advantages
listed in in it have either found their way into Java (lambdas, fibers) or to
other similar languages like Kotlin (multiple return values). Go has the
undisputed upper hand when it comes to command-line apps (I really like it
that I can use a language so similar to Java for stuff I never liked using
Java for, and I was never fond of using scripting languages that require
tedious dependency management for standalone programs), but is at a
fundamental disadvantage when it comes to long-running important servers.

~~~
vorklerta
Go is particularly well suited to long-running critical server apps. It has
fewer GC issues compared to Java and is also simpler language (making it
harder to screw things up - Java generics can get very complex).

~~~
pron
> It has fewer GC issues compared to Java

No, it has more GC issues. It's just that there aren't yet enough libraries
and big applications to make that apparent. It hasn't been stressed enough
just yet.

~~~
pcwalton
I think it's likely that Golang apps _won 't_ stress the GC as much as Java
does, because of the simple fact that you can't realistically use j.u.c-style
concurrent data structures, since you don't have generics. Where the JVM GC
really shines is when you're using shared-memory concurrent data structures,
which are really great things—however, without generics, programmers just
won't use them in the first place.

(I'm not saying this is a negative for Java, BTW; making shared memory data
structures both fast and idiomatic is really important if you care about
performance of parallel code.)

~~~
pron
Why do you think generics are more relevant for concurrent data structures?

~~~
pcwalton
Because "programs don't need more than one type of dictionary, so the language
can just hard code one implementation in" is at least a defensible position in
a single-threaded setting (although I don't agree with it), but it definitely
isn't in a scalable parallel setting.

~~~
justthistime_
Yeah. Go. The concurrent language with a single, mutable, thread-unsafe
dictionary implementation.

------
xyby
Without a definition of "succeed", this cannot be argued against or agreed to.
Like every other language, Go will be used by some people and not used by
other people.

~~~
billsix
I believe "doomed to succeed" is a reference to language evolution and
popularity; discussed by the Haskell community

[http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.schem...](http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.scheme/2009-04/msg00162.html)

------
modulus1
Go's success has me confused. My team enjoys using Go, but to me it feels like
i'm a prisoner. The designer's slavishly followed opinions are laser focused
on reducing variation across go codebases. There's definitely less to learn
than most languages. Unfortunately, sometimes the blessed way of doing things
doesn't work well for your problem and not only are you left with a hammer to
cut the wood, but making a saw is outlawed.

~~~
api
The article hits on this but doesn't bring up Google's high turnover rate.

Google is a resume tick box. Go over to AngelList and look at lists of
startups. Take a drink every time you see 'worked at Google' listed as a
qualification. You'll be destroyed in an hour or so.

Thus people get jobs at Google, put in a year or two, and go off for a higher
paying and/or sexier job or a startup of their own.

Go is laser focused on simplicity, maintainable code bases, and uniformity to
allow the next crop of Valley recruits to pick up where the last crop left
off.

~~~
tptacek
If this was true, and not a just-so story, then it should be easy to point to
several well-known open source projects that started out in Golang and ended
up in some other language, or several concepts that were prototyped in Golang
and then ported over to some other language.

Like every programming language ever, there are surely many Golang users
who've used it solely to add a keyword to their resume. That's not a very
interesting observation, because the same thing is true of Rust, Scala, and
even Haskell.

Further, that doesn't really address the question of why so many teams select
Golang in the first place. A programmer might use Golang to get the keyword on
their resume, but a team shipping a new product has no such incentive.

~~~
justthistime_
I think people who use Go in the first place are not those who think much
about "can this be done in a better way?".

It's quite similar to the notion of "I'm a PHP developer and I don't
understand why everyone says it is terribly designed! I learned to work with
it and never tried anything else, so it can't be that bad!!!".

Not every developer cares about software development. There are plenty of
people who chose this profession after they heard that a random developer can
become the next Bill Gates by writing the right iOS app.

Having a language which doesn't require an inexperienced and non-interested
developer to reflect on all the lessons learned in the last 40 years of
software development and computer science fits the bill of this kind of person
pretty well.

Sure, he/she is missing out on 4 decades of improvements to this profession,
but who cares? Despite all the medical advances, there is still an economic
niche for quacks selling "cosmic crystals" to cure your cancer.

There is nothing wrong with this. People don't pick a job in finance, because
"they like to work with numbers" either.

We should just be aware of it.

~~~
NateDad
Your argument seems to rely on go being the first language someone has
learned. Very few people learn go as a first language. Most people I know in
the Go community have 10+ years of professional development experience in a
variety of the popular imperative languages and have used go for a couple
years. I'm sure there are probably some people learning go as a first language
by now, but I doubt it's a significant number.

So, "not knowing any better" is kind of ridiculous.

~~~
justthistime_
There are plenty of people out there which didn't manage or didn't need to
advance beyond their first-year experience for the last ten years. "What did X
do?" is a much better question than "How long did X do it?".

(For many jobs one year of experience is perfectly fine!)

I think people who can think critically and evaluate various options rarely
join personality cults, which kind of explains Go's current community.

------
dawkins
"Go won’t let you abstract yourself in the foot." :)

~~~
jamesfisher
What a strange idea. The whole point of a programming language is to enable
abstraction. I suppose assembler doesn't let you "abstract yourself in the
foot" (whatever that means) either.

~~~
Artemis2
There is such a thing as too much abstraction. That's partly why Java has now
that huge reputation of being a very enterprisey language.

~~~
stass
That is actually due to a lack of rich abstraction mechanisms in Java.

------
fauigerzigerk
_> TL;DR Golang was explicitly engineered to thrive in projects built by large
groups of programmers with different skill levels, and there is no larger such
group than the open source community._

I think this premise could not be more wrong. The open source community is not
a project team, and open source project teams are very likely much more
homogenous and stable than teams working on commercial software.

Yes there may be non core contributors, but if contributions are not up to
standard, they are simply rejected. If that means slower progress an open
source project can live with that. A commercial project can not, because it
has deadlines.

------
hyperpallium
It's an interesting language test, of how easy it is to understand an open
source project.

Looking at github, the lines of code are usually easy to understand in C and
java. What's difficult is how the parts of the project fit together (which is
_never_ documented). Does Go help with that?

~~~
dsymonds
I think it can help with that in the sense that Go packages don't have complex
boundaries and the type system is simple and self-contained. You don't have to
trace an inheritance hierarchy to understand any given type, so a project of
multiple packages is generally easy to understand just by reading each piece
independently.

~~~
hyperpallium
Inheritance can be a problem, but I was thinking more of the architecture,
what calls what, who is in control, where are the various tasks done, what are
the interactions... I'm not sure how a simpler type system would help with
that e.g finding out which module does the task of interest, but I don't know
Go.

[ Design patterns were supposed to help with this, with recognizable groups of
classes. Sounds like a good idea, but I haven't found that, but maybe I don't
know them well enough, or projects don't them well enough. ]

------
orian
Isn't the issue that people who generally like Go read and write articles like
this? ;-) The same is said by PHP devs:)

~~~
slapresta
PHP has (sadly) already succeeded.

~~~
leoi11
yet I doubt that if doomed to success has anything to do with doomed to
succeed forever

------
sapek
Whether you like Go or not depends on whether you think of software
development as engineering or as craft.

~~~
rwmj
More like "... whether you've used any more modern languages than C" (such as
ML and many other functional and research languages).

~~~
4ad
I have used SML, OCaml, Haskell, and many other languages, and I like Go, and
use it for almost anything I do these days. So your statement is false. The
only thing I did like more in functional languages was writing compilers
(which ironically happens to be what I'm doing now in Go).

~~~
ngrilly
What kind of compiler are you writing? For which language and target?

~~~
4ad
For Go and sparc64, I did arm64 before.

~~~
ngrilly
You did the work to compile Go to arm64? Thanks for that then!

~~~
4ad
Yes I did, welcome!

------
gtrubetskoy
Compiled to native binary, garbage collected, no JVM and not object oriented
is why I like it.

~~~
nobullet
What's wrong with JVM?

~~~
rifung
Someone correct me if I'm wrong but I think not using the JVM makes
deployments much simpler. At least that was one of the benefits a team at
Amazon stated about switching to Go while I was there

~~~
icedchai
In practice, it doesn't make much difference.

You install the JVM once and rarely upgrade it.

You build and distribute your Java apps as fat jars (meaning, all dependencies
bundled.)

~~~
rifung
But what happens when some of the apps require different versions of the JVM?

~~~
bitmapbrother
As long as you're using the latest version then this shouldn't be a problem as
the JVM is backwards compatible.

~~~
tacticus
Except on those fun occasions when it isn't really. :\

------
DubiousPusher
I highly recommend replacing any occurrence of, “Go is just not for you”, with
"Go is probably not the right tool for what you're trying to do."

The former can seem, snide or condescending, even when that is 100% not the
intent.

I write both C++ and C# frequently. I love both languages. But I deal with
people who use either language exclusively and continually gripe about the
other. And the proper response is, "it's probably just not the right tool for
the thing you're trying to do."

------
vorg
> _accept that they won’t change anything. The Go team has said time and again
> that the language is done for the foreseeable future. You are too late to
> the party. Some might cry about this, but this stability promise brings more
> long term benefits than any language improvement could. Breaking changes,
> even if for the better, are not always welcome_

The promise of stability from a large software corp puts in place a solid
language foundation people can rely on when building apps in the language.
Someone building a successful app using the language shouldn't be able to
dictate future changes to the language based on their own needs only, ignoring
smaller or less popular apps. Golang's language spec is a big help with this.

When you've tried working with a language whose backers cancel work on a spec
for 10 years, then tailor the language's functionality for the one application
they themselves are building, you appreciate the promise of stability. When
the language's backers open up their AST to programmer addons via annotations,
then later duplicate the functionality of the most popular addon, you
appreciate the backing company's understanding that long term benefits come
from nurturing the community.

When you see a backing company suddenly retrench all the staff working on a
programming language, you appreciate that Google is using Golang internally
and is unlikely to do the same. Although Golang was born of a Google internal
need, let's hope the needs of their own systems won't dictate future changes
_at the expense of_ the external community, and that they keep their stability
promise.

------
aroman
> Go won’t let you abstract yourself in the foot.

What a brilliant sentence.

~~~
sunstone
Abstraction if necessary but not necessarily abstraction.

------
BuckRogers
"TL;DR Golang was explicitly engineered to thrive in projects built by large
groups of programmers with different skill levels, and there is no larger such
group than the open source community."

This would almost be right, but Go has much poorer language interop than C due
to the GC and non-C compatible ABI. This means unless we're going to a
monoculture of GoAllTheThings (not likely), Go will never succeed C as being
the basis of fundamental open source community projects.

For myself, I was and remain mildly interested in Go as my next move off of
Python(2). And still believe Go is a better move than porting to Python3-
which as an aside makes no sense technically, but the coercion/threats from
the Python3istas are beyond reproach (as if the existing Python2 community is
the problem), and set me solidly against it. Of this new generation of
languages, Swift was always my ideal. Both in language and implementation. Now
that it's going to the server I can't help but find the attraction of
serverside Swift and getting in on the groundfloor of that ecosystem. While
gaining skills in the language of iOS to be irresistible.

Count me in as one eager for Swift 2.0. I believe Swift is the language that
is doomed to succeed.
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

~~~
chadscira
Swift has an interesting situation. Within 6 months of its beta release it was
already being used to publish iOS & OSX apps.

With it also being open source, and ported to other platforms I can imagine
other mobile operating systems also embracing the language in hopes to get
more developer traction.

Not to mention that they have taken a little from every language, and server-
side swift is a whole different beast.

This is going to be fun ;)

~~~
BuckRogers
Yes sir. And I'm no "Apple guy". My first computer was a Commodore64, and I
own no Mac. Never have. My only Apple products in my lifetime has been 1 iPod
Nano, an AppleTV2 (only for jailbreaking/XBMC) and 1 company iPhone 5S (after
5 years and 4 Android phones, some personal, some company, all running
CyanogenMod when possible).

I hate how languages like Go get lumped in with "Google", an association which
to _me_ , is negative. For many, people fawn over Google, thinking a for-
profit like Google does things in their best interests. When in reality it's
temporarily mutually aligned interests.

I'm at the core if anything, a Mozilla guy. Not entirely because I'm not too
diehard on the JSAllTheThings movement. I strongly lean towards native, even
if my work consists mostly of Python2 backend for webapps. At least with
native executing code it's _possible_ to be open source. You never know what's
executing serverside. So I'm less of a fan of the so-called "open web" (an
oxymoron) than most. And that's discounting the difference in end product that
exists between native/web. I like my web to be it's original intended usecase-
such as how HN is. Nothing too fancy, data sharing.

I think from a language/implementation standpoint that Swift hit it on the
money. That's what I would have wanted out of a Python3. If that were Swift,
I'd be a huge fan. Swift just nailed what I believe people are really looking
for. Go is a little sketchy in ways. I don't hate it, don't actively work
against it as I do Python3... well, can't say I work against it but I don't
extoll its technical churn. But Go at least is trying to solve a real problem,
and solves more problems than it creates. Even if I think it squares up
against Java more than it does C or Python.

Unfortunately, Swift is associated with Apple which has its own zealots (and
zealous haters). It's regretful that programming is now fashion, hype, trend.
But I do think they have the best-of-breed language here for general purpose
use.

My money and personal contributions to these new wave of languages will
definitely be to work on server-side Swift solutions. The thought of a single-
language solution with a single GOOD language from backend to front if you use
iOS is pretty amazing and I'm really looking forward to that, and Swift
backend / web frontend as well.

------
fishnchips
Although Go was initially marketed as systems language it more often than not
eats into Python's market share rather than C++ or Java's - at least in all
places that I've seen it 'in the wild' (eg. saw that 1st hand at Google, read
about that at Dropbox). Coming from professional Java or C++ development Go
feels lacking but it feels like an incredible power-up when it replaces a
piece of Python (or Perl, or Ruby, I guess...)

------
_pdp_
I am not quite sure I agree with this article. It's like saying that C wont
succeed because it lacks every single feature that is available in modern
languages (I am not talking about C++ and above).

Go was designed to create low-level stuff with high-level language and it does
not need features beyond that. It has enough features to satisfy some extreme
low level tasks. If you want high-level programs then write them in your
favourite scripting language. I prefer coffescript due to its expressiveness
but I realise that t is not everyone's cup of tee.

However, for low-level programming and where I know static compilation and
performance is a key, I will go with go. Why? Because it will take me 10 times
longer to do it in C. And although I like C, I will not kill myself to use it
unless I am really have to.

P.S. my company has done some amazing stuff with go, docker, fleet and coreos
in a very short time. I have no doubt it would have taken us much more time if
we had decided to use something else.

------
jubei
Is there any "best practice" Go, especially in terms of architecturing apps? I
come from a long php background, and spent the past 3 weeks learning and
prototyping a Go project. Looking at my code, I definitely have "open source
stage fright". Any links/advice/books appreciated.

~~~
NateDad
Gofmt your code. Run errcheck, golint, and go vet, and make sure they don't
complain. Run go test -race and make sure it doesn't complain.

The best Go code uses built-in types and small interfaces in its APIs. Use
interface{} as a last resort, and then only if your function can really take
anything. Don't overuse channels. Sometimes a mutex is more appropriate, and
that's ok. Rarely use reflect. Don't panic except during package init. Never
ignore errors. Don't try to make your Go code conform to the way other
languages work. Magic is bad, don't try to make your code magical.

The go community is quite nice in general (there are bad apples in any group).
Show off your code, it's the only way to learn, and chances are you'll get
some good review comments at least.

------
ilurk
I'm curious about two things.

(1) where does Rust fit in this?

(2) and if Go is lacking in the concurrency department and loses to Erlang in
latency. Why don't people use Erlang/Elixir for servers and Python/etc for
client side?

~~~
davidw
> Why don't people use Erlang/Elixir

Because Erlang is _different_. It's not just the syntax, even though that
throws many people uncomfortable with much that's not a direct descendant of C
syntax; it's the whole programming model which requires a real shift in
perspective that simply isn't easy.

It's worth it once you start to "get it", but that can take a bit.

I do think Elixir gives the Erlang VM a better shot at the big time, because
it lessens the syntax obstacle for many people.

~~~
bostik
> _Because Erlang is different._

I'd say that fails to capture the full scope of the statement.

From where I stand, Erlang is not just a language - it's an extremely robust,
highly opinionated event loop with its very own DSL.

~~~
ngrilly
> an extremely robust, highly opinionated event loop with its very own DSL

It's very reductive. Erlang is a distributed platform with a functional
programming language, lightweight processes communicating through distributed
asynchronous shared-nothing message passing, preemptive scheduler, etc.

------
istvan__
This is a very light article with not too much information. Go already
succeeded simply because Google uses it. This means all of the problems they
need to solve in Go has decent support (net/http etc.) and you can just use in
your own projects, and this also means that the out of the box performance is
decent. These are good enough reasons to use Go. If you are talking about
language features I don't think that Go is that amazing. Supporting CSP is a
big win though.

------
andyidsinga
this:

    
    
      > Go won’t let you abstract yourself in the foot.
    

aside from being amusing -- I like this, but can anyone confirm its true in
practice with Go?

~~~
NateDad
The lack of generics (and operator overloading and type hierarchies) makes it
hard to write grandiose frameworks and all but impossible to write DSLs. I
consider this a good thing. You're definitely pushed in the direction of
writing straightforward, no frills code that uses boring types with little
magic.

------
framp
A language success is largely determined by marketing. Go will succeed because
a lot of brilliant people are using it and it's not bad. That's exactly why
node.js is where it is now, and PHP was cool back in the days.

That said, I'll just leave this here:
[http://yager.io/programming/go.html](http://yager.io/programming/go.html)

------
charlieflowers
God, this is a beautiful turn of phrase: "Go won’t let you abstract yourself
in the foot."

------
mshenfield
I don't quite buy that a pretty low level language reduces developer fright.
In my mind Go is a replacement for C more than the next Python. In that
respect it is still intimidating for developers who have never done or done
very little low level programming.

~~~
dwc
I friend of mine who has dabbled in C for years is still pretty scared of it.
He loves Go. He's gotten Go into production where he works. I think there are
a lot of people like him.

------
0xdeadbeefbabe
Plan9's failure payed the karma points for go's success. Duh.

------
stox
Go is simply the follow on to Limbo. It is the product of many years of
experience supporting the construction of large systems. Most of its roots are
from Bell Labs.

------
justinhj
This article seems to suggest that Go was designed as a language for large
teams. Firstly it was designed as an research project and secondly I don't
think it does work for large teams.

The simple type system and lack of genetics makes code verbose. The dependency
system seems to require everyone is on the bleeding edge, correct me if I'm
wrong. The channel based concurrency is very elegant but appears to be too
coarse grained for high performance programs that would otherwise use it.

That said I like the languages simplicity and do think it has it's uses in the
world. Just not large team, large project development.

~~~
Artemis2
Go is not about research in the sense of inventing new things. The holy
designers of Go (Ken Thompson, Rob Pike, Russ Cox) have clearly stated that Go
only borrows from other languages (C, SmallTalk...). The goal is not to
reinvent the wheel in a new, confusing language, but rather to put together
parts that have been thoroughly tested. They make sense together and the
result is a boring language that is made to be used.

------
shmerl
To put it roughly, Go was made to appeal to Java developers as a better Java
replacement. In contrast Rust was created to appeal to C++ developers as a
better C++ replacement.

------
Dewie3
Maybe these _programming in the large_ languages don't necessarily have to be
fantastic for programming in the large, and in the long term. But they have to
be great for this at least in the short term. So imagine that such a language
shows itself to be good for making medium-scale applications in the first year
(assuming that large-scale applications take longer to become "large-scale").
The code is uniform, people can easily get up to speed with whatever section
they are working on, there are no _big_ surprises - great. This language gets
adopted in more projects because of the initial rite of passage, and some luck
and marketing (hype and random factors seems to be given for new technology,
in the short term). So more projects spring up following the same model. These
also work great, and by now we have a handful of new, discovered concepts
associated with learning and using the language. The language, ecosystem and
implementations are still lean and easy to comprehend. And so some years pass.

Now this language is actually used for _large_ applications. It's still all
gravy, the code bases are still uniform and easy to understand. People can
easily be trained. More projects adopt this language, or even use it to build
things from scratch. It gets applied to more domains. Years pass, and things
that were unobservable in the beginning start to rear its head. They weren't
_non-existing_ , but they were so minuscule in this large landscape (remember
- big adoption of this language) that it was unobservable from the bigger
picture. Now what was a problem for a few developers seems to be a problem for
many people. For a while, they solve this pain point by educating about
certain patterns to look out for and solve. This works for a while, but after
a while more pain points become apparent. And like for the initial pain point,
it is just not a pain point for a small group of ignorable developers, but
indeed a systemic one. There seems to be something wrong. We can't simply
solve this pain point with education and applying patterns - we need
_abstractions_. There is some murmur about this - the principal point about
this language was to avoid over-abstracting things. We need to practice
constraint. This works for a while, but after some time the concerned voices
of the people advocating this kind of restraint gets drowned out. These
limitations are just _too much_ for people to deal with. So people start
suggesting and inventing so-called _abstractions_. And pain points are
relieved. After a while you have a whole cottage industry of these
abstractions. And people's day to day life with this language and its
associated code bases are happier and more productive. On the other hand,
there is more to learn now, and things aren't straightforward any more. You
can't simply look up a library and have flat, easy to read code. You also need
to learn the associated _abstractions_. You also notice that the technologies
associated with these abstractions are getting kind of _big_. They are
starting to take on a life of their own. And it seems like they don't really
_fit_. Some of them feel kind of shoe-horned in, as if there was no general
slot for them already installed, it just had to be jammed in there.

Now, is this language good for large-scale development? The language is still
easy to learn. Somehow. There was a bunch of additions up through the years to
ease some pain points. Not all of jive as well with each other, or with the
original language. But with some elbow grease, it is perfectly serviceable.
Not to mention all the associated technology that cropped up to assist the
language in its ascent - _that_ is the hard part. So the language is not
_really_ easy to learn any more, with the associated things. But people know
it, there are code bases to maintain and it has proven that it isn't
_useless_.

Is the language good for large-scale development? Doesn't matter. It already
won and is here to stay.

------
wavesum
Destined to succeed might make better english.

~~~
mrspeaker
Aw, c'mon - where's your sense of imagination! No one would click on an
article with that title (except Go fans). "Doomed to succeed" surprises the
reader and entices them to see what it could possibly mean. It's a fantastic
title!

