We've just started using Go as well. It smokes our Python app in terms of speed, and is fun to use (maybe just because it's new?).
I have always wondered, however, that if moving to a new language seems great because of the language, or because you have such a better understanding of the implementation of the problem you are trying to solve.
New is fun. Exploration is fun. I think a lot of people will swear by a new language simply because it's not old and probably doesn't suffer many of the same deficiencies they're used to in their "every day," language.
This to me is an illusion however. One must remain skeptical and treat new, untested languages with even more scrutiny than an old one. Many of these new languages will make extraordinary claims. Discovering the evidence to support these claims is often left as an exercise to the programmer.
That being said, new has a lot of advantages. It's free to try to break away from past paradigms that perhaps limited programmers. Stability can always come later once the core ideas have been fleshed out. And it's always fun to work on fresh ideas rather than refining the same old ones that we're plagued with.
Personally I wouldn't use a language and compiler that only just reached 1.0 this year in a production system. If I was really interested in Go I'd certainly hack with it and perhaps on it, but I wouldn't trust it to be reliable. Maybe that makes me an old, stodgy fart but I trust wisdom over brilliance when it comes to building systems that are dependable and robust.
Go also works very well at STARTeurope, powering our event-platform http://startuplive.in/
Developing a high level webframework from scratch just for one website was a bit of a crazy undertaking: https://github.com/ungerik/go-start
(sorry, the documentation needs a big update and a tutorial. Most time was spent on running stuff and shipping features...).
I'm still a bit of a novice, could someone elaborate on what he means by operator overloading being "problem creating?" I thought that was one of the main, 'core' concepts of OOP. Inheritance, and polymorphism.
How would you make something like a GUI without being able to specialize classes by overriding certain methods?
The argument is roughly that it is, in fact, not very useful, while opening up a vast array of misuses - especially in the domain of being all too clever. What does "+" mean on a list and an object? Add, probably. But what if it's two lists? Union? Or add the second list as the last element to the first? Named functions "add" and "union" aren't any less readable and loads more descriptive.
The only situation you positively need operator overloading is when doing arithmetic, and you should do that using the built in types. This, of course, sucks when the built in types are inadequate, and you e.g. want to use a arbitrary precision library such as BigDecimal in Java.
This, of course, is an opinion, and I'm not shy to admit it's been shaped by being burned by Lift, the Scala web framework which makes heavy use of symbolic function names which makes it incredibly difficult to talk about or search for answers online.
His point is that, if you aren't familiar with the code, operator overloading can be difficult to read. It gives objects the appearance of being native types, and it is sometimes not entirely clear what the result of the overload might be. What does "dog + cat" equal? In an extreme example, if you are crazy enough, it might make sense to have animal + animal = baby animal. You need to temper that example down to something closer to reality :)
I personally like overloading, but I think it's probably too easy to abuse, and I can see how it would cause problems with a team size larger than 5.
As far as I can see, whenever the Go team encountered a language feature that could possibly be abused, they always deferred to leaving it out. Whether that is good or bad I'm not sure we will know until we have years of experience with it.
I haven't seen a GUI written in Go yet, but the basic idea is that you don't customize via inheritance; you do it in a different way. For example, in many UI libraries, you can create a function and ask a widget to call you when you receive an event; the widget will have methods like:
addClickHandler(myFunction)
Any customization you could do with inheritance could be done with a callback function instead, provided that the object has the hook you want.
In Go, there is also an "interface" which is basically a set of methods.
Yes, I think you misunderstood. You are thinking of overriding methods, which is very important. Operator overloading is where you redefine the behavior of a "+" symbol, for example.
What sort of development environment are others here using for go (if using it at all, of course) ? I've had reasonably good experience with the go-mode in emacs.
I'm using vim with the vim plugins that come in go/misc/vim. I use :Import and :Drop for adding and removing imports, and :Fmt to run gofmt in vim. I also have a git pre-commit hook that runs gofmt.
I'm one of the project owners on the GoClipse project. I do a lot of polyglot development (Java, Javascript, C, Go, & a little Python). I've used and liked vim, Sublime w/ GoSublime, and GoClipse. All with gocode. I have a hard time escaping Eclipse, in general, because of my skill profile. It kind of unifies the experience.
I use Acme, simply because it's got good buffer management and a useful editing language. I also used go-mode about a year ago, before I got sick of emacs.
LiteIDE X (http://code.google.com/p/liteide) is a small, portable IDE for Go with package management, build management, and compilation from within the IDE. Also, light debugging support. And, OSS, of course. I've used it on smallish Go projects without problems.
Nowadays, polyglot approach is the only right path for a software company. When I arrived in Berlin a month ago, I was positively surprised that SoundCloud supports local Clojure or functional programming groups. Keep up with great work!
The usual text editor features, like templates, reduce the typing, but the point is that the programmer must think, each time, about what they want to do when a function fails. This can become either a really good habit, or a distraction, depending on your perspective and problem domain.
When people say Go poor or no error handling, this is probably what they are complaining about. The fundamental properties offered by try/catch/throw are unpacked by Go into defer, recover and multiple value returns and type switches. Go's designers make the argument that when used thoughtlessly, exceptions encourages error handling antipatterns.
Go doesn't "lack error-handling." They're referring to the fact that Go doesn't have exceptions; you check return codes to detect and handle errors. For some this is tedious, but has advantages (mentioned in the article) with respect to understanding an entire program.
it's not there there's no error handling; it's that there's no exceptions. Instead, you use multiple return values, one of which is an error, and you check the return value for an error. It forces you to handle errors at the call site and makes diapers unimplementable.
is this from looking at their jobs page? because usually those 'requirements' are just guidelines to make sure the people applying know their stuff, and if you contact the company it turns out they're a little more flexible.
[+] [-] anon01|13 years ago|reply
I have always wondered, however, that if moving to a new language seems great because of the language, or because you have such a better understanding of the implementation of the problem you are trying to solve.
[+] [-] agentultra|13 years ago|reply
New is fun. Exploration is fun. I think a lot of people will swear by a new language simply because it's not old and probably doesn't suffer many of the same deficiencies they're used to in their "every day," language.
This to me is an illusion however. One must remain skeptical and treat new, untested languages with even more scrutiny than an old one. Many of these new languages will make extraordinary claims. Discovering the evidence to support these claims is often left as an exercise to the programmer.
That being said, new has a lot of advantages. It's free to try to break away from past paradigms that perhaps limited programmers. Stability can always come later once the core ideas have been fleshed out. And it's always fun to work on fresh ideas rather than refining the same old ones that we're plagued with.
Personally I wouldn't use a language and compiler that only just reached 1.0 this year in a production system. If I was really interested in Go I'd certainly hack with it and perhaps on it, but I wouldn't trust it to be reliable. Maybe that makes me an old, stodgy fart but I trust wisdom over brilliance when it comes to building systems that are dependable and robust.
[+] [-] pjmlp|13 years ago|reply
Like any other compiled language would do.
[+] [-] laktek|13 years ago|reply
(Yes, I will commit to finish the rest of the series)
[+] [-] ungerik|13 years ago|reply
[+] [-] ungerik|13 years ago|reply
[+] [-] goostavos|13 years ago|reply
How would you make something like a GUI without being able to specialize classes by overriding certain methods?
Have I misunderstood his point?
[+] [-] mseebach|13 years ago|reply
The only situation you positively need operator overloading is when doing arithmetic, and you should do that using the built in types. This, of course, sucks when the built in types are inadequate, and you e.g. want to use a arbitrary precision library such as BigDecimal in Java.
This, of course, is an opinion, and I'm not shy to admit it's been shaped by being burned by Lift, the Scala web framework which makes heavy use of symbolic function names which makes it incredibly difficult to talk about or search for answers online.
[+] [-] Lewisham|13 years ago|reply
I personally like overloading, but I think it's probably too easy to abuse, and I can see how it would cause problems with a team size larger than 5.
As far as I can see, whenever the Go team encountered a language feature that could possibly be abused, they always deferred to leaving it out. Whether that is good or bad I'm not sure we will know until we have years of experience with it.
[+] [-] mseepgood|13 years ago|reply
In go you get polymorphism via interfaces and you can share implementation via embedding. http://golang.org/doc/effective_go.html#embedding
[+] [-] skybrian|13 years ago|reply
In Go, there is also an "interface" which is basically a set of methods.
[+] [-] paraboul|13 years ago|reply
By reading the code "foo + bar" you can't know what is really doing internally.
He is talking about operator (+-*=[]&) overloading. Not method overloading.
[+] [-] robharper|13 years ago|reply
[+] [-] fjellfras|13 years ago|reply
[+] [-] shawnps|13 years ago|reply
[+] [-] ssteel|13 years ago|reply
http://code.google.com/p/goclipse/ https://github.com/nsf/gocode
[+] [-] redbad|13 years ago|reply
http://www.sublimetext.com/2
https://github.com/DisposaBoy/GoSublime
[+] [-] jff|13 years ago|reply
[+] [-] andrewbinstock|13 years ago|reply
[+] [-] truebosko|13 years ago|reply
[+] [-] geoka9|13 years ago|reply
It took us 25 years to begin to see that the king is naked!
UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
[+] [-] zaiste|13 years ago|reply
[+] [-] _ak|13 years ago|reply
[+] [-] shortlived|13 years ago|reply
[+] [-] swdunlop|13 years ago|reply
When people say Go poor or no error handling, this is probably what they are complaining about. The fundamental properties offered by try/catch/throw are unpacked by Go into defer, recover and multiple value returns and type switches. Go's designers make the argument that when used thoughtlessly, exceptions encourages error handling antipatterns.
[+] [-] dhconnelly|13 years ago|reply
[+] [-] zemo|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] jurre|13 years ago|reply
[+] [-] user911302966|13 years ago|reply
Where are the moving parts?
[+] [-] wetbrain|13 years ago|reply
There's always many problems that aren't immediately apparent but difficult.
[+] [-] mseepgood|13 years ago|reply
[+] [-] brandoncapecci|13 years ago|reply
[+] [-] emmett|13 years ago|reply
Why would this bother you that they are trying new things and learning?
[+] [-] cloudhead|13 years ago|reply