19 ms·

What Golang Is and Is Not

168 points by elrodeo 10y ago

scriptproof 10y ago
If you make a program that is executed a million of times or more a day, it make sense to have a language that is "near the CPU", and allows to optimize and speed up the most. This is what Go is. It will be a mistake to use it elsewhere.
- catnaroek 10y ago
  C++, otherwise a deeply flawed language, gives you more abstraction than Go and allows you to optimize and micromanage things more.
  - pjmlp 10y ago
    Not only C++, there are plenty of options. The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety.
    - codygman 10y ago
      One thing I can credit Go for is leading me from the untyped world to the typed one. I soon found the holes in the Go type system, and went looking for a stronger type system. I now generally prefer Haskell.
      - snaky 10y ago
        If Go is from typed world, then Perl too. Some magical built-in types (scalar, array, hash, typeglob, regexp, io handle) you cannot confuse, interface{} is scalar holding a reference, and built-in datatypes (arrays and hashes) are magical and you cannot construct something similar. Well, at least there's 'tie' mechanics in Perl after all that makes types extensible.
        codygman 10y ago
        Go is more from the typed world than Python where I came from. It will tell you at compile time you are using a string rather than an int (unless you use interface{}).
        snaky 10y ago
        The only difference is a selection of basic types. There's just no such types as string or int in Perl, Perl is a contextually polymorphic language whose scalars can be strings, numbers, or references (which includes objects). Although strings and numbers are considered pretty much the same thing for nearly all purposes, references are strongly-typed, uncastable pointers with builtin reference-counting and destructor invocation.
        codygman 10y ago
        For me the compile time and runtime distinctions are more important.
        snaky 10y ago
        Reflection you need to use, whether it be with interface{} in Go or with $scalar in Perl is runtime thing. reflect.TypeOf(tst), ref($tst) - there's no much difference. Type mismatch errors for basic types are handled in compile time, be it Go or Perl.
    - remus 10y ago
      >The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety. You say that like it's a small thing, but what proportion of bugs in C code does that cover? Im guessing you'd hit over 50%.
      - pjmlp 10y ago
        It is a small thing because there are other languages that offer the same safety with more features and lets face it, if a C coder is willing to embrace a GC enabled language there are lots to chose from, with AOT compilation to native code. I just expected more from Google, specially if one compares to the other company sponsored languages.
        snaky 10y ago
        Comparing apples to apples, the first compiler sponsored by 'other company' was PHP, so Go looks not that bad in comparison. Reason is second, and maybe Google's second language would be 1ML.
        pjmlp 10y ago
        Actually I was thinking in all languages that had commercial compilers, which goes way back than just PHP.
  - TillE 10y ago
    I love how C++ has had simple features like default arguments / function overloading for decades, while modern languages like Go and Rust require awkward workarounds. Swift 3 looks good, though. They've learned the right lessons.
    - catnaroek 10y ago
      Default arguments, at least as done in C++, complicate the language's semantics (e.g., template specialization selection) far more than they raise the level abstraction. Definitely not a well-designed feature. And Rust's traits are a far more principled (and thus better!) approach to overloading than anything C++ has (Boost's concept checks?). Traits turn concepts into language entities that are directly expressible in Rust syntax, rather than in awkward English documentation.
    - dominotw 10y ago
      C++'s problem was never 'not enough features' it was precisely the opposite.
    - pcwalton 10y ago
      There are also features that Rust has that C++ doesn't. So what?
    - tomjakubowski 10y ago
      I certainly wouldn't say these are "simple features" in C++. Overload resolution in particular is one of the most complicated parts of the language. Default arguments can get weird since the right hand side of the default, more or less, just gets inlined at the call site; I do recall there were a couple bugs in the last year at work because of C++ default arguments, though I don't remember their details. It's also fun when you don't realize a particular function has a default argument until you make a function pointer to it and assign/pass it to something that you mistakenly think is compatible. Depending on how nasty your codebase's use of templates and overloaded functions is, this can be a nightmare to debug.
- soulbadguy 10y ago
  Golang is only 'near cpu' when compared to python or ruby. Golang is much closer to java/c# then c/c++
  - xyproto 10y ago
    Go (the language) have at least two implementations: the official Go implementation and GCC (yes, Go is included in GCC, along with Fortran and Ada). The latest Go implementation (Go 1.7) has made Go a lot faster. I would argue that it closer the speed of executables generated with GCC (gcc/g++) than OpenJDK, the Oracle JVM, Mono or the .NET compiler for C#. Go (the language) can be made just as fast as C (the language), for many cases. Go has the advantage of making it much easier to use multiple processors, though.
    - vvanders 10y ago
      Until you have control over stack/heap and data locality you're never going to be able to approach C/C++/Rust speeds. Conversely if you're using C/C++ through a ton of heap/virtual pointers then you're losing a lot of the value the language brings and should be using something higher level.
      - dilap 10y ago
        Go allocates on the heap unless it can prove something doesn't escape, in which case it's on the stack. Not explicit programmer control, but I think you can reasonably make it do what you want. Because it exposes pointers as a first-class concept, you also have good control of how data is laid out in memory (=> locality). It's not like Python or Java where everything is a pointer and gets spread out all over memory.
        vvanders 10y ago
        Can you do an arena allocator in Go with disparate types? If not then you're really missing out on data locality. In also not a huge fan of a compiler "automatically" performing escape analysis. Makes a single change causing cascading perf problems very easy and hard to catch.
sergiotapia 10y ago
The author is quite correct. Go is super boring, and runs fast. Two great points for it. For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit. The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of code that's easy to understand. Here's just one example from me - both examples scrape some info from HTML: Elixir: https://github.com/sergiotapia/magnetissimo/blob/master/lib/parsers/demonoid.ex#L36 https://github.com/sergiotapia/magnetissimo/blob/master/lib/... Go: https://github.com/sergiotapia/gophers/blob/master/scrape.go#L39 https://github.com/sergiotapia/gophers/blob/master/scrape.go... You tell me which one is nicer to look at and easier to understand.
- viach 10y ago
  Elixir is nicer to look at, Go is easier to understand.
  - themgt 10y ago
    I find "nice to look at" and "easier to understand" tend to converge over time. Elixir pushes me to expand my mental maps a bit more than Go, but once I grok it the code reads much more coherently and concisely. Go to me reads like an ELI5 programming language.
    - erikpukinskis 10y ago
      In some ways they converge, in some ways not. On some level "nice to look at" means everything conveys some meaning, and nothing is obviously awkward. "Easy to understand" means everything you might need to know is on the screen. Those things are often aligned, but sometimes orthogonal. Put another way, you can make something that looks simple and pleasing, but hides a lot of complexity that's required to understand in order to be able to do your work.
    - mixedCase 10y ago
      >I find "nice to look at" and "easier to understand" tend to converge over time. Elixir pushes me to expand my mental maps a bit more than Go, but once I grok it the code reads much more coherently and concisely. Sounds like something that won't hold up as well over time.
AmazingLifeBot 10y ago
What an amazing time to be alive! (Sorry for missing yesterday's Go post - I was down for maintenance)
bluejekyll 10y ago
> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler? Go made the decision to allow for Null, even after nearly every other modern language and other older ones are trying to kick it to the curb; Swift, Rust, Scala, Kotlin, no nulls (the JVM ones have a compatability problem, as does swift with ObjC, but still). Is it simpler to delay discovery of Null data to runtime? Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more. So yes, it's simpler, but at too high a cost IMO. To me the innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. This is a million times better than JVM, Ruby, Python, Perl, etc. This is a huge improvement over Java, and something every language should have an option for. Ironically this is also the least innovative feature, because this is how static binaries in C and C++ have worked for years. I think this article is very well written, but I don't think it's fair to the innovation going on in other languages. (Disclaimer: I used Go, discovered the three primary flaws as I listed above, and then searched for a better language. It would be fair to call me a hater, usually I try to avoid this, but in this case that's fine with me)
- catnaroek 10y ago
  > Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taking subtyping for granted. But what if subtyping isn't always a good idea? Say, because it forces you to reason about variance (which humans always seem to do wrong!). (inb4: Yes, Go has subtyping. When a struct conforms to a given interface, that's subtyping.)
knucklesandwich 10y ago
Accusing other languages of suffering from paralysis of choice and fragmentation and offering "go get" as an example of solving this is truly ironic: https://github.com/avelino/awesome-go#package-management https://github.com/avelino/awesome-go#package-management
- IshKebab 10y ago
  Why? `go get` is an obvious default choice for package management. You don't have to make a choice. There would be paralysis of choice if when you install Go you were forced to choose from that list, but you aren't.
  - knucklesandwich 10y ago
    You'd have a point if the default with Go was a good choice. In practice its not. It's a terrible choice that gives you no ability to use multiple versions of a package (across projects), control a project's dependency's versions, vendor a dependency or build from your system build directory on a case by case basis, etc. The entire build chain with Go is probably one of the most frustratingly limited build tools I've ever used, which is probably why nearly every Go developer I've met has switched to using one of the third party options.
  - bobbyi_settv 10y ago
    I don't see how something that doesn't allow pinning versions can be an obvious default choice for dependency management.
  - spriggan3 10y ago
    > Why? `go get` is an obvious default choice for package management. I thought go get wasn't a package manager /s
junke 10y ago
So, Go is designed to be an engineering language and not an academic toy. Contrary to other languages, Go programmers "deliver" and have a pragmatic view of the real development world, not just their own commits. Go programmers need a deeper understanding of computer science because other programmers are lazy and have everything given for free and probably don't need to know how it works. A whole page discussing the virtues of Go by insulting people.
- codygman 10y ago
  Go doesn't make real world programming easier. It makes you work hard for pointless things. Most of its problems are from a lack of generics.
  - thatswrong0 10y ago
    Yep. Add those and a proper type system and you have yourself a decent language. But when the creator of the language doesn't see the value in abstractions [0], then it's probably never going to happen. [0] https://github.com/robpike/filter https://github.com/robpike/filter
    - RodgerTheGreat 10y ago
      His formulation of reduce() is strikingly clumsy, both in signature and implementation. I daresay I wouldn't have much use for such a function either! Most languages which provide a reduce() permit programmers to provide an initial "carry-in" value. This is a neater and more useful way to handle the cases of a zero- or one-element list. Moreover, it lets you do more interesting things with the reduction. Consider the following, using ES6-style JavaScript to collect a set of the unique values of a list via reduce(): function unique(list) { return list.reduce(function (sofar, item) { if (!sofar.includes(item)) { sofar.push(item); } return sofar; }, []); }
      - randomdata 10y ago
        To be fair, even with a well designed interface, it is difficult to see the advantage of your example over using a simple for loop: func unique(list []int) (r []int) { for i := range list { if !includes(r, i) { r = append(r, i) } } return }
codygman 10y ago
As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cases for your code hurts productivity. I also believe that languages exist to make getting to an end result in given domains easier. Go does not make my life easier. I really hope it gets generics. I wish it would do away with nil/null. Nim is a very good language that actually accomplishes the simplicity Go wanted imo. Go affords simplicity to the Go compiler writers at the cost of burdening Go users with having to remember inane things.
- skybrian 10y ago
  Having tried to use Go for analytics, I agree that it's not a good fit for that use case. (It does work well for scripts and simple servers, though.)
  - snaky 10y ago
    Looking at things people write in Go, I can't shake the feeling Go is a new /bin/sh with xinetd built in.
    - drvdevd 10y ago
      The way I personally use it ... I'd say you're exactly right. And adding that to an easy cross compilation/platform story that can side-step C toolchains in many cases, garbage collection, and intelligible concurrency, and you've got an extremely useful tool.
      - snaky 10y ago
        So the main reasons for Go are the fact 'coproc' keyword added to Bash since version 4 is still considered experimental[1] and the fact that a vast majority of modern developers don't know shell good enough. [1] https://www.reddit.com/r/bash/comments/4ksl7w/golanglike_goroutines_in_bash/ https://www.reddit.com/r/bash/comments/4ksl7w/golanglike_gor...
tux1968 10y ago
The article mentions a keynote speech by Rob Pike* from 2012 which is quite illuminating. The trade-offs made were all centered around google-scale and the pain points of such a massive operation. It stands to reason that people working outside of that environment may be less pleased with the language. [*] https://www.infoq.com/presentations/Go-Google https://www.infoq.com/presentations/Go-Google
- 20yrs_no_equity 10y ago
  Google is not the only entity that operates at scale, and simply because google does it does not mean it is the correct choice. That's kinda cargo cultish. In distributed systems, go is fragile and dangerous -- because it will panic. IT has no supervision system, and it has the potential for deadlocks, in fact, unless you engineer around it, all coroutines and channels will produce deadlocks and can silently kill your program. When that happens you have no idea why things are broken-- nothings happening. And this is a language without a decent debugger!
  - lossolo 10y ago
    > In distributed systems, go is fragile and dangerous -- because it will panic. Do you know when it will panic? Do you know you can recover from panic if you for example want to communicate with other systems that this node is going offline? > it has the potential for deadlocks I could write that for most of languages that have mutexes. This is design problem, not language problem. > When that happens you have no idea why things are broken-- nothings happening. It's only true if you do not know how to use debugger and don't know how language features you use works.
    - deleted 10y ago
      [deleted]
- SZJX 10y ago
  tbh I don't think workers even inside of that environment will be much pleased either. The managers are likely pleased because it speeds up the organizational efficiency, but that doesn't necessarily have anything to do with the happiness of the developers who actually write code and have to bear its many unpleasantness. That's just two separate things.
unsignedqword 10y ago
I'm not much of a Go programmer but I would definitely regard Go's multiple return and error handling (save the 'no assertions' clause) as very cool. I'm not sure if any other languages have experimented with that approach before the rise of Go, but to me at least it appears much saner than the prevalent ridiculousness of exception handling.
- herval 10y ago
  Some languages support tuples - you can also use stuff like ADTs to the same effect. I think Go's advantage here is that it's the only way to handle non-panic exceptions, so you won't have systems where half of the errors are handled with exceptions and half with returning tuples, for instance...(I personally like the lack of "throwing exceptions" part, but find the multiple-return somewhat exotic)
  - unsignedqword 10y ago
    Handling it as tuples is just as fine, but it's important that a language intending to do so be devoid of verbosity and cruft. For example, D supports tuples, but I would not want to attempt Go-style error handling in it: https://rosettacode.org/wiki/Return_multiple_values#D https://rosettacode.org/wiki/Return_multiple_values#D You make a good point, too, that multiple-return being the only way to do errors is more ideal than the language saying "oh, we support that, but we also have exceptions, too!" At least in a language with Go's philosophy, you can expect other people's libraries and your own code to play by the same rules.
- 20yrs_no_equity 10y ago
  Multiple return is great, though sending a tuple back is how we've been doing it in erlang for 20 years. Not much difference between {foo, bar} and (foo, bar). Go's error handling however is terrible, absolutely the worst and its tendency to panic is atrocious. Especially without supervision or restart capability. HEre's a spot where elixir has it right and is vastly superior.
  - grey-area 10y ago
jbeja 10y ago
Not this zealotry again.
Myrmornis 10y ago
> Custom data structures can be composed from the well understood builtins, rolled in under 100 lines of code and can can exist close to the place they are used (yes repeated!). The effect of this approach on readability, maintainability, decoupling, ... adds so much more value to the whole lifecycle, than the cost of the omission. It's interesting to me that this philosophy comes from the Go designers at Google, and that Google is also well known for keeping vast amounts of source code advancing in lock-step in a single repository. From reading the recent article on Google's source code repository structure, I believe that being able to reuse code (e.g. data structure implementations) without versioning headaches is one of the intended and actual benefits. It's of course not that surprising that two different areas (Go design and repository structure) might pull in two different directions, but these are two important high level issues so it does seem a little inconsistent to me.
jksmith 10y ago
What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success. Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far? The reason why golang appears to have such wide adoption in such a short period of time is that it really does seem to contribute to helping devs get their shit done. Massive amounts of working code are being written in golang, and that's good for the software industry as a whole. Currently I run a massive project written in the standard issue kitchen sink corporate language (C#). It's got generics, functional extensions, all kinds of shit to make the most discriminating programmer happy. Well guess what, IMO C# for all it's features still doesn't serve the business of software dev as well as golang because it doesn't pull off what golang is brilliant at (easy to code for wide range of skill levels, easy to mentor, easy to test, easy to hire for). The result is difficulty finding productive devs, and a code base that is not up to my preferred quality standards. This may be hard to swallow, but it might really be the case that you can get more quality work done with more devs if toolchain simplicity is emphasized over language features. If the evidence continues to bear this out for golang, then it's time for me to shed some language biases just so I can remain competitive.
- xiaoma 10y ago
  Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a much steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.
  - karma_vaccum123 10y ago
    Wikipedia says Elixir first appeared in 2012, while Go first appeared in November 2009. Go is not that much older than Elixir...so I don't buy your analysis. By time Go was four years old, it had much greater adoption than Elixir does today.
  - geodel 10y ago
    Go 1.0 is released in March 2012 so it is not even half decade old.
bad_user 10y ago
As some people like to point out, I'd also like to remind that in 1968 Algol had: - user defined record types - user defined sum types - switch/case statement with support for sum types - unified syntax for value and reference types - closures with lexical scoping - parallelism support - multi-pass compilation Given that many mainstream languages don't offer even what Algo68 had, I personally understand how a Go developer might thing that "nothing is new under the sun" since the 80's. After all, Go ignores all progress in programming languages for the last 40 years. I recommend watching "Growing a Language", a legendary presentation by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 I do love the attempts of Go developers to rationalize Go's choices. But in the end it will end up being a hated language, universally recognized as a net negative in the industry. But that won't stop the working programmer from doing the same mistake again and again.
- jacques_chester 10y ago
  The most famous writeup, discussed here when it emerged 7 years ago, was "Go vs Brand X". http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
  - _ak 10y ago
    And where is Algol now? It's dead. Theoretical superiority on paper is worth absolutely nothing when there is no usable implementation for modern computing environments out there. This article was written to make Go look bad and unoriginal, but it inadvertently proves that Go is Algol's legitimate successor exactly _because_ it has all these features _and_ a working implementation that is available for wide variety of architectures and operating systems.
    - jacques_chester 10y ago
      I think Pascal (and Modula and Oberon) are more legitimate successors to Algol. I wasn't aware that all of those working implementations had stopped working. Popularity is just one dimension a language can be placed on. Java utterly dominates the volume of new code being written in regular industry and has most likely done so for the entire lifetime of Go. And this says little about their other relative virtues.
behnamoh 10y ago
I'm not a Golang programmer, but the mere fact that GOOG decided Java for android is convincing enough that even GOOG does not believe in its Go. (Frankly, I doubted that a little, until I realized Al-*-Go was not actually written in Go!)
- oautholaf 10y ago
  Uhh, as someone who was there when Android began: There was no Go in 2005. And anyway, Go started with explicit about initial goal of being a server-side language, with choices (eg, only static linking) appropriate for that goal.
- seabrookmx 10y ago
  Android predates Go. And it wasn't even started by Google.. Android was it's own company and had already made it's decision on Java well before Google decided to buy it. Not to mention Go is focused on a different use case. Go is gunning for microservices (with it's concurrency chops) and CLI based tools (being a single compiled binary).. whereas Android apps are a totally different beast that stands little to gain from either of those. In fact shipping multiple binaries for different architectures is a bit of a detractor for Android considering it supports MIPS, ARM, and x86. > until I realized Al-*-Go was not actually written in Go! Again, AlphaGo was based off technology from DeepMind, a company Google acquired. Please atleast do some quick wikipedia browsing before spewing FUD.
  - oautholaf 10y ago
    As someone who was there, let me say that the decision to use Java was definitely not made before the Google acquisition. The codebase that came with the acquisition was C++/JavaScript and was completely rewritten.
  - deleted 10y ago
    [deleted]
  - behnamoh 10y ago
    > Android predates Go... So? Apple introduced Swift after Obj-C to make developing iOS apps easier. What about GOOG? Couldn't they at least use Dart or Go (both of which they developed) for android app development after Java? BTW, last time I checked, they're still in for a lot to come from Oracle. > Again, Al-*-Go was based off technology from ... So let me get this straight. They bought a technology which was apparently written in C++/JS and rewrote it in another lang, but then again, they did not choose Go or Dart. Seems like some one needs a wikipedia browsing...
bpicolo 10y ago
> Finally, in certain problem domains the power and flexibility of a hash-map is also unavoidable, therefore Go provides a Map built in Not a fan of this sentence. Why try to make it sound like Maps are unusual or bad? Just as fundamental as the list to real programming.
p0nce 10y ago
> To provide any solution in Go that needs a dynamic data structure you can choose between hand rolled linked structures or a Slice or Map (or compose with them). As they are quite different the choice is normally obvious. Contrast this to the choice between map, set, hashset, bag etc etc, or rolling your own in a language that makes this a lot harder. I can't help but think the whole article is filled with bursts of dishonesty. A language like C++, which let you use the proper data-structure in about two lines of code, is a lot easier when it comes to data-structures. While the Go programmer implements a multi-map, priority-queue or red-black tree, anyone else will have moved on to an actual topic of interest. If you need a particular data-structure, surely having one ready in the toolbox is a net positive, not a negative.
danmux 10y ago
The irony in all of these comments is that they almost all fall back to, or start with, discussing language design, and on the whole ignore the tools and processes that have a consistency from Go team to Go team. The value of this power and consistency is probably overlooked in this and many other conversations because they are complex to discuss, and it is simply easier to focus on the almost provable value of the language features, missing or present (maybe another availability bias at work?). The point of the article was to try and refocus on Go as an engineering tool in a much broader context.
SZJX 10y ago
> It is not ‘missing’ comprehensions, or inheritance, or generics, they are omitted (and I pray, always will be). In some way, in the context of the current fashion of returning to more functional languages, or the evolution of good old languages to include more functional paradigms (I’m looking at you Javascript and Python for two examples) then in a tenuous convoluted way Go has ‘innovated’ by avoiding that trend. That's such a weird statement. If anything, those are likely more OOP-related than FP-related, and he didn't really point out what's so bad about "more functional paradigms", besides the implication that it might be harder for new hires to pick up etc. Anyways, I see that Go reduces the learning curve and simplifies lifecycle of huge projects, but at considerable costs about language features and expressiveness. I myself if working as a developer would rather not bear those costs just for the sake of the whole clogs of the organization running a bit more smoothly, and also so that myself would not just program day-in day-out en masse with everybody else out there in an overly simplified language that potentially puts me at more of a disadvantage in my career path. Maybe the leaders of huge companies would have other thoughts and there will definitely be developers who are happy to fill those roles, it's just not me.

168 points by elrodeo 10y ago

If you make a program that is executed a million of times or more a day, it make sense to have a language that is "near the CPU", and allows to optimize and speed up the most. This is what Go is. It will be a mistake to use it elsewhere.

catnaroek 10y ago
C++, otherwise a deeply flawed language, gives you more abstraction than Go and allows you to optimize and micromanage things more.
- pjmlp 10y ago
  Not only C++, there are plenty of options. The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety.
  - codygman 10y ago
    One thing I can credit Go for is leading me from the untyped world to the typed one. I soon found the holes in the Go type system, and went looking for a stronger type system. I now generally prefer Haskell.
    - snaky 10y ago
      If Go is from typed world, then Perl too. Some magical built-in types (scalar, array, hash, typeglob, regexp, io handle) you cannot confuse, interface{} is scalar holding a reference, and built-in datatypes (arrays and hashes) are magical and you cannot construct something similar. Well, at least there's 'tie' mechanics in Perl after all that makes types extensible.
      - codygman 10y ago
        Go is more from the typed world than Python where I came from. It will tell you at compile time you are using a string rather than an int (unless you use interface{}).
        snaky 10y ago
        The only difference is a selection of basic types. There's just no such types as string or int in Perl, Perl is a contextually polymorphic language whose scalars can be strings, numbers, or references (which includes objects). Although strings and numbers are considered pretty much the same thing for nearly all purposes, references are strongly-typed, uncastable pointers with builtin reference-counting and destructor invocation.
        codygman 10y ago
        For me the compile time and runtime distinctions are more important.
        snaky 10y ago
        Reflection you need to use, whether it be with interface{} in Go or with $scalar in Perl is runtime thing. reflect.TypeOf(tst), ref($tst) - there's no much difference. Type mismatch errors for basic types are handled in compile time, be it Go or Perl.
  - remus 10y ago
    >The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety. You say that like it's a small thing, but what proportion of bugs in C code does that cover? Im guessing you'd hit over 50%.
    - pjmlp 10y ago
      It is a small thing because there are other languages that offer the same safety with more features and lets face it, if a C coder is willing to embrace a GC enabled language there are lots to chose from, with AOT compilation to native code. I just expected more from Google, specially if one compares to the other company sponsored languages.
      - snaky 10y ago
        Comparing apples to apples, the first compiler sponsored by 'other company' was PHP, so Go looks not that bad in comparison. Reason is second, and maybe Google's second language would be 1ML.
        pjmlp 10y ago
        Actually I was thinking in all languages that had commercial compilers, which goes way back than just PHP.
- TillE 10y ago
  I love how C++ has had simple features like default arguments / function overloading for decades, while modern languages like Go and Rust require awkward workarounds. Swift 3 looks good, though. They've learned the right lessons.
  - catnaroek 10y ago
    Default arguments, at least as done in C++, complicate the language's semantics (e.g., template specialization selection) far more than they raise the level abstraction. Definitely not a well-designed feature. And Rust's traits are a far more principled (and thus better!) approach to overloading than anything C++ has (Boost's concept checks?). Traits turn concepts into language entities that are directly expressible in Rust syntax, rather than in awkward English documentation.
  - dominotw 10y ago
    C++'s problem was never 'not enough features' it was precisely the opposite.
  - pcwalton 10y ago
    There are also features that Rust has that C++ doesn't. So what?
  - tomjakubowski 10y ago
    I certainly wouldn't say these are "simple features" in C++. Overload resolution in particular is one of the most complicated parts of the language. Default arguments can get weird since the right hand side of the default, more or less, just gets inlined at the call site; I do recall there were a couple bugs in the last year at work because of C++ default arguments, though I don't remember their details. It's also fun when you don't realize a particular function has a default argument until you make a function pointer to it and assign/pass it to something that you mistakenly think is compatible. Depending on how nasty your codebase's use of templates and overloaded functions is, this can be a nightmare to debug.
soulbadguy 10y ago
Golang is only 'near cpu' when compared to python or ruby. Golang is much closer to java/c# then c/c++
- xyproto 10y ago
  Go (the language) have at least two implementations: the official Go implementation and GCC (yes, Go is included in GCC, along with Fortran and Ada). The latest Go implementation (Go 1.7) has made Go a lot faster. I would argue that it closer the speed of executables generated with GCC (gcc/g++) than OpenJDK, the Oracle JVM, Mono or the .NET compiler for C#. Go (the language) can be made just as fast as C (the language), for many cases. Go has the advantage of making it much easier to use multiple processors, though.
  - vvanders 10y ago
    Until you have control over stack/heap and data locality you're never going to be able to approach C/C++/Rust speeds. Conversely if you're using C/C++ through a ton of heap/virtual pointers then you're losing a lot of the value the language brings and should be using something higher level.
    - dilap 10y ago
      Go allocates on the heap unless it can prove something doesn't escape, in which case it's on the stack. Not explicit programmer control, but I think you can reasonably make it do what you want. Because it exposes pointers as a first-class concept, you also have good control of how data is laid out in memory (=> locality). It's not like Python or Java where everything is a pointer and gets spread out all over memory.
      - vvanders 10y ago
        Can you do an arena allocator in Go with disparate types? If not then you're really missing out on data locality. In also not a huge fan of a compiler "automatically" performing escape analysis. Makes a single change causing cascading perf problems very easy and hard to catch.

sergiotapia 10y ago

The author is quite correct. Go is super boring, and runs fast. Two great points for it. For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit. The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of code that's easy to understand. Here's just one example from me - both examples scrape some info from HTML: Elixir: https://github.com/sergiotapia/magnetissimo/blob/master/lib/parsers/demonoid.ex#L36 https://github.com/sergiotapia/magnetissimo/blob/master/lib/... Go: https://github.com/sergiotapia/gophers/blob/master/scrape.go#L39 https://github.com/sergiotapia/gophers/blob/master/scrape.go... You tell me which one is nicer to look at and easier to understand.

viach 10y ago
Elixir is nicer to look at, Go is easier to understand.
- themgt 10y ago
  I find "nice to look at" and "easier to understand" tend to converge over time. Elixir pushes me to expand my mental maps a bit more than Go, but once I grok it the code reads much more coherently and concisely. Go to me reads like an ELI5 programming language.
  - erikpukinskis 10y ago
    In some ways they converge, in some ways not. On some level "nice to look at" means everything conveys some meaning, and nothing is obviously awkward. "Easy to understand" means everything you might need to know is on the screen. Those things are often aligned, but sometimes orthogonal. Put another way, you can make something that looks simple and pleasing, but hides a lot of complexity that's required to understand in order to be able to do your work.
  - mixedCase 10y ago
    >I find "nice to look at" and "easier to understand" tend to converge over time. Elixir pushes me to expand my mental maps a bit more than Go, but once I grok it the code reads much more coherently and concisely. Sounds like something that won't hold up as well over time.

AmazingLifeBot 10y ago

What an amazing time to be alive! (Sorry for missing yesterday's Go post - I was down for maintenance)

bluejekyll 10y ago

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler? Go made the decision to allow for Null, even after nearly every other modern language and other older ones are trying to kick it to the curb; Swift, Rust, Scala, Kotlin, no nulls (the JVM ones have a compatability problem, as does swift with ObjC, but still). Is it simpler to delay discovery of Null data to runtime? Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more. So yes, it's simpler, but at too high a cost IMO. To me the innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. This is a million times better than JVM, Ruby, Python, Perl, etc. This is a huge improvement over Java, and something every language should have an option for. Ironically this is also the least innovative feature, because this is how static binaries in C and C++ have worked for years. I think this article is very well written, but I don't think it's fair to the innovation going on in other languages. (Disclaimer: I used Go, discovered the three primary flaws as I listed above, and then searched for a better language. It would be fair to call me a hater, usually I try to avoid this, but in this case that's fine with me)

catnaroek 10y ago
> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taking subtyping for granted. But what if subtyping isn't always a good idea? Say, because it forces you to reason about variance (which humans always seem to do wrong!). (inb4: Yes, Go has subtyping. When a struct conforms to a given interface, that's subtyping.)

knucklesandwich 10y ago

Accusing other languages of suffering from paralysis of choice and fragmentation and offering "go get" as an example of solving this is truly ironic: https://github.com/avelino/awesome-go#package-management https://github.com/avelino/awesome-go#package-management

IshKebab 10y ago
Why? `go get` is an obvious default choice for package management. You don't have to make a choice. There would be paralysis of choice if when you install Go you were forced to choose from that list, but you aren't.
- knucklesandwich 10y ago
  You'd have a point if the default with Go was a good choice. In practice its not. It's a terrible choice that gives you no ability to use multiple versions of a package (across projects), control a project's dependency's versions, vendor a dependency or build from your system build directory on a case by case basis, etc. The entire build chain with Go is probably one of the most frustratingly limited build tools I've ever used, which is probably why nearly every Go developer I've met has switched to using one of the third party options.
- bobbyi_settv 10y ago
  I don't see how something that doesn't allow pinning versions can be an obvious default choice for dependency management.
- spriggan3 10y ago
  > Why? `go get` is an obvious default choice for package management. I thought go get wasn't a package manager /s

junke 10y ago

So, Go is designed to be an engineering language and not an academic toy. Contrary to other languages, Go programmers "deliver" and have a pragmatic view of the real development world, not just their own commits. Go programmers need a deeper understanding of computer science because other programmers are lazy and have everything given for free and probably don't need to know how it works. A whole page discussing the virtues of Go by insulting people.

codygman 10y ago
Go doesn't make real world programming easier. It makes you work hard for pointless things. Most of its problems are from a lack of generics.
- thatswrong0 10y ago
  Yep. Add those and a proper type system and you have yourself a decent language. But when the creator of the language doesn't see the value in abstractions [0], then it's probably never going to happen. [0] https://github.com/robpike/filter https://github.com/robpike/filter
  - RodgerTheGreat 10y ago
    His formulation of reduce() is strikingly clumsy, both in signature and implementation. I daresay I wouldn't have much use for such a function either! Most languages which provide a reduce() permit programmers to provide an initial "carry-in" value. This is a neater and more useful way to handle the cases of a zero- or one-element list. Moreover, it lets you do more interesting things with the reduction. Consider the following, using ES6-style JavaScript to collect a set of the unique values of a list via reduce(): function unique(list) { return list.reduce(function (sofar, item) { if (!sofar.includes(item)) { sofar.push(item); } return sofar; }, []); }
    - randomdata 10y ago
      To be fair, even with a well designed interface, it is difficult to see the advantage of your example over using a simple for loop: func unique(list []int) (r []int) { for i := range list { if !includes(r, i) { r = append(r, i) } } return }

codygman 10y ago

As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cases for your code hurts productivity. I also believe that languages exist to make getting to an end result in given domains easier. Go does not make my life easier. I really hope it gets generics. I wish it would do away with nil/null. Nim is a very good language that actually accomplishes the simplicity Go wanted imo. Go affords simplicity to the Go compiler writers at the cost of burdening Go users with having to remember inane things.

skybrian 10y ago
Having tried to use Go for analytics, I agree that it's not a good fit for that use case. (It does work well for scripts and simple servers, though.)
- snaky 10y ago
  Looking at things people write in Go, I can't shake the feeling Go is a new /bin/sh with xinetd built in.
  - drvdevd 10y ago
    The way I personally use it ... I'd say you're exactly right. And adding that to an easy cross compilation/platform story that can side-step C toolchains in many cases, garbage collection, and intelligible concurrency, and you've got an extremely useful tool.
    - snaky 10y ago
      So the main reasons for Go are the fact 'coproc' keyword added to Bash since version 4 is still considered experimental[1] and the fact that a vast majority of modern developers don't know shell good enough. [1] https://www.reddit.com/r/bash/comments/4ksl7w/golanglike_goroutines_in_bash/ https://www.reddit.com/r/bash/comments/4ksl7w/golanglike_gor...

tux1968 10y ago

The article mentions a keynote speech by Rob Pike* from 2012 which is quite illuminating. The trade-offs made were all centered around google-scale and the pain points of such a massive operation. It stands to reason that people working outside of that environment may be less pleased with the language. [*] https://www.infoq.com/presentations/Go-Google https://www.infoq.com/presentations/Go-Google

20yrs_no_equity 10y ago
Google is not the only entity that operates at scale, and simply because google does it does not mean it is the correct choice. That's kinda cargo cultish. In distributed systems, go is fragile and dangerous -- because it will panic. IT has no supervision system, and it has the potential for deadlocks, in fact, unless you engineer around it, all coroutines and channels will produce deadlocks and can silently kill your program. When that happens you have no idea why things are broken-- nothings happening. And this is a language without a decent debugger!
- lossolo 10y ago
  > In distributed systems, go is fragile and dangerous -- because it will panic. Do you know when it will panic? Do you know you can recover from panic if you for example want to communicate with other systems that this node is going offline? > it has the potential for deadlocks I could write that for most of languages that have mutexes. This is design problem, not language problem. > When that happens you have no idea why things are broken-- nothings happening. It's only true if you do not know how to use debugger and don't know how language features you use works.
  - deleted 10y ago
    [deleted]
SZJX 10y ago
tbh I don't think workers even inside of that environment will be much pleased either. The managers are likely pleased because it speeds up the organizational efficiency, but that doesn't necessarily have anything to do with the happiness of the developers who actually write code and have to bear its many unpleasantness. That's just two separate things.

unsignedqword 10y ago

I'm not much of a Go programmer but I would definitely regard Go's multiple return and error handling (save the 'no assertions' clause) as very cool. I'm not sure if any other languages have experimented with that approach before the rise of Go, but to me at least it appears much saner than the prevalent ridiculousness of exception handling.

herval 10y ago
Some languages support tuples - you can also use stuff like ADTs to the same effect. I think Go's advantage here is that it's the only way to handle non-panic exceptions, so you won't have systems where half of the errors are handled with exceptions and half with returning tuples, for instance...(I personally like the lack of "throwing exceptions" part, but find the multiple-return somewhat exotic)
- unsignedqword 10y ago
  Handling it as tuples is just as fine, but it's important that a language intending to do so be devoid of verbosity and cruft. For example, D supports tuples, but I would not want to attempt Go-style error handling in it: https://rosettacode.org/wiki/Return_multiple_values#D https://rosettacode.org/wiki/Return_multiple_values#D You make a good point, too, that multiple-return being the only way to do errors is more ideal than the language saying "oh, we support that, but we also have exceptions, too!" At least in a language with Go's philosophy, you can expect other people's libraries and your own code to play by the same rules.
20yrs_no_equity 10y ago
Multiple return is great, though sending a tuple back is how we've been doing it in erlang for 20 years. Not much difference between {foo, bar} and (foo, bar). Go's error handling however is terrible, absolutely the worst and its tendency to panic is atrocious. Especially without supervision or restart capability. HEre's a spot where elixir has it right and is vastly superior.
- grey-area 10y ago

jbeja 10y ago

Not this zealotry again.

Myrmornis 10y ago

> Custom data structures can be composed from the well understood builtins, rolled in under 100 lines of code and can can exist close to the place they are used (yes repeated!). The effect of this approach on readability, maintainability, decoupling, ... adds so much more value to the whole lifecycle, than the cost of the omission. It's interesting to me that this philosophy comes from the Go designers at Google, and that Google is also well known for keeping vast amounts of source code advancing in lock-step in a single repository. From reading the recent article on Google's source code repository structure, I believe that being able to reuse code (e.g. data structure implementations) without versioning headaches is one of the intended and actual benefits. It's of course not that surprising that two different areas (Go design and repository structure) might pull in two different directions, but these are two important high level issues so it does seem a little inconsistent to me.

jksmith 10y ago

What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success. Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far? The reason why golang appears to have such wide adoption in such a short period of time is that it really does seem to contribute to helping devs get their shit done. Massive amounts of working code are being written in golang, and that's good for the software industry as a whole. Currently I run a massive project written in the standard issue kitchen sink corporate language (C#). It's got generics, functional extensions, all kinds of shit to make the most discriminating programmer happy. Well guess what, IMO C# for all it's features still doesn't serve the business of software dev as well as golang because it doesn't pull off what golang is brilliant at (easy to code for wide range of skill levels, easy to mentor, easy to test, easy to hire for). The result is difficulty finding productive devs, and a code base that is not up to my preferred quality standards. This may be hard to swallow, but it might really be the case that you can get more quality work done with more devs if toolchain simplicity is emphasized over language features. If the evidence continues to bear this out for golang, then it's time for me to shed some language biases just so I can remain competitive.

xiaoma 10y ago
Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a much steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.
- karma_vaccum123 10y ago
  Wikipedia says Elixir first appeared in 2012, while Go first appeared in November 2009. Go is not that much older than Elixir...so I don't buy your analysis. By time Go was four years old, it had much greater adoption than Elixir does today.
- geodel 10y ago
  Go 1.0 is released in March 2012 so it is not even half decade old.

bad_user 10y ago

As some people like to point out, I'd also like to remind that in 1968 Algol had: - user defined record types - user defined sum types - switch/case statement with support for sum types - unified syntax for value and reference types - closures with lexical scoping - parallelism support - multi-pass compilation Given that many mainstream languages don't offer even what Algo68 had, I personally understand how a Go developer might thing that "nothing is new under the sun" since the 80's. After all, Go ignores all progress in programming languages for the last 40 years. I recommend watching "Growing a Language", a legendary presentation by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 I do love the attempts of Go developers to rationalize Go's choices. But in the end it will end up being a hated language, universally recognized as a net negative in the industry. But that won't stop the working programmer from doing the same mistake again and again.

jacques_chester 10y ago
The most famous writeup, discussed here when it emerged 7 years ago, was "Go vs Brand X". http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
- _ak 10y ago
  And where is Algol now? It's dead. Theoretical superiority on paper is worth absolutely nothing when there is no usable implementation for modern computing environments out there. This article was written to make Go look bad and unoriginal, but it inadvertently proves that Go is Algol's legitimate successor exactly _because_ it has all these features _and_ a working implementation that is available for wide variety of architectures and operating systems.
  - jacques_chester 10y ago
    I think Pascal (and Modula and Oberon) are more legitimate successors to Algol. I wasn't aware that all of those working implementations had stopped working. Popularity is just one dimension a language can be placed on. Java utterly dominates the volume of new code being written in regular industry and has most likely done so for the entire lifetime of Go. And this says little about their other relative virtues.

behnamoh 10y ago

I'm not a Golang programmer, but the mere fact that GOOG decided Java for android is convincing enough that even GOOG does not believe in its Go. (Frankly, I doubted that a little, until I realized Al-*-Go was not actually written in Go!)

oautholaf 10y ago
Uhh, as someone who was there when Android began: There was no Go in 2005. And anyway, Go started with explicit about initial goal of being a server-side language, with choices (eg, only static linking) appropriate for that goal.
seabrookmx 10y ago
Android predates Go. And it wasn't even started by Google.. Android was it's own company and had already made it's decision on Java well before Google decided to buy it. Not to mention Go is focused on a different use case. Go is gunning for microservices (with it's concurrency chops) and CLI based tools (being a single compiled binary).. whereas Android apps are a totally different beast that stands little to gain from either of those. In fact shipping multiple binaries for different architectures is a bit of a detractor for Android considering it supports MIPS, ARM, and x86. > until I realized Al-*-Go was not actually written in Go! Again, AlphaGo was based off technology from DeepMind, a company Google acquired. Please atleast do some quick wikipedia browsing before spewing FUD.
- oautholaf 10y ago
  As someone who was there, let me say that the decision to use Java was definitely not made before the Google acquisition. The codebase that came with the acquisition was C++/JavaScript and was completely rewritten.
- deleted 10y ago
  [deleted]
- behnamoh 10y ago
  > Android predates Go... So? Apple introduced Swift after Obj-C to make developing iOS apps easier. What about GOOG? Couldn't they at least use Dart or Go (both of which they developed) for android app development after Java? BTW, last time I checked, they're still in for a lot to come from Oracle. > Again, Al-*-Go was based off technology from ... So let me get this straight. They bought a technology which was apparently written in C++/JS and rewrote it in another lang, but then again, they did not choose Go or Dart. Seems like some one needs a wikipedia browsing...

bpicolo 10y ago

> Finally, in certain problem domains the power and flexibility of a hash-map is also unavoidable, therefore Go provides a Map built in Not a fan of this sentence. Why try to make it sound like Maps are unusual or bad? Just as fundamental as the list to real programming.

p0nce 10y ago

> To provide any solution in Go that needs a dynamic data structure you can choose between hand rolled linked structures or a Slice or Map (or compose with them). As they are quite different the choice is normally obvious. Contrast this to the choice between map, set, hashset, bag etc etc, or rolling your own in a language that makes this a lot harder. I can't help but think the whole article is filled with bursts of dishonesty. A language like C++, which let you use the proper data-structure in about two lines of code, is a lot easier when it comes to data-structures. While the Go programmer implements a multi-map, priority-queue or red-black tree, anyone else will have moved on to an actual topic of interest. If you need a particular data-structure, surely having one ready in the toolbox is a net positive, not a negative.

danmux 10y ago

The irony in all of these comments is that they almost all fall back to, or start with, discussing language design, and on the whole ignore the tools and processes that have a consistency from Go team to Go team. The value of this power and consistency is probably overlooked in this and many other conversations because they are complex to discuss, and it is simply easier to focus on the almost provable value of the language features, missing or present (maybe another availability bias at work?). The point of the article was to try and refocus on Go as an engineering tool in a much broader context.

SZJX 10y ago

> It is not ‘missing’ comprehensions, or inheritance, or generics, they are omitted (and I pray, always will be). In some way, in the context of the current fashion of returning to more functional languages, or the evolution of good old languages to include more functional paradigms (I’m looking at you Javascript and Python for two examples) then in a tenuous convoluted way Go has ‘innovated’ by avoiding that trend. That's such a weird statement. If anything, those are likely more OOP-related than FP-related, and he didn't really point out what's so bad about "more functional paradigms", besides the implication that it might be harder for new hires to pick up etc. Anyways, I see that Go reduces the learning curve and simplifies lifecycle of huge projects, but at considerable costs about language features and expressiveness. I myself if working as a developer would rather not bear those costs just for the sake of the whole clogs of the organization running a bit more smoothly, and also so that myself would not just program day-in day-out en masse with everybody else out there in an overly simplified language that potentially puts me at more of a disadvantage in my career path. Maybe the leaders of huge companies would have other thoughts and there will definitely be developers who are happy to fill those roles, it's just not me.