Will Go be the new go-to programming language?(gigaom.com)
gigaom.com
Will Go be the new go-to programming language?
http://gigaom.com/cloud/will-go-be-the-new-go-to-programming-language/
185 comments
> The speed of development is far better than any other language I've experienced.
No, it isn't. Here's the proof: someone has said exactly that about, and I'm really not kidding, every newly popular language over the last 20 years. They said it about Java. About Python. About Ruby, and CoffeeScript and Clojure and Haskell and...
Yet the Great Leap Forward in programming productivity hasn't arrived. And Go won't bring it either.
Go no doubt improves your speed of coding. And being a new and different toolbox it's more fun, so it makes your coding more engaging. You "feel" more productive. But your hard bugs are still hard. And your maintenance hassles are still hassles. And your bad designs are still bad. That stuff is what takes time, not banging out your code.
Programming languages can make the easy stuff easy. They can't fix our own stupidity.
(To be clear: I'm not saying Go is bad, it actually looks like a ton of fun to me, though I haven't had the chance to really kick the tires yet. But don't attribute to it properties it doesn't have.)
No, it isn't. Here's the proof: someone has said exactly that about, and I'm really not kidding, every newly popular language over the last 20 years. They said it about Java. About Python. About Ruby, and CoffeeScript and Clojure and Haskell and...
Yet the Great Leap Forward in programming productivity hasn't arrived. And Go won't bring it either.
Go no doubt improves your speed of coding. And being a new and different toolbox it's more fun, so it makes your coding more engaging. You "feel" more productive. But your hard bugs are still hard. And your maintenance hassles are still hassles. And your bad designs are still bad. That stuff is what takes time, not banging out your code.
Programming languages can make the easy stuff easy. They can't fix our own stupidity.
(To be clear: I'm not saying Go is bad, it actually looks like a ton of fun to me, though I haven't had the chance to really kick the tires yet. But don't attribute to it properties it doesn't have.)
> someone has said exactly that about, and I'm really not
> kidding, every newly popular language over the last 20
> years.
> Programming languages can make the easy stuff easy.
> They can't fix our own stupidity.
Sure, but again, recognize that your points are all the same stuff we've already heard. Moving from C++ to Java was like that (especially in the domain of debugging). Moving from PHP to Ruby was like that (especially in the domain of reuse). And these points were universally recognized by everyone writing Java or Ruby, and they weren't wrong.
And you aren't wrong. Go has made you more productive, and I don't argue with that. But how much of that is Go and how much of that is simply you becoming better after being tickled by your new toy?
Back the clock up to the '98 C++/PHP world, and you'll see all the same bad software. It's not that nothing has improved, but the improvements are mild. People "wrote code" really fast back then too, and that code was clean, and just like back then people spend most of their time evolving that now-much-less-clean code to work in new design domains. And that's the stuff that has barely changed at all.
And you aren't wrong. Go has made you more productive, and I don't argue with that. But how much of that is Go and how much of that is simply you becoming better after being tickled by your new toy?
Back the clock up to the '98 C++/PHP world, and you'll see all the same bad software. It's not that nothing has improved, but the improvements are mild. People "wrote code" really fast back then too, and that code was clean, and just like back then people spend most of their time evolving that now-much-less-clean code to work in new design domains. And that's the stuff that has barely changed at all.
So you're not saying that everyone was wrong when they claimed they were more productive in C++/Java/Scala than in C/C++/Java?
We're using modern languages to build things that were difficult/impossible in older languages. Sure, the 1998 PHP world looks primitive, and the actual code may be bad, but I think it was miles ahead of the 1988 COBOL world.
I would have thought that each language brought more suitable tools to the jobs at the time, and people were more productive. I feel more productive in Go now than I ever have. It's not a factor of 10, but it's noticeable. Yes it may be that it's new and I enjoy it so I'm more productive, but given the language's designers' rock-hard stance on introducing complexity, I am confident in a frustration-reduced experience in Go for the foreseeable future.
Also, if this increase in productivity is just due to learning a new language, I think that's as good a reason as any to learn it :)
We're using modern languages to build things that were difficult/impossible in older languages. Sure, the 1998 PHP world looks primitive, and the actual code may be bad, but I think it was miles ahead of the 1988 COBOL world.
I would have thought that each language brought more suitable tools to the jobs at the time, and people were more productive. I feel more productive in Go now than I ever have. It's not a factor of 10, but it's noticeable. Yes it may be that it's new and I enjoy it so I'm more productive, but given the language's designers' rock-hard stance on introducing complexity, I am confident in a frustration-reduced experience in Go for the foreseeable future.
Also, if this increase in productivity is just due to learning a new language, I think that's as good a reason as any to learn it :)
[deleted]
'Performance' is not a bullet point. Please do not wave hands about 'performance' without thinking about the actual benefit in the actual domain you are programming in.
If you need to write fine-grained embedded, DSP or graphics code you are probably going to use a true low level language like C or C++ anyway, not a gc language.
If you are not working in a domain like that, you need to measure to even know whether the language is even a significant bottleneck. By the time you have measured you can often find a targeted place to optimize with FFI or extension modules.
If you are using a language just because you think it is faster at everything, you are optimizing prematurely and in a somewhat naive way.
If you need to write fine-grained embedded, DSP or graphics code you are probably going to use a true low level language like C or C++ anyway, not a gc language.
If you are not working in a domain like that, you need to measure to even know whether the language is even a significant bottleneck. By the time you have measured you can often find a targeted place to optimize with FFI or extension modules.
If you are using a language just because you think it is faster at everything, you are optimizing prematurely and in a somewhat naive way.
Performance is a huge bullet point for me. A language such as Python or Ruby requires you to make considerations (writing performance-sensitive code by shelling out to a native C extension, for example) that don't crop up in a natively compiled language such as Go.
In fact, for performance-sensitive things the difference is often staggering, even for things that scripting languages were originally invented for, such as text processing. Performance-sensitive doesn't always mean "DSP or graphics code". If you want to process huge log files in Ruby, for example, you can start as many threads you like to attempt to parallelize it without getting anywhere because of the global interpreter lock, and will find yourself resorting to things like forking off child processes. Ruby would be a bad fit because it does not perform well. I often end up writing such processing code in Lua (using LuaJIT) because of the dramatic difference in performance.
One must always consider the domain, but performance is one important facet of Go: Go gives you high performance without sacrificing much of the expressiveness of dynamic languages such as Python and Ruby. (Conversely, C/C++ gives you high performance without the same expressiveness.) If Go had the same VM as Ruby I would probably never consider using it for anything, as I don't see any language-level benefits that outweigh the performance aspect.
In fact, for performance-sensitive things the difference is often staggering, even for things that scripting languages were originally invented for, such as text processing. Performance-sensitive doesn't always mean "DSP or graphics code". If you want to process huge log files in Ruby, for example, you can start as many threads you like to attempt to parallelize it without getting anywhere because of the global interpreter lock, and will find yourself resorting to things like forking off child processes. Ruby would be a bad fit because it does not perform well. I often end up writing such processing code in Lua (using LuaJIT) because of the dramatic difference in performance.
One must always consider the domain, but performance is one important facet of Go: Go gives you high performance without sacrificing much of the expressiveness of dynamic languages such as Python and Ruby. (Conversely, C/C++ gives you high performance without the same expressiveness.) If Go had the same VM as Ruby I would probably never consider using it for anything, as I don't see any language-level benefits that outweigh the performance aspect.
> If you are not working in a domain like that, you need to measure to even know whether the language is even a significant bottleneck.
Or, if one is confident that the project can be done in Go, and that existing performance measurements of alternatives are accurate and show much worse performance, and the alternatives aren't much easier to use anyway, use Go and don't look back. Why optimize with FFI or extension modules when one can scrap that idea at little expense?
As an analogy if I wanted a faster car I'd probably be better off switching cars than tweaking my existing car's engine.
Or, if one is confident that the project can be done in Go, and that existing performance measurements of alternatives are accurate and show much worse performance, and the alternatives aren't much easier to use anyway, use Go and don't look back. Why optimize with FFI or extension modules when one can scrap that idea at little expense?
As an analogy if I wanted a faster car I'd probably be better off switching cars than tweaking my existing car's engine.
A new car doesn't have the same learning curve as a new programming language. You can pretty much jump in any car and drive it.
Python, your performance will be substantially improved anyway
Except not really - if you are doing computation in Python you are probably using NumPy which in turn is using hand-tuned assembly language BLAS or whatever under the hood. And if not, you are probably I/O bound.
Except not really - if you are doing computation in Python you are probably using NumPy which in turn is using hand-tuned assembly language BLAS or whatever under the hood. And if not, you are probably I/O bound.
That's a small use case compared to the whole language. The statement you disagree with is more true than your anecdote about one library. On top of that, all the network I/O is automatically nonblocking.
His point is that it probably doesn't matter for performance whether you're building in Python or Go, since neither language can make the kernel handle socket buffers and network events faster. I/O-bound programs in either language will have poll/select/epoll/whatever at the top of their profile.
The main point is that for CPU bound tasks, other than those that use Numpy, the performance is still a dog with Python.
I threw in the comment about nonblocking I/O niceties as icing on the cake, but since we're on the topic it's worth mentioning that a language with these features built in is superior to one where it is either a tricky library or a monkey patch, referring to Twisted, Tornado, Gevent and Eventlet.
I threw in the comment about nonblocking I/O niceties as icing on the cake, but since we're on the topic it's worth mentioning that a language with these features built in is superior to one where it is either a tricky library or a monkey patch, referring to Twisted, Tornado, Gevent and Eventlet.
What? No it isn't. Go's concurrency support is fundamentally different than Python's idiomatic approach (event libraries). It's an apples/oranges comparison. If one approach is more performant than the other, I'd bet on the event library, since evented programs are more or less scheduled purely by I/O.
I like Go. I've been writing in it for a couple of weeks now and will continue to. But don't oversell it.
I like Go. I've been writing in it for a couple of weeks now and will continue to. But don't oversell it.
I'm pretty sure i/o bound go routines will use the very same kernel eventing mechanism. I looked into this recently, and you have to explicitly tell it to use more than one thread with http://golang.org/pkg/runtime/#GOMAXPROCS
Exactly.
It certainly is. Just look at the insanity of the nonblocking I/O experience in Python. It's confusing, divided, and results in duplicated work all the way down to the database driver level.
I'm not overselling it. I'm someone who's built an entire web framework around gevent and knows that having this functionality in the library is a massive weakness of Python.
In Python, we have monkey patching vs. an entirely new driver vs. just using blocking calls.
In Go, we just have nonblocking I/O because that's how it works.
I'm not overselling it. I'm someone who's built an entire web framework around gevent and knows that having this functionality in the library is a massive weakness of Python.
In Python, we have monkey patching vs. an entirely new driver vs. just using blocking calls.
In Go, we just have nonblocking I/O because that's how it works.
In both goroutines and events, blocking IO will be parked waiting on a select (or similar device). In both, they implicitly context switch while blocking, meaning that processing ready IO might have to wait for other stuff to reach a scheduling point. Unlike events, goroutines can be processed on more than one underlying OS thread at once.
Advantage: goroutines.
Advantage: goroutines.
Well, scipy/numpy is quite relevant in the Python ecosystem; it's not something you can ignore when talking about the language. Like Rails to Ruby, numpy is quite a big feature of Python.
It might be nice for a quick script or standalone program, but most decent size software projects need plenty of mature libraries to be of much use. Python and C have decades head start here.
Can Go make use of C or Python libraries? Or is that a crazy question?
(Part of Python's popularity is that it is such a great glue language)
(Part of Python's popularity is that it is such a great glue language)
It can call into C easily: http://golang.org/cmd/cgo/
I think Lua is still the most simple and easiest in this regard. And Lua is embeddable.
Everyone is striving for concurrency as a language feature but sometimes it seems like a solution looking for a problem. What is it that you _cannot_ do now that you must have concurrency in order to do? What specific real world problem is it that you cannot solve? What are the cost-savings you will achieve with concurrency?
Maybe concurrency is a matter of smart programming, not dummy-proof languages with concurrency "built-in"?
Concurrency seems to be Go's main selling point (along with fast compilation). But Go is not small, it's not embeddable and it can't leverage C functions with the same ease as Lua. With Lua you can extend apps written in C. With Go you are writing the same old C apps again in Go. All the Go libraries I've see so far are just libraries that exist in other languages to do the same old things we've been doing for years, rewritten in Go.
At least with Lua, creativity and expression is encouraged by letting people write their own libraries. All the existing C libraries don't have to be rewritten as Lua libraries. What a boring exercise that would be. All you need to do is understand how to interface with C functions and there's little you cannot do vis-a-vis existing C libraries to do the "usual things".
Just my opinion. Lua is an arbitrary example. It's the general concepts of simplicity, small size, extending applications, and leveraging existing C code of which I am a "fanboy". It just happens that Lua meets some of these criteria. Sorry if it offends anyone.
Everyone is striving for concurrency as a language feature but sometimes it seems like a solution looking for a problem. What is it that you _cannot_ do now that you must have concurrency in order to do? What specific real world problem is it that you cannot solve? What are the cost-savings you will achieve with concurrency?
Maybe concurrency is a matter of smart programming, not dummy-proof languages with concurrency "built-in"?
Concurrency seems to be Go's main selling point (along with fast compilation). But Go is not small, it's not embeddable and it can't leverage C functions with the same ease as Lua. With Lua you can extend apps written in C. With Go you are writing the same old C apps again in Go. All the Go libraries I've see so far are just libraries that exist in other languages to do the same old things we've been doing for years, rewritten in Go.
At least with Lua, creativity and expression is encouraged by letting people write their own libraries. All the existing C libraries don't have to be rewritten as Lua libraries. What a boring exercise that would be. All you need to do is understand how to interface with C functions and there's little you cannot do vis-a-vis existing C libraries to do the "usual things".
Just my opinion. Lua is an arbitrary example. It's the general concepts of simplicity, small size, extending applications, and leveraging existing C code of which I am a "fanboy". It just happens that Lua meets some of these criteria. Sorry if it offends anyone.
I've evaluated Lua for a number of use cases and even use it on my Ti NSpire calculator occasionally, but it has some horrible problems, particularly related to metatables and the concept of 1-based indexes. It also doesn't give us any advantages over other languages. LuaJIT is impressive I will say though.
However, Go's apparent concurrency focus is a bad assumption.
The problems that Go solves are simply: simplicity, synchronisation, thread scalability, time to market, modularity, testability, consistency, security and memory management.
All of those, you really can't do in C quickly and safely.
Go is a fixed C, with a fixed standard library that suits NOW, not 20-30 years ago. That's all it is and that should be applauded and praised. It also fixes the inevitable mountain of stuff you have to do to get something significant done in C and ignores the utter retarded complexity of C++ and Java.
Ultimately:
A single person can build something significant in Go in a week.
A single person cannot build something signficant in C in a week.
cgo is very easy. I've plugged SDL into it in a few minutes.
However, Go's apparent concurrency focus is a bad assumption.
The problems that Go solves are simply: simplicity, synchronisation, thread scalability, time to market, modularity, testability, consistency, security and memory management.
All of those, you really can't do in C quickly and safely.
Go is a fixed C, with a fixed standard library that suits NOW, not 20-30 years ago. That's all it is and that should be applauded and praised. It also fixes the inevitable mountain of stuff you have to do to get something significant done in C and ignores the utter retarded complexity of C++ and Java.
Ultimately:
A single person can build something significant in Go in a week.
A single person cannot build something signficant in C in a week.
cgo is very easy. I've plugged SDL into it in a few minutes.
I agree with you mostly. Although you are comparing Go to a language with manual memory management, not another GC language, like Lua (sorry to keep using that example).
A question: What is your idea of "something significant"?
Go seems like an ideal language to quickly build servers. Am I missing something else?
A question: What is your idea of "something significant"?
Go seems like an ideal language to quickly build servers. Am I missing something else?
Go has FFI hooks with "import C", outside of that I haven't found anything (though Go's way looks much simpler than typical FFI setups at first glance). No direct access to C / C++ libraries like D does, though that's probably a good thing.
There is Go support for SWIG: http://www.swig.org/Doc2.0/Go.html
Still, it is rarely used, building in pure Go is much nicer, because one of the great things about Go is building systems where you can understand all the pieces.
And if you want to understand what a Go lib does looking at the source is surprisingly informative. (This also addresses most of the complaints about documentation).
Still, it is rarely used, building in pure Go is much nicer, because one of the great things about Go is building systems where you can understand all the pieces.
And if you want to understand what a Go lib does looking at the source is surprisingly informative. (This also addresses most of the complaints about documentation).
Well, I don't expect most programs to be re-written in Go, but I think in, say 10 years' time most new programs will be. By then Go's mature, fast libraries will be comparable to any of Python's (although C will have the kernel-level advantages still I think).
I think 24 months quoted in the article is optimistic...
I think 24 months quoted in the article is optimistic...
Make Go code easily usable from Python (as C is) and the point will be completely moot. Why not do it?
Is already possible: https://bitbucket.org/binet/go-python
But is simpler to just write all your code in Go, Python code is not just slower, it is also less reliable and less maintainable.
But is simpler to just write all your code in Go, Python code is not just slower, it is also less reliable and less maintainable.
What is substantially different from GO besides performance. It just always seemed like another boring OO language that is fast. I've not really been impressed with the programming languages created at google. None of them seem to be very innovative or solve anything new. I guess it stems from google's affection towards java and misusing python (not using any of it's more powerful features, so it the code basically looks like a prettier version of java).
“How big a deal is this static typing thing??” - Barb Darrow (author of the article)
wow
wow
No, it is less expressive than Ruby and JS and so will not be as popular with the masses who optimize for LoC.
It's close. The tooling is really user-friendly, which is a big win.
Add some sort of decent generics and you're really close.
A top-class GUI toolkit would be good too.
Add some sort of decent generics and you're really close.
A top-class GUI toolkit would be good too.
I feel like not including generics is a huge oversight. Also, the way many go aficionados discuss this over at golang-nuts put me off a great deal.
to some extent, i think that the demand for generics is based on familiarity.
for example, long ago, i was looking at the source for some of the go libraries and couldn't understand why they had cut+paste code. when i asked on stackoverflow the unaminous answer was "because go doesn't support generics". you can see the discussion here - http://stackoverflow.com/questions/6645329/why-does-the-go-i...
BUT if you read that thread, and the discussion under the first answer, you'll see that there is an apparently reasonable solution without generics. that seemed like an obvious approach to me (coming, i guess, more from python and fp), but one that wasn't obvious to anyone answering (coming, i guess, more from java and c).
i have no evidence that this is a general problem, but it surprised me at the time. ever since i have been suspicious of people complaining about the lack of generics (disclaimer: i don't use go myself - when i looked at it i thought that it was clear improvement on c/c++/java, but could have been even better if they had been more open to ideas from fp - http://acooke.org/cute/GoRocksHow0.html ; in other words, i'd be happy to use it at work instead of c (current project), but if i can choose myself i'm more likely to go with a more functional approach).
for example, long ago, i was looking at the source for some of the go libraries and couldn't understand why they had cut+paste code. when i asked on stackoverflow the unaminous answer was "because go doesn't support generics". you can see the discussion here - http://stackoverflow.com/questions/6645329/why-does-the-go-i...
BUT if you read that thread, and the discussion under the first answer, you'll see that there is an apparently reasonable solution without generics. that seemed like an obvious approach to me (coming, i guess, more from python and fp), but one that wasn't obvious to anyone answering (coming, i guess, more from java and c).
i have no evidence that this is a general problem, but it surprised me at the time. ever since i have been suspicious of people complaining about the lack of generics (disclaimer: i don't use go myself - when i looked at it i thought that it was clear improvement on c/c++/java, but could have been even better if they had been more open to ideas from fp - http://acooke.org/cute/GoRocksHow0.html ; in other words, i'd be happy to use it at work instead of c (current project), but if i can choose myself i'm more likely to go with a more functional approach).
I think your so question shows exactly why generics are useful. A solution where you pass a callback predicate to the iterating function would work in Go, but be much slower than one in which the predicate logic can be inlined. E.g. if your image is 1920x1200 you would need to call the function that checks if the pixel is opaque 2.3 million times. That approach works ok in Python and Ruby which do not mind being a little on the slow side, but Go is supposed to be closer to the metal so something more efficient is needed.
i don't disagree with what you're saying (and i raise the question of efficiency in the link). my point was more about the sociology of the complaints: i think most people are complaining because they're used to generics and don't have the tools/smarts to solve problems in alternative ways.
i think the general conclusion from this thread is that generics would be useful because, at the moment, if you want top performance, you need to have type unsafe code in critical loops.
that sounds quite reasonable to me...
...so maybe i am just an arrogant bastard that doesn't think much of fellow programmers. but i suspect that most people, when they complain about generics are not making that argument. they're simply complaining because it's not what they are used to.
as i say, i may be wrong. i may be a horrible man. if people want to convert/improve me i suggest they start making comments that are a bit more nuanced than "i miss generics".
i think the general conclusion from this thread is that generics would be useful because, at the moment, if you want top performance, you need to have type unsafe code in critical loops.
that sounds quite reasonable to me...
...so maybe i am just an arrogant bastard that doesn't think much of fellow programmers. but i suspect that most people, when they complain about generics are not making that argument. they're simply complaining because it's not what they are used to.
as i say, i may be wrong. i may be a horrible man. if people want to convert/improve me i suggest they start making comments that are a bit more nuanced than "i miss generics".
You can write a C++ style pre processer to compute efficient specialized methods from a template definition. The only problem is winning community adoption over the objections of the go dev team.
> to some extent, i think that the demand for generics is based on familiarity.
Such as the familiarity of java developers who had to wait for a decade to get generics? The familiarity of C developers where void*? Or the familiarity of Python developers where "whatever"?
This claim doesn't check out.
Such as the familiarity of java developers who had to wait for a decade to get generics? The familiarity of C developers where void*? Or the familiarity of Python developers where "whatever"?
This claim doesn't check out.
[deleted]
What is an example of a use case for generics that can't be done, or is significantly less convenient to do, with interfaces? It sounds like there is at least some thought that generics may be included at some point, but I really haven't missed them thus far.
I have to agree that the lack of generics is one of the biggest holes in Go.
Common container data structures are one example. You can't write, say, a generic binary search tree in Go, unless you wrap all your data in an interface. While possible, this means you have to downcast all over the place.
The built-in map, while useful, is limited in how far it goes.
Maybe I'm just spoiled by the STL and the Java collections libraries.
Common container data structures are one example. You can't write, say, a generic binary search tree in Go, unless you wrap all your data in an interface. While possible, this means you have to downcast all over the place.
The built-in map, while useful, is limited in how far it goes.
Maybe I'm just spoiled by the STL and the Java collections libraries.
A lot of functional constructs heavily rely on parametric polymorphism. For example:
map :: (a -> b) -> [a] -> [b]
Slight nitpick, you can do this, just not with type safety. Type safety is the real reason generics are better than interfaces.
If you're attached to FP style you shouldn't choose an imperative language in the first place.
It has been pretty conclusively demonstrated at this point that a basic suite of "weak" FP tools is pretty useful in any language. No serious modern language should try to work without convenient closures and a functioning map and filter statement/function/whatever. This hasn't got anything to do with purity or academic goodness, and everything to do with the fact that languages like Python or Ruby, which are emphatically not FP languages, have simply shown such things to be indispensable tools for concise code.
Pretty useful: yes.
Essential: no.
Map/Filter introduce several new semantic concepts to a language. I think they were avoided for simplicity's sake and the fact you can achieve the same result with a for loop, even if it is slightly less concise.
Essential: no.
Map/Filter introduce several new semantic concepts to a language. I think they were avoided for simplicity's sake and the fact you can achieve the same result with a for loop, even if it is slightly less concise.
> Map/Filter introduce several new semantic concepts to a language.
No they don't. If you already have first-class functions (Go does) and some sort of sequence type (Go does), you have map/filter. There's no new semantic concepts.
No they don't. If you already have first-class functions (Go does) and some sort of sequence type (Go does), you have map/filter. There's no new semantic concepts.
With this standard for "essential" you may as well just drop down into assembly language.
The only added simplicity here is for the compiler writers, not the end users.
The only added simplicity here is for the compiler writers, not the end users.
numbers = map(numbers, func(n int) int {
return n * n
})
for i, n := range numbers { numbers[i] = n * n }
Sorry, but I do not see a difference in the order of assembly language vs. high-level language.
for i, n := range numbers { numbers[i] = n * n }
Sorry, but I do not see a difference in the order of assembly language vs. high-level language.
The difference is small because map is trivial, but the implications of using higher order functions isn't. Even something like trees sees a divergence between the styles (not necessarily in the order of assembly language vs. high-level, but certainly more than you're making out).
Higher order functions are really useful for splitting apart navigation of a data structure and the processing of the data contained within it.
Given that you can use purely higher order functions for control flow, I wouldn't say one is more essential than the other.
Higher order functions are really useful for splitting apart navigation of a data structure and the processing of the data contained within it.
Given that you can use purely higher order functions for control flow, I wouldn't say one is more essential than the other.
Now try it on a more complex type. Then try and compose various operations. Then swap out the container type.
(Unfortunately, formatting is lost)
a) With a more complex type (I don't see how this would affect one more than the other)
Functional would be:
foos = map(foos, func(f Foo) Foo { return Foo{f.A * f.A, f.B * f.B} })
Iterative is:
for i, f := range foos { foos[i] = Foo{f.A * f.A, f.B * f.B} }
b) Composing various operations. Composing filter + map:
Functional would be:
x := filter(map(numbers, func(n int) int { return n * n }), func(n int) bool { return n % 2 == 0 })
Iterative is:
x := make([]int, 0); for _, n := range numbers { sq := n * n; if sq % 2 == 0 { x = append(x, sq) } }
c) Swapping the container type is just a matter of swapping "_, n := range numbers".
a) With a more complex type (I don't see how this would affect one more than the other)
Functional would be:
foos = map(foos, func(f Foo) Foo { return Foo{f.A * f.A, f.B * f.B} })
Iterative is:
for i, f := range foos { foos[i] = Foo{f.A * f.A, f.B * f.B} }
b) Composing various operations. Composing filter + map:
Functional would be:
x := filter(map(numbers, func(n int) int { return n * n }), func(n int) bool { return n % 2 == 0 })
Iterative is:
x := make([]int, 0); for _, n := range numbers { sq := n * n; if sq % 2 == 0 { x = append(x, sq) } }
c) Swapping the container type is just a matter of swapping "_, n := range numbers".
> With a more complex type (I don't see how this would affect one more than the other)
It does because the discussion is about generics. The fact that you're writing out types for one and not the other makes your comparisons a bit disingenuous, though I understand if Go isn't very good at functional programming.
b) Composing various operations. Composing filter + map:
As you keep building them up the imperative style will have more code overhead and less efficiency.
> c) Swapping the container type is just a matter of swapping "_, n := range numbers".
This isn't true since the functional one could easily swap out to use an infinite data source whereas the imperative will be constrained to the arrays you're already using.
It does because the discussion is about generics. The fact that you're writing out types for one and not the other makes your comparisons a bit disingenuous, though I understand if Go isn't very good at functional programming.
b) Composing various operations. Composing filter + map:
As you keep building them up the imperative style will have more code overhead and less efficiency.
> c) Swapping the container type is just a matter of swapping "_, n := range numbers".
This isn't true since the functional one could easily swap out to use an infinite data source whereas the imperative will be constrained to the arrays you're already using.
We're WAY past the point where it is acceptable to pretend basics like map and filter are some esoteric functional thing. Every reasonable language has them, and no language without them is worth even considering.
map and filter are no problem:
https://github.com/tcard/functional
I can't say I've actually needed to use map or filter. You can, much as people did for the last 30 years and still do with C, quite happily do this sort of stuff with a for loop...
https://github.com/tcard/functional
I can't say I've actually needed to use map or filter. You can, much as people did for the last 30 years and still do with C, quite happily do this sort of stuff with a for loop...
People spent years without loops too, "quite happily" doing it with jumps. Lacking useful abstractions is not a case of preference, it is being inferior.
It's not that there's a lot of things that you flat-out can't do, it's that you can't do those things in a type-safe manner. The type system isn't capable of representing what you're trying to do. This seems like an odd omission in a language that otherwise has static typing.
I suspect this is why a lot of people who've jumped on the Golang bandwagon come from Python & Ruby: they're already used to no compile-time type safety, so they're not missing anything. For people who like type systems and have a style of programming that relies upon them, Go doesn't give them the tools they need to be productive.
In Steve Yegge's terms: C++ is a pretty software-conservative update to C (it even has backwards-compatible syntax). Meanwhile, Go is a pretty software-liberal update (slightly to the right of Python). G simply does not support a software-conservative programming style. Consequently, Go's adoption has mostly come from software-liberal communities.
I suspect this is why a lot of people who've jumped on the Golang bandwagon come from Python & Ruby: they're already used to no compile-time type safety, so they're not missing anything. For people who like type systems and have a style of programming that relies upon them, Go doesn't give them the tools they need to be productive.
In Steve Yegge's terms: C++ is a pretty software-conservative update to C (it even has backwards-compatible syntax). Meanwhile, Go is a pretty software-liberal update (slightly to the right of Python). G simply does not support a software-conservative programming style. Consequently, Go's adoption has mostly come from software-liberal communities.
I hate those terms, but by his definitions, Go is statically typed and defaults to not including features if they think they might be misused. Doesn't sound that liberal to me, compared to, say, Ruby with monkey-patching.
I tend to use generics alongside reflection a lot, for example I might use a Mapper<TFrom, TTo> when mapping between different representations (an object and associated service contract being one example).
The mapper can take care of almost everything using a few conventions and reflection, and for anything where those conventions don't cover it you plug in a little custom code (inherit from Mapper<,> or use composition).
Not sure how you’d handle that sort of case in Go without generics?
The mapper can take care of almost everything using a few conventions and reflection, and for anything where those conventions don't cover it you plug in a little custom code (inherit from Mapper<,> or use composition).
Not sure how you’d handle that sort of case in Go without generics?
Repository style generic data access layers: http://stackoverflow.com/questions/11914712/writing-generic-...
There are several generic data access layers implemented in Go: standard JSON package, Gustavo's BSON package, App Engine Data store and more. They all use the reflect package internally.
Yeah, it basically makes the answer to the original question an emphatic "No".
Have you checked out Rust (http://rust-lang.org)? They seem to be closer to what Go's original goals were, with generics, proper RAII, etc.
It's not an oversight, it is a tradeoff.
Check Russ Cox'sswtch.com website for details.
You can write generic functions with reflection.
The creators of Go have cluster a.k.a. cloud computing in mind: http://www.youtube.com/watch?v=FTl0tl9BGdc
And the predictions in this article are about PaaS / IaaS / orchestration, which have not a lot to do with GUI.
Implementing a top-class GUI toolkit that is not just a binding to an existing one would be at least half a decade of work. And when it's done all GUIs will be rendered by web views anyway. The web is the presentation layer of the future. Classic desktop widget sets like QtGui or Swing will fit nowhere, because all the consumer operating systems like iOS, OS X, Android and Windows 8+ will have highly custom user interface paradigms, which won't be mappable to each other by some cross-platform thing.
Implementing a top-class GUI toolkit that is not just a binding to an existing one would be at least half a decade of work. And when it's done all GUIs will be rendered by web views anyway. The web is the presentation layer of the future. Classic desktop widget sets like QtGui or Swing will fit nowhere, because all the consumer operating systems like iOS, OS X, Android and Windows 8+ will have highly custom user interface paradigms, which won't be mappable to each other by some cross-platform thing.
>just a web view anyways
This. Go makes it fantastically simple to go from 0-to-web-server.
There were a few projects I wanted to write in Go, but avoided because of needing a GUI.
Then I remembered: I can just bolt a web-page onto my app, and I get a GUI for free [assuming knowledge of HTML/CSS/JS].
Even better: that GUI will work on any computer with a modern web-browser, including my phones. If you stick to standards, it should even be a reasonably consistent UX across the newer browsers.
---
While I would still _like_ to see a good UI toolkit for Go, I really think it's less of a necessity than most would have you believe.
This. Go makes it fantastically simple to go from 0-to-web-server.
There were a few projects I wanted to write in Go, but avoided because of needing a GUI.
Then I remembered: I can just bolt a web-page onto my app, and I get a GUI for free [assuming knowledge of HTML/CSS/JS].
Even better: that GUI will work on any computer with a modern web-browser, including my phones. If you stick to standards, it should even be a reasonably consistent UX across the newer browsers.
---
While I would still _like_ to see a good UI toolkit for Go, I really think it's less of a necessity than most would have you believe.
Agreed.
I'm playing with the idea of a Cairo/Postscript type library with X, Win32, Quartz backends in Golang which would be a good foundation for such a thing.
I have got precisely nowhere apart from trying to connect to an X server unsuccessfully though :)
I'm playing with the idea of a Cairo/Postscript type library with X, Win32, Quartz backends in Golang which would be a good foundation for such a thing.
I have got precisely nowhere apart from trying to connect to an X server unsuccessfully though :)
Idea: a Go HTML GUI toolkit designed to allow writing a GUI in real Go code without thinking about html, css, ajax, etc. It just abstracts that stuff away, providing a much more standardized/typical GUI programming experience, all the while running a web server and generating HTML on the fly.
I really wish all languages had an IDE that included an interface builder as nice as Visual Studio. Making a VB.NET program really is rapid application development, because in most cases you don't even need to write more than a dozen or so lines of code.
I find programming to be easy (relatively). I find interfaces to be almost insurmountably difficult. That's the only reason I stick exclusively to command-line programs.
I find programming to be easy (relatively). I find interfaces to be almost insurmountably difficult. That's the only reason I stick exclusively to command-line programs.
>I find interfaces to be almost insurmountably difficult.
Odd. Here's my 5 min explanation of how GUI programming works:
You have a bunch of objects that are responsible for generating events and painting themselves to the screen. They exist in hierarchies. You have objects that coordinate the transitions between different display states by swapping out different hierarchies (view FSMs, really.) You communicate with your domain backend thread/process through some kind of command channel. When your domain models change, they publish some events that go back through that channel to notify your display hierarchies so they can update themselves. Everything is async and through message passing.
The difficulties can be in a) setting up your hierarchy of display objects and b) getting your event routing / updating to happen in a clean way. Oh yea, and c) handling partially-complete domain models in the ui ;)
Cocoa/CocoaTouch and Flex are both quite nice environments for gui programming. I haven't used MFC, winforms or xaml/winrt..
Odd. Here's my 5 min explanation of how GUI programming works:
You have a bunch of objects that are responsible for generating events and painting themselves to the screen. They exist in hierarchies. You have objects that coordinate the transitions between different display states by swapping out different hierarchies (view FSMs, really.) You communicate with your domain backend thread/process through some kind of command channel. When your domain models change, they publish some events that go back through that channel to notify your display hierarchies so they can update themselves. Everything is async and through message passing.
The difficulties can be in a) setting up your hierarchy of display objects and b) getting your event routing / updating to happen in a clean way. Oh yea, and c) handling partially-complete domain models in the ui ;)
Cocoa/CocoaTouch and Flex are both quite nice environments for gui programming. I haven't used MFC, winforms or xaml/winrt..
Full disclaimer: I haven't done much UI (outside of HTML/CSS/JS, that is)... I dabbled with Visual Basic and the associated tooling (WinForms, at the time) during my college courses.
Of everything you describe, I think the area I struggled most with was:
>getting your event routing / updating to happen in a __clean__ way.
I was a naive and young programmer, so I'll withhold any criticisms towards WinForms, but the event routing was a _mess_ by the end of that project.
Of everything you describe, I think the area I struggled most with was:
>getting your event routing / updating to happen in a __clean__ way.
I was a naive and young programmer, so I'll withhold any criticisms towards WinForms, but the event routing was a _mess_ by the end of that project.
> I find programming to be easy (relatively). I find interfaces to be almost insurmountably difficult.
That's a personality type (mine too). Probably best to bite the bullet with HTML/CSS. I think non-web interface builders are a thing of the past. Which is too bad, because CSS is a monster to master.
That's a personality type (mine too). Probably best to bite the bullet with HTML/CSS. I think non-web interface builders are a thing of the past. Which is too bad, because CSS is a monster to master.
[deleted]
I think developers will stay on traditional desktop systems, most likely a Linux since Apple and Microsoft target consumers(consuming videos, browsing the web or using only specific applications like Excel).
Developers need tools too so we shouldn't just abandon non-web technologies.
Developers need tools too so we shouldn't just abandon non-web technologies.
There's no reason why development tools couldn't be moved to the web. It's already happening with Github. And Github could include an IDE like Cloud9 one day.
I've been out of the OSX-space for a while. Are there a lot of apps using web views for their GUI? The only ones I can think of are Colloquy and Adium. Even then, they don't do the whole GUI as a web view, just the parts of the display that are theme-able.
> Are there a lot of apps using web views for their GUI?
No. [Edit: I'm talking about apps that use webviews make a native-looking app. Web apps don't qualify.]
No. [Edit: I'm talking about apps that use webviews make a native-looking app. Web apps don't qualify.]
All the apps developed for the web outnumber the apps in the app store.
Maybe I should have specified WebView rather than web view. IIRC, a WebView is a ready-to-go embed-able WebKit widget in the toolkit of OSX GUI developers.
Colloquy represents the chatroom text as a stream of XML, which it uses XSLT themes to translate into HTML, which is displayed in a WebView. I'm sure Adium does something similar.
"Using HTML/CSS/JS as the new GUI medium" doesn't limit itself to just running stuff in a traditional browser. I was under the assumption that we were talking about making HTML/CSS/JS the new GUI layer, even for native apps.
Colloquy represents the chatroom text as a stream of XML, which it uses XSLT themes to translate into HTML, which is displayed in a WebView. I'm sure Adium does something similar.
"Using HTML/CSS/JS as the new GUI medium" doesn't limit itself to just running stuff in a traditional browser. I was under the assumption that we were talking about making HTML/CSS/JS the new GUI layer, even for native apps.
There are a few GUI toolkits in the works, it seems.
http://go-lang.cat-v.org/library-bindings
Check out the "GUIs and Widget Toolkits" section.
http://go-lang.cat-v.org/library-bindings
Check out the "GUIs and Widget Toolkits" section.
top class GUI toolkit? come back in a few years
I'm waiting for a mature GUI library to start something serious in Go.
I'd be very^2 interested to see how the concurrency primitives of Go help graphical applications.
Given that Rob created one of Go's ancestors using the same CSP concurrency model back in the 80's precisely to build GUI apps, I think it should work quite well:
http://doc.cat-v.org/bell_labs/squeak/
http://doc.cat-v.org/bell_labs/squeak/
Ha! didn't know he worked specifically in this context, thanks a lot. I'm even more impatient now.
Yes. :) I'm using it now, and it feels better to me than Java and C/C++. The language is cleaner and the toolchain is very smooth.
The new Go Revel framework (by HN user robfig) looks especially promising for web MVC apps: http://robfig.github.com/revel/
The new Go Revel framework (by HN user robfig) looks especially promising for web MVC apps: http://robfig.github.com/revel/
[deleted]
Yes. Combined with Dart and Google has their strategy for leaving Java and Firefox in the dust.
I doubt dart will ever gain the momentum that go currently has.
go has momentum? I am not sure I would go that far.
Go certainly has buzz.
I keep thinking I should get around to doing a real project with it, then I get irritated by the strident advocacy and put it off again. For purposes which seem to call for Go I can easily just go back to C. Which is already beyond mature and plays nicely with almost any non-JVM language.
I keep thinking I should get around to doing a real project with it, then I get irritated by the strident advocacy and put it off again. For purposes which seem to call for Go I can easily just go back to C. Which is already beyond mature and plays nicely with almost any non-JVM language.
it is really early to bury a tool that has just started to take some shape. why do you have doubts?
It's certainly the new go-to programming language for blog posts about programming languages :)
It's a very nice language, I like it a lot, but if there's one thing we all should have learnt over the last few years, it's that no programming language is the right choice for every task.
It's a very nice language, I like it a lot, but if there's one thing we all should have learnt over the last few years, it's that no programming language is the right choice for every task.
I think Go has big potential, especially with those who now code C++ or Java but also with some users of dynamic typing languages. I have a feeling Go is here to stay for a while.
"C will always have its place but Ruby and Python code bases will go to Go."
Not in the web world. Go will take programmers from the C/Java camp, but not many from the ruby/python camp.
Not even one in a hundred startups will use Go as their main programming language. Ask PG to confirm.
I am an early golang user and once in a while play with it to try new stuff, but still coding everything else in python.
To answer the question: Yes for systems work, No for web work.
Not in the web world. Go will take programmers from the C/Java camp, but not many from the ruby/python camp.
Not even one in a hundred startups will use Go as their main programming language. Ask PG to confirm.
I am an early golang user and once in a while play with it to try new stuff, but still coding everything else in python.
To answer the question: Yes for systems work, No for web work.
"I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++."
- Rob Pike (http://commandcenter.blogspot.com/2012/06/less-is-exponentia...)
Strangely, I think almost the opposite - I think it'll take a lot of "scripting language" tasks, but not much of the system programmers jobs.
Coming from a scripting language background, Go feels like a step forward in performance, without many of the headaches of C++ or Java.
But speaking to people who write C++ for a living, they see little or no use for go for them, as they need either the performance or flexibility of a lower level language like C++ - that's why they haven't moved to an alternative a long time ago.
Coming from a scripting language background, Go feels like a step forward in performance, without many of the headaches of C++ or Java.
But speaking to people who write C++ for a living, they see little or no use for go for them, as they need either the performance or flexibility of a lower level language like C++ - that's why they haven't moved to an alternative a long time ago.
Cannot agree more, and I will give go a try to replace python for performance.
Be sure to do the same jobs you would do in Python, keep track of how long it takes, and measure the difference - otherwise you are optimizing prematurely with snake oil.
I'm pretty sure doing the same job twice and measuring the time taken each time is a guarantee that whatever you do, it'll take twice as long and bore you to death...
I disagree. IMO:
I think Go will be well suited for web applications: 1. Google App Engine will continue to play a major role in Go's development. 2. The speed of development in Go is equal to or exceeds that of other dynamic languages. Static typing takes minimal extra time and immediately pays off by catching silly errors, then continues to ease development (and documentation) in the future. 3. Go's standard library already contains powerful tools to develop web apps.
It's important to remember that Go is still very young. Could you explain why you still prefer Python over Go?
I think Go will be well suited for web applications: 1. Google App Engine will continue to play a major role in Go's development. 2. The speed of development in Go is equal to or exceeds that of other dynamic languages. Static typing takes minimal extra time and immediately pays off by catching silly errors, then continues to ease development (and documentation) in the future. 3. Go's standard library already contains powerful tools to develop web apps.
It's important to remember that Go is still very young. Could you explain why you still prefer Python over Go?
The language offers much more powerful programming abstractions.
If you need speed, you can either go PyPy, or Cython after locating the problematic code spots.
If you need speed, you can either go PyPy, or Cython after locating the problematic code spots.
Go offers nothing for C programmers, and Java/C++ programmers are largely using languages by corporate decree, not choice. Go's main audience is in fact people who are still clinging to dynamically typed languages. Where modern languages like haskell or scala are too scary for them, go is familiar enough to draw them in, and show them that static typing doesn't mean java.
'clinging to dynamically typed languages' and 'too scary' implies that the only people using such languages are incompetent beginners. That is posturing more than it is an honest description of reality. Same applies to your description of Go as nothing more than a bridge to Scala.
Are you so sure that everyone using languages other than Scala and Haskell is that much dumber than you are?
It took a while for C++ and then for Java to become languages of corporate decree. If Go will ever become one of those languages, it will take around the same amount of time.
Are you so sure that everyone using languages other than Scala and Haskell is that much dumber than you are?
It took a while for C++ and then for Java to become languages of corporate decree. If Go will ever become one of those languages, it will take around the same amount of time.
>'clinging to dynamically typed languages' and 'too scary' implies that the only people using such languages are incompetent beginners
No it doesn't, it implies they are accustomed to dynamically typed languages, and unfamiliar with modern statically typed languages.
>Same applies to your description of Go as nothing more than a bridge to Scala.
That's interesting given that I said no such thing.
>Are you so sure that everyone using languages other than Scala and Haskell is that much dumber than you are?
Who are you replying to? I said nothing of the sort.
>If Go will ever become one of those languages, it will take around the same amount of time.
What does that have to do with anything? Nobody is discussing whether or not go will become the corporate standard language.
No it doesn't, it implies they are accustomed to dynamically typed languages, and unfamiliar with modern statically typed languages.
>Same applies to your description of Go as nothing more than a bridge to Scala.
That's interesting given that I said no such thing.
>Are you so sure that everyone using languages other than Scala and Haskell is that much dumber than you are?
Who are you replying to? I said nothing of the sort.
>If Go will ever become one of those languages, it will take around the same amount of time.
What does that have to do with anything? Nobody is discussing whether or not go will become the corporate standard language.
As someone who only used C for systems work for 15 years, and for the last two years switched exclusively to Go (except in the kernel) I disagree. Go offers everything I want as a C programmer.
I didn't mean to suggest that absolutely zero C programmers would adopt go, merely that go does not address the needs C does, so most people using C won't have the option of using go instead. Obviously if you were using C for things that didn't need C to begin with, then go becomes an option.
> Betteridge's Law of Headlines is an adage that states, "Any headline which ends in a question mark can be answered by the word 'no'".
http://en.wikipedia.org/wiki/Betteridge%27s_Law_of_Headlines
http://en.wikipedia.org/wiki/Betteridge%27s_Law_of_Headlines
Is there a law about people always quoting a law from wikipedia?.. Betteridge, Poe, Godwin, Dunning-Kruger.. it is getting just as old as the terrible blog post titles that provoke them them.
This is not really even such a ridiculous proposition, either- certainly worthy of discussion.
This is not really even such a ridiculous proposition, either- certainly worthy of discussion.
Much better that we all recite this message board trope than talk about golang. After all, there might be 1 or 2 people left in the world who haven't already heard it.
And there might be 1 or 2 people left on Hacker News who haven't already heard of Go.
And that's why the link goes to an article discussing usage of Go instead of the golang homepage.
Law applied to some recent HN headlines:
How Much Is a Fun Job Worth? No.
Ask HN: Why is wikidot.com blacklisted? No.
Ask HN: What is your ideal income? No.
Which educational technologies are worth betting on? No.
Ask PG: What Is The Most Frighteningly Ambitious Idea You Have Been Pitched On? No.
How Much Is a Fun Job Worth? No.
Ask HN: Why is wikidot.com blacklisted? No.
Ask HN: What is your ideal income? No.
Which educational technologies are worth betting on? No.
Ask PG: What Is The Most Frighteningly Ambitious Idea You Have Been Pitched On? No.
Is Betteridge's Law of Headlines Correct?
I've found that law rather accurate for news headlines, but rather less so for blog posts or scientific papers.
There is no answer in this article, but the evidence given says "maybe".
I'd like to see Cassandra implemented in Go (currently its Java/JVM-based).
Why?
I would imagine his reasoning would be that Go handle concurrency and threading very efficiently and with a low memory footprint, while Java tends to use more memory.
Mainly to see if it would have better GC ability than Cassandra.
I love Cassandra, and the JVM is solid too, but the "stop-the-world-pause" in it's current garbage collectors truly blows. All of that fast latency is for not if the JVM decides to spend a few seconds churning through garbage. :(
I've looked into Azul's Zing JVM, but it's basically only for beefy hardware (16+ cores and 32GB+ RAM), and it's also crazy expensive.
I love Cassandra, and the JVM is solid too, but the "stop-the-world-pause" in it's current garbage collectors truly blows. All of that fast latency is for not if the JVM decides to spend a few seconds churning through garbage. :(
I've looked into Azul's Zing JVM, but it's basically only for beefy hardware (16+ cores and 32GB+ RAM), and it's also crazy expensive.
> Mainly to see if it would have better GC ability than Cassandra.
Considering the naïvety of Go's GC (a non-generational, non-compacting, conservative, stop-the-world and broken-on-32b[0] mark&sweep)... I would tend to bet against it way sooner than on it.
And remember that goroutines use shared memory, so you can't have an emergent concurrent GC as in Erlang.
[0] http://utcc.utoronto.ca/~cks/space/blog/programming/GoLang32... https://groups.google.com/forum/?fromgroups#!topic/golang-nu...
Considering the naïvety of Go's GC (a non-generational, non-compacting, conservative, stop-the-world and broken-on-32b[0] mark&sweep)... I would tend to bet against it way sooner than on it.
And remember that goroutines use shared memory, so you can't have an emergent concurrent GC as in Erlang.
[0] http://utcc.utoronto.ca/~cks/space/blog/programming/GoLang32... https://groups.google.com/forum/?fromgroups#!topic/golang-nu...
Currently most commercial JVMs beat down Go's GC with hands down, specially in 32 bit machines.
I've never used Cassandra, but from what I'd read about Netflix and other's use of it, everyone used at least 32GB of RAM in each node?
Am I totally wrong?
Am I totally wrong?
So, there's a difference between "how much RAM is in the box", and "how much RAM is allocated to the JVM".
The latter is where Azul Zing requires a lot of RAM to operate, as I understand it.
The recommended RAM for the JVM heap running Cassandra is 8GB, and 4GB isn't uncommon in the cloud. Netflix uses 12GB, and is contemplating going back to 8GB (they made that decision awhile ago, and things have changed since then).
I have boxes that run JVM heaps as low as 2GB just fine. It really just depends on how you're using it. (I've heard of people using 256MB heaps with Cassandra.)
The latter is where Azul Zing requires a lot of RAM to operate, as I understand it.
The recommended RAM for the JVM heap running Cassandra is 8GB, and 4GB isn't uncommon in the cloud. Netflix uses 12GB, and is contemplating going back to 8GB (they made that decision awhile ago, and things have changed since then).
I have boxes that run JVM heaps as low as 2GB just fine. It really just depends on how you're using it. (I've heard of people using 256MB heaps with Cassandra.)
I was under the impression that Cassandra used concurrent mark and sweep (i.e. -XX:+UseConcMarkSweepGC) as the default setting.
I does, but that's still not pause-less, and it doesn't cover a "full" collection at all, just the intermediate ones.
I get a full collection roughly once every 10 minutes. Until then, the pauses are only in the 20-30ms range (which is still double the usual latency for a request).
With Azul Zing, the longest you'll ever see is the 20-30ms range, and it's virtually always around 1ms.
I get a full collection roughly once every 10 minutes. Until then, the pauses are only in the 20-30ms range (which is still double the usual latency for a request).
With Azul Zing, the longest you'll ever see is the 20-30ms range, and it's virtually always around 1ms.
It's all about the libraries, Python and C for example have libraries/bindings for most things, e.g. Postgresql, ZMQ, Json etc. Google could invent the best programming language ever but without _mature_ _robust_ libraries it is pretty much useless.
Go has a pretty decent standard library.
http://golang.org/pkg/
http://golang.org/pkg/
Unfortunately, it seems to be lacking many useful data structures. This bites you hard once you hit the limitations of the built-ins.
Which data structures have you personally been bitten by that lack of?
I ask this because I often find myself thinking I would want such-and-such a feature in a tool, library, etc, but unless it was implemented in response to an immediate need, when I actually add it I realize it ends up unused.
I ask this because I often find myself thinking I would want such-and-such a feature in a tool, library, etc, but unless it was implemented in response to an immediate need, when I actually add it I realize it ends up unused.
I mostly wanted some better set and map container implementations (hashtables, binary search trees, tries); the built-in map can't be applied to all types, and is quite limited in how configurable it is. Given that we were going to be using these data structures everywhere, we decided Go was a bad choice for our project.
My guess is that better containers aren't in the library because of the lack of generics. I really hope the Go folks get around to adding generics soon; it's a beautiful language in most other respects. It would definitely be one of my first choices for a more systems-y project.
My guess is that better containers aren't in the library because of the lack of generics. I really hope the Go folks get around to adding generics soon; it's a beautiful language in most other respects. It would definitely be one of my first choices for a more systems-y project.
Yes it looks good, but what about mature 3rd party libraries?
Good software takes time. Asking a new programming language to have "mature 3rd party libraries" is a bit harsh. You are, of course, correct in that the variety of libraries available in Go is more limited than older languages, but I have hope that it will change rapidly.
http://www.joelonsoftware.com/articles/fog0000000017.html
http://www.joelonsoftware.com/articles/fog0000000017.html
I am not asking it to have anything, the article is insulating that GO is the new go to language, it is not because it doesn't have mature and comprehensive libraries. When I make a decision to use a particular language I don't wan't to handicap myself, you need as much edge as possible. In 10 years maybe Go will have a vast array of mature libs but until then I shall be choosing Python and C.
I hesitate to contradict you, but the title and content of the article is steeped in the future tense.
Its a good opportunity to contribute!
This is one of the main reasons that I use Go. Its libraries are of significantly higher quality than most other languages. And since most libraries are native, it's much easier to expand on their capabilities without having to resort to forking some C extension like with Python.
Go does have quite a few bindings that exist already for many commonly-used libraries (and some not-so-commonly-used). I'm pretty glad there are Lua bindings, for example. When Go makes more sense than C but Lua makes more sense than Go, I was kind of stuck until I discovered this.
Here is a listing I know of, this probably isn't comprehensive:
http://go-lang.cat-v.org/library-bindings
Here is a listing I know of, this probably isn't comprehensive:
http://go-lang.cat-v.org/library-bindings
That is a list of wrappers for C libraries, there are even more pure-Go libraries:
http://go-lang.cat-v.org/pure-go-libs
And I maintain both pages, and I have to confess they are badly outdated because is hard to keep up with all the libraries that are being written.
http://go-lang.cat-v.org/pure-go-libs
And I maintain both pages, and I have to confess they are badly outdated because is hard to keep up with all the libraries that are being written.
The "Talks and Videos" page (http://go-lang.cat-v.org/talks/) is outdated as well. Here's my personal list:
Why Learn Go? http://www.youtube.com/watch?v=FTl0tl9BGdc Short interview with Rob Pike, OSCON 2012
Get Started with Go http://www.youtube.com/watch?v=2KmHtgtEZ1s Andrew Gerrand
A Tour of Go http://www.youtube.com/watch?v=ytEkHepK08c Russ Cox
Go Concurrency Patterns http://www.youtube.com/watch?v=f6kdp27TYZs Rob Pike, Google I/O 2012 Goroutines, Channels
Meet the Go Team http://www.youtube.com/watch?v=sln-gJaURzk Panel (Pike, Thompson, Griesemer, Gerrand, Fitzpatrick, Simons), Google I/O 2012
Computing Map Tiles with Go on App Engine http://www.youtube.com/watch?v=sPagpg0b7no Chris Broadfoot, Andrew Gerrand, Google I/O 2012
Go in Production http://www.youtube.com/watch?v=kKQLhGZVN4A Gustavo Niemeyer, Google I/O 2012
Go: Code that grows with grace http://vimeo.com/42146678 (Contains some audio glitches) Andrew Gerrand
Interview with Rob Pike http://www.infoq.com/interviews/pike-google-go/ Rob Pike, GOTO Conference
Lexical Scanning in Go http://www.youtube.com/watch?v=HxaD_trXwRE Rob Pike
Cuddle, A Go AppEngine Demo http://www.youtube.com/watch?v=HQtLRqqB-Kk Andrew Gerrand
Building Integrated Apps on Google's Cloud Platform http://www.youtube.com/watch?v=Mo1YKpIF1PQ Andrew Gerrand, Google Developer Day Japan 2011
Real World Go http://www.youtube.com/watch?v=7QDVRowyUQA Andrew Gerrand, I/O BootCamp 2011
Go: it's that simple?! http://www.youtube.com/watch?v=LWpm1qpWRwA Andrew Gerrand, OSDC 2011
Practical Go Programming http://www.youtube.com/watch?v=2-pPAvqyluI Andrew Gerrand, FOSDEM 2011
Writing Web Apps in Go http://www.youtube.com/watch?v=-i0hat7pdpk Andrew Gerrand, Rob Pike, Google I/O 2011
Go Programming http://www.youtube.com/watch?v=jgVhBThJdXc Rob Pike, Google I/O 2010
Another Go at Language Design http://www.youtube.com/watch?v=7VcArS4Wpqk Rob Pike, Stanford University
Public Static Void http://www.youtube.com/watch?v=5kj5ApnhPAE Rob Pike, OSCON 2010
The Go Programming Language http://www.youtube.com/watch?v=rKnDgT73v8s Rob Pike, Google Tech Talk
Why Learn Go? http://www.youtube.com/watch?v=FTl0tl9BGdc Short interview with Rob Pike, OSCON 2012
Get Started with Go http://www.youtube.com/watch?v=2KmHtgtEZ1s Andrew Gerrand
A Tour of Go http://www.youtube.com/watch?v=ytEkHepK08c Russ Cox
Go Concurrency Patterns http://www.youtube.com/watch?v=f6kdp27TYZs Rob Pike, Google I/O 2012 Goroutines, Channels
Meet the Go Team http://www.youtube.com/watch?v=sln-gJaURzk Panel (Pike, Thompson, Griesemer, Gerrand, Fitzpatrick, Simons), Google I/O 2012
Computing Map Tiles with Go on App Engine http://www.youtube.com/watch?v=sPagpg0b7no Chris Broadfoot, Andrew Gerrand, Google I/O 2012
Go in Production http://www.youtube.com/watch?v=kKQLhGZVN4A Gustavo Niemeyer, Google I/O 2012
Go: Code that grows with grace http://vimeo.com/42146678 (Contains some audio glitches) Andrew Gerrand
Interview with Rob Pike http://www.infoq.com/interviews/pike-google-go/ Rob Pike, GOTO Conference
Lexical Scanning in Go http://www.youtube.com/watch?v=HxaD_trXwRE Rob Pike
Cuddle, A Go AppEngine Demo http://www.youtube.com/watch?v=HQtLRqqB-Kk Andrew Gerrand
Building Integrated Apps on Google's Cloud Platform http://www.youtube.com/watch?v=Mo1YKpIF1PQ Andrew Gerrand, Google Developer Day Japan 2011
Real World Go http://www.youtube.com/watch?v=7QDVRowyUQA Andrew Gerrand, I/O BootCamp 2011
Go: it's that simple?! http://www.youtube.com/watch?v=LWpm1qpWRwA Andrew Gerrand, OSDC 2011
Practical Go Programming http://www.youtube.com/watch?v=2-pPAvqyluI Andrew Gerrand, FOSDEM 2011
Writing Web Apps in Go http://www.youtube.com/watch?v=-i0hat7pdpk Andrew Gerrand, Rob Pike, Google I/O 2011
Go Programming http://www.youtube.com/watch?v=jgVhBThJdXc Rob Pike, Google I/O 2010
Another Go at Language Design http://www.youtube.com/watch?v=7VcArS4Wpqk Rob Pike, Stanford University
Public Static Void http://www.youtube.com/watch?v=5kj5ApnhPAE Rob Pike, OSCON 2010
The Go Programming Language http://www.youtube.com/watch?v=rKnDgT73v8s Rob Pike, Google Tech Talk
I haven't 'diff'-ed these two lists but a similar listing of Go-related talks can be found on Go community's unofficial wiki: https://code.google.com/p/go-wiki/wiki/GoTalks
Nice, im worried that due to Go's young age the libraries might be a bit flaky or lacking, I could be wrong though.
It's a chicken/egg thing. People will use Go for projects that its existing libraries can handle. That will be more people as the libraries expand. Given the extent of today's libraries I'd say that Go is useful for plenty of projects.
This can be said about pretty much any language in their infancy, it is not a setback, just a matter of time and getting attention from the community (and Go is getting a lot).
Can anyone confirm that 32-bit problems still exist concerning memory leaks and cgo? If so, this would confirm that it isn't a cross-platform "go-to programming language".
I don't see it happening in the near future but it might.
For those wanting to learn more Go I recommend this online book: http://www.golang-book.com/
Is Google behind all this hype ? There isn't a day without a Go article somewhere.
For small ad-hoc multi-processing servers that web shops are writing. Maybe, that seems like a good use case. Not as exotic as Erlang, and not a very demanding environment.
No big chance for enterprise or academia. And I believe that for ordinary "check this, forward that" backend programming, Ruby, Python and Perl will still remain staples, with a few percentage points shifting back and forth, as usual. Rails didn't end Python.
On the other hand, I wouldn't shed a tear if it would eat up the majority of node.js' marketshare.
No big chance for enterprise or academia. And I believe that for ordinary "check this, forward that" backend programming, Ruby, Python and Perl will still remain staples, with a few percentage points shifting back and forth, as usual. Rails didn't end Python.
On the other hand, I wouldn't shed a tear if it would eat up the majority of node.js' marketshare.
Enterprise here. We're knocking huge monolithic applications sitting on CLR and JVM processes into greater numbers of smaller stand-alone components (SOA style). Go fits here very well indeed.
Our authentication, filestore, directory services, messaging and web front end are all easy targets.
Our authentication, filestore, directory services, messaging and web front end are all easy targets.
As an absolute amateur in programming i was surprised that i could master Go syntax(in the sense of not having to check back in the notes) in under 2 hours of practice.
Go is awesome, but why must we limit ourselves to one language?!
My dev plan used to be Python for rapid prototyping and C for speed optimization. With the advent of Go, I find I'm moving the infrastructure-level Python work into Go and replacing many of the C-oriented middleware tasks with it as well. I'm sure this will evolve as the libraries grow, but I don't see Python & C going away. Nor do I think this is the vision at Google. I suppose this is what is meant by "systems language".
I think Go could end up being the under 35-generation's version of Lisp (in terms of love affair with language structure, etc.).
My dev plan used to be Python for rapid prototyping and C for speed optimization. With the advent of Go, I find I'm moving the infrastructure-level Python work into Go and replacing many of the C-oriented middleware tasks with it as well. I'm sure this will evolve as the libraries grow, but I don't see Python & C going away. Nor do I think this is the vision at Google. I suppose this is what is meant by "systems language".
I think Go could end up being the under 35-generation's version of Lisp (in terms of love affair with language structure, etc.).
Things Go got right;
1. Go doesn't discard the last 40+ years of programming history. Ints, chars, arrays, pointers, structs -- in addition to minimalist types that build on these -- are at the heart of Go's lexicon.
2. Following off of point 1: C and C++ source code and algorithms are easily translatable into Go because they look like Go.
3. Following off of point 2: Because old C/C++ code looks similar to Go, Go's libraries will soon number C/C++.
4. A well thought-out, minimalist toolchain. Working with "go install", vim, and gocode is like dancing in the clouds when compared with the morass that is Eclipse or Visual Studio, let alone C/C++ and its makefiles.
5. Go's object-orientation is done right. Go strongly emphasizes "has-a" relations and eschews the "is-a" relations that are prevalent in C# and Java. To see the effect this has on code readability, look at Go's documentation. For example, http://golang.org/pkg/database/sql/ ...scanning one page tells one all that's needs to be known about a package. Go's objects ride just above atomic data structures. There is not a five-mile chain of object dependencies and corresponding taxonomy clouding one's understanding as in C# or Java.
6. Go's channels give the programmer their very own ksh/bash built right in to the language. Admittedly, this is an oversimplification, but piping program units together is a proven method of strongly modularizing applications and has the added benefit of being inherently concurrent. Languages have been moving away from the shell for decades and have in the process lost its advantages.
(With all that said in point 6, there is still room for something like a lightweight, cross-platform, glue-language similar to bash/ksh that -- like Go -- does not throw out 40+ years of shell history. Unsung Tcl/Tk (http://www.softpanorama.org/Scripting/tcl.shtml) and Expect seems to fit the bill the closest currently, though it does not read like the C family of languages. Perhaps if someone were to build a Go shell, or create a cshell that used used Go's conventions, Go would have a good glue-language counterpart.)
1. Go doesn't discard the last 40+ years of programming history. Ints, chars, arrays, pointers, structs -- in addition to minimalist types that build on these -- are at the heart of Go's lexicon.
2. Following off of point 1: C and C++ source code and algorithms are easily translatable into Go because they look like Go.
3. Following off of point 2: Because old C/C++ code looks similar to Go, Go's libraries will soon number C/C++.
4. A well thought-out, minimalist toolchain. Working with "go install", vim, and gocode is like dancing in the clouds when compared with the morass that is Eclipse or Visual Studio, let alone C/C++ and its makefiles.
5. Go's object-orientation is done right. Go strongly emphasizes "has-a" relations and eschews the "is-a" relations that are prevalent in C# and Java. To see the effect this has on code readability, look at Go's documentation. For example, http://golang.org/pkg/database/sql/ ...scanning one page tells one all that's needs to be known about a package. Go's objects ride just above atomic data structures. There is not a five-mile chain of object dependencies and corresponding taxonomy clouding one's understanding as in C# or Java.
6. Go's channels give the programmer their very own ksh/bash built right in to the language. Admittedly, this is an oversimplification, but piping program units together is a proven method of strongly modularizing applications and has the added benefit of being inherently concurrent. Languages have been moving away from the shell for decades and have in the process lost its advantages.
(With all that said in point 6, there is still room for something like a lightweight, cross-platform, glue-language similar to bash/ksh that -- like Go -- does not throw out 40+ years of shell history. Unsung Tcl/Tk (http://www.softpanorama.org/Scripting/tcl.shtml) and Expect seems to fit the bill the closest currently, though it does not read like the C family of languages. Perhaps if someone were to build a Go shell, or create a cshell that used used Go's conventions, Go would have a good glue-language counterpart.)
> Go doesn't discard the last 40+ years of programming history
Except for:
- enumerations
- exceptions
- generics
- dynamic modules
- ...
Except for:
- enumerations
- exceptions
- generics
- dynamic modules
- ...
Well he said it didn't discard the last 40+ years of programming history, he didn't say anything about the last 30 of those.
- iota
- http://golang.org/doc/go_faq.html#exceptions
- http://golang.org/doc/go_faq.html#genericsiota is a poor man's solution compared with what real enumerations are
http://en.wikipedia.org/wiki/Enumerated_type
As for the other two links Go fanboys like to throw them around to feel happy that they beloved language is comparable to programming languages developed in the 70's.
http://en.wikipedia.org/wiki/Enumerated_type
As for the other two links Go fanboys like to throw them around to feel happy that they beloved language is comparable to programming languages developed in the 70's.
Ignoring and being selective are different things. The golang designers have made intentional choices and the reasoning is provided in the links I sent. I am not a fanboy. IMHO, Go would have been MUCH more interesting if goroutines did not run in a shared address space and if they implemented generics (even as a hygenic macro..)
The things that you left off your list that I think are much more interesting are:
The things that you left off your list that I think are much more interesting are:
- Weak/Strong purity, enforced by the type system
- uniqueness typing
- chan is too special. The difficulty with implementing a good netchan interface is starting to show this.[deleted]
I can't use Go until they fix the whitespace bug:
http://zackarymorris.tumblr.com/post/26701252898/a-mistake-i...
But other than that, it looks like a very tasteful language and I want to use it for some parallel computation experiments since they make it so easy to spin off tasks.
http://zackarymorris.tumblr.com/post/26701252898/a-mistake-i...
But other than that, it looks like a very tasteful language and I want to use it for some parallel computation experiments since they make it so easy to spin off tasks.
Wow... I don't understand diving into a language like this without reading about or looking at other source code already written in the language. This is not a bug! Golang enforces certain formatting, it is very opinionated and the authors are very upfront about that. http://golang.org/doc/effective_go.html#formatting
Also, you can use the `gofmt` tool (when running Go on your local machine) to help you learn what Go prefers if you don't want to read all of the excellent documentation on the site. [EDIT: I see you already know about this tool but I'll leave this comment here for others]
Also, you can use the `gofmt` tool (when running Go on your local machine) to help you learn what Go prefers if you don't want to read all of the excellent documentation on the site. [EDIT: I see you already know about this tool but I'll leave this comment here for others]
Rules about whitespace seem like an awfully superficial reason to dismiss an entire language. Do the other benefits not outweigh that?
summary: Click-bait title, content-free article, great language, excellent conversation in (HN) comments.
Oh, and here's a pretty good comment on the article regarding static vs dynamic typing:
eamonnerbonne Thursday, September 13 2012
It’s a night and day difference. Let me try a writing
analogy with Word + Notepad.
Say you’re trying to write a text for a particularly
picky client that will reject your text if you make any
mistake or use any unclear phrase. Then dynamic typing is
like Notepad: you better be careful, have lots of
proofreaders, and expect to have your text rejected
often. And when you print it, it’s in a slow-to-read
monospaced font.
Static typing is like Word with all the grammar checking
turned up to 11 (it won’t let you print or email any text
with what it thinks is an error). It’s harder to learn,
and sometimes your PC runs slowly, and the grammar
checker will find lots of irrelevant stuff, and to keep
it happy you might need to change your style, but it
*will* make certain types of error irrelevant (e.g.
spelling), and occasionally catch more complicated
mistakes too. Also, as a bonus that might or might not be
relevant, word prints in a font you can read much more
quickly.
The point being: they’re totally different ways of doing
things.
The following features make Go as the "go-to" language for me:
1.Coroutines, Channels and Select: Concurrency with built in synchronization and communication is accessible(especially if your are new to concurrent programming) enough to handle "most" of the grunt work. 2.gofmt: Formats your code for you. No more debates(procrastination) on that. 3.godoc: Generates documents. No more looking for the best 3rd party tool and wasting time. 4. Defer and Close: Helps you to do better post-operation tasks i.e better resource management. 5. Error Handling: Multivalue returns. 6. Type Hierarchy: No type hierarchy exists in the conventional sense. 7. Slices & Maps: Just two of them, and that's why I love it. 8. Brevity and Readability: Clutter free syntax. WYSISWYG language. 9. Philosophy of Exclusiveness: This is most important non-feature which makes Go different and exciting. Go's vision is to be an exclusive programming paradigm rather than being an inclusive one. In this Google I/O video: http://www.youtube.com/watch?v=sln-gJaURzk, Robert Griesemer speaks about an incident that how in a "D" programming conference, the developers intended to include a new programming paradigm in the future. This is what sold it for me as I care more about how the language will grow instead of what new cool features will come in.
Performance is a contentious issue. In an ideal world, performance would just depend on the platform and the language, but in reality it also depends on the skill and idiosyncrasies of the programmer. For me, that is a non-issue.
Quick Reference to Go talks: http://code.google.com/p/go-wiki/wiki/GoTalks
1.Coroutines, Channels and Select: Concurrency with built in synchronization and communication is accessible(especially if your are new to concurrent programming) enough to handle "most" of the grunt work. 2.gofmt: Formats your code for you. No more debates(procrastination) on that. 3.godoc: Generates documents. No more looking for the best 3rd party tool and wasting time. 4. Defer and Close: Helps you to do better post-operation tasks i.e better resource management. 5. Error Handling: Multivalue returns. 6. Type Hierarchy: No type hierarchy exists in the conventional sense. 7. Slices & Maps: Just two of them, and that's why I love it. 8. Brevity and Readability: Clutter free syntax. WYSISWYG language. 9. Philosophy of Exclusiveness: This is most important non-feature which makes Go different and exciting. Go's vision is to be an exclusive programming paradigm rather than being an inclusive one. In this Google I/O video: http://www.youtube.com/watch?v=sln-gJaURzk, Robert Griesemer speaks about an incident that how in a "D" programming conference, the developers intended to include a new programming paradigm in the future. This is what sold it for me as I care more about how the language will grow instead of what new cool features will come in.
Performance is a contentious issue. In an ideal world, performance would just depend on the platform and the language, but in reality it also depends on the skill and idiosyncrasies of the programmer. For me, that is a non-issue.
Quick Reference to Go talks: http://code.google.com/p/go-wiki/wiki/GoTalks
No. Not for me, anyway.
Go seems okay. I tried to write a few small programs in it but spent a lot of time hunting around in the manual for how to do things. D (as in dlang.org) has a very similar feature set (static but not annoying typing, lightweight threads, value types, GC, native high-level arrays, yaddah yaddah) but is more familiar to us C/Java programmers. One feeling I get is that Go exposes a lot of quirks (e.g. the 'make' function and inter-thread messaging) in the syntax of the language, whereas D takes care of those cases with regular library functions. I was impressed that while writing my first D program I rarely committed any syntax errors, as I found it an intuitive extension of Java/C syntax. So if anything is to by my next go-to language, it's more likely to be D than Go. Or does that make it a d-to language? Ha ha ha heh hrm cough.
Go seems okay. I tried to write a few small programs in it but spent a lot of time hunting around in the manual for how to do things. D (as in dlang.org) has a very similar feature set (static but not annoying typing, lightweight threads, value types, GC, native high-level arrays, yaddah yaddah) but is more familiar to us C/Java programmers. One feeling I get is that Go exposes a lot of quirks (e.g. the 'make' function and inter-thread messaging) in the syntax of the language, whereas D takes care of those cases with regular library functions. I was impressed that while writing my first D program I rarely committed any syntax errors, as I found it an intuitive extension of Java/C syntax. So if anything is to by my next go-to language, it's more likely to be D than Go. Or does that make it a d-to language? Ha ha ha heh hrm cough.
Why would you write critical software on a language developed by one company that has a habit of dropping projects once they get bored with them?
As the consternation of C# developers about windows 8, and java developers about Oracle lawsuits, relying on a language that a single company makes is foolish - especially companies that have a track record of abandoning projects.
I think C++11 will be the new go to language. It is standardized. As Moore's law runs out for single cores, C++ is positioned as the language that can run fast on a single process and scale easily to multicore
As the consternation of C# developers about windows 8, and java developers about Oracle lawsuits, relying on a language that a single company makes is foolish - especially companies that have a track record of abandoning projects.
I think C++11 will be the new go to language. It is standardized. As Moore's law runs out for single cores, C++ is positioned as the language that can run fast on a single process and scale easily to multicore
The speed of development is far better than any other language I've experienced. I use it as a replacement for C++ and Bash, a statement I don't think you could make about any other language. Apart from the lowest-level kernel work and the highest-performance code, I think Go will become the NBL. Even on the subject of performance, Go is improving quickly, and if you're using it as a replacement for, say Python, your performance will be substantially improved anyway.
Its simplicity is astonishing. Very few things will surprise you whilst coding, although a few topics take a while to learn. I know many hackers try to work in accordance with the phrase "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.". I cannot think of anything Go has that it doesn't need. Not even goto :P
http://www.quotationspage.com/quote/26979.html http://golang.org/ref/spec#Goto_statements