6 ms·

Yes. 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

by Jabbles 14y ago

Yes. 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://www.quotationspage.com/quote/26979.html http://golang.org/ref/spec#Goto_statements http://golang.org/ref/spec#Goto_statements

ajross 14y ago
> 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.)
- redbad 14y ago
  > someone has said exactly that about, and I'm really not > kidding, every newly popular language over the last 20 > years. That's probably true, and I grok your point, but pretty much everyone who's using Go in a production environment cites speed of development among the major, top-N reasons they're using the language. Past a certain threshold, there's something there that can't be hand-waved away. > Programming languages can make the easy stuff easy. > They can't fix our own stupidity. One of the neat things about Go, in my opinion, is that it converts a lot of "hard stuff" to "easy stuff", especially in the domain of concurrency, simply by the nature of its idioms.
  - deleted 14y ago
    [deleted]
  - ajross 14y ago
    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.
    - Jabbles 14y ago
      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 :)
markmm 14y ago
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.
- tocomment 14y ago
  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)
  - eckyptang 14y ago
    It can call into C easily: http://golang.org/cmd/cgo/ http://golang.org/cmd/cgo/
    - protobluffers 14y ago
      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.
gaius 14y ago
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.
- j2labs 14y ago
  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.
  - tptacek 14y ago
    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.
    - j2labs 14y ago
      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.
      - tptacek 14y ago
        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.
slurgfest 14y ago
'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.
- genwin 14y ago
  > 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.
  - mseebach 14y ago
    To continue your car analogy, buying a Porche isn't going to make you go faster if the route you're optimizing is across Los Angeles in rush hour.
    - genwin 14y ago
      True! But the whole cross-state trip likely has plenty of open road.
  - justinhj 14y ago
    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.
sbochins 14y ago
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).

by Jabbles 14y ago

ajross 14y ago

> 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.)

redbad 14y ago
> someone has said exactly that about, and I'm really not > kidding, every newly popular language over the last 20 > years. That's probably true, and I grok your point, but pretty much everyone who's using Go in a production environment cites speed of development among the major, top-N reasons they're using the language. Past a certain threshold, there's something there that can't be hand-waved away. > Programming languages can make the easy stuff easy. > They can't fix our own stupidity. One of the neat things about Go, in my opinion, is that it converts a lot of "hard stuff" to "easy stuff", especially in the domain of concurrency, simply by the nature of its idioms.
- deleted 14y ago
  [deleted]
- ajross 14y ago
  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.
  - Jabbles 14y ago
    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 :)

markmm 14y ago

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.

tocomment 14y ago
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)
- eckyptang 14y ago
  It can call into C easily: http://golang.org/cmd/cgo/ http://golang.org/cmd/cgo/
  - protobluffers 14y ago
    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.

gaius 14y ago

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.

j2labs 14y ago
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.
- tptacek 14y ago
  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.
  - j2labs 14y ago
    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.
    - tptacek 14y ago
      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.

slurgfest 14y ago

'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.

genwin 14y ago
> 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.
- mseebach 14y ago
  To continue your car analogy, buying a Porche isn't going to make you go faster if the route you're optimizing is across Los Angeles in rush hour.
  - genwin 14y ago
    True! But the whole cross-state trip likely has plenty of open road.
- justinhj 14y ago
  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.

sbochins 14y ago

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).