My reason for comment related purely to the looseness of the conversation, w.r.t. the word "scale", which, it seems I had misunderstood to mean an affine transform.
In light of this comment, I now see you were talking about some growth function or change in topology/structure.
This can be mitigated by processes not being "objects".
Especially objects that need to be pinned by ref counting.
My personal interpretation of the Actor model is a message passing system to model the real world.
In the real world I can shout out "make me a sandwich" and even if I perceive that there is a process that could potentially satisfy that request, I also work on the assumption that for any number of reasons... the channel of communication going away, misenterpretation, the agent or myself dying, the resources not being available or delays due to manufacturing may impede progress.
That is just the way the real world works.
Although Future/Promise can be built easily on top of Actor, they are optimistic at best - especially in diatributed cases; which, if my interpretation is correct is your reason for Actor in the first place.
Actor is powerful so in my opinion, future/promise and building ref-counts on top undermines the core of it.
Pat Helland, after numerous years of distributed transaction work completely did a 180 in the face of reality.
There is nothing wrong with Actor.
As far as strong typing, I personally believe that is a completely orthogonal conversation. I just cannot see the conflation.
Strongly typed to me means I send an argument to a function and it happens to match the signature.
Well, if I have a strongly typed function that takes two integers and somehow is supposed to return the sum. I guess it is helpful to know that as the user-agent (caller) of the function, but that knowledge only helps programmers, not computers.
Strong typing is definitely not a model of reality when dealing with humans as functions, and often humans are end-point "processes" (heh) of function calls.
Not that I am against strong typing in any way. I just believe the Actor model is cleaner without mixing things up.
Certainly agree Erlang is great but not the ultimate.
Well... my 2c and thanks to you, Alan, Joe, Hoare, Sussman, Gelernter et al. et al. for the inspirations over the years, and appreciate you plugging away at the models to this day.
That a corporation worth multiple billions of dollars can't keep our information secure despite one individual.
That is the message here.
IMHO, the "punishment" trajectory should aim toward Capital One. After all they are the ones who ultimately fucked up.
Frankly; Oh dear my ex-employee, or someone "trusted" who was pissed off because I/We didn't think I/We did anything to piss them off is not an admissible excuse.
Why anyone should weep for a multi-billion dollar company while crowing "throw the bitch in jail" for exposing their lacking security practices is beyond me.
Who is the criminal. A large mega-corp who could not keep their shit straight or an individual who proved their security perfectly invalid, and then told us!
Instead of focusing on the lady involved, perhaps holding Capital One accountable for their part in the matter may be a better thrust to this thread.
While it might not be okay to instigate such breaches, we might also consider it the actions of a whistleblower. Especially given the unusual way she went sbout disclosing things.
Sure, perhaps there is a little bit of hey look at me about it, but at the bottom of the trough it is actually the corporation that has ultimate responsibility.
I look forward to a statement from Capital One of regret that they allowed the breach to happen and will strive for better standards of security.
And that is actually a message for the entire industry.
Some enterprising developer could use images from Tinder (or better) OkCupid tagged with data coming from the individuals profile data, then interpolate based on abstract factors such as risk taking, gender bias etc. Well... you get the picture.
I think this is a very dangerous game we are playing here but I guess it is going to be done.
A big problem is MongoDB isn't schemaless, it is document oriented.
That is a really big schema choice imposed on developers and the root cause of for instance why it took years to be able to create good indexes on inner fields, and they still can't do it efficiently.
The same can be said for simple key value stores.
True schemaless databases are much rarer and provide developers orders of magnitude increases in terms of flexibility, expression and speed.
Unfortunately these kinds of databases are not readily available to a broad audience. It's also the case that for the majority of jobs and developers SQL based stores are still a very good choice unless you need to deal with huge amounts of data from disparate sources without bringing down the system.