17 ms·

Four days of Go

496 points by wtbob 12y ago

jgrahamc 12y ago
In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers, that is, the “bad” programmers. I think this is why some people dislike Go. The Go authors have made a decision about the language and are sticking to it. I get the impression that they are doing this because they believe they are 'right'. That makes some people uncomfortable because we programmers like to discuss everything, and argue, and it's hard to come up against people who have what is close to 'faith' in their own beliefs.
- aperture 12y ago
  I enjoyed that the author readily admits to his own faults concerning Go too: In this telling, the story of Go is really a tale of revenge, not just against slow builds, but against all kinds of sloppy programming. Which in my opinion is too bad, because I myself am a sloppy programmer. This really does seem to be the approach I see with the Go digest mailing list. What I don't understand though is the ease of importing a library, say from Github. Interesting that the language from the author is all about how rigid and unforgiving Go is, yet "some guys" libraries can just be thrown into the mix in your program, and Go has no issues with this.
  - mike_hearn 12y ago
    Go is developed inside Google where all dependencies are checked into their global version control repository. There are literally no versions inside the Google codebase - everything is compiled at head. If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project! Given this background and the Go designers focus on Google's internal needs, it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)
    - MetaCosm 12y ago
      > If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project! The alternative is of course supporting dozens or hundreds of copies of a library and every possible commit hash of said library. I contracted at a python shop that had 81 versions of a single library in use all pinned at different versions. The reason I know this is that I had the great joy of dealing with upgrading all of them after a critical hole was not only discovered (the company knew about it for some time, but just didn't want to bother updating all those apps) but exploited... repeatedly. > it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?) If by "fixed" you mean there are dozens of solutions to pin versions -- then yes. If you mean baked into the go tool, then no.
      - mike_hearn 12y ago
        Yes, I didn't pass judgement on the approach. It works well enough for Google and avoids problems with e.g. ELF symbol conflicts. For development out on the open internet you do need some way to specify versions so it's a puzzling lack, but "if it works for Google it works for you" does seem to be a recurring theme in the Go design.
      - _yosefk 12y ago
        But - but! Saying that you want your org to use one version of a library at a time is one thing. Saying that you want your code to use the latest version of every library is another thing altogether, however, and that's what "no version for github code" does, right? "One version per org" means "upgrades are harder, but patches are easier and you don't need to deal with different quirks of different versions at the same time and you don't get problems using 2 components that need 2 different versions of some other thing in one process etc." "Latest version, always" means you have no way to even build the latest version of your thing that was tested and is known to compile and work. Kinda sucks, I think.
    - aikah 12y ago
      > Given this background and the Go designers focus on Google's internal needs Does it mean the community isn't a priority? this vertical relationship between the Go team and the community could doom the language as fast as it was made popular, that's my opinion.That's a real issue.
- zerr 12y ago
  > faith Or arrogance and incompetence. It's been said many times. Go team should spend at least one day with Gilad Bracha...
  - deleted 12y ago
    [deleted]
  - laumars 12y ago
    I find it amusing that people would use the term "incompetence" to describe Ken Thompson and Rob Pike. These two guys have been as instrumental in shaping modern computing as Linus Torvalds, Bill Gates and Steve Jobs. But I guess it's easy to be critical of other peoples output when you're an anonymous internet user yourself.
    - zerr 12y ago
      Sorry, I thought it was clear - incompetence regarding [modern] language design. They don't deny this neither. And it seems they're even proud of this. > when you're an anonymous internet user It is easy to be honest, yes.
      - deleted 12y ago
        [deleted]
      - scott_s 12y ago
        I don't think your amended statement is much better. They have designed a language that meets their goals. They have decided not to include many things, but that does not mean that they are not aware of them, or are incompetent for doing so.
        0xdeadbeefbabe 12y ago
        Right, and what zerr calls incompetence could also be called post-modernism.
- howeyc 12y ago
  I think this is part of it, some of the hate comes from people that "know better" (possibly true for some, obviously the Go authors aren't omnipotent) than the Go language designers and are baffled that the language design ideas they know about aren't in the language. But I can tell you in my experience that this type of forceful "everything is a error, no warnings" and "it is done this way (formatting for instance)" are a breath of fresh air. Having dealt with team members that barely know how to program and think a compiler spitting out an executable means it's ready (what warnings? why do those matter, it compiled), Go makes coordinating with them a lot easier. It forces them to be more correct before an executable is created. It doesn't make them better, but at least the rest of the team can work with what they create until they do get better. Also, the simplicity of the language sure helps everybody (regardless of skill) get up to speed quickly. People that know what they're doing may hate there isn't some special feature they love (generics, etc) in the language, but working with a team of varied skill is so much easier this way. In before "but adding generics does not make team projects harder, look at language ..."
  - wiremine 12y ago
    > ...are a breath of fresh air... Agreed. Go lacks many things, but the "zen" of Go is wonderful feature most people aren't aware of, or under appreciate. I wouldn't use Go for everything, but I wouldn't dismiss it because it doesn't have a favorite language feature.
    - chimeracoder 12y ago
      > Agreed. Go lacks many things, but the "zen" of Go is wonderful feature most people aren't aware of, or under appreciate. It's funny that you use the word "Zen" - about two years ago, I gave a talk about Go to the New York Python Meetup about why I switched to Go[0], and the punchline was that Go fits the Zen of Python[1] better than Python does[2]. [0] Before anyone gets upset - they asked me to speak, and they were genuinely happy with the presentation. It's not like I went in there to troll with a talk on "This is why your language sucks"! [1] https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/ [2] If anyone's interested, these were the slides: https://s3.amazonaws.com/golangweekly/go_for_pythonistas.pdf https://s3.amazonaws.com/golangweekly/go_for_pythonistas.pdf
- hnrem 12y ago
  "we programmers like to discuss everything" -- I enjoy being free from discussing the language, to discuss the context.
- tormeh 12y ago
  Which is why Go has goto's and pointers. Got it. No, Go's adherents are just sloppy in a different way. I have many bad things to say about Haskell, but I admire Haskellers lack of sloppiness. I cannot say the same about Gophers.
  - skj 12y ago
    Like any decision, there are some trade-offs involved.
  - jerf 12y ago
    Go's goto is the standard structured-programming-limited goto which is not allowed to violate blocks, which means it is not the goto that is "considered harmful". Go's "pointers" are not allowed to do pointer arithmetic, which basically means that they are references. As they are also backed by a garbage collector, this means you can't do any of the nasty C things you can do with them, not even "fail to deallocate" them. All you've got left is "unexpected liveness" (a.k.a. "memory leak") and that can happen to anybody, even Haskell. You can dock a couple of points for pointers being allowed to be nil. You may want to give half-a-point back for the fact that a nil pointer can actually be a valid implementation of an object, and I actually use this quite a bit. But nil maps can be accidentally unpleasant.
    - tormeh 12y ago
      Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code. You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.
      - voidlogic 12y ago
        In my organization Goto's have to get past code review, which is rare and when they do make sense they are probably good option. Your organization can have its own style guidelines.... Just say no gotos- done.
      - 12y ago
- oblio 12y ago
  An involuntarily funny quote from the article: > Their solution was not to engage and educate those programmers to change their habits. I wish the blog author good luck in educating masses of programmers, even smart ones :)
  - BinaryIdiot 12y ago
    It's certainly difficult; every time I have to tell someone their opinion is wrong they get defensive. Look, I'm just trying to educate you. I'm right so let's just end it at that. :)
- jfaucett 12y ago
  Personally, I think people dislike Go because they try using it for tasks where it makes their life miserable. Mainly for web programming. (unless of course you're a masochist and enjoy not having a repl and want static typing and a compilation step when recursively parsing unknown json data structures). In my experience, Go is a tool thats really good for a certain set of programming tasks and like all other languages really bad or annoyingly painful for others. For me, Go is my number one tool for creating command line apps now. I get immediate cross-platform cli tools with zero headache. Its also a really nice fit for lower level networking/distributed applications where you are working with byte protocols (things like mozillas heka, or docker, proxy servers, chat clients, etc), the networking server-side stuff where you would probably have used C++/Java. My recommendation would be, if you work a lot on this kind of software seriously start using Go, you will love it and think everyone is crazy for hating on Go. The problem is I think lots of people are trying to use Go for stuff it is not designed for and where, compared to the alternatives, it is a rather bad fit. For instance Go is zero fun for: Compiler Programming (Haskell/C++ have way better tooling), Games (libs are one thing but Go cannot compete with C++ perf here), Desktop GUI apps (Just use QT), Mobile Apps, and Web Programming (take your pick of python,ruby,js,clojure,php - your life will be much easier), Hardware/Low Level Systems programming (Obviously you can't use a GCed lang here). I haven't found another area where I really like programming in Go besides CLI and networking I mentioned above. It could have another sweet spot I've missed...
  - smt88 12y ago
    > unless of course you're a masochist and ... want static typing Some people say to prototype in a dynamically-typed language and then switch to a static language later. Dynamic typing might save keystrokes, but typecasting and type-checking do require lots of typing, and who cares that much about a few hundred extra keystrokes anyway? Some people say to create whole, large apps in dynamically-typed languages, but those people clearly haven't tried modifying or debugging code bases in those languages that weren't created with utmost discipline and 100% test coverage. So with 10 years of web programming experience, I'd emphatically argue that masochism is not using static typing. I have warm, happy dreams of a future where there's a great alternative to the dynamic/weak web languages of today. There are already some great entrants, but nothing has reached the massive popularity of existing languages yet. (Edited for clarity)
- serve_yay 12y ago
  Sounds wonderful to me!
- justicezyx 12y ago
  "I get the impression that they are doing this because they believe they are 'right'. That makes some people uncomfortable because we programmers like to discuss everything, and argue, and it's hard to come up against people who have what is close to 'faith' in their own beliefs." They do not just argue, then invent their own wheels. Go is not special in this sense, just another wheel, whose inventors have a stronger sense of righteousness. And I think it is well grounded.
- smegel 12y ago
  "Opinionated" frameworks/tools/languages are becoming pretty common these says. I would say programmers are becoming quite fond of authors who just make some damned decisions.
  - nulltype 12y ago
    Endless arguing over 2 vs 4 spaces or spaces vs tabs has not really advanced the programming industry very much, despite being highly democratic. For a lot of these small decisions, it doesn't really matter what you choose as long as a choice is made and it's consistent.
- rickhanlonii 12y ago
  The best example of this for me is the initialism style rule: > Words in names that are initialisms or acronyms (e.g. "URL" or "NATO") have a consistent case. For example, "URL" should appear as "URL" or "url" (as in "urlPony", or "URLPony"), never as "Url". Here's an example: ServeHTTP not ServeHttp. > This rule also applies to "ID" when it is short for "identifier," so write "appID" instead of "appId". > Code generated by the protocol buffer compiler is exempt from this rule. Human-written code is held to a higher standard than machine-written code. To enforce this in the linter they literally define a list of initialisms[1]. [1]: https://github.com/golang/go/wiki/CodeReviewComments#initialisms https://github.com/golang/go/wiki/CodeReviewComments#initial... [2]: https://github.com/golang/lint/blob/master/lint.go#L695 https://github.com/golang/lint/blob/master/lint.go#L695
- 0xdeadbeefbabe 12y ago
  > we programmers like to discuss everything, and argue I doubt that, for the sake of truth and not just to argue with you. Most programmers do not want to argue or discuss things. Most programmers leverage knowledge and understanding to make the computer do interesting things. Some find go more understandable and useful than others.
- imron 12y ago
  I remember when Go first came out and I thought "wow, that looks interesting, I'll check it out", then when I was checking it out, I found that the language enforced placing opening curly braces at the end of a line rather than wherever you want, such as at the beginning of the next line (which I generally prefer). There was no option to even be flexible about this, for example, by programming one way and then using gofmt before committing code, because you will literally have an incorrect program if you put the opening brace on the next line due to automatic semicolons placed at the end of lines. And so ended my 15 minutes of playing with Go.
zimbatm 12y ago
That was quite fun to read. The point about Go being too pedantic and thus hindering exploration is something I've felt too. Some of that pain was mitigated by the Sublime Text Go plugin that has shortcuts to add/remove imports.
- M8 12y ago
  Also he is spot on about the mascot.
  - nutate 12y ago
    I <3 the gopher: https://blog.golang.org/gopher https://blog.golang.org/gopher
- tormeh 12y ago
  This is generally a tradeoff you have to make in programming language design. Should the checker enforce good code or should it let all but the most broken code through in the name of exploratory programming? I would recommend using Python or possibly Clojure to experiment with and then translate the code to a language that will help you catch bugs (Ada/a functional one) when you know exactly how the problem is solved.
  - wtetzner 12y ago
    Maybe there could be an --experimentation-mode compiler flag that would be less strict.
- emehrkay 12y ago
  Yes, it was very funny and informative. I let out an audible sound when reading some of these one-liners: > It is possible, however, that the Go team has developed a set of secret signifiers to distinguish these constructions in everyday conversation and not told me about them. or > At first I wrote my methods on the values, which seemed like the normal, American thing to do. Someone posted yesterday about how to pronounce hexadecimal numbers. It's funny because somedoby, somewhere has a lexicon for describing the different overloaded loop types. sidenone: i find overloading cheap or sort of a cheat. I understand it in the content of typed languages, but in something like JavaScript or PHP it fucking sucks.
jlebrech 12y ago
no ternary is a smart move tho. makes code more readable for all skill levels.
- deckiedan 12y ago
  It's a balance between readability meaning 'short, and concise' and readability meaning 'very clear, even if that requires being overly verbose'. return (data.name !== '' ?: 'New Data') or Python style: return (data.name if data.name else 'New Data') vs: if (data.name != '') { return data.name } else { return 'New Data' } The former being much more concise, so that you can display (and grok, perhaps) a single function in 3 or 4 lines, vs the Go style, which can result in extremely long functions (long because they do a few things, and require error checks before and after each one, and so on, rather than being long for actually doing a lot). The single line version implies at the beginning that all the line does is return. The longer version requires you to read the whole paragraph to figure out what it does.
  - jlebrech 12y ago
    extra long functions promotes breaking them down into smaller functions.
    - deckiedan 12y ago
      Of course - absolutely. No-one disputes that (seriously). The difference ends up being between a 5 line function, which does 5 simple things, and a 20 line function that does 5 simple things. In my previous example, it was 1 line which returned either the name, or 'New Name', or else 5 lines to do the same. In the end, not a big deal. A matter of taste, rather than judgement, I feel.
      - deckiedan 12y ago
        I suppose one could argue that it's one line actually doing 3 things... but anyway. Not a big deal, at the end of the day.
TheDom 12y ago
California New Wave of systems programming languages Love it!
- cmollis 12y ago
  Jersey-style, scorched-earth C..
  - rootbear 12y ago
    This essay was full of some great turns of phrase. I'll keep reading his blog.
hahainternet 12y ago
Wow. For once a fantastic article on Go which is clearly balanced and educated by experience. This is the sort of thing we should see more of on HN IMO.
- nodivbyzero 12y ago
  +1. Agreed. I'm tired to read about startups/success stories/failures.
  - ChikkaChiChi 12y ago
    Your sarcasm is noted. I believe hahainternet was referring to articles that either gloss over the bad parts of a thing, or make specious claims to reinforce their ideas.
    - ajkjk 12y ago
      Not sure that was sarcastic.
donlzx 12y ago
IMO, there are two different opposite directions in programming languages and tools approaches, 1) The artistic approach which is very flexible and requires creative thinking and deep understanding of the essence of computing. However, you can easily shoot yourself with it. Languages of this type are for code guru, knights and hackers. 2) The engineering approach which has rigid rules for efficiency and social cooperation. It is less error-prone but tend to suppress diversity and discovery. Golang belongs to this category. To me, the core Go authors are more of engineers than artists :) I use Go for work and simple command-line tools for myself. It is also great for cooperation in well defined scenarios, e.g., Web back-end service. When it comes to creative works, I'd rather avoid it.
- wiremine 12y ago
  > To me, the core Go authors are more of engineers than artists I thought the same thing. They are like the anti-Larry Wall.
  - nulltype 12y ago
    I guess that makes Go the inverse of Perl. I assume if a Perl programmer shakes hands with a Go programmer, they cancel each other out.
    - vram22 12y ago
      No, the Go programmer will win. Strong(ly) type(d), you see :) #SorryCouldntResist Note: Said without any bias towards either Go or Perl. Also, I'm not a language lawyer, and this was a joke, so I'm not replying to any comments about Go not being "purely" or "strictly" strongly typed or whatever.
      - vram22 12y ago
        Also, speaking of Perl, check out this (old) interview with Larry Wall: http://jugad2.blogspot.in/2015/04/interview-linux-journal-with-larry-wall.html http://jugad2.blogspot.in/2015/04/interview-linux-journal-wi...
MindTwister 12y ago
I find that every issue I had with unused imports disappeared when I started using goimports: http://godoc.org/golang.org/x/tools/cmd/goimports http://godoc.org/golang.org/x/tools/cmd/goimports
- rakoo 12y ago
  There are unused imports, solved easily with goimports, and then there are unused variables, which AFAIK are not solved by any tool. I dig what the author says regarding "explorability" hindered by all those errors popping up. It's also funny to see errors solved automagically by tools instead of manually by the developer; there used to be a time where IDEs where voluntarily avoided because they did too many magic things to your code and to your project, and true hackers should be able to work with only a text editor and the compiler. I fear go may be headed back to IDE-land if it starts relying too much on tools (we have goimports today, the go generate command is to be used for code mangling before compiling ...)
  - wtbob 12y ago
    > I fear go may be headed back to IDE-land if it starts relying too much on tools (we have goimports today, the go generate command is to be used for code mangling before compiling ...) I think that it's kinda the opposite: rather than one monolithic IDE, it's lots of little pieces working together. Pretty much what one would expect from the guys who brought us Plan 9 and Go…
cpfohl 12y ago
What a fantastic writer. Hilarious technical articles are rare.
- scott_karana 12y ago
  Agreed! I've not chuckled this much since reading Steve Yegge articles.
nicpottier 12y ago
Hats off to the writing style, both informative and a good read.
dysoco 12y ago
I must said, I've never heard of this guy, I think I have a new favorite blogger now.
- deathtrader666 12y ago
  He's the one behind ChicagoBoss - an MVC web framework in Erlang.
  - dysoco 12y ago
    Ah yeah, I'm not really into the Erlang world but I've heard of ChicagoBoss.
- loopbit 12y ago
  He has a few very, very interesting articles. I would point out the following two: - How not to sort by average ranking (http://www.evanmiller.org/how-not-to-sort-by-average-rating.html http://www.evanmiller.org/how-not-to-sort-by-average-rating....) is a recommended read on coursera's recommender systems course. - Rank Hotness With Newton's Law of Cooling (http://www.evanmiller.org/rank-hotness-with-newtons-law-of-cooling.html http://www.evanmiller.org/rank-hotness-with-newtons-law-of-c...)
- digitalzombie 12y ago
  That's because Evan usually write about Erlang. I love his article on Erlang.
dilap 12y ago
Fantastic article. Two tips about the pain points regarding unused imports and variables: The program goimports is an extended version of gofmt that will automatically add and remove imports. Bind it to a keystroke of your editor of choice, and the imports situation becomes painless. For unused variables, you can do "_ = someVar" to stop it from being flagged as unused. Still a bit of a pain, but much easier than commenting and uncommenting things all the time.
garfij 12y ago
Ever since I started immediately creating at least one "test" file in my Go projects, I have found that both the unused variable/imports problem, as well as the "freedom to explore" issue have been eliminated for me. Sure, they will still bite me in that individual test file if the situation arises. It keeps the problem out of the "real" code, however so I don't get it when building. In this way I get to maintain a creative space to test out various apis and do my "print to console" testing, while also keeping my primary code base Go-Clean™.
alanctgardner3 12y ago
Two things stick out: Catching unused variables is pretty essential, it's easy to shoot yourself in the foot by redeclaring a variable with := inside a block. >> which means you have to need separate storage for the actual RaceCar and GetawayCar values, either on the stack with a temporary variable or on the heap with calls to new Maybe I miss his point here, but in Go it's totally valid to just create a new *GetawayCar with &GetawayCar{} in any scope. You can return that pointer from your current method. It's not necessary to explicitly put your GetawayCar on the heap with new(), Go will decide for you with escape analysis.
nnx 12y ago
> Go basically forces you to have clean code all along, > which is a bit like forcing a scientist to wipe down the > workbench and rinse all the beakers between every experiment, >or forcing a writer to run the spell checker after every cigarette. As usage of gofmt is idiomatic Go, simply using the superset goimports handles all of this for you. Sure, any language has tools to reformat code for you in some magic ways - but what makes Go special is that it takes this kind of tooling seriously enough by making it standard right out-of-the-box and right when initiating new users to the language (notice the [Format] button on the first slide of the official Go tutorial http://tour.golang.org/welcome/1 http://tour.golang.org/welcome/1 ). https://github.com/bradfitz/goimports https://github.com/bradfitz/goimports http://michaelwhatcott.com/gosublime-goimports/ http://michaelwhatcott.com/gosublime-goimports/ Nevertheless, this new article from Evan is a marvel, a must-read, as usual.
- swah 12y ago
  go fmt could be a tool that transformed "sloppy Go" (unused imports, variable redeclarations...) into formal Go before compiling...
karlgrz 12y ago
That was great!
anindyabd 12y ago
"Throw caution to the garbage collector" -- my new favorite phrase.
rogpeppe1 12y ago
From the article: In order to do evil things like convert raw bytes to floats, I chose to use the “unsafe” package FWIW you don't need unsafe to do that. encoding/binary + http://golang.org/pkg/math/#Float64frombits http://golang.org/pkg/math/#Float64frombits will do the job just fine.
chrisduesing 12y ago
Educational and entertaining as always Evan, I would love to see a similar writeup on Elixir. Maybe a Chicago Boss port is in order ;)
- timClicks 12y ago
  Evan actually spent a lot of time enabling Elixir support in CB when he was actively involved with the project.
coldtea 12y ago
>Reading Go’s mailing list and documentation, I get a similar sense of refusal-to-engage — the authors are communicative, to be sure, but in a didactic way. They seem tired of hearing people’s ideas, as if they’ve already thought of everything, and the relative success of Go at Google and elsewhere has only led them to turn the volume knob down. Which is a shame, because they’ll probably miss out on some good ideas This captures my sentiments and experiences with the language perfectly.
zellyn 12y ago
Great article. However, I would not assume that us (good programmers) vs them (bad ones) is how the go folks see the world. If a couple decades of programming have taught me anything, it's that "them" is usually "me" or "past me" or "500 of us".
- nulltype 12y ago
  A good point. I've seen people say that the Go designers are designing a language for "bad programmers", but maybe they're just designing for humans. Maybe code readability is more important than conciseness.
0xdeadbeefbabe 12y ago
I wonder what he'll say in 8 days. I'm of the opinion that you can still make a mess with go. Also, the gopher doesn't look that careful.
jasonlotito 12y ago
> If I had to guess, I’d say the Go gopher suffers from a mild form of autism. > I get the same feeling about the Go language. It feels like it is designed by an obsessive personality — obsessed with build times in particular, but also having an obsession with detail, someone who rarely makes mistakes when writing code, who generally will not run code until it appears to be complete and correct. WTF? Not only is it insulting, it's ignorant. Considering some of the other comments here regarding how "excellent" this article is, it clearly doesn't concern many when casual insults are allowed. No no, let's applaud someone for making casual, racist-like remarks without even questioning it. If this is considered quality, we should be ashamed.
- teach 12y ago
  As a high school teacher, I work with kids on the autism spectrum all the time, and I don't find his comments offensive. They seem relatively accurate, too.
  - jasonlotito 12y ago
    > As a high school teacher As a father of two autistic children, I do. > and I don't find his comments offensive. He's equating look to a disorder. It's like saying "Black man dressed 'street clothes' must be dangerous."
    - teach 12y ago
      I think he's saying "overly concerned with detail, marked lack of eye contact; probably on the autism spectrum." These are literally two of the diagnostic criteria for 299.00 Autism Spectrum Disorder. It seems like you're reading a negative connotation into the "autistic" label that isn't present in the article. Calling the gopher "unsettling" is the biggest insult I can find in what he wrote.
- EugeneOZ 12y ago
  He need to try run Rust code :)
- 12y ago
stefantalpalaru 12y ago
> It’s also worth mentioning that you can get Go-style M:N concurrency model in C by using Apple’s libdispatch. Not so fast. That library is only available for OS X and FreeBSD.
- threeseed 12y ago
  There are ports: Linux: https://github.com/nickhutchinson/libdispatch https://github.com/nickhutchinson/libdispatch Windows: https://github.com/DrPizza/libdispatch https://github.com/DrPizza/libdispatch
  - stefantalpalaru 12y ago
    The Linux port seems to be using OS threads from Pthreads instead of coroutines for the concurrent queue.
Scramblejams 12y ago
I used Go at work to write some utilities which extracted and manipulated values from large text files. It compiled fast and ran fast (at least, compared to the Python it was replacing). However, I learned that Go is a language conceived for Programming in the Large, and I found out (once again, thanks Java) that I don't like languages for Programming in the Large. But if I liked that sort of thing it'd probably be one of my first choices.
vowelless 12y ago
> Go is productive enough that I’ve been enjoying implementing things from scratch like collapsible widgets and navigating a viewport. In order to do evil things like convert raw bytes to floats, I chose to use the “unsafe” package, which made me feel manly, powerful, and highly supportive of private gun ownership. This was really funny!
anonfunction 12y ago
By the way, if anyone who works on the Go math library is reading this, there are a few important functions missing. I thought the same, so I built a stats library[1] of my own. It also only works on float64's at the moment. 1. https://github.com/montanaflynn/stats https://github.com/montanaflynn/stats
mrcwinn 12y ago
Go is not a perfect language, but I've been hard-pressed to find one and so I've stopped looking. Here's what I like about Go. Go is crazy boring. You type things. You hit return. You type the next thing. Error not nil? Type more. There's something very sequential, linear, methodical about it all. I suppose in part it's gofmt. It may also be a byproduct of any strongly typed language, but unlike many of those languages, Go feels simple and reasonable. I actually think this is how programming serious applications should be. A little boring. Nothing too fancy or cute. No refactors to fit some new great abstraction pattern. Not to wax nostalgic — in fact, I can't, because I wasn't even born — it reminds me of paper tape in old computers. The card gets punched, it feeds in, and the computer considers and executes your instructions. We're still doing that, really. Programming should be simpler. Sometimes I think we go out of our way to make it more complicated because we are experienced and bored. :)
polymathist 12y ago
I am worried that there might be a dangerous trend in conversations about go on HN recently. There seems to be a tendency toward ad hominem comments against the go authors. The article itself is a great read. I love hearing interesting and honest commentary about the language. But I wonder if comments like "for reasons that appear to be political, does not have integer Min and integer Max functions" are appropriate. Later the author mentions "I get a similar sense of refusal-to-engage — the authors are communicative, to be sure, but in a didactic way." If the go community (or the programming community at large) truly has the sense that the go authors are unwilling to engage with the users of the language, then that's a big problem. However, are these sort of off the cuff comments the right way to start a discussion about it? At the very least, I wish that the author would provide specific evidence for these claims. I'm sure that there is some justification for them, but what the author is telling us is his inference, and I would appreciate an opportunity to read the source material and decide for myself. FWIW I have been programming in go for 2.5 years and made a few trips to the go-nuts mailing list. I don't share the author's impression, but I also haven't read every thread on the mailing list. That's far from the worst of it, of course. I have read comments calling the go authors arrogant, ignorant, or conceited. If you insist on criticizing the go authors, I would hope that you could at least keep it professional and provide a link to some comment/literature to back up your criticism. I welcome criticism of go, or of any topic for that matter. I just want to avoid unfair characterization and irrelevant ad hominem comments. Am I being too defensive or do other people share this concern?
- rdtsc 12y ago
  > However, are these sort of off the cuff comments the right way to start a discussion about it? Well it is a persons' opinion. There are some facts, some humor, some personal opinions. I am not sure the author planned on being on the front page of HN. I don't think he submitted his own article. It is up to the readers to put things in the appropriate "bins" so to speak -- "This is good advice", "I don't like this part", "This is just a personal attack" and so on. Sometimes the same article can contain a variety of things.
kristianp 12y ago
From what I can gather on the mailing list threads, the language designers are against polymorphism, as well as adding letters to function names, so unlike the standard C library which operates on float, double, and long double, as well as int and long where appropriate (e.g. absolute value), the Go standard math library operates only on float64. This is criticism of go I haven't heard before.
rvalue 12y ago
I still find it shocking how people can continue to write in Go which still does not have an official debugger!
lugg 12y ago
My workflow at present is to print out the hex representation of a binary file onto physical sheets of paper, and then mark them up with a ball-point pen that I received last year at a conference about technology. I love writing like this, where you got that pen doesn't matter one bit, yet it turns the drab of a tech blog into an enjoyable story to read.
coldgrnd 12y ago
is the code of "Hecate: The Hex Editor From Hell" available to look at?
- hpux 12y ago
  The same question here.
AnonJ 12y ago
This author is quite exaggerating a bit. It seems like he himself is constantly preoccupied with politics. Fine. But this doesn't mean other people who he see with his eyes are necessarily thinking in the same pattern. "Machiavellian" is such a heavy word. Go started out with a purpose, a purpose which makes a lot of sense. It's not all about "make a new language and shove the new rules onto everyone by coupling it with Very Fast Build Times, a kind of veto-proof Defense Spending Bill in the Congress of computer programming." Such a design has a lot of practical value.

496 points by wtbob 12y ago

In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers, that is, the “bad” programmers. I think this is why some people dislike Go. The Go authors have made a decision about the language and are sticking to it. I get the impression that they are doing this because they believe they are 'right'. That makes some people uncomfortable because we programmers like to discuss everything, and argue, and it's hard to come up against people who have what is close to 'faith' in their own beliefs.

aperture 12y ago
I enjoyed that the author readily admits to his own faults concerning Go too: In this telling, the story of Go is really a tale of revenge, not just against slow builds, but against all kinds of sloppy programming. Which in my opinion is too bad, because I myself am a sloppy programmer. This really does seem to be the approach I see with the Go digest mailing list. What I don't understand though is the ease of importing a library, say from Github. Interesting that the language from the author is all about how rigid and unforgiving Go is, yet "some guys" libraries can just be thrown into the mix in your program, and Go has no issues with this.
- mike_hearn 12y ago
  Go is developed inside Google where all dependencies are checked into their global version control repository. There are literally no versions inside the Google codebase - everything is compiled at head. If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project! Given this background and the Go designers focus on Google's internal needs, it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)
  - MetaCosm 12y ago
    > If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project! The alternative is of course supporting dozens or hundreds of copies of a library and every possible commit hash of said library. I contracted at a python shop that had 81 versions of a single library in use all pinned at different versions. The reason I know this is that I had the great joy of dealing with upgrading all of them after a critical hole was not only discovered (the company knew about it for some time, but just didn't want to bother updating all those apps) but exploited... repeatedly. > it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?) If by "fixed" you mean there are dozens of solutions to pin versions -- then yes. If you mean baked into the go tool, then no.
    - mike_hearn 12y ago
      Yes, I didn't pass judgement on the approach. It works well enough for Google and avoids problems with e.g. ELF symbol conflicts. For development out on the open internet you do need some way to specify versions so it's a puzzling lack, but "if it works for Google it works for you" does seem to be a recurring theme in the Go design.
    - _yosefk 12y ago
      But - but! Saying that you want your org to use one version of a library at a time is one thing. Saying that you want your code to use the latest version of every library is another thing altogether, however, and that's what "no version for github code" does, right? "One version per org" means "upgrades are harder, but patches are easier and you don't need to deal with different quirks of different versions at the same time and you don't get problems using 2 components that need 2 different versions of some other thing in one process etc." "Latest version, always" means you have no way to even build the latest version of your thing that was tested and is known to compile and work. Kinda sucks, I think.
  - aikah 12y ago
    > Given this background and the Go designers focus on Google's internal needs Does it mean the community isn't a priority? this vertical relationship between the Go team and the community could doom the language as fast as it was made popular, that's my opinion.That's a real issue.
zerr 12y ago
> faith Or arrogance and incompetence. It's been said many times. Go team should spend at least one day with Gilad Bracha...
- deleted 12y ago
  [deleted]
- laumars 12y ago
  I find it amusing that people would use the term "incompetence" to describe Ken Thompson and Rob Pike. These two guys have been as instrumental in shaping modern computing as Linus Torvalds, Bill Gates and Steve Jobs. But I guess it's easy to be critical of other peoples output when you're an anonymous internet user yourself.
  - zerr 12y ago
    Sorry, I thought it was clear - incompetence regarding [modern] language design. They don't deny this neither. And it seems they're even proud of this. > when you're an anonymous internet user It is easy to be honest, yes.
    - deleted 12y ago
      [deleted]
    - scott_s 12y ago
      I don't think your amended statement is much better. They have designed a language that meets their goals. They have decided not to include many things, but that does not mean that they are not aware of them, or are incompetent for doing so.
      - 0xdeadbeefbabe 12y ago
        Right, and what zerr calls incompetence could also be called post-modernism.
howeyc 12y ago
I think this is part of it, some of the hate comes from people that "know better" (possibly true for some, obviously the Go authors aren't omnipotent) than the Go language designers and are baffled that the language design ideas they know about aren't in the language. But I can tell you in my experience that this type of forceful "everything is a error, no warnings" and "it is done this way (formatting for instance)" are a breath of fresh air. Having dealt with team members that barely know how to program and think a compiler spitting out an executable means it's ready (what warnings? why do those matter, it compiled), Go makes coordinating with them a lot easier. It forces them to be more correct before an executable is created. It doesn't make them better, but at least the rest of the team can work with what they create until they do get better. Also, the simplicity of the language sure helps everybody (regardless of skill) get up to speed quickly. People that know what they're doing may hate there isn't some special feature they love (generics, etc) in the language, but working with a team of varied skill is so much easier this way. In before "but adding generics does not make team projects harder, look at language ..."
- wiremine 12y ago
  > ...are a breath of fresh air... Agreed. Go lacks many things, but the "zen" of Go is wonderful feature most people aren't aware of, or under appreciate. I wouldn't use Go for everything, but I wouldn't dismiss it because it doesn't have a favorite language feature.
  - chimeracoder 12y ago
    > Agreed. Go lacks many things, but the "zen" of Go is wonderful feature most people aren't aware of, or under appreciate. It's funny that you use the word "Zen" - about two years ago, I gave a talk about Go to the New York Python Meetup about why I switched to Go[0], and the punchline was that Go fits the Zen of Python[1] better than Python does[2]. [0] Before anyone gets upset - they asked me to speak, and they were genuinely happy with the presentation. It's not like I went in there to troll with a talk on "This is why your language sucks"! [1] https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/ [2] If anyone's interested, these were the slides: https://s3.amazonaws.com/golangweekly/go_for_pythonistas.pdf https://s3.amazonaws.com/golangweekly/go_for_pythonistas.pdf
hnrem 12y ago
"we programmers like to discuss everything" -- I enjoy being free from discussing the language, to discuss the context.
tormeh 12y ago
Which is why Go has goto's and pointers. Got it. No, Go's adherents are just sloppy in a different way. I have many bad things to say about Haskell, but I admire Haskellers lack of sloppiness. I cannot say the same about Gophers.
- skj 12y ago
  Like any decision, there are some trade-offs involved.
- jerf 12y ago
  Go's goto is the standard structured-programming-limited goto which is not allowed to violate blocks, which means it is not the goto that is "considered harmful". Go's "pointers" are not allowed to do pointer arithmetic, which basically means that they are references. As they are also backed by a garbage collector, this means you can't do any of the nasty C things you can do with them, not even "fail to deallocate" them. All you've got left is "unexpected liveness" (a.k.a. "memory leak") and that can happen to anybody, even Haskell. You can dock a couple of points for pointers being allowed to be nil. You may want to give half-a-point back for the fact that a nil pointer can actually be a valid implementation of an object, and I actually use this quite a bit. But nil maps can be accidentally unpleasant.
  - tormeh 12y ago
    Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code. You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.
    - voidlogic 12y ago
      In my organization Goto's have to get past code review, which is rare and when they do make sense they are probably good option. Your organization can have its own style guidelines.... Just say no gotos- done.
    - 12y ago
oblio 12y ago
An involuntarily funny quote from the article: > Their solution was not to engage and educate those programmers to change their habits. I wish the blog author good luck in educating masses of programmers, even smart ones :)
- BinaryIdiot 12y ago
  It's certainly difficult; every time I have to tell someone their opinion is wrong they get defensive. Look, I'm just trying to educate you. I'm right so let's just end it at that. :)
jfaucett 12y ago
Personally, I think people dislike Go because they try using it for tasks where it makes their life miserable. Mainly for web programming. (unless of course you're a masochist and enjoy not having a repl and want static typing and a compilation step when recursively parsing unknown json data structures). In my experience, Go is a tool thats really good for a certain set of programming tasks and like all other languages really bad or annoyingly painful for others. For me, Go is my number one tool for creating command line apps now. I get immediate cross-platform cli tools with zero headache. Its also a really nice fit for lower level networking/distributed applications where you are working with byte protocols (things like mozillas heka, or docker, proxy servers, chat clients, etc), the networking server-side stuff where you would probably have used C++/Java. My recommendation would be, if you work a lot on this kind of software seriously start using Go, you will love it and think everyone is crazy for hating on Go. The problem is I think lots of people are trying to use Go for stuff it is not designed for and where, compared to the alternatives, it is a rather bad fit. For instance Go is zero fun for: Compiler Programming (Haskell/C++ have way better tooling), Games (libs are one thing but Go cannot compete with C++ perf here), Desktop GUI apps (Just use QT), Mobile Apps, and Web Programming (take your pick of python,ruby,js,clojure,php - your life will be much easier), Hardware/Low Level Systems programming (Obviously you can't use a GCed lang here). I haven't found another area where I really like programming in Go besides CLI and networking I mentioned above. It could have another sweet spot I've missed...
- smt88 12y ago
  > unless of course you're a masochist and ... want static typing Some people say to prototype in a dynamically-typed language and then switch to a static language later. Dynamic typing might save keystrokes, but typecasting and type-checking do require lots of typing, and who cares that much about a few hundred extra keystrokes anyway? Some people say to create whole, large apps in dynamically-typed languages, but those people clearly haven't tried modifying or debugging code bases in those languages that weren't created with utmost discipline and 100% test coverage. So with 10 years of web programming experience, I'd emphatically argue that masochism is not using static typing. I have warm, happy dreams of a future where there's a great alternative to the dynamic/weak web languages of today. There are already some great entrants, but nothing has reached the massive popularity of existing languages yet. (Edited for clarity)
serve_yay 12y ago
Sounds wonderful to me!
justicezyx 12y ago
"I get the impression that they are doing this because they believe they are 'right'. That makes some people uncomfortable because we programmers like to discuss everything, and argue, and it's hard to come up against people who have what is close to 'faith' in their own beliefs." They do not just argue, then invent their own wheels. Go is not special in this sense, just another wheel, whose inventors have a stronger sense of righteousness. And I think it is well grounded.
smegel 12y ago
"Opinionated" frameworks/tools/languages are becoming pretty common these says. I would say programmers are becoming quite fond of authors who just make some damned decisions.
- nulltype 12y ago
  Endless arguing over 2 vs 4 spaces or spaces vs tabs has not really advanced the programming industry very much, despite being highly democratic. For a lot of these small decisions, it doesn't really matter what you choose as long as a choice is made and it's consistent.
rickhanlonii 12y ago
The best example of this for me is the initialism style rule: > Words in names that are initialisms or acronyms (e.g. "URL" or "NATO") have a consistent case. For example, "URL" should appear as "URL" or "url" (as in "urlPony", or "URLPony"), never as "Url". Here's an example: ServeHTTP not ServeHttp. > This rule also applies to "ID" when it is short for "identifier," so write "appID" instead of "appId". > Code generated by the protocol buffer compiler is exempt from this rule. Human-written code is held to a higher standard than machine-written code. To enforce this in the linter they literally define a list of initialisms[1]. [1]: https://github.com/golang/go/wiki/CodeReviewComments#initialisms https://github.com/golang/go/wiki/CodeReviewComments#initial... [2]: https://github.com/golang/lint/blob/master/lint.go#L695 https://github.com/golang/lint/blob/master/lint.go#L695
0xdeadbeefbabe 12y ago
> we programmers like to discuss everything, and argue I doubt that, for the sake of truth and not just to argue with you. Most programmers do not want to argue or discuss things. Most programmers leverage knowledge and understanding to make the computer do interesting things. Some find go more understandable and useful than others.
imron 12y ago
I remember when Go first came out and I thought "wow, that looks interesting, I'll check it out", then when I was checking it out, I found that the language enforced placing opening curly braces at the end of a line rather than wherever you want, such as at the beginning of the next line (which I generally prefer). There was no option to even be flexible about this, for example, by programming one way and then using gofmt before committing code, because you will literally have an incorrect program if you put the opening brace on the next line due to automatic semicolons placed at the end of lines. And so ended my 15 minutes of playing with Go.

zimbatm 12y ago

That was quite fun to read. The point about Go being too pedantic and thus hindering exploration is something I've felt too. Some of that pain was mitigated by the Sublime Text Go plugin that has shortcuts to add/remove imports.

M8 12y ago
Also he is spot on about the mascot.
- nutate 12y ago
  I <3 the gopher: https://blog.golang.org/gopher https://blog.golang.org/gopher
tormeh 12y ago
This is generally a tradeoff you have to make in programming language design. Should the checker enforce good code or should it let all but the most broken code through in the name of exploratory programming? I would recommend using Python or possibly Clojure to experiment with and then translate the code to a language that will help you catch bugs (Ada/a functional one) when you know exactly how the problem is solved.
- wtetzner 12y ago
  Maybe there could be an --experimentation-mode compiler flag that would be less strict.
emehrkay 12y ago
Yes, it was very funny and informative. I let out an audible sound when reading some of these one-liners: > It is possible, however, that the Go team has developed a set of secret signifiers to distinguish these constructions in everyday conversation and not told me about them. or > At first I wrote my methods on the values, which seemed like the normal, American thing to do. Someone posted yesterday about how to pronounce hexadecimal numbers. It's funny because somedoby, somewhere has a lexicon for describing the different overloaded loop types. sidenone: i find overloading cheap or sort of a cheat. I understand it in the content of typed languages, but in something like JavaScript or PHP it fucking sucks.

jlebrech 12y ago

no ternary is a smart move tho. makes code more readable for all skill levels.

deckiedan 12y ago
It's a balance between readability meaning 'short, and concise' and readability meaning 'very clear, even if that requires being overly verbose'. return (data.name !== '' ?: 'New Data') or Python style: return (data.name if data.name else 'New Data') vs: if (data.name != '') { return data.name } else { return 'New Data' } The former being much more concise, so that you can display (and grok, perhaps) a single function in 3 or 4 lines, vs the Go style, which can result in extremely long functions (long because they do a few things, and require error checks before and after each one, and so on, rather than being long for actually doing a lot). The single line version implies at the beginning that all the line does is return. The longer version requires you to read the whole paragraph to figure out what it does.
- jlebrech 12y ago
  extra long functions promotes breaking them down into smaller functions.
  - deckiedan 12y ago
    Of course - absolutely. No-one disputes that (seriously). The difference ends up being between a 5 line function, which does 5 simple things, and a 20 line function that does 5 simple things. In my previous example, it was 1 line which returned either the name, or 'New Name', or else 5 lines to do the same. In the end, not a big deal. A matter of taste, rather than judgement, I feel.
    - deckiedan 12y ago
      I suppose one could argue that it's one line actually doing 3 things... but anyway. Not a big deal, at the end of the day.

TheDom 12y ago

California New Wave of systems programming languages Love it!

cmollis 12y ago
Jersey-style, scorched-earth C..
- rootbear 12y ago
  This essay was full of some great turns of phrase. I'll keep reading his blog.

hahainternet 12y ago

Wow. For once a fantastic article on Go which is clearly balanced and educated by experience. This is the sort of thing we should see more of on HN IMO.

nodivbyzero 12y ago
+1. Agreed. I'm tired to read about startups/success stories/failures.
- ChikkaChiChi 12y ago
  Your sarcasm is noted. I believe hahainternet was referring to articles that either gloss over the bad parts of a thing, or make specious claims to reinforce their ideas.
  - ajkjk 12y ago
    Not sure that was sarcastic.

donlzx 12y ago

IMO, there are two different opposite directions in programming languages and tools approaches, 1) The artistic approach which is very flexible and requires creative thinking and deep understanding of the essence of computing. However, you can easily shoot yourself with it. Languages of this type are for code guru, knights and hackers. 2) The engineering approach which has rigid rules for efficiency and social cooperation. It is less error-prone but tend to suppress diversity and discovery. Golang belongs to this category. To me, the core Go authors are more of engineers than artists :) I use Go for work and simple command-line tools for myself. It is also great for cooperation in well defined scenarios, e.g., Web back-end service. When it comes to creative works, I'd rather avoid it.

wiremine 12y ago
> To me, the core Go authors are more of engineers than artists I thought the same thing. They are like the anti-Larry Wall.
- nulltype 12y ago
  I guess that makes Go the inverse of Perl. I assume if a Perl programmer shakes hands with a Go programmer, they cancel each other out.
  - vram22 12y ago
    No, the Go programmer will win. Strong(ly) type(d), you see :) #SorryCouldntResist Note: Said without any bias towards either Go or Perl. Also, I'm not a language lawyer, and this was a joke, so I'm not replying to any comments about Go not being "purely" or "strictly" strongly typed or whatever.
    - vram22 12y ago
      Also, speaking of Perl, check out this (old) interview with Larry Wall: http://jugad2.blogspot.in/2015/04/interview-linux-journal-with-larry-wall.html http://jugad2.blogspot.in/2015/04/interview-linux-journal-wi...

MindTwister 12y ago

I find that every issue I had with unused imports disappeared when I started using goimports: http://godoc.org/golang.org/x/tools/cmd/goimports http://godoc.org/golang.org/x/tools/cmd/goimports

rakoo 12y ago
There are unused imports, solved easily with goimports, and then there are unused variables, which AFAIK are not solved by any tool. I dig what the author says regarding "explorability" hindered by all those errors popping up. It's also funny to see errors solved automagically by tools instead of manually by the developer; there used to be a time where IDEs where voluntarily avoided because they did too many magic things to your code and to your project, and true hackers should be able to work with only a text editor and the compiler. I fear go may be headed back to IDE-land if it starts relying too much on tools (we have goimports today, the go generate command is to be used for code mangling before compiling ...)
- wtbob 12y ago
  > I fear go may be headed back to IDE-land if it starts relying too much on tools (we have goimports today, the go generate command is to be used for code mangling before compiling ...) I think that it's kinda the opposite: rather than one monolithic IDE, it's lots of little pieces working together. Pretty much what one would expect from the guys who brought us Plan 9 and Go…

cpfohl 12y ago

What a fantastic writer. Hilarious technical articles are rare.

scott_karana 12y ago
Agreed! I've not chuckled this much since reading Steve Yegge articles.

nicpottier 12y ago

Hats off to the writing style, both informative and a good read.

dysoco 12y ago

I must said, I've never heard of this guy, I think I have a new favorite blogger now.

deathtrader666 12y ago
He's the one behind ChicagoBoss - an MVC web framework in Erlang.
- dysoco 12y ago
  Ah yeah, I'm not really into the Erlang world but I've heard of ChicagoBoss.
loopbit 12y ago
He has a few very, very interesting articles. I would point out the following two: - How not to sort by average ranking (http://www.evanmiller.org/how-not-to-sort-by-average-rating.html http://www.evanmiller.org/how-not-to-sort-by-average-rating....) is a recommended read on coursera's recommender systems course. - Rank Hotness With Newton's Law of Cooling (http://www.evanmiller.org/rank-hotness-with-newtons-law-of-cooling.html http://www.evanmiller.org/rank-hotness-with-newtons-law-of-c...)
digitalzombie 12y ago
That's because Evan usually write about Erlang. I love his article on Erlang.

dilap 12y ago

Fantastic article. Two tips about the pain points regarding unused imports and variables: The program goimports is an extended version of gofmt that will automatically add and remove imports. Bind it to a keystroke of your editor of choice, and the imports situation becomes painless. For unused variables, you can do "_ = someVar" to stop it from being flagged as unused. Still a bit of a pain, but much easier than commenting and uncommenting things all the time.

garfij 12y ago

Ever since I started immediately creating at least one "test" file in my Go projects, I have found that both the unused variable/imports problem, as well as the "freedom to explore" issue have been eliminated for me. Sure, they will still bite me in that individual test file if the situation arises. It keeps the problem out of the "real" code, however so I don't get it when building. In this way I get to maintain a creative space to test out various apis and do my "print to console" testing, while also keeping my primary code base Go-Clean™.

alanctgardner3 12y ago

Two things stick out: Catching unused variables is pretty essential, it's easy to shoot yourself in the foot by redeclaring a variable with := inside a block. >> which means you have to need separate storage for the actual RaceCar and GetawayCar values, either on the stack with a temporary variable or on the heap with calls to new Maybe I miss his point here, but in Go it's totally valid to just create a new *GetawayCar with &GetawayCar{} in any scope. You can return that pointer from your current method. It's not necessary to explicitly put your GetawayCar on the heap with new(), Go will decide for you with escape analysis.

nnx 12y ago

> Go basically forces you to have clean code all along, > which is a bit like forcing a scientist to wipe down the > workbench and rinse all the beakers between every experiment, >or forcing a writer to run the spell checker after every cigarette. As usage of gofmt is idiomatic Go, simply using the superset goimports handles all of this for you. Sure, any language has tools to reformat code for you in some magic ways - but what makes Go special is that it takes this kind of tooling seriously enough by making it standard right out-of-the-box and right when initiating new users to the language (notice the [Format] button on the first slide of the official Go tutorial http://tour.golang.org/welcome/1 http://tour.golang.org/welcome/1 ). https://github.com/bradfitz/goimports https://github.com/bradfitz/goimports http://michaelwhatcott.com/gosublime-goimports/ http://michaelwhatcott.com/gosublime-goimports/ Nevertheless, this new article from Evan is a marvel, a must-read, as usual.

swah 12y ago
go fmt could be a tool that transformed "sloppy Go" (unused imports, variable redeclarations...) into formal Go before compiling...

karlgrz 12y ago

That was great!

anindyabd 12y ago

"Throw caution to the garbage collector" -- my new favorite phrase.

rogpeppe1 12y ago

From the article: In order to do evil things like convert raw bytes to floats, I chose to use the “unsafe” package FWIW you don't need unsafe to do that. encoding/binary + http://golang.org/pkg/math/#Float64frombits http://golang.org/pkg/math/#Float64frombits will do the job just fine.

chrisduesing 12y ago

Educational and entertaining as always Evan, I would love to see a similar writeup on Elixir. Maybe a Chicago Boss port is in order ;)

timClicks 12y ago
Evan actually spent a lot of time enabling Elixir support in CB when he was actively involved with the project.

coldtea 12y ago

>Reading Go’s mailing list and documentation, I get a similar sense of refusal-to-engage — the authors are communicative, to be sure, but in a didactic way. They seem tired of hearing people’s ideas, as if they’ve already thought of everything, and the relative success of Go at Google and elsewhere has only led them to turn the volume knob down. Which is a shame, because they’ll probably miss out on some good ideas This captures my sentiments and experiences with the language perfectly.

zellyn 12y ago

Great article. However, I would not assume that us (good programmers) vs them (bad ones) is how the go folks see the world. If a couple decades of programming have taught me anything, it's that "them" is usually "me" or "past me" or "500 of us".

nulltype 12y ago
A good point. I've seen people say that the Go designers are designing a language for "bad programmers", but maybe they're just designing for humans. Maybe code readability is more important than conciseness.

0xdeadbeefbabe 12y ago

I wonder what he'll say in 8 days. I'm of the opinion that you can still make a mess with go. Also, the gopher doesn't look that careful.

jasonlotito 12y ago

> If I had to guess, I’d say the Go gopher suffers from a mild form of autism. > I get the same feeling about the Go language. It feels like it is designed by an obsessive personality — obsessed with build times in particular, but also having an obsession with detail, someone who rarely makes mistakes when writing code, who generally will not run code until it appears to be complete and correct. WTF? Not only is it insulting, it's ignorant. Considering some of the other comments here regarding how "excellent" this article is, it clearly doesn't concern many when casual insults are allowed. No no, let's applaud someone for making casual, racist-like remarks without even questioning it. If this is considered quality, we should be ashamed.

teach 12y ago
As a high school teacher, I work with kids on the autism spectrum all the time, and I don't find his comments offensive. They seem relatively accurate, too.
- jasonlotito 12y ago
  > As a high school teacher As a father of two autistic children, I do. > and I don't find his comments offensive. He's equating look to a disorder. It's like saying "Black man dressed 'street clothes' must be dangerous."
  - teach 12y ago
    I think he's saying "overly concerned with detail, marked lack of eye contact; probably on the autism spectrum." These are literally two of the diagnostic criteria for 299.00 Autism Spectrum Disorder. It seems like you're reading a negative connotation into the "autistic" label that isn't present in the article. Calling the gopher "unsettling" is the biggest insult I can find in what he wrote.
EugeneOZ 12y ago
He need to try run Rust code :)
12y ago

stefantalpalaru 12y ago

> It’s also worth mentioning that you can get Go-style M:N concurrency model in C by using Apple’s libdispatch. Not so fast. That library is only available for OS X and FreeBSD.

threeseed 12y ago
There are ports: Linux: https://github.com/nickhutchinson/libdispatch https://github.com/nickhutchinson/libdispatch Windows: https://github.com/DrPizza/libdispatch https://github.com/DrPizza/libdispatch
- stefantalpalaru 12y ago
  The Linux port seems to be using OS threads from Pthreads instead of coroutines for the concurrent queue.

Scramblejams 12y ago

I used Go at work to write some utilities which extracted and manipulated values from large text files. It compiled fast and ran fast (at least, compared to the Python it was replacing). However, I learned that Go is a language conceived for Programming in the Large, and I found out (once again, thanks Java) that I don't like languages for Programming in the Large. But if I liked that sort of thing it'd probably be one of my first choices.

vowelless 12y ago

> Go is productive enough that I’ve been enjoying implementing things from scratch like collapsible widgets and navigating a viewport. In order to do evil things like convert raw bytes to floats, I chose to use the “unsafe” package, which made me feel manly, powerful, and highly supportive of private gun ownership. This was really funny!

anonfunction 12y ago

By the way, if anyone who works on the Go math library is reading this, there are a few important functions missing. I thought the same, so I built a stats library[1] of my own. It also only works on float64's at the moment. 1. https://github.com/montanaflynn/stats https://github.com/montanaflynn/stats

mrcwinn 12y ago

Go is not a perfect language, but I've been hard-pressed to find one and so I've stopped looking. Here's what I like about Go. Go is crazy boring. You type things. You hit return. You type the next thing. Error not nil? Type more. There's something very sequential, linear, methodical about it all. I suppose in part it's gofmt. It may also be a byproduct of any strongly typed language, but unlike many of those languages, Go feels simple and reasonable. I actually think this is how programming serious applications should be. A little boring. Nothing too fancy or cute. No refactors to fit some new great abstraction pattern. Not to wax nostalgic — in fact, I can't, because I wasn't even born — it reminds me of paper tape in old computers. The card gets punched, it feeds in, and the computer considers and executes your instructions. We're still doing that, really. Programming should be simpler. Sometimes I think we go out of our way to make it more complicated because we are experienced and bored. :)

polymathist 12y ago

I am worried that there might be a dangerous trend in conversations about go on HN recently. There seems to be a tendency toward ad hominem comments against the go authors. The article itself is a great read. I love hearing interesting and honest commentary about the language. But I wonder if comments like "for reasons that appear to be political, does not have integer Min and integer Max functions" are appropriate. Later the author mentions "I get a similar sense of refusal-to-engage — the authors are communicative, to be sure, but in a didactic way." If the go community (or the programming community at large) truly has the sense that the go authors are unwilling to engage with the users of the language, then that's a big problem. However, are these sort of off the cuff comments the right way to start a discussion about it? At the very least, I wish that the author would provide specific evidence for these claims. I'm sure that there is some justification for them, but what the author is telling us is his inference, and I would appreciate an opportunity to read the source material and decide for myself. FWIW I have been programming in go for 2.5 years and made a few trips to the go-nuts mailing list. I don't share the author's impression, but I also haven't read every thread on the mailing list. That's far from the worst of it, of course. I have read comments calling the go authors arrogant, ignorant, or conceited. If you insist on criticizing the go authors, I would hope that you could at least keep it professional and provide a link to some comment/literature to back up your criticism. I welcome criticism of go, or of any topic for that matter. I just want to avoid unfair characterization and irrelevant ad hominem comments. Am I being too defensive or do other people share this concern?

rdtsc 12y ago
> However, are these sort of off the cuff comments the right way to start a discussion about it? Well it is a persons' opinion. There are some facts, some humor, some personal opinions. I am not sure the author planned on being on the front page of HN. I don't think he submitted his own article. It is up to the readers to put things in the appropriate "bins" so to speak -- "This is good advice", "I don't like this part", "This is just a personal attack" and so on. Sometimes the same article can contain a variety of things.

kristianp 12y ago

From what I can gather on the mailing list threads, the language designers are against polymorphism, as well as adding letters to function names, so unlike the standard C library which operates on float, double, and long double, as well as int and long where appropriate (e.g. absolute value), the Go standard math library operates only on float64. This is criticism of go I haven't heard before.

rvalue 12y ago

I still find it shocking how people can continue to write in Go which still does not have an official debugger!

lugg 12y ago

My workflow at present is to print out the hex representation of a binary file onto physical sheets of paper, and then mark them up with a ball-point pen that I received last year at a conference about technology. I love writing like this, where you got that pen doesn't matter one bit, yet it turns the drab of a tech blog into an enjoyable story to read.

coldgrnd 12y ago

is the code of "Hecate: The Hex Editor From Hell" available to look at?

hpux 12y ago
The same question here.

AnonJ 12y ago

This author is quite exaggerating a bit. It seems like he himself is constantly preoccupied with politics. Fine. But this doesn't mean other people who he see with his eyes are necessarily thinking in the same pattern. "Machiavellian" is such a heavy word. Go started out with a purpose, a purpose which makes a lot of sense. It's not all about "make a new language and shove the new rules onto everyone by coupling it with Very Fast Build Times, a kind of veto-proof Defense Spending Bill in the Congress of computer programming." Such a design has a lot of practical value.