19 ms·

Why Go is doomed to succeed

291 points by dawkins 11y ago

gtrubetskoy 11y ago
Compiled to native binary, garbage collected, no JVM and not object oriented is why I like it.
- nobullet 11y ago
  What's wrong with JVM?
  - wiremine 11y 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.
  - rifung 11y 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
    - icedchai 11y ago
      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 11y ago
        But what happens when some of the apps require different versions of the JVM?
        bitmapbrother 11y ago
        As long as you're using the latest version then this shouldn't be a problem as the JVM is backwards compatible.
        tacticus 11y ago
        Except on those fun occasions when it isn't really. :\
        icedchai 11y ago
        You know you can have multiple VMs installed, with different JAVA_HOMEs, right? This is a solved problem.
  - bkeroack 11y ago
    Among other things, an unnecessary VM layer if all you ever run on is x86.
    - pmahoney 11y ago
      The VM part of the JVM allows for really great monitoring: there are standard ways for tools to hook into bytecode and add instrumentation without needing the source. There are also lots of mature tools available, but that's mostly because the JVM has been around for so long. We're looking at Go right now, and our instrumentation is currently done manually at the source level. Are there, or will there be, tools to add instrumentation similar to those available on the JVM? I'm sure it's possible...
  - gtrubetskoy 11y 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.
  - yo-code-sucks 11y ago
    Memory overhead, and the ability for endless abstraction to save three lines of boilerplate code and then the fact that it has only one actual implementation, meaning the abstraction was unnecessary.
- lohengramm 11y ago
  Very well put. I would also add nice UTF-8 support, easy concurrency and overall simplicity.
  - wz1000 11y ago
    All those points along with the parents apply to Haskell too. Yet Haskell does not enjoy the same hype/success.
    - rakoo 11y ago
      I think you'll find some people who wouldn't say that Haskell is overall simple, or at least as simple as Go can be.
      - codygman 11y ago
        > I think you'll find some people who wouldn't say that Haskell is overall simple, or at least as simple as Go can be. You'll also find some people who say the opposite. We need to qualify what kind of simple we are talking about? Are we talking purely about language? Are we talking about standard libraries? Ease of use of API's? Ease of use in analyzing performance? If we just compare Go's syntax to Haskell's syntax you'll find they both have few reserved words.
xyby 11y 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 11y 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.scheme/2009-04/msg00162.html http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.schem...
orian 11y 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 11y ago
  PHP has (sadly) already succeeded.
  - leoi11 11y ago
    yet I doubt that if doomed to success has anything to do with doomed to succeed forever
dawkins 11y ago
"Go won’t let you abstract yourself in the foot." :)
- myg204 11y ago
  What a good expression. Did the author originate it?
  - dawkins 11y ago
    yes, it's from the article
- jamesfisher 11y 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.
  - Veedrac 11y 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.
  - Artemis2 11y 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.
    - stass 11y ago
      That is actually due to a lack of rich abstraction mechanisms in Java.
gamesbrainiac 11y 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.
- bkeroack 11y 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).
  - tptacek 11y 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.
    - tomp 11y ago
      > 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. That is a great way to compare languages. Incidentally, that's the same way I feel about Scala vs Python.
sapek 11y ago
Whether you like Go or not depends on whether you think of software development as engineering or as craft.
- rwmj 11y ago
  More like "... whether you've used any more modern languages than C" (such as ML and many other functional and research languages).
  - 4ad 11y 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).
    - rwmj 11y ago
      I didn't carry out a scientific study -- to my knowledge, no one is bringing any hard facts to the table when they talk about programming language preferences -- so you can't evaluate what I said as logically true or false. For reference, I have used OCaml, Haskell, Golang and C extensively. I think Golang is a wasted opportunity to replace C. It's a mediocre language with a bunch of annoyances.
    - ngrilly 11y ago
      What kind of compiler are you writing? For which language and target?
      - 4ad 11y ago
        For Go and sparc64, I did arm64 before.
        ngrilly 11y ago
        You did the work to compile Go to arm64? Thanks for that then!
vezzy-fnord 11y 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.
- aaggarwal 11y 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.
  - Elrac 11y 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.
    - okasaki 11y ago
      Well, C++ has all of that.
_pdp_ 11y 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.
deleted 11y ago
[deleted]
coldtea 11y 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.
- pcwalton 11y 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 11y 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.
    - deleted 11y ago
hyperpallium 11y 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?
- dsymonds 11y 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.
  - hyperpallium 11y 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 11y ago
> Go won’t let you abstract yourself in the foot. What a brilliant sentence.
- sunstone 11y ago
  Abstraction if necessary but not necessarily abstraction.
coldtea 11y 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.
pron 11y 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.
- dsymonds 11y ago
  It's not hard to find people switching from Java to Go (e.g. http://www.infoworld.com/article/2608571/application-development/article.html 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.
  - pron 11y 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.
latch 11y 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.
- yo-code-sucks 11y ago
  Thumbs up!
- jjawssd 11y ago
  Please tell me more about the pain-driven lessons Hibernate and their ilk taught us
  - latch 11y 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 11y 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.
justinhj 11y 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.
- Artemis2 11y 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 11y 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.
- api 11y 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.
  - tptacek 11y 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.
    - stefantalpalaru 11y ago
      Let's not do SEO in HN comments. The language's name is "Go", not "Golang".
ilurk 11y 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 11y 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.
- Dewie3 11y ago
  > (1) where does Rust fit in this? It doesn't. Not any more than other languages anyway.
- davidw 11y 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 11y 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.
    - ngrilly 11y ago
      > 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.
wavesum 11y ago
Destined to succeed might make better english.
- mrspeaker 11y 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__ 11y 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.
Dewie3 11y 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 11y 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 11y 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 11y 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 11y 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.
- NateDad 11y 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 11y ago
God, this is a beautiful turn of phrase: "Go won’t let you abstract yourself in the foot."
mshenfield 11y 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.
- dwc 11y 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.
BuckRogers 11y 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.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
- chadscira 11y 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 ;)
  - BuckRogers 11y 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.
andyidsinga 11y 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 11y ago
  I just started on my first Go project last night...and yeah, that feels about right.
- giovannibajo1 11y 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
- NateDad 11y 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 11y 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.
- ads_are_shite 11y ago
  So, if we tread the same well worn steps as Google, drink from the same fountains we see their guilded staff drink from, we will be ok, but anything off the beaten path, we will be fucked? And good luck getting anything else as go is basically what Google say (see versioning and generics for examples).
- neverminder 11y 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.
vorg 11y 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.
0xdeadbeefbabe 11y ago
Plan9's failure payed the karma points for go's success. Duh.
framp 11y 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 http://yager.io/programming/go.html
T3RMINATED 11y ago
Its Doomed because its made by Google they should stick to Search.
shmerl 11y 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.
spopejoy 11y 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.
- MetaCosm 11y ago
  Yep, just like Dart... oh, wait.
- mkramlich 11y 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
  - 699 11y ago
    I would say Mozilla is backing Rust, and Google is responsible for a lot of Python's success.
  - pjmlp 11y ago
    Let me fix that list CNRI: Python AT&T: C++ Unisys: Perl EPFL: Scala 37signals: Ruby Mozilla: Rust
    - wirrbel 11y ago
stox 11y 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.

291 points by dawkins 11y ago

gtrubetskoy 11y ago

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

nobullet 11y ago
What's wrong with JVM?
- wiremine 11y 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.
- rifung 11y 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
  - icedchai 11y ago
    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 11y ago
      But what happens when some of the apps require different versions of the JVM?
      - bitmapbrother 11y ago
        As long as you're using the latest version then this shouldn't be a problem as the JVM is backwards compatible.
        tacticus 11y ago
        Except on those fun occasions when it isn't really. :\
      - icedchai 11y ago
        You know you can have multiple VMs installed, with different JAVA_HOMEs, right? This is a solved problem.
- bkeroack 11y ago
  Among other things, an unnecessary VM layer if all you ever run on is x86.
  - pmahoney 11y ago
    The VM part of the JVM allows for really great monitoring: there are standard ways for tools to hook into bytecode and add instrumentation without needing the source. There are also lots of mature tools available, but that's mostly because the JVM has been around for so long. We're looking at Go right now, and our instrumentation is currently done manually at the source level. Are there, or will there be, tools to add instrumentation similar to those available on the JVM? I'm sure it's possible...
- gtrubetskoy 11y 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.
- yo-code-sucks 11y ago
  Memory overhead, and the ability for endless abstraction to save three lines of boilerplate code and then the fact that it has only one actual implementation, meaning the abstraction was unnecessary.
lohengramm 11y ago
Very well put. I would also add nice UTF-8 support, easy concurrency and overall simplicity.
- wz1000 11y ago
  All those points along with the parents apply to Haskell too. Yet Haskell does not enjoy the same hype/success.
  - rakoo 11y ago
    I think you'll find some people who wouldn't say that Haskell is overall simple, or at least as simple as Go can be.
    - codygman 11y ago
      > I think you'll find some people who wouldn't say that Haskell is overall simple, or at least as simple as Go can be. You'll also find some people who say the opposite. We need to qualify what kind of simple we are talking about? Are we talking purely about language? Are we talking about standard libraries? Ease of use of API's? Ease of use in analyzing performance? If we just compare Go's syntax to Haskell's syntax you'll find they both have few reserved words.

xyby 11y 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 11y 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.scheme/2009-04/msg00162.html http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.schem...

orian 11y 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 11y ago
PHP has (sadly) already succeeded.
- leoi11 11y ago
  yet I doubt that if doomed to success has anything to do with doomed to succeed forever

dawkins 11y ago

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

myg204 11y ago
What a good expression. Did the author originate it?
- dawkins 11y ago
  yes, it's from the article
jamesfisher 11y 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.
- Veedrac 11y 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.
- Artemis2 11y 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.
  - stass 11y ago
    That is actually due to a lack of rich abstraction mechanisms in Java.

gamesbrainiac 11y 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.

bkeroack 11y 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).
- tptacek 11y 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.
  - tomp 11y ago
    > 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. That is a great way to compare languages. Incidentally, that's the same way I feel about Scala vs Python.

sapek 11y ago

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

rwmj 11y ago
More like "... whether you've used any more modern languages than C" (such as ML and many other functional and research languages).
- 4ad 11y 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).
  - rwmj 11y ago
    I didn't carry out a scientific study -- to my knowledge, no one is bringing any hard facts to the table when they talk about programming language preferences -- so you can't evaluate what I said as logically true or false. For reference, I have used OCaml, Haskell, Golang and C extensively. I think Golang is a wasted opportunity to replace C. It's a mediocre language with a bunch of annoyances.
  - ngrilly 11y ago
    What kind of compiler are you writing? For which language and target?
    - 4ad 11y ago
      For Go and sparc64, I did arm64 before.
      - ngrilly 11y ago
        You did the work to compile Go to arm64? Thanks for that then!

vezzy-fnord 11y 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.

aaggarwal 11y 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.
- Elrac 11y 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.
  - okasaki 11y ago
    Well, C++ has all of that.

_pdp_ 11y 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.

deleted 11y ago

[deleted]

coldtea 11y 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.

pcwalton 11y 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 11y 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.
  - deleted 11y ago

hyperpallium 11y 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?

dsymonds 11y 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.
- hyperpallium 11y 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 11y ago

> Go won’t let you abstract yourself in the foot. What a brilliant sentence.

sunstone 11y ago
Abstraction if necessary but not necessarily abstraction.

coldtea 11y 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.

pron 11y 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.

dsymonds 11y ago
It's not hard to find people switching from Java to Go (e.g. http://www.infoworld.com/article/2608571/application-development/article.html 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.
- pron 11y 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.

latch 11y 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.

yo-code-sucks 11y ago
Thumbs up!
jjawssd 11y ago
Please tell me more about the pain-driven lessons Hibernate and their ilk taught us
- latch 11y 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 11y 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.

justinhj 11y 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.

Artemis2 11y 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 11y 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.

api 11y 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.
- tptacek 11y 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.
  - stefantalpalaru 11y ago
    Let's not do SEO in HN comments. The language's name is "Go", not "Golang".

ilurk 11y 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 11y 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.
Dewie3 11y ago
> (1) where does Rust fit in this? It doesn't. Not any more than other languages anyway.
davidw 11y 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 11y 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.
  - ngrilly 11y ago
    > 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.

wavesum 11y ago

Destined to succeed might make better english.

mrspeaker 11y 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__ 11y 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.

Dewie3 11y 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 11y 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 11y 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 11y 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 11y 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.

NateDad 11y 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 11y ago

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

mshenfield 11y 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.

dwc 11y 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.

BuckRogers 11y 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.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

chadscira 11y 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 ;)
- BuckRogers 11y 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.

andyidsinga 11y 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 11y ago
I just started on my first Go project last night...and yeah, that feels about right.
giovannibajo1 11y 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
NateDad 11y 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 11y 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.

ads_are_shite 11y ago
So, if we tread the same well worn steps as Google, drink from the same fountains we see their guilded staff drink from, we will be ok, but anything off the beaten path, we will be fucked? And good luck getting anything else as go is basically what Google say (see versioning and generics for examples).
neverminder 11y 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.

vorg 11y 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.

0xdeadbeefbabe 11y ago

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

framp 11y 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 http://yager.io/programming/go.html

T3RMINATED 11y ago

Its Doomed because its made by Google they should stick to Search.

shmerl 11y 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.

spopejoy 11y 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.

MetaCosm 11y ago
Yep, just like Dart... oh, wait.
mkramlich 11y 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
- 699 11y ago
  I would say Mozilla is backing Rust, and Google is responsible for a lot of Python's success.
- pjmlp 11y ago
  Let me fix that list CNRI: Python AT&T: C++ Unisys: Perl EPFL: Scala 37signals: Ruby Mozilla: Rust
  - wirrbel 11y ago

stox 11y 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.