5 ms·

"The only problem that I have ever heard as being at least in the sights of Go was the 'building parallel applications' problem" That's only a small part of it

by enneff 16y ago

"The only problem that I have ever heard as being at least in the sights of Go was the 'building parallel applications' problem" That's only a small part of it. It's also designed to be less confusing than C++, and more flexible and faster than Java. As a result, it's actually a very different kind of language. Feels like a scripting language, but you get static typing and the performance of a compiled language. Lots of smart programmers are finding good use for Go, so your comments seem like unnecessary and misplaced negativity to me.

jbarham 16y ago
> Feels like a scripting language, but you get static typing and the performance of a compiled language. Exactly. I'm a longtime enthusiastic Python programmer and reluctant C++ programmer, and for me Go is the first language that could realistically replace both Python and C++ for my programming. For me the killer features of Go are: - Go code is almost as compact as Python but--especially for numeric code--much, much faster. - You never have to wait for the compiler! Everything I've written compiles and links in a fraction of a second. - Easy CSP-style concurrency: goodbye races and deadlocks w/ threaded code. Note too that, apart from the C runtime and low-level OS interfacing stuff, the entire Go standard library is written in Go itself. Contrast this w/ "scripting"/dynamic languages like Python or Ruby where much of the standard library has to be written in C for performance. (FWIW I have published some open source Go code on Github at http://github.com/jbarham http://github.com/jbarham and the beginnings of an AWS library at http://code.google.com/p/goaws/. http://code.google.com/p/goaws/.)
- runT1ME 16y ago
  Go isn't the only language that matches those requirements though. I took a long hard look at Go for very similar reasons and ended up deciding on Scala. It feels like a scripting language, incredible performance, extremely compact code when you need it to be, actors. >Easy CSP-style concurrency: goodbye races and deadlocks w/ threaded code. I actually disagree with this, CSP style, actors, message passing, you still have potential race conditions and deadlocks. What you gain is a nice separation between what is shared and what isn't. Just don't think Go's concurrency is the many-core silver bullet anymore than locks or Tx Memory is...

by enneff 16y ago

jbarham 16y ago

> Feels like a scripting language, but you get static typing and the performance of a compiled language. Exactly. I'm a longtime enthusiastic Python programmer and reluctant C++ programmer, and for me Go is the first language that could realistically replace both Python and C++ for my programming. For me the killer features of Go are: - Go code is almost as compact as Python but--especially for numeric code--much, much faster. - You never have to wait for the compiler! Everything I've written compiles and links in a fraction of a second. - Easy CSP-style concurrency: goodbye races and deadlocks w/ threaded code. Note too that, apart from the C runtime and low-level OS interfacing stuff, the entire Go standard library is written in Go itself. Contrast this w/ "scripting"/dynamic languages like Python or Ruby where much of the standard library has to be written in C for performance. (FWIW I have published some open source Go code on Github at http://github.com/jbarham http://github.com/jbarham and the beginnings of an AWS library at http://code.google.com/p/goaws/. http://code.google.com/p/goaws/.)

runT1ME 16y ago
Go isn't the only language that matches those requirements though. I took a long hard look at Go for very similar reasons and ended up deciding on Scala. It feels like a scripting language, incredible performance, extremely compact code when you need it to be, actors. >Easy CSP-style concurrency: goodbye races and deadlocks w/ threaded code. I actually disagree with this, CSP style, actors, message passing, you still have potential race conditions and deadlocks. What you gain is a nice separation between what is shared and what isn't. Just don't think Go's concurrency is the many-core silver bullet anymore than locks or Tx Memory is...