15 ms·
Google’s Go has some coders raving
- elithrar 13y agoI'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.
- brown9-2 13y agoIt'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.
- obviouslygreen 13y agoIt's confusing why anyone would seek to blame a project's failure on the choice of programming language. The choice of language does have the potential to deep six a project; however, it's rarely something that can be blamed on the language itself. I've seen projects fail because of the language the chose for at least two reasons, but I think these two are the most obviously harmful: 1. Choosing a language that isn't just unsuitable, its design goals and tradeoffs should make it an obviously poor choice in terms of your requirements. 2. Choosing a language for use by a team that has no experience with it, no time to learn it, and/or lacks the discipline to learn it in sufficient depth to use it efficiently for the project's purposes. Again, these are not failures of any given language. They are, however, potential project-killers that are only possible based on the choice of programming language.
- rubinelli 13y agoWhat 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 http://gonuts.io or https://github.com/GPMGo/gopm https://github.com/GPMGo/gopm
- codygman 13y agoYeah, I saw the post about gonuts.io on the mailing list and wished the creator would have gotten a warmer welcome. Some valid points were brought up, but everyone seemed to be annoyed at him.
- whataaa 13y agoI like more Dart.
- andyhmltn 13y agoyou more need grammar learn
- bachback 13y agoMe build my own GRAMMERS! chomsky rulez.
- brightsize 13y agoIn Soviet Russia ....
- programminggeek 13y agoGo 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.
- shurcooL 13y agoI can't wait for that to happen. I might just get an Android device and start developing for it when it does. 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.
- chimeracoder 13y agoI'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.
- myko 13y agoYep! Brad Fitzpatrick posted an example of bundling a Go executable within an Android apk somewhat recently: https://plus.google.com/115863474911002159675/posts/DWmyygSrvt7 https://plus.google.com/115863474911002159675/posts/DWmyygSr...
- melling 13y agoConsidering that Dalvik isn't very fast, Go might be a much better solution on phones and tablets.
- beck5 13y agoThe thing I really miss about my C# days is the automated refactoring. How good are the available refactoring tools for golang?
- ominous_prime 13y agoI haven't seen any yet (though I would probably not be one to use them), but the language lends itself to the creation of such tools very well. Between the basics like fmt, and easy assess to the AST, I don't think it will be too long before more advanced tooling comes out from some of the larger organizations using go.
- mbell 13y agoThere 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. [0] https://github.com/mtoader/google-go-lang-idea-plugin https://github.com/mtoader/google-go-lang-idea-plugin
- jweir 13y agoI am not familiar with C#, but what Go does have is gofmt. This forces all Go code to be formatted and styled in a consisten manner. This not only solves readability issues, but makes all code consistent for machine reading and replacing. gofmt also supplies a pattern replace method, which is a bit more sophisticated than a regex search and replace. http://golang.org/cmd/gofmt/ http://golang.org/cmd/gofmt/
- kvb 13y agoRefactoring is not reformatting, nor are text replacement systems comparable. Refactoring allows you to keep program behavior the same while safely making structural changes to your code. Renaming is one simple example of this (where true refactoring tools are superior to textual find-and-replace because they understand which occurrences of an identifier are semantically identical). But there are many other useful refactoring operations, such as extracting a bit of logic into its own method, etc.
- shurcooL 13y agoThe 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. [1] e.g. https://gist.github.com/shurcooL/5571468 https://gist.github.com/shurcooL/5571468, https://gist.github.com/shurcooL/5504644 https://gist.github.com/shurcooL/5504644
- manuletroll 13y agoThat's very much my feeling too, it's the first time I feel like I'm really reusing a lot of my code.
- swalsh 13y agostupid question, but from your second example what does the _ do? in this line? "for _, "
- nuttendorfer 13y agoAFAIK the function returns to values but you only need name in this case, so _ discards that return value.
- troym 13y agoIt's the "blank identifier", a throw-away variable. See http://golang.org/ref/spec#Blank_identifier http://golang.org/ref/spec#Blank_identifier
- ominous_prime 13y ago"_" is when you must assign a value, but don't want to use it. range in the for loop return 2 values (index, value). If you don't want the index, you can assign it to "_" to ignore it. http://golang.org/ref/spec#Blank_identifier http://golang.org/ref/spec#Blank_identifier
- deleted 13y ago[deleted]
- tptacek 13y agoNo, you do not: package main import ( "os" "io/ioutil" ) func main() { f, _ := os.Open("/etc/ttys") buf, _ := ioutil.ReadAll(f) print(string(buf)) } Feed that to "go run". It'll work fine. Those two imports, by the way, are morally the same imports you gave .NET. It might be reasonable to argue that most files will need to import "fmt" (although the Damnable Use Requirement means you won't be importing it anywhere you don't need it), but I'm lost as to why you imported "strings", "bytes" ("strings" for raw arrays of bytes) or "bufio" (in all my Golang code only two files I have import "bufio").
- exch 13y agoEven shorter: package main import "io/ioutil" func main() { data, err := ioutil.ReadFile("/etc/ttys") ... println(string(data)) }
- sigzero 13y agoThere is one thing I hate. Go error handling.
- tptacek 13y agoIt is very explicit and C-like. If, like me, your favorite language is C, it's OK (I agree it's not optimal). If your favorite language has exceptions, it'll annoy you a lot.
- thezilch 13y agoWhy is that? Compared to? Is it worse than exceptions? f, err := os.Open("/etc/ttys") if err != nil { // handle `err` "f not found" } try: f = open("/etc/ttys") except IOError as err: // handle `err` "f not found" I hate having to sometimes reindent a block of code, not changing any part of the block, because I need to wrap it in a try/except. It really drives me crazy with my obsession to have a clean, revision history.
- fixxer 13y agoI am totally one of these ravers. 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 13y ago>Anyone prefer Scala to Go? 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 13y agoYes. 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.
- th0br0 13y agoAbsolutely. 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... [1] http://akka.io http://akka.io
- swah 13y agoIts hard to accept that Scala + Akka is something similar to what Go has going, one just seems so heavy and the other so light. Probably FUD.
- anon1385 13y agoI 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. [1] http://news.ycombinator.com/item?id=5750256 http://news.ycombinator.com/item?id=5750256
- fmstephe 13y agoI 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.
- tptacek 13y ago"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."
- hierro 13y agoThe 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.
- rsc 13y agoThanks for your contributions. I apologize that you've found it difficult. Just to respond to your points: 1. CLAs are a fact of life in open source to keep the lawyers happy (http://en.wikipedia.org/wiki/Contributor_License_Agreement http://en.wikipedia.org/wiki/Contributor_License_Agreement). We've tried to make it as simple as possible: you fill out one web form, we do the rest. And it's just once, not every time. So if you're already listed as a contributor, you're done with this forever. 2. You're free of course to prepare the code any way you want. We insist on the hg extension to manage the review of the patch, mainly because it makes our lives easier: there are a LOT more contributors than there are core Go team members doing code reviews. (And we don't just review; sometimes we even like to write our own code.) I hope using the tool isn't really too burdensome. Many people work with other things, like git in the same dir or hg in another dir, and then they copy the changes into their "review" tree. 3. This is a real problem. We don't have a good system for tracking these: so far we've just been letting everyone watch the same stream and deal with what needs dealing with. But the volume has gotten high enough that we are dropping too many incoming changes or bug reports on the floor. We're working on a new system to track incoming changes and bug reports and assign them to a clear owner so that everyone knows who is responsible for what. I hope this will go live soon.
- andrewljohnson 13y agoMake no mistake, Google developers often make great programming tools. It stems from a culture of engineering and dog-fooding. Some examples are AppEngine, Angular.js, Go, GWT, and Chrome Developer tools.
- adrianlmm 13y agoYou forgot to add Dart.
- alvivi 13y agoNo, he doesn't.
- digitalzombie 13y agoDart is a Programming Language like wise with Go. I don't get where he'sshe's going with his/her post though...
- bokglobule 13y agoI 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). Just my humble opinion..
- azth 13y agoScala has a small community? :)
- bokglobule 13y agoI guess it's how you look at it, but Indeed still shows very little movement over the last years with interest in Scala developers by businesses. Even compared to Go, it's very small. http://www.indeed.com/jobtrends?q=scala%2C++go&l= http://www.indeed.com/jobtrends?q=scala%2C++go&l=
- happy_dino 13y agoThe search term you chose looks really favourable to Go, but closer inspection reveals that it doesn't contain a single Go job. I think this is more accurate: http://www.indeed.com/jobtrends?q=scala%2C++golang http://www.indeed.com/jobtrends?q=scala%2C++golang Golang: 8 Jobs Scala: 1,434 Jobs
- venomsnake 13y agoCan golang do function decorators - I have been using it for some pet projects (nothing fancy) but could not find this so loved python feature there?
- supersillyus 13y agoYes, in the same sense that any language with first class functions can. So, like: var SomeFunc = RequireAuth(func(...) { ... }); However, there's no language-level support, so you can't decorate methods as easily as you might in a language like Python.
- WayneDB 13y agoGo 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". At least be consistent. http://golang.org/pkg/ http://golang.org/pkg/
- codygman 13y agoI'm guessing fmt is the odd one out because it's used a lot and clear that it means format. Of course by that logic, image should be img too.