Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

youtube.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

#11

Post by bakul »

pjmlp wrote: post #7
jacinabox wrote: post #4

I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.

Modula-2 already had co-routines in 1978. Concurrent Pascal had them in 1976. And there are plenty of other examples gaining digital dust.

Concurrent pascal didn't allow unsafe concurrent access to shared data structures. Go allows safe concurrent access but doesn't stop such access. Its authors encourage people to use channels but this sharing is intrinsic -- one can start a nested function as a concurrent goroutine & it has full concurrent access to its environment. Go tools can check for race conditions but ideally such support should be in the language itself. So in a sense Go is worse than Concurrent Pascal for the main feature it touts!

Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

#12

Post by YorickPeterse »

jacinabox wrote: post #4

I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.

    > goroutines are a major innovation upon threads.
Not exactly, Erlang has had them for almost three decades.

Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

#13

Post by dragonwriter »

YorickPeterse wrote: post #12
jacinabox wrote: post #4

I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.

> goroutines are a major innovation upon threads. Not exactly, Erlang has had them for almost three decades.

Goroutines are not Erlang processes; they are similar in that each is multiplexed M:N style onto native threads, but goroutines aren't shared-nothing, and they communicate with channels rather than each process having a mailbox.

Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

#14

Post by teamfrizz »

bakul wrote: post #11
pjmlp wrote: post #7

Earlier quoted context omitted.

Modula-2 already had co-routines in 1978. Concurrent Pascal had them in 1976. And there are plenty of other examples gaining digital dust.

Concurrent pascal didn't allow unsafe concurrent access to shared data structures. Go allows safe concurrent access but doesn't stop such access. Its authors encourage people to use channels but this sharing is intrinsic -- one can start a nested function as a concurrent goroutine & it has full concurrent access to its environment. Go tools can check for race conditions but ideally such support should be in the langu…

allows and doesn't stop are the same thing.

Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

#15

Post by kazinator »

teamfrizz wrote: post #14
bakul wrote: post #11

Earlier quoted context omitted.

Concurrent pascal didn't allow unsafe concurrent access to shared data structures. Go allows safe concurrent access but doesn't stop such access. Its authors encourage people to use channels but this sharing is intrinsic -- one can start a nested function as a concurrent goroutine & it has full concurrent access to its environment. Go tools can check for race conditions but ideally such support should be in the langu…

allows and doesn't stop are the same thing.

Maybe OP means "allows safe concurrent access but doesn't stop unsafe concurrent access".

Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

#16

Post by bakul »

kazinator wrote: post #15
teamfrizz wrote: post #14

Earlier quoted context omitted.

allows and doesn't stop are the same thing.

Maybe OP means "allows safe concurrent access but doesn't stop unsafe concurrent access".

Indeed.

Meant to write "Go allows safe concurrent access but doesn't stop unsafe concurrent access to shared data structures"

Thanks & sorry for the confusion.

Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

#18

Post by espeed »

kazinator wrote: post #15
teamfrizz wrote: post #14

Earlier quoted context omitted.

allows and doesn't stop are the same thing.

Maybe OP means "allows safe concurrent access but doesn't stop unsafe concurrent access".

And that capabilities model is one of the big differences in Pony and was the key to achieving Pony's parallel lock-free provably correct concurrency model.

Most lang/system capability models (including Go's) are open from the start -- where anyone can do anything -- and then when designing the lang/system you try to restrict access between some things at some of the time, but this gets messy fast and it's hard to get right and thus it's almost never optimal.

So rather than trying to start with an open model that's inherently flawed by definition, Pony flips the model on its head and begins from the perspective that everything is denied unless specified. You would say Pony has a deny-first capabilities model, which you can see explicitly defined here in Pony's capabilities matrix...

https://soyyomakesgames.wordpress.com/2016/10/10/ponys-capab...

And if you listen to Sylvan's talks, he is emphatic that solving the capabilities problem upfront was key that made everything else possible. All the other cool stuff you hear about in Pony like the provably correct runtime and finally achieving something approaching Hewitt's elusive Actor model that's been theoretically true for 40 years but never fully realized. Well the key to solving that mystery and unlocking the door was to take a new view on the capabilities model and building everything off that from the start.

Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

#19

Post by abrookewood »

jacinabox wrote: post #4

I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.

Arguably, new styles of programming are making concurrency less important. You won't always need a concurrent language when you can spin up a thousand instances of your function on platforms like AWS Lambda etc.

Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]

#20

Post by espeed »

abrookewood wrote: post #19
jacinabox wrote: post #4

I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.

Arguably, new styles of programming are making concurrency less important. You won't always need a concurrent language when you can spin up a thousand instances of your function on platforms like AWS Lambda etc.

No, don't think like that. Concurrency is becoming more important, that's just the new reality on the other side of Moore's Law. Concurrency doesn't just happen. Someone has to design the AWS Lambda concurrency model and build the system to scale even if it's not you. And unless the system's design is improving over time and approaching optimal, eventually no one's going to use it because it will cost more than it should so people will move on toward the optimal one. And just like we have multi-layer caching models, distributed means we now have multi-layer concurrency models. Message passing Actors might be optimal between nodes, but within nodes matrix-multiply tensor models running on GPU/TPU accelerators is where optimal's at. And unless you understand it, you won't even be on the map.
Post reply on HN