4 ms·

TL;DR This is all the concrete code from the article: 1 awaitPing andThen sendPong I'd find more valuable blog posts explaining how to solve a concrete pr

by pacala 12y ago

TL;DR This is all the concrete code from the article: 1 awaitPing andThen sendPong I'd find more valuable blog posts explaining how to solve a concrete problem with concrete code using the Actor model than mishmashes of quotes appealing to various authorities.

lomnakkus 12y ago
I was going to chide you for unfairly calling out the lack of code vs. the abundance abstract concepts, but... yeah. This was pretty much content-free except for a few links to... things.
- pacala 12y ago
  I'm working hard to keep a professional, factual approach. There is more under the surface: A. (Appeal to authority) Until very recently, I've worked for years at a huge and very successful distributed systems company. There wasn't a single system using the actor model I ran into. I haven't heard anyone advocating for the actor model. Everything was a service with an RPC interface. At least one other huge competitor is well known for a service-oriented revolution phase. B. (Unsubstantiated anecdote). The majority of advocacy around Actors I've come across lacks substance. There is very little exemplification of what problems are solved or comparison to other ways to solve the problem. But it's almost guaranteed to have an appeal to Erlang's authority thrown somewhere in there. The OP is a canonical example. C. (Concrete example, you can start calling me out on it). Speaking of actors, messaging and distributed systems, I just don't get what's the point of sending an unreliable message if you don't check the response and tailor your reactions based on it. Which is basically doing RPCs. How do you even test something like "endpoint.send(request)" when messages can get lost?! Sorry if I sound harsh and unfair. I only bring this up because I'm forced by exterior circumstances to pay attention to "Actor model" tradeoffs.
  - lomnakkus 12y ago
    I think you misunderstand. I was (at least in substance) agreeing with you! :) The operative phrase being "I was going to..." [but didn't]. EDIT: ... but awesome post nonetheless! ;)

by pacala 12y ago

lomnakkus 12y ago

I was going to chide you for unfairly calling out the lack of code vs. the abundance abstract concepts, but... yeah. This was pretty much content-free except for a few links to... things.

pacala 12y ago
I'm working hard to keep a professional, factual approach. There is more under the surface: A. (Appeal to authority) Until very recently, I've worked for years at a huge and very successful distributed systems company. There wasn't a single system using the actor model I ran into. I haven't heard anyone advocating for the actor model. Everything was a service with an RPC interface. At least one other huge competitor is well known for a service-oriented revolution phase. B. (Unsubstantiated anecdote). The majority of advocacy around Actors I've come across lacks substance. There is very little exemplification of what problems are solved or comparison to other ways to solve the problem. But it's almost guaranteed to have an appeal to Erlang's authority thrown somewhere in there. The OP is a canonical example. C. (Concrete example, you can start calling me out on it). Speaking of actors, messaging and distributed systems, I just don't get what's the point of sending an unreliable message if you don't check the response and tailor your reactions based on it. Which is basically doing RPCs. How do you even test something like "endpoint.send(request)" when messages can get lost?! Sorry if I sound harsh and unfair. I only bring this up because I'm forced by exterior circumstances to pay attention to "Actor model" tradeoffs.
- lomnakkus 12y ago
  I think you misunderstand. I was (at least in substance) agreeing with you! :) The operative phrase being "I was going to..." [but didn't]. EDIT: ... but awesome post nonetheless! ;)