8 ms·
Go turns three
- jgrahamc 14y agoCongratulations to everyone involved with Go. I've been loving using it and it's nice to see CloudFlare mentioned in that post as we are using Go more and more for our production systems.
- xorl 14y agoAgreed, I've been having a lot of fun with the language and have been using it more and more on a daily basis.
- lbarrow 14y agoWe've been playing around with Go where I work. The concurrency model is great, and the type/object/interface approach is pretty flexible. The language designers also succeeded in eliminating many of the pain points they felt with C/C++/Java: dependency bloat and compilation speed. My workflow with Go has more in common with an interpreted language than anything else. However, the lack of generics seems like a pretty bad oversight. It's annoying to rewrite common functional operations (e.g. map, reduce) over and over again with slightly different argument types (or sprinkling type casts all over your code).
- objclxt 14y agoThis is probably one of the most discussed things on the Go mailing list (golang-nuts, if anyone is interested). Unlike some other features (like exceptions, again something oft discussed) there seems to be some openness towards it, but also a desire to not introduce anything that would cause increased complexity without a similar or greater increase in value.
- lbarrow 14y agoGo's approach to exception handling has a greater impact on the way Go programs are written than the lack of generics. That said, I'm fine with the exception handling because it's obviously a conscious decision by the language designers, and it fits in with the spirit of the language. The lack of generics doesn't feel like that. It strikes me more as an oversight than anything else. This is especially true because some builtins (i.e. make) are generic functions -- they're just special, and you aren't allowed to make your own.
- azth 14y agoThere are some other oversights too: lack of immutability/const qualifier; nil pointers in the language; `defer` working at the function, rather than the scope level, etc. Even for error handling, why not use a sum/option type as several other languages use?
- millerm 14y agoRegarding nil references, I now always think of this Sir Charles Antony Hoare quote when the topic arises: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965."
- azth 14y agoSo he's saying he rejected declarations that allow you to declare either nullable or non-nullable types? Kotlin and Rust seem to have an interesting approach. In Kotlin, you have to explicitly declare nullable types, and Rust does not allow references/pointers to be null in the first place if I am not mistaken. I have just recently started learning more about Scala, and although it allows nulls to be passed, they are not idiomatic, and I am guessing it would not be too hard to have an automatic style checker that catches uses of null (at least those that do not interface to Java libraries).
- masklinn 14y agoNo, he's saying he now rejects references being nullable (as the default state of all reference types). A concept of "nothing here" is sometimes necessary so he probably doesn't reject explicit nullability annotations (option types as in Haskell, MLs or Rust for instance; this is not exactly an original approach either).
- 46Bit 14y agoSimilar feelings here, although I've only been playing with it for a week or so. As someone who grew up (literally) on interpreted languages, Go feels far more pleasant to code in than C/C++.
- naner 14y agoHowever, the lack of generics seems like a pretty bad oversight. The lack of generics was not an oversight but an explicit design decision.
- xahrepap 14y agoDo you have a link to a wiki page or blog post or anything that explains why they decided to omit generics?
- lbarrow 14y agohttp://golang.org/doc/go_faq.html#generics http://golang.org/doc/go_faq.html#generics
- xahrepap 14y agoThanks
- eternalban 14y agohttp://research.swtch.com/generic http://research.swtch.com/generic
- sigzero 14y agoMaybe he should have said the lack of generics was a mistake and needs to be corrected?
- irahul 14y ago> It's annoying to rewrite common functional operations (e.g. map, reduce) over and over again with slightly different argument types (or sprinkling type casts all over your code). Personally I would go with interface{} and type cast.
- burntsushi 14y agoThis isn't viable if it's a performance critical portion of your code. Idiomatic Go (currently) is to use a for loop for map and reduce/fold operations.
- irahul 14y ago> Idiomatic Go (currently) is to use a for loop for map and reduce/fold operations. There is going to be a for loop one way or the other. The question is n occurrences of for loop or one occurrence of for loop in a generic_map func followed by n-1 occurrences of call to generic_map and type casting. As for performance, function calls themselves incur a performance penalty. That doesn't necessitate putting all code inline. If the profiler says that interface{} and type casting incurs a significant performance penalty(it does incur a penalty but does it matter?), then I would go for inline for.
- diminish 14y agoFrom the upvotes, apparently Go has a lot of support on HN, and/or there are a lot of Googlers here. I am particularly curious about Go and Ceylon, 2 recent languages with strong corporate backing. Is anyone using Go in a startup? Congratulations to Go open source for 3rd year. Go Go!
- lbarrow 14y agoI work for Braintree -- we've been playing around with Go internally in the last two months, but no production system uses it yet. The language itself is pretty cool, but most of our work is still web application development (broadly defined). Go isn't particularly suited for that, and even if it were, it doesn't have a mature framework for doing webdev yet.
- burntsushi 14y ago> The language itself is pretty cool, but most of our work is still web application development (broadly defined). Go isn't particularly suited for that, and even if it were, it doesn't have a mature framework for doing webdev yet. Really? Web development is one of Go's strengths IMO, and the standard library was clearly designed with web development in mind. i.e., the HTML template library, the net/http library, etc. There are also a few third party frameworks out there. They may or may not be mature depending upon your definition, but gorilla looks promising.
- objclxt 14y agoSoundcloud use Go, as others have mentioned so do CloudFlare, Heroku use it for a few things...there's a list of production users here: http://go-lang.cat-v.org/organizations-using-go http://go-lang.cat-v.org/organizations-using-go Personally, I've used Go for some prototyping work internally. I thought it was a great language to write in. Sadly I haven't had a chance to do something in production with it myself yet! I've been keeping a close eye on Revel as well (http://robfig.github.com/revel/ http://robfig.github.com/revel/), which is a Play-like web framework under active development.
- 14y ago
- afhof 14y agoIts nice to see my name in the Contributors file. I found that submitting patches was easy and said patches were quickly reviewed. What isn't easy is reading and understanding the documentation. The jump between the Go tour and the Go docs is gaping. I wish some five star technical writers would take a look and fix it since I feel that is Go's biggest problem right now.
- kingfishr 14y agoReally? I feel pretty much the exact opposite way. I find the docs to be thorough, accurate, and concise.
- chime 14y agoI wish the docs included basic examples of how to use various packages and functions. I end up searching for golang packageX example instead. And often I end up on StackOverflow where someone else is using it wrong and ten others are trying to correct them.
- drivebyacct2 14y agohttp://gobyexample.com http://gobyexample.com
- drivebyacct2 14y agoI completely agree, but only after a good read of Effective Go and honestly the language spec. The language spec is documented and completely, completely readable. I have no doubt it's a result of the simplicity driven by the simple/fast compiler. Just seeing the examples get you in the Go states of mind and prepare you for the standard library. I do think that sometimes the more complex packages are aided by examples and I think the std lib could take on a few more examples. Fortunately, http://gobyexample.com http://gobyexample.com someone is already doing that.
- eikenberry 14y agoBetween The Go tour and the Go reference does is the Effective Go guide. It gets you going pretty well with lots of practical examples and patterns of how to do things in Go. http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html
- pjmlp 14y agoEven if I tend to criticize the decision to leave out generics, my congratulations to the Go team for their work.
- z3phyr 14y agoIn 2010, there was a poll between haskell and go. That time, haskell won.... Why not have this poll again?