A key goal of Spritely is that different instances can be written in different languages as long as the code obeys the protocol. Still, a reference implementation will be important to attract developers. Criteria if that implementation is to achieve its goals are, in order of importance,
Familiar to a wide audience (rules out APL)
Memory safe (reduces cognitive effort and vulnerabilities)
Availability of needed libraries (especially crypto, but also UI)
A decent development environment (because developers will delta off it)
Performant enough (can’t be so slow as to be annoying, factors of 10 matter)
Small enough memory footprint (not too important, but I’d hate to see it be 10GB)
I was looking at an article focusing on difference in energy use, but it also has data on performance and memory footprint. Some of the data is questionable, (Why is TypeScript 5x slower than JavaScript?), but the relative numbers are interesting.
In spite of the fact that I’m currently really annoyed with its development environment, I think JavaScript best meets the criteria. Python is another candidate, but it is >10x slower. I think Java is another candidate based solely on the criteria l listed, but I’m not looking forward to using it.
Spritely is comitted to providing reference implementations in two languages/environments.
@alanhkarp - Is “Memory Safe” the only security-ish feature required? Doesn’t strict mode in JS do more than that?
I’m also not 100% sure about the library-availability requirement as we’re likely to need to create capability safe ones. Perhaps rephrasing that might include oCap compliant libraries?
Good points. I didn’t include anything language dependent in the criteria, but strict mode, or more likely Hardened EcmaScript, would be the choice for a JavaScript implementation. I’d also like something like Joe-E for Java.
Tamed libraries are very important, but I don’t know if any exist. Is the work Stiegler did for Caja still viable? I expect bit rot has set in for the tamed Java libraries.
I’m not an expert on JavaScript, but I do work at Agoric with many who are. The expectation seems to be that hardened JavaScript will make it reasonable to re-use many of the standard JavaScript libraries safely. This applies especially to pure computational libraries, but we’re also making use of some of the popular UI frameworks.
Given Oracle’s apparent desire to lock down Java with patents and license terms, I think it might be better to avoid it. [bias disclosure: I am disposed against Java based on years of programming in it.]
Has Agoric published/shared anything about hardening any of the popular UI frameworks?
No.
I’m not familiar enough with any of the frameworks to have participated in discussions concerning them, so I don’t know how they’re being handled.
I’ve held off on replying to this one until I had the energy to ramble a bit.
Of course, Spritely already does have [a] reference implementation[s]… two of them! One is in Racket, and one is in Guile. These are both in scheme, so it may appear that this is a trivial port, but you’d be underestimating the amount of effort between these implementations because of wide divergence between the languages. That said, we do want a non-scheme, non-lisp implementation (and I agree that JS is the most likely target… the question is whether or not a port needs to be done at all, if demonstration with Agoric’s tooling can be done, or if cross-compilation to JS/WASM is possible. But that’s for the kernel-layer… Goblins/Swingset, basically. That’s just the foundation for Spritely’s work.)
However, the fact that Guile and Racket are much more similar than most but not quite as similar as they appear was intentional for the porting effort. Rather than simply copy-pasting the Racket code and massaging it until it was valid Guile code, I ported from Racket in Guile in stages… see the pre-goblins drectory in the Guile-Goblins repo. This done with the very intent that we’d be able to port to other languages in the future, and also to give me a chance to reassess the fundamentals of Goblins. I was surprised even though Goblins was mostly manually re-typed-in in phases, I ended up finding that most of the design decisions that have been made felt like the right ones. That’s not usually the case for something like this, so it increased my confidence in Goblins’ design greatly. It also means that porting elsewhere, and having a workflow for porting that can be reproduced, is very possible.
Now, @alanhkarp gave a list of requirements at the top. I agree with them, but I think there are other desirable properties which are missing. More soon… I will expand on the thinking, rationale, and some projections, in incremental pieces.
I’ve advocated in the past for rust, for a few reasons: it both has a lot of momentum and a chance to influence the default inclinations of its users, it has a community that is already experimenting with capabilities, and it’s sufficiently different from Scheme (static type system, AOT compilation, C-style, close to the metal) that it would demonstrate that Spritely can work indepedently of those language characteristics. There are also a lot of eyes on it right now.
Javascript I agree is a good choice, but with Agoric working on a (hopefully compatible) network ocap library there, I think it’s worth it to push a bit further out.
I also think that it’s worth reaching out to language communities who are much (much!) smaller but would benefit from a collective connection to what has the potential to be a multi-language object marketplace.
The descendants of Smalltalk were built for that world in some ways, especially Newspeak with its capability-adjacent security model (Gilad has been doing some renewed work on it, I hear).
Common Lisp would be an easier hop and has been getting some “so retro it’s fun again” traction recently (I remember when vi the editor suddenly leapt back into popularity as a new generation discovered its obscure appeal).
Really it’s less about “what can this language do for Spritely” and more “what can Spritely do for this language”. Some language ecosystems have a niche that Spritely would fit nicely into — either because secure networked objects haven’t been seriously worked in that ecosystem, or that the previous solutions have atrophied away. Others, I think, have other similar equivalents or a huge diversity of competing choices which makes it tricky for Spritely to get a foothold. Python’s Twisted architecture for instance, or C++’s vast back catalog would make it hard for folks to notice Spritely or wire it into existing work.
I’m happy to verify my learnings of these spritely concepts and potential for interoperability by implementing in JavaScript and/or TypeScript. I want to believe it is possible.
Also my language learning time allocation is going towards rustlang, so if anyone starts implementing things in that, it may be good for me to try following along.
We don’t harden any of the popular UI frameworks. We integrate our hardened JS code with them, though… with no small amount of wailing and gnashing of teeth.
I suppose most of the wailing is around build tools: front end dev requires a bundler, and bundlers tend to mangle the SES shim.
The most recent solution I have seen to this is:
but I tried to reproduce those results in a project of my own without luck.
OOoh! Glad to see someone is putting in that work I’ve been mulling over how I would implement something similar if it ever got to it. So glad I won’t have to
He he, I think you’ll get as many language suggestions as there are developers with their own preference
Bringing in Erlang/Elixir. Not the biggest, most popular language but growing in popularity (e.g. by attractiveness of Phoenix LiveView for webapps). It is nice to have a reference impl. based on FP paradigm. And Erlang/OTP has a native actor model. The language is specifically designed for distributed, fault-tolerant applications (originating from Ericsson for use in telecoms applications).
That said, we do want a non-scheme, non-lisp implementation (and I agree that JS is the most likely target… the question is whether or not a port needs to be done at all, if demonstration with Agoric’s tooling can be done, or if cross-compilation to JS/WASM is possible. But that’s for the kernel-layer… Goblins/Swingset, basically. That’s just the foundation for Spritely’s work.)
