fearthetelomere

7 ms·

31.
by fearthetelomere 6y ago
That's an important point, and didn't mean to make the problem of distributed actors appear trivial. In my mind, all the more reason to consider the distributed case when baking in actors into your language. For example, what dist
32.
by fearthetelomere 6y ago
With something like Elixir/Erlang, the distributed system is quite robust and reliable from my experience. A bit rigid and somewhat difficult to configure for custom topologies, but dependable overall. >a plain-old set of services t
33.
by fearthetelomere 6y ago
Actors aren't just about local concurrency, and if a language is attempting to bake them in, they should leave some room for the distributed case in my opinion. One of the biggest benefits of using actors is that whether an actor exist
34.
by fearthetelomere 6y ago
>Does the actor model make it easy to write concurrent spaghetti code? I think you could write concurrent spaghetti code in any environment just as easily, to be honest. I also think it really depends on which actor-model implementation
35.
by fearthetelomere 6y ago
Guessing you haven't seen Futurama. Not the same exact plot of course, but I immediately thought of it. [1] https://en.wikipedia.org/wiki/A_Fishful_of_Dollars
36.
by fearthetelomere 6y ago
You mean something like this? https://openstartuplist.com/
37.
by fearthetelomere 6y ago
I didn't consider that gRPC ser/deser was somewhat expensive. Then that would also be true for the TCP case too, right? Assuming I'm sending data over plain TCP, would Protobuf be comparable in performance to another DB wire
38.
Ask HN: Protobuf as a Database Wire Protocol?
1 points by fearthetelomere 6y ago|3 comments