6 ms·

Lots of sentiment, not much substance. Concurrency support is possible in Python, without gevent-style monkey patching (or callback madness). Have a look at co

by ak217 14y ago

Lots of sentiment, not much substance. Concurrency support is possible in Python, without gevent-style monkey patching (or callback madness). Have a look at concurrent.futures and http://www.dabeaz.com/coroutines/index.html http://www.dabeaz.com/coroutines/index.html. It really needs a lot more work before it's part of the language's DNA, though. Also, pypy needs much wider adoption as quickly as possible, to address the speed problems (and its STM branch holds huge potential). For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python.

peter_l_downs 14y ago
+1 for dabeaz's coroutines presentation. It's really well done, and if you write Python daily / monthly / even yearly it's worth reading.
zemo 14y ago
>Lots of fluff, not much substance. that was deliberate. There has been a glut of "introduction to Go" blog posts, and the documentation for introductory Go from the Go Team is quite good, so I didn't feel the need to author another introductory post. Most of the stories about why people use Go are bigger, established companies, so I wanted to show how it was perceived by a different audience. I don't remember where I saw it, but someone talked about using Go in contrast with Java, and the overwhelming reaction was "that's cool but I'm a Python programmer, I'm curious what Python programmers think", so I was just trying to give it that angle. >Have a look at concurrent.futures but this is part of the problem: it's a library. Concurrency deserves language-level support. Adding concurrency at the library level is like adding an object system at the library level.
- outworlder 14y ago
  > but this is part of the problem: it's a library. Concurrency deserves language-level support. Adding concurrency at the library level is like adding an object system at the library level. Which is not a problem at all. Lisp and Scheme have been doing that since forever.
  - xyproto 14y ago
    Not exactly prime choices for OO programmers, though
  - reinhardt 14y ago
    Their (lack of) popularity suggests that the "at all" part might be a bit too absolute.
  - scott_s 14y ago
    I assume they depend on macros to do so? That changes the game. Hans Boehm has an excellent paper on this issue titled "Threads Cannot be Imlemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf That paper was published in PLDI (http://dl.acm.org/citation.cfm?id=1065042 http://dl.acm.org/citation.cfm?id=1065042). His arguments have much to do with what the compiler doesn't know, which could potentially be solved with macros.
    - pcwalton 14y ago
      You don't need macros to solve this problem. You can use unique types, STM, etc. to forbid the data sharing at the type level and ensure a coherent memory model.
      - scott_s 14y ago
        The paper's position is that you can't implement threads, safely, as a library because the compiler is not aware of the concurrency. My point was that this reasoning may not hold if your language has full macros. Your suggestions will work great, but those are in the compiler, not as a library.
        pcwalton 14y ago
        Well, the point is that concurrency primitives don't have to be built into the language to enable libraries to write safe concurrent abstractions. Rather, the type system features that enable it can exist in the compiler as general type system features unrelated to concurrency that just so happen to be able to ensure the safety of concurrent code if used properly.
- ak217 14y ago
  > Concurrency deserves language-level support. I absolutely agree, which is why I said it needs more work.
- irahul 14y ago
  > I don't remember where I saw it, but someone talked about using Go in contrast with Java, and the overwhelming reaction was "that's cool but I'm a Python programmer, I'm curious what Python programmers think", so I was just trying to give it that angle. I have seen more Python/Ruby programmers interested in Go than Java or C++ programmers. Rob Pike seems to have observed it as well. 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++. http://commandcenter.blogspot.in/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.in/2012/06/less-is-exponential...
georgemcbay 14y ago
"For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python." Can you be a bit more concrete here? Because whether you like the code styles enforced by gofmt and the compiler itself or not, Go is the most consistently readable language I've ever used (once you adapt yourself to the language). IMO, this seems like an especially odd problem for someone to have with Go.
- ak217 14y ago
  Idiomatic Go: http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html Idiomatic Python: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html http://python.net/~goodger/projects/pycon/2007/idiomatic/han... (doesn't cover a number of important things) When comparing the two, I'm not impressed with Go.
  - winter_blue 14y ago
    The first link, Effective Go doesn't talk about the philosophy behind idiomatic Go, like _Code like a Pythonista_ does. There is however snippets of Go code on that page, and it's fairly reminiscent of C/C++. I don't really see that as a drawback, for I believe C code is fairly readable for what it offers (speed.) Go likeness to C doesn't offend me one bit, considering the power and speed it offers versus C.
  - lambda 14y ago
    What makes you unimpressed? Why do you think that Python clearly wins? Do you think that the additional type safety, namespace safety, and ease of concurrency in Go are worth nothing? Or do you just think that Python has more that outweigh that? I know that I frequently kick myself in Python when I typo a name somewhere, and everything dies far beyond where I made the mistake because it goes along happily storing something into that typoed variable, and then when I read it later it has the wrong value, and it takes me a while to trace back and find where I made the typo.
    - paul-woolcock 14y ago
jfaucett 14y ago
I wonder if parent has ever coded with Go? You have to maybe learn a new syntax (partially), but once you have its incredibly readable. for instance, encapsulation is handled by giving semantic significance to the case (upper or lower) of the first character in a variable name. So "myFunc" is local and not visible whereas "MyFunc" is publicly accessible. This and many other features make Go extremely readable for me at least, although I admit, I did have to read the docs and program some of my own projects before I really got accustomed to the syntax.

by ak217 14y ago

peter_l_downs 14y ago

+1 for dabeaz's coroutines presentation. It's really well done, and if you write Python daily / monthly / even yearly it's worth reading.

zemo 14y ago

>Lots of fluff, not much substance. that was deliberate. There has been a glut of "introduction to Go" blog posts, and the documentation for introductory Go from the Go Team is quite good, so I didn't feel the need to author another introductory post. Most of the stories about why people use Go are bigger, established companies, so I wanted to show how it was perceived by a different audience. I don't remember where I saw it, but someone talked about using Go in contrast with Java, and the overwhelming reaction was "that's cool but I'm a Python programmer, I'm curious what Python programmers think", so I was just trying to give it that angle. >Have a look at concurrent.futures but this is part of the problem: it's a library. Concurrency deserves language-level support. Adding concurrency at the library level is like adding an object system at the library level.

outworlder 14y ago
> but this is part of the problem: it's a library. Concurrency deserves language-level support. Adding concurrency at the library level is like adding an object system at the library level. Which is not a problem at all. Lisp and Scheme have been doing that since forever.
- xyproto 14y ago
  Not exactly prime choices for OO programmers, though
- reinhardt 14y ago
  Their (lack of) popularity suggests that the "at all" part might be a bit too absolute.
- scott_s 14y ago
  I assume they depend on macros to do so? That changes the game. Hans Boehm has an excellent paper on this issue titled "Threads Cannot be Imlemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf That paper was published in PLDI (http://dl.acm.org/citation.cfm?id=1065042 http://dl.acm.org/citation.cfm?id=1065042). His arguments have much to do with what the compiler doesn't know, which could potentially be solved with macros.
  - pcwalton 14y ago
    You don't need macros to solve this problem. You can use unique types, STM, etc. to forbid the data sharing at the type level and ensure a coherent memory model.
    - scott_s 14y ago
      The paper's position is that you can't implement threads, safely, as a library because the compiler is not aware of the concurrency. My point was that this reasoning may not hold if your language has full macros. Your suggestions will work great, but those are in the compiler, not as a library.
      - pcwalton 14y ago
        Well, the point is that concurrency primitives don't have to be built into the language to enable libraries to write safe concurrent abstractions. Rather, the type system features that enable it can exist in the compiler as general type system features unrelated to concurrency that just so happen to be able to ensure the safety of concurrent code if used properly.
ak217 14y ago
> Concurrency deserves language-level support. I absolutely agree, which is why I said it needs more work.
irahul 14y ago
> I don't remember where I saw it, but someone talked about using Go in contrast with Java, and the overwhelming reaction was "that's cool but I'm a Python programmer, I'm curious what Python programmers think", so I was just trying to give it that angle. I have seen more Python/Ruby programmers interested in Go than Java or C++ programmers. Rob Pike seems to have observed it as well. 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++. http://commandcenter.blogspot.in/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.in/2012/06/less-is-exponential...

georgemcbay 14y ago

"For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python." Can you be a bit more concrete here? Because whether you like the code styles enforced by gofmt and the compiler itself or not, Go is the most consistently readable language I've ever used (once you adapt yourself to the language). IMO, this seems like an especially odd problem for someone to have with Go.

ak217 14y ago
Idiomatic Go: http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html Idiomatic Python: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html http://python.net/~goodger/projects/pycon/2007/idiomatic/han... (doesn't cover a number of important things) When comparing the two, I'm not impressed with Go.
- winter_blue 14y ago
  The first link, Effective Go doesn't talk about the philosophy behind idiomatic Go, like _Code like a Pythonista_ does. There is however snippets of Go code on that page, and it's fairly reminiscent of C/C++. I don't really see that as a drawback, for I believe C code is fairly readable for what it offers (speed.) Go likeness to C doesn't offend me one bit, considering the power and speed it offers versus C.
- lambda 14y ago
  What makes you unimpressed? Why do you think that Python clearly wins? Do you think that the additional type safety, namespace safety, and ease of concurrency in Go are worth nothing? Or do you just think that Python has more that outweigh that? I know that I frequently kick myself in Python when I typo a name somewhere, and everything dies far beyond where I made the mistake because it goes along happily storing something into that typoed variable, and then when I read it later it has the wrong value, and it takes me a while to trace back and find where I made the typo.
  - paul-woolcock 14y ago

jfaucett 14y ago

I wonder if parent has ever coded with Go? You have to maybe learn a new syntax (partially), but once you have its incredibly readable. for instance, encapsulation is handled by giving semantic significance to the case (upper or lower) of the first character in a variable name. So "myFunc" is local and not visible whereas "MyFunc" is publicly accessible. This and many other features make Go extremely readable for me at least, although I admit, I did have to read the docs and program some of my own projects before I really got accustomed to the syntax.