I think the thing that amuses me most about the current Go hype is when people defend the language with statements along the lines of "it is supposed to be boring"[1]. Go is the new (old) Java and the arguments echo those of 15 years ago.
1) created for people less smart than the designers (even if not intentionally: maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer)
2) designed to be easy to use in a corporate environment with large teams of varying abilities (the 'simplicity', which is really more familiarity: most people can write boilerplate filled imperative C-family language style code already).
3) attempts to make certain types of errors harder than the languages it replaces (in Java thats memory errors, in Go it's concurrency errors), but by ignoring established PL research still gives you a big gun that is loaded and aimed at your foot (doing concurrency in Java with threads and locks, NULL and deadlocks in Go, etc). i.e. very conservative when it comes to adopting PL ideas, but perhaps bringing one old idea to the mainstream, and being prepared to make a lot of sacrifices (to ensure an 'easy' language) to get people on board with that one idea.
The amusing thing is that the creators of Go are some of the fiercest critics of Java, but they have created something that seems to follow a very similar philosophy to the original Java. I guess it remains to be seen if Go will have added as many features in 15 years time as Java has in the last 15.
I don't mean this as a slight against Go (or Java!). I just find the comparison illuminating.
> maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer
The reasons that Go doesn't have generics are well documented and discussed (continually) on golang-nuts. Basically, the designers feel none of the existing generics implementations are adequate. They claim that if and when a better solution is devised, they're open to using it.
I don't know why you're accusing them of shielding users from generics, unless you think they're being disingenuous.
"I don't mean this as a slight against Go, or Java. I'm just saying it's made for people of a certain level of intelligence and designed for use at giant corporations."
We created Go first and foremost for ourselves. Go is the language we want to be (and are) writing programs in. I haven't had this much fun writing programs in a long time.
It is emphatically NOT true that Go is "created for people less smart than the designers". At no point during any design discussion did we say "well, that will be too difficult for the average programmer".
The part about "large teams of varying abilities" is not true either. What is true is that Go was designed for large-scale programming, though, and the things that work in a 100-line Haskell pearl don't necessarily scale to million-line programs. Rob Pike gave a talk about this at SPLASH titled "Go at Google: Language Design in the Service of Software Engineering" [1]. I highly recommend it if you want to see where we're coming from with some of the design.
Your third point is certainly true, but I can't think of a decent language that doesn't attempt to make certain types of errors harder than the languages it replaces.
my rant re: generics, I wish people would read through the documentation (FAQ) and discussion of this first.
The language designers have not ruled out generics, and are fully open to providing them at some point. The issue is that they have yet to find an implementation that fits within the language design goals.
Yes, if you jump on the mailing list, and propose that they somehow "use" .NETs generics, and you actually have no idea how that would be implemented, or impact the compiler and runtime, you're not going to be greeted cordially. This happens fairly frequently, and is probably why people think the community is totally against generics.
The Go team wants generics, when they find the right way to handle them within the language. In the meantime, most heavy users seem to agree that lack of generics is better than poor generics.
Gosling himself said that scripting projects were always fun and fast, but when the job got large only static languages made sense (paraphrasing). This definitely echos my experience. The only way I've been able to manage large scripting projects is by building a quasi static type system - the strictest conventions allow you to decrease cognitive wait substantially.
What I find amusing lately is the exodus from Ruby over to Javascript. What's the thought there - maybe there weren't enough braces? Maybe THIS time, this scripting language will work! What valiant hope.
According to Rob Pike the lack of features is a feature (less is more) not a way to appease to the fictional 'average programmer' in the PL designers imagination. So I don't know where do you get the idea that go is meant to be used by 'lesser minds'.
IIRC Rob Pike was hacking away in C++ and the some guys from C++1x comite came to google to show C++'s new features. And he thought to himself: "Really you really think the problem with C++ is not enough features?"
Go and Java are both opinionated languages, and the first release of Java was a small language, but the opinions they embody are quite different.
I think the advocates of Go who say "it is supposed to be boring" are giving a mistaken impression. Java was "talking down" to replaceable cog programmers, by having "one way to do it" that fronts the then-popular inheritance based OO, and syntax that spells everything out. Go is "talking up" to a programmer who is expected to want to see the algorithm in stark brush strokes against an uncluttered page, by having "one way to do it" that fronts the imperative algorithm and very light very regular syntax that doesn't obtrude. Go is not for people who want to program the language (try Haskell or a lisp). Go is for people who want to program the program.
I agree, Go seems designed to solve a lot of the same problems with C/C++ that Java was designed to solve. That's probably why the creators of Go are fierce critics of Java, because Go is meant to replace Java (which was meant to replace C/C++). They operate in the same problem space, so they're going to be competitors.
I fail to recognize the world from which your comment seemingly comes.
Reducing the mental load of a programming language has nothing to do with how "smart" anyone is, it's about making everyone more productive. Otherwise, the smartest programmers would all be clamoring to use C++.
I think a much better comparison is with C. C, similarly, has a paucity of features. It is also relatively easy to grasp its core. However, this has never prevented C from being used to build very powerful applications.
I would like to know exactly what the established programming language research is. My strong impression is that if there was ever anything that was not established it was 'how to build the best programming language'. Not trolling, just asking for clarification on that point.
> maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer
I believe I heard that Gosling did want to have first-class functions initially in Java, but they just ran out of time.
Go, of course, does have closures like almost all modern languages. The lack of generics does stymy what you can express statically with higher-order functions, but it does have them.
Have you read Rob Pike's post here [1]? I wonder if your post is made with that knowledge in mind or without, and whether it'd change your perception in any way.
>Go is the new (old) Java and the arguments echo those of 15 years ago.
I don't think anybody (that is, more than a few outliers) said anything about Java being "boring" back then. It's in the last 5-7 years, after J2EE came out of favour, that is in vogue to say these kind of things. And I know that, because I was around back then. Java was supposed to be safer, yes, but nobody said it was supposed to be boring or targeted to enterprise drones. On the contrary, it was deemed "revolutionary" and the language of the rich web (because of applets).
>1) created for people less smart than the designers
Well, most programmers are indeed less smart than Ken Thompson or Rob Pike, so that would be a good call IF it was true.
But from what I have read, it was created to be the perfect language FOR it's designers, scratching THEIR pain points -- not targeted to some inferior programmers. And it's designers were and are are very fond of the language and heavy users of it.
So, I don't see where you got your (1) point.
>2) designed to be easy to use in a corporate environment with large teams of varying abilities (the 'simplicity', which is really more familiarity: most people can write boilerplate filled imperative C-family language style code already).
Who said Go is about 'boilerplate'? One of the design goals was to reduce boilerplate, and in practice it's very succint, eg. to get the same thing going, compared to Python code.
>3) attempts to make certain types of errors harder than the languages it replaces (in Java thats memory errors, in Go it's concurrency errors), but by ignoring established PL research still gives you a big gun that is loaded and aimed at your foot (doing concurrency in Java with threads and locks, NULL and deadlocks in Go, etc). i.e. very conservative when it comes to adopting PL ideas, but perhaps bringing one old idea to the mainstream, and being prepared to make a lot of sacrifices (to ensure an 'easy' language) to get people on board with that one idea.
So, in essence, it's not a hodgepodge of newfangled PL research like Haskell. Sounds good to me.
>The amusing thing is that the creators of Go are some of the fiercest critics of Java, but they have created something that seems to follow a very similar philosophy to the original Java.
Well, they are not critics of the original Java. Matter of fact, some of them have also programmed lots of in Java in the past.
>I don't mean this as a slight against Go (or Java!). I just find the comparison illuminating.
1&2: Since you are using my comment as a reference, let me first declare that Java (not Go, though I have been using it for a while now) is my everyday language. You seem to point out that "a boring language" is designed for lesser programmers. And Java started out as one(just like Go has).
But let's step back and explore "boring" here. When I talk about Go being boring, I mean the specs of the language are boring. In contrast, Java has a pretty exciting spec while the code itself is boring.These two are worlds apart. Go promotes a "boring" spec to write smarter code[1]. Like Python, the focus is on expressiveness rather than on features(standard library features).It reduces the cognitive overhead so that you can "program" more.
3) Neither Go's concurrency patterns nor the avoidance of concurrency errors(or non-determinism of code execution)is anything new. It's based on more than 30 years of research including Unix pipes, Hoare's CSP. The patterns Go follows is not conservative at all! It still follows the same PL ideas you are talking about(or not talking about). If you are looking for the gun it's still there[2]. The wrapper around concurrency is not a protection but an enhancement so that the code can focus more on project logic. And still the wrapper is sometimes not enough to avoid mutilating your foot. I don't think Go inventors had that in mind while designing the patterns. Also Go too handles memory management(yes, just like Java).
Your comparison is based on incorrect hypothesis. I can hardly see the illumination. Let's just say Go is a fresh new programming paradigm and it would be hasty to jump to conclusions without exploring it a bit more.
> The amusing thing is that the creators of Go are some of the fiercest critics of Java, but they have created something that seems to follow a very similar philosophy to the original Java. I guess it remains to be seen if Go will have added as many features in 15 years time as Java has in the last 15.
Funny you should say that, because IIRC they also have stated that one of the reasons they are so skeptical of adding features to the language is that Java started out as nice and simple language that was a great alternative to what was available at the time, and that they don't want to repeat the mistakes of what happened after that.
"1) created for people less smart than the designers..."
This one doesn't hold up to inspection. The indications are that Google intended to use it in house. If nothing else can be said about Google, they do believe they are smart.
> "The issue for PHP and even Node.js is obviously you're trapped in a single-threaded situation and what I really wanted was to be able to do a lot of things concurrently,"
Remember "Node.js is cancer"? Remember how the Node.js fanboys would bully programmers on social media who critiqued it? At no point have I seen Go programmers hype up the language and attack others.
I sincerely hope the "brogrammers" and "hackers" who beat their chest about Rails and Node.js and whatever framework was/is flavor of the day, do not start using Go.
They will be a negative force in the community and it will be sickening to see them pump up the hype and declare themselves as champions of Go.
The main reason I love Go is because it makes me feel like the more I use it, the more I'm able to do and get it done faster. When I solve a given problem, it's solved for all my current and future projects written in Go.
When I was working with C++ earlier, that was not really the case. After spending many years with it, I couldn't write a simple web server in under 5 minutes. Making something into a library had too much overhead. In Go, once I've done something [1], the next time it's one line to import it.
Also, working with the language programmatically is a pleasure. There's a full parser in the standard library.
I'm still a little confused as to why Haunts keeps getting used as an example of Go "failing". As discussed in other Go-related comment threads, the project would have likely failed with any language, not just because Go doesn't have a version pinning package manager.
It's confusing why anyone would seek to blame a project's failure on the choice of programming language.
The presence of this anecdote in the article seems to fulfill some sort of journalistic requirement to balance any positive stories with criticism as well, to be in the center. It doesn't make a lot of sense when writing about programming languages.
What baffles me isn't the lack of a version pinning package manager, but that a significant portion of the Go community actively criticizes projects trying to implement them, like http://gonuts.io or https://github.com/GPMGo/gopm
Go has always looked interesting to me, but I don't understand why Google hasn't put go on Android yet. It seems like a better long term solution for Google than Java is for just about everything, but maybe it's not.
I've asked this question of a number of core Go contributors.
First, I should point out that you CAN currently run Go programs on an Android device. You just can't take advantage of the SDK and make GUI-based applications, etc.[0]
Basically, the answer is that nothing's preventing anybody (including you and me) from doing so, except the fact that we would have to wrap the entire NDK and make it available/usable through Go.
That's not any more difficult to do in Go than it is to do in Java, but it's a massive amount of work which has already been solved for Java, so there's little incentive to recreate it in Go.
(I'm paraphrasing, so my answer may be slightly wrong, but hopefully you get the idea - perhaps @enneff can give a more complete answer).
[0] You can, however, bundle them as hybrid applications, because Android applications apparently allow bundling of arbitrary binaries, from what I've been told.
If Google offers official support for a second language on Android, it will almost certainly be another JVM based language like Scala or (my personal dream) Clojure. They can already be used to write native apps, and would allow Google to continue to use Dalvik and the all the tooling surrounding it, which they've invested a tremendous amount of resources in.
The only things that really bothers me about Go is how difficult is to contribute a patch (even when I'm listed as a contributor). First, you have to sign an agreement to give an unlimited license to Google to use your code as they see fit, then you have to use a special HG extension to get your patches uploaded to codereview.google.com (which disables branches/commits/etc, and doesn't let you submit multiple patches affecting the same files) and, finally, the patches may sit in review for a few weeks until someone from the core dev team takes a look at them.
Go is the right language for the right time: easy enough for the Python people (like me) to pick up quickly, but with a concurrency model that makes taking advantage of multi-core very easy.
Yes, very much so. I love being able to keep so much of the state in the type system, freeing my attention for more important things; it also (ironically?) lets me write much more dynamic-feeling code by using "typeclasses" to supply varying implementations for an operation. I don't realise how much I depend on it until I try to go back to other languages. Go has some useful standard types and a good story in place for some other generic type use cases, but if you need a (generic) type that the language designers didn't think of (and e.g. even Option is missing), you're stuffed.
Yes. Not sure how much I feel like talking about generics and error handling again, but those are the first two reasons. I can respect them wanting error conditions to be explicit, but then they give you no acceptable way of dealing with them -- perhaps because proven techniques from the functional world would require parametric polymorphism, or yet more built-ins from the language designers.
Absolutely.
Each time I try to move away from Scala, I always notice the lack of functional features in most other languages + a type system that's as strong as Scala's.
Most importantly, with Akka([1]) you have an awesome concurrency framework that comes with lots of features out of the box.
However, for many client-side applications, Go's lack of the JVM is a huge plus...
Go is awesome, and I'd love an excuse to use it in production. The problem is that being a young language, there aren't many libraries, and the ones that do exist are often at very early stages at best too. That means when you need a library to solve problems like printing a PDF, you are out of luck.
The other thing that makes me a bit nervous about using it in production is the idea of linking to the latest/head version of a dependency. Maybe I just don't properly understand the paradigm though.
Those nits aside, I believe Go has bright future and within 2 years will be mainstream. Meanwhile, Scala is better suited for projects that need lots of libraries and mature tooling.
You can pry the super powerful type system, functional programming support, monad comprehensions, library ecosystem, IDE support from my cold dead hands :D
There is some support via a plugin [0] for JetBrains Idea. I also wouldn't be surprised to see JetBrains put some internal effort into supporting Go, from what I've heard Idea is pretty popular within Google and they just switched their Android Studio over to an Idea base.
I wonder if Go will be similar to Scala where it arrives to solve issues with Java (or C++). I found that although Scala is a nice language in many ways, the smallness of the community prevented me from adopting it big time for most work. The same holds true for languages like F#. They're fine for special cases (likely what Google intended with Go), but won't be a general purpose replacement for more mainstream languages without some huge advance in support (like what the Rails team did for the Ruby language).
Go is alright, but I don't understand their naming convention for packages. Why "fmt" instead of "format"?
OK, I guess they think abbreviations are useful...but then they went with "database" instead of "db", "encoding" instead of "enc" and "image" instead of "img".
[+] [-] anon1385|13 years ago|reply
1) created for people less smart than the designers (even if not intentionally: maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer)
2) designed to be easy to use in a corporate environment with large teams of varying abilities (the 'simplicity', which is really more familiarity: most people can write boilerplate filled imperative C-family language style code already).
3) attempts to make certain types of errors harder than the languages it replaces (in Java thats memory errors, in Go it's concurrency errors), but by ignoring established PL research still gives you a big gun that is loaded and aimed at your foot (doing concurrency in Java with threads and locks, NULL and deadlocks in Go, etc). i.e. very conservative when it comes to adopting PL ideas, but perhaps bringing one old idea to the mainstream, and being prepared to make a lot of sacrifices (to ensure an 'easy' language) to get people on board with that one idea.
The amusing thing is that the creators of Go are some of the fiercest critics of Java, but they have created something that seems to follow a very similar philosophy to the original Java. I guess it remains to be seen if Go will have added as many features in 15 years time as Java has in the last 15.
I don't mean this as a slight against Go (or Java!). I just find the comparison illuminating.
[1] http://news.ycombinator.com/item?id=5750256
[+] [-] freyr|13 years ago|reply
The reasons that Go doesn't have generics are well documented and discussed (continually) on golang-nuts. Basically, the designers feel none of the existing generics implementations are adequate. They claim that if and when a better solution is devised, they're open to using it.
I don't know why you're accusing them of shielding users from generics, unless you think they're being disingenuous.
[+] [-] tptacek|13 years ago|reply
[+] [-] rsc|13 years ago|reply
We created Go first and foremost for ourselves. Go is the language we want to be (and are) writing programs in. I haven't had this much fun writing programs in a long time.
It is emphatically NOT true that Go is "created for people less smart than the designers". At no point during any design discussion did we say "well, that will be too difficult for the average programmer".
The part about "large teams of varying abilities" is not true either. What is true is that Go was designed for large-scale programming, though, and the things that work in a 100-line Haskell pearl don't necessarily scale to million-line programs. Rob Pike gave a talk about this at SPLASH titled "Go at Google: Language Design in the Service of Software Engineering" [1]. I highly recommend it if you want to see where we're coming from with some of the design.
Your third point is certainly true, but I can't think of a decent language that doesn't attempt to make certain types of errors harder than the languages it replaces.
[1] http://talks.golang.org/2012/splash.article
[+] [-] ominous_prime|13 years ago|reply
The language designers have not ruled out generics, and are fully open to providing them at some point. The issue is that they have yet to find an implementation that fits within the language design goals.
Yes, if you jump on the mailing list, and propose that they somehow "use" .NETs generics, and you actually have no idea how that would be implemented, or impact the compiler and runtime, you're not going to be greeted cordially. This happens fairly frequently, and is probably why people think the community is totally against generics.
The Go team wants generics, when they find the right way to handle them within the language. In the meantime, most heavy users seem to agree that lack of generics is better than poor generics.
[+] [-] smrtinsert|13 years ago|reply
What I find amusing lately is the exodus from Ruby over to Javascript. What's the thought there - maybe there weren't enough braces? Maybe THIS time, this scripting language will work! What valiant hope.
[+] [-] PuercoPop|13 years ago|reply
IIRC Rob Pike was hacking away in C++ and the some guys from C++1x comite came to google to show C++'s new features. And he thought to himself: "Really you really think the problem with C++ is not enough features?"
[+] [-] JulianMorrison|13 years ago|reply
I think the advocates of Go who say "it is supposed to be boring" are giving a mistaken impression. Java was "talking down" to replaceable cog programmers, by having "one way to do it" that fronts the then-popular inheritance based OO, and syntax that spells everything out. Go is "talking up" to a programmer who is expected to want to see the algorithm in stark brush strokes against an uncluttered page, by having "one way to do it" that fronts the imperative algorithm and very light very regular syntax that doesn't obtrude. Go is not for people who want to program the language (try Haskell or a lisp). Go is for people who want to program the program.
[+] [-] kyllo|13 years ago|reply
[+] [-] nknighthb|13 years ago|reply
Reducing the mental load of a programming language has nothing to do with how "smart" anyone is, it's about making everyone more productive. Otherwise, the smartest programmers would all be clamoring to use C++.
[+] [-] fmstephe|13 years ago|reply
I would like to know exactly what the established programming language research is. My strong impression is that if there was ever anything that was not established it was 'how to build the best programming language'. Not trolling, just asking for clarification on that point.
[+] [-] munificent|13 years ago|reply
I believe I heard that Gosling did want to have first-class functions initially in Java, but they just ran out of time.
Go, of course, does have closures like almost all modern languages. The lack of generics does stymy what you can express statically with higher-order functions, but it does have them.
[+] [-] shurcooL|13 years ago|reply
[1] http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...
[+] [-] coldtea|13 years ago|reply
I don't think anybody (that is, more than a few outliers) said anything about Java being "boring" back then. It's in the last 5-7 years, after J2EE came out of favour, that is in vogue to say these kind of things. And I know that, because I was around back then. Java was supposed to be safer, yes, but nobody said it was supposed to be boring or targeted to enterprise drones. On the contrary, it was deemed "revolutionary" and the language of the rich web (because of applets).
>1) created for people less smart than the designers
Well, most programmers are indeed less smart than Ken Thompson or Rob Pike, so that would be a good call IF it was true.
But from what I have read, it was created to be the perfect language FOR it's designers, scratching THEIR pain points -- not targeted to some inferior programmers. And it's designers were and are are very fond of the language and heavy users of it.
So, I don't see where you got your (1) point.
>2) designed to be easy to use in a corporate environment with large teams of varying abilities (the 'simplicity', which is really more familiarity: most people can write boilerplate filled imperative C-family language style code already).
Who said Go is about 'boilerplate'? One of the design goals was to reduce boilerplate, and in practice it's very succint, eg. to get the same thing going, compared to Python code.
>3) attempts to make certain types of errors harder than the languages it replaces (in Java thats memory errors, in Go it's concurrency errors), but by ignoring established PL research still gives you a big gun that is loaded and aimed at your foot (doing concurrency in Java with threads and locks, NULL and deadlocks in Go, etc). i.e. very conservative when it comes to adopting PL ideas, but perhaps bringing one old idea to the mainstream, and being prepared to make a lot of sacrifices (to ensure an 'easy' language) to get people on board with that one idea.
So, in essence, it's not a hodgepodge of newfangled PL research like Haskell. Sounds good to me.
>The amusing thing is that the creators of Go are some of the fiercest critics of Java, but they have created something that seems to follow a very similar philosophy to the original Java.
Well, they are not critics of the original Java. Matter of fact, some of them have also programmed lots of in Java in the past.
>I don't mean this as a slight against Go (or Java!). I just find the comparison illuminating.
Well, you sure sound like you do.
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
[+] [-] realrocker|13 years ago|reply
But let's step back and explore "boring" here. When I talk about Go being boring, I mean the specs of the language are boring. In contrast, Java has a pretty exciting spec while the code itself is boring.These two are worlds apart. Go promotes a "boring" spec to write smarter code[1]. Like Python, the focus is on expressiveness rather than on features(standard library features).It reduces the cognitive overhead so that you can "program" more. 3) Neither Go's concurrency patterns nor the avoidance of concurrency errors(or non-determinism of code execution)is anything new. It's based on more than 30 years of research including Unix pipes, Hoare's CSP. The patterns Go follows is not conservative at all! It still follows the same PL ideas you are talking about(or not talking about). If you are looking for the gun it's still there[2]. The wrapper around concurrency is not a protection but an enhancement so that the code can focus more on project logic. And still the wrapper is sometimes not enough to avoid mutilating your foot. I don't think Go inventors had that in mind while designing the patterns. Also Go too handles memory management(yes, just like Java).
Your comparison is based on incorrect hypothesis. I can hardly see the illumination. Let's just say Go is a fresh new programming paradigm and it would be hasty to jump to conclusions without exploring it a bit more.
[1]http://commandcenter.blogspot.in/2012/06/less-is-exponential... [2]http://golang.org/pkg/sync/
P.S: I don't program in Java by choice. Android Developer. Edit: language
[+] [-] vanderZwan|13 years ago|reply
Funny you should say that, because IIRC they also have stated that one of the reasons they are so skeptical of adding features to the language is that Java started out as nice and simple language that was a great alternative to what was available at the time, and that they don't want to repeat the mistakes of what happened after that.
[+] [-] mtdewcmu|13 years ago|reply
This one doesn't hold up to inspection. The indications are that Google intended to use it in house. If nothing else can be said about Google, they do believe they are smart.
[+] [-] 0xdeadbeefbabe|13 years ago|reply
Golang also differs from Java in some obvious low level ways.
[+] [-] bangkoknights|13 years ago|reply
Remember "Node.js is cancer"? Remember how the Node.js fanboys would bully programmers on social media who critiqued it? At no point have I seen Go programmers hype up the language and attack others.
I sincerely hope the "brogrammers" and "hackers" who beat their chest about Rails and Node.js and whatever framework was/is flavor of the day, do not start using Go.
They will be a negative force in the community and it will be sickening to see them pump up the hype and declare themselves as champions of Go.
[+] [-] columbus1492|13 years ago|reply
[deleted]
[+] [-] shurcooL|13 years ago|reply
When I was working with C++ earlier, that was not really the case. After spending many years with it, I couldn't write a simple web server in under 5 minutes. Making something into a library had too much overhead. In Go, once I've done something [1], the next time it's one line to import it.
Also, working with the language programmatically is a pleasure. There's a full parser in the standard library.
[1] e.g. https://gist.github.com/shurcooL/5571468, https://gist.github.com/shurcooL/5504644
[+] [-] manuletroll|13 years ago|reply
[+] [-] swalsh|13 years ago|reply
"for _, "
[+] [-] elithrar|13 years ago|reply
[+] [-] brown9-2|13 years ago|reply
The presence of this anecdote in the article seems to fulfill some sort of journalistic requirement to balance any positive stories with criticism as well, to be in the center. It doesn't make a lot of sense when writing about programming languages.
[+] [-] rubinelli|13 years ago|reply
[+] [-] programminggeek|13 years ago|reply
[+] [-] tptacek|13 years ago|reply
[+] [-] chimeracoder|13 years ago|reply
First, I should point out that you CAN currently run Go programs on an Android device. You just can't take advantage of the SDK and make GUI-based applications, etc.[0]
Basically, the answer is that nothing's preventing anybody (including you and me) from doing so, except the fact that we would have to wrap the entire NDK and make it available/usable through Go.
That's not any more difficult to do in Go than it is to do in Java, but it's a massive amount of work which has already been solved for Java, so there's little incentive to recreate it in Go.
(I'm paraphrasing, so my answer may be slightly wrong, but hopefully you get the idea - perhaps @enneff can give a more complete answer).
[0] You can, however, bundle them as hybrid applications, because Android applications apparently allow bundling of arbitrary binaries, from what I've been told.
[+] [-] shurcooL|13 years ago|reply
I think it will happen eventually. The language is new, but it's having a lot of success and spreading both within Google and outside.
[+] [-] gw|13 years ago|reply
[+] [-] melling|13 years ago|reply
[+] [-] hierro|13 years ago|reply
[+] [-] fixxer|13 years ago|reply
Go is the right language for the right time: easy enough for the Python people (like me) to pick up quickly, but with a concurrency model that makes taking advantage of multi-core very easy.
Anyone prefer Scala to Go?
[+] [-] lmm|13 years ago|reply
Yes, very much so. I love being able to keep so much of the state in the type system, freeing my attention for more important things; it also (ironically?) lets me write much more dynamic-feeling code by using "typeclasses" to supply varying implementations for an operation. I don't realise how much I depend on it until I try to go back to other languages. Go has some useful standard types and a good story in place for some other generic type use cases, but if you need a (generic) type that the language designers didn't think of (and e.g. even Option is missing), you're stuffed.
[+] [-] quatrevingts|13 years ago|reply
[+] [-] th0br0|13 years ago|reply
[1] http://akka.io
[+] [-] matrix|13 years ago|reply
The other thing that makes me a bit nervous about using it in production is the idea of linking to the latest/head version of a dependency. Maybe I just don't properly understand the paradigm though.
Those nits aside, I believe Go has bright future and within 2 years will be mainstream. Meanwhile, Scala is better suited for projects that need lots of libraries and mature tooling.
[+] [-] digitalzombie|13 years ago|reply
I'd choose Ada or Rust over Go.
For concurrency I'd choose Erlang or Rust over Go.
If it's Node.js or Go. I guess I'll choose Go.
[+] [-] zohebv|13 years ago|reply
You can pry the super powerful type system, functional programming support, monad comprehensions, library ecosystem, IDE support from my cold dead hands :D
[+] [-] papsosouid|13 years ago|reply
Yes, by a huge margin. I rank my preferences like so:
derp languages (go lives here) < scala < ocaml/F# < haskell
But that doesn't make it clear how huge the distance is between the derps and scala.
[+] [-] beck5|13 years ago|reply
[+] [-] mbell|13 years ago|reply
[0] https://github.com/mtoader/google-go-lang-idea-plugin
[+] [-] andrewljohnson|13 years ago|reply
Some examples are AppEngine, Angular.js, Go, GWT, and Chrome Developer tools.
[+] [-] bokglobule|13 years ago|reply
Just my humble opinion..
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] venomsnake|13 years ago|reply
[+] [-] supersillyus|13 years ago|reply
So, like:
However, there's no language-level support, so you can't decorate methods as easily as you might in a language like Python.[+] [-] WayneDB|13 years ago|reply
OK, I guess they think abbreviations are useful...but then they went with "database" instead of "db", "encoding" instead of "enc" and "image" instead of "img".
At least be consistent.
http://golang.org/pkg/
[+] [-] whataaa|13 years ago|reply