Hacker News Reader

Comment by chc4 | Hacker News Reader

I really like the idea of a binary tree memory model, especially an acyclic one. It appeals to the mind in the same way Lisp s-exprs do, and possibly even more: everything is either [head tail] or a number! How stupid!

As far as I know, a lot of this stuff is fairly novel as well. Imagine you could simply mmap() bytes into your process from the network, verify that it nests inside your type definition (including recursive members!), and not have to worry about following evil pointers while still allowing arbitrary-sized members. This actually happens in urbit: all network messages to apps, including those sent from a web browser to your personal planet, are just ++jam nouns with something like an executable mime type plus autogenerated type verification function

Of course, I'm pretty biased about Urbit, so your enthusiasm may vary.

View on HN

It sounds a lot like google protocol buffers, or one of the many java serialization frameworks. This "jam" thing may be better integrated into the urbit architecture, but without any portability/interop with other systems/languages.

See the comment above; it's nice not to need a separate framework. At least, for Urbit to Urbit networking.

Of course there's nothing stopping you from encoding or decoding anyone else's protocols in Urbit. Or vice versa. Actually, using bit functions on bigints is a fairly pleasant way of handling binary protocols.

There's also no particular problem in generating or decoding jammed nouns on non-Urbit systems. It's a binary encoding, but the decoder is a page of code. Perhaps jam:ASN.1 as JSON:SGML. :-)

That's just about how it works with Cap'n Proto, https://capnproto.org/

No idea about if you could do it with mmap from the network, that'd be an OS thing and I suspect not possible to do from a streaming protocol like TCP in most places.

CP is one of many IDLs [1]. IDLs are great, but there is always an impedance mismatch in translating a language's native data structures to a language-independent IDL. Someone has to do this work, though there are sometimes various scary ways to do it automatically.

In any case, the idea that validating or describing external or untrusted data is the job of an additional system outside the programming language, rather than the job of the language's type system, seems mainly historical. Sending data over the network was a new and unusual use case when most of today's languages were being designed. It isn't now.

[1] https://en.wikipedia.org/wiki/Interface_description_language

Yup, I've heard of Cap'n Proto before, but unfortunately never worked with it. I was under the impression that you still had to write the specfile yourself, and that deserializing malicious data was unsafe (along with being platform specific), but that doesn't seem to be the case.

Urbit RPC is how I imagine RPC should always be: sending a message to `:talk` isn't actually a procedure call, but instead just sending a noun that it pattern matches on. You just say "send %talk on ~doznec this noun [%msg 'hello world']", with ~doznec on the other side automagically verifying the type with a living spec of code and molds and calling the correct function that takes the type you sent.

The fact that this all happens completely transparently, even for sending messages to local apps (and hence embrassing remote servers), and as a core feature of the language is great.

> deserializing malicious data was unsafe

Deserializing malicious Cap'n Proto messages is safe (barring some now security bug found in the implementation). Cap'n Proto RPC is explicitly designed to be used between mutually non-trusting parties.

Reply on news.ycombinator.com