undefined | Better HN

0 pointstptacek11y ago0 comments

That's a reductive summary of goroutines. I don't doubt other languages have competitive features, but let's be clear about what the feature is:

* Lightweight threads with a scheduling and state overhead low enough to run hundreds of thousands of threads at a time.

* Seamless integration with the language, without any rituals or incantations needed to invoke them; you can, for instance, trivially pass closures from goroutine to goroutine.

* A data sharing scheme that makes sense with promiscuous threading ("synchronized" data structures often don't, because they'll end up serializing threads)

Lots of languages have green threads, but not all these properties.

I'm guessing Haskell does? I don't write Haskell, but my impression is that it has everything.

0 comments

lobster_johnson11y ago

Erlang has the first two concepts nailed down.

I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access.

I don't know Haskell's concurrency tools very well, but I believe it can provide much of the same functionality as Erlang, but the whole OTP toolset is missing — just as it is in Go. (Certain aspects of OTP can't be implemented in Go at all without additional changes to language/runtime.)

tptacekOP11y ago

Neat. You can start an Erlang process (or whatever they're called) with an anonymous function, and pass it another anonymous function that closes over another lexical environment?

jerf11y ago

Yes, both in Haskell and Erlang.

For me, Go's big win is that I can finally bring this, the right way to do it, to work, because it's the first time this paradigm is present in a conventional imperative language, not that it is the first in general. Many other languages got it right in theory before Go, but there was always some practical stopper, involving some obscure programming paradigm that I stood no chance of getting buy-in on (from engineering or management) or an ecosystem that simply couldn't be reasonably be called production-ready across the set of tasks I needed to accomplish. Go finally gave me almost everything I wanted for work. If it isn't everything, well, that's life sometimes, you know?

1 more reply

lobster_johnson11y ago

Absolutely:

    do_stuff() ->
      GetAnswer = fun() -> 42 end,
      spawn(fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end).

Here, GetAnswer is a closure, as is the anonymous function given to spawn() function.

1 more reply

brickcap11y ago

Also don't ets tables do that, #3 I mean? Where different processes can access the same data structure? You can even control what process read or write to it. It is pretty neat.

thirsteh11y ago

Yeah, you could have said the same about Haskell. 'forkIO' in Haskell and 'go' in Go are essentially identical. You could also argue that Haskell's STM is even safer than using CSP channels (which also exist in Haskell) since you greatly decrease your chance of data races (while sacrificing some performance in cases where a transaction is often retried.)

But in the end it doesn't really matter that much. Go and Haskell are completely different languages for different purposes (getting stuff done in regular companies vs. doing interesting PL research or more advanced development in companies with little turnover.)

coolsunglasses11y ago

>You could also argue that Haskell's STM is even safer than using CSP channels (which also exist in Haskell) since you greatly decrease your chance of data races

We actually have transactional and non-transactional channels as well, which is pretty cool.

Also the reason for using STM instead of channels is that they compose without the possibility of deadlock. You can have deadlocks with channels.

tel11y ago

I'll try to represent Haskell here.

1. Totally, definitely. The new Haskell IO manager in GHC 7.8 completely blows this out of the water. It's wonderful.

2. You fork or async IO procedures which can be considered immutable values in their own right and passed around without the slightest concern. There is a small difficulty in that Haskell's laziness makes it a small trick to ensure that work gets done in the right place, which is undoubtedly a mark against Haskell, though perhaps not a huge one.

3. Things like STM, MVars, and (now) LVish let this happen in all kinds of ways. The only problem might be picking the right option due to the wealth of choices. Fortunately, the right answer is almost always STM.

I'd be more than happy to translate a task to demonstrate these things.

asdf123411y ago

> The new Haskell IO manager in GHC 7.8 completely blows this out of the water.

Go will still outperform Haskell by a huge margin and the typical Go process will have a much smaller memory footprint.

I don't even like Go, but nobody choosing Go is realistically considering Haskell as an alternative.

samth11y ago

I encourage you to look a the benchmarks published here: http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03... which includes Haskell beating nginx and Haskell beating SDN controllers written in C++ and in Java.

tel11y ago

I'm not so sure that is true. I'd love to see some benchmarking, though.

platz11y ago

I don't like go either, but I won't believe that a ghc webserver is a fast as a go webserver until we can see it in the techempower benchmarks.

1 more reply

Mikera11y ago

Clojure has all of this in core.async - which is just a library, it doesn't need special support from the underlying language.

goroutines are certainly nice and CSP is a good mental model for solving many problems, but I don't think a feature like this should be used to justify switching to a whole new language.

Blackthorn11y ago

What? No. You could not be more wrong. core.async does not support the first point in the least.

Don't believe me? Make a go block in core.async and have it call another function, then have that function block. Do it 10,000 times. I'll wait. And wait. And wait. And wait...get the picture?

Clojure has this in Pulsar, which is a library...that happens to perform bytecode modification to support this (which I consider to be on the same level as special support from the underlying level). Pulsar is an absolutely amazing project and I'm not trying to take anything away from it with this comment, but merely trying to illustrate how far off you are.

j / k navigate · click thread line to collapse

0 comments

lobster_johnson11y ago

Erlang has the first two concepts nailed down.

tptacekOP11y ago

Neat. You can start an Erlang process (or whatever they're called) with an anonymous function, and pass it another anonymous function that closes over another lexical environment?

jerf11y ago

Yes, both in Haskell and Erlang.

1 more reply

lobster_johnson11y ago

Absolutely:

    do_stuff() ->
      GetAnswer = fun() -> 42 end,
      spawn(fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end).

Here, GetAnswer is a closure, as is the anonymous function given to spawn() function.

1 more reply

brickcap11y ago

Also don't ets tables do that, #3 I mean? Where different processes can access the same data structure? You can even control what process read or write to it. It is pretty neat.

thirsteh11y ago

coolsunglasses11y ago

>You could also argue that Haskell's STM is even safer than using CSP channels (which also exist in Haskell) since you greatly decrease your chance of data races

We actually have transactional and non-transactional channels as well, which is pretty cool.

Also the reason for using STM instead of channels is that they compose without the possibility of deadlock. You can have deadlocks with channels.

tel11y ago

I'll try to represent Haskell here.

1. Totally, definitely. The new Haskell IO manager in GHC 7.8 completely blows this out of the water. It's wonderful.

I'd be more than happy to translate a task to demonstrate these things.

asdf123411y ago

> The new Haskell IO manager in GHC 7.8 completely blows this out of the water.

Go will still outperform Haskell by a huge margin and the typical Go process will have a much smaller memory footprint.

I don't even like Go, but nobody choosing Go is realistically considering Haskell as an alternative.

samth11y ago

tel11y ago

I'm not so sure that is true. I'd love to see some benchmarking, though.

platz11y ago

I don't like go either, but I won't believe that a ghc webserver is a fast as a go webserver until we can see it in the techempower benchmarks.

1 more reply

Mikera11y ago

Clojure has all of this in core.async - which is just a library, it doesn't need special support from the underlying language.

goroutines are certainly nice and CSP is a good mental model for solving many problems, but I don't think a feature like this should be used to justify switching to a whole new language.

Blackthorn11y ago

What? No. You could not be more wrong. core.async does not support the first point in the least.

Don't believe me? Make a go block in core.async and have it call another function, then have that function block. Do it 10,000 times. I'll wait. And wait. And wait. And wait...get the picture?

j / k navigate · click thread line to collapse