> You cannot pass functions, promises, or other non-serializable objects
Functions are serializable. And deserializable. You can absolutely take one defined on one machine, kick it over the wire, then execute it on another one. Likewise closures, you serialise the associated state as well.
Promises are the same thing - a distributed language runtime should be exactly the sort of graph execution system which lets you pass promises between machines and have things work out.
Further, they don't say what other "non-serializable" things are. Is a DAG serialisable without spuriously unrolling it into a tree and failing to fold back into a DAG at the other end? How about a graph? Given that all things are serializable it is difficult to guess what things they haven't implemented.
So by "they've got the implementation wrong", I'm saying they haven't implemented the tricky part of serialisation, only the copy ints over wires part. And by "wrong", I'm saying that a language runtime dedicated to transparently running typescript functions on other machines should be able to run those functions on other machines even if they have closed over state.
Author here. Absolutely agree with what you're saying.
Maybe the line could be written better. It is supposed to say: You can't pass functions and promises. And you can't pass in other data types that are not serialisable.
I definitely did not intend to say that functions or promises are not serialisable, and it is something we're looking into. The complexity is with serialising the closure state.
The other thing we're implementing is constraining the data types via the type system itself.
All data is serialisable. I'd say that's axiomatic. Data is information with a concrete representation.
At present the docs say it can serialise things that it can serialise with a couple of examples on each side.
My best guess is there's some limitations caused by the stack under your implementation that you haven't worked around, but I don't know what those limitations are or which ones you plan to resolve.
In addition to what can be sent there's a load of design choices about what is sent.
Is aliasing within the original preserved?
Is potential aliasing introduced?
Is it compressed in transit?
Is it delta encoded with respect to information that was sent previously?
Is there some initial blob of information every instance starts up with that messages are deduplicated against?
And that's before the behaviour on mutation - when one machine changes the data, how and when is that change reflected on other machines?
> All data is serialisable. I'd say that's axiomatic. Data is information with a concrete representation.
I Do not disagree. I think the problem comes from us using the term serializable to liberally.
> My best guess is there's some limitations caused by the stack under your implementation that you haven't worked around, but I don't know what those limitations are or which ones you plan to resolve.
Agree. Feedback received, and thanks. This will be worked in.
But I'll attempt to answer your questions here:
> Is aliasing within the original preserved?
No. The data being sent over the network is copied by value, not reference - if that makes sense.
> Is it compressed in transit?
Yes. With Message Pack.
> Is it delta encoded with respect to information that was sent previously?
I'm not sure I follow, but all calls are independent of each other.
> Is there some initial blob of information every instance starts up with that messages are deduplicated against?
> And that's before the behaviour on mutation - when one machine changes the data, how and when is that change reflected on other machines?
Not sure if this helps, but this [1] talks about the architecture. There's a C&C. The control-plane is the orchestrator for all machines.
I'm guessing, but it should be possible to pass anything remotely as a proxy with an ID: calls to a closure or the resolution of a promise cause further RPC, and sending it back recovers the original value.
It’s technically correct but really we all know what was meant. They’re serialisable but not really deserialisable, even if it’s a pure function it might not even be serialised in a version of JS that the receiver understands.
> serialised in a version of JS that the receiver understands
I don't think the use case for this is as general as most RPC systems.
The linked site envisions a situation where you had an app running on one server, now you want to break that workload up while making the absolute minimum number of code changes.
All the clients and code would still be controlled by the same team.
that's still not something I'd want to inflict to myself. That means you need to somehow ensure the functions you pass are pure, and that upgrading Node or changing the compilation target could break the app if the release rollout is progressive.
Using function serialisation for applicative purposes is always going to be a hack that will come back to bite the team at one time or another.
I misread the above comment it seems, however, my point was that for many it is not instant no, since so many buy space from GitHub et al. Probably most of the small companies.
They have already trust in place. Do they trust Zed too?
Your home internet and your cellular provider can “attest” you make a monthly payment - right now, the scarcity of ipv4 and cell phone numbers often serve this purpose. A government agency or bank can attest you’re a real person. A hardware manufacturer can attest you purchased a device. A PGP style web-of-trust can show other people, who also own scarce resources and they may trust indirectly, also think you’re real.
Blockchain may be largely over-hyped, but from this bubble I think important research in zero-knowledge proofs and trust-less systems will one day lead to a solution to this that is private and decentralized, rather than fully trackable and run by mega-corps.
It’s pretty easy to guess what features (either manually made or AI based) the phishing detector saw:
1. “Facebook” and “login” in the URL
2. URL redirect
3. “Facebook login”, “password login, “forget password” etc in text body
4. The quoted email from Spotify sounding close (in vector space) to phishing text.
5. A link to Facebook settings, followed by a series of steps; these instructions say to log in to a non-Facebook url using your Facebook email
All of these together was probably enough to hit some threshold.
From there the issue was just misaligned personal incentives, all along the chain from engineers at Facebook to Netcraft and Digital Ocean, that leads to false positives being an acceptable outcome.
People use “green bubbles” to just mean “no guaranteed delivery or delivery receipts, no read receipts, very low quality image and videos, bad support for reactions, threaded replies, and group chats”.
…the color isn’t the problem. It’s shorthand for the real underlying issues
The color is a big part of the problem, white on green is one of the hardest to read because of the distribution of color cone cells in our retinas. Only maybe white on yellow would be worse.
…if you wanted full anonymity, why did you turn on DNA relative sharing? Why don’t you turn it off now? Or do you mean, you assume they could place your profile within a tree, if they wanted to?
The first paragraph of the linked Wikipedia says “In Australia and New Zealand, it can also be a neutral or positive term when used with a positive qualifier (e.g., "He's a good cunt").”
Another crazy way to think about it: every two years, humanity experiences more time (in terms of “total hours of existence”) than the entire age of the universe, from the Big Bang to now. A universes lifetime of collective experience, every two years.
