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

Ask HN: Are you using actors in production? Why/Why not?

news.ycombinator.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Ask HN: Are you using actors in production? Why/Why not?

#21

Post by iampims »

lostintangent wrote: post #7
evanmoran wrote: post #3

Earlier quoted context omitted.

Let me second this. For example in Go, the simplest way to use a channel is to queue work to it from several endpoints. Then another Go routine can pull it off, usually becoming the exclusive writer of whatever the next step the computation is. So even though Go has this green/micro thread behavior behind the scenes (go routines), it’s main innovation is around the concurrency safe queue (the channel) so those thread…

I _really_ appreciate this reply! Naively speaking, when I look at actors, I just can’t think of why they’d be superior to coordinated queues/channels, except for within an arbitrarily configurable, rules-based system (e.g. game NPC behavior, network routing). But I couldn’t help but assume this was dramatically oversimplifying the problem/missing the point. If someone were using Go routines and channels, what do you…

Because they scale to more than one node is a very important feature.

Re: Ask HN: Are you using actors in production? Why/Why not?

#22

Post by contingencies »

lostintangent wrote: post #18
contingencies wrote: post #16

Life is but a stage, and we are all actors upon it. It's impossible to make many useful statements regarding architecture unless there is proper context. Goals, resources, constraints, expectations. Use the right tool for the job.

Then how do any of these distributed systems tools/frameworks write a meaningful or concise landing page? Making informed trade-offs are obviously important. But in a world of saturated information, it seems like there’s even more value in being hyper clear about what the purpose of a thing is? And even better, what it’s _not_. Unfortunately, many of these tools claim to be broadly applicable, in a way that makes it…

Yeah, well, the logical reaction to that is to use minimal tools and unix and actually measure a supposed fault before attempting to work on it. First get it working, then get it working well. Usually the overriding business architectural considerations are achieving functionality within reasonable time and money, using existing HR, and without creating too much technical debt. Characteristics of specific components are generally not high on the list. This can be different in high availability systems, safety related systems, long-term stability fault-recovery-required systems and other special use cases. But for 99% of enterprise, HTTP @ 10Mbps + solid tools like the filesystem or sqlite3 will do it. Scaling becomes easy because you're on 100% known interfaces, so swapping any given component out is trivial, ie. future-proofing exists by default. Interfaces before implementation. For more wisdom tidbits try https://github.com/globalcitizen/taoup ;)

Re: Ask HN: Are you using actors in production? Why/Why not?

#23

Post by jhgg »

At Discord our entire real time system is built ontop of Elixir. Everything is an "actor" in that model. Every single Discord server, websocket connection, voice call, screenshare, etc... distributed using a consistent hash ring.

It's an incredibly great model for these things. We've been able to scale this system from hundreds to hundreds of millions of users with very little changes to the underlying architecture.

Re: Ask HN: Are you using actors in production? Why/Why not?

#24

Post by adamhp »

jhgg wrote: post #23

At Discord our entire real time system is built ontop of Elixir. Everything is an "actor" in that model. Every single Discord server, websocket connection, voice call, screenshare, etc... distributed using a consistent hash ring. It's an incredibly great model for these things. We've been able to scale this system from hundreds to hundreds of millions of users with very little changes to the underlying architecture.

I love the Discord developer blog. You folks really know your stuff.

Re: Ask HN: Are you using actors in production? Why/Why not?

#25

Post by dantodor »

lostintangent wrote: post #15
dantodor wrote: post #13

I'm using both Scala/Akka and Elixir in production. Once you get to better know the paradigm, you'll never ever want anyrhing else. And if by niche you understand resilient backends, yes, it's pretty niche then :)

Any insights that you’d want to share with someone not using Java/Scala or Erlang/Elixir? I’d love to get the benefits of actors in Node, Python or Go, but I’m not entirely sure what I’m missing yet.

Not very sure, but actors kinda make sense in multi-threaded environments, so you can forget about Node and Python. In Go, you can replace easily actors with goroutines and channels.

Re: Ask HN: Are you using actors in production? Why/Why not?

#26

Post by lostintangent »

iampims wrote: post #21
lostintangent wrote: post #7

Earlier quoted context omitted.

I _really_ appreciate this reply! Naively speaking, when I look at actors, I just can’t think of why they’d be superior to coordinated queues/channels, except for within an arbitrarily configurable, rules-based system (e.g. game NPC behavior, network routing). But I couldn’t help but assume this was dramatically oversimplifying the problem/missing the point. If someone were using Go routines and channels, what do you…

Because they scale to more than one node is a very important feature.

True! But you don’t need actors to enable horizontal scaling?

Re: Ask HN: Are you using actors in production? Why/Why not?

#27

Post by asfarley »

I use Akka.NET in production. It’s been good and I don’t have any major concerns, but I wonder sometimes about depending on a third-party library in case it becomes obsolete.

One difficulty coming from non-actor systems is getting a callback or response from messages. By default, actor messages are outgoing-only so the idea of a callback or response message needs to be implemented on top.

Re: Ask HN: Are you using actors in production? Why/Why not?

#28

Post by Jugurtha »

I worked on a project where a device was to be paired to Bluetooth Low Energy device by a non-technical user and send that data somewhere through 3G dongle. It had to be untouched, update its own software, work all the time, recover when there was any problem (lost BLE connection, poor internet coverage, sync data, take a shot at a deliver-once scheme, handle connection errors, handle device swap, and a variety of other issues - I had actual, literal, nightmares related to UTC and time zones -

We used the actor model for that project because it made it easier to deal with exceptions. Even things that usually worked didn't at some point, and to take into account all that could go wrong would have made it much more diffcult because there was always something new that went wrong.

Post reply on HN