4 ms·
>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 f
by 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 agoNot exactly prime choices for OO programmers, though
- reinhardt 14y agoTheir (lack of) popularity suggests that the "at all" part might be a bit too absolute.
- scott_s 14y agoI 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 agoYou 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 agoThe 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 agoWell, 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.
- scott_s 14y agoI take your point, but I find it unlikely that anyone would defined the correct language semantics that would guarantee correct results under concurrency without designing for concurrency. Which is the point of Boehm's paper: your language (and its compiler) need to know about concurrency in order to get it right.
- zvrba 14y agoBut these arguments are pretty much invalid today: C++11 introduces explicit support for concurrency, and the compiler MUST be aware of it, even though it may look (on the surface) as a "library".
- scott_s 14y ago
- 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...