Why Go is doomed to succeed

https://texlution.com/post/why-go-is-doomed-to-succeed/

by dawkins • 11 years ago

291 312 11 years ago

texlution.com

gtrubetskoy2• 11 years ago

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

nobullet• 11 years ago

What's wrong with JVM?

wiremine• 11 years ago

Nothing, IMHO. However, I do like Go's much leaner memory footprint for server side software. At least, that's been my experience: the same code doing the same task takes up much less RAM.

rifung2• 11 years ago

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

bkeroack2• 11 years ago

Among other things, an unnecessary VM layer if all you ever run on is x86.

gtrubetskoy2• 11 years ago

The JVM is a piece of software that rivals the kernel in complexity with for the most part redundant functionality (i.e. memory management, monitoring the running program, etc.). It does have the benefit of being uniform across platforms, but if you're dealing with a single OS, then the extra weight and deployment complexity isn't worth it - you're better off learning your operating system and its tools.

lohengramm• 11 years ago

Very well put. I would also add nice UTF-8 support, easy concurrency and overall simplicity.

wz1000• 11 years ago

All those points along with the parents apply to Haskell too. Yet Haskell does not enjoy the same hype/success.

xyby• 11 years ago

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• 11 years ago

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...

orian• 11 years ago

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

slapresta• 11 years ago

PHP has (sadly) already succeeded.

leoi11• 11 years ago

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

dawkins2• 11 years ago

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

myg2042• 11 years ago

What a good expression. Did the author originate it?

dawkins2• 11 years ago

yes, it's from the article

jamesfisher• 11 years ago

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.

Veedrac2• 11 years ago

I tend to think of abstraction as the price. To see why this is justified, note that you can trivially come up with an abstraction that has no benefit (eg. pointless redirection), but coming up with one that has no cost (eg. developer-, compiler- or run-time) is near-impossible.

It's true that many abstractions pay for themselves many times over, but not all do. For some applications, this means that a language encouraging a more direct solution comes out ahead; for others one looks for languages that make the wanted abstractions cheaper.

Artemis22• 11 years ago

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.

tantalic• 11 years ago

The whole point of a gun is to enable shooting.

gamesbrainiac• 11 years ago

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.

bkeroack2• 11 years ago

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).

tptacek12• 11 years ago

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.

microtonal7• 11 years ago

I agree that the number of possible solutions is often smaller than in other languages. But there are still often multiple ways which are considered idiomatic Go (in the sense that they are all widely used). E.g. if you build some iterable type, you could provide iteration via:

1. Go channels: send every value over a channel.

2. Callbacks: provide an iteration function which takes a callback function.

3. Closures: let a closure return the next value when called.

4. Iterators: create a separate iterator type with e.g. HasNext()/Next() methods.

In this respect C was much simpler, because only (2) and (4) were really possible (and sometimes indexing).

scriptproof• 11 years ago

But you are lucky if your project has a large group of programmers. There is more probably a large group of projects with a small group of programmers. There are also some large projects: Linux, KDE, LibreOffice, VLC, LLVM, etc... and none is written in Go.

doomrobo• 11 years ago

Linux (1991)
KDE (1996)
LibreOffice (based on StarOffice, 6.0 released in 2002)
VLC (2001)
LLVM (2003)

I think you have a point r.e there being more smaller projects than large projects with large teams. But this is a terrible argument. Go was released in 2007. Are you being facetious or are you suggesting that porting a mature codebase to Go is that easy? CoreOS was released in 2013 and so was Docker. I know that Docker actually ported to Go after the fact, but it was still relatively young and Go was already mature by then.

microtonal7• 11 years ago

This is a weird argument to make, since Go was first introduced in 2009 and the first stable version was released in 2012. All those projects precede Go by a decade or more.

Also, despite Go's short existence, there are already a surprising number of large Go project (Docker, Syncthing, etcd).

qznc• 11 years ago

"explicitly engineered to thrive in projects built by large groups of programmers with different skill levels"

Reminds me of Java. Although, Java gets increasingly complex these days. It also started out without generics.

discardorama• 11 years ago

I don't think you can say "Reminds me of Java" with "Simple enough". Java is too complicated now.

XorNot• 11 years ago

The most pleasant thing about learning Go for me has been that largely, if the compiler is happy, my code works. At times the compiler feels nitpicky, but so far that opinionation has tended to make me write better code that is unquestionably very readable so far.

sapek• 11 years ago

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

rwmj3• 11 years ago

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

4ad3• 11 years ago

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).

garfij• 11 years ago

I like how ML is more modern than C, but they were both released in the early 70s.

tptacek12• 11 years ago

This got downvoted but I think there's more truth here than on much of the rest of the thread, though I might use words other than "engineering" and "craft". I'm fond of saying that Golang isn't a particularly great programming language, but is one of the great programming tools.

omni• 11 years ago

I'm fond of saying that Golang isn't a particularly great programming language, but is one of the great programming tools.

Could you elaborate on what you mean here? Why do you not consider Go a language? What do you consider the requirements to be a programming language?

vezzy-fnord6• 11 years ago

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.

aaggarwal6• 11 years ago

I have never used Go before. From the sound of it, it looks like Go hits a sweet spot between C and Java? and of course the Google support is a major factor for a possible success.

Elrac8• 11 years ago

"Between C and Java" hits it very well, I'd say.

When I jumped ship from C to Java, Java's object orientation wasn't exciting to me, and its exception handling is an acquired taste.

But dynamically growable, garbage collected buffers are something I'd missed for a long time. And the simple ability to concatenate strings without first reserving space for the result. Oh, and hash maps! Remarkably versatile data structures, those.

Coming from C, Java was a delight. Java would have a lot more trouble dragging me away from Go.

masklinn5• 11 years ago

it looks like Go hits a sweet spot between C and Java?

If your sweet spot is 90~95% java and 5~10% C.

vezzy-fnord6• 11 years ago

Not quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when the vestiges of what would become Plan 9 and Inferno began to take shape (the sam editor that would influence acme, the rc shell, mk and the predecessor to 9P [streams] would all originate here - see "Interprocess Communication in the Ninth Edition Unix System" [1]).

Meanwhile, Rob Pike and his contemporaries did language research, particularly related to the semantics of CSP-style concurrency. Syntactically they were all C-like, as the Plan 9/Research Unix community all generally liked it.

Newsqueak was the first and it was a cross between C and with special syntax and semantics for procs (green threads). It was written for GUI workstation environments in mind, the idea being to easily build multi-seat applications. From Newsqueak arose Alef, which refined on it but had manual memory management. Then from Alef came Limbo, the language running on top of the Dis VM that formed the core of the Inferno OS.

Fast forward some years later, Rob Pike and some other Bell Labs vets are at Google. Some event happens which painfully reminds them of mediocrity in computing, that gives them the drive again and they resume right where they left from Limbo.

Go is born.

[1] http://cm.bell-labs.co/who/dmr/ipcpaper.html

oldmanjay• 11 years ago

It doesn't feel right to say go is "between" java and c. There isn't a tremendous amount of expressiveness in go that java can't replicate, and there's enough in java missing from go that makes it a wash, for me anyway.

tptacek12• 11 years ago

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.

api2• 11 years ago

When I looked it over it struck me as a stripped down Java that's friendlier for systems programming and could interoperate with C without the torture of JNI.

vezzy-fnord6• 11 years ago

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.

ChuckMcM• 11 years ago

That captures it for me, imagine a Python that squeezed to the essential bits of Java and left you with Go. It helped that Java, Python, and C++ were the core languages at Google where Go was developed so you had to have something that could bring that community along.

For me personally Rust is more my style, but I agree with the original author that the structural aspects of Go program construction will benefit large communities greatly. It is something I had not really considered seriously before.

antod• 11 years ago

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

To me when people compare Go to Python, I can't help feeling that means quite an old version of Python (eg 1.5) in terms of expressivity and higher level features.

Python 1.5 was quite a small straight forward language compared to today. Which seems like the goals Go has.

nickbauman• 11 years ago

The problem with Go is likely a result of having the kinds of stated goals that it has. The designers of Java deliberately created a language that was for people they didn't trust. The result is a hammer that looks and works like a dildo.

So we're likely headed to where the commensurate Go analogy to Java is a hammer that looks and works like a catheter or something?

One last analogy. What would you prefer: a pilot who has been certified to fly that aircraft and has a minimum number of flight hours or giving every passenger a joystick sticking out of their seat tray so that maybe collectively they won't crash the plane?

Oh, and you kids get off my lawn (waves cane)! ;)

Merovius8• 11 years ago

The correct analogy (as we are generally not building people) is "Building an aircraft, that needs a pilot with certification and a certain number of flight hours, or building an aircraft that can be flown by any passanger with minimal instructions, if the need arises". In the latter aircraft, you still benefit from an experienced pilot, but at least, if they pass out, get drunk or plainly go rogue, you still have a decent chance of dealing with the situation, instead of just crashing.

pjmlp11• 11 years ago

I don't like how Go's design turnoud to be, but I surely appreciate that it means less C code and more memory safe code.

Eventually C will be squeezed into an Assembly like niche, used only for shaving out ms out of an application, kernel stuff or those little code tricks not exposed on the safe layer.

_pdp_• 11 years ago

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.

coldtea5• 11 years ago

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.

pcwalton14• 11 years ago

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.

gnuvince• 11 years ago

Not the parent, but I've read many comments here on HN from users who feel that if a language doesn't include an HTTP server in the standard library, it's not ready for production work. Ridiculous, of course, but that may be what the parent is referring to.

coldtea5• 11 years ago

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".

coldtea5• 11 years ago

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.

Yes, that's probably the case (Rust caters to more complex needs). Still makes it more difficult to just "dive into it" like you can with Go or Java or Python etc. Of course it's probably much simpler compared to mastering C++ or getting C right without dangerous bugs.

kzvezdarov• 11 years ago

It's rather that Rust's standard library and third party library support is incomplete. E.g.:

- last time I checked there was no option to have non-blocking IO which is a pain.

- custom JSON serialization/deserialization from/into custom data structures is extremely painful (for reference, rustc_serialize's Decodable trait).

- thread::scoped leaking destructors under certain conditions. This is more of an example of how a complex language gives rise to complex issues that very are difficult to debug and fix.

This will get better in time obviously but this is the current state of the language. Nonblocking IO in particular is really unfortunate to see in a 1.0 version tag.

Veedrac2• 11 years ago

Surely the parent comment only meant that Rust was too complex to use, not that Rust was unduly complex. If Go would be a feasible choice, Rust is probably solving problems that aren't too relevant to you.

I think http://arewewebyet.com/ speaks to the completeness point sufficiently. Rust-the-language is probably complete enough for all but the most serious use-cases, but Rust-the-ecosystem isn't.

spotman4• 11 years ago

This was my favorite quote/sentence in the article. For me it feels extremely true. I am one of those people that has to write, read, debug and maintain large software systems.

Sure generic's would be nice, but I do not feel they really would change much. After using and supporting Go for years, I would rather keep it how it is. Simple and verbose.

Getting up at 3am in the morning to respond to a page going off in a production system that you didn't write, there is something extremely parseable with Go. It doesn't hide and abstract things in a way where you have to end up digging.

Often the docs are just not enough to really understand software. In the event you end up having to go read the code to understand it, when things get that far, I wish it was Go every time. There is little in the world more frustrating than having to read 18 java files to understand a simple format of a payload because your coming in late to the codebase.

jshen• 11 years ago

The problem with all statements regarding programming languages is that they rarely have empirical evidence to back them up. Do you have any data showing that generics will lead to a cleaner language? I have seen a study or two that tried to measure productivity, bug counts, etc with regards to generics and what it showed was that writing code using a library that is built with generics was ever so slightly faster. However, it showed that creating or editing a library that used generics took 10x longer.

It seems that you can't really make the claim that adding generics leads to a "much cleaner language".

hyperpallium2• 11 years ago

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?

dsymonds6• 11 years ago

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.

hyperpallium2• 11 years ago

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. ]

aroman• 11 years ago

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

What a brilliant sentence.

sunstone• 11 years ago

Abstraction if necessary but not necessarily abstraction.

coldtea5• 11 years ago

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.

pron12• 11 years ago

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.

dsymonds6• 11 years ago

It's not hard to find people switching from Java to Go (e.g. http://www.infoworld.com/article/2608571/application-develop..., 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.

pron12• 11 years ago

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.

twic• 11 years ago

That particular example of someone switching is someone whose background is in Java, but moved to a project implemented largely in Go. He switched because he changed projects.

spotman4• 11 years ago

Sure, there is some nice things about the JVM.

However, for me, Java was the first language to get ditched when I got comfortable enough with Go to accomplish similar tasks.

Reasons are many, but Go definitely wins "single native binary" argument. Java has to be installed, and it has different versions that can be installed. Go you simply compile for whatever platform you want, and you literally have a single native binary. No other dependencies need to be installed.

Hot code loading and swapping is neat in Java, but most places I have worked do not have the operational skill to really take advantage of this, and instead compound that against the JVM's slow startup time, which makes it double bad. With Go, you ship a simple binary that starts up very quickly, and so operationally the effect of faster, more seamless deploys are a much better experience.

pron12• 11 years ago

I think that those advantages are extremely valuable for command-line apps, and hardly matter at all for servers. Those organizations you've mentioned probably do take advantage of bytecode manipulation (they have undoubtedly used shadowing, and probably some agents) even though they don't write manipulation -- or hot-swapping -- code themselves, and they certainly enjoy the JVMs unmatched monitoring.

vorklerta4• 11 years ago

Many of the Java monitoring is only critical because of the garbage collection issues with large heaps. Since switching away from Java we don't miss any of the features you've listed. The problem with Java is the mountain of bloated frameworks which have become standard over the last 10+ years - things like Spring, Hibernate etc. which new developers are expected to learn. With Go new developers which join the team aren't saddled with years of legacy frameworks which are expected as standard knowledge. The JVM is a great platform, but Java the language and to a greater extent its frameworks are a major liability for the future of the JVM. Go and Java (the language) are both incredibly boring to program in (a good thing in if you have developers of varying skill levels), but they are a safe choice with a low bar for learning. Java unfortunately has a mountain of legacy cruft which makes it a pretty terrible choice for new hires to ramp up on.

pron12• 11 years ago

Many of the Java monitoring is only critical because of the garbage collection issues with large heaps.

That's not true. All JVM libraries expose a ton of monitoring information through the standard JMX interface at every level of the stack, from deep inside the JVM, through logging framework, DB drivers, schedulers etc., and all the way through the application.

And I can only guess that you've yet to encounter Go's even worse GC problems with large heaps.

Java unfortunately has a mountain of legacy cruft which makes it a pretty terrible choice for new hires to ramp up on.

True, but only in legacy codebases. A new Java project is as pristine as a new Go project, and new Java libraries are just as lean (because there's a lot of cross-influence between the two environments).

Dewie33• 11 years ago

When pron posts on a thread about lang X, it tends to be 30% about lang X and 70% raving about the JVM platform.

vorklerta4• 11 years ago

More like 90% blindly advocating the superiority of Java. Does he ever sleep?

latch2• 11 years ago

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• 11 years ago

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

latch2• 11 years ago

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.

jhardcastle• 11 years ago

This is sort of the conclusion I've come to in the last few weeks as I think about and research in preparation for my next startup. I learned to code with C / Perl in the late 90's, moved to scripted/interpreted "web" languages like ColdFusion, PHP, RoR, JS, and about a year ago I finally decided to build a toy project with Go for Google App Engine. I found the process really instructional, but ultimately pretty frustrating. I fall very much into the author's second camp; it's not the language for me, for what I want to use it for. I'm building a pure web app, with very little systems orchestration need (outside standard devops). Go seems like a great fit for building Docker, but a poor fit for building AirBnB. Especially at first, when I'm likely to be the only programmer for 12-18 months, it seems to me that Go is a poor choice to begin with. It loads too much technical debt (probably the wrong term) onto our startup at a time when we need to move fast and break things. If we are hugely successful and we end up with 20 programmers in 3-5 years, then maybe it'll be time to re-architect key microservices in golang. Until then, I think RoR makes the most sense for us.

I've been looking for someone to verbalize this train of thought for a few weeks.

mst2• 11 years ago

I keep wondering whether the lack of generics is in part intended to make people not even try and implement Hibernate but to accept using a lower level of abstraction instead.

justinhj• 11 years ago

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.

Artemis22• 11 years ago

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.

modulus1• 11 years ago

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.

api2• 11 years ago

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.

tptacek12• 11 years ago

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.

meatysnapper• 11 years ago

For any big company, you end up with hordes of lazy or worse, very bad programmers. You need a COBOL-like language to allow them to produce things and not mess up things too badly.

GO fits the bill.

kyrra• 11 years ago

Any sources that say Google had a high turnover rate? Only things I can find is that most employees have a short tenure, which seems to be due to lots of hiring.

ilurk• 11 years ago

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?

Skunkleton• 11 years ago

In reply to your first question, I don't think it does. Go and Rust were both initially marketed as "systems" languages, but in reality they make very different design trades. I would say that Go lines up more with Java or C# than it does with C or Rust. I would guess that having both Rust and Go in your toolkit will be a benefit in the future.

Dewie33• 11 years ago

(1) where does Rust fit in this?

It doesn't. Not any more than other languages anyway.

davidw• 11 years ago

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• 11 years ago

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.

biokoda• 11 years ago

(2) People tend to follow the path of least resistance even if not the most optimal. Erlang requires more effort in the beginning, but pays off immensely later on. It's easier to start learning go because it's not as strange. This is also why node.js became so popular. It has the lowest barrier to entry.

wavesum• 11 years ago

Destined to succeed might make better english.

mrspeaker• 11 years ago

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!

istvan__• 11 years ago

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.

Dewie33• 11 years ago

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.

fauigerzigerk• 11 years ago

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.

fishnchips• 11 years ago

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...)

DubiousPusher• 11 years ago

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."

jubei• 11 years ago

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.

NateDad4• 11 years ago

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.

charlieflowers• 11 years ago

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

mshenfield• 11 years ago

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.

dwc2• 11 years ago

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.

BuckRogers2• 11 years ago

"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....

chadscira• 11 years ago

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 ;)

BuckRogers2• 11 years ago

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.

MetaCosm6• 11 years ago

Go 1.5 can call C and be called from C. So you can write a Go function to extend your C app.

andyidsinga• 11 years ago

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?

akhilcacharya• 11 years ago

I just started on my first Go project last night...and yeah, that feels about right.

giovannibajo1• 11 years ago

In my experience, Go makes it hard to write libraries in the STL/C++ sense (that is, reusable abstractions), while making it very easy to write libraries in the "batteries" sense. So yes I think the metaphore is correct

NateDad4• 11 years ago

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.

Animats• 11 years ago

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.

neverminder• 11 years ago

I brought Rust into my job for some non-essential stuff and so far it obliterated my usual tools (Scala, Python to be more specific) in shear speed and low memory consumption. I've written no more than a thousand LOC of it and most of it is still clumsy bearing it mind the fact that I'm new to it, but the potential that it has cannot be denied. To me it's a missing link I was waiting for - a low level language that feels like a high level one.

kibwen6• 11 years ago

I'm currently reaching out to people using Rust for their jobs so that we can establish a more formal relationship with corporate users, and I'd love to hear more about your use cases. :) My email is on my profile page here.

octatoan2• 11 years ago

shear speed

Do you write tools for a woollens manufacturer?

serge2k• 11 years ago

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.")

Which is why Java gets used instead.

reagency3• 11 years ago

Often Java is too slow too. (Slow == overhead from GC of unwanted object metadata and heap allocated objects)

laumars3• 11 years ago

In some situations, yes. But Java can suffer from similar complexity and maintainability issues too.

Go, for all it's short comings and missing features, is closer to the "instant gratification" state that Python and it's ilk enjoy while having performance closer to that of Java.

I'm not trying to say one language is better or worse than the other though. Just my observations as to why Go is gaining popularity.

reagency3• 11 years ago

Does Google use Go in any high-load services?

dkuntz2• 11 years ago

download.google.com is completely powered by Go at this point, iirc.

rakoo2• 11 years ago

Vitess (https://github.com/youtube/vitess) scales mysql for youtube level of usage.

codygman2• 11 years ago

program in Haskell for fun.

What about the people who program in Haskell for work?

Go is for people who have a job to do.

People use Go for fun.

pcwalton14• 11 years ago

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• 11 years ago

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

Merovius8• 11 years ago

I find it counterintuitive, that generics and traits improve speed. I would enjoy a deeper explanation of that :)

kibwen6• 11 years ago

  > 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.

This is a mischaracterization of Rust to the point of incredulity. I've been talking to companies experimenting with Rust and all the engineers I've spoken to have praised Rust for its ability to let them do their jobs with confidence. These engineers are in domains where GC is intolerable and C++ is considered too much of a risk (in fact, one of my biggest surprises in this current endeavor is discovering how few people in industry will describe themselves as comfortable with C++ to the point of being willing to use it in greenfield projects with confidence). Without Rust, these companies would be forced to buy more hardware to throw hardware at the problem or hire C++ specialists to throw at the problem; fortunately Rust threads the needle and provides extreme business value.

Rust was created to solve a specific pain point. It's not some language that sprang fully-formed and perfectly-designed out of the ether. It solves problems that no other language even attempts to solve (no, Ada doesn't do what Rust does (and likewise, Rust doesn't do what Ada does)), and the mechanisms that it uses to do that took years of iteration and concerted effort on large codebases.

Not everyone needs to be working at the level that Rust does, and I think that's great. I'm a polyglot programmer myself, and I like Rust because at last there exists a language that lets me perform at the level of C with the same level of memory correctness that I expect from Python (or really, any language designed post-1995).

jrcii• 11 years ago

I never heard that phrase "thread the needle" before that's good

octatoan2• 11 years ago

Rust is for people who debate language semantics on Lambda the Ultimate and program in Haskell for fun.

Very smooth. /s

ngrilly8• 11 years ago

Other than that, there are few killer problems with the language when doing server-side stuff.

Which ones?

vorg• 11 years ago

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.

0xdeadbeefbabe2• 11 years ago

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

framp• 11 years ago

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

shmerl• 11 years ago

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.

spopejoy3• 11 years ago

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.

MetaCosm6• 11 years ago

Yep, just like Dart... oh, wait.

mkramlich• 11 years ago

bingo

Google: Go

Microsoft: C#

Sun/Oracle: Java

almost all others: more on their own merits, from developers eyes (Python, Perl, C++, Ruby, Rust, D, Scala, LUA, JS, etc.)

a language should have innate merits, of course, but never discount the advantages of having a single corporate entity with lots of cash and focus and a built-in install base of eyes

pjmlp11• 11 years ago

Let me fix that list

CNRI: Python

AT&T: C++

Unisys: Perl

EPFL: Scala

37signals: Ruby

Mozilla: Rust

freyr• 11 years ago

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• 11 years ago

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.

wyager2• 11 years ago

Languages are not products. The analogy is not reasonable.

ngrilly8• 11 years ago

The article claims, and tries to "prove", that Go succeeds because it was designed from the very beginning to be a mainstream language, trying to stay simple enough to be accessible to most programmers. You're not discussing this in your comment.

You claim that Go succeeds because Google's behind it. Maybe, maybe not. Then write your own article to make your point.

The paragraph about Erlang was not a "potshot". The author is just pointing out a tradeoff, which is real. There is no question that Erlang is a great language and system.

spopejoy3• 11 years ago

Yes, it won’t always keep you safe from data races as Erlang will, but Erlang keeps you safe by copying your data over and over, making it significantly slower, TANSTAAFL.

Potshot. Defend it at your peril.

muraiki• 11 years ago

You characterize certain language features as objectively better. Indeed, those who do not use the particular approach you advocate (FP) or the feature you desire are "haters who refuse to understand". Is this really a charitable way to look at other programmers? As people who, because they do not use your preferred language or languages, are apparently full of hatred and -- not a lack of understanding, but a _refusal_ to understand?

How about we consider the author of the blog post, the Go community, and the Go language's designers in a more charitable light. Perhaps the points made in the article are actually valid: that language features involve tradeoffs, some of which are measured not just in terms of performance, and that languages are designed to achieve certain goals that might not align with yours.

Yes, I imagine that "Go certainly doesn't succeed because of smug/boring articles like this one" although I'd remove "smug/boring." Before I used Go I hated it "from first principles", because I had used Scala and Clojure and Haskell and Reactive Extensions and all sorts of FP goodness. But to make a long story short, once I started using Go I really enjoyed it and now I willingly choose to use it to solve problems. It was the use of Go that convinced me that perhaps these absolutes from FP I believed in weren't quite absolutes after all. But this doesn't mean that I consider Go to be some kind of perfect holy grail of programming, either.

Does that make me a hater who refuses to understand? Does it make me some kind of idiot for regressing from FP? Or perhaps the goals of Go aligned with my team's goals, and that was really helpful and valuable to us?

spopejoy3• 11 years ago

I characterize FP as not worse, which of course implies that it must be better in some scenarios to even compete.

I characterize Go as having glaring warts. ":=" will bomb on reassignment UNLESS you destructure alongside a new variable. Wart. Try to close over a variable in a loop; wince in pain as you make a throwaway anonymous function to do so. Wart. Don't get me started on "interface {}".

Nonetheless, I think Go is a great tool for the right job. I don't think it's "better for open source" (WTF???). I wouldn't want to write a massively-concurrent (not parallel: concurrent) system in such a loose-goosey, non-polymorphic language. But that's just me, knock yourself out.

stox• 11 years ago

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.

Why Go is doomed to succeed

Related Stories