Why Go’s design is a disservice to intelligent programmers

Over the course of the past few months I’ve been using Go to implement a proof of concept program in my spare time. This was done in part to learn Go and to also see if such a program would work. The program itself is very simplistic and not the focus of this article but my experience of using Go is worth writing a few words. Go is shaping up to be a popular language for doing serious large scale work and a language created by Google is not to be sniffed at. With all that said, I honestly think Go’s design is a disservice to intelligent programmers.

Created for lesser programmers?

An Introduction to Programming in GoGo is very easy to learn, in fact it’s so easy it took me one evening to read an introductory text and be productive almost immediately. The book I learned from was entitled An Introduction to Programming in Go and is available on-line. Similar to Go, the book is easy to read with good examples and clocking in at about 150 pages you can finish it in one sitting. Initially this simplicity starts off very refreshing in a programming world full of overly complicated technologies but there’s a niggling thought of “Is that it?”.

Google maintains that Go’s simplicity is a selling point and it’s designed that way for maximising productivity in large teams but I’m not convinced. There are aspects of Go that are either seriously lacking or overly verbose because it doesn’t trust developers to get things right. This focus on simplicity was a concious decision made by the language designers and in order to fully understand why, we need to understand the motivation for developing Go and the state of mind of the creators.

So why create it so simple? Well, here’s a few quotes from Rob Pike:

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
– Rob Pike 1

It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.
– Rob Pike 2

What? So Rob Pike is basically saying that the developers at Google aren’t very good so they’ve developed a dumbed down language so they can get things done. What a condescending view on your own employees. I’ve always thought that the developers at Google are hand picked from the brightest and best on Earth. Surely they can handle something a little more complicated?

Artifacts of being too simple

Being simple is a noble pursuit of any design and trying to make something simple is hard. However, when trying to solve (or even express) complicated problems you sometimes need a complicated tool. Of course too much complexity is bad in programming but there is a nice middle ground when the language allows you to create elegant abstractions that make things easier to understand and use. From my experience of using Go it’s just too simple to create useful abstractions.

Not very expressive

Because Go is so simple most constructs that other languages take for granted have been left out. On the surface this looks like a good idea but when confronted with a problem you can only write verbose code. A reason for Go’s simplicity is to help developers read other people’s code but being overly simplistic actually hurts readability. There are no shortcuts in Go, it’s verbose code or nothing.

For example, if you are writing a command line tool that needs to read text input from stdin or a file passed as an argument, you might do it like this:

Although this code is trying to be as generic as possible you are hamstrung by Go’s forced verbosity and a simple task ends up being a lot of code.

Here’s the same example using the D language:

Now, which one is more readable? I’d choose the D version. It’s a lot more readable purely because it’s expressing the program’s intent in a much more clear way. This code also uses concepts that are more advanced than the Go code but they’re nothing too complicated that an intelligent programmer couldn’t pick up quickly and easily.

Boiler plate hell

A feature often requested for Go is support for generics. This would at least allow for stopping all the unnecessary boiler plate code that has to be created to support all needed data types. If for example you’d like to create a function which calculates the sum of a list of integers you are immediately sentenced to implementing the same function for all needed data types. There simply is no other way around it.

Here’s an example:

This example doesn’t even implement all the integer types, just the signed ones. This is a complete violation of DRY, one of programmings most well known and understood principles and ignoring it is a huge source of bugs. Why on Earth would you want to do this? This is a terrible facet of Go.

Here’s the same example in D:

Simple, elegant and straight to the point. Here the reduce function can handle any type and the predicate (passed as a template parameter) defines how to reduce the list. Yes it’s more complicated than Go but not so complicated that intelligent programmers can’t understand it. Which is more maintainable and easy to read?

An easily circumvented type system

I guess by now Go programmers reading this will be frothing at the mouth shouting “You’re doing it wrong!”. Well, there is another way of implementing generic functions and data types, and that is to completely break the type system!

Check this example out for a showcase of stupidity patching a language to overcome shortfalls:

This Reduce implementation was taken from an on-line article entitled Idiomatic generics in Go. Well if that’s idiomatic, i’d hate to see un-idiomatic. Using interface{} is a farce and is only included in the language to circumvent type checking. It is an empty interface which is implicitly implemented by all types allowing a total free for all. This style of programming is as ugly as hell and not only that but to perform such acrobatics in the above example you are also forced to use runtime reflection. Even Rob Pike doesn’t like people abusing reflection and has mentioned this in many talks.

It’s a powerful tool that should be used with care and avoided unless strictly necessary.
– Rob Pike 3

I’d take D’s templates any day over this nonsense. How can anyone say interface{}  is more readable or even type safe?

Dependency management woes

Go has a built-in dependency system which is built upon popular source control hosting services. The tools that ship with Go are aware of these services and can retrieve code from them, install and build it in one fell swoop. While this is great, there is a major oversight and that is versioning! Yes that’s right you can retrieve source code from services such as github or bitbucket using the Go tools but you can’t specify a version of the code. Again this screams that the design has been made as simple as possible to the detriment of being useful. I can’t fathom the thinking behind such a decision.

When questions where asked about this state the Go team wrote a forum thread outlining how they where going to get around this issue. Their recommendation was to just copy the entire repository at that time into your project and leave it as-is. What the hell are they thinking? We have these awesome source control systems with great tagging and version support which the Go creators ignore and just copy the whole thing around.

Cultural baggage from C

In my opinion Go has been designed by people who have been using C all their lives and don’t want to try anything new. The language could be described as C with training wheels. There is no new ideas in the language apart from the concurrency support (which is excellent by the way) and it’s such a shame. You have this great concurrency support in a barely usable, hamstrung language.

Another grating issue is that because Go is procedural (just like C ‘shock horror’) you start writing code in a procedural way which feels archaic and old hat. I know object-oriented programming is no silver bullet but it would have been nice to be able to abstract details away into types and provide better encapsulation.

Simplicity for its own sake

Go was designed to be simple and it has succeeded in that goal. It has been written for lesser programmers using an old language as a template. It comes complete with simple tools for doing simple things. It is simple to learn and simple to use.

It’s overly verbose, inexpressive and a disservice to intelligent programmers everywhere.

Submit a comment


  1. Agree 100%. If D was the only language with these ‘advanced’ features such as *generics*/templates, the argument would be less strong. But when *java*, a programing language already used by google has them, it shows there isn’t really any excuse for Go’s poor design.

    I suppose Go might be a nice soft landing for script kiddies coming from python or php land (that aren’t as brave as others who are jumping into strongly typed functional language), but I don’t think that’s who will end up carrying the language.

    I’m not sure D will ever take off, but Rust might, or an ML variant, and Go will be a forgotten relic in history.

  2. God save us from “intelligent” programmers (or those who *think* they’re intelligent based on some very subjective criteria of what makes someone intelligent). If I could never spend another hour looking at obfuscated C++ macro and template meta-programming hell built by self-professed “geniuses”, I’d die a happy man.

    Go wasn’t created by stupid people and it’s not used by stupid people. But it’s used, a lot, and more and more, to create real solutions for real people on real projects. Why wasn’t Docker written in D? Those Docker people sure must be very unintelligent in your eyes. Spotify? They will surely fail for using Go as well, instead of D. Kubenetes? A non-starter, obviously, very unintelligent project. Also not in D.

    And Google? That has-been company has at most a year left before it collapses under the weight of all the projects that were internally written in Go. If only they were smart enough to use D!

    Go is becoming a success. And I think ultimately, you *hate* that. You want it to fail. Its very existence is an affront to everything you hold dear. If Go were to become a success, it would somehow invalidate all your past successes and efforts.

    Too bad. Go is coming. Rust is coming. Node JS is coming. More and more start-ups are picking them up (and not looking back), more and more projects are using these languages. D tried. It did. A noble effort. But ultimately, in the long term, it’s not going anywhere.

    And that’s the real cause of your pain, isn’t it? That people are picking Go (and soon Rust) over D.

    • You may have a point here, but your examples of good software are off. Spotify, a closed source music player? What’s innovative in this? It’s a good service (or so I heard), because of its UX, not because of how it’s made. Docker, a poorly designed command line wrapper for lxc which could have been written in bash?

      • It could also have been written in C, but it wasn’t.

    • I can understand why you have a beef with intelligent programmers.

    • “If I could never spend another hour looking at obfuscated C++ macro and template meta-programming hell built by self-professed “geniuses”, I’d die a happy man.”

      So every language is either as dumbed-down as Go, or as stupidly over-complicated as C++? Are these the only two languages you know?

      “Go is becoming a success. And I think ultimately, you *hate* that. You want it to fail. Its very existence is an affront to everything you hold dear. If Go were to become a success, it would somehow invalidate all your past successes and efforts.”

      …because the only reason someone could possibly dislike what you like is because of massive character flaws and an inflated ego? That’s quite an assumption you’re making. Why are you so emotionally invested in Go, anyway?

      “Go is coming. Rust is coming.”

      And Rust is excellent. In fact, it addresses almost all of Go’s problems mentioned in this post. I’m not sure what you’re getting at here–are you saying that because both Rust and Go are new, Go doesn’t suck? Or did you think the author was also criticizing Rust? Because he never mentioned Rust and these two languages have absolutely nothing to do with each other anyway.

    • Could not agree more with this comment. Having been a hard-core Perl and C programmer most of my life for Nike and IBM and now teaching Go as one of our main languages to very intelligent 8-18 year olds I can say Go has a solid future. I’m glad a language as well thought out as this insults “intelligent” programmers like this author (who would not have been hired by me or any of the teams I’ve ever worked on, in fact we fired “intelligent” programmers like this for a reason). Enjoy your intelligence.

      • Agree 100 per cent with you! As a very “unintelligent” software developer with over 25 years of IT experience (using C, C++, C#, Objective-C, Java, Python, FORTRAN, Smalltalk) and having led the Windows NT group at ATI Technologies (now AMD), I am surely a fool for loving Go and its nice, clean syntax, productive toolchain, and ample library ecosystem. My pragmatic nature and preference for easy-to-learn tools clearly reflect a profound lack of intelligence. Shame on me!

        • That’s great! With all this experience perhaps you could address the actual points made in the article? Oh, that’s right, you can’t.

        • You know I wouldn’t brag about those credentials. ATI had the shitiest drivers for Windows, and drivers are the number one reason I stick with NVidia… And AMD continues to have issue with Windows.


          Keep braggen but you don’t have much to brag about.

        • I won’t speculate about your intelligence, but is it not telling that you do not address any of the points in the original post, but instead feel insulted by the criticism of GO?

          The fact that the import system is broken by design and that you can’t even change missing imports from error to warning, should make people wonder if GO is a child’s toy.

  3. Hrm, I considered myself on the upper end of programmer ability, able to think logically, transfer skills from language to language relatively easily, understand what makes a compiler tick, and build an OS from scratch. But little did I know, I’m just a “lesser” programmer because I enjoy Go’s simplicity. Thanks for the insult!

    • A mark of stupidity is a complete inability to understand what someone has written, substituting something else entirely or even the opposite … as you have done.

    • So f*cking sick of “my d*ck is longer” mentality in software “engineering” world. How many years will it take to realize that intelligence isn’t measured on the same scale? How long to understand that singular dedication to one purpose is a waste of a life?

      A language should be simple enough for an average developer to fall into “the pit of success”. It should also allow an above average programmer to express himself without creating an un-maintainable mess.

      Go write assembly x86,you pricks.

      • Assembly is very simple conceptually and as bad at abstraction. In that regard, Go is much closer to assembly than D.

  4. Please write a 10kLOC program in the language, BEFORE judge the language!

    The simplicity is great for maintaining large programs: everybody can read and understand in seconds every part of the program!

    Dependency management: all those tags and branches on remote repos are just promises!
    If you depend hard on those repos, you should vendor that code, otherwise you may be surprised in the future, when someone introduces a change, that she thinks backwards-compatible, but your program will misbehave with it!
    If that’s acceptable, then use the wonderful gopkg.in service.

  5. I couldn’t agree more. I tried to program in Go. I bought some books. I feel more or less confident in Go. One thing I loved about it were channels. I dumped Go, because:

    * You have no control over goroutine’s lifecycle. You can’t check if it is alive. You are not notified when it dies. You have no means of killing it. I might be biased as Erlang programmer, but goroutines are really crippled.

    * Flat module namespace. A major drawback for any larger team. You may have deep-nested module structure, but one that matters and points to right function is last part of module path. So for module “mylib/network/udp/port/*.go” functions are referred by port.something and will clash with “mylib/serial/port/*.go”. You need rename-on-import to overcome this. Really PitA.

    * Exotic compiler. Go’s C/C++ compiler does not follow standard C calling convention and therefore Go’s libraries can’t be directly linked with native libraries – be it Windows or Linux. You have a neat wrapper generator, yet it has measurable overhead.

    * Returning “tuples” from functions. Properly implemented it has lots of sense, but it needs pattern matching built into language (see Erlang standard library). Go’s “if error!=nil” repeated thousands of times throughout the code makes my eyes bleed. This is the part of Go I hate the most, especially knowing, that Go has exceptions (well, sort of, panic/recover is a very limited mechanism).

    * Lack of proper generics (already mentioned).

    On the other hand:

    * Go developers circumvented lack of git import versioning by use of gopkg.in service. Imports look like "gopkg.in/qml.v1".

    * Go’s channels are brilliant. I wish there was such mechanism in Erlang – while it has message queues, they are anonymous queues one-per-process. You can’t do a simple fanout protocol as in Go.

    • Go has had import renaming since the beginning.

      Now you can reference them as udpPort.something and serPort.something in the code.

    • “I wish there was such mechanism in Erlang”
      This one can trivially implement in Erlang via a helper process. Processes are cheap in Erlang.
      Erlang will not however typecheck statically, ofc.

  6. Dear sir,

    Do you realize that your whole first Go code snippet can be replaced with a single call to ioutil.Read{All,File}?

    Moreover if there’s no data piped to os.Stdin, you’re program will simply hang, so it’s poorly built.

  7. The argument of having to re-implement a sum function for every datatype therefore go sucks does not convince me anymore, show me a real life program that needs a sum for every datatype, signed and unsigned, and I’ll show you a overcomplicated solution to a problem. Think about it, summing more than a few signed bytes will require an accumulator variabele which is of a bigger type. So convert the bytes to int64 while summing and voila only 1 summing function needed.
    This is the direction of thought Go forces you in. Unify and generalize, convert all your types to bytes as soon as possible, make your byte formats processable without marshalling, so you can process and route your data and ship it over to some other process without lots of overhead. Please,don’t complain a workhorse doesn’t know how to do fancy showpony tricks. Just let it pull carts loaded with piles of data. That’s what it is good at.
    After 10 years of seeing programmers trying to use C#’s every new trick to solve a solved problem just because they were bored that day (myself included) I think a boring programming language like Go is a stroke of genius.

    • yes, you’re right, I also didn’t like the fact that is using a function to do a sum, and in the D example is using the + operator, it doesn’t seems to be good to make a comparison without even the same stuff.

    • Thank you! Finally, some wisdom over “intelligence”!

  8. Please use Real-World-Examples when you are arguing about issues with a language. There are probably Perl/APL one liners for both problems this doesn’t mean they are the best language for writing everything.

    Anyways… first example:

    Of course this isn’t an ideal solution either, because it doesn’t work on large files properly. Anyways, you probably wouldn’t write this program in the first place… because you already have cat and tr.
    For the second example you would write:

    Of course unlikely, because you usually don’t need sum over multiple types at the same time. You probably will only use int for some particular case.

    Third example, why the hell would you write a reduce function if you only need sum?

    • I agree the author examples are not the best, but your response is ugly as hell, wtf is doing? :S


    • Jesus, my eyes are bleeding! I think I prefer the D code.

  9. Your Go code is wrong in so many ways!

    The Dry argument is somehow valid. There are packages that can generate that code for you, and they are pretty easy to use and integrate in your build procedure.

    The versioning is not valid at all, there are packages that can help you with that and probably this will be addressed in future versions of go. Those packages are just like using bundler in Ruby, or composer in PHP…

    The other points are invalid and only shows that the author thinks that “a better programer” is someone who uses exceptions for everything and cannot stand “lesser programmers” who can write better code that he can, just because the tool doesn’t take a century to be learn.

    p.s. I like the error handling in go, but if you don’t like it, and want to be a “an intelligent programmer”(sarcasm) you can use panic.

    Go is a simple tool that can do a lot, it is not a silver bullet, neither is D or any other language that is out there.

    A developer with 15 years of experience should know better, than to judge a programming language.

  10. Just one question – if you’re right, why Go, and not D, is chosen for the majority of new projects in system/networking software?

    Probably something wrong with your arguments.

    • Go [...] is chosen for the majority of new projects in system/networking software?

      [[citation needed]]

      • Docker
        CoreOS tooling

        I could probably Go like this all day. What do you have on the other side – Puppet, Chef? They’re not being picked for new projects.

        • In order as alternatives NOT in Go:

          • Docker -> Libvirt
          • Racket -> Um, what? Racket is a language that is not Go. How exactly does this support “Go is popular”?
          • Flynn -> Again, what? Flynn is written in Ruby, not Go.
          • Deis -> Pick any Java application server, almost all of which have remote management tools.
          • Terraform/Consul/Serf (way to list vertical products as separate things in a lame attempt to prove your superiority) -> Puppet (and yes, it is being used for “new projects” in rather important sectors), Microsoft Orchestrator and System Center, etc.
          • Raft -> For the third time, WTF? Raft is an algorithm with full implementations in several languages including C++, Erlang, Java, Javascript, Scala, and even POSIX shell script. Adding Go to that list still doesn’t support the argument.
          • etcd -> Cassandra, MongoDB, etc.
          • kubernetes -> libvirt, Salt
          • CoreOS tooling -> Really? You’re going to use a single niche OS to claim popularity? Equally idiotic counter-claim: Gentoo uses Python, therefore Python is more popular than other languages.
          • Flynn is written Go not Ruby.
            Comparing Deis(Paas) with Java application server really?
            Docker and Libvirt are totally different things (Containers vs Virtualisation)

    • So do you imply that JavaScript is a much better language than Haskell (or if you wish Go) because is used in more projects ?

      Quality for you is equal with quantity ?

      Justin Bieber is a better musician than Mozart ?

      • Nice comparsion, really. But not in this case, though.

        From theoretical ground – Haskell is much better language, yes. But reality is simply don’t need that ‘better qualities’. It’s much more like evolutionary process – there are incentives, payoffs and profits of using one or another language, and Haskell doesn’t win here. You may argue million times, that JS is worse, but still, JavaScript has properties that made it de-facto language for web applications. You may or may not understand the reasons, but you can’t fight the reality.

        The same with Go. There are a lot of people, who think ‘simpler is better’. You may not agree with them, but still – they find it more practical, more productive, and it has a lot of qualities that make people choose Go over other languages and quickly develop great software (without generics). Look, you’re getting much higher real productivity with less costs. That’s it.
        And the most beautiful thing here, that it’s not the occasion. Go Authors have very profound understanding of the industry, so they designed it that way on purpose.

        • In that case PHP is a better language, hahahaha. Java, ObjectiveC,… come on.

          • Hey now. You leave ObjC out of this. ObjC never did anything to you.

        • What are reasons for js to be most popular language except it’s the only choice on the client side ?

        • Thank you, The Rational Dude! I love the wisdom, despise the “intelligence”.

          Hey kids, instead of repeating “Google made Go” mantra, look at the list of authors. Authority matters to you, doesn’t it? It doesn’t? OK, think of it this way, Ken Thompson has seen more programming mistakes in his life than you will ever produce in yours.

    • In that case PHP is a super duper better language, hahahaha. Also Java, ObjectiveC, C, Python, Scala, Erlang… come on.

      I don’t think that you could compare a language based on its popularity over a specific niche.

    • “Probably something wrong with your arguments.”


      Nice fallacy.

    • Because it is simple like hell for any programmer with a procedural background who is not really spoiled with OO or any architecture. And that is the 60% of the developers hammering code w/o ever making an architecture for 10.000+ LOC, thinking about strategies of logging, protocols etc. They can be good at maintaining 100.000+ LOC, always scoping to the particular problem.
      Go tries to be an answer to the common problems of the industry, reducing code-entropy, forcing single policies. I chose Go at the current company for projects and not because I like it, but because I find it fit the problem and hopefully it will not stink and rot early.
      Yes, Go can make the average programmers more effective offering a tool that forces writing solid code, for small – mid-sized projects, likely a service based environment, on the back-end. And for most of the daily life this is enough. At the cost of verbosity, copy-paste. But overall serves the purpose. But I have two other where I would never use Go because I see where I’ll hit the wall with it.
      however, Go will never make You more than that, because there is no hierarchy in the language, not any kind, and that does not help to think highly abstract. In the world of Go the architects will take this role.
      If You want elegance pick a functional language. Are they simple? Not. Are they expressive and elegant? Yes. Do we need them in the daily code smithing? As per my experience – You need programmers. Easy to teach into Your problem and technology. So they can hammer the daily metal.

  11. I scanned the comments and felt I had to step in and say something (famous last words).

    Google didn’t create a “dumb” language for “dumb” employees. A majority of Google’s staffers are young and fresh out of college- but certainly not “dumb”. I find Rob’s statements to be on point. How do you catch up a young twenty-something who needs to start writing production ready code as soon as possible? You make a language familiar, simple, but fast enough that your products don’t suffer. If Google was hell-bent on using only the most powerful language I’m sure we’d expect every Googler to know three lisp dialects- but we don’t, because that’s unreasonable.

    • I know three lisp dialects (CL, Scheme, Emacs Lisp).
      If you know one, picking up another is about as hard as learning a new library.

  12. People who didn’t like Go, most likely didn’t understand Go.

    • Yeah, the usual argument : you don’t like something you don’t understand it.

      Let me ask you a simple question : what’s the difference between subtype polymorphism and parametric polymorphism ?

    • “People who didn’t like Go, most likely didn’t understand Go.”

      Textbook ad hominem fallacy.

    • I obviously struck a nerve if Dave Cheney has to try and calm the waters. ;)

      • Yes, you so obviously struck a nerve that Dave Cheney went back in time and published his article before yours.

      • Well whoops, my bad I thought that was referencing his article about simplicity, not a followup.

  13. Never liked GO, it solves no problems I have ever faced. Anyway reading the comments from GO supporters (target audience) here enlightens me why I dislike the language.

  14. I think Pike was misquoted and meant “not incapable”. I. E. They’re not incapable of understanding a brilliant language.

    The point being that language designers to us on brilliant languages rather than making sure the programs written in the language are maintainable and contribute to a large env environment without encouraging behaviors that bite you in the future.

    A lot of the “problems” in Go that people cite are solutions to problems that are very real in production at google. You don’t have those problems today but you will soon. OR, you do have those problems but you are so used to them that when someone offers a solution you can’t see the value.


    • Thank you, wise words. Kids, the future is: a lot of data coming sat you fast. It’s not about pretty constructs, it’s about being practical, even if cruel. Go works, accept it.

  15. I agree on your points. Another major Go drawback is the lack of exceptions. Actually Go DOES have an exceptions. panic/recover is exactly exception implementation. But standard library is not build with exceptions in mind so they are basically unusable unless you’re willing to reimplement standard library.

    Almost any modern language nowadays thrown return codes out of window. What a strange design decision to use return codes in 21 century?

    I know Rust and I like it. In rust it justified by 0-cost abstraction principle. And return codes in Rust actually are usable in contrast with Go.

    Go have solid implementation and brilliant engineers are working on it. Good GC, unmatched parallelism. What a shame to have such limited language a top of such powerful engine.

    • Go doesn’t use “return codes” for error handling. You don’t return just an int, you can return the error itself with a specific type, message and information. You can use them for controlling the flow of the application. Panic/recover is not like an exception. You can “recover” from panic only in a defer statement. The idea is that you don’t have try/catch blocks that are used for flow control in your application.

      I find the error handling pretty nice actually. If a function is returning an error – it can fail, and you should check about it (if you care). It is not perfect, because sometimes you have a lot of

      but it helps you see what can fail and where.

  16. this is a poor article. it does very little to convince me of anything about the Go language. it succeeds only in convincing me that the author is a condescending, arrogant, jerk.

    • > the author is a condescending, arrogant, jerk.

      No, I don’t think so, but I think the tone was intended to invoke that reaction. The paths the author takes are all well tread at this point, regardless of your opinion on their validity. The tone and inherent defensiveness instilled into the Go community (why still?!) is guaranteed to bring in debate and comments. I just wish the pro-Go side were a bit less personal in their replies. Nothing quite like calling someone an asshole for calling people assholes.

      • I would not put all the negative answers under the “Go community” hat. Here is a thread in reddit about this article, and I don’t see anyone calling the author an asshole. Also you can look at the comments in Hacker news as well. Most of the comments in this article are not the work of the “Go community”.

    • Yours is a poor comment that succeed only in convincing me that you’re a stupid and dishonest troll.

  17. Or maybe it’s just you.

    Your first example could have been boiled down to (removing the arbitrary verbosity that you injected)

    You complain that Go is written for stupid developers, and yet you somehow find the most convoluted, difficult way to write something? This example doesn’t even use some odd quirk known only to Go gurus — it’s in a package called “ioutil”, fer chrissake.

    That’s just hyperbole, though. Your other points are valid. Go doesn’t have generics because nobody has yet suggested a way to implement generics that doesn’t suck. They’re either slow or ugly. We certainly don’t want Java generics, and most experienced developers implement a “no templates” rule if they choose to use C++ (D unfortunately followed the C++ model for generics,). Generics in Go would be good, if somebody finds a way to make it fast to compile, fast to execute, and without the huge code bloat of templates.

    I also sympathize with your point about dependency management. Vendoring is a horrible, ugly solution, but it seems to be the way the Go community is veering. It does solve the repeatable build concern.

    Your bias against procedural languages is simple prejudice. I’ve seen no indication or proof that OO provides any better code, and a lot of evidence that it results in much worse code and design. Functional programming is great, but procedural programming is still king of practicality. And Go provides plenty of opportunity for encapsulation and abstraction; you just didn’t spend enough time learning about it to understand it.

    Try setting your D bias aside and spend some time learning deeper beyond the introductory “hello world” documentation, and you can avoid mistakes like this. That’s what smart people do.

    • “Go doesn’t have generics because nobody has yet suggested a way to implement generics that doesn’t suck.”

  18. While it’s nice to see you took the time to pen your thoughts, if you haven’t used Go to write production code, you’re completely missing the point.

    Go is a language designed in the service of software engineering. Software engineering is about production code.

    Write production code in Go and then you will realise how wrong you really are.

  19. From the first example and the responses in the comments it looks like you don’t know Go or its stdlib. So why write about it instead of sticking to D. Truth is the adoption of Go is getting under the skin of the users of some other languages like D that haven’t taken off.

    Go is basically C with a few pitfalls eliminated… nothing more, nothing less. Those that use it just like those that like C just want to think about a problem logically and write the code to solve it. They don’t care about fancy language features or choosing between them. They don’t care about engineering functions to support an infinite number of types when they know they’ll never use more than one in their implementation. Its good for people that determine that they must do X, Y and Z and then do just that in a clear and straight forward manner with more focus on the problem and little focus on the language. This is probably why I see less “how do I do Y in language X” around the Go community than others. Some seem to be far more about wrangling the language than solving any problems.

    Now if you want to write generic libraries then its not so good. That obviously wasn’t the goal. But it appears that people are discovering that you need most of these libraries to wrap up solutions that are convoluted due to excessive baggage in the language. Its often so easy to just write what you need in Go that wrapping things up in a library feels like overkill. You might feel that this doesn’t make sense but that’s fine. Use D and have fun.

  20. C language heritage isn’t bad in itself. Being a “better C” isn’t bad in itself. Great things were accomplished in C. D-lang isn’t the silver bullet.

  21. Well, this post seems to have upset people. For what it’s worth, I agree, and although I think the phrase ‘created for lesser programmers’ is unfortunate, the thesis is on point: Go deliberately eschews expressiveness for compactness, hoping that a low barrier to entry will lead it to success.

    Personally, think the moment I lost my respect for Go was when I found the thread on the Golang Google Group about implementing basic map and reduce methods on collections.
    The response from the community was huffy, defensive and short sighted. “Why don’t you just use a for loop? That’s the Go idiom! Modern developers just can’t be bothered to write lots of code! I’ve been writing nothing but boilerplate C for the last forty years and it works for me! Don’t make suggestions until you’ve written ten thousand lines* of code in Go!”

    Ultimately, I think it’s fair to say that Go’s design is highly C-inspired, for both good and evil. Like Go, C is a compact language which requires tons of boilerplate. It’s probably fair to expect that of its grandchild too.

    The argument that the author needs to use Golang in production more before he can criticise it seems silly, though. Why would you embark on a project comprising thousands of man hours working on a platform you knowingly suspect to be inefficient?

    *Note: can we kill Gladwell’s “10,000″ hour myth now? Even he admits it was just a guesstimation

  22. One’s goal as a programmer is to write clear, maintainable, idiomatic code in whatever language one is using, and I would argue that languages encrusted with every feature known to man (and steadily growing) make that at least as difficult as a “too simple” language. Past a certain point, the problem should be the problem, not the programming language.

    OTOH, a complicated language can provide those who learn it with a feeling of self-importance. After all, one has invested a great deal of time and effort into learning it. I personally think that is at least part of what underlies people moving from Python and Ruby to Go rather than from C++ to Go.

  23. I don’t use Go for my daily programming. I do not care for it’s lack of (proper) metaprogramming.
    However I find it difficult to read any hard arguments in the article.
    The simplicity is something useful. Fact that I can read and understand complex, intricate, yet very short Haskel programs does not make reading (or writing) of such programs more efficient. Nor must the programs themselves be more efficient.
    I’d take take simplicity over complexity always.
    Go in fact allows very efficient programming whenever concurrent computations are required. I don’t have to exercise my knowledge of java concurrency to quickly write a decent concurrent program – what’s wrong with that?
    Go has also a few really useful features like built-in UTF support or support for binary operations on array elements of fixed length.
    And just before you ask, yes – I did produced a ‘medium’ sized project purely in go. It would be much simpler with generics yet it was simple enough. Go was right tool in that case and I wrote the whole thing amazingly quickly.

  24. During decades of programming, I’ve come to really respect the likes of Rob Pike. When they do something a particular way, it usually turns out to be what should have been done.

    Because Google produces breathtaking stuff, people usually assume that you simply have to be Genius Grade to even get to the job interview, and therefore every programmer there has to be a superior coder. The reality, however, is that there simply aren’t enough geniuses around. While Google (and Facebook and all the other places we admire) certainly does have their share of the best, the grim truth is that the bulk of the rest are between mediocre and fair, with also a sizable number of just inexperienced programmers.

    Now, the bulk of programming costs comes from debugging, and most bugs come from the lesser half of the programmers.

    This is why Go is “dumbed down”. If Google really only had geniuses or extremely able programmers, then their in-house language would be productive and expressive, but not necessarily fathomable by unskilled or untalented programmers. It wouldn’t need to.

    When Google decided they needed a new language, D simply was not ready for the task. Today, D is becoming a viable alternative. Facebook is already using D, and there are companies with products that would have been impossible to develop within a reasonable budget in any other language.

  25. So… There’s literally NO perfect language. One resolves one thing better, second resolves something else. This is like a war between Python and PHP. Could you guys pretty please just shut the fuck up about comparing languages and why D is better or C is better or Go or whatever fuck else. To the author of very very “agenda against Go” I wanna say that dude, I find your D ugly as fuck. Like seriously UGLY! You may not (obviously not) share opinion with me but that’s my opinion and I HAVE RIGHT to HAVE ONE as you do. Does that make me less smarter than you because I don’t like your shiny D? Well I hope so very much! I really don’t wanna be that smart!

    I admit there are things in go that should be done better but that language get the job done very well. Wrote with my own hands multiple projects that are processing millions and millions of messages per day and not even single fault is happening or something going very wrong. Language just works whether you like it or not.

    Reason why go does not allow you to do things that you as intelligent programmer wanna do is because not every one on this planet is as intelligent as you are. People NEED TO LEARN. While they learning best practices they on a daily basis make OUR, “intelligent programmer” days fucked up because we need to look and fix horrible code and just deal with it. Google wanted to eliminate that as much as possible and tell you hey, no you just fuck cannot do that!

    One additional thing to tell you is that you as obvious Go hater CANNOT write Go code as you DO NOT KNOW GOLANG. You might think that you know but your examples are to be polite, not the best. Before you next time write any golang-hate article, please please please, ask real golang developer to write them for you. You might find that examples he wrote are not as bad after all.

    All the best,

  26. Why people keep saying that generics/templates are complex for compiler? Basic templates are just substring substitution. In expressions like

    all occurrences of “T” are just replaced with actual type “int”, no smart logic here. It’s advanced stuff like template recursion, partial specialization and type deduction that really requires compiler to do to hard work of enumerating of all possible choices and selecting the best match. But all this advanced stuff is unnecessary IMHO, I participated in a C++ project with 1mloc of code and we had never used template recursion and partial template specialization and were happy about it.
    Basic generics/template support is easy and useful so you do not have to reimplement containers or algorithms each time for different data types. Min/Max/Sum algorithms are easy enough to rewrite them every time, but what about sort?
    In conclusion, I think basic generics will be implemented in Go sooner or later.

  27. D programmer here (7+ years of professional experience) that is researching Go:

    I don’t know if Go is all it says it is, but D is not all that great.
    – D breaks with every release, there is no clear language spec and features are bolted on regularly (which would not be a problem if it didn’t break existing things) so there is no feeling of security. Go on other hand, locked specs for v. 1 so people can expect that what they built will work in future. Simplicity of Go, compared to D, can be seen as quality.

    – Libraries and tools for D are usually of poor quality or obsolete. Lot of work got lost due to reason stated above – they worked once but then new version of D got released and people lost interest in upgrading/rewriting them to keep up. Again, D community got/was split one more than 1 stdlib and on more than 1 version of language and a lot of people left. Lot of basic tools or libraries were not included in D (even though were build repeatedly by community) so this is weak spot compared to Go.

    • These issues were maybe valid five or six years ago but not now. In the last few years there has been a tremendous commitment to stability. Also the spec is here: http://dlang.org/spec.html

  28. People in here have no idea what they’re talking about (type inference, channels come to mind as solutions to problems exposed above).

    As for the author well, wouldn’t expect a D and PHP fan to understand what’s elegant about Go. You probably code alone in your basement and shout at Jrs because they don’t understand the elegance of your 1000 feature language.

    Every language deserves consideration, D just like Go.

  29. Lol, I love to read these language wars, and how much passion a programmer can throw out of it, just for the pleassure.
    I have been using Go for 9 months and it takes me half the time to deliver a project than with C#/Java. Besides, it has a lower memory usage, fast as hell and no dependencies to install.
    The only thing I agree with is with the lack of generics. But there are so many advantages, that it doesn’t really matter.
    For me its a win-win, so is for my customers. Then being unintelligent is totally a relative word.

    • If you like Go and it’s speed but miss generics, just imagine how productive and happy you would be with a language such as D, which is much faster than Go and has generics.

  30. As others have commented here, your code examples are not optimal. It is possible to write very elegant code in Go. Having said that, no language is perfect. No language can always express things elegantly…including D.

    As a long-time C programmer, I appreciate the clean, simple Go syntax. And I don’t miss generics, just as I didn’t miss generics when I programmed in C for over 15 years. Both languages are fully capable of writing large software systems. We’re seeing broad adoption of Go by many companies. We’re seeing Go rocketing to prominence on TIOBE and Redmonk rankings. Obviously, many, many people appreciate the power and versatility of Go.

    I’m not a fan of “expressive” languages where the designer chooses to pile on feature after feature, thereby adding to the complexity. (I’m thinking, in particular, of Scala, but also C++.) I prefer a minimal set of orthogonal features that can be used to express your algorithms and data structures simply, even if it means some additional “verbosity.”

    Complex languages add to the cognitive burden of programming. They tend to make code harder to understand, if not harder to read. Elegant abstractions are all fine and good, but in my opinion, easy-to-read and easy-to-understand code is preferable. I don’t mind reading a bit more verbosity if it eases my cognitive load.

    And I’m a very intelligent programmer.

    While interface{} does bypass type-checking for the sake of flexibility, it’s not much different than in Python or Smalltalk where typing is dynamic. I’m a huge fan of Python and Smalltalk.

    And now Go.

    • Sorry, not TIOBE. TIOBE is such a retarded ranking system. Why is something like Logo and Inform at #29 and #37, respectively, and Haskell is at #48??? And Clojure, CoffeeScript, and Go aren’t even in the top 50 anymore. (In 2009, Go was TIOBE’s “Programming Language of the Year”. This year, JavaScript takes that honour.) Redmonk and langpop.corger.nl are much better, much more reliable systems.

    • I love wise people. Burned by experience, humble but sturdy. You are not “intelligent”, that’s what the college kids are, you are “wise”, Sir!

  31. This post is ugly as hell. Examples are bad. Examples for comparison are not doing same thing. Also you can write imports as one line in go too. This person just not an expert on the issue.

  32. Can you make a good review like this for Clojure? I’m a mediocre java programmer whom is confused as to why we are spending time taking out semicolons from java, scala (cough), apparently go as well (cough) or removing type system ruby, (cough).

    But as I’ve said, I’m mediocre and I’m very curious as to why can’t we just all use lisp style programming?

  33. Completely agree with the statement about concurrency.

    There is no new ideas in the language apart from the concurrency support (which is excellent by the way) and it’s such a shame. You have this great concurrency support in a barely usable, hamstrung language.

    I wish Python had awesome concurrency support like channels, and goroutines.

  34. Maybe it’s just me as a complete novice in Go but
    doesn’t it seem weird to anybody that
    out of 100 comments on this article (and lots more on reddit etc)
    there is no single one saying
    how to calculate a sum of integers in Go that works both for []int8 and []int64 ?

    Can somebody give a comprehensive and convincing answer to that part of the article?

    • Strange that, isn’t it?

    • Re-read the comments. Two-three posts at least, including one solution. The bottom-line, Go seemed to have been produced by people who solved real problems. The next time you have to sum across byte, int16, int32 and int64 just pick int64 as your “sum” variable type.

      BTW, for any contrived example, C++ will always win. What’s that? You want to get on with your life without spending half of it learning language intricacies? Thought so.

    • Who says we want a single implementation. I’m happy with one for int8 and one for int64:

        • “Better is a dry morsel and quietness with it Than a house full of feasting with strife.”
          — Proverbs 17:1

  35. years since go come to the world.
    and you read comments and past wars of the internet about Go vs the others… and more the times passes and more you the actual Golang actually literally dying : ressources complicate to use as hell, less and less support from the community, no GUI, famous real world application absolutly unimplementable in GO, at less by infinite manipulation and endless go bloody get… just a waste of time.
    Well, thank you, that Golang have been a very deep joke.

    • Delusions, it’s what for dinner. At least run Google trends before you run BS.

  36. You mention Go’s concurrency as one thing it has that D doesn’t. I invite you to look at core.thread.Fiber. Compare that with Go.

    Go’s goroutines are integrated into all IO. Blocking operations don’t block the whole program in Go. That’s convenient. It’s what Node.js was trying to achieve. 95% of the time, it’s what you want. But there’s plenty it doesn’t allow you to do:

    How do you yield from a coroutine? You perform a blocking operation. There’s no explicit “yield” function.

    You have a simulation consisting of actors. You want to ensure that they are scheduled once per simulation tick, and you care about the order in which they act. You wish to write their behaviors using coroutines because it’s much simpler. How do you do this in Go? You can’t.

    You want to kill a coroutine. Perhaps your simulation has an actor that was destroyed. Perhaps that coroutine was created for a user request that was canceled. How do you do that in Go? Everywhere your coroutine yields, after the yield, you explicitly check if the coroutine should exit.

    With D’s fibers, that’s all pretty easy. And fibers in D are nearly an afterthought. You don’t get is automatic conversion of blocking operations into yields in the standard library, and you don’t get channels, but both are solved in vibe.d.

    I’ve written 15-20KLOC in Go and probably 50+KLOC in D, and I’d recommend D before Go for most things. The only exception that comes to mind is corporate library support — Google and AWS have published SDKs for Go, for instance, but there is no such support for D.

  37. Go is a nice thing since it keeps all those substandard programmers from polluting the ecosystems around all those real programming languages. Srsly, just take a look at the comments above and you’ll see what I mean. Using some ugly templating to fill the holes in the type system or suggesting converting all numbers to int64 (what if I have int128?) is just pretty fucked up right here, and that is precisely what I have already seen in C++ (more template hacks upon template hacks!), Java (AbstractSingletonFactoryWhatever), and other programming communities.

    Thanks for your post btw. I didn’t know D was still alive these days.

  38. Those are insteresting points but what killed it for me was the very crap excuse they seem to be pushing… easy to use! Maybe it is maybe it isn’t I don’t know, I just couldn’t find a good book on Go which is an automatic no no on my part. On the other hand Google made Go for one purpose “the web” they took the C language and turned it into a giant turd. Its not meant to be Pythonic easy, we don’t need another high level wannabe titan.

  39. By making a programming language easy for almost everyone you are basically saying it is composed of the lowest common denominators of software design.

    Just think about that for a minute and all its ramifications.

    • Sure, let’s think about this. It means that the authors have seen so much sh*tty code from “intelligent engineers” that they’ve figured out how to develop a language to avoid common mistakes. Oh my god, what a horror, the language is “controlling my thoughts”.

  40. I completely 100% agree with this blog post. It sucks to say that even C# is more Dry than Go :( .

    There’s no way to dry up a LOT of code, especially when you get into channels etc.

    Case in point, every rest endpoint makes a database call, and every single call has to pass two separate channels (model channel, error channel) and the parameters for the DB query. It is the absolute opposite of DRY, but it’s so fast I can’t stop using it :\

    • Wide man. The kids just don’t get it. They want a shiny toy upfront, can’t dig for subtlety.

      • Wrong thread reply. M. Drapper’s post is idiotic.

      • Yes, subtilities like not calling anything you disagree with “idiotic”, I’m sure.

  41. Actually, anything from Google should always be sniffed at. Otherwise, you could miss the creeping stench of bloat, inefficiency and redundancy.

  42. I’m agree with your article, and it’s why i’ll continue to use Go !!!
    I had the same feeling with Go that I had with Python. The first time i see it i thought, what is this toy ? Ok, when it’s a toy i will play with it. It’s fun. Right, i continue. It works. Fine, i continue. It’s fast, i continue. Tt’s easy to maintain. Fine, i try it in production, i win money ! And now, why should i come back to (censured) most featured lang ?

    Today bikes (a toy for kids !) rides quicker than car in big town…

    • Wise man. The kids just don’t get it. They want a shiny toy upfront, can’t dig for subtlety.

  43. I have seen some small game projects in the wild made with GO recently, that to me suggests it has an undefined future. While it was nothing exceptional some the projects I saw seemed to handle memory management much better than a Java project. On another note graphically some of the games felt more closer to C# projects this seems like another case of win GO’s future.

  44. I see Go addressing some simple and generic use-cases. Look into most of the usual codes on the back end: data-decoration from different sources, business logic, etc. If anything, flat object hierarchy. Theoretically I miss the elegance of Haskell, even the generics, but … most of the time I do not use generics in procedural code. I know that I have integers or floats or whatever. No Ord class, for instance -, but I do not have to see how that particular data-type is made to be an Ord instance. And with custom data-structures I have to implement it anyway… On the other hand Go concurrency patterns help to architecture some problems performance-wise. Also the language is forcing to solve something on a given way resulting in rather homogeneous code that is readable. Scan some libraries… Go does not go far with abstractions – use the beautiful Haskell, then -, verbose, but far not as Java ( none blamed ), compiles fast, easy to deploy, etc. Do not try to look for the missing flexibility via interfaces – those are not to substitute generics. Those are to allow a type-cast into a different behavior, always one at a time. Maybe that is annoying, but it tries to keep everything related around the actual logic at the cost of repetitive code. If I pick the style of the back end code – thousands of lines of non OO heavy language – I see the similar ‘dumb’ world that Go brings to us. With Go I tend to trust more the average programmer, because he/she is not allowed to spread wings of abstractions. And that is often an advantage in itself…

  45. Anything higher level than assembler like Go is just another high-level abstract language and not for a hard-core programmer.

    Keep chasing that bit-dragon!

  46. Well, go sucks. None of posted responses reacted directly to criticism. Looks like lower programmers can’t handle reality. Tell me, why is so great to have no generics ? It’s not even OOP nor FP. It’s nothing. Maybe some relict from procedural history.

  47. Thanks for this article, I understood some parts but not everything, does anybody know of a good executive overview? I am just starting to get into programming so the code parts confused me a bit :)

  48. No one is looking for opinions. True developers just build something if environment easy to start with. So put your opinion in your underwears!!!

  49. Interesting article. You write D, have 15+ years of experience in software, work for a little known company called VictoriaPlum.com selling bathroom faucets , live in a walled city best known for its Gothic 13th century origins , making a few k Pounds per year (or rather Brexit-i-fied (read de-valued) Pound Sterling ).
    I write Go, have a little less than 5 years of experience and work for a company that is poised to change the face of how humans operate on this planet, live in the hub of technological innovation on the planet that congregates the best minds in the industry ( silicon valley) and make half a million bucks a year.

    • …but, but you didn’t address any of my arguments. Textbook ad hominem attack.

      • I addressed the crux of your argument.. Your post insinuates that go is a disservice to intelligent programmers. Assuming the people impacting the world through software can be classified as intelligent to some degree, and given the fact that they are using Go to build supporting frameworks for these projects, seems to imply that the crux of your argument is completely flawed. I suggest you re-title this post as . quite simply, “My take on Go’s design”

        • You’ve addressed nothing and the last comment doesn’t even read like English.

          I write Go, have a little less than 5 years of experience and work for a company that is poised to change the face of how humans operate on this planet, live in the hub of technological innovation on the planet that congregates the best minds in the industry ( silicon valley) and make half a million bucks a year.

          It always surprises me that people such as yourself always make wild claims but never use your real name, I wonder why?

    • In reply to ‘Googler’, You serve ads, get over yourself.

  50. Gary, I loved this comment thread — thank you for the amusing flame war, complete with ‘the old guy’ who calls everyone who agrees with him ‘wise’.

    This was truly entertaining and I’m forced to conclude as you did that Go contributes nothing. The existence of (verbosely written) libraries cannot overcome the poor expressiveness.

    Here’s wisdom: I like flexible, powerful, terse-but-highly-readable languages. I couldn’t care less about the libraries when I can express it myself.

    –and though it won’t stop the gophers– I’m as salty as they come: 90 languages, 22 years, hundreds of projects of every description on every platform. Beautiful, picasso-level code. Yes. PHP.

    They will never understand.

  51. python would be great lang for you, it is not verbose as much as go or even d. no int8, int16… just
    print sum([1,2,3,4])


  52. Awesome article man, I feel exactly the same way. Well done.

  53. Yep, definitely agree. I’ve written quite a bit of Go in high production environments. I couldn’t agree more. I felt like a robot writing it. It was so boring.

  54. So many butthurt comments, especially from those who write with Go. What a coincidence. :D Look, this language sucks big time. Take even the fact that up to this time there is no suitable debugger for it that would simply works. Don’t give me the bullshit about “gdb” and “ldb”, they don’t work well with Go. Yeah, there is Delve but its a hobby-project by someone and can’t be relied upon.

  55. Go concurrency model is nothing new, concurrentML has it around 1995-1997

  56. I have been using D I considered it to be a good language. Certainly better than C++. But it takes experience to master.

    Go’s strenght is its simplicity. As you say, it can be learn in a very short time. There are other things I don’t like in the language which are pitfalls. Using := with multiple return values. I got bitten by this a few times.

    For a professional project I had the choice to promote the use of D or Go. I finally promoted Go in place of D’for four main reason.
    1. Simplicity make it easy and fast to learn. The Go comunity size is growing fast
    2. Due to the growing user base, the amount of libs and tools available is growing fast too (remember the betamax VHS war). If I need something (ex. FITS image, Swagger) there is always at least one package/tool available.
    3. Poor performance of the D web server. Go’s fastHTTP is pretty good
    4. Programming in D requires to be intelligent and to activate many neurons. Go is simple to write and to read. It requires much less effort and neurons than programming in D so that programming is a pleasure again. It’s much less strain on the brain. I’m getting closer to 55 years old and had a burnout. So this is important to me.

    As long as the job is done in time and a newbie can quickly understand what some code does, who cares to be more intelligent ?

  57. I would like to add that simplicity is trump. Any programmer know that.

    When evaluating simplicity, one should not only consider the number of lines written. The amount of required knowledge matters too.

    Consider the following example. I could express some idea in only a few words taken from a dictionary of a million words, or 10 times more words but from a dictionary of only a tousand words.

    Which one is simpler ? My feeling is that the second would be simpler. It would be understandable by many more people than the first text.

    Of course you may consider it a diservice to intelligence to use only a tousand word dictionary, but what is the goal ? The goal is that as many people as possible can produce and read as many ideas as possible. This will yield the fastest progress in intelligence in the end, and this is what matter. The big size of the dictionary and the resulting conciseness of expression will loose the intelligence competition at the end.

  58. Why as D not exploded in popularity? How did Rush, Swift, Go come out of nowhere and surpassed D in popularity?

  59. You probably write a lot of bad code and naively don’t realize that the Go language was written by developers who have more individual and combined experience than you do. Why are you still writing Perl?!

  60. Go was invented to get us free from stupid class” makers”. A class over a class over a class over a class to get a config var… Who knows in our days what is a stack, pop, push, malloc, thread or mutex?

    If someone doesn’t know the power of a pointer or a structure, they should be quite, cause in the end thats the real stuff.

    This web site only exists cause of that lazy and stupid prog languages that makes tcp, arp, and real stuff work….

Submit a Comment

We would love to hear your thoughts. Feel free to submit a comment and join the conversation!

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">