10 ms·

Why Go?

162 points by nathany 13y ago

rohshall 13y ago
I agree with everything except Go is fun or the assertion that it combines best of both dynamic and statically compiled languages. It is a minimalistic get-it-done language, I would say it is 'modern java'. There are no aha moments that you experience while learning go. It always feels like - ya, I have seen that. Go did not take the best of the pre-existing languages, it took the minimal set that made sense to the designers; for example: it omitted 'best' features like map, reduce and filter in favour of 'plain old boring' for loops. I wonder how many programmers can wake up in the morning and say to themselves - wow, I am going to program in Go today.
- nathany 13y ago
  Thanks for reading my article. It is my opinion that Go is fun, but it's just that, an opinion. I'm glad we have the diversity in programming languages that allows us to pick what we like (esp. when it comes to the server). Best.
- jff 13y ago
  If you don't think Go is fun, you've never made a channel of channels of functions.
- danenania 13y ago
  Go's aha moment is its low cognitive overhead. It eschews power and conciseness for clarity, everywhere. It takes the exact opposite approach to functional languages, preferring boring simplicity to powerful but cryptic abstraction. It turns out that an uncompromising devotion to clarity is quite powerful in its own right. It's not right for every use case, but highly compelling for many.
  - danieldk 13y ago
    Go's aha moment is its low cognitive overhead. I think some of us already had that with the first Java versions. Actually, Go looks a lot like old Java versions, minus the VM, plus Goroutines/channels, and static duck typing. I have written a fair share of Go code and ultimately it's a very boring, but predictable language. If it builds a larger ecosystem, it will not be much different than a Java that compiles to native code. Without some of the advantages of the JVM. (What we are really seeing here on HN lately is a hype, pretty much like node.js and FP before. Go has a better chance to stick, because it has a good steward.)
    - irrelative 13y ago
      Honest question: what do you consider the advantages of the JVM over native code?
      - hellrich 13y ago
        "Write once, run anywhere"
        qu4z-2 13y ago
        I've heard this far more commonly from Java programmers as "Write once, debug everywhere", but maybe that's changed. (this was quite some time ago)
      - threeseed 13y ago
        Definitely deployment flexibility. Write on OSX, Test on Linux, Run on Solaris. But also performance. JVM can be faster than say C/C++ code in many cases.
      - danieldk 13y ago
        - "Write once, run everywhere." as the sibling poster mentions. I can build on my Mac, deploy on whatever the server platform is. Snapshot and release builds of our build server are distributed via a Nexus-managed repository. So, everyone codes against exactly the same dependencies, regardless of the platform. - Hotswapping/JRebel. - Good interoperability with other languages. E.g. the Typesafe folks implemented Akka in Scala. Java gets it for (well, almost) free. - Easy monitoring and instrumentation. Obviously, there are downsides as well, such as startup times (twofold: starting the VM and Hotspot detection/compilation), preset heap size, expensive JNI (native interface), etc.
        dualogy 13y ago
        > Write once, run everywhere Well, so Go is "write once, build 3-9x, run anywhere".. close enough ;)
  - tikhonj 13y ago
    You're mistaking familiarity for simplicity. You cannot get much simpler than the lambda calculus, full stop. It has three concepts--lambdas, variables and application--and one evaluation rule. That is all. The rest of the language features are almost always just a thin layer over this. Even when you add types, it's still an amazingly simple model. And the types do not generally affect the runtime behavior of code at all. Functional languages are the very picture of something simple but not necessarily easy. Go, at least for you, is the opposite: it's easy because it's similar to what you're used to, but it also has quite a bit of surface area. My impression is that Go vies for simplicity of implementation over simplicity of semantics. It is a very operational sort of language. Its goal is to make the how clear--the code reflects what it does. Languages like Haskell, on the other hand, are completely the opposite. Haskell values simplicity of semantics over simplicity of implementation. It is a very denotational sort of language. Its goal is to make the what clear--the code reflects what it means. It's a difference in philosophies, certainly, just not quite in the way you construed it to be.
    - cgag 13y ago
      Great relevant talk: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
    - raganwald 13y ago
      Yes! Exceedingly simple semantics combining to form a difficult-to-use language is often called a "Turing Tar Pit," a place where everything is possible but nothing of interest is easy. Conway's Game of Life is even simpler than the lambda calculus, and people build all sorts of amazing things in it, but examples like a calculator that outputs human-readable digits are circus tricks.
      - papsosouid 13y ago
        >Exceedingly simple semantics combining to form a difficult-to-use language Who was suggesting that we should form difficult to use languages on those simple semantics?
  - pjmlp 13y ago
    > Go's aha moment is its low cognitive overhead. Very good for replaceable programmers, the dream of every manager. :)
    - delian66 13y ago
      Low cognitive overhead is also good for your future self, that will have to maintain the 'clever' mess which you wrote in a hurry ... In my experience so far, the abstractions that Go offers for writing concurrent code are very nice and easy to understand, and deploying it is really good - it generates static binaries, which you simply upload where you need them. It is a very practical language.
    - myg204 13y ago
      Simplicity in design is still a panacea, only good programmers can do it on non trivial systems. Go will allow for better clarity, but beautiful code will not write itself.
  - coldtea 13y ago
    >Go's aha moment is its low cognitive overhead. You mean its strength is that is a Blub language? Because the "low cognitive overhead" is exactly what Java was touted for, back in the day (before the EE madness).
    - danenania 13y ago
      It may make the blubs more effective, but that doesn't necessarily mean it can't also make the geniuses more effective too.
      - Roboprog 13y ago
        "Blub" refers to the language itself, rather than the developers. As in "think (no deeper than) in Blub (language concepts)" I can see both sides of the "clever is better/worse" argument, though. E.g. - C++ operator overloading is powerful and harmful.
  - MetaCosm 13y ago
    Go's aha moment IMHO is at the edges. If you have built a complex application (250k+ lines) in C++, Python or Java you know about the quiet undignified pains those projects often suffer. - Horrible build systems (and horrible build times) --- Go compiles fast, and the compile and dependency system is baked in - Impossible to untangle dependencies (don't ever remove an include, who knows where it is used) --- Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up - Nightmare deploys (system wide assumptions) --- Go deploys with a single platform dependent binary, it is absolutely awesome - Inconsistent formatting, self-directed standards on formatting. --- Gofmt is the one true format, heck, even some bad formatting won't compile (try to uncuddle your else to see) - Inconsistent build systems and build system quality, made worse by using libraries and systems that have their OWN build systems. --- Go get combined with its include system (use it or lose it) really let you tie together systems in a sane way without any custom build routes. - Dealing with modern concurrency --- Go having built in channel communication makes many problems trivial, and allows new methods of abstraction (goes to Go's model of composition).
    - danieldk 13y ago
      I'll take Java as an example, since I only use Python for short scripts. - Horrible build systems (and horrible build times) Maven is a great build system, Java has good compile times, and most modern Java IDEs have incremental compilation. And you can specify versions of dependencies, rather than having to maintain a list of SHA1 hashes of versions considered to be stable. (don't ever remove an include, who knows where it is used) This is primarily a problem in C/C++, where one can indirectly get the correct dependencies by accident. Most modern compiled languages don't have this problem. Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up Which can be annoying for debugging. I'd rather have my IDE or linter give warnings. - Nightmare deploys (system wide assumptions) 'mvn package', it's also easy to configure maven to build an archive with dependencies, configuration files, or whatever you'd like to be in a deploy. In fact, deployments are even easier than in Go, since my package built on OS X will also deploy on a Linux server. My colleagues use different platforms (a mixture of Linux, Windows, and OS X) and it's never a problem. - Inconsistent formatting, self-directed standards on formatting. It's good that the Go team made a standard formatting. That said, my employer has a default layout. It's a matter of importing an XML file in Eclipse or IntelliJ and everything is in company layout (yay). - Inconsistent build systems and build system quality Nearly every Java library is available via Central Maven Repository. Including versioning :), meaning that if upstream changes their API, it's not your problem. In contrast to Go repository/packages. Dealing with modern concurrency Ever heard of Actor models and Akka? Composable concurrency, across more than one machine. With supervision, routing, etc.
  - papsosouid 13y ago
    >It takes the exact opposite approach to functional languages, preferring boring simplicity to powerful but cryptic abstraction. Yes, functional programming is based on the idea that abstractions should be cryptic. That's a very reasonable observation, and not at all ignorant.
- orangethirty 13y ago
  I do look forward to programming in Go. My day gig is working with PHP and horribly written Python (globals everywhere). Go is, simply put, refreshing. So much, that I'm moving away from Python as my go to web language to Go.
- gravitronic 13y ago
  Spoken like someone who hasn't written much Go, or at least hasn't used it for what it's best at. I suggest you read Effective Go and try writing some concurrent applications. It's aha moments are plentiful once you realize the power in the simplicity.
  - pjmlp 13y ago
    I have written Go code, and what the language offers is no different from java.util.concurrent, .NET TPL, C++ Cilk, PPL, and many other frameworks offer.
    - jesstaa 13y ago
      Goroutines aren't really the selling point. It's simple enough to implement similar concepts in any language. It's the combination of a set of complimentary features, the maturity and the stability that really sells Go.
      - swah 13y ago
        They might be for programmers who don't have threads. Maybe that explains why its so popular with Python/Ruby/PHP folks?
      - gnaritas 13y ago
        You can't call Go mature.
- mseebach 13y ago
  > it omitted 'best' features like map, reduce and filter in favour of 'plain old boring' for loops Well, it included closures, so luckily it's trivial to add those after the fact.
  - danieldk 13y ago
    Yeah, per type or with interface{}, where every function has to do run-time introspection. Maybe trivial, but not lots of fun.
- DennisP 13y ago
  Go has first-class functions, so if you want map/reduce/filter there's nothing stopping you.
  - quatrevingts 13y ago
    Except that you lose type safety (or write an implementation for every permutation of types..)
    - DennisP 13y ago
      Didn't realize that, thanks.
  - papsosouid 13y ago
    Go doesn't have parametric polymorphism. So yeah, there is something stopping you.
    - voidlogic 13y ago
      Nope, not stopping you: http://blog.burntsushi.net/type-parametric-functions-golang http://blog.burntsushi.net/type-parametric-functions-golang
      - papsosouid 13y ago
        Yes, stopping me. "You can resort to a horrible ugly cludge and lose type safety for your efforts" is not having parametric polymorphism.
keypusher 13y ago
Does anyone have experience with Go as REST application server? I'm in prototyping phase (in Python) of something that is basically going to be a big REST API frontend with a lot of application logic and a db backend. I'm worried about scale as if this thing is going to take off it needs to scale big and support tens of thousands (or more) of requests a second. From the article it sounds like Go would be a great choice, I found the "gorest" framework and it looks decent, but I'm wondering if anyone has experience in this area? Specifically the DB interfacing, JSON marshalling, and writing lots of classes with complex application logic parts.
- danenania 13y ago
  I just put a small go learning project up on github. https://github.com/danenania/go-promocodes https://github.com/danenania/go-promocodes It's a tiny rest api for generating promo codes to bypass in app purchase locks in an ios app. It uses gorilla/mux[1] for routing, mongodb with mgo[2], and is heroku-ready[3]. One file and 129 lines all told. Perhaps it can help. 1: http://www.gorillatoolkit.org/pkg/mux http://www.gorillatoolkit.org/pkg/mux 2: http://labix.org/mgo http://labix.org/mgo 3: http://mmcgrana.github.io/2012/09/getting-started-with-go-on-heroku.html http://mmcgrana.github.io/2012/09/getting-started-with-go-on...
- dmishe 13y ago
  Adding to that, I have a large django project and I would love to use go for api, but how to deal with all the model code written in python?
- TheBiv 13y ago
  "I'm worried about scale as if this thing is going to take off it needs to scale big..." Please don't say this. If you are being paid by someone else, please check with them to ensure what their priorities are when things "scale big" bc often times you can bide yourself time if you have their requirements met while you scramble to make everything perfect on the backend. If you are not being paid by someone else or this is a side project, then please do not try and solve this question now. Answers to questions of "scale" are so broad that you will drive yourself mad trying to find the "perfect" tool, when one doesn't exist. You don't scale a language or a framework, you scale application logic. Scaling to millions of requests is the best possible problem to have, but put yourself in a position to have that problem! And asking basic questions of how to build something that can handle some amount of load in a language that you are not familiar with will FAR outweigh the perceived benefits of choosing that language/framework!
askimto 13y ago
Why not Go? Mandatory GC.
- nathany 13y ago
  I suppose if you're writing a Triple-A video game or real-time/firmware? (neither of which are "server") Outside of those cases, Rob Pike has given some discussion on interior pointers and how it's possible to limit the amount of garbage generated: http://talks.golang.org/2012/splash.article#TOC_14 http://talks.golang.org/2012/splash.article#TOC_14. (along with the usual techniques, like object pools, used with good success in JavaScript and Android games).
- kaib 13y ago
  This is incorrect. I've written a bunch of ARM firmware in Go and I've seen server applications that use custom allocators for allocation sensitive code.
  - pcwalton 13y ago
    Quoting Ian Lance Taylor: "Ultimately, though, it sounds like you want a language which has no garbage collection, and Go is not that language. Language constructs will allocate memory in ways that are not immediately obvious, so there is no reasonable way for a Go program to completely manage its own memory." https://groups.google.com/d/msg/golang-nuts/LoJJ1bICduA/AQFtD8_VI0sJ https://groups.google.com/d/msg/golang-nuts/LoJJ1bICduA/AQFt... Of course you can write memory pools and free lists—you can write them in any language—but, like other languages, the GC will still trace them during mark time and there is no safety provided by the language if you return an object to the pool that's still in use, or leak objects by forgetting to reuse them, and so on. The fact is that programming in Go, for all practical purposes, requires using a garbage collector.
    - kaib 13y ago
      When you manually allocate memory you are naturally responsible for the lifecycle of that memory. In Go you allocate such memory outside the GC to avoid tracing.
zyb09 13y ago
Do people really want to roll their own Webservers in Go? That's like a lot of work and sounds like disasters waiting to be happening. Sure it has potential, but I'll wait till something mature comes along and then use that. In mean time if you want to get of Ruby, I'd use something proven and fast like Java. There's really nothing wrong with Tomcats.
- agentS 13y ago
  I guess you could roll your own... or use the one from the standard library: http://golang.org/pkg/net/http/#ListenAndServe http://golang.org/pkg/net/http/#ListenAndServe
  - enneff 13y ago
    Incidentally, the same stack that powers dl.google.com.
- deleted 13y ago
  [deleted]
- mvzink 13y ago
  Having written a few web servers (and other servers) in Go, I assure you that you will be surprised how little work it is. However, I think where Go will shine is in highly customizable "frameworks"—not in the vein of Rails etc. at all but rather collections of components you can piece together for your own needs. You can already see how this will look with the net/http library and its Handlers: just about as easy and clear as hooking in Rack or WSGI middleware/apps, but with the safety and holy-mother-of-job speed that you just don't see in Ruby or Python (okay, the speed isn't that big a deal unless you've only been exposed to Ruby...) and without Java's startup times.
  - threeseed 13y ago
    Who cares about startup times for a web server ? And with JRebel, Play or Grails you have no startup time anyway. You just hot swap the code in the JVM.
realrocker 13y ago
Go is the oncoming storm. Been writing in Go for an year now. My dev config: API server + AngularJS. Before Go, I had never done serious web development(Android Developer), so I don't know the difference, but when I see fellow developers talking about concurrency and API's with respect and awe, I giggle inside a little. Previously I have also done GUI programming with Python, and the freedom from: not worrying about indentation, slow speed and default sync behavior is relieving. Talking about verbosity is a bit dodgy since it also depends on the skills of the programmer. But, at-least in my case, I think my Go code is less verbose then I would have written in Python. One of the main reasons for that is the highly accessible type system.
- orangethirty 13y ago
  Yes, it somehow manages to be less verbose than Python, while still being very readable. Sure, you do leave something on the table, but its a fair trade.
  - benhoyt 13y ago
    Less verbose than Python -- interesting (not that Python is "verbose"!). I've always heard Go was almost as concise as Python, but not quite. Can you give a couple of multi-line Go code examples that are more concise than the equivalent Python?
    - nathany 13y ago
      I found the ability to define a method on a slice/array to be less verbose than the equivalent inherit/delegation setup in Ruby, though I can't speak for Python. http://nathany.com/good http://nathany.com/good I can't imagine a more concise syntax for automatic delegation than Go's embedding.
  - coldtea 13y ago
    It's not by any means "less verbose than Python". Can you write any program in Go that cannot be written in less lines (often half) in Python?
matiasb 13y ago
I've been experimenting with it these weeks. The "Learning Go" is an interesting book: http://www.miek.nl/projects/learninggo/ http://www.miek.nl/projects/learninggo/ Also the number of projects is increasing: http://code.google.com/p/go-wiki/wiki/Projects#Linguistics http://code.google.com/p/go-wiki/wiki/Projects#Linguistics I'm looking for cool Go projects out there, so share your github stuff!
haberman 13y ago
> Go is closer in spirit to C than to any other language This is certainly not the case for the way that I personally think about C. Perhaps there are two "spirits" of C; two ways that people think about it: 1. C is small, C is simple, C lets you write useful programs with good performance while keeping the language itself simple. For this view of C, I can see Go being a compelling alternative. 2. C is a bare-metal environment for implementing low-level systems code like VMs, garbage collectors, JITs, and other runtimes. It imposes nothing and never gets in your way. For this view of C (which is how I think of it), Go is not an alternative. If you are inclined to disagree, answer for me: why is the Go runtime and GC not itself written in Go? I think that perhaps the difference between these two views of C leads to some of the disagreement about whether Go is an alternative for C.
- jbarham 13y ago
  > why is the Go runtime and GC not itself written in Go? In a word: bootstrapping. It's a FAQ: http://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers http://golang.org/doc/faq#What_compiler_technology_is_used_t...
  - pcwalton 13y ago
    I don't see how to easily implement a garbage collector in a language that doesn't let you precisely control garbage collected allocations (i.e. making all GC allocations immediately apparent and visible, instead of using escape analysis), for the same heap you're allocating into. You'd have to reason very carefully about the colors of your objects in order to ensure correctness in the presence of allocating into the same heap you're in the process of marking or sweeping or copying. (This is not the same problem as incremental collection—with incremental collection you can count on barriers to handle it for you.) I wouldn't be surprised if it's doable with some really clever tricks, but it doesn't seem worth it in terms of maintainability. Just use C or C++.
    - tikhonj 13y ago
      Or, one day, Rust :P. Or does Rust's optional GC get in the way? I'm not really familiar with that part of the language.
ternaryoperator 13y ago
Odd to see a reference to Asana as the way to go in an article on Go. Asana is primarily written in Java.
- nathany 13y ago
  The tech link for Asana talks about JavaScript (V8cgi) and Erlang. Trello is primarily Node.js.
6ren 13y ago
Theory: when a language is often hyped, it means few are adopting it. Consider: lisp. In contrast: PHP, objective-C. I'll be interested in checking back in 5 years, to see what happened. But I admit, fast startup times and coroutines are big wins. Also, multicore is late. Dual-core x86 in 2004, and in 2013 we are still on quad-core. With a doubling every two years, we'd be at 32 cores. Instead, today's trend is toward the less powerful ARM. We do have "multicore" in GPUs (1000's). I've long thought that processor evolution will be similar to organs in a body or firms in a market-place, i.e. with special-purpose silicon, like video decoders etc. Which is what we have with SoC.
- MetaCosm 13y ago
  Umm... My cheap linode vm toy box has 8 cores. Intel's higher tier server chips run 20 threads per chip (across 10 cores). Heck, even a dirt cheap Dell 1U with 2x X5670 has 24 threads going.
  - 6ren 13y ago
    Yeah, the limitation isn't hardware, but utilisation thereof. Maybe Go will change that; but I don't see it touting concurrent code as becoming trivial - just easier. (maybe I'm wrong?) Server loads are typically embarrassingly parallelizable, e.g. serving concurrent web requests. I mean, consider, are you maxing out all 8 cores? Multicore utilisation is hard, in general. So desktop cpus pretty much stalled at quad-core (I expect ARM chips are doing likewise as we speak).
    - MetaCosm 13y ago
      Concurrency with messaging is rather trivial, because it does away with the vast majority of the hard parts (but not all of them). Go is easy in that regard for the same reasons Erlang is easy .
      - 6ren 13y ago
        I looked into Erlang in some depth, and found its concurrency ability was due to shared-nothing modules (which smalltalk also has), which I think you refer to with "messaging". Race conditions can still occur, which I guess you include with "not all of them". Plus, in Erlang this was found to not address all concurrency problems, and so a software transactional database is included as standard. Looking at the details, I don't think general concurrency is a solved problem. Looking at the results, if it was, we'd have much better utilisation of multi-core architectures by now than we do. For example, 32 core x86, clocked ultra-low, for extraordinarily low power consumption. Actually, another issue is that message passing might work better with cores with their own RAM, so the modules can work independently. I think there's a huge amount of kool-aid around concurrency "solutions" - functional programming, erlang, and now Go. Because concurrency is so valuable, if Go really does make it trivial, we it should quickly dominate all other languages. But it seems to me that concurrency is still a hard problem.
blowski 13y ago
> When I look at Ruby, I see C++11 in different clothes. Twenty years of cruft, and still adding features that nobody needs. A new language is a fresh start. That's not necessarily a good thing. Those '20 years of cruft' represent battle-hardened code. Those features have been requested - maybe not by you, but communities the size of Ruby, PHP, Python don't do these things on a whim.
- nathany 13y ago
  Yes, Ruby/Python have strong ecosystems from their 20+ years of existence. Go's third-party packages are still young by comparison. But sometimes it's good to rethink past assumptions, even if it means writing code from scratch. The feature linked is Ruby refinements, for which much of the community was against. And note, I did not say refinements weren't wanted, clearly they were wanted by someone. I said they aren't needed.
davidw 13y ago
I think that sooner or later, it may get enough of what makes Erlang great to be a replacement, but IIRC, it's not quite there yet. All the process monitoring and management stuff... See previous discussion(s): https://news.ycombinator.com/item?id=5451916 https://news.ycombinator.com/item?id=5451916 https://www.hnsearch.com/search#request/all&q=Erlang+Go https://www.hnsearch.com/search#request/all&q=Erlang+Go
broxlone 13y ago
Why should I go or not?
- keypusher 13y ago
  Should you stay or should you go?
swah 13y ago
How are you communicating with Go in a SOA? I think Python/Ruby frontends and Go backends would be a good match, if Thrift/ZeroMQ/Redis/HTTP/whatever bridges work well.
Roboprog 13y ago
Because I like to be able to use function pointers, as well as just interfaces :-) Because sometimes I like just smashing the "leading" values into a structure, rather than having to write a constructor (or worse, NOT writing a constructor and having to set, set, set my "bean" to make it useful) It's almost as much fun as TurboP^H^H^H^H^H^H ANSI C.
p0nce 13y ago
> And we have gophers! What could be more fun than that? The funnier thing will be when the hype disappear as fast as it came.

162 points by nathany 13y ago

I agree with everything except Go is fun or the assertion that it combines best of both dynamic and statically compiled languages. It is a minimalistic get-it-done language, I would say it is 'modern java'. There are no aha moments that you experience while learning go. It always feels like - ya, I have seen that. Go did not take the best of the pre-existing languages, it took the minimal set that made sense to the designers; for example: it omitted 'best' features like map, reduce and filter in favour of 'plain old boring' for loops. I wonder how many programmers can wake up in the morning and say to themselves - wow, I am going to program in Go today.

nathany 13y ago
Thanks for reading my article. It is my opinion that Go is fun, but it's just that, an opinion. I'm glad we have the diversity in programming languages that allows us to pick what we like (esp. when it comes to the server). Best.
jff 13y ago
If you don't think Go is fun, you've never made a channel of channels of functions.
danenania 13y ago
Go's aha moment is its low cognitive overhead. It eschews power and conciseness for clarity, everywhere. It takes the exact opposite approach to functional languages, preferring boring simplicity to powerful but cryptic abstraction. It turns out that an uncompromising devotion to clarity is quite powerful in its own right. It's not right for every use case, but highly compelling for many.
- danieldk 13y ago
  Go's aha moment is its low cognitive overhead. I think some of us already had that with the first Java versions. Actually, Go looks a lot like old Java versions, minus the VM, plus Goroutines/channels, and static duck typing. I have written a fair share of Go code and ultimately it's a very boring, but predictable language. If it builds a larger ecosystem, it will not be much different than a Java that compiles to native code. Without some of the advantages of the JVM. (What we are really seeing here on HN lately is a hype, pretty much like node.js and FP before. Go has a better chance to stick, because it has a good steward.)
  - irrelative 13y ago
    Honest question: what do you consider the advantages of the JVM over native code?
    - hellrich 13y ago
      "Write once, run anywhere"
      - qu4z-2 13y ago
        I've heard this far more commonly from Java programmers as "Write once, debug everywhere", but maybe that's changed. (this was quite some time ago)
    - threeseed 13y ago
      Definitely deployment flexibility. Write on OSX, Test on Linux, Run on Solaris. But also performance. JVM can be faster than say C/C++ code in many cases.
    - danieldk 13y ago
      - "Write once, run everywhere." as the sibling poster mentions. I can build on my Mac, deploy on whatever the server platform is. Snapshot and release builds of our build server are distributed via a Nexus-managed repository. So, everyone codes against exactly the same dependencies, regardless of the platform. - Hotswapping/JRebel. - Good interoperability with other languages. E.g. the Typesafe folks implemented Akka in Scala. Java gets it for (well, almost) free. - Easy monitoring and instrumentation. Obviously, there are downsides as well, such as startup times (twofold: starting the VM and Hotspot detection/compilation), preset heap size, expensive JNI (native interface), etc.
      - dualogy 13y ago
        > Write once, run everywhere Well, so Go is "write once, build 3-9x, run anywhere".. close enough ;)
- tikhonj 13y ago
  You're mistaking familiarity for simplicity. You cannot get much simpler than the lambda calculus, full stop. It has three concepts--lambdas, variables and application--and one evaluation rule. That is all. The rest of the language features are almost always just a thin layer over this. Even when you add types, it's still an amazingly simple model. And the types do not generally affect the runtime behavior of code at all. Functional languages are the very picture of something simple but not necessarily easy. Go, at least for you, is the opposite: it's easy because it's similar to what you're used to, but it also has quite a bit of surface area. My impression is that Go vies for simplicity of implementation over simplicity of semantics. It is a very operational sort of language. Its goal is to make the how clear--the code reflects what it does. Languages like Haskell, on the other hand, are completely the opposite. Haskell values simplicity of semantics over simplicity of implementation. It is a very denotational sort of language. Its goal is to make the what clear--the code reflects what it means. It's a difference in philosophies, certainly, just not quite in the way you construed it to be.
  - cgag 13y ago
    Great relevant talk: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
  - raganwald 13y ago
    Yes! Exceedingly simple semantics combining to form a difficult-to-use language is often called a "Turing Tar Pit," a place where everything is possible but nothing of interest is easy. Conway's Game of Life is even simpler than the lambda calculus, and people build all sorts of amazing things in it, but examples like a calculator that outputs human-readable digits are circus tricks.
    - papsosouid 13y ago
      >Exceedingly simple semantics combining to form a difficult-to-use language Who was suggesting that we should form difficult to use languages on those simple semantics?
- pjmlp 13y ago
  > Go's aha moment is its low cognitive overhead. Very good for replaceable programmers, the dream of every manager. :)
  - delian66 13y ago
    Low cognitive overhead is also good for your future self, that will have to maintain the 'clever' mess which you wrote in a hurry ... In my experience so far, the abstractions that Go offers for writing concurrent code are very nice and easy to understand, and deploying it is really good - it generates static binaries, which you simply upload where you need them. It is a very practical language.
  - myg204 13y ago
    Simplicity in design is still a panacea, only good programmers can do it on non trivial systems. Go will allow for better clarity, but beautiful code will not write itself.
- coldtea 13y ago
  >Go's aha moment is its low cognitive overhead. You mean its strength is that is a Blub language? Because the "low cognitive overhead" is exactly what Java was touted for, back in the day (before the EE madness).
  - danenania 13y ago
    It may make the blubs more effective, but that doesn't necessarily mean it can't also make the geniuses more effective too.
    - Roboprog 13y ago
      "Blub" refers to the language itself, rather than the developers. As in "think (no deeper than) in Blub (language concepts)" I can see both sides of the "clever is better/worse" argument, though. E.g. - C++ operator overloading is powerful and harmful.
- MetaCosm 13y ago
  Go's aha moment IMHO is at the edges. If you have built a complex application (250k+ lines) in C++, Python or Java you know about the quiet undignified pains those projects often suffer. - Horrible build systems (and horrible build times) --- Go compiles fast, and the compile and dependency system is baked in - Impossible to untangle dependencies (don't ever remove an include, who knows where it is used) --- Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up - Nightmare deploys (system wide assumptions) --- Go deploys with a single platform dependent binary, it is absolutely awesome - Inconsistent formatting, self-directed standards on formatting. --- Gofmt is the one true format, heck, even some bad formatting won't compile (try to uncuddle your else to see) - Inconsistent build systems and build system quality, made worse by using libraries and systems that have their OWN build systems. --- Go get combined with its include system (use it or lose it) really let you tie together systems in a sane way without any custom build routes. - Dealing with modern concurrency --- Go having built in channel communication makes many problems trivial, and allows new methods of abstraction (goes to Go's model of composition).
  - danieldk 13y ago
    I'll take Java as an example, since I only use Python for short scripts. - Horrible build systems (and horrible build times) Maven is a great build system, Java has good compile times, and most modern Java IDEs have incremental compilation. And you can specify versions of dependencies, rather than having to maintain a list of SHA1 hashes of versions considered to be stable. (don't ever remove an include, who knows where it is used) This is primarily a problem in C/C++, where one can indirectly get the correct dependencies by accident. Most modern compiled languages don't have this problem. Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up Which can be annoying for debugging. I'd rather have my IDE or linter give warnings. - Nightmare deploys (system wide assumptions) 'mvn package', it's also easy to configure maven to build an archive with dependencies, configuration files, or whatever you'd like to be in a deploy. In fact, deployments are even easier than in Go, since my package built on OS X will also deploy on a Linux server. My colleagues use different platforms (a mixture of Linux, Windows, and OS X) and it's never a problem. - Inconsistent formatting, self-directed standards on formatting. It's good that the Go team made a standard formatting. That said, my employer has a default layout. It's a matter of importing an XML file in Eclipse or IntelliJ and everything is in company layout (yay). - Inconsistent build systems and build system quality Nearly every Java library is available via Central Maven Repository. Including versioning :), meaning that if upstream changes their API, it's not your problem. In contrast to Go repository/packages. Dealing with modern concurrency Ever heard of Actor models and Akka? Composable concurrency, across more than one machine. With supervision, routing, etc.
- papsosouid 13y ago
  >It takes the exact opposite approach to functional languages, preferring boring simplicity to powerful but cryptic abstraction. Yes, functional programming is based on the idea that abstractions should be cryptic. That's a very reasonable observation, and not at all ignorant.
orangethirty 13y ago
I do look forward to programming in Go. My day gig is working with PHP and horribly written Python (globals everywhere). Go is, simply put, refreshing. So much, that I'm moving away from Python as my go to web language to Go.
gravitronic 13y ago
Spoken like someone who hasn't written much Go, or at least hasn't used it for what it's best at. I suggest you read Effective Go and try writing some concurrent applications. It's aha moments are plentiful once you realize the power in the simplicity.
- pjmlp 13y ago
  I have written Go code, and what the language offers is no different from java.util.concurrent, .NET TPL, C++ Cilk, PPL, and many other frameworks offer.
  - jesstaa 13y ago
    Goroutines aren't really the selling point. It's simple enough to implement similar concepts in any language. It's the combination of a set of complimentary features, the maturity and the stability that really sells Go.
    - swah 13y ago
      They might be for programmers who don't have threads. Maybe that explains why its so popular with Python/Ruby/PHP folks?
    - gnaritas 13y ago
      You can't call Go mature.
mseebach 13y ago
> it omitted 'best' features like map, reduce and filter in favour of 'plain old boring' for loops Well, it included closures, so luckily it's trivial to add those after the fact.
- danieldk 13y ago
  Yeah, per type or with interface{}, where every function has to do run-time introspection. Maybe trivial, but not lots of fun.
DennisP 13y ago
Go has first-class functions, so if you want map/reduce/filter there's nothing stopping you.
- quatrevingts 13y ago
  Except that you lose type safety (or write an implementation for every permutation of types..)
  - DennisP 13y ago
    Didn't realize that, thanks.
- papsosouid 13y ago
  Go doesn't have parametric polymorphism. So yeah, there is something stopping you.
  - voidlogic 13y ago
    Nope, not stopping you: http://blog.burntsushi.net/type-parametric-functions-golang http://blog.burntsushi.net/type-parametric-functions-golang
    - papsosouid 13y ago
      Yes, stopping me. "You can resort to a horrible ugly cludge and lose type safety for your efforts" is not having parametric polymorphism.

keypusher 13y ago

Does anyone have experience with Go as REST application server? I'm in prototyping phase (in Python) of something that is basically going to be a big REST API frontend with a lot of application logic and a db backend. I'm worried about scale as if this thing is going to take off it needs to scale big and support tens of thousands (or more) of requests a second. From the article it sounds like Go would be a great choice, I found the "gorest" framework and it looks decent, but I'm wondering if anyone has experience in this area? Specifically the DB interfacing, JSON marshalling, and writing lots of classes with complex application logic parts.

danenania 13y ago
I just put a small go learning project up on github. https://github.com/danenania/go-promocodes https://github.com/danenania/go-promocodes It's a tiny rest api for generating promo codes to bypass in app purchase locks in an ios app. It uses gorilla/mux[1] for routing, mongodb with mgo[2], and is heroku-ready[3]. One file and 129 lines all told. Perhaps it can help. 1: http://www.gorillatoolkit.org/pkg/mux http://www.gorillatoolkit.org/pkg/mux 2: http://labix.org/mgo http://labix.org/mgo 3: http://mmcgrana.github.io/2012/09/getting-started-with-go-on-heroku.html http://mmcgrana.github.io/2012/09/getting-started-with-go-on...
dmishe 13y ago
Adding to that, I have a large django project and I would love to use go for api, but how to deal with all the model code written in python?
TheBiv 13y ago
"I'm worried about scale as if this thing is going to take off it needs to scale big..." Please don't say this. If you are being paid by someone else, please check with them to ensure what their priorities are when things "scale big" bc often times you can bide yourself time if you have their requirements met while you scramble to make everything perfect on the backend. If you are not being paid by someone else or this is a side project, then please do not try and solve this question now. Answers to questions of "scale" are so broad that you will drive yourself mad trying to find the "perfect" tool, when one doesn't exist. You don't scale a language or a framework, you scale application logic. Scaling to millions of requests is the best possible problem to have, but put yourself in a position to have that problem! And asking basic questions of how to build something that can handle some amount of load in a language that you are not familiar with will FAR outweigh the perceived benefits of choosing that language/framework!

askimto 13y ago

Why not Go? Mandatory GC.

nathany 13y ago
I suppose if you're writing a Triple-A video game or real-time/firmware? (neither of which are "server") Outside of those cases, Rob Pike has given some discussion on interior pointers and how it's possible to limit the amount of garbage generated: http://talks.golang.org/2012/splash.article#TOC_14 http://talks.golang.org/2012/splash.article#TOC_14. (along with the usual techniques, like object pools, used with good success in JavaScript and Android games).
kaib 13y ago
This is incorrect. I've written a bunch of ARM firmware in Go and I've seen server applications that use custom allocators for allocation sensitive code.
- pcwalton 13y ago
  Quoting Ian Lance Taylor: "Ultimately, though, it sounds like you want a language which has no garbage collection, and Go is not that language. Language constructs will allocate memory in ways that are not immediately obvious, so there is no reasonable way for a Go program to completely manage its own memory." https://groups.google.com/d/msg/golang-nuts/LoJJ1bICduA/AQFtD8_VI0sJ https://groups.google.com/d/msg/golang-nuts/LoJJ1bICduA/AQFt... Of course you can write memory pools and free lists—you can write them in any language—but, like other languages, the GC will still trace them during mark time and there is no safety provided by the language if you return an object to the pool that's still in use, or leak objects by forgetting to reuse them, and so on. The fact is that programming in Go, for all practical purposes, requires using a garbage collector.
  - kaib 13y ago
    When you manually allocate memory you are naturally responsible for the lifecycle of that memory. In Go you allocate such memory outside the GC to avoid tracing.

zyb09 13y ago

Do people really want to roll their own Webservers in Go? That's like a lot of work and sounds like disasters waiting to be happening. Sure it has potential, but I'll wait till something mature comes along and then use that. In mean time if you want to get of Ruby, I'd use something proven and fast like Java. There's really nothing wrong with Tomcats.

agentS 13y ago
I guess you could roll your own... or use the one from the standard library: http://golang.org/pkg/net/http/#ListenAndServe http://golang.org/pkg/net/http/#ListenAndServe
- enneff 13y ago
  Incidentally, the same stack that powers dl.google.com.
deleted 13y ago
[deleted]
mvzink 13y ago
Having written a few web servers (and other servers) in Go, I assure you that you will be surprised how little work it is. However, I think where Go will shine is in highly customizable "frameworks"—not in the vein of Rails etc. at all but rather collections of components you can piece together for your own needs. You can already see how this will look with the net/http library and its Handlers: just about as easy and clear as hooking in Rack or WSGI middleware/apps, but with the safety and holy-mother-of-job speed that you just don't see in Ruby or Python (okay, the speed isn't that big a deal unless you've only been exposed to Ruby...) and without Java's startup times.
- threeseed 13y ago
  Who cares about startup times for a web server ? And with JRebel, Play or Grails you have no startup time anyway. You just hot swap the code in the JVM.

realrocker 13y ago

Go is the oncoming storm. Been writing in Go for an year now. My dev config: API server + AngularJS. Before Go, I had never done serious web development(Android Developer), so I don't know the difference, but when I see fellow developers talking about concurrency and API's with respect and awe, I giggle inside a little. Previously I have also done GUI programming with Python, and the freedom from: not worrying about indentation, slow speed and default sync behavior is relieving. Talking about verbosity is a bit dodgy since it also depends on the skills of the programmer. But, at-least in my case, I think my Go code is less verbose then I would have written in Python. One of the main reasons for that is the highly accessible type system.

orangethirty 13y ago
Yes, it somehow manages to be less verbose than Python, while still being very readable. Sure, you do leave something on the table, but its a fair trade.
- benhoyt 13y ago
  Less verbose than Python -- interesting (not that Python is "verbose"!). I've always heard Go was almost as concise as Python, but not quite. Can you give a couple of multi-line Go code examples that are more concise than the equivalent Python?
  - nathany 13y ago
    I found the ability to define a method on a slice/array to be less verbose than the equivalent inherit/delegation setup in Ruby, though I can't speak for Python. http://nathany.com/good http://nathany.com/good I can't imagine a more concise syntax for automatic delegation than Go's embedding.
- coldtea 13y ago
  It's not by any means "less verbose than Python". Can you write any program in Go that cannot be written in less lines (often half) in Python?

matiasb 13y ago

I've been experimenting with it these weeks. The "Learning Go" is an interesting book: http://www.miek.nl/projects/learninggo/ http://www.miek.nl/projects/learninggo/ Also the number of projects is increasing: http://code.google.com/p/go-wiki/wiki/Projects#Linguistics http://code.google.com/p/go-wiki/wiki/Projects#Linguistics I'm looking for cool Go projects out there, so share your github stuff!

haberman 13y ago

> Go is closer in spirit to C than to any other language This is certainly not the case for the way that I personally think about C. Perhaps there are two "spirits" of C; two ways that people think about it: 1. C is small, C is simple, C lets you write useful programs with good performance while keeping the language itself simple. For this view of C, I can see Go being a compelling alternative. 2. C is a bare-metal environment for implementing low-level systems code like VMs, garbage collectors, JITs, and other runtimes. It imposes nothing and never gets in your way. For this view of C (which is how I think of it), Go is not an alternative. If you are inclined to disagree, answer for me: why is the Go runtime and GC not itself written in Go? I think that perhaps the difference between these two views of C leads to some of the disagreement about whether Go is an alternative for C.

jbarham 13y ago
> why is the Go runtime and GC not itself written in Go? In a word: bootstrapping. It's a FAQ: http://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers http://golang.org/doc/faq#What_compiler_technology_is_used_t...
- pcwalton 13y ago
  I don't see how to easily implement a garbage collector in a language that doesn't let you precisely control garbage collected allocations (i.e. making all GC allocations immediately apparent and visible, instead of using escape analysis), for the same heap you're allocating into. You'd have to reason very carefully about the colors of your objects in order to ensure correctness in the presence of allocating into the same heap you're in the process of marking or sweeping or copying. (This is not the same problem as incremental collection—with incremental collection you can count on barriers to handle it for you.) I wouldn't be surprised if it's doable with some really clever tricks, but it doesn't seem worth it in terms of maintainability. Just use C or C++.
  - tikhonj 13y ago
    Or, one day, Rust :P. Or does Rust's optional GC get in the way? I'm not really familiar with that part of the language.

ternaryoperator 13y ago

Odd to see a reference to Asana as the way to go in an article on Go. Asana is primarily written in Java.

nathany 13y ago
The tech link for Asana talks about JavaScript (V8cgi) and Erlang. Trello is primarily Node.js.

6ren 13y ago

Theory: when a language is often hyped, it means few are adopting it. Consider: lisp. In contrast: PHP, objective-C. I'll be interested in checking back in 5 years, to see what happened. But I admit, fast startup times and coroutines are big wins. Also, multicore is late. Dual-core x86 in 2004, and in 2013 we are still on quad-core. With a doubling every two years, we'd be at 32 cores. Instead, today's trend is toward the less powerful ARM. We do have "multicore" in GPUs (1000's). I've long thought that processor evolution will be similar to organs in a body or firms in a market-place, i.e. with special-purpose silicon, like video decoders etc. Which is what we have with SoC.

MetaCosm 13y ago
Umm... My cheap linode vm toy box has 8 cores. Intel's higher tier server chips run 20 threads per chip (across 10 cores). Heck, even a dirt cheap Dell 1U with 2x X5670 has 24 threads going.
- 6ren 13y ago
  Yeah, the limitation isn't hardware, but utilisation thereof. Maybe Go will change that; but I don't see it touting concurrent code as becoming trivial - just easier. (maybe I'm wrong?) Server loads are typically embarrassingly parallelizable, e.g. serving concurrent web requests. I mean, consider, are you maxing out all 8 cores? Multicore utilisation is hard, in general. So desktop cpus pretty much stalled at quad-core (I expect ARM chips are doing likewise as we speak).
  - MetaCosm 13y ago
    Concurrency with messaging is rather trivial, because it does away with the vast majority of the hard parts (but not all of them). Go is easy in that regard for the same reasons Erlang is easy .
    - 6ren 13y ago
      I looked into Erlang in some depth, and found its concurrency ability was due to shared-nothing modules (which smalltalk also has), which I think you refer to with "messaging". Race conditions can still occur, which I guess you include with "not all of them". Plus, in Erlang this was found to not address all concurrency problems, and so a software transactional database is included as standard. Looking at the details, I don't think general concurrency is a solved problem. Looking at the results, if it was, we'd have much better utilisation of multi-core architectures by now than we do. For example, 32 core x86, clocked ultra-low, for extraordinarily low power consumption. Actually, another issue is that message passing might work better with cores with their own RAM, so the modules can work independently. I think there's a huge amount of kool-aid around concurrency "solutions" - functional programming, erlang, and now Go. Because concurrency is so valuable, if Go really does make it trivial, we it should quickly dominate all other languages. But it seems to me that concurrency is still a hard problem.

blowski 13y ago

> When I look at Ruby, I see C++11 in different clothes. Twenty years of cruft, and still adding features that nobody needs. A new language is a fresh start. That's not necessarily a good thing. Those '20 years of cruft' represent battle-hardened code. Those features have been requested - maybe not by you, but communities the size of Ruby, PHP, Python don't do these things on a whim.

nathany 13y ago
Yes, Ruby/Python have strong ecosystems from their 20+ years of existence. Go's third-party packages are still young by comparison. But sometimes it's good to rethink past assumptions, even if it means writing code from scratch. The feature linked is Ruby refinements, for which much of the community was against. And note, I did not say refinements weren't wanted, clearly they were wanted by someone. I said they aren't needed.

davidw 13y ago

I think that sooner or later, it may get enough of what makes Erlang great to be a replacement, but IIRC, it's not quite there yet. All the process monitoring and management stuff... See previous discussion(s): https://news.ycombinator.com/item?id=5451916 https://news.ycombinator.com/item?id=5451916 https://www.hnsearch.com/search#request/all&q=Erlang+Go https://www.hnsearch.com/search#request/all&q=Erlang+Go

broxlone 13y ago

Why should I go or not?

keypusher 13y ago
Should you stay or should you go?

swah 13y ago

How are you communicating with Go in a SOA? I think Python/Ruby frontends and Go backends would be a good match, if Thrift/ZeroMQ/Redis/HTTP/whatever bridges work well.

Roboprog 13y ago

Because I like to be able to use function pointers, as well as just interfaces :-) Because sometimes I like just smashing the "leading" values into a structure, rather than having to write a constructor (or worse, NOT writing a constructor and having to set, set, set my "bean" to make it useful) It's almost as much fun as TurboP^H^H^H^H^H^H ANSI C.

p0nce 13y ago

> And we have gophers! What could be more fun than that? The funnier thing will be when the hype disappear as fast as it came.