

Go-flavored JavaScript - tantalor
http://www.johntantalo.com/blog/go-flavored-javascript/

======
gunz_rozez
Doesn't this approach have the same downside as what some critics are saying
about evented procedures like node that it would result in spaghetti callback
code and worse if you are not careful deadlocks?

~~~
tantalor
The same could be said of Go, but I don't think its true.

I think the lesson of channels is important. If you constrain your
communication to a channel then your callbacks will be simpler, not more
complicated, because the channel manages the communication for you.

It's like using Unix pipes instead of managing buffers yourself. It's a simple
tool, and hides the tedious/ugly bits that nobody wants to see.

------
jessedhillon
This is not the same thing as Go. Traditional languages tend to produce
unreadable, message and difficult to follow code when describing concurrent
tasks -- this is the impetus for a language like Go, where concurrency is
built-in.

Also, I believe all Javascript engines are single-threaded -- try passing to
`go()` a function which doesn't return and you will see that nothing outside
of that loop will ever be executed.

~~~
tantalor
> you will see that nothing outside of that loop will ever be executed

Yes, that is true. Maybe I wasn't clear, but I tried to point out that every
"thread of control" must yield as soon as possible to the event loop in
JavaScript.

Since Go is _not_ single-threaded, a real goroutine doesn't need to yield.

