Demo of the same chat program I wrote earlier in Goblins running over Tor onion services and CapTP:

Here's the thing. The chat program contains *no networking code at all*. Literally none. CapTP takes care of all of it. It's just objects messaging each other. I didn't change a line of it from when I just tested it on my local machine. I just hooked together the two users via CapTP.

If you notice "oh, this looks kind of slow" there are two reasons for that:

- It's running over Tor onion services, which are slow
- I wrote this as the bare minimum proof of concept to see how small it could be. As such nothing is cached... literally every incoming message ends up also re-requesting the remote user's username.

But this is the same 250 line chat program I published a screenshot of a couple weeks ago with no changes to the chat code *at all*.

This is what I mean when I say Goblins is a distributed programming system: here we have something that *looks* like a network program, but the person writing it doesn't have to think about the network pretty much at all. It just looks like normal programming. Which meant that with no changes, the program I wrote to run in one process locally also worked spanning across machines over the network (over Tor onion services even!).

That's *powerful*.

@cwebber Awesome demo!

How are communication latency and failures dealt with? The traditional RPC/RMI model provides full network transparency, which also means it doesn’t provide explicit control over failure modes, etc. Perhaps CapTP handles “dead objects”, and maybe there’s Fiber-style scheduling happening? (Thinking out loud!)

Hey @civodul I have much to say but can't at the moment! Please remind me if I have forgotten to reply to this :)

Great stuff! You put up a nice target there 🔘 👌

@cwebber What happens if the network library throws a bug and I don't know anything about what is inside that box?

@dualhammers sorry would like to reply more but limited time, but the reply here is probably related to what @civodul is asking

@cwebber I have no knowledge in my brain which allows me to make sense of that phrase in the way you probably intend.

@dualhammers yes and it wasn't helpful I suppose but in order to reply in a way you can understand, I need more time than I have at the second!

Ping me in a couple days and see if I can give you a better one.

@cwebber I may :) I was only passingly curious, though.

Good luck with the rest of your work

@dualhammers @cwebber goblins if i understand correctly uses the “promise” pattern for everything, so the difference between this and RPC is that, while RPC makes a network call look identical to a local method/function call, a promise does the opposite, turning all local calls into async calls that might fail. a failure results in a “broken promise”, and if i interpret this right, there’s plumbing for handling broken promises with similar niceties to handling exceptions in languages with those.

@dualhammers @cwebber that is just how i understood what was written. i could be 100% wrong.

@dualhammers @cwebber but fundamentally, as long as you write your code to expect any message from one object to another to possibly fail, it doesn’t make a difference whether that’s over a network. and it makes locally running code more robust, fault tolerant, and parallelisable and debuggable too, since plenty of local resources like user input, file system, cross thread ipc and so on need to follow that async, handle failure model *anyway*

@dualhammers @cwebber and as long as everything is using the one api/language feature for that pattern, code for handling network messages can be maintained seperately from the codebase that depends on it without breaking any api guarantees/expectations as you might with a traditional networking library. as long as the network module can send/recieve messages and report broken promises, it can handle things like security/retry/timeouts in whatever way makes sense in the year it is being written

@zensaiyuki @dualhammers I think that's a pretty good explanation!

And the "broken promise contagion" bit that I didn't explain is that promises which rely on other promises which break automatically are also informed and are broken too, which is a bit like the exception propagation behavior that @zensaiyuki explained.

Thanks for doing a better job explaining than I did! :)

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!