10 ms·

Google's Go Programming Language Grows Up: Now What?

102 points by rohshall 14y ago

bkirkby 14y ago
i've not had a ton of experience with Go, just some coder challenge type stuff, but i love almost everything about the language. it has the feel of old skool C, but greatly improved and upgraded. the one thing i hate about Go is how it does exported identifiers. in order to make a variable/method available to other packages, you must start the variable name with an uppercase letter. this is the only way to export identifiers which means the exporting is a bit obfuscated. giving meaning to the first letter of a variable name is filled with potential problems: 1. people will inadvertently export properties simply because they chose to name them with uppercases 2. in some cases, you will need to force this case sensitive language to be case insensitive. ex: a json property named "address" needs to unmarshal into a Go variable named "Address" 3. i don't have this concern personally, but i wonder about coding in languages that don't have uppercases. (actually, it's prolly legit to force them to code in english i suppose) i've read the Go engineers are extremely happy with this feature, so i guess i'm going to have to get used to it and the bevy of problems it creates if i'm going to continue using it.
- markdrago 14y ago
  FWIW the 'tag' concept in Go alleviates concern #2. Info regarding tags (scroll a bit): http://golang.org/ref/spec#Struct_types http://golang.org/ref/spec#Struct_types How tags are used by the built-in JSON encoding library: http://golang.org/pkg/encoding/json/#Marshal http://golang.org/pkg/encoding/json/#Marshal Of course, just because this kind of thing can be handled with tags doesn't mean that people will actually know to use them or actually use them correctly.
  - bkirkby 14y ago
    thanks for that! i wasn't even aware of field tags. i can see this solution causing other problems too. there can only be one tag per field, right? what happens when another library has a different meaning for the tag? are we going to see a hacky standard emerge where we have multiple tags in the one field separated by semicolons (with a precursor for each tag like 'json:')? it feels like an ugly hack to use tags this way, but i guess an ugly hack is what is needed for this right now. i would much prefer a separate keyword to explicitly export fields. or, since we are already hacking the tag, why not have the compiler export any field with a tag called "export"?
esolyt 14y ago
"Now that Google has released a stable version, and is deploying support on Google App Engine, it's likely to gain even more traction." I think what Go actually needs is another popular framework so that the language can be used without depending on Google's App Engine and it's unstable pricing.
- genbattle 14y ago
  The great thing about Go as a web language is that alot of the bones are already there - templates and HTTP handling are already waiting for you in the standard library. The most popular web frameworks i've seen for Go so far are Web.go (a Web.py clone) and Revel (a Play clone). Frameworks will develop organically over time. The only reason they're not very strong at this stage is because as I said; most of the batteries you need for web development are already included in the standard library.
  - luriel 14y ago
    > The most popular web frameworks i've seen for Go so far are Web.go (a Web.py clone) and Revel (a Play clone). Unfortunately both web.go and specially Revel were developed by people that were not (yet?) familiar with Go's style, and they simply cloned what they expected from other languages and frameworks they were more familiar with. Gorilla[1] and pat[2] (by the creator of Sinatra, who is now a Gopher) fit much more with the Go style and philosophy. [1]: http://gorilla-web.appspot.com/ http://gorilla-web.appspot.com/ [2]: https://github.com/bmizerany/pat https://github.com/bmizerany/pat
- jedc 14y ago
  Unstable pricing?? App Engine pricing stayed the same for years, then made a big shift as it officially came out of preview. Yes, it was a big change, but it's only happened once. I'm a novice developer using App Engine and while there are things you can criticize about it (including the cost), "unstable pricing" isn't one.
  - esolyt 14y ago
    I don't dislike App Engine. I just don't want to depend on it. I don't like the idea that I am practically forced to use App Engine if I choose to use Go, since there aren't any viable alternatives as far as I can see. We need the "Django" of Go.
lucian1900 14y ago
Go's GC is in fact much, much worse than the JVM's. One may have less memory issues because Go tends to generate less garbage, though.
- louhike 14y ago
  Can you prove your statement or give a link to an article on this subject?
  - lucian1900 14y ago
    The JVM has several swappable GCs, both mature and new. There is plenty of documentation out there about them. Go has (had?) libgc and is going to get a slightly better GC. I believe it's not even generational. Again, there are plenty of articles about that, especially about the recent and prominent bug on 32bit platforms.
- effinjames 14y ago
  Go's VM consume less resources, so we gets more RAM. Fore back-end processing, it's a supercool trade off.
  - genbattle 14y ago
    First of all; Go is compiled to binary form, it doesn't run on a VM (yet?). Second of all; the words you're looking for are "get" and "For", not "gets" and "Fore". Sorry to be a grammar nazi, but I'm just calling it as I see it, and this isn't Reddit or 4chan (yet?). For others wanting to know more about Go's garbage collection, it used a conservative GC up until recently, but heaps of work has been done to make the GC precise, so we don't get leaks on 32-bit platforms. As far as I know this GC change has yet to be released (current release is 1.0.2, and the changes should be in the next release). That said, if you clone tip and build from there (it's remarkably stable) you should be able to see the differences.
    - tomp 14y ago
      For some people, VM means everything that the language offers to the programmer at runtime. Sometimes libraries, usually GC. Even malloc could be considered VM.
biomechanica 14y ago
It's seems like there's been a lot of posts about Go lately. Maybe I'm delusional.. I find Go to be nice to work with. I'm just starting out in it so I'm not exactly proficient yet, but it feels a lot easier to program with against say, Java. In regards to the GC. I saw a post a little while ago made by Rob Pike, I think (could be wrong) about how there are many improvements coming where they see 50% speed ups (sometimes even more). So, as young language I think Go has come pretty far and more is to come.
- nicholassmith 14y ago
  No, I agree there seems to be some kind of watershed moment where a lot of people are talking about it.
  - jff 14y ago
    And, apparently, a few people are now pissed that every post isn't about Node.js or Ruby anymore, because I have come across a small group of people that come into every Go thread and spread the same FUD about garbage collection, performance, maturity, and generics.
    - nicholassmith 14y ago
      Means it has hit a level of success then, remember when every thread about Ruby would degenerate into "YEAH! But RoR doesn't SCALE! HAH!"? Level of snark seems proportional to the level of success a language is enjoying. I must admit, I've not tried Go yet and I'm not overly sold on some of the syntax aspects but it's nice to see a new language doing well against established players.
- Jabbles 14y ago
  I wish that the articles submitted about Go were recent, rather than several months old. Go may be stable, but the culture and community are still changing rapidly. I'd also like to point out that the article contains virtually no information about Go, instead relying on speculation and some hacked up quotes from people who've used it (and one from Rob Pike).
kennethh 14y ago
What web framework should one use with Go?
- gamache 14y ago
  There seems to be a bit of traction around Revel: http://robfig.github.com/revel/ http://robfig.github.com/revel/ It was founded as a Play framework derivative, if you're familiar with that (I wasn't). I've been using it to put together a web service and I like it so far.
  - thebluesky 14y ago
    >It was founded as a Play framework derivative, if you're familiar with that (I wasn't). Play is a web framework for Scala and Java: http://playframework.org/ http://playframework.org/ We've been very happy with it.
  - luriel 14y ago
    Revel is getting traction mostly among people who (like its author) are not very familiar with Go. As gorilla http://gorilla-web.appspot.com/ http://gorilla-web.appspot.com/ and pat https://github.com/bmizerany/pat https://github.com/bmizerany/pat (by the creator of Sinatra) are much more in line with the Go philosophy.
    - batista 14y ago
      The good (brilliant) thing about Play for Java, was that it wasn't inline with the Java philosophy. So, Revel not being in line with the Go philosophy could also be a great thing.
- _ak 14y ago
  net/http together with Gorilla: http://gorilla-web.appspot.com/ http://gorilla-web.appspot.com/
- johnpmayer 14y ago
  Angularjs ;-) Seriously, push your templates, models, and controllers into static client code (html/js) and use any of the dead-simple Sinatra-like clones to quickly scaffold your REST resources. Go is a superb "plumbing" language, in my opinion.
webreac 14y ago
It is too sad, they choose the name of my favourite game to name a language. Now it is near impossible to make google searches about game of go.
- liotier 14y ago
  To avoid that obvious namespace collision, the Go language is usually referred to as "Golang".
  - seunosewa 14y ago
    Shouldn't they just rename the language to GoLang?
- praptak 14y ago
  The popularity of the verb "go" doesn't help either of the search terms. It's even in the article itself: "Can Go Go Mainstream?" Where Would Go Go if a Woodchuck would Go(#) Go? (#)As in "rewrite all of his woodchucking apps in Go"
  - genbattle 14y ago
    To be fair, this will change as go becomes more popular and mature, I don't even know why people keep bringing it up. Is "C" any more searchable? If C was 3 years old, search results would probably be dominated by pages on the letter "C". I remember search results when C# first came out: most search engines presumed you were talking about musical notes. Java searches kept showing me pages about coffee suppliers and distributors. None of these languages have this problem anymore because they are mature, and the context around them is firmly established. The accepted name for the language when doing searches is "golang", and Google does a great job at optimising results around this term. Also there's the IRC channel and Google group if you can't find what you need.
    - deleted 14y ago
      [deleted]
    - 14y ago
aartur 14y ago
I don't like that Go has builtin generic collections, but doesn't allow programmers to build their own. It feels more like some corporate/"4GL" programming language than a hacker's/"real" programmer's one. Maybe lack of generics is not so important, but it shows designer's attitude towards language users.
- ovidiu 14y ago
  This issue has been addressed in the FAQ. They say generics might get added at some point, but they don't want to rush it. C# 1.0 didn't have generics either. http://golang.org/doc/go_faq.html#generics http://golang.org/doc/go_faq.html#generics
  - elemeno 14y ago
    I'd argue that C# didn't become an interesting and enjoyable language until it gained generics. Generics certainly aren't essential to a language, but once you're used to them it does feel a touch chafing not to have them, as well as it feel a touch strange for them not to be included in a new, statically typed, language. My opinion naturally...
  - aartur 14y ago
    I meant that if they use generics in some built-in classes, they should also give that possibility to users. If they cannot give it to users, they shouldn't use it in built-in classes. It feels like they think users are too dumb to implement their own, so they give some created by them.
    - ovidiu 14y ago
      Maybe they are afraid of introducing some features they would later regret. This is not a hobby project of some lone hacker, it's meant to compile Google's infrastructure. I really don't see why user code has to have the same capabilities as the runtime. It looks more like a philosophical request than a practical one.
    - Jare 14y ago
jeremyjh 14y ago
This is really getting a bit overheated. I think I understand where the Go team is coming from, but there is so much hype from other quarters that I think is at best premature. I think Go will be a fantastic alternative to C for "systems" programming, once it matures. I think this was one of its most immediate original goals, but really it is not yet ready to do even that. Two main reasons it is not ready for that is that performance is not yet there though I think it will get there; second reason is that it has no support for dynamic linking or code loading. You can't write something like Apache, or even Nagios in a platform that has no support for loadable modules. Still I think there are LOTS of applications where these constraints would not be an issue. So then we have all this hype and people doing things like building web applications in Go and calling it the next Node.js or Ruby or Python and frankly this is just stupid. Despite some claims it has nowhere near the expressive power of those languages. It is statically typed but has no Generics - and there are quite a few use cases where there is no answer(https://groups.google.com/forum/#!topic/golang-nuts/PYJayE50JZg[1-25] https://groups.google.com/forum/#!topic/golang-nuts/PYJayE50...) and you will just have duplicate code. It polymorphism but no inheritance - and the way interfaces and composition works while still fairly powerful is not at all what an OO programmer would expect(http://xampl.com/so/category/software/golang/ http://xampl.com/so/category/software/golang/) just naively reading about this feature. Whatever you want to say about the benefits of simplicity, this is LESS powerful than any OO dynamic language. Go's closures are nice, but aside from that on what basis can any other claims be made about its expressive power? In fact, the language is intentionally very, very limited. They want large teams of mediocre programmers [1] to produce code that is very supportable. Everytime someone in the lists brings up a "why don't we have" question all the answers revolve around this premise, that the language becomes "too complicated" if you have crazy features like generics. So it seems Go is optimized to satisfy the angst of systems programmers who have to work on C code that is thirty years old and been maintained by dozens of people. I get it, but that doesn't mean its really a good language for hackers to use to build the latest social network for people who like cats. Ok so concurrency. Yes Goroutines are smart. Channels are smart. These are great features. Scala can do the same thing (and more elegantly) with it's Actor constructs. The same thing can probably be done in other languages such as Ruby (https://github.com/igrigorik/agent https://github.com/igrigorik/agent). Its nice that this feature is in Go from the beginning, but its going to make its way into other platforms as well. Performance. Well...lots of blog articles just keep repeating the mantra of "native code" as though it automatically means something. It doesn't. C isn't just fast because it generates native code, it is fast because it's compiler has been optimized for decades. Go doesn't have that today. In fact today, Go is slower than Java and Scala based on both Google's benchmarks (http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-performance-benchmark.php http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-p...) and the language shootout (http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang...). Go will get there almost certainly, or at least very close, but it isn't there today. Today if you want a static, fast language with good concurrency and an incredible standard library and extended library ecosystem then you want Scala I think. If you want a powerful, expressive language for quickly building web applications then you want Python, Ruby[2] or Node.js or similar. If you want a language is actually very fast and with incredible libraries you want C/C++. I really do not hate Go. But it is not yet ready to replace hardly anything in my opinion. edit: [1]You are right. The "mediocre programmer" comment is really out of line and a major distraction. I guess I actually think this IS a feature of Go: more maintainable code than C/C++ from mediocre developers. I'm bitter and tired ofdebugging twenty-year old C programs and I wish they were all written in Go. I shouldn't read that into Thompson's or Pike's intentions though. [2]May brain stopped working here - I meant Ruby not Java.
danenania 14y ago
I've been learning and trying out both Clojure and Go recently. While they clearly take very different approaches on many issues, I think they also have a surprising amount in common in their core philosophies. They both focus strongly on simplicity, removing boilerplate, performant and minimalist core data structures, and providing clean abstractions for parallelism. The split in how each goes about targeting 'simplicity' is quite interesting, and seems close to the heart of each language. In Go, simple seems to mean: obvious, intuitive, unclever, and familiar. Clojure's conception is much headier: simplicity isn't accomplished through familiarity and comfort, but through the power and flexibility to create appropriate abstractions, and the discipline to avoid dangerous ones. The most immediate consequence, for a newbie, is that Go feels a lot easier to learn, while Clojure is more mind-expanding and abstract. In Go, simplicity is easy. In Clojure, the simplicity is deeper and perhaps more theoretically pure, but reaching it can be quite a challenge. My preliminary feeling so far is that each feels like a very clean, modern language and is basically superior to other languages I've used (Ruby, Python, C, js) by every important metric except maturity of community and libraries, and each will have its place. Go's lack of cleverness probably makes it ideal for more run-of-the-mill systems with a lot of straightforward io, where organization, maintainability, and baseline performance are more important than development of powerful algorithms, while Clojure will be a better fit when cleverness is desired either to solve difficult problems or for rapid feature development (a la pg's Beating The Averages). I could also see them potentially working quite well in tandem for a system that spans both those categories. One more thought: as much as I like Clojure and understand the pragmatism of targeting the jvm, Go's ultra-simple, ultra-fast runtime, along with libraries and a community that embody a similar spirit, really is such a breath of fresh air compared to the jvm world and even the ruby/python worlds. In this realm I think Go beats Clojure at its own game. Thanks to the more 'difficult' choice of starting a fresh platform rather than leveraging an existing one, Go's whole ecosystem and development experience now share a unifying philosophy, and every aspect of working with Go is suffused with what makes Go great.
- reddit_clone 14y ago
  I wonder how hard/easy would be to compile Clojure to a native application? Perhaps targeting something like LLVM? Of course the big advantage of easy availability of all those Java libraries will be gone. But it might open other doors.
muruke 14y ago
I haven't written anything real in Go yet, but there is a lot of articles about it, and many parts of it do appeal to me. I like how they didn't write another language for the JVM, I like the c inspired syntax, I like the concurrency model they have, etc. It also seems to be getting a lot of praise in web development circles. But am I the only one that cringes at going back to writing & and * for passing parameters etc. for web development? I know there is sometimes a need for really managing memory but... I'd love a simplistic language built around the ideas of Go (small runtime, fast, type safe, compiled etc.) for building web apps. Time to download Go source and tinker...
sgdesign 14y ago
Like everybody, I've been hearing good things about Go lately. But although I'm curious about the language, its homepage (http://golang.org/ http://golang.org/) doesn't make a great impression. It looks very amateurish and unappealing. And you can pretty much say the same thing about http://www.scala-lang.org/ http://www.scala-lang.org/ and http://clojure.org/ http://clojure.org/ It might not seem like a big deal, but it would certainly not hurt a language's popularity to have a slightly nicer site. Unless of course these languages don't want to become popular. Edit: I actually can't find a single language site that looks good. So maybe bashing Go for this is unfair, although I still find the Go site particularly bad.
- BasDirks 14y ago
  Sometimes nicer is worse. When using the website of a language I want to focus only on information-I am on a mission. Things need to be in the right places, typography should be spartan and correct. It is a usability problem, not about appeal per se. The people coding circles around you often wouldn't notice if the logo of their language was in Comic Sans. To restore your faith a bit: http://www.iolanguage.com/ http://www.iolanguage.com/
- IvarTJ 14y ago
  I am not sure what you find unappealing about those websites, but I find Go’s website very easy to navigate and for browsing the standard library. When looking for software to depend on, I think I prefer a visual design that does not attempt to be in any way “mysterious,” but rather simple and predictable.
  - modarts 14y ago
    How do you equate "mysterious" with good visual design?
    - IvarTJ 14y ago
      I made an uneducated guess for why sgdesign disliked golang.org’s web design. I think an unearthly visual design is more appropriate for adventure games, less so for software tools. That does not mean that only “mysterious” visual design is good visual design.
scriptproof 14y ago
"programming to that in a way that is nonblocking". It is strange that go it compared to Node.js and this sentence is false. Each function has a Sync version to program in "blocking" way.
- gfosco 14y ago
  Sure there are Sync versions, but you almost never want to use them. There's nothing wrong with his sentence. He did not enjoy the Node.JS callback style event loop. I love it.
davidw 14y ago
I am / We are considering using Go, but I'm a bit reticent about its maturity compared to Erlang, which is a very, very solid system. The 32 garbage collection issue is a big question. Arm support is another. Also, all the extras Erlang gives you in terms of writing robust systems look pretty attractive. That said, I'm about 99% that Erlang will always remain a niche player, along the lines of Smalltalk and Lisp, whereas Go has a shot at 'the big time'. That's something to keep in mind in terms of hiring people and getting other people up to speed on the language. Go is something that other people will look at and 'get' a bit quicker than Erlang. BTW, interesting article on Go concurrency vs Erlang concurrency: http://www.informit.com/articles/article.aspx?p=1768317 http://www.informit.com/articles/article.aspx?p=1768317
- luriel 14y ago
  You might want to watch this talk about using Erlang in production: http://www.youtube.com/watch?v=G0eBDWigORY http://www.youtube.com/watch?v=G0eBDWigORY Go and Erlang have some differences, and I found particularly interesting that pretty much all the issues they have with Erlang don't apply to Go often because of how Go avoided what might seem superficially like a 'feature' in favor of "raw" simplicity. That said, Erlang probably would be my second choice after Go if I had to build a highly concurrent distributed system, just realize that things are not as rosy as they seem. BTW, to address your other comments: all the remaining 32bit GC issues should be solved in the upcoming Go 1.1 release (still you will always be much better off using the 64bit port), and the ARM port is in pretty good shape.
  - davidw 14y ago
    > Go and Erlang have some differences, and I found particularly interesting that pretty much all the issues they have with Erlang don't apply to Go often because of how Go avoided what might seem superficially like a 'feature' in favor of "raw" simplicity. Some of what they discuss simply isn't available in Go, like OTP, so I wouldn't count that as a "win" for Go. Other things like 'heart' are things I want, given that it's going to be for a semi-embedded system. That's a good video, but all languages have gotchas and things to watch out for, especially mature ones. Go has some advantages in a 'fresh start': some of the biggest Erlang warts are actually the language itself; the syntax, records, some things like that that are just kind of ugly. For a product currently in development, "should be solved by a future release" is probably too far in the future to matter much. "pretty good shape" sounds a bit worrisome for a semi-embedded device where updates via the internet are not necessarily going to be an easy proposition. 64bit is going to eat more memory, something we'd prefer to avoid if at all possible.
rbanffy 14y ago
Just out of curiosity, is anyone using Vala? I was asked to do a little bit of research into alternatives to build a cross-platform chat client and, along with the more obvious Java, C++/wx, Objective-C/OSX/GNUStep and C#/.NET/Mono stacks, I found Vala as a possible option.

102 points by rohshall 14y ago

i've not had a ton of experience with Go, just some coder challenge type stuff, but i love almost everything about the language. it has the feel of old skool C, but greatly improved and upgraded. the one thing i hate about Go is how it does exported identifiers. in order to make a variable/method available to other packages, you must start the variable name with an uppercase letter. this is the only way to export identifiers which means the exporting is a bit obfuscated. giving meaning to the first letter of a variable name is filled with potential problems: 1. people will inadvertently export properties simply because they chose to name them with uppercases 2. in some cases, you will need to force this case sensitive language to be case insensitive. ex: a json property named "address" needs to unmarshal into a Go variable named "Address" 3. i don't have this concern personally, but i wonder about coding in languages that don't have uppercases. (actually, it's prolly legit to force them to code in english i suppose) i've read the Go engineers are extremely happy with this feature, so i guess i'm going to have to get used to it and the bevy of problems it creates if i'm going to continue using it.

markdrago 14y ago
FWIW the 'tag' concept in Go alleviates concern #2. Info regarding tags (scroll a bit): http://golang.org/ref/spec#Struct_types http://golang.org/ref/spec#Struct_types How tags are used by the built-in JSON encoding library: http://golang.org/pkg/encoding/json/#Marshal http://golang.org/pkg/encoding/json/#Marshal Of course, just because this kind of thing can be handled with tags doesn't mean that people will actually know to use them or actually use them correctly.
- bkirkby 14y ago
  thanks for that! i wasn't even aware of field tags. i can see this solution causing other problems too. there can only be one tag per field, right? what happens when another library has a different meaning for the tag? are we going to see a hacky standard emerge where we have multiple tags in the one field separated by semicolons (with a precursor for each tag like 'json:')? it feels like an ugly hack to use tags this way, but i guess an ugly hack is what is needed for this right now. i would much prefer a separate keyword to explicitly export fields. or, since we are already hacking the tag, why not have the compiler export any field with a tag called "export"?

esolyt 14y ago

"Now that Google has released a stable version, and is deploying support on Google App Engine, it's likely to gain even more traction." I think what Go actually needs is another popular framework so that the language can be used without depending on Google's App Engine and it's unstable pricing.

genbattle 14y ago
The great thing about Go as a web language is that alot of the bones are already there - templates and HTTP handling are already waiting for you in the standard library. The most popular web frameworks i've seen for Go so far are Web.go (a Web.py clone) and Revel (a Play clone). Frameworks will develop organically over time. The only reason they're not very strong at this stage is because as I said; most of the batteries you need for web development are already included in the standard library.
- luriel 14y ago
  > The most popular web frameworks i've seen for Go so far are Web.go (a Web.py clone) and Revel (a Play clone). Unfortunately both web.go and specially Revel were developed by people that were not (yet?) familiar with Go's style, and they simply cloned what they expected from other languages and frameworks they were more familiar with. Gorilla[1] and pat[2] (by the creator of Sinatra, who is now a Gopher) fit much more with the Go style and philosophy. [1]: http://gorilla-web.appspot.com/ http://gorilla-web.appspot.com/ [2]: https://github.com/bmizerany/pat https://github.com/bmizerany/pat
jedc 14y ago
Unstable pricing?? App Engine pricing stayed the same for years, then made a big shift as it officially came out of preview. Yes, it was a big change, but it's only happened once. I'm a novice developer using App Engine and while there are things you can criticize about it (including the cost), "unstable pricing" isn't one.
- esolyt 14y ago
  I don't dislike App Engine. I just don't want to depend on it. I don't like the idea that I am practically forced to use App Engine if I choose to use Go, since there aren't any viable alternatives as far as I can see. We need the "Django" of Go.

lucian1900 14y ago

Go's GC is in fact much, much worse than the JVM's. One may have less memory issues because Go tends to generate less garbage, though.

louhike 14y ago
Can you prove your statement or give a link to an article on this subject?
- lucian1900 14y ago
  The JVM has several swappable GCs, both mature and new. There is plenty of documentation out there about them. Go has (had?) libgc and is going to get a slightly better GC. I believe it's not even generational. Again, there are plenty of articles about that, especially about the recent and prominent bug on 32bit platforms.
effinjames 14y ago
Go's VM consume less resources, so we gets more RAM. Fore back-end processing, it's a supercool trade off.
- genbattle 14y ago
  First of all; Go is compiled to binary form, it doesn't run on a VM (yet?). Second of all; the words you're looking for are "get" and "For", not "gets" and "Fore". Sorry to be a grammar nazi, but I'm just calling it as I see it, and this isn't Reddit or 4chan (yet?). For others wanting to know more about Go's garbage collection, it used a conservative GC up until recently, but heaps of work has been done to make the GC precise, so we don't get leaks on 32-bit platforms. As far as I know this GC change has yet to be released (current release is 1.0.2, and the changes should be in the next release). That said, if you clone tip and build from there (it's remarkably stable) you should be able to see the differences.
  - tomp 14y ago
    For some people, VM means everything that the language offers to the programmer at runtime. Sometimes libraries, usually GC. Even malloc could be considered VM.

biomechanica 14y ago

It's seems like there's been a lot of posts about Go lately. Maybe I'm delusional.. I find Go to be nice to work with. I'm just starting out in it so I'm not exactly proficient yet, but it feels a lot easier to program with against say, Java. In regards to the GC. I saw a post a little while ago made by Rob Pike, I think (could be wrong) about how there are many improvements coming where they see 50% speed ups (sometimes even more). So, as young language I think Go has come pretty far and more is to come.

nicholassmith 14y ago
No, I agree there seems to be some kind of watershed moment where a lot of people are talking about it.
- jff 14y ago
  And, apparently, a few people are now pissed that every post isn't about Node.js or Ruby anymore, because I have come across a small group of people that come into every Go thread and spread the same FUD about garbage collection, performance, maturity, and generics.
  - nicholassmith 14y ago
    Means it has hit a level of success then, remember when every thread about Ruby would degenerate into "YEAH! But RoR doesn't SCALE! HAH!"? Level of snark seems proportional to the level of success a language is enjoying. I must admit, I've not tried Go yet and I'm not overly sold on some of the syntax aspects but it's nice to see a new language doing well against established players.
Jabbles 14y ago
I wish that the articles submitted about Go were recent, rather than several months old. Go may be stable, but the culture and community are still changing rapidly. I'd also like to point out that the article contains virtually no information about Go, instead relying on speculation and some hacked up quotes from people who've used it (and one from Rob Pike).

kennethh 14y ago

What web framework should one use with Go?

gamache 14y ago
There seems to be a bit of traction around Revel: http://robfig.github.com/revel/ http://robfig.github.com/revel/ It was founded as a Play framework derivative, if you're familiar with that (I wasn't). I've been using it to put together a web service and I like it so far.
- thebluesky 14y ago
  >It was founded as a Play framework derivative, if you're familiar with that (I wasn't). Play is a web framework for Scala and Java: http://playframework.org/ http://playframework.org/ We've been very happy with it.
- luriel 14y ago
  Revel is getting traction mostly among people who (like its author) are not very familiar with Go. As gorilla http://gorilla-web.appspot.com/ http://gorilla-web.appspot.com/ and pat https://github.com/bmizerany/pat https://github.com/bmizerany/pat (by the creator of Sinatra) are much more in line with the Go philosophy.
  - batista 14y ago
    The good (brilliant) thing about Play for Java, was that it wasn't inline with the Java philosophy. So, Revel not being in line with the Go philosophy could also be a great thing.
_ak 14y ago
net/http together with Gorilla: http://gorilla-web.appspot.com/ http://gorilla-web.appspot.com/
johnpmayer 14y ago
Angularjs ;-) Seriously, push your templates, models, and controllers into static client code (html/js) and use any of the dead-simple Sinatra-like clones to quickly scaffold your REST resources. Go is a superb "plumbing" language, in my opinion.

webreac 14y ago

It is too sad, they choose the name of my favourite game to name a language. Now it is near impossible to make google searches about game of go.

liotier 14y ago
To avoid that obvious namespace collision, the Go language is usually referred to as "Golang".
- seunosewa 14y ago
  Shouldn't they just rename the language to GoLang?
praptak 14y ago
The popularity of the verb "go" doesn't help either of the search terms. It's even in the article itself: "Can Go Go Mainstream?" Where Would Go Go if a Woodchuck would Go(#) Go? (#)As in "rewrite all of his woodchucking apps in Go"
- genbattle 14y ago
  To be fair, this will change as go becomes more popular and mature, I don't even know why people keep bringing it up. Is "C" any more searchable? If C was 3 years old, search results would probably be dominated by pages on the letter "C". I remember search results when C# first came out: most search engines presumed you were talking about musical notes. Java searches kept showing me pages about coffee suppliers and distributors. None of these languages have this problem anymore because they are mature, and the context around them is firmly established. The accepted name for the language when doing searches is "golang", and Google does a great job at optimising results around this term. Also there's the IRC channel and Google group if you can't find what you need.
  - deleted 14y ago
    [deleted]
  - 14y ago

aartur 14y ago

I don't like that Go has builtin generic collections, but doesn't allow programmers to build their own. It feels more like some corporate/"4GL" programming language than a hacker's/"real" programmer's one. Maybe lack of generics is not so important, but it shows designer's attitude towards language users.

ovidiu 14y ago
This issue has been addressed in the FAQ. They say generics might get added at some point, but they don't want to rush it. C# 1.0 didn't have generics either. http://golang.org/doc/go_faq.html#generics http://golang.org/doc/go_faq.html#generics
- elemeno 14y ago
  I'd argue that C# didn't become an interesting and enjoyable language until it gained generics. Generics certainly aren't essential to a language, but once you're used to them it does feel a touch chafing not to have them, as well as it feel a touch strange for them not to be included in a new, statically typed, language. My opinion naturally...
- aartur 14y ago
  I meant that if they use generics in some built-in classes, they should also give that possibility to users. If they cannot give it to users, they shouldn't use it in built-in classes. It feels like they think users are too dumb to implement their own, so they give some created by them.
  - ovidiu 14y ago
    Maybe they are afraid of introducing some features they would later regret. This is not a hobby project of some lone hacker, it's meant to compile Google's infrastructure. I really don't see why user code has to have the same capabilities as the runtime. It looks more like a philosophical request than a practical one.
  - Jare 14y ago

jeremyjh 14y ago

This is really getting a bit overheated. I think I understand where the Go team is coming from, but there is so much hype from other quarters that I think is at best premature. I think Go will be a fantastic alternative to C for "systems" programming, once it matures. I think this was one of its most immediate original goals, but really it is not yet ready to do even that. Two main reasons it is not ready for that is that performance is not yet there though I think it will get there; second reason is that it has no support for dynamic linking or code loading. You can't write something like Apache, or even Nagios in a platform that has no support for loadable modules. Still I think there are LOTS of applications where these constraints would not be an issue. So then we have all this hype and people doing things like building web applications in Go and calling it the next Node.js or Ruby or Python and frankly this is just stupid. Despite some claims it has nowhere near the expressive power of those languages. It is statically typed but has no Generics - and there are quite a few use cases where there is no answer(https://groups.google.com/forum/#!topic/golang-nuts/PYJayE50JZg[1-25] https://groups.google.com/forum/#!topic/golang-nuts/PYJayE50...) and you will just have duplicate code. It polymorphism but no inheritance - and the way interfaces and composition works while still fairly powerful is not at all what an OO programmer would expect(http://xampl.com/so/category/software/golang/ http://xampl.com/so/category/software/golang/) just naively reading about this feature. Whatever you want to say about the benefits of simplicity, this is LESS powerful than any OO dynamic language. Go's closures are nice, but aside from that on what basis can any other claims be made about its expressive power? In fact, the language is intentionally very, very limited. They want large teams of mediocre programmers [1] to produce code that is very supportable. Everytime someone in the lists brings up a "why don't we have" question all the answers revolve around this premise, that the language becomes "too complicated" if you have crazy features like generics. So it seems Go is optimized to satisfy the angst of systems programmers who have to work on C code that is thirty years old and been maintained by dozens of people. I get it, but that doesn't mean its really a good language for hackers to use to build the latest social network for people who like cats. Ok so concurrency. Yes Goroutines are smart. Channels are smart. These are great features. Scala can do the same thing (and more elegantly) with it's Actor constructs. The same thing can probably be done in other languages such as Ruby (https://github.com/igrigorik/agent https://github.com/igrigorik/agent). Its nice that this feature is in Go from the beginning, but its going to make its way into other platforms as well. Performance. Well...lots of blog articles just keep repeating the mantra of "native code" as though it automatically means something. It doesn't. C isn't just fast because it generates native code, it is fast because it's compiler has been optimized for decades. Go doesn't have that today. In fact today, Go is slower than Java and Scala based on both Google's benchmarks (http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-performance-benchmark.php http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-p...) and the language shootout (http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang...). Go will get there almost certainly, or at least very close, but it isn't there today. Today if you want a static, fast language with good concurrency and an incredible standard library and extended library ecosystem then you want Scala I think. If you want a powerful, expressive language for quickly building web applications then you want Python, Ruby[2] or Node.js or similar. If you want a language is actually very fast and with incredible libraries you want C/C++. I really do not hate Go. But it is not yet ready to replace hardly anything in my opinion. edit: [1]You are right. The "mediocre programmer" comment is really out of line and a major distraction. I guess I actually think this IS a feature of Go: more maintainable code than C/C++ from mediocre developers. I'm bitter and tired ofdebugging twenty-year old C programs and I wish they were all written in Go. I shouldn't read that into Thompson's or Pike's intentions though. [2]May brain stopped working here - I meant Ruby not Java.

danenania 14y ago

I've been learning and trying out both Clojure and Go recently. While they clearly take very different approaches on many issues, I think they also have a surprising amount in common in their core philosophies. They both focus strongly on simplicity, removing boilerplate, performant and minimalist core data structures, and providing clean abstractions for parallelism. The split in how each goes about targeting 'simplicity' is quite interesting, and seems close to the heart of each language. In Go, simple seems to mean: obvious, intuitive, unclever, and familiar. Clojure's conception is much headier: simplicity isn't accomplished through familiarity and comfort, but through the power and flexibility to create appropriate abstractions, and the discipline to avoid dangerous ones. The most immediate consequence, for a newbie, is that Go feels a lot easier to learn, while Clojure is more mind-expanding and abstract. In Go, simplicity is easy. In Clojure, the simplicity is deeper and perhaps more theoretically pure, but reaching it can be quite a challenge. My preliminary feeling so far is that each feels like a very clean, modern language and is basically superior to other languages I've used (Ruby, Python, C, js) by every important metric except maturity of community and libraries, and each will have its place. Go's lack of cleverness probably makes it ideal for more run-of-the-mill systems with a lot of straightforward io, where organization, maintainability, and baseline performance are more important than development of powerful algorithms, while Clojure will be a better fit when cleverness is desired either to solve difficult problems or for rapid feature development (a la pg's Beating The Averages). I could also see them potentially working quite well in tandem for a system that spans both those categories. One more thought: as much as I like Clojure and understand the pragmatism of targeting the jvm, Go's ultra-simple, ultra-fast runtime, along with libraries and a community that embody a similar spirit, really is such a breath of fresh air compared to the jvm world and even the ruby/python worlds. In this realm I think Go beats Clojure at its own game. Thanks to the more 'difficult' choice of starting a fresh platform rather than leveraging an existing one, Go's whole ecosystem and development experience now share a unifying philosophy, and every aspect of working with Go is suffused with what makes Go great.

reddit_clone 14y ago
I wonder how hard/easy would be to compile Clojure to a native application? Perhaps targeting something like LLVM? Of course the big advantage of easy availability of all those Java libraries will be gone. But it might open other doors.

muruke 14y ago

I haven't written anything real in Go yet, but there is a lot of articles about it, and many parts of it do appeal to me. I like how they didn't write another language for the JVM, I like the c inspired syntax, I like the concurrency model they have, etc. It also seems to be getting a lot of praise in web development circles. But am I the only one that cringes at going back to writing & and * for passing parameters etc. for web development? I know there is sometimes a need for really managing memory but... I'd love a simplistic language built around the ideas of Go (small runtime, fast, type safe, compiled etc.) for building web apps. Time to download Go source and tinker...

sgdesign 14y ago

Like everybody, I've been hearing good things about Go lately. But although I'm curious about the language, its homepage (http://golang.org/ http://golang.org/) doesn't make a great impression. It looks very amateurish and unappealing. And you can pretty much say the same thing about http://www.scala-lang.org/ http://www.scala-lang.org/ and http://clojure.org/ http://clojure.org/ It might not seem like a big deal, but it would certainly not hurt a language's popularity to have a slightly nicer site. Unless of course these languages don't want to become popular. Edit: I actually can't find a single language site that looks good. So maybe bashing Go for this is unfair, although I still find the Go site particularly bad.

BasDirks 14y ago
Sometimes nicer is worse. When using the website of a language I want to focus only on information-I am on a mission. Things need to be in the right places, typography should be spartan and correct. It is a usability problem, not about appeal per se. The people coding circles around you often wouldn't notice if the logo of their language was in Comic Sans. To restore your faith a bit: http://www.iolanguage.com/ http://www.iolanguage.com/
IvarTJ 14y ago
I am not sure what you find unappealing about those websites, but I find Go’s website very easy to navigate and for browsing the standard library. When looking for software to depend on, I think I prefer a visual design that does not attempt to be in any way “mysterious,” but rather simple and predictable.
- modarts 14y ago
  How do you equate "mysterious" with good visual design?
  - IvarTJ 14y ago
    I made an uneducated guess for why sgdesign disliked golang.org’s web design. I think an unearthly visual design is more appropriate for adventure games, less so for software tools. That does not mean that only “mysterious” visual design is good visual design.

scriptproof 14y ago

"programming to that in a way that is nonblocking". It is strange that go it compared to Node.js and this sentence is false. Each function has a Sync version to program in "blocking" way.

gfosco 14y ago
Sure there are Sync versions, but you almost never want to use them. There's nothing wrong with his sentence. He did not enjoy the Node.JS callback style event loop. I love it.

davidw 14y ago

I am / We are considering using Go, but I'm a bit reticent about its maturity compared to Erlang, which is a very, very solid system. The 32 garbage collection issue is a big question. Arm support is another. Also, all the extras Erlang gives you in terms of writing robust systems look pretty attractive. That said, I'm about 99% that Erlang will always remain a niche player, along the lines of Smalltalk and Lisp, whereas Go has a shot at 'the big time'. That's something to keep in mind in terms of hiring people and getting other people up to speed on the language. Go is something that other people will look at and 'get' a bit quicker than Erlang. BTW, interesting article on Go concurrency vs Erlang concurrency: http://www.informit.com/articles/article.aspx?p=1768317 http://www.informit.com/articles/article.aspx?p=1768317

luriel 14y ago
You might want to watch this talk about using Erlang in production: http://www.youtube.com/watch?v=G0eBDWigORY http://www.youtube.com/watch?v=G0eBDWigORY Go and Erlang have some differences, and I found particularly interesting that pretty much all the issues they have with Erlang don't apply to Go often because of how Go avoided what might seem superficially like a 'feature' in favor of "raw" simplicity. That said, Erlang probably would be my second choice after Go if I had to build a highly concurrent distributed system, just realize that things are not as rosy as they seem. BTW, to address your other comments: all the remaining 32bit GC issues should be solved in the upcoming Go 1.1 release (still you will always be much better off using the 64bit port), and the ARM port is in pretty good shape.
- davidw 14y ago
  > Go and Erlang have some differences, and I found particularly interesting that pretty much all the issues they have with Erlang don't apply to Go often because of how Go avoided what might seem superficially like a 'feature' in favor of "raw" simplicity. Some of what they discuss simply isn't available in Go, like OTP, so I wouldn't count that as a "win" for Go. Other things like 'heart' are things I want, given that it's going to be for a semi-embedded system. That's a good video, but all languages have gotchas and things to watch out for, especially mature ones. Go has some advantages in a 'fresh start': some of the biggest Erlang warts are actually the language itself; the syntax, records, some things like that that are just kind of ugly. For a product currently in development, "should be solved by a future release" is probably too far in the future to matter much. "pretty good shape" sounds a bit worrisome for a semi-embedded device where updates via the internet are not necessarily going to be an easy proposition. 64bit is going to eat more memory, something we'd prefer to avoid if at all possible.

rbanffy 14y ago

Just out of curiosity, is anyone using Vala? I was asked to do a little bit of research into alternatives to build a cross-platform chat client and, along with the more obvious Java, C++/wx, Objective-C/OSX/GNUStep and C#/.NET/Mono stacks, I found Vala as a possible option.