10 ms·

Writing Web Applications in Go

72 points by gits1225 14y ago

photon137 14y ago
I've often wondered about using Go as an architectural choice - it's near-native fast, the syntax and semantics are good, it's GC'ed and runs on Linux (edit: my language of choice is C# - and Go is the only one that comes close to it _and_ runs on Linux, IMO - any others out there?- performance is critical). However, if I decide to go with Go as a framework choice, is there an active market of Go developers out there from which one can hire?
- wging 14y ago
  It seems so easy to pick up that I wonder whether it's wise to restrict hiring to those who are 'Go developers'.
  - photon137 14y ago
    That's also true. But having the ability to hire people who can hit the ground running with production code is an advantage.
- gits1225 14y ago
  I think, the best time to find hackers would be before killer applications[1] written in that specific programming language starts to appear. After that, time will pave way to The Go paradox[2]. The best places to find these people would be golang-nuts mailing list, /r/golang, #go-nuts irc etc. [1] https://en.wikipedia.org/wiki/Killer_app https://en.wikipedia.org/wiki/Killer_app [2] http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
  - danieldk 14y ago
    After that, time will pave way to The Go paradox[2]. I am not sure. Most people who know the important low-level languages well, are not likely to be a fan of Go. Seasoned C++ hackers will miss templates dearly (no, interfaces are not a replacement for templates, they are a replacement for abstract base classes) and C/C++ programmers dislike the lack of control over memory management. If you are using C or C++ in 2012, you probably have good reasons and Go mostly sacrifices the advantages of C and C++. Someone who is familiar enough with Haskell, ML, or Scala, will dislike the fact that Go practically ignored (or rejected?) two or three decades of research an programming languages. From the perspective of PL research, Go is a weak language. In other words, the low-level and strong typing crowds are not that much interested in Go. If there is a new imperative language that does interest them, it is probably Rust. The question is, who does switch to Go? One would guess that these are mostly Python and Ruby programmers who have never written much C, C++, or Haskell, and are looking for something faster and compiled. Yes, this is a generalization, and there are plenty of exceptions. Not exactly the 'Python paradox', 'better than the rest', programmers. Following the Google+ community, discussions on HN, and to an extend the Go mailing lists, confirms those suspicions. There are lot of grandiose claims supporting Go (one of my personal pet peeves are people claiming that 'Go interfaces are like Haskell typeclasses'). But if you look at the language spec, there is not much interesting. Goroutines are nice, but they are just green threads. Channels have been done elsewhere. Go is just a very boring language (which isn't necessarily bad), pretty much like Java, without the good package management (no versioning), good IDEs, broad library support, or a performant garbage collector. Boring languages attract more mediocre programmers than great programmers. Edit: if you downvote, please, at least leave a comment ;).
    - 3pt14159 14y ago
      Easier concurrancy and better string management. Current c/c++ people already learned the common methods. Also, less ambiguous lines of code.
    - aninteger 14y ago
      I can't downvote but I'm using C/C++ in 2013 instead of Go simply because Go is not portable enough. There is currently no PowerPC port and that is still a requirement for me.
      - jff 14y ago
        gccgo might solve your problem, if you actually want the problem to be solved.
    - icey 14y ago
      Hi, mediocre programmer here! I would add a bullet point to the list of reasons I like go: "Boring to people who bring up Haskell in every programming conversation" ;) Seriously though, there are huge classes of problems in which the "interesting" part of the problem isn't the software that gets written but the business needs it solves. I am a fan of functional programming (I started the Clojure subreddit, and do a lot of "for fun" programming in it), but I've never run across a problem at my business where I felt like I needed to crack open Okasaki's book, or thought "this would be easier with an applicative functor". Something I've enjoyed about learning Go is the open & accepting nature of the community; I don't think I've ever heard someone called "mediocre" because of other languages they use. I am happy to feel like I don't have to be an incredible programmer to read the source code of the language I use, or the libraries I pull into my projects. I just want to get shit done so I can work on the problems that I find interesting, and for lots of us, that's just not going to be yet another implementation of datalog.
    - burntsushi 14y ago
      > no, interfaces are not a replacement for templates, they are a replacement for abstract base classes Interfaces aren't a replacement for templates, but they aren't a replacement for abstract base classes either. Interfaces in Go provide polymorphism through structural sub-typing. My limited knowledge of abstract base classes says that these are very much not the same. > Someone who is familiar enough with Haskell, ML, or Scala, will dislike the fact that Go practically ignored (or rejected?) two or three decades of research an programming languages. From the perspective of PL research, Go is a weak language. I am a Haskell programmer, but that crowd is impossible to please unless you've provided every PL feature out of research in the last few decades. I've seen virtually no appreciation for simplicity of language design as an entire unit. > If there is a new imperative language that does interest them, it is probably Rust. Yes. I can't wait for Rust to get a bit more love in the documentation department. Pattern matching? Algebraic data types? Thread local storage? Type classes? Yes please! Where do I sign up? > The question is, who does switch to Go? One would guess that these are mostly Python and Ruby programmers who have never written much C, C++, or Haskell, and are looking for something faster and compiled. Yes, this is a generalization, and there are plenty of exceptions. Not exactly the 'Python paradox', 'better than the rest', programmers. In my experience, most Go programmers are in fact coming from Python and Ruby. The premise of the "Go" or "Python" paradox is that skilled programmers tend to be the first ones to adopt new languages. Then the less-skilled programmers follow when there is sufficient buzz. I think that if one accepts that premise, it is applicable for Go. > one of my personal pet peeves are people claiming that 'Go interfaces are like Haskell typeclasses' That is annoying, but completely understandable. They are deceptively similar on the surface. But I don't think this kind of confusion is unique to Go. You'll see it everywhere. You know what else people confuse? That Go interfaces are just like abstract base classes! :P > But if you look at the language spec, there is not much interesting. That's kind of the point. If you don't accept the overall simplicity of the design Go as a feature, then I can't blame you if you dismiss Go. If all you want to judge a language by is whether it includes cool and exciting new features, then Go will never be a good choice for you a priori. > Go is just a very boring language (which isn't necessarily bad), pretty much like Java, without the good package management (no versioning) I am utterly baffled. Go's approach to packaging is literally the best tool of its class that I've ever used. The Go tool militates toward convention rather than providing a dizzying array of features. This makes it strictly less powerful than other packaging tools, but god dammit, it makes it dead simple to install packages. You want to try my window manager, which is roughly 30,000 LOC (including my X libraries)? If you have Go installed: `go get github.com/BurntSushi/wingo`. That's it. You're done. I just ran it on my system, and it downloaded, compiled and installed my window manager---along with all of its dependencies---in less than 30 seconds. You might say---other build tools can do this! But do you know how many lines of configuration I had to write for any of this to work? None. I didn't specify dependencies. No strange command line flags. Nothing. The common case Just Works. > Goroutines are nice, but they are just green threads. Channels have been done elsewhere. This is a vast understatement. Just green threads? And please, tell me, what other mainstream language supports green threads? I know Haskell and Erlang do. Rust will (yay). Anything else? No? (I know Java doesn't, but I can't remember if this is a limitation of the JVM or if Scala or Clojure have green threads). Go does. That's a pretty big deal. Go makes a solid concurrent style of programming in a C-like language virtually free. Sure, everything is still mutable, but there are powerful idioms that---in my experience---militate against race conditions. It's not as good as Haskell/Erlang/Rust in the compile time safety department, but I'll be damned if it isn't loads easier than my other choices: C, C++, Java, Python, Ruby, Lua, blah blah. > Boring languages attract more mediocre programmers than great programmers. And close minded folk think they have all the answers. It's possible for people to enjoy using more than one tool. I'm a hacker, and I love good tools. Go is a great tool. So is Haskell. I hope that Rust will be.
- iamwil 14y ago
  You can look on the google groups, called go-nuts, and see how many devs are subscribed. I wouldn't worry about an active market of Go devs to hire. If a language is any good, it'll attract developers. If you're a programmer, you should try out the language to not only do things you can do in other languages (to see how it fares), but more importantly, "What are the new things I can do with Go that use to be hard, but are now easy?"
- icey 14y ago
  I've spent the past couple of months working with Go, coming from a mostly C# and Python background. One of the attractions to the language for me is that it's straightforward to pick up. Because there aren't a lot of "fancy" features in the language like Linq or list comprehensions, it's easy to dive into a block of code and figure out what's going on without requiring a lot of background knowledge. The language eschews some brevity in exchange for clarity, which gives me a lot of confidence that I can take a good developer from any background, give them a week and feel like they've got a decent chance of acquiring the knowledge they need to work with the language. The newness of the language means that there isn't a huge ecosystem of libraries available, BUT the standard lib is pretty damn great, and there are more and more people coming to the language every day. My favorite thing about go is it's overall sense of boringness - Go code seems very predictable. There's a culture of digging into the source throughout the community, and tools like go fmt & go vet ensure that most code looks similar. It'd be worth spending a week with it to write something useful to get a sense of whether or not you truly like it, but my experience has been very positive so far.
  - StavrosK 14y ago
    My problem with it is how frustrating it is to write when you're not very familiar with it, but I suspect that's more of a generic complaint about learning a new language rather than soecifically about Go. Every line I write, I go "argh, I wonder if this is the idiomatic way to do this" and I get frustrated a lot. I love the features, though, especially the concurrency ones. It was conceptually trivial to write a multicasting TCP proxy in it.
    - icey 14y ago
      I had the same problems when I first started learning the language, and while I'm certain I've got a lot more to learn I found that making a habit of reading lots of source code made a huge difference. After a little while you start thinking about "can this code be clearer? Are the intentions obvious?" and that makes the code much easier to write. Go is incredibly easy to refactor, so instead of worrying about being exactly right, you can focus on "is this easy to reason about?". My experience has been that this process will get you very close to idiomatic code on its own.
- krakensden 14y ago
  No love for Mono? My impression was that they're doing good work- they've finally turned on their generational GC, for instance.
humanspecies 14y ago
Go still hasn't found a niche to be useful to. Nobody's giving up 30 years of C for systems programming, nobody's going to use Go for web apps when higher level languages are clearly more practical, nobody will give up Haskell for scientific and massive parallel programming. All in all I think Go is an interesting experiment but it serves no purpose that I can use right now
- bromang 14y ago
  C/C++ is the language of choice for scientific and massively parallel programming. as far as I know Haskell is not really competitive in that area.
  - lutusp 14y ago
    > C/C++ is the language of choice ... Linus Torvalds would disagree that C and C++ are the same language as suggested by "C/C++" and by the singular pronoun that follows. http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus And maybe too much weight is given to Torvalds' views on this and other topics.
    - danieldk 14y ago
      Linus Torvalds would disagree that C and C++ are the same language as suggested by "C/C++" and by the singular pronoun that follows. One can easily program as if it were C, using templates to avoid ugly macro mess for generic algorithms and types. Edit: corrected is -> as.
      - lutusp 14y ago
        > One can easily program is if [sic] it were C, using templates to avoid ugly macro mess for generic algorithms and types. Did you mean "as if"? If so, that's exactly what Torvalds objects to -- the things about C++ that supposedly represent improvements over C. He goes on about how many of the conveniences of C++ -- like the STL -- aren't as wrung out as most people think and don't actually work as intended. I don't necessarily agree with his position in all respects, but some of the enhancements in C++, aren't actually enhancements.
sshillo 14y ago
If you need performance why not go with scala. The play framework is super easy to use. Anyone who is familiar with mvc will pick it up very fast. There is also Martin Odersky's course which is a great intro.
- lucian1900 14y ago
  Scala is extremely complex, rivaling C++. Its syntax in particular is just crazy. Which is a shame, since it's otherwise somewhat interesting. Haskell is a much better choice than Scala, as long as JVM isn't required.
  - GhotiFish 14y ago
    I'm sorry, but as I've tried to learn Haskell in 2 month sprints 4 separate times and failed, I can not in good conscience recommend Haskell, ever. I like the language allot, but even the programmers I believe are extremely talented just cannot learn it, let alone 99% of people I have to work with who simply can not even begin to make use of the language at it's most basic form. A professor I knew, who was easily one of the more decorated in my university, claimed he knew Haskell. I had used Haskell to parse biomedical data for my course on biometrics, as the data was inconsistent and full of errors, the correct design was to create a monadic structure. I consulted that professor, and he was flummoxed, just on the basic structure of the program (which was done in a basic top down style of declaring the types and breaking large functions into small ones). I fully accept my inability to use the language in a useful way may just be symptomatic of me being an idiot. I fully accept that my professors inability to understand the language in a any way may be symptomatic of him being an idiot. But as big a failure as I am at learning this language, I can't imagine the result of tasking someone who doesn't enjoy programming with maintaining Haskell. If scala is worse, then that's just horrifying.
    - josh-j 14y ago
      Just considering the language, then I think Scala is considerably easier to learn than haskell _if_ you're from an OO background. It's a multi-paradigm language making it easy to use it like a better c++11. However, idiomatic Scala is functional, and so you're pushed in another direction by the community (but, importantly, not forced). However, starting with a blank slate, then Haskell might be the easier language to learn. But if we consider the resources to learn the language along with the language, then I think Scala dominates Haskell. Haskell was painful for me to learn because to become proficient I had to trudge through not only books but wikis, blogs, and code. There is nothing like Odersky's Scala book in Haskell. Learn you a Haskell, the Haskell wikibook, and Real World Haskell are all _terrible_ at preparing someone to become a proficient haskeller because while they show you the language they don't train you to think functionally. In imperative languages you're giving a lot of sequential instructions to a robot. In functional languages you're programming the robot to understand a new language, and then you describe the way things ought to be in that language.
neya 14y ago
Why do people choose 'Go' over Scala? The latter is a 'better' choice (in my opinion) for web applications and add in the play framework, you've got an ultra-fast, scalable web app. running in minutes. I do admit that Scala has a steeper learning curve, but my guess is that it's worth it. Can anyone explain WHY Scala seems to be ignored by most of the programming community, especially here on HN, where everyone seems to be in favor of either Node.js or Go... ? Is there anyone who can provide some constructive negative feedback regarding Scala (apart from the learning curve) over GO?
- deleted 14y ago
  [deleted]
- meaty 14y ago
  Because it requires an entire JVM of baggage, is terribly complicated and doesn't really give any benefits over anything else. Its like a Swiss army knife with a million blunt obscure tools rather than 5 useful sharp ones, or a crazy girlfriend who has three violent ex husbands who keep coming round to your house and lives with a crackhead. Go is a trip to your Volvo dealer - uneventful but you get what you want at the end of the day and get where you want to go and when you're done, you're done.
  - jebblue 14y ago
    >> entire JVM of baggage It's comprehensive, stable, capable, reliable and understandable. >> is terribly complicated EJB's are complicated, the JVM isn't complicated. >> doesn't really give any benefits over anything else Check the list of companies and people using the JVM and languages implemented on it.
    - meaty 14y ago
      Yes I know. We use the JVM as well and EJBs and toplink and JMS and glassfish and all sorts of hellish enterprise stuff. People smoke. It doesn't mean its good.
  - mafribe 14y ago
deleted 14y ago
[deleted]
kinofcain 14y ago
One of the first things you're likely to desire after going through this tutorial is more sophisticated routing, the gorilla toolkit has an excellent reversible routing system that works with the std lib http packages: http://www.gorillatoolkit.org/pkg/mux http://www.gorillatoolkit.org/pkg/mux
NateDad 14y ago
You can actually read the go language spec in a couple hours. You can pick up and be productive in the language in a weekend. And yet you can optimize code down to the byte level where needed. This is the uniqueness of Go. It is familiar enough that most anyone can look at some code and figure out what it's doing, but it's not hard to make complex and performant code. Simple and powerful is better than complex and powerful.
- eropple 14y ago
  > And yet you can optimize code down to the byte level where needed. I can't see how this can be true in any real form if I can't completely turn off garbage collection. There's a lower bound to your ability to eke out additional perf when you have to take into account a stop-the-world garbage collector that you don't directly control. I'm certainly not the best programmer around, but I tend to subscribe to the notion that perhaps complex and powerful exists because that complexity grants additional flexibility to those who know how to use it. (Hell, Rob Pike has admitted as much on his blog regarding why Go doesn't appeal to many people who are competent C++ programmers. Though he decided to frame it as if it's a negative, which I really appreciated.)
  - lucian1900 14y ago
    Go makes it easy (and common) enough to avoid spurious allocations and to reuse memory. The GC is often relied on about as much as explicit deallocation in C++, not as much as in functional or dynamic languages.
tferris 14y ago
What's the fastest templating engine for Go? And how does it compare to respective implementations in other languages?
lumberjack 14y ago
I was kind of disappointed that they went with a flat file approach for permanent storage, especially because the documentation for the typical RDBMS interaction isn't exactly comprehensive.
trungonnews 14y ago
Question for Gophers. How do you guys debug your code? What IDE do you use? Scala works beautifully with IDEA IDE, one of the best IDE out there! GUI debugger just works out of the box. I tried using Go for a little bit but I find IDE and tooling support for Go is a bit lacking. Do people consider these aspects anymore when they evaluate a new language? A proper IDE support can greatly boost your productivity!
- andrewguenther 14y ago
  I have not personally used it, but I know that there is an IDEA plugin for Go out there that some people I know use and seem to be happy with.
  - trungonnews 14y ago
    I used that plugin too. It's still missing the debugging support.
- genwin 14y ago
  In Go I do poor man's debugging, print statements. Knowing the exact line number of an error is most of what I want for debugging. On errors Go shows the stack with line numbers. An IDE might be icing on the cake but there are usually disadvantages to be accepted as well.
- jff 14y ago
  I debug it using Printfs as needed--it just doesn't need a ton of debugging, and Go makes it easy with the %#v format in Printf giving an appropriate, annotated representation of pretty much any data type. Stack traces are also very informative if something goes badly wrong. I'm pretty sure GDB works now too, but again I have never really felt the need for it. But then, I've never really felt the need for syntax highlighting, code folding, or auto-completed function names. I feel like if my Go code has reached a level of complexity where it needs those things, I've done something wrong. My IDE is Acme, it lets me edit files, run my build scripts, and execute test programs.
  - 14y ago
michaelfairley 14y ago
I've run Go in production for a web application, and I'll say that Go is not a great choice for this task. The built in HTTP server doesn't have a way to shut down gracefully, there's not a good zero-downtime restart story, and the standard library SQL package (and abstractions on top of it) has some nasty warts that only show up under concurrent load. If you build a webapp in Go, be prepared to spend a lot of time monkeying around with problems that are solved issues on most other platforms.
- icey 14y ago
  Could you share some information about the SQL warts you found under concurrent load?
  - michaelfairley 14y ago
    My favorite – the method that determines the size of the connection pool: http://golang.org/src/pkg/database/sql/sql.go#L227 http://golang.org/src/pkg/database/sql/sql.go#L227
    - icey 14y ago
      That does look pretty gross, thanks for sharing. Any other ones stick out in your mind? I've been happy using Go against postgres, but haven't had a significant enough load to run into real problems yet.
- toddh 14y ago
  There are a few bumps and warts. The server close issue was one that made wonder if they ever tested, but I eventually discovered you can close down a server: lis, err := net.Listen("tcp","127.0.0.1:80") go http.Serve(lis, router) lis.Close()
  - michaelfairley 14y ago
    Closing the server is easy; making sure all in flight requests finish successfully, not so easy.
rartichoke 14y ago
I still don't see the use case for web app or web game development in Go. Go ahead and make a mini Go app, re-implement half the features that Express in Node has, then benchmark the 2 with real data using the same data and templates. Come back when you see that once you start pulling records in from mongodb or somewhere else and start rendering either server side templates with this mongo data or serving json back then the performance differences of the 2 frameworks begin to disappear. Node will perform better under high concurrency too for most sized responses. So where's the motivation to switch? If I switch to Go then I have to learn Go + I'm still using Javascript on the front end. If I stick with Node then I can use my JS knowledge on both ends. This is a really big deal for day to day web app programming and is a deal breaker for html5 games. Go cannot be taken seriously to be used for web apps until it offers actual performance gains over JS and gets something that lets you write Go but it spits out JS for the client, sort of like Java has GWT (ps. that bombermine mmo uses GWT). There's also a serious lack of good light weight web frameworks for Go. None of them come close to what Express does for Node, and I'm not the only one who thinks Express is really close to an excellent mix of features without getting in your face.
- BarkMore 14y ago
  Node will perform better under high concurrency too for most sized responses. Can you share evidence supporting this claim?
  - rartichoke 14y ago
    I tested it with Go v1.0.3 vs Node v0.8.21 + Express v3.1.0 I used mgo with Go to connect to mongodb. Then I filled it with 1,024 documents that was composed of 2 fields. One field with a few bytes of text and the other with a paragraph of text. Then I created a few handlers to return: 1) 1x document as json 2) 7x documents as json 3) 15x documents as json At 15x I decided this was likely going to generate a response large enough that there's no point going higher. It was about 25kb worth of json. Then I used a lib called "routes": https://github.com/drone/routes https://github.com/drone/routes It's not really close to what express does but it's better than nothing. Then I added in my own etag generator using the same method that express does (it gens it off the body length) for responses > 1kb. Then I benchmarked each route 3 times with ab using: -n 7500 -c {50, 250, 750, 1500} I ignored the first and averaged the last 2 results. I did this on a local VM locked down to 1 CPU with 512mb of ram with a c2d 2.13ghz CPU and a 7200 rpm sata HD. Then I did the same with express using just bodyParser since neither setup had session support. Go didn't have a Redis store that was capable of working with the Gorilla session lib so I didn't use sessions on both setups. I used the native mongodb driver for node. Express was for the most part 10-15% faster where faster is more requests per second served. The latency was back and forth. I feel like the latency @ 99% was tighter with Go once the concurrency got really high but the amount was not enough to matter. For example once I got to the higher concurrencies both were taking a ridiculous amount of time (over 7 seconds) on my old crappy desktop. Loading in 5.5 seconds instead of 7 seconds is not really "better" since it's abysmal on both. Go is much better at responding with large amounts of data when the database call is eliminated. I can only assume its ability to deal with large strings is leaps and bounds superior to v8 which makes sense to me. The thing is though, that's pretty much irrelevant. If I was going to serve static content I would be using S3 or nginx. If I'm serving dynamic content then I'm likely pulling this in from a database.
StavrosK 14y ago
Most of the comments here generally rave about Go, but what would be more useful to us is things that people found not to be so great in it, like michaelfairley's comment. I'd like to know what Go isn't good for, to avoid spending ages writing something in it because I like its features only to discover it can't easily do something I want.

72 points by gits1225 14y ago

I've often wondered about using Go as an architectural choice - it's near-native fast, the syntax and semantics are good, it's GC'ed and runs on Linux (edit: my language of choice is C# - and Go is the only one that comes close to it _and_ runs on Linux, IMO - any others out there?- performance is critical). However, if I decide to go with Go as a framework choice, is there an active market of Go developers out there from which one can hire?

wging 14y ago
It seems so easy to pick up that I wonder whether it's wise to restrict hiring to those who are 'Go developers'.
- photon137 14y ago
  That's also true. But having the ability to hire people who can hit the ground running with production code is an advantage.
gits1225 14y ago
I think, the best time to find hackers would be before killer applications[1] written in that specific programming language starts to appear. After that, time will pave way to The Go paradox[2]. The best places to find these people would be golang-nuts mailing list, /r/golang, #go-nuts irc etc. [1] https://en.wikipedia.org/wiki/Killer_app https://en.wikipedia.org/wiki/Killer_app [2] http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
- danieldk 14y ago
  After that, time will pave way to The Go paradox[2]. I am not sure. Most people who know the important low-level languages well, are not likely to be a fan of Go. Seasoned C++ hackers will miss templates dearly (no, interfaces are not a replacement for templates, they are a replacement for abstract base classes) and C/C++ programmers dislike the lack of control over memory management. If you are using C or C++ in 2012, you probably have good reasons and Go mostly sacrifices the advantages of C and C++. Someone who is familiar enough with Haskell, ML, or Scala, will dislike the fact that Go practically ignored (or rejected?) two or three decades of research an programming languages. From the perspective of PL research, Go is a weak language. In other words, the low-level and strong typing crowds are not that much interested in Go. If there is a new imperative language that does interest them, it is probably Rust. The question is, who does switch to Go? One would guess that these are mostly Python and Ruby programmers who have never written much C, C++, or Haskell, and are looking for something faster and compiled. Yes, this is a generalization, and there are plenty of exceptions. Not exactly the 'Python paradox', 'better than the rest', programmers. Following the Google+ community, discussions on HN, and to an extend the Go mailing lists, confirms those suspicions. There are lot of grandiose claims supporting Go (one of my personal pet peeves are people claiming that 'Go interfaces are like Haskell typeclasses'). But if you look at the language spec, there is not much interesting. Goroutines are nice, but they are just green threads. Channels have been done elsewhere. Go is just a very boring language (which isn't necessarily bad), pretty much like Java, without the good package management (no versioning), good IDEs, broad library support, or a performant garbage collector. Boring languages attract more mediocre programmers than great programmers. Edit: if you downvote, please, at least leave a comment ;).
  - 3pt14159 14y ago
    Easier concurrancy and better string management. Current c/c++ people already learned the common methods. Also, less ambiguous lines of code.
  - aninteger 14y ago
    I can't downvote but I'm using C/C++ in 2013 instead of Go simply because Go is not portable enough. There is currently no PowerPC port and that is still a requirement for me.
    - jff 14y ago
      gccgo might solve your problem, if you actually want the problem to be solved.
  - icey 14y ago
    Hi, mediocre programmer here! I would add a bullet point to the list of reasons I like go: "Boring to people who bring up Haskell in every programming conversation" ;) Seriously though, there are huge classes of problems in which the "interesting" part of the problem isn't the software that gets written but the business needs it solves. I am a fan of functional programming (I started the Clojure subreddit, and do a lot of "for fun" programming in it), but I've never run across a problem at my business where I felt like I needed to crack open Okasaki's book, or thought "this would be easier with an applicative functor". Something I've enjoyed about learning Go is the open & accepting nature of the community; I don't think I've ever heard someone called "mediocre" because of other languages they use. I am happy to feel like I don't have to be an incredible programmer to read the source code of the language I use, or the libraries I pull into my projects. I just want to get shit done so I can work on the problems that I find interesting, and for lots of us, that's just not going to be yet another implementation of datalog.
  - burntsushi 14y ago
    > no, interfaces are not a replacement for templates, they are a replacement for abstract base classes Interfaces aren't a replacement for templates, but they aren't a replacement for abstract base classes either. Interfaces in Go provide polymorphism through structural sub-typing. My limited knowledge of abstract base classes says that these are very much not the same. > Someone who is familiar enough with Haskell, ML, or Scala, will dislike the fact that Go practically ignored (or rejected?) two or three decades of research an programming languages. From the perspective of PL research, Go is a weak language. I am a Haskell programmer, but that crowd is impossible to please unless you've provided every PL feature out of research in the last few decades. I've seen virtually no appreciation for simplicity of language design as an entire unit. > If there is a new imperative language that does interest them, it is probably Rust. Yes. I can't wait for Rust to get a bit more love in the documentation department. Pattern matching? Algebraic data types? Thread local storage? Type classes? Yes please! Where do I sign up? > The question is, who does switch to Go? One would guess that these are mostly Python and Ruby programmers who have never written much C, C++, or Haskell, and are looking for something faster and compiled. Yes, this is a generalization, and there are plenty of exceptions. Not exactly the 'Python paradox', 'better than the rest', programmers. In my experience, most Go programmers are in fact coming from Python and Ruby. The premise of the "Go" or "Python" paradox is that skilled programmers tend to be the first ones to adopt new languages. Then the less-skilled programmers follow when there is sufficient buzz. I think that if one accepts that premise, it is applicable for Go. > one of my personal pet peeves are people claiming that 'Go interfaces are like Haskell typeclasses' That is annoying, but completely understandable. They are deceptively similar on the surface. But I don't think this kind of confusion is unique to Go. You'll see it everywhere. You know what else people confuse? That Go interfaces are just like abstract base classes! :P > But if you look at the language spec, there is not much interesting. That's kind of the point. If you don't accept the overall simplicity of the design Go as a feature, then I can't blame you if you dismiss Go. If all you want to judge a language by is whether it includes cool and exciting new features, then Go will never be a good choice for you a priori. > Go is just a very boring language (which isn't necessarily bad), pretty much like Java, without the good package management (no versioning) I am utterly baffled. Go's approach to packaging is literally the best tool of its class that I've ever used. The Go tool militates toward convention rather than providing a dizzying array of features. This makes it strictly less powerful than other packaging tools, but god dammit, it makes it dead simple to install packages. You want to try my window manager, which is roughly 30,000 LOC (including my X libraries)? If you have Go installed: `go get github.com/BurntSushi/wingo`. That's it. You're done. I just ran it on my system, and it downloaded, compiled and installed my window manager---along with all of its dependencies---in less than 30 seconds. You might say---other build tools can do this! But do you know how many lines of configuration I had to write for any of this to work? None. I didn't specify dependencies. No strange command line flags. Nothing. The common case Just Works. > Goroutines are nice, but they are just green threads. Channels have been done elsewhere. This is a vast understatement. Just green threads? And please, tell me, what other mainstream language supports green threads? I know Haskell and Erlang do. Rust will (yay). Anything else? No? (I know Java doesn't, but I can't remember if this is a limitation of the JVM or if Scala or Clojure have green threads). Go does. That's a pretty big deal. Go makes a solid concurrent style of programming in a C-like language virtually free. Sure, everything is still mutable, but there are powerful idioms that---in my experience---militate against race conditions. It's not as good as Haskell/Erlang/Rust in the compile time safety department, but I'll be damned if it isn't loads easier than my other choices: C, C++, Java, Python, Ruby, Lua, blah blah. > Boring languages attract more mediocre programmers than great programmers. And close minded folk think they have all the answers. It's possible for people to enjoy using more than one tool. I'm a hacker, and I love good tools. Go is a great tool. So is Haskell. I hope that Rust will be.
iamwil 14y ago
You can look on the google groups, called go-nuts, and see how many devs are subscribed. I wouldn't worry about an active market of Go devs to hire. If a language is any good, it'll attract developers. If you're a programmer, you should try out the language to not only do things you can do in other languages (to see how it fares), but more importantly, "What are the new things I can do with Go that use to be hard, but are now easy?"
icey 14y ago
I've spent the past couple of months working with Go, coming from a mostly C# and Python background. One of the attractions to the language for me is that it's straightforward to pick up. Because there aren't a lot of "fancy" features in the language like Linq or list comprehensions, it's easy to dive into a block of code and figure out what's going on without requiring a lot of background knowledge. The language eschews some brevity in exchange for clarity, which gives me a lot of confidence that I can take a good developer from any background, give them a week and feel like they've got a decent chance of acquiring the knowledge they need to work with the language. The newness of the language means that there isn't a huge ecosystem of libraries available, BUT the standard lib is pretty damn great, and there are more and more people coming to the language every day. My favorite thing about go is it's overall sense of boringness - Go code seems very predictable. There's a culture of digging into the source throughout the community, and tools like go fmt & go vet ensure that most code looks similar. It'd be worth spending a week with it to write something useful to get a sense of whether or not you truly like it, but my experience has been very positive so far.
- StavrosK 14y ago
  My problem with it is how frustrating it is to write when you're not very familiar with it, but I suspect that's more of a generic complaint about learning a new language rather than soecifically about Go. Every line I write, I go "argh, I wonder if this is the idiomatic way to do this" and I get frustrated a lot. I love the features, though, especially the concurrency ones. It was conceptually trivial to write a multicasting TCP proxy in it.
  - icey 14y ago
    I had the same problems when I first started learning the language, and while I'm certain I've got a lot more to learn I found that making a habit of reading lots of source code made a huge difference. After a little while you start thinking about "can this code be clearer? Are the intentions obvious?" and that makes the code much easier to write. Go is incredibly easy to refactor, so instead of worrying about being exactly right, you can focus on "is this easy to reason about?". My experience has been that this process will get you very close to idiomatic code on its own.
krakensden 14y ago
No love for Mono? My impression was that they're doing good work- they've finally turned on their generational GC, for instance.

humanspecies 14y ago

Go still hasn't found a niche to be useful to. Nobody's giving up 30 years of C for systems programming, nobody's going to use Go for web apps when higher level languages are clearly more practical, nobody will give up Haskell for scientific and massive parallel programming. All in all I think Go is an interesting experiment but it serves no purpose that I can use right now

bromang 14y ago
C/C++ is the language of choice for scientific and massively parallel programming. as far as I know Haskell is not really competitive in that area.
- lutusp 14y ago
  > C/C++ is the language of choice ... Linus Torvalds would disagree that C and C++ are the same language as suggested by "C/C++" and by the singular pronoun that follows. http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus And maybe too much weight is given to Torvalds' views on this and other topics.
  - danieldk 14y ago
    Linus Torvalds would disagree that C and C++ are the same language as suggested by "C/C++" and by the singular pronoun that follows. One can easily program as if it were C, using templates to avoid ugly macro mess for generic algorithms and types. Edit: corrected is -> as.
    - lutusp 14y ago
      > One can easily program is if [sic] it were C, using templates to avoid ugly macro mess for generic algorithms and types. Did you mean "as if"? If so, that's exactly what Torvalds objects to -- the things about C++ that supposedly represent improvements over C. He goes on about how many of the conveniences of C++ -- like the STL -- aren't as wrung out as most people think and don't actually work as intended. I don't necessarily agree with his position in all respects, but some of the enhancements in C++, aren't actually enhancements.

sshillo 14y ago

If you need performance why not go with scala. The play framework is super easy to use. Anyone who is familiar with mvc will pick it up very fast. There is also Martin Odersky's course which is a great intro.

lucian1900 14y ago
Scala is extremely complex, rivaling C++. Its syntax in particular is just crazy. Which is a shame, since it's otherwise somewhat interesting. Haskell is a much better choice than Scala, as long as JVM isn't required.
- GhotiFish 14y ago
  I'm sorry, but as I've tried to learn Haskell in 2 month sprints 4 separate times and failed, I can not in good conscience recommend Haskell, ever. I like the language allot, but even the programmers I believe are extremely talented just cannot learn it, let alone 99% of people I have to work with who simply can not even begin to make use of the language at it's most basic form. A professor I knew, who was easily one of the more decorated in my university, claimed he knew Haskell. I had used Haskell to parse biomedical data for my course on biometrics, as the data was inconsistent and full of errors, the correct design was to create a monadic structure. I consulted that professor, and he was flummoxed, just on the basic structure of the program (which was done in a basic top down style of declaring the types and breaking large functions into small ones). I fully accept my inability to use the language in a useful way may just be symptomatic of me being an idiot. I fully accept that my professors inability to understand the language in a any way may be symptomatic of him being an idiot. But as big a failure as I am at learning this language, I can't imagine the result of tasking someone who doesn't enjoy programming with maintaining Haskell. If scala is worse, then that's just horrifying.
  - josh-j 14y ago
    Just considering the language, then I think Scala is considerably easier to learn than haskell _if_ you're from an OO background. It's a multi-paradigm language making it easy to use it like a better c++11. However, idiomatic Scala is functional, and so you're pushed in another direction by the community (but, importantly, not forced). However, starting with a blank slate, then Haskell might be the easier language to learn. But if we consider the resources to learn the language along with the language, then I think Scala dominates Haskell. Haskell was painful for me to learn because to become proficient I had to trudge through not only books but wikis, blogs, and code. There is nothing like Odersky's Scala book in Haskell. Learn you a Haskell, the Haskell wikibook, and Real World Haskell are all _terrible_ at preparing someone to become a proficient haskeller because while they show you the language they don't train you to think functionally. In imperative languages you're giving a lot of sequential instructions to a robot. In functional languages you're programming the robot to understand a new language, and then you describe the way things ought to be in that language.

neya 14y ago

Why do people choose 'Go' over Scala? The latter is a 'better' choice (in my opinion) for web applications and add in the play framework, you've got an ultra-fast, scalable web app. running in minutes. I do admit that Scala has a steeper learning curve, but my guess is that it's worth it. Can anyone explain WHY Scala seems to be ignored by most of the programming community, especially here on HN, where everyone seems to be in favor of either Node.js or Go... ? Is there anyone who can provide some constructive negative feedback regarding Scala (apart from the learning curve) over GO?

deleted 14y ago
[deleted]
meaty 14y ago
Because it requires an entire JVM of baggage, is terribly complicated and doesn't really give any benefits over anything else. Its like a Swiss army knife with a million blunt obscure tools rather than 5 useful sharp ones, or a crazy girlfriend who has three violent ex husbands who keep coming round to your house and lives with a crackhead. Go is a trip to your Volvo dealer - uneventful but you get what you want at the end of the day and get where you want to go and when you're done, you're done.
- jebblue 14y ago
  >> entire JVM of baggage It's comprehensive, stable, capable, reliable and understandable. >> is terribly complicated EJB's are complicated, the JVM isn't complicated. >> doesn't really give any benefits over anything else Check the list of companies and people using the JVM and languages implemented on it.
  - meaty 14y ago
    Yes I know. We use the JVM as well and EJBs and toplink and JMS and glassfish and all sorts of hellish enterprise stuff. People smoke. It doesn't mean its good.
- mafribe 14y ago

deleted 14y ago

[deleted]

kinofcain 14y ago

One of the first things you're likely to desire after going through this tutorial is more sophisticated routing, the gorilla toolkit has an excellent reversible routing system that works with the std lib http packages: http://www.gorillatoolkit.org/pkg/mux http://www.gorillatoolkit.org/pkg/mux

NateDad 14y ago

You can actually read the go language spec in a couple hours. You can pick up and be productive in the language in a weekend. And yet you can optimize code down to the byte level where needed. This is the uniqueness of Go. It is familiar enough that most anyone can look at some code and figure out what it's doing, but it's not hard to make complex and performant code. Simple and powerful is better than complex and powerful.

eropple 14y ago
> And yet you can optimize code down to the byte level where needed. I can't see how this can be true in any real form if I can't completely turn off garbage collection. There's a lower bound to your ability to eke out additional perf when you have to take into account a stop-the-world garbage collector that you don't directly control. I'm certainly not the best programmer around, but I tend to subscribe to the notion that perhaps complex and powerful exists because that complexity grants additional flexibility to those who know how to use it. (Hell, Rob Pike has admitted as much on his blog regarding why Go doesn't appeal to many people who are competent C++ programmers. Though he decided to frame it as if it's a negative, which I really appreciated.)
- lucian1900 14y ago
  Go makes it easy (and common) enough to avoid spurious allocations and to reuse memory. The GC is often relied on about as much as explicit deallocation in C++, not as much as in functional or dynamic languages.

tferris 14y ago

What's the fastest templating engine for Go? And how does it compare to respective implementations in other languages?

lumberjack 14y ago

I was kind of disappointed that they went with a flat file approach for permanent storage, especially because the documentation for the typical RDBMS interaction isn't exactly comprehensive.

trungonnews 14y ago

Question for Gophers. How do you guys debug your code? What IDE do you use? Scala works beautifully with IDEA IDE, one of the best IDE out there! GUI debugger just works out of the box. I tried using Go for a little bit but I find IDE and tooling support for Go is a bit lacking. Do people consider these aspects anymore when they evaluate a new language? A proper IDE support can greatly boost your productivity!

andrewguenther 14y ago
I have not personally used it, but I know that there is an IDEA plugin for Go out there that some people I know use and seem to be happy with.
- trungonnews 14y ago
  I used that plugin too. It's still missing the debugging support.
genwin 14y ago
In Go I do poor man's debugging, print statements. Knowing the exact line number of an error is most of what I want for debugging. On errors Go shows the stack with line numbers. An IDE might be icing on the cake but there are usually disadvantages to be accepted as well.
jff 14y ago
I debug it using Printfs as needed--it just doesn't need a ton of debugging, and Go makes it easy with the %#v format in Printf giving an appropriate, annotated representation of pretty much any data type. Stack traces are also very informative if something goes badly wrong. I'm pretty sure GDB works now too, but again I have never really felt the need for it. But then, I've never really felt the need for syntax highlighting, code folding, or auto-completed function names. I feel like if my Go code has reached a level of complexity where it needs those things, I've done something wrong. My IDE is Acme, it lets me edit files, run my build scripts, and execute test programs.
- 14y ago

michaelfairley 14y ago

I've run Go in production for a web application, and I'll say that Go is not a great choice for this task. The built in HTTP server doesn't have a way to shut down gracefully, there's not a good zero-downtime restart story, and the standard library SQL package (and abstractions on top of it) has some nasty warts that only show up under concurrent load. If you build a webapp in Go, be prepared to spend a lot of time monkeying around with problems that are solved issues on most other platforms.

icey 14y ago
Could you share some information about the SQL warts you found under concurrent load?
- michaelfairley 14y ago
  My favorite – the method that determines the size of the connection pool: http://golang.org/src/pkg/database/sql/sql.go#L227 http://golang.org/src/pkg/database/sql/sql.go#L227
  - icey 14y ago
    That does look pretty gross, thanks for sharing. Any other ones stick out in your mind? I've been happy using Go against postgres, but haven't had a significant enough load to run into real problems yet.
toddh 14y ago
There are a few bumps and warts. The server close issue was one that made wonder if they ever tested, but I eventually discovered you can close down a server: lis, err := net.Listen("tcp","127.0.0.1:80") go http.Serve(lis, router) lis.Close()
- michaelfairley 14y ago
  Closing the server is easy; making sure all in flight requests finish successfully, not so easy.

rartichoke 14y ago

I still don't see the use case for web app or web game development in Go. Go ahead and make a mini Go app, re-implement half the features that Express in Node has, then benchmark the 2 with real data using the same data and templates. Come back when you see that once you start pulling records in from mongodb or somewhere else and start rendering either server side templates with this mongo data or serving json back then the performance differences of the 2 frameworks begin to disappear. Node will perform better under high concurrency too for most sized responses. So where's the motivation to switch? If I switch to Go then I have to learn Go + I'm still using Javascript on the front end. If I stick with Node then I can use my JS knowledge on both ends. This is a really big deal for day to day web app programming and is a deal breaker for html5 games. Go cannot be taken seriously to be used for web apps until it offers actual performance gains over JS and gets something that lets you write Go but it spits out JS for the client, sort of like Java has GWT (ps. that bombermine mmo uses GWT). There's also a serious lack of good light weight web frameworks for Go. None of them come close to what Express does for Node, and I'm not the only one who thinks Express is really close to an excellent mix of features without getting in your face.

BarkMore 14y ago
Node will perform better under high concurrency too for most sized responses. Can you share evidence supporting this claim?
- rartichoke 14y ago
  I tested it with Go v1.0.3 vs Node v0.8.21 + Express v3.1.0 I used mgo with Go to connect to mongodb. Then I filled it with 1,024 documents that was composed of 2 fields. One field with a few bytes of text and the other with a paragraph of text. Then I created a few handlers to return: 1) 1x document as json 2) 7x documents as json 3) 15x documents as json At 15x I decided this was likely going to generate a response large enough that there's no point going higher. It was about 25kb worth of json. Then I used a lib called "routes": https://github.com/drone/routes https://github.com/drone/routes It's not really close to what express does but it's better than nothing. Then I added in my own etag generator using the same method that express does (it gens it off the body length) for responses > 1kb. Then I benchmarked each route 3 times with ab using: -n 7500 -c {50, 250, 750, 1500} I ignored the first and averaged the last 2 results. I did this on a local VM locked down to 1 CPU with 512mb of ram with a c2d 2.13ghz CPU and a 7200 rpm sata HD. Then I did the same with express using just bodyParser since neither setup had session support. Go didn't have a Redis store that was capable of working with the Gorilla session lib so I didn't use sessions on both setups. I used the native mongodb driver for node. Express was for the most part 10-15% faster where faster is more requests per second served. The latency was back and forth. I feel like the latency @ 99% was tighter with Go once the concurrency got really high but the amount was not enough to matter. For example once I got to the higher concurrencies both were taking a ridiculous amount of time (over 7 seconds) on my old crappy desktop. Loading in 5.5 seconds instead of 7 seconds is not really "better" since it's abysmal on both. Go is much better at responding with large amounts of data when the database call is eliminated. I can only assume its ability to deal with large strings is leaps and bounds superior to v8 which makes sense to me. The thing is though, that's pretty much irrelevant. If I was going to serve static content I would be using S3 or nginx. If I'm serving dynamic content then I'm likely pulling this in from a database.

StavrosK 14y ago

Most of the comments here generally rave about Go, but what would be more useful to us is things that people found not to be so great in it, like michaelfairley's comment. I'd like to know what Go isn't good for, to avoid spending ages writing something in it because I like its features only to discover it can't easily do something I want.