[CentralOH] Additional Go Language Influences

[Joe Shaw]

Hi,

On Tue, Feb 24, 2015 at 1:00 PM, James Bonanno <james at atlantixeng.com>
wrote:

> Looking over the Go programming language, it seems to me to have similar
> syntax to Ada and VHDL languages, and the general paradigms of concurrency
> are emulated in memory versus truly parallel processes. What I like about
> it is the light overhead of the concurrency. This is the first software
> language that I've seen come close to this type of methodology. I know the
> presenter mentioned Pascal as an influence, but I would also mention these
> other languages.


Thanks for the info.  I am not too familiar with Ada or VHDL.  The basis of
Go's concurrency is a series of papers on Communicating Sequential
Processes (CSP) from 1978.
http://en.wikipedia.org/wiki/Communicating_sequential_processes

This is also where Erlang gets its concurrency model from.  As you mention,
though, there is a pretty big difference in that Go's are all within a
single process.  There are both advantages and disadvantages to this, and
the lightness of creating goroutines is one of them.

Other than C, the most direct ancestor of Go (and its source of concurrency
syntax) comes from a small language called Newsqueak (
http://en.wikipedia.org/wiki/Newsqueak) that was also created by Rob Pike.
Its influence comes largely from CSP and Smalltalk.


> Will Python develop a lightweight concurrency model?


Python has some external projects which have introduced the idea of "green
threads", such as greenlet and gevent.  However, I think Go's greatest
strength is that the concurrency is baked in at a very fundamental level in
the language and runtime.  Gevent for instance does some pretty scary
monkeypatching of various low-level functions in places like the socket and
os modules to achieve concurrency.

I think to get the kind of concurrency Go enjoys would require a Python
4-like re-breaking of the language syntax, which I think would be a tough
sell. Maybe it could be done incrementally, I'm not sure.

One of the things I like best about Go is that goroutines allow you to
write code in a very linear, sequential, non-concurrent fashion and add
asynchronicity later.  If you look at my first example from the talk, the
concurrent URL fetcher:

     https://github.com/joeshaw/talks/blob/master/cohpy/fetch.go

notice that the fetch() function does not involve concurrency at all.  It
is how we use and compose that function later inside main() that makes the
concurrency work.  It's a best practice in Go that APIs you write should
not expose goroutines or channels but instead act synchronously.  The
consumers of your API should have the freedom to make them asynchronous by
running them in a goroutine.

While I think the asyncio stuff in Python is really great and a big
improvement over things like gevent (or even Twisted), like C#'s
async/await syntax it "infects" your code by making it necessary to yield
within (or in C#, mark async) any code that needs to run asynchronously.
It can become a fairly large burden to convert code from being synchronous
to asynchronous because it often affects large portions of your call stack.

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/centraloh/attachments/20150224/51b82361/attachment.html>