15 ms·

Why I Like Go

179 points by craigkerstiens 14y ago

niggler 14y ago
"Go compiles down to native code and it does it fast. Usually in just a few seconds." Very strange statement. Most programming languages/runtimes do small operations very quickly.
- StavrosK 14y ago
  What do you mean? He means that you can compile a pretty large program in seconds, most languages' compilers aren't that fast.
  - niggler 14y ago
    What's "pretty large"? It's fair to say that compilation is quick, but that's meaningless without a comparison. For example, you can generate really short C++ programs that exploit the template mechanism to perform heavy calculations at compile time.
    - shadowmint 14y ago
      It's not a scientific test or anything, but the results are so marked it's almost worth not even bothering to measure it: 24k loc of C (24743 total excluding headers and comments), using ninja and cmake, without using the autofail tool suite (which ups the time taken about about 150%): $ time make ... real 0m16.929s user 0m9.952s sys 0m4.641s 23kloc of go code (23588 total excluding comments): $ time go build ... real 0m1.667s user 0m1.331s sys 0m0.214s
  - seanmcdirmid 14y ago
    What do you mean? Even C# is measured in millions of lines per-second. The only compilers that are kind of slow these days deal with complex static type systems (Scala), whereas Go has a simple static type system and should compile fast.
    - laureny 14y ago
      Agreed. In terms of compilation times, Scala feels as slow in compilation times as C++ did in the early 2000's. Kotlin and Ceylon are showing that it's possible to be a modern JVM language and still compile fast. Hopefully, Scala can learn from them.
      - seanmcdirmid 14y ago
        Martin Odersky does care about compilation speed a lot and pulls out as many tricks as possible to make it faster. But Scala has a way powerful type system in a way that I doubt Kotlin and Ceylon are barely approaching. I don't think many want to give up scala's features for better compilation speed, which anyway can be mitigated via better incremental compilation (disclaimer, my experience is about 5 years out of date).
    - meaty 14y ago
      With c# though it has to compile it again at runtime which destroys your advantage.
      - seanmcdirmid 14y ago
        That hasn't been true for a long time (ngen.....).
        meaty 14y ago
        Ngen is useless if you're deploying to IIS. Think of views, asp.net pages etc. You're to going to put them in the GAC are you. Ir makes pretty much no sense to ngen anything other than stuff exposed to com or core framework bits. All you do is fuck yourself at deploy time.
        seanmcdirmid 14y ago
        I've never done any asp.net programming, but then isn't C# competitive with everything else in that space (like python, ruby...)? .net has a pretty good back end and the only thing you really fight with is not instruction compilation/execution time, but garbage collection. GC is mainly why you might want to use C++ sometimes instead of C#.
  - laureny 14y ago
    > most languages' compilers aren't that fast All mainstream languages compile in about that ballpark, if not faster. I've always found it odd that one of the driving design principles of Go was "fast compilation". It's always struck me as odd and short-sighted, obviously motivated by the Go authors' history with C++. If only they had spent some more time studying other languages, they would have realized that compilation times are really not a concern in languages these days, and they might also have designed Go with more modern features in mind, such as exceptions and generics.
    - DeepDuh 14y ago
      Not really a concern? I don't agree. Look at large C++ projects, and let's not speak about GPU frameworks like CUDA, OpenCL and OpenACC. If it weren't be a concern, software companies wouldn't invest in clusters just for compilation.
      - laureny 14y ago
        Didn't I just single out C++ as the only mainstream language being slow to compile?
        RobotCaleb 14y ago
        Apparently you're stuck in a world where nobody around you uses C++. I hate to be the one to break the news to you...
        laureny 14y ago
        Didn't I just call C++ "mainstream"?
      - pjmlp 14y ago
        Contrary to what many young developers may think, C and C++ aren't the only languages with compilation to native code. Already in 1987 Turbo Pascal 4.0 was compiling quite fast, Borland states around 34,000 lines/minute for the 5.5 version in 1989. Similar compilation speeds are possible for languages with modules, since the early 80's. Go's compilation speed is only news for someone that never used a module based language for systems programming like Modula-2 or Turbo Pascal, just to name two.
- sehugg 14y ago
  It looks like Go has a compiler implementation with a custom linker and object format. Turbo Pascal got much of its speed from its linker (and by having a module system instead of include files) so they may have decided on the same strategy. They do list the Wirth family of languages as an influence in the FAQ -- of course Oberon and Plan 9 also have history with the Go designers.
mvzink 14y ago
Question re: only utilizing one CPU and GOMAXPROCS: would it be in bad taste to, by default, for a program which might be used by other people (and uses goroutines extensively) to include in initialization "runtime.GOMAXPROCS(runtime.NumCPU())"?
- carbocation 14y ago
  I asked this on the freenode #go-nuts channel. The consensus was no. 1) Not every program benefits from this. 2) It's hoped that this will be deprecated soon hopefully.
- wmf 14y ago
  C or Java programs use all cores by default. I think it's reasonable for Go to have the same default.
  - jlgreco 14y ago
    C, previous to C11, didn't even have a concept of threading... (And who the hell is using C11 like that anyway?)
    - wmf 14y ago
      OK, pthreads.
      - jlgreco 14y ago
        It is going to be a pretty hard sell that mimicking pthreads is ever a good idea... Regardless, considering the casual nature of goroutines and the deliberate heavy-weight nature of pthreads, I find it hard to see pthreads as being any sort of argument about what Go should do, regardless of pthreads' shortcomings. They are wildly different animals.
deleted 14y ago
[deleted]
revelation 14y ago
Simple C Interface By using build directives you can integrade with C libraries really easily. And its a bunch of magic. I thought these people were serious about having a language for "systems programming". What good is it if it can't properly interface with the systems programming language that people actually use, C? It seems they wanted to add "C interop", but didn't understand what that means.. at all. You give it a header with function prototypes, because thats apparently the only way to tell it "I want to call this native function", and you get... undefined references for the native functions? What the hell is it even trying to do? You don't have source and you don't have linker stubs for a lot of the libraries you want to interop with. It's a complete non-starter. It's interop for awesome magic demos.
- james4k 14y ago
  It sounds like you couldn't get it to work and then decided they've done it wrong. I'm not terribly convinced.
- shadowmint 14y ago
  What? CGO is pretty cool actually. It does have some irritating downsides (pkg-config for example, is used, and there's no other option to link to a specific library afaik)... ...but seriously, what are you even talking about? All you need is a header, and a binary (library; .so or .dll). Done. How would you even use a library that doesn't have a header? Sounds like you've spent some time using COM objects and the . autocomplete function on them; that's just windows crazy-talk, if you want to use that kind of nonsense, go write powershell.
- drivebyacct2 14y ago
  You, literally, have no idea what you're talking about. And I'll simply laugh at your very last sentence.
- jbarham 14y ago
  Nonsense. Go's cgo facility is a fantastically productive way to wrap C code. I've written a lot wrappers using Python's C API and a bunch wrappers using cgo and cgo is light years ahead. For a real-world comparison see this Sqlite wrapper for Go at http://code.google.com/p/gosqlite/source/browse/sqlite/sqlite.go http://code.google.com/p/gosqlite/source/browse/sqlite/sqlit... and compare it to a similar wrapper for Python at http://code.google.com/p/pysqlite/source/browse/#hg%2Fsrc http://code.google.com/p/pysqlite/source/browse/#hg%2Fsrc. The Go wrapper isn't a "magic demo", it's code that works reliably in production. The bottom line is that cgo lets me quickly write production quality C wrappers for Go using Go itself.
jsdavo 14y ago
It gets Damien Katz's approval so I'm learning it ASAP. https://twitter.com/damienkatz/status/289575389641179137 https://twitter.com/damienkatz/status/289575389641179137
cincinnatus 14y ago
Sounds like a list of C# benefits. In 2004.
- shurcooL 14y ago
  C# doesn't build native binaries on all platforms out of the box.
  - pjmlp 14y ago
    Like any other language. Don't mix a language with the available implementations. You can get native binaries with ngen or mono -aot. The dependency on CLR is no different than relying on libc being available when using dynamic linking.
- jkat 14y ago
  Except for the goroutine and channel, and the type system, and the package system.
  - pjmlp 14y ago
    Ah you mean Task Parallel Library and NuGet?
    - deleted 14y ago
      [deleted]
    - jkat 14y ago
      I didn't realize NuGet let you do remote path import. Nor that it was around in 2004. Nor that it's part of the C# language spec. Goroutine + Channels are vastly different than the TPL. The comparison is so far off that I can't even come up with a clever analogy. There's more to concurrency than threads, and more to communication than locks.
      - pjmlp 14y ago
        > I didn't realize NuGet let you do remote path import. Nor that it was around in 2004. Nor that it's part of the C# language spec. Fare enough if you want to limit yourself to 2004 and compiler specific support. > Goroutine + Channels are vastly different than the TPL If you take out your Go coloured glasses and read in what TPL does, you will see that what Goroutines and channels are indeed available as Tasks and Queues.
dinkumthinkum 14y ago
These posts make me feel like Go is some oddball quirky person we all know and we all feel like we have talk about how great he/she is at some drunken party. I mean, we all love Go and all ...
- pjmlp 14y ago
  Some people need support from others to confirm they are making a good choice.
shurcooL 14y ago
I've become aware of Go just a few months go, but I already like it so much that I'm planning to make my next/current project in it, after using C++ exclusively the last 8+ years. It has a lot of good things going for it, as a modern language should, but IMO that only makes it a viable alternative. What really pushes it over onto the "I wanna use it" side is how easy and natural it makes concurrent programming. See e.g. vimeo.com/53221560
wsc981 14y ago
Unrelated: I like the fact this person used Github as a "blog". I've been looking for some good blogging software & host for a while, but Github might just fit my needs :)
- jkat 14y ago
  it's pretty common..it leverages github pages (1) which itself is powered by jekyll (2) (1) http://pages.github.com/ http://pages.github.com/ (2) http://jekyllrb.com/ http://jekyllrb.com/
- minhajuddin 14y ago
  Checkout http://substancehq.com http://substancehq.com too, it is a very simple hosted blogging engine.
  - wsc981 14y ago
    Thanks, it seems like a nice tool. Formats Objective-C as well! Great for my purposes :)
- MatthewPhillips 14y ago
  Word of caution: GitHub has, at least in the past, had issues of gh-pages taking hours to be built. So if you are writing something particularly timely (like a project announcement) it might not be the best idea. I gave up on using it for precisely this reason ~ 1 year ago so things might have improved.
rogerbinns 14y ago
I'm still of the opinion go messed up the error handling badly. As a simple example note how every tutorial doesn't bother looking for the error return of println calls and hence would silently ignore errors. IMHO the ideal solution is that if you make no effort to look at the error return of a function, it is automatically returned to your parent. This is somewhat analogous to exceptions, but they require a lot more syntax. (Yes I know about panic/recover.)
- drivebyacct2 14y ago
  I always find it interesting that people repeat the example of println as if it's any different than any other time that you make a decision to ignore or check error codes. It's no different than most other languages that would be in Go's category. Also, I presume you meant fmt.Println (println shouldn't be used and almost surely doesn't return an error). >is that if you make no effort to look at the error return of a function, it is automatically returned to your parent That would be... very, very, very strange for a huge number of reasons. Syntactically, function signature wise... You're basically just asking for exceptions in that case. And besides, that's how most functions that can error work, as I'm sure you know from any example code. function makeSomething() (Something, error) { something = new(Something) err = mightBreak(something) if err != nil { return nil, err } else { return something, nil } } Yes, it's explicit error handling. Yes, it's griped about on every, single HN thread about Go. And the mailing list, extensively. For a parallel example, do you call checkError() on your PrintStream (System.out) in Java after calling System.out.println? If not, you're not really checking to make sure println worked: http://docs.oracle.com/javase/6/docs/api/java/io/PrintStream.html http://docs.oracle.com/javase/6/docs/api/java/io/PrintStream...
  - sbov 14y ago
    Make a decision to or forget to check error codes. My gripe is fairly different from the OP's in this aspect. Go is inconsistent. For functions that return values I need to use, I will be warned by the compiler if I forget to handle the error. For those that don't, the compiler will happily let me accidentally ignore the error. I'd rather require that all return values be handled whether I use them or not. For the rare case that a function returns a value I honestly don't care about, I can just use _. At least I'm not hiding the fact that I knowingly am ignoring stuff. (Edit: despite the above, I still do enjoy using Go.)
jetti 14y ago
"Oh, and there isn't any pointer math, so you won't screw yourself with it." It has been said before and I'll say it again here, but because you can mess stuff up because you don't know what your doing is a terrible reason to not have something in a language (or even a program).
- ericbb 14y ago
  Incidentally, I don't think it's entirely true that "there isn't any pointer math". I've never used it but I understand that you can do C-like pointer tricks by using the package called "unsafe": http://golang.org/pkg/unsafe/ http://golang.org/pkg/unsafe/ and http://golang.org/ref/spec#Package_unsafe http://golang.org/ref/spec#Package_unsafe
  - dchest 14y ago
    Yes, indeed. Here's the "canonical" C strlen translated to unsafe Go with pointer arithmetic: package main import ( "fmt" "unsafe" ) func strlen(b []byte) int { str := uintptr(unsafe.Pointer(&b[0])) s := str for ; *(*byte)(unsafe.Pointer(s)) != 0; s++ {} return int(s - str) } func main() { fmt.Println(strlen([]byte("ho ho ho\000"))) } Not that anyone should use it :-) The safe and readable variant of this, often used in Go code, is "slice arithmetic", like this: http://golang.org/src/pkg/crypto/sha256/sha256.go#L105 http://golang.org/src/pkg/crypto/sha256/sha256.go#L105
- pekk 14y ago
  I agree, but at the same time it seems good for pointer math to be marked off as unusual - something you only do when you are down a manhole, not the default way of doing normal things.
- barrkel 14y ago
  I think it's an excellent reason for not having something in a language. It's not you or me I'm worried about; it's all the other people, and their libraries that I may take dependencies on. The more error-prone the constructs available in a language, the more likely artifacts created with the language, on average, are to have errors. The easiest way of eliminating these problems is to eliminate the constructs. This only becomes a serious problem if the workarounds are too verbose, too inefficient, or impossible. Not all applications will need the workarounds. If that subset of applications is productive, the language may be viable - or at least, won't be non-viable because of lack of the given constructs.
graue 14y ago
These points are all very true, and I admit I haven't done more with Go yet than play around. But there are a few reasons I feel I don't like Go, or at least, there are warts that will probably limit how much I'm going to like it. Nil pointers are #1 on that list. Tony Hoare called them a "billion dollar mistake"[1]. In Go, as in C, C++, or Java, any pointer can be `nil` (similar to `NULL`) at any point in time. You essentially always have to check; you're constantly just one pointer dereference away from blowing up the program. Since ways of solving this problem are known, I find this hard to swallow in a new language. Compare Rust where, unless you have explicitly used the unsafe features of the language, all pointers are guaranteed non-nil and valid. Instead of a function returning a nil pointer, it returns an `Option` type which is either `Some ptr` or `None`. The type system guarantees you have considered both possibilities so there's no such thing as a runtime null pointer dereference. Scala has a similar `Option` type, as does Haskell, calling it `Maybe`. In 2013 I don't want to still constantly check for a nil pointer, or have my program blow up at runtime if I forget. The second disappointment is that when I looked into it, it seemed there are ways to call C functions from Go code, but no working way to call Go from C code. Maybe that wasn't a goal at Google, but it seems like a missed opportunity. As a result, you can't use Go to write an Nginx module, or an audio plugin for a C/C++ host app, or a library that can be used from multiple languages. I think there is a real unmet need for a higher-level, safer language you can use to write libraries. Imagine if zlib, or libpng, or the reference implementations of codecs (Vorbis, Opus, VP8) could be written in something like Go. Or spelling correction libraries. Currently we have two tiers of libraries: those written in C/C++, which can be used from any language under the sun (Python bindings, Ruby bindings, Perl bindings, PHP bindings...), and those written in high-level dynamic languages (Python, Ruby, Perl, PHP, ...) which can only be used by the same language. We need a middle ground. C isn't expressive or safe enough to deserve to be the lingua franca like this. And Go is tantalizingly close to replacing it, but not quite. [1]: http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc...
- pixie_ 14y ago
  What about instead of having non-nullable types - do what objective-c does and 'drop' calls to null objects. There's been a number of times that instead of my application blowing up from a null exception, whatever feature my user was using just didn't work, but the rest of the application ran fine and they could report the bug to me. It's a much nicer user experience to have the car 'not' blow up if the AC button isn't working.
jxcole 14y ago
I would like to add one other thing I like about go: There is a parser and an abstract syntax tree in the standard library. Sometimes when I'm programming at work I need to add log messages to every method on a large interface (or several interfaces). It is obvious to me that there needs to be some tool or library that adds these very simple log messages to these methods for me (like "Entering method getUser(UserId=2701, SessionId='AABCF')"). The tool we have at work uses runtime generated code to add these messages to methods automatically. Besides the performance hit this is fine, except for one problem. Sometimes it doesn't work; and it is impossible to figure out why. You turn on the tool, add all the right metadata, and nothing happens. You could argue that it is a tool problem, but I think one of the big things is that runtime generated code is just vastly inferior to compile time generated code. If I were using go, my tool would open the code, read the interfaces, and spit out a nice implementation of logging in a .generated.go file and if it doesn't work for some reason I can actually go look at the generated code and see why. Trying to figure out why an implementation isn't working by looking at it's dynamically generated bytecode or .net clr is not fun at all.
- contingencies 14y ago
  runtime generated code is just vastly inferior to compile time generated code That's a big call. I think you should curtail it, eg. "runtime generate code can be harder to debug". This is often true but not always. Let's not get in to workmen and their tools.
  - lemming 14y ago
    I agree with the GP's statement, because "harder to debug" == "vastly inferior". In my last job we worked a huge amount with generated code, and having generated source that you can step through is essential. I've never seen runtime generated code that's easy to debug.
    - batgaijin 14y ago
      Lisp macros?
blt 14y ago
It's interesting how many people post about moving to Go from an interpreted or VM language background. The original presentation video pitched it as a C++ replacement, but that is clearly not the whole story. This author does not seem to have much experience in native development. I wonder if the Go designers predicted how many people they'd convert from python/ruby/java.
- pjmlp 14y ago
  Yeah, what many of these people state as Go features are actually common to many static compiled languages in the Pascal/Modula family. Old becomes new when you don't know it.
- kbuck 14y ago
  Frankly, I think a lot of the people currently working with C/C++ are avoiding Go because of the garbage collector. You can't trust a garbage collector; you don't know when it will run, how long it'll take, or how quickly it will free the memory you used. C/C++ programmers are used to having complete control over all of this. Sure, you could familiarize yourself with the internals of whichever GC you're working with, but at that point you might as well have invested the same amount of time writing the program in a language without a GC.
  - wting 14y ago
    That's one of the reasons Rust appealed to me more than Go. Go has a global mark and sweep GC. OTOH Rust has a thread local, optional GC.
  - dualogy 14y ago
    > You can't trust a garbage collector; you don't know when it will run, how long it'll take, or how quickly it will free the memory you used You can certainly control the GC somewhat. For example, disable unpredictable automatic GC and run GC yourself at a more opportune time, or never (if the program terminates before consuming all swap space of course). I have one app where I loop continously and invoke the GC every second. Why so often -- crazy, right? No because the "garbage" generated over that second --thanks to some memory-aware development practices-- is minimal, so the GC call will typically return in way under 1ms. Of course that's a meaningless number without app context and other numbers, but you do get some control. Basically Go gives you both philosophies. On one hand, you can auto-GC and never worry about mem or perf and simply "code out" your need, like you would in Java/C#/Python etc. Or, you can carefully design data structures and operations with allocations and GC (or supressed/non-existing GC) in mind. Sure, you don't get direct access to malloc()/free(), but implicitly (via Go's data structures, struct values vs pointers etc etc) you have a great deal more control over memory accesses, allocations etc.
flashmob 14y ago
Another great thing: gofmt - Go has no style guide, just this tool! Committed code ends up looking cleaner and you don't have to adapt to other's wacky standards. No more tabs vs spaces arguments or where to place that brace... brilliant. http://golang.org/doc/effective_go.html#formatting http://golang.org/doc/effective_go.html#formatting
- jff 14y ago
  It does have a style guide, it's just that gofmt will automatically make your code conform to that style guide :) The Go style is close enough to my normal C style that I end up mostly conforming anyway, but gofmt is great for making code look a bit prettier.
Daviey 14y ago
Argh! I felt rage reading: Package System or lack there of. Since Go compiles everything statically, you don't have to worry about packages at runtime. But how do you include libraries into your code? Simply by importing them via url, like so: import "github.com/bmizerany/pq" It was all good until that point.
- burntsushi 14y ago
  Are you going to say why, or just let us guess?
  - lobster_johnson 14y ago
    My guess: Remote packages are useless because (afaik) you can't specify a revision. This means "go get" will get the latest HEAD, which could be anything. Go needs something like Ruby's Bundler to let a package declare what versions are required and let you pin to specific versions.
    - burntsushi 14y ago
      If I desperately needed a specific version of a package, I'd fork the project and freeze it where appropriate. Does the `go` tool need to be aware of versions? IMO, no. Would it be a nice feature if it could be added without making the tool difficult to use? Yes. But so far, it hasn't appeared to slow anyone down. I've worked quite a bit with distribution tools for both Python and Haskell, and Go's tool is a breath of fresh air.
nogo 14y ago
Google pr is doing a great job with the go language. Every day 2-3 stories is always highly rated on a language not many people outside google cares about. Time to hellban som accounts maybe?
- vanderZwan 14y ago
  Says an account called "nogo" created 5 minutes before posting?
  - deleted 14y ago
    [deleted]
  - drivebyacct2 14y ago
    Ironically there is someone creating new accounts and trolling each of the Go posts. Last time it was someone spewing inconsistent lies about the Go build system.
    - jlgreco 14y ago
      My money is on the 0xABADC0DA doing it. An obsession with Google's relationship with Go and thinking that google employees were gaming HN to push Go was kind of his MO. Really quite obnoxious, I don't know who he thought his audience was.
- dualogy 14y ago
  Go is a "Google language" about as much as C is "the AT&T language". So you really think Google is paying developers to blog about Go? Where do I sign up, I want some of that cake...
- jff 14y ago
  Well, I think somebody's account will be hellbanned today...
- georgemcbay 14y ago
  Unlike Java or C# or some other languages, there's basically no monetization path for Google from Go. They don't sell a Go compiler or IDE or anything like that. The whole this is open source and free. Go for them is a project aimed at solving their own problems, and if it solves yours too, so be it. With that in mind, your theory doesn't make a whole lot of sense. As one of the people who does upvote the Go stories and has posted one myself, I think the real reason you see this is Go is an incredibly fun language to learn (at least if you're already a programmer, I can't speak for true neophytes) and the design of both the language and the API remind you about how much complexity you can get out of combining a few simple concepts. After years of dealing with other people's 1000 line FactoryOfFactoriesFactory classes in Java, such simplicity is incredibly refreshing and it is difficult not to try to direct other programmers into taking a look. IMO there's a lot of benefit to playing around with Go even if you end up not using it as a primary language and thus I plan to continue evangelizing it.
z3phyr 14y ago
But I like Haskell more.
ungerik 14y ago
Another one in a long list :) The case for Go: https://gist.github.com/ungerik/3731476 https://gist.github.com/ungerik/3731476
seivan 14y ago
I've been thinking of leaving Ruby for web applications. Both Go and Haskell are contenders because of the compilation step. Been doing iOS so much lately (almost 3 years now) over the course, I've come to love compiled languages much more. I still use Ruby for backend services and smaller scripts. But I want to leave it for larger backend software. This was a nice list, thank you.
grn 14y ago
I remember that Go had some issues related to the garbage collector on 32-bit machines. Are they solved now?
- freeformz 14y ago
  Not fully... http://code.google.com/p/go/issues/detail?id=909 http://code.google.com/p/go/issues/detail?id=909
cwarrior 14y ago
Is Go used any where else besides at Google?
- freeformz 14y ago
  yes

179 points by craigkerstiens 14y ago

"Go compiles down to native code and it does it fast. Usually in just a few seconds." Very strange statement. Most programming languages/runtimes do small operations very quickly.

StavrosK 14y ago
What do you mean? He means that you can compile a pretty large program in seconds, most languages' compilers aren't that fast.
- niggler 14y ago
  What's "pretty large"? It's fair to say that compilation is quick, but that's meaningless without a comparison. For example, you can generate really short C++ programs that exploit the template mechanism to perform heavy calculations at compile time.
  - shadowmint 14y ago
    It's not a scientific test or anything, but the results are so marked it's almost worth not even bothering to measure it: 24k loc of C (24743 total excluding headers and comments), using ninja and cmake, without using the autofail tool suite (which ups the time taken about about 150%): $ time make ... real 0m16.929s user 0m9.952s sys 0m4.641s 23kloc of go code (23588 total excluding comments): $ time go build ... real 0m1.667s user 0m1.331s sys 0m0.214s
- seanmcdirmid 14y ago
  What do you mean? Even C# is measured in millions of lines per-second. The only compilers that are kind of slow these days deal with complex static type systems (Scala), whereas Go has a simple static type system and should compile fast.
  - laureny 14y ago
    Agreed. In terms of compilation times, Scala feels as slow in compilation times as C++ did in the early 2000's. Kotlin and Ceylon are showing that it's possible to be a modern JVM language and still compile fast. Hopefully, Scala can learn from them.
    - seanmcdirmid 14y ago
      Martin Odersky does care about compilation speed a lot and pulls out as many tricks as possible to make it faster. But Scala has a way powerful type system in a way that I doubt Kotlin and Ceylon are barely approaching. I don't think many want to give up scala's features for better compilation speed, which anyway can be mitigated via better incremental compilation (disclaimer, my experience is about 5 years out of date).
  - meaty 14y ago
    With c# though it has to compile it again at runtime which destroys your advantage.
    - seanmcdirmid 14y ago
      That hasn't been true for a long time (ngen.....).
      - meaty 14y ago
        Ngen is useless if you're deploying to IIS. Think of views, asp.net pages etc. You're to going to put them in the GAC are you. Ir makes pretty much no sense to ngen anything other than stuff exposed to com or core framework bits. All you do is fuck yourself at deploy time.
        seanmcdirmid 14y ago
        I've never done any asp.net programming, but then isn't C# competitive with everything else in that space (like python, ruby...)? .net has a pretty good back end and the only thing you really fight with is not instruction compilation/execution time, but garbage collection. GC is mainly why you might want to use C++ sometimes instead of C#.
- laureny 14y ago
  > most languages' compilers aren't that fast All mainstream languages compile in about that ballpark, if not faster. I've always found it odd that one of the driving design principles of Go was "fast compilation". It's always struck me as odd and short-sighted, obviously motivated by the Go authors' history with C++. If only they had spent some more time studying other languages, they would have realized that compilation times are really not a concern in languages these days, and they might also have designed Go with more modern features in mind, such as exceptions and generics.
  - DeepDuh 14y ago
    Not really a concern? I don't agree. Look at large C++ projects, and let's not speak about GPU frameworks like CUDA, OpenCL and OpenACC. If it weren't be a concern, software companies wouldn't invest in clusters just for compilation.
    - laureny 14y ago
      Didn't I just single out C++ as the only mainstream language being slow to compile?
      - RobotCaleb 14y ago
        Apparently you're stuck in a world where nobody around you uses C++. I hate to be the one to break the news to you...
        laureny 14y ago
        Didn't I just call C++ "mainstream"?
    - pjmlp 14y ago
      Contrary to what many young developers may think, C and C++ aren't the only languages with compilation to native code. Already in 1987 Turbo Pascal 4.0 was compiling quite fast, Borland states around 34,000 lines/minute for the 5.5 version in 1989. Similar compilation speeds are possible for languages with modules, since the early 80's. Go's compilation speed is only news for someone that never used a module based language for systems programming like Modula-2 or Turbo Pascal, just to name two.
sehugg 14y ago
It looks like Go has a compiler implementation with a custom linker and object format. Turbo Pascal got much of its speed from its linker (and by having a module system instead of include files) so they may have decided on the same strategy. They do list the Wirth family of languages as an influence in the FAQ -- of course Oberon and Plan 9 also have history with the Go designers.

mvzink 14y ago

Question re: only utilizing one CPU and GOMAXPROCS: would it be in bad taste to, by default, for a program which might be used by other people (and uses goroutines extensively) to include in initialization "runtime.GOMAXPROCS(runtime.NumCPU())"?

carbocation 14y ago
I asked this on the freenode #go-nuts channel. The consensus was no. 1) Not every program benefits from this. 2) It's hoped that this will be deprecated soon hopefully.
wmf 14y ago
C or Java programs use all cores by default. I think it's reasonable for Go to have the same default.
- jlgreco 14y ago
  C, previous to C11, didn't even have a concept of threading... (And who the hell is using C11 like that anyway?)
  - wmf 14y ago
    OK, pthreads.
    - jlgreco 14y ago
      It is going to be a pretty hard sell that mimicking pthreads is ever a good idea... Regardless, considering the casual nature of goroutines and the deliberate heavy-weight nature of pthreads, I find it hard to see pthreads as being any sort of argument about what Go should do, regardless of pthreads' shortcomings. They are wildly different animals.

deleted 14y ago

[deleted]

revelation 14y ago

Simple C Interface By using build directives you can integrade with C libraries really easily. And its a bunch of magic. I thought these people were serious about having a language for "systems programming". What good is it if it can't properly interface with the systems programming language that people actually use, C? It seems they wanted to add "C interop", but didn't understand what that means.. at all. You give it a header with function prototypes, because thats apparently the only way to tell it "I want to call this native function", and you get... undefined references for the native functions? What the hell is it even trying to do? You don't have source and you don't have linker stubs for a lot of the libraries you want to interop with. It's a complete non-starter. It's interop for awesome magic demos.

james4k 14y ago
It sounds like you couldn't get it to work and then decided they've done it wrong. I'm not terribly convinced.
shadowmint 14y ago
What? CGO is pretty cool actually. It does have some irritating downsides (pkg-config for example, is used, and there's no other option to link to a specific library afaik)... ...but seriously, what are you even talking about? All you need is a header, and a binary (library; .so or .dll). Done. How would you even use a library that doesn't have a header? Sounds like you've spent some time using COM objects and the . autocomplete function on them; that's just windows crazy-talk, if you want to use that kind of nonsense, go write powershell.
drivebyacct2 14y ago
You, literally, have no idea what you're talking about. And I'll simply laugh at your very last sentence.
jbarham 14y ago
Nonsense. Go's cgo facility is a fantastically productive way to wrap C code. I've written a lot wrappers using Python's C API and a bunch wrappers using cgo and cgo is light years ahead. For a real-world comparison see this Sqlite wrapper for Go at http://code.google.com/p/gosqlite/source/browse/sqlite/sqlite.go http://code.google.com/p/gosqlite/source/browse/sqlite/sqlit... and compare it to a similar wrapper for Python at http://code.google.com/p/pysqlite/source/browse/#hg%2Fsrc http://code.google.com/p/pysqlite/source/browse/#hg%2Fsrc. The Go wrapper isn't a "magic demo", it's code that works reliably in production. The bottom line is that cgo lets me quickly write production quality C wrappers for Go using Go itself.

jsdavo 14y ago

It gets Damien Katz's approval so I'm learning it ASAP. https://twitter.com/damienkatz/status/289575389641179137 https://twitter.com/damienkatz/status/289575389641179137

cincinnatus 14y ago

Sounds like a list of C# benefits. In 2004.

shurcooL 14y ago
C# doesn't build native binaries on all platforms out of the box.
- pjmlp 14y ago
  Like any other language. Don't mix a language with the available implementations. You can get native binaries with ngen or mono -aot. The dependency on CLR is no different than relying on libc being available when using dynamic linking.
jkat 14y ago
Except for the goroutine and channel, and the type system, and the package system.
- pjmlp 14y ago
  Ah you mean Task Parallel Library and NuGet?
  - deleted 14y ago
    [deleted]
  - jkat 14y ago
    I didn't realize NuGet let you do remote path import. Nor that it was around in 2004. Nor that it's part of the C# language spec. Goroutine + Channels are vastly different than the TPL. The comparison is so far off that I can't even come up with a clever analogy. There's more to concurrency than threads, and more to communication than locks.
    - pjmlp 14y ago
      > I didn't realize NuGet let you do remote path import. Nor that it was around in 2004. Nor that it's part of the C# language spec. Fare enough if you want to limit yourself to 2004 and compiler specific support. > Goroutine + Channels are vastly different than the TPL If you take out your Go coloured glasses and read in what TPL does, you will see that what Goroutines and channels are indeed available as Tasks and Queues.

dinkumthinkum 14y ago

These posts make me feel like Go is some oddball quirky person we all know and we all feel like we have talk about how great he/she is at some drunken party. I mean, we all love Go and all ...

pjmlp 14y ago
Some people need support from others to confirm they are making a good choice.

shurcooL 14y ago

I've become aware of Go just a few months go, but I already like it so much that I'm planning to make my next/current project in it, after using C++ exclusively the last 8+ years. It has a lot of good things going for it, as a modern language should, but IMO that only makes it a viable alternative. What really pushes it over onto the "I wanna use it" side is how easy and natural it makes concurrent programming. See e.g. vimeo.com/53221560

wsc981 14y ago

Unrelated: I like the fact this person used Github as a "blog". I've been looking for some good blogging software & host for a while, but Github might just fit my needs :)

jkat 14y ago
it's pretty common..it leverages github pages (1) which itself is powered by jekyll (2) (1) http://pages.github.com/ http://pages.github.com/ (2) http://jekyllrb.com/ http://jekyllrb.com/
minhajuddin 14y ago
Checkout http://substancehq.com http://substancehq.com too, it is a very simple hosted blogging engine.
- wsc981 14y ago
  Thanks, it seems like a nice tool. Formats Objective-C as well! Great for my purposes :)
MatthewPhillips 14y ago
Word of caution: GitHub has, at least in the past, had issues of gh-pages taking hours to be built. So if you are writing something particularly timely (like a project announcement) it might not be the best idea. I gave up on using it for precisely this reason ~ 1 year ago so things might have improved.

rogerbinns 14y ago

I'm still of the opinion go messed up the error handling badly. As a simple example note how every tutorial doesn't bother looking for the error return of println calls and hence would silently ignore errors. IMHO the ideal solution is that if you make no effort to look at the error return of a function, it is automatically returned to your parent. This is somewhat analogous to exceptions, but they require a lot more syntax. (Yes I know about panic/recover.)

drivebyacct2 14y ago
I always find it interesting that people repeat the example of println as if it's any different than any other time that you make a decision to ignore or check error codes. It's no different than most other languages that would be in Go's category. Also, I presume you meant fmt.Println (println shouldn't be used and almost surely doesn't return an error). >is that if you make no effort to look at the error return of a function, it is automatically returned to your parent That would be... very, very, very strange for a huge number of reasons. Syntactically, function signature wise... You're basically just asking for exceptions in that case. And besides, that's how most functions that can error work, as I'm sure you know from any example code. function makeSomething() (Something, error) { something = new(Something) err = mightBreak(something) if err != nil { return nil, err } else { return something, nil } } Yes, it's explicit error handling. Yes, it's griped about on every, single HN thread about Go. And the mailing list, extensively. For a parallel example, do you call checkError() on your PrintStream (System.out) in Java after calling System.out.println? If not, you're not really checking to make sure println worked: http://docs.oracle.com/javase/6/docs/api/java/io/PrintStream.html http://docs.oracle.com/javase/6/docs/api/java/io/PrintStream...
- sbov 14y ago
  Make a decision to or forget to check error codes. My gripe is fairly different from the OP's in this aspect. Go is inconsistent. For functions that return values I need to use, I will be warned by the compiler if I forget to handle the error. For those that don't, the compiler will happily let me accidentally ignore the error. I'd rather require that all return values be handled whether I use them or not. For the rare case that a function returns a value I honestly don't care about, I can just use _. At least I'm not hiding the fact that I knowingly am ignoring stuff. (Edit: despite the above, I still do enjoy using Go.)

jetti 14y ago

"Oh, and there isn't any pointer math, so you won't screw yourself with it." It has been said before and I'll say it again here, but because you can mess stuff up because you don't know what your doing is a terrible reason to not have something in a language (or even a program).

ericbb 14y ago
Incidentally, I don't think it's entirely true that "there isn't any pointer math". I've never used it but I understand that you can do C-like pointer tricks by using the package called "unsafe": http://golang.org/pkg/unsafe/ http://golang.org/pkg/unsafe/ and http://golang.org/ref/spec#Package_unsafe http://golang.org/ref/spec#Package_unsafe
- dchest 14y ago
  Yes, indeed. Here's the "canonical" C strlen translated to unsafe Go with pointer arithmetic: package main import ( "fmt" "unsafe" ) func strlen(b []byte) int { str := uintptr(unsafe.Pointer(&b[0])) s := str for ; *(*byte)(unsafe.Pointer(s)) != 0; s++ {} return int(s - str) } func main() { fmt.Println(strlen([]byte("ho ho ho\000"))) } Not that anyone should use it :-) The safe and readable variant of this, often used in Go code, is "slice arithmetic", like this: http://golang.org/src/pkg/crypto/sha256/sha256.go#L105 http://golang.org/src/pkg/crypto/sha256/sha256.go#L105
pekk 14y ago
I agree, but at the same time it seems good for pointer math to be marked off as unusual - something you only do when you are down a manhole, not the default way of doing normal things.
barrkel 14y ago
I think it's an excellent reason for not having something in a language. It's not you or me I'm worried about; it's all the other people, and their libraries that I may take dependencies on. The more error-prone the constructs available in a language, the more likely artifacts created with the language, on average, are to have errors. The easiest way of eliminating these problems is to eliminate the constructs. This only becomes a serious problem if the workarounds are too verbose, too inefficient, or impossible. Not all applications will need the workarounds. If that subset of applications is productive, the language may be viable - or at least, won't be non-viable because of lack of the given constructs.

graue 14y ago

These points are all very true, and I admit I haven't done more with Go yet than play around. But there are a few reasons I feel I don't like Go, or at least, there are warts that will probably limit how much I'm going to like it. Nil pointers are #1 on that list. Tony Hoare called them a "billion dollar mistake"[1]. In Go, as in C, C++, or Java, any pointer can be `nil` (similar to `NULL`) at any point in time. You essentially always have to check; you're constantly just one pointer dereference away from blowing up the program. Since ways of solving this problem are known, I find this hard to swallow in a new language. Compare Rust where, unless you have explicitly used the unsafe features of the language, all pointers are guaranteed non-nil and valid. Instead of a function returning a nil pointer, it returns an `Option` type which is either `Some ptr` or `None`. The type system guarantees you have considered both possibilities so there's no such thing as a runtime null pointer dereference. Scala has a similar `Option` type, as does Haskell, calling it `Maybe`. In 2013 I don't want to still constantly check for a nil pointer, or have my program blow up at runtime if I forget. The second disappointment is that when I looked into it, it seemed there are ways to call C functions from Go code, but no working way to call Go from C code. Maybe that wasn't a goal at Google, but it seems like a missed opportunity. As a result, you can't use Go to write an Nginx module, or an audio plugin for a C/C++ host app, or a library that can be used from multiple languages. I think there is a real unmet need for a higher-level, safer language you can use to write libraries. Imagine if zlib, or libpng, or the reference implementations of codecs (Vorbis, Opus, VP8) could be written in something like Go. Or spelling correction libraries. Currently we have two tiers of libraries: those written in C/C++, which can be used from any language under the sun (Python bindings, Ruby bindings, Perl bindings, PHP bindings...), and those written in high-level dynamic languages (Python, Ruby, Perl, PHP, ...) which can only be used by the same language. We need a middle ground. C isn't expressive or safe enough to deserve to be the lingua franca like this. And Go is tantalizingly close to replacing it, but not quite. [1]: http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc...

pixie_ 14y ago
What about instead of having non-nullable types - do what objective-c does and 'drop' calls to null objects. There's been a number of times that instead of my application blowing up from a null exception, whatever feature my user was using just didn't work, but the rest of the application ran fine and they could report the bug to me. It's a much nicer user experience to have the car 'not' blow up if the AC button isn't working.

jxcole 14y ago

I would like to add one other thing I like about go: There is a parser and an abstract syntax tree in the standard library. Sometimes when I'm programming at work I need to add log messages to every method on a large interface (or several interfaces). It is obvious to me that there needs to be some tool or library that adds these very simple log messages to these methods for me (like "Entering method getUser(UserId=2701, SessionId='AABCF')"). The tool we have at work uses runtime generated code to add these messages to methods automatically. Besides the performance hit this is fine, except for one problem. Sometimes it doesn't work; and it is impossible to figure out why. You turn on the tool, add all the right metadata, and nothing happens. You could argue that it is a tool problem, but I think one of the big things is that runtime generated code is just vastly inferior to compile time generated code. If I were using go, my tool would open the code, read the interfaces, and spit out a nice implementation of logging in a .generated.go file and if it doesn't work for some reason I can actually go look at the generated code and see why. Trying to figure out why an implementation isn't working by looking at it's dynamically generated bytecode or .net clr is not fun at all.

contingencies 14y ago
runtime generated code is just vastly inferior to compile time generated code That's a big call. I think you should curtail it, eg. "runtime generate code can be harder to debug". This is often true but not always. Let's not get in to workmen and their tools.
- lemming 14y ago
  I agree with the GP's statement, because "harder to debug" == "vastly inferior". In my last job we worked a huge amount with generated code, and having generated source that you can step through is essential. I've never seen runtime generated code that's easy to debug.
  - batgaijin 14y ago
    Lisp macros?

blt 14y ago

It's interesting how many people post about moving to Go from an interpreted or VM language background. The original presentation video pitched it as a C++ replacement, but that is clearly not the whole story. This author does not seem to have much experience in native development. I wonder if the Go designers predicted how many people they'd convert from python/ruby/java.

pjmlp 14y ago
Yeah, what many of these people state as Go features are actually common to many static compiled languages in the Pascal/Modula family. Old becomes new when you don't know it.
kbuck 14y ago
Frankly, I think a lot of the people currently working with C/C++ are avoiding Go because of the garbage collector. You can't trust a garbage collector; you don't know when it will run, how long it'll take, or how quickly it will free the memory you used. C/C++ programmers are used to having complete control over all of this. Sure, you could familiarize yourself with the internals of whichever GC you're working with, but at that point you might as well have invested the same amount of time writing the program in a language without a GC.
- wting 14y ago
  That's one of the reasons Rust appealed to me more than Go. Go has a global mark and sweep GC. OTOH Rust has a thread local, optional GC.
- dualogy 14y ago
  > You can't trust a garbage collector; you don't know when it will run, how long it'll take, or how quickly it will free the memory you used You can certainly control the GC somewhat. For example, disable unpredictable automatic GC and run GC yourself at a more opportune time, or never (if the program terminates before consuming all swap space of course). I have one app where I loop continously and invoke the GC every second. Why so often -- crazy, right? No because the "garbage" generated over that second --thanks to some memory-aware development practices-- is minimal, so the GC call will typically return in way under 1ms. Of course that's a meaningless number without app context and other numbers, but you do get some control. Basically Go gives you both philosophies. On one hand, you can auto-GC and never worry about mem or perf and simply "code out" your need, like you would in Java/C#/Python etc. Or, you can carefully design data structures and operations with allocations and GC (or supressed/non-existing GC) in mind. Sure, you don't get direct access to malloc()/free(), but implicitly (via Go's data structures, struct values vs pointers etc etc) you have a great deal more control over memory accesses, allocations etc.

flashmob 14y ago

Another great thing: gofmt - Go has no style guide, just this tool! Committed code ends up looking cleaner and you don't have to adapt to other's wacky standards. No more tabs vs spaces arguments or where to place that brace... brilliant. http://golang.org/doc/effective_go.html#formatting http://golang.org/doc/effective_go.html#formatting

jff 14y ago
It does have a style guide, it's just that gofmt will automatically make your code conform to that style guide :) The Go style is close enough to my normal C style that I end up mostly conforming anyway, but gofmt is great for making code look a bit prettier.

Daviey 14y ago

Argh! I felt rage reading: Package System or lack there of. Since Go compiles everything statically, you don't have to worry about packages at runtime. But how do you include libraries into your code? Simply by importing them via url, like so: import "github.com/bmizerany/pq" It was all good until that point.

burntsushi 14y ago
Are you going to say why, or just let us guess?
- lobster_johnson 14y ago
  My guess: Remote packages are useless because (afaik) you can't specify a revision. This means "go get" will get the latest HEAD, which could be anything. Go needs something like Ruby's Bundler to let a package declare what versions are required and let you pin to specific versions.
  - burntsushi 14y ago
    If I desperately needed a specific version of a package, I'd fork the project and freeze it where appropriate. Does the `go` tool need to be aware of versions? IMO, no. Would it be a nice feature if it could be added without making the tool difficult to use? Yes. But so far, it hasn't appeared to slow anyone down. I've worked quite a bit with distribution tools for both Python and Haskell, and Go's tool is a breath of fresh air.

nogo 14y ago

Google pr is doing a great job with the go language. Every day 2-3 stories is always highly rated on a language not many people outside google cares about. Time to hellban som accounts maybe?

vanderZwan 14y ago
Says an account called "nogo" created 5 minutes before posting?
- deleted 14y ago
  [deleted]
- drivebyacct2 14y ago
  Ironically there is someone creating new accounts and trolling each of the Go posts. Last time it was someone spewing inconsistent lies about the Go build system.
  - jlgreco 14y ago
    My money is on the 0xABADC0DA doing it. An obsession with Google's relationship with Go and thinking that google employees were gaming HN to push Go was kind of his MO. Really quite obnoxious, I don't know who he thought his audience was.
dualogy 14y ago
Go is a "Google language" about as much as C is "the AT&T language". So you really think Google is paying developers to blog about Go? Where do I sign up, I want some of that cake...
jff 14y ago
Well, I think somebody's account will be hellbanned today...
georgemcbay 14y ago
Unlike Java or C# or some other languages, there's basically no monetization path for Google from Go. They don't sell a Go compiler or IDE or anything like that. The whole this is open source and free. Go for them is a project aimed at solving their own problems, and if it solves yours too, so be it. With that in mind, your theory doesn't make a whole lot of sense. As one of the people who does upvote the Go stories and has posted one myself, I think the real reason you see this is Go is an incredibly fun language to learn (at least if you're already a programmer, I can't speak for true neophytes) and the design of both the language and the API remind you about how much complexity you can get out of combining a few simple concepts. After years of dealing with other people's 1000 line FactoryOfFactoriesFactory classes in Java, such simplicity is incredibly refreshing and it is difficult not to try to direct other programmers into taking a look. IMO there's a lot of benefit to playing around with Go even if you end up not using it as a primary language and thus I plan to continue evangelizing it.

z3phyr 14y ago

But I like Haskell more.

ungerik 14y ago

Another one in a long list :) The case for Go: https://gist.github.com/ungerik/3731476 https://gist.github.com/ungerik/3731476

seivan 14y ago

I've been thinking of leaving Ruby for web applications. Both Go and Haskell are contenders because of the compilation step. Been doing iOS so much lately (almost 3 years now) over the course, I've come to love compiled languages much more. I still use Ruby for backend services and smaller scripts. But I want to leave it for larger backend software. This was a nice list, thank you.

grn 14y ago

I remember that Go had some issues related to the garbage collector on 32-bit machines. Are they solved now?

freeformz 14y ago
Not fully... http://code.google.com/p/go/issues/detail?id=909 http://code.google.com/p/go/issues/detail?id=909

cwarrior 14y ago

Is Go used any where else besides at Google?

freeformz 14y ago
yes