9 ms·

The Reliability of Go

150 points by exch 13y ago

kenkam 13y ago
I would like to hear more about the technical implementations from the author on how he managed to improve performance. He mentions: "Due to the complex nature of the system this script could take up to three minutes to scan nodes and process the results" but how does Go solve this complex system that Python couldn't? 3 minutes to 1 second is a superb improvement. The second paragraph reads like: replacing a relational DB with a (in memory?) key value store resulted in more throughput. He implemented it in Go, but he could have implemented it in any other language. What I want to know is how he convinced management to use Go? Where did he find the programmers? I work in a similar environment and I don't see my firm adopting Go any time soon, although I wished they had as I'm a big fan of Go and believe it has a place especially server side processes (e.g. algo trading, market data feeds) where concurrent connections are prevalent.
- deleted 13y ago
  [deleted]
- elithrar 13y ago
  > He implemented it in Go, but he could have implemented it in any other language I assume he used Go's concurrency features, although he could have articulated on that. > Where did he find the programmers I don't think you explicitly need to hire new programmers. If you have capable, existing programmers, the learning curve is pretty minimal for something like Go.
  - TheAnimus 13y ago
    >I assume he used Go's concurrency features, although he could have articulated on that. I've yet to find a good explanation of what is so special about them, why I'd choose it over F# or C# Async/Await. In the case of pinging servers, I would have prefered to use a 'cheaper' to develop language, which has a boatload of libraries that are widely used. Anyone got any links or stories about why you would want to use Go for something like that? I don't find this blog story remotely useful in the whole 'why Go' thing.
    - threeseed 13y ago
      This is a good overview of Go concurrency: http://www.slideshare.net/jgrahamc/go-oncurrency http://www.slideshare.net/jgrahamc/go-oncurrency As a Java developer I personally don't find it that impressive compared to something like the LMAX Disruptor or even Vert.x but I can appreciate that it is simple and that always counts for a lot.
      - randomsearch 13y ago
        As an Ada 95 developer, I like that Go seems to have an Adalite concurrency-related syntax.
        tptacek 13y ago
        Both systems have a CSP design, right? Golang is pretty up front about having lifted its design from Hoare.
        randomsearch 13y ago
        Yes, you're right - the design comes from CSP. The syntax looks nicely Adalike.
    - kenkam 13y ago
      I think async/await is semantically similar to the promises pattern [1] but different to the Go concurrent models using channels. What the compiler does with await/async is quite interesting [2]. Essentially it takes your await/async code and turns the related code into a state machine which keeps track of how control should be switched between the callee and the await keyword (and uses Task for the async bit). [1] http://blog.parse.com/2013/01/29/whats-so-great-about-javascript-promises/ http://blog.parse.com/2013/01/29/whats-so-great-about-javasc... [2] http://www.codeproject.com/Articles/535635/Async-Await-and-the-Generated-StateMachine http://www.codeproject.com/Articles/535635/Async-Await-and-t...
      - TheAnimus 13y ago
  - kenkam 13y ago
    I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.
    - Ecio78 13y ago
      Probably that would be the most interesting part of the story...
    - Stephen_C 13y ago
      Andy convinced management by spending a lot of personal development time creating and testing the Go components before demonstrating in a peer review process that they were an appropriate solution. There's no special method - the introduction of Go was incremental. If I remember correctly the monitoring collection component (mentioned in the blog post) was the first. It was small, easy to swap in and easy to demonstrate the improvements. You build trust in the technology and work flow before moving on to larger more critical/risky projects. (Andy is very much missed by his former colleagues)
      - j_s 13y ago
        Would be interesting to hear the details on management's side of the story: 'This guy re-wrote all our stuff in the new hotness then left the company'
        Stephen_C 13y ago
        Well what sort of story are you expecting to hear? Without going into detail it's not really that exciting. There was a requirement for high volume/through put messaging component in our infrastructure. That technological requirement (along with non functional requirements e.g. development time/costs) was more than adequately met by a program(s) written by a team member written in Go. Was it an opportunity to further explore the "new hotness" that is/was Go…absolutely but the solution could have been implemented in one of the other supported technologies C/C++/Java with appropriate advantages/disadvantages associated with each. It will stay in use for as long as it provides the best solution, if that changes a more appropriate solution will be investigated. > 'This guy re-wrote all our stuff in the new hotness then left the company' The Go dataStore is "a" component within a large infrastructure, it is supportable by more than one member of the development team (a core requirement when deploying any new technology to production). I'll also note that before Andy left, being a professional and thoughtful colleague, he put a lot of effort into ensuring appropriate training and knowledge was given to team members that had not been part of the deployment. As Andy is a very well regarded former colleague, it helps that we could easily get in touch for a query, even when we're out for a beer or five* :) (*five might not be a maximum in that scenario)
- deleted 13y ago
  [deleted]
- brown9-2 13y ago
  On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. As exciting as Go is it sounds like replacing the old script with a sufficiently concurrent and well-written application in any language should have worked well. More details would be really helpful. Also the author seems to be responding to a question of reliability by talking about performance which is not the same thing.
  - Stephen_C 13y ago
    I doubt Andy would disagree with you, it's no slight or bad commentary against Python (Andy was the cheerleader for introducing Python into our infrastructure where it is blossoming nicely). With sufficient development time Andy could have introduced more concurrency and optimisation into the Python monitoring component (I'm thinking Gevent might have been a nice fit)...but without introducing additional frameworks or libraries Go had these features as a core component. The offhand performance comment aside, Andy was noting that a component written in Go is depended on to handle VERY high volumes of message throughput in a financial services firm. While no proof of reliability it is merely anecdotal support that Go is being used in production environments.
  - coldtea 13y ago
    >On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. "Inadequate concurrency features" IS an inherent problem with Python The Language. (Notice I didn't say "inadequate use of concurrency features", I said "inadequate concurrency features").
    - Roboprog 13y ago
      It's been a while, but I remember that Python threads run into a global interpreter lock quite often, yes?
      - bvdbijl 13y ago
- codonaut 13y ago
  Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? Is there that much inherent instability in Python? Can it be assumed that the scripts in this case aren't comparable?
  - _pmf_ 13y ago
    > Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? It stalls in Python because the author is not acquainted with non-blocking system programming (the select()-call, which has been around since at least the eighties and has been a part of core Python since a very long time). As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question.
    - tptacek 13y ago
      It's funny how people who learn evented programming in scripting languages like Python feel like they've discovered some new hidden concept. No competent systems developer fails to understand what select() does. Suggesting that the author was't "acquainted" with select says more about this comment than about the author of the post it comments on.
    - coldtea 13y ago
      >It stalls in Python because the author is not acquainted with non-blocking system programming Citation needed. How about "he is acquainted but can't be bothered to use it retrofitted to a language not tailor made for it"? >As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question. And why you think you're any better than him based on a short blog post (and especially one in which he does not delve into why the Python version was slower or says it would be impossible to make it faster, just mentions it's speed in passing), is beyond me. Maybe cut down the snark?
  - Cowen 13y ago
    Without actually be able to see either script, I would assume that his Go implementation took advantage of some of Go's more natural concurrency features. The only reason I'd assume the Go version was concurrent and the Python one wasn't is that concurrent processing in Python can be very prickly. That is by design. Guido has talked about how adding too much support for concurrency at the language level would complicate things and probably end up with a language that was very non-Pythonic.
sergiotapia 13y ago
"Excellent tooling"; from the article. What does he mean? I've searched the Go websites but it seems all Google gives you is the Go compiler and a tour.
- exch 13y ago
  He is referring to the `go` command, which is a front end to all of go's build tools. http://golang.org/cmd/go/ http://golang.org/cmd/go/
- mseepgood 13y ago
  go doc, go fmt, go fix, go vet, go build, go run, go test, go get, go install, ... and present!
- ralph 13y ago
  The go command does more than just compile. http://golang.org/doc/cmd http://golang.org/doc/cmd
- r4um 13y ago
  Various go projects/tools are listed here http://code.google.com/p/go-wiki/wiki/Projects http://code.google.com/p/go-wiki/wiki/Projects
raverbashing 13y ago
I remember some time ago a complaint about Go having some bugs on 32-bit machines (something related to the GC) So yes, if you have control over your environment it may be a better choice But the biggest issue with 'less than mainstream' languages are libraries. Things like DB connectors, protocol libraries (SOAP for example - yes, unfortunately this is necessary for some 3rd part services), etc Heck, even for Python 2 (not to mention P3) this is an issue sometimes
- CountHackulus 13y ago
  Every compiler has bugs. All of them, even ICC, xlC, and other heavyweight ones. The fact that Go has a bug in the GC on a 32-bit machine is hardly surprising.
  - raverbashing 13y ago
    http://www.abtinforouzandeh.com/2012/04/08/Do-Not-Use-Go-For-32bit-Development.html http://www.abtinforouzandeh.com/2012/04/08/Do-Not-Use-Go-For...
  - Wilya 13y ago
    No need to split hairs. Go had an easy to run into and not obvious to fix bug on 32bit. That's a bigger problem than most gcc/ICC/whatever bugs, which tend to be happen in obscure corner cases (because the most obvious bugs are long gone).
- rubinelli 13y ago
  IIRC, Go tries to allocate a contiguous portion of virtual memory. This isn't a problem in 64-bit, because the addressable space is so big, but a 32-bit system that has been running for a while may have enough memory fragmentation that you can't allocate a large enough block. I have to agree about libraries. You don't realize how great it is to have finely-tuned JDBC drivers for every database on Earth until you can't use them.
- Titanous 13y ago
  This was mostly fixed in yesterday's 1.1 release: https://code.google.com/p/go/issues/detail?id=909 https://code.google.com/p/go/issues/detail?id=909
tezza 13y ago
If I had been at that conference, I would have asked the same question. Thanks for the data point (Yes, fine for production AFAYCT). What does Go do when it segfaults ? Simply saying it has not-yet-segfaulted is but one factor of production-readiness. Does Go leave just a coredump ? One thing I like about java in a production sense is that if the JVM exits unexpectedly it writes an hs_err_pid file that has a dump of what the threads are doing at the point of failure.
- 4ad 13y ago
  Go programs don't segfault because Go is a memory safe language (unless you use unsafe). They can segfault in the runtime, but that never happened to me. Nevertheless, what happens when you segfault is a property of the system, not of the language implementation. It will happen whatever happens to C programs that segfault. Go programs can panic but that doesn't produce a core dump, only a stacktrace.
  - pcwalton 13y ago
    I've heard conflicting things here. I was under the impression that Go was not memory safe while mutating maps without synchronization. For example, these articles allude to possible memory corruption: http://golang.org/doc/articles/race_detector.html http://golang.org/doc/articles/race_detector.html "memory corruption" http://golang.org/doc/faq#atomic_maps http://golang.org/doc/faq#atomic_maps http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article "Go is not purely memory safe in the presence of concurrency."
    - 4ad 13y ago
      You are correct, I was presenting a simplified view. While Go was designed with memory safety in mind, the specification does not guarantee memory safety. With that being said, it also doesn't preclude it (unlike C). For example, the gc implementation without parallelism (not to be confused with concurrency) is memory safe while the gc implementation with parallelism is not. This is the reason why GOMAXPROCS is always 1 in the playground and on the App Engine. There's nothing precluding a paralel implementation from also being memory safe.
reinhardt 13y ago
Somewhat off-topic but are there any data on the penetration of Go outside Google, a few other companies [1] and weekend hack projects on Github? Thanks to its unfortunate name, even searching for Go developer positions is challenging [2]. [1] http://go-lang.cat-v.org/organizations-using-go http://go-lang.cat-v.org/organizations-using-go [2] http://www.indeed.com/jobs?q=go+developer http://www.indeed.com/jobs?q=go+developer
- shocks 13y ago
  Use the keyword 'golang' instead. :)
  - why-el 13y ago
    This could have been a better name in my opinion. One should stay away from frequently used English words.
    - jmhain 13y ago
      Maybe they wanted the name to symbolize the syntactical terseness of the language, and every other two letter name had already been taken by unix utilities.
- BarkMore 13y ago
  List of organizations that use Go: https://code.google.com/p/go-wiki/wiki/GoUsers https://code.google.com/p/go-wiki/wiki/GoUsers
16s 13y ago
I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google). All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards). It bothers me to no end to see corporations taking control of the fundamental building blocks (programming languages) of technology and then to see technologists and developers go on and on about how wonderful and better these corporate languages are. With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not. Google already control your search, your browser, your phone, your email and in some cases your OS (Chrome) why would you want them to control you programming language as well? The idea boggles my mind. I wish others felt as strongly about this as I do. If you want to control your future, then use C or C++ or some other ISO standardized language with lot's of free compilers available, do not use a corporate controlled programming language. There is a reason go compilers are C and C++.
- tptacek 13y ago
  I too am upset at the prospect of annoying little text ads popping up in my source code. DOWN WITH GOLANG.
  - joshbaptiste 13y ago
    heh.. classic response
  - _pmf_ 13y ago
    > I too am upset at the prospect of annoying little text ads popping up in my source code. You are not using the correct term. In Web 2.0, these are not called "annoying", but "unobtrusive".
- exch 13y ago
  Go is completely open source. The primary devs just happen to work at Google. That is all. If anything, the Google name attachment may only serve to help convince management that Go is a safe, long-term bet. If you don't like the Google attachment, you are entirely free to fork the language and make it your own.
waterside81 13y ago
We moved a huge chunk of our code from Python to Go. We have one simple Go binary that just listens on a certain port and API requests from our Django app are proxied to the Go instance running. No issues, no panics, no memory leaks. It's pretty amazing to see a long running process never growing in memory (well, if you're coming from the Python world at least, I'm sure the JVM is pretty solid at keeping it's place nice & tidy). Folks - Go ain't a fad, it's a great language if your problem domain benefits from concurrency AND if you need to deploy to multiple locations and love being able to just drop a single binary and walk away.
- kamaal 13y ago
  How good is Go, as a replacement for Java?
  - beatgammit 13y ago
    What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interactions. I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. It's more suited for the server, but it can work well for computationally-intensive tasks as well. Go is better thought of as a replacement for whatever server stack you have than a replacement for a given language.
    - swah 13y ago
      But the runtime performance is probably closer to Java than Python...
      - beatgammit 13y ago
        Well, yeah, because Go is compiled, not interpreted. It's GC isn't as optimized as Java's, but for straight computational speed, it's pretty comparable to other compiled languages. It just isn't a drop-in replacement for Java because it doesn't live in the same space. It does, however, have a similar feel as Python, especially with slices (except Go's don't copy data) and first-order functions. It's a completely different feel though than Python.
moshberm 13y ago
What happens if Google decides to send Go the way of the RSS reader, the SMS search, and the dinosaur?
- Jtsummers 13y ago
  Nothing, it's not a service. The code is already out there along with the documentation and language spec. The worst they can do is: 1. Cancel their future contributions. 2. Create a closed source fork (is this feasible with the license if they don't control what others have contributed?) In the worst case, if there aren't enough go enthusiasts it goes the way of other niche languages. Since the supporters seem to be active enough, I doubt that'll happen.
koraytaylan 13y ago
first I saw go I thought meh but with so many people saying good things about it makes go inevitably more interesting day after day. however I just feel like it's going to be like mongo. when it first got popular, people all moved to mongo as it miraculously solving all the problems. same thing happening with go now and after sudden disappear of all the mongo evangelists, this makes me doubtful about go obviously.
- azth 13y ago
  IMO, people like hype, and a lot of the time, they are not aware of what better alternatives exist. If Go did not have Google or Ken or Pike as names behind it, do you think it would have gone anywhere? It doesn't really offer anything special compared to more expressive and safer languages like Scala and Rust for instance. You can see it right here in the comments: someone said that Go is a memory safe language. It is not any more safer than Java is in that regard. We need languages that are safer than Java and Go.

150 points by exch 13y ago

I would like to hear more about the technical implementations from the author on how he managed to improve performance. He mentions: "Due to the complex nature of the system this script could take up to three minutes to scan nodes and process the results" but how does Go solve this complex system that Python couldn't? 3 minutes to 1 second is a superb improvement. The second paragraph reads like: replacing a relational DB with a (in memory?) key value store resulted in more throughput. He implemented it in Go, but he could have implemented it in any other language. What I want to know is how he convinced management to use Go? Where did he find the programmers? I work in a similar environment and I don't see my firm adopting Go any time soon, although I wished they had as I'm a big fan of Go and believe it has a place especially server side processes (e.g. algo trading, market data feeds) where concurrent connections are prevalent.

deleted 13y ago
[deleted]
elithrar 13y ago
> He implemented it in Go, but he could have implemented it in any other language I assume he used Go's concurrency features, although he could have articulated on that. > Where did he find the programmers I don't think you explicitly need to hire new programmers. If you have capable, existing programmers, the learning curve is pretty minimal for something like Go.
- TheAnimus 13y ago
  >I assume he used Go's concurrency features, although he could have articulated on that. I've yet to find a good explanation of what is so special about them, why I'd choose it over F# or C# Async/Await. In the case of pinging servers, I would have prefered to use a 'cheaper' to develop language, which has a boatload of libraries that are widely used. Anyone got any links or stories about why you would want to use Go for something like that? I don't find this blog story remotely useful in the whole 'why Go' thing.
  - threeseed 13y ago
    This is a good overview of Go concurrency: http://www.slideshare.net/jgrahamc/go-oncurrency http://www.slideshare.net/jgrahamc/go-oncurrency As a Java developer I personally don't find it that impressive compared to something like the LMAX Disruptor or even Vert.x but I can appreciate that it is simple and that always counts for a lot.
    - randomsearch 13y ago
      As an Ada 95 developer, I like that Go seems to have an Adalite concurrency-related syntax.
      - tptacek 13y ago
        Both systems have a CSP design, right? Golang is pretty up front about having lifted its design from Hoare.
        randomsearch 13y ago
        Yes, you're right - the design comes from CSP. The syntax looks nicely Adalike.
  - kenkam 13y ago
    I think async/await is semantically similar to the promises pattern [1] but different to the Go concurrent models using channels. What the compiler does with await/async is quite interesting [2]. Essentially it takes your await/async code and turns the related code into a state machine which keeps track of how control should be switched between the callee and the await keyword (and uses Task for the async bit). [1] http://blog.parse.com/2013/01/29/whats-so-great-about-javascript-promises/ http://blog.parse.com/2013/01/29/whats-so-great-about-javasc... [2] http://www.codeproject.com/Articles/535635/Async-Await-and-the-Generated-StateMachine http://www.codeproject.com/Articles/535635/Async-Await-and-t...
    - TheAnimus 13y ago
- kenkam 13y ago
  I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.
  - Ecio78 13y ago
    Probably that would be the most interesting part of the story...
  - Stephen_C 13y ago
    Andy convinced management by spending a lot of personal development time creating and testing the Go components before demonstrating in a peer review process that they were an appropriate solution. There's no special method - the introduction of Go was incremental. If I remember correctly the monitoring collection component (mentioned in the blog post) was the first. It was small, easy to swap in and easy to demonstrate the improvements. You build trust in the technology and work flow before moving on to larger more critical/risky projects. (Andy is very much missed by his former colleagues)
    - j_s 13y ago
      Would be interesting to hear the details on management's side of the story: 'This guy re-wrote all our stuff in the new hotness then left the company'
      - Stephen_C 13y ago
        Well what sort of story are you expecting to hear? Without going into detail it's not really that exciting. There was a requirement for high volume/through put messaging component in our infrastructure. That technological requirement (along with non functional requirements e.g. development time/costs) was more than adequately met by a program(s) written by a team member written in Go. Was it an opportunity to further explore the "new hotness" that is/was Go…absolutely but the solution could have been implemented in one of the other supported technologies C/C++/Java with appropriate advantages/disadvantages associated with each. It will stay in use for as long as it provides the best solution, if that changes a more appropriate solution will be investigated. > 'This guy re-wrote all our stuff in the new hotness then left the company' The Go dataStore is "a" component within a large infrastructure, it is supportable by more than one member of the development team (a core requirement when deploying any new technology to production). I'll also note that before Andy left, being a professional and thoughtful colleague, he put a lot of effort into ensuring appropriate training and knowledge was given to team members that had not been part of the deployment. As Andy is a very well regarded former colleague, it helps that we could easily get in touch for a query, even when we're out for a beer or five* :) (*five might not be a maximum in that scenario)
deleted 13y ago
[deleted]
brown9-2 13y ago
On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. As exciting as Go is it sounds like replacing the old script with a sufficiently concurrent and well-written application in any language should have worked well. More details would be really helpful. Also the author seems to be responding to a question of reliability by talking about performance which is not the same thing.
- Stephen_C 13y ago
  I doubt Andy would disagree with you, it's no slight or bad commentary against Python (Andy was the cheerleader for introducing Python into our infrastructure where it is blossoming nicely). With sufficient development time Andy could have introduced more concurrency and optimisation into the Python monitoring component (I'm thinking Gevent might have been a nice fit)...but without introducing additional frameworks or libraries Go had these features as a core component. The offhand performance comment aside, Andy was noting that a component written in Go is depended on to handle VERY high volumes of message throughput in a financial services firm. While no proof of reliability it is merely anecdotal support that Go is being used in production environments.
- coldtea 13y ago
  >On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. "Inadequate concurrency features" IS an inherent problem with Python The Language. (Notice I didn't say "inadequate use of concurrency features", I said "inadequate concurrency features").
  - Roboprog 13y ago
    It's been a while, but I remember that Python threads run into a global interpreter lock quite often, yes?
    - bvdbijl 13y ago
codonaut 13y ago
Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? Is there that much inherent instability in Python? Can it be assumed that the scripts in this case aren't comparable?
- _pmf_ 13y ago
  > Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? It stalls in Python because the author is not acquainted with non-blocking system programming (the select()-call, which has been around since at least the eighties and has been a part of core Python since a very long time). As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question.
  - tptacek 13y ago
    It's funny how people who learn evented programming in scripting languages like Python feel like they've discovered some new hidden concept. No competent systems developer fails to understand what select() does. Suggesting that the author was't "acquainted" with select says more about this comment than about the author of the post it comments on.
  - coldtea 13y ago
    >It stalls in Python because the author is not acquainted with non-blocking system programming Citation needed. How about "he is acquainted but can't be bothered to use it retrofitted to a language not tailor made for it"? >As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question. And why you think you're any better than him based on a short blog post (and especially one in which he does not delve into why the Python version was slower or says it would be impossible to make it faster, just mentions it's speed in passing), is beyond me. Maybe cut down the snark?
- Cowen 13y ago
  Without actually be able to see either script, I would assume that his Go implementation took advantage of some of Go's more natural concurrency features. The only reason I'd assume the Go version was concurrent and the Python one wasn't is that concurrent processing in Python can be very prickly. That is by design. Guido has talked about how adding too much support for concurrency at the language level would complicate things and probably end up with a language that was very non-Pythonic.

sergiotapia 13y ago

"Excellent tooling"; from the article. What does he mean? I've searched the Go websites but it seems all Google gives you is the Go compiler and a tour.

exch 13y ago
He is referring to the `go` command, which is a front end to all of go's build tools. http://golang.org/cmd/go/ http://golang.org/cmd/go/
mseepgood 13y ago
go doc, go fmt, go fix, go vet, go build, go run, go test, go get, go install, ... and present!
ralph 13y ago
The go command does more than just compile. http://golang.org/doc/cmd http://golang.org/doc/cmd
r4um 13y ago
Various go projects/tools are listed here http://code.google.com/p/go-wiki/wiki/Projects http://code.google.com/p/go-wiki/wiki/Projects

raverbashing 13y ago

I remember some time ago a complaint about Go having some bugs on 32-bit machines (something related to the GC) So yes, if you have control over your environment it may be a better choice But the biggest issue with 'less than mainstream' languages are libraries. Things like DB connectors, protocol libraries (SOAP for example - yes, unfortunately this is necessary for some 3rd part services), etc Heck, even for Python 2 (not to mention P3) this is an issue sometimes

CountHackulus 13y ago
Every compiler has bugs. All of them, even ICC, xlC, and other heavyweight ones. The fact that Go has a bug in the GC on a 32-bit machine is hardly surprising.
- raverbashing 13y ago
  http://www.abtinforouzandeh.com/2012/04/08/Do-Not-Use-Go-For-32bit-Development.html http://www.abtinforouzandeh.com/2012/04/08/Do-Not-Use-Go-For...
- Wilya 13y ago
  No need to split hairs. Go had an easy to run into and not obvious to fix bug on 32bit. That's a bigger problem than most gcc/ICC/whatever bugs, which tend to be happen in obscure corner cases (because the most obvious bugs are long gone).
rubinelli 13y ago
IIRC, Go tries to allocate a contiguous portion of virtual memory. This isn't a problem in 64-bit, because the addressable space is so big, but a 32-bit system that has been running for a while may have enough memory fragmentation that you can't allocate a large enough block. I have to agree about libraries. You don't realize how great it is to have finely-tuned JDBC drivers for every database on Earth until you can't use them.
Titanous 13y ago
This was mostly fixed in yesterday's 1.1 release: https://code.google.com/p/go/issues/detail?id=909 https://code.google.com/p/go/issues/detail?id=909

tezza 13y ago

If I had been at that conference, I would have asked the same question. Thanks for the data point (Yes, fine for production AFAYCT). What does Go do when it segfaults ? Simply saying it has not-yet-segfaulted is but one factor of production-readiness. Does Go leave just a coredump ? One thing I like about java in a production sense is that if the JVM exits unexpectedly it writes an hs_err_pid file that has a dump of what the threads are doing at the point of failure.

4ad 13y ago
Go programs don't segfault because Go is a memory safe language (unless you use unsafe). They can segfault in the runtime, but that never happened to me. Nevertheless, what happens when you segfault is a property of the system, not of the language implementation. It will happen whatever happens to C programs that segfault. Go programs can panic but that doesn't produce a core dump, only a stacktrace.
- pcwalton 13y ago
  I've heard conflicting things here. I was under the impression that Go was not memory safe while mutating maps without synchronization. For example, these articles allude to possible memory corruption: http://golang.org/doc/articles/race_detector.html http://golang.org/doc/articles/race_detector.html "memory corruption" http://golang.org/doc/faq#atomic_maps http://golang.org/doc/faq#atomic_maps http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article "Go is not purely memory safe in the presence of concurrency."
  - 4ad 13y ago
    You are correct, I was presenting a simplified view. While Go was designed with memory safety in mind, the specification does not guarantee memory safety. With that being said, it also doesn't preclude it (unlike C). For example, the gc implementation without parallelism (not to be confused with concurrency) is memory safe while the gc implementation with parallelism is not. This is the reason why GOMAXPROCS is always 1 in the playground and on the App Engine. There's nothing precluding a paralel implementation from also being memory safe.

reinhardt 13y ago

Somewhat off-topic but are there any data on the penetration of Go outside Google, a few other companies [1] and weekend hack projects on Github? Thanks to its unfortunate name, even searching for Go developer positions is challenging [2]. [1] http://go-lang.cat-v.org/organizations-using-go http://go-lang.cat-v.org/organizations-using-go [2] http://www.indeed.com/jobs?q=go+developer http://www.indeed.com/jobs?q=go+developer

shocks 13y ago
Use the keyword 'golang' instead. :)
- why-el 13y ago
  This could have been a better name in my opinion. One should stay away from frequently used English words.
  - jmhain 13y ago
    Maybe they wanted the name to symbolize the syntactical terseness of the language, and every other two letter name had already been taken by unix utilities.
BarkMore 13y ago
List of organizations that use Go: https://code.google.com/p/go-wiki/wiki/GoUsers https://code.google.com/p/go-wiki/wiki/GoUsers

16s 13y ago

I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google). All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards). It bothers me to no end to see corporations taking control of the fundamental building blocks (programming languages) of technology and then to see technologists and developers go on and on about how wonderful and better these corporate languages are. With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not. Google already control your search, your browser, your phone, your email and in some cases your OS (Chrome) why would you want them to control you programming language as well? The idea boggles my mind. I wish others felt as strongly about this as I do. If you want to control your future, then use C or C++ or some other ISO standardized language with lot's of free compilers available, do not use a corporate controlled programming language. There is a reason go compilers are C and C++.

tptacek 13y ago
I too am upset at the prospect of annoying little text ads popping up in my source code. DOWN WITH GOLANG.
- joshbaptiste 13y ago
  heh.. classic response
- _pmf_ 13y ago
  > I too am upset at the prospect of annoying little text ads popping up in my source code. You are not using the correct term. In Web 2.0, these are not called "annoying", but "unobtrusive".
exch 13y ago
Go is completely open source. The primary devs just happen to work at Google. That is all. If anything, the Google name attachment may only serve to help convince management that Go is a safe, long-term bet. If you don't like the Google attachment, you are entirely free to fork the language and make it your own.

waterside81 13y ago

We moved a huge chunk of our code from Python to Go. We have one simple Go binary that just listens on a certain port and API requests from our Django app are proxied to the Go instance running. No issues, no panics, no memory leaks. It's pretty amazing to see a long running process never growing in memory (well, if you're coming from the Python world at least, I'm sure the JVM is pretty solid at keeping it's place nice & tidy). Folks - Go ain't a fad, it's a great language if your problem domain benefits from concurrency AND if you need to deploy to multiple locations and love being able to just drop a single binary and walk away.

kamaal 13y ago
How good is Go, as a replacement for Java?
- beatgammit 13y ago
  What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interactions. I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. It's more suited for the server, but it can work well for computationally-intensive tasks as well. Go is better thought of as a replacement for whatever server stack you have than a replacement for a given language.
  - swah 13y ago
    But the runtime performance is probably closer to Java than Python...
    - beatgammit 13y ago
      Well, yeah, because Go is compiled, not interpreted. It's GC isn't as optimized as Java's, but for straight computational speed, it's pretty comparable to other compiled languages. It just isn't a drop-in replacement for Java because it doesn't live in the same space. It does, however, have a similar feel as Python, especially with slices (except Go's don't copy data) and first-order functions. It's a completely different feel though than Python.

moshberm 13y ago

What happens if Google decides to send Go the way of the RSS reader, the SMS search, and the dinosaur?

Jtsummers 13y ago
Nothing, it's not a service. The code is already out there along with the documentation and language spec. The worst they can do is: 1. Cancel their future contributions. 2. Create a closed source fork (is this feasible with the license if they don't control what others have contributed?) In the worst case, if there aren't enough go enthusiasts it goes the way of other niche languages. Since the supporters seem to be active enough, I doubt that'll happen.

koraytaylan 13y ago

first I saw go I thought meh but with so many people saying good things about it makes go inevitably more interesting day after day. however I just feel like it's going to be like mongo. when it first got popular, people all moved to mongo as it miraculously solving all the problems. same thing happening with go now and after sudden disappear of all the mongo evangelists, this makes me doubtful about go obviously.

azth 13y ago
IMO, people like hype, and a lot of the time, they are not aware of what better alternatives exist. If Go did not have Google or Ken or Pike as names behind it, do you think it would have gone anywhere? It doesn't really offer anything special compared to more expressive and safer languages like Scala and Rust for instance. You can see it right here in the comments: someone said that Go is a memory safe language. It is not any more safer than Java is in that regard. We need languages that are safer than Java and Go.