Live data from Hacker News

Stream Processing for Go

blog.wallaroolabs.com

21–30 of 35 posts

Re: Stream Processing for Go

#21
post #20

Earlier quoted context omitted.

the actor model in Erlang and (recently!) in Pony implements something even better: explicit backpressure by deprioritizing senders to busy mailboxes. The model can do this because it includes the scheduler in its scope, which doesn't happen in CSP.

This was never meant to be a complete solution to back pressure in Erlang and has recently been remove for the next major release: https://github.com/erlang/otp/commit/2e601a2efc19d64ed0628a5... I’ve heard speculation that it really only helped scheduler efficiency and this didn’t apply all that well on SMP schedulers and has finally been removed since non-SMP builds are no longer supported. As for Pony, their actor…

My reply would be that while both Pony and Erlang are actor model languages, the semantics are quite different.

I never speak of either being better than the other. Rather, they are different. I'm an expert on backpressure in Pony, not so much in Erlang, so I'll leave it at that.

Re: Stream Processing for Go

#22
post #20

Earlier quoted context omitted.

This was never meant to be a complete solution to back pressure in Erlang and has recently been remove for the next major release: https://github.com/erlang/otp/commit/2e601a2efc19d64ed0628a5... I’ve heard speculation that it really only helped scheduler efficiency and this didn’t apply all that well on SMP schedulers and has finally been removed since non-SMP builds are no longer supported. As for Pony, their actor…

My reply would be that while both Pony and Erlang are actor model languages, the semantics are quite different. I never speak of either being better than the other. Rather, they are different. I'm an expert on backpressure in Pony, not so much in Erlang, so I'll leave it at that.

I’m a fan of both approaches. As we can never it say too soon in life: tradeoffs.

Re: Stream Processing for Go

#23
post #16

Earlier quoted context omitted.

In my view and experience, the actor model and the CSP model of Go and others (which is also very similar to Flow-Based Programming (FBP) if using buffered channels), can actually fit together very nicely, with each of them sitting at different abstraction levels: - The actor model for high-level coordination and communication - CSP and/or FBP at the low-level, for high performance processing. The reason for this is…

the actor model in Erlang and (recently!) in Pony implements something even better: explicit backpressure by deprioritizing senders to busy mailboxes. The model can do this because it includes the scheduler in its scope, which doesn't happen in CSP.

I, too, have a bit of experience with backpressure implementations in both Erlang and Pony. Erlang's "penalize the sender" doesn't work in many cases, so I'm not surprised that it's being removed. Erlang's remote distribution implementation & messaging semantics are Mostly Great but is definitely not Perfect.

1. Head-of-line blocking caused by congestion on the single TCP connection used for message transmission between any two Erlang nodes. This can cause major problems for apps control vs. data plane design, such as Riak and Lasp. Work on Partisan (https://github.com/lasp-lang/partisan) appears to be a substantial improvement.

2. If the single remote distribution TCP connection between two nodes is broken, then the first Erlang process to send a message to the remote node is, hrrm, well, borrowed/co-opted by the BEAM VM to connect the new TCP session. IIRC that process is marked unrunnable by the scheduler until the connection is set up or perhaps there's an error. If that process is really important to the functioning of your app, for example, an important system manager in the control plane of the app, then you have a very difficult-to-diagnose latency Heisenbug to cope with.

-Scott

Re: Stream Processing for Go

#25
post #12

Wow, Pony! Pony is one of my favorite young languages. It fits a similar niche that Go fits (not saying that either language can't be used for other purposes), in that they both are great for building cli tools with good concurrency primitives. Pony, however, uses the Actor model like Erlang (although the programming model is a bit different). In my opinion this is a superior model for concurrency than goroutines. I…

I think the lack of support for compiling on other platform is a huge issue for CLI, Go compiles on many platform very very easily it's a one liner and you can do it from any platforms, Pony can't do it. So why would you bother doing CLI on language that don't support that?

CLI should be a single binary or having a very minimal runtime that can run anywhere.

Re: Stream Processing for Go

#26

Does all state have to fit in memory?

Currently yes. If your state doesn't fit in memory on the number of machines you have, you'd need to add more.

We plan on adding support for only keeping part of state in memory. That's in the discussion phase. We want to talk to folks about their use cases and ideally work with them before adding it.

There are many trade-offs involved in such a feature and making those trade-offs based on informed decisions of our possible users needs is our preferred solution.

Re: Stream Processing for Go

#27
post #25
post #12

Wow, Pony! Pony is one of my favorite young languages. It fits a similar niche that Go fits (not saying that either language can't be used for other purposes), in that they both are great for building cli tools with good concurrency primitives. Pony, however, uses the Actor model like Erlang (although the programming model is a bit different). In my opinion this is a superior model for concurrency than goroutines. I…

I think the lack of support for compiling on other platform is a huge issue for CLI, Go compiles on many platform very very easily it's a one liner and you can do it from any platforms, Pony can't do it. So why would you bother doing CLI on language that don't support that? CLI should be a single binary or having a very minimal runtime that can run anywhere.

You can cross compile Pony, it isn't however, well documented at this point in time.

Re: Stream Processing for Go

#28
post #25

Earlier quoted context omitted.

I think the lack of support for compiling on other platform is a huge issue for CLI, Go compiles on many platform very very easily it's a one liner and you can do it from any platforms, Pony can't do it. So why would you bother doing CLI on language that don't support that? CLI should be a single binary or having a very minimal runtime that can run anywhere.

You can cross compile Pony, it isn't however, well documented at this point in time.

Have you seen how hard it is to make it works on Windows?

Re: Stream Processing for Go

#29

Hi all, I'm the VP of Engineering at Wallaroo Labs. Happy to answer questions. I worked with Andy on this preview release of our Go API. Andy will be on in a while and will also be answering any questions that might come up. We are getting ready to start work on performance tuning soon. We have a lot of work already planned there. If you play around with the Go API, we'd love to hear from you. We need your feedback t…

One small nit on the Go example code:

  func (wordTotals *WordTotals) Update(word string) {
        total, found := wordTotals.WordTotals[word]
        if !found {
            total = 0
        }
        wordTotals.WordTotals[word] = total + 1
  }
Can be done as:

  func (wordTotals *WordTotals) Update(word string) {
        wordTotals.WordTotals[word] += 1
  }
(thanks to Go default values)
Post reply on HN