Has anyone checked this out?
It seems it might be interesting.
2 Likes
It sure sounds interesting but it I also feel this article leaves some loose ends and I believe you also have to complement it with FAQ.
I thought I would atleast give the hello world a go Quickstart.
Yes, I didn’t actually dive into how it works or the foundations of the “internet computer” - just the basis for the language, what I found interesting is that they’ve chosen actors as the basis for it - perhaps there’s also some interesting stuff for those working on creating typed languages on the beam?
I don’t understand though why they’ve chosen to implement futures/promises/awaits - I personally dislike them, I think they just obfuscate a lot what is going on.
Yes. I pretty much scanned the whole thing first and this was the thing that made me actually read it proper. If this would become a big thing I guess we as a lot are in a good spot to use it as we already know the actor stuff (assuming that they did not screw it up).
But I believe they have a lot to prove before they can climb out of the not another language hole.
They seem to aim to keep it familiar to the average C family user and I guess it is a common solution there.
1 Like
I’m curious how they plan to guard against reentrancy attacks as seen in Ethereum’s smart contract actor tooling.
BEAM-style actors avoid those problems by making call a blocking operation; the process state can’t change while waiting for a reply. But that can cause deadlock if there’s a call cycle (process A waiting on process B which is waiting on process A), so it sounds like this takes the opposite approach where actors can still answer other messages while awaiting a reply.
3 Likes
I thought this was a great question and I was unable to find an answer in any of their currently published guides, FAQ and other documentation. Therefore I asked the question on their forum. No answers yet, I’ll keep you posted 
.
2 Likes
But if I understood correctly they also have ordered sequential mailbox processing so it should be at least mitigated? in the sense that each message has to be processed fully before another one is?
That’s the solution in things like gen_server, but that can deadlock: if process A sends a message to process B (and blocks waiting for a response) and then process B sends a message to process A. The blog seems very enthusiastic about NEVER blocking, so process A is presumably still responding to messages while awaiting a reply from B.
When I read it I had the idea they were using the same model as Erlang, and supposedly implemented futures as what would be the equivalent of calls in OTP (or Task’s awaits).
That is true, in practice, either before coffee or after a long day I have accidentally once or twice created deadlocks when refactoring code (like extracting things that were outside processes to be processed inside a given process instead because you decide you want sequential flow) but that has never been a practical problem because you just notice it the first time you test (manually or automated) it that it just ain’t moving forward as it should. Anyway, thought it was interesting.
Not all deadlocks are as easy to see, and in the past it has resulted in e.g. smart contracts managing large amounts of money locking up (making the money unusable for everyone).
But isn’t that because the contracts could “mutate” the underlying wallets/transfers wtv while being called repeatedly?
In a BEAM process, if there was a deadlock then the first message would deadlock the process and no further messages to that process would be processed until the deadlock unlocked?
There what seems to happen is that the same smart contract, for the same wallet is called repeatedly and there’s no sequential processing, that “process” (I don’t know how a smart contract runs in ethereum) that is handling the call can still be called repeatedly. In the BEAM you would probably have an uniquely identifiable process - identified by the msg.sender and/or target wallet, wtv - so repeated activations of the contract would only be processed after the first one was handled (and each subsequent one after the previous on was, and so on), so the amount would be reflected when the next message was to be processed?
(ofc running a totally distributed network would make it probably thornier to figure out how to only allow a single processing point, but I mean conceptually)
