joel_dice's comments

I created https://github.com/dicej/component-sandbox-demo when you asked about this on the Bytecode Alliance Zulip. Curious if you have any feedback on it.

There's a simple example of using React server-side rendering here: https://github.com/fermyon/spin-js-sdk/tree/main/examples/ja.... We haven't tried anything more advanced than that, yet, but a full-blown isomorphic app should work fine in theory.

The main limitation at the moment is that we only support a handful of Web APIs (e.g. `fetch`, `URL`, etc.) and NodeJS APIs (e.g. `readFile`), as well as QuickJS's built-in ES2020 APIs, so if you try to run an existing app you may find it needs a Web API we don't yet support. If so, please feel free to open an issue on the `spin-js-sdk` repo.

This resembles ascending a rope using prusiks, which is a lot of fun if you haven't tried it. Great to see a variation the helps people with limited mobility to get around unassisted.

I've been making my way through this book for the past few weeks; just started Chapter 20. I tried reading Harper's Practical Foundations for Programming Languages first, but it was too abstract for me, so I switched to TaPL.

What I like most about Pierce's book is that he introduces each concept with a formal, abstract definition, complete with proofs of correctness, but also follows that up with a concrete implementation in OCaml. The latter is very easy to follow if you've had some experience with the ML family of languages. I sometimes find myself skipping ahead to the OCaml version when I get lost in the math syntax, which for me is less familiar. I'm planning to come back to Harper's book later, but Pierce's book is the perfect fit for where I am now.

My only criticism is that some parts are very dated given it hasn't been updated in almost 20 years. In particular, the version of Java he discusses throughout the book (pre-generics, pre-type-inference) bears little resemblance to the modern one. And since 2002 we've seen affine types (e.g. Rust) start to have mainstream influence, among other things.

In case it's helpful, I'm compiling a list of resources as I learn type systems, logic, category theory, etc.:

https://gist.github.com/dicej/d1117e5d65155d750c16234e6eff16...

I've implemented a RDBMS that supports this [1]. It handles joins, views (which are automatically materialized and incrementally updated), etc. It's memory only, and it doesn't support exotic stuff like recursive CTEs, but it does exactly what you're asking for. We used it in production successfully for frequently-updated real time data at the company where I used to work.

Notably, it uses persistent search trees such that each revision shares structure with the previous one, which makes diffing two closely-related revisions extremely efficient (just skip over any shared structure). Subscribers just receive a stream of diffs, with backpressure handled automatically by skipping over intermediate revisions. See [2] for a more detailed summary.

It also exposes revisions as first-class objects, which allows you to tag, diff, and even three-way merge them. Specifically, you can run arbitrary queries on both revisions and diffs. See [3] for examples.

It's no longer maintained, unfortunately. Someday I may revive it, perhaps adding support for spilling data that won't fit in memory to log-structured merge trees. I'd also rewrite it in a language like Rust, which will help flatten some of the more pointer-heavy data structures and reduce tail latencies. If anyone is interested in seeing that happen or helping out, let me know.

I'm really surprised this still isn't supported in mainstream DBMSes. The MVCC model in PostgreSQL seems particularly well suited to it.

[1]: https://github.com/ReadyTalk/revori

[2]: https://github.com/ReadyTalk/revori/wiki/Design-and-Implemen...

[3]: https://github.com/ReadyTalk/revori/wiki/CLI-Revori-Client

I've been biking year-round in Denver for decades. The winters here are relatively mild, but we do get blizzards now and then.

I tried studded tires, but found they didn't help much. Black ice is rare here compared to layers of snow and slush, which don't give studs much to bite into. For me, three inch tires with an open tread pattern at low pressure -- plus an upright riding position that distributes weight evenly between the wheels -- gives me the most confidence.

Regarding the cold, I'd say windproofing is most important, and expedition-style mittens are well worth the investment. You won't need much insulation (except maybe at the extremities) once you start generating body heat. Multiple top layers, each with their own full length zipper, will let you regulate your temperature without getting off the bike. That's especially helpful if you have long climbs and long descents.

Nice work! I spent about six months pursuing the exact same idea about five years ago with the hope of building a company around it. I got reasonably far with a prototype, but gave up on the business side of things after doing more extensive market research and interviews.

One of the people I talked to had been involved with a startup called Adrenaline Mobility which did something very similar, but ultimately ran out of runway and was acquired by Twitter. He told an interesting story about how they (over-)built a highly scalable service but had a really hard time selling it. Those who lack the training to know the difference between good security and hand waving didn't see the value, and those who did have the training and skills didn't trust a third party to do it right anyway.

Nonetheless, a lot has changed in the past five years, and end-to-end encryption is more widely appreciated now. I hope you have better luck with the commercial side of things; this looks like a very promising start.

On the topic of inactive continuation implementations for Java: I implemented native support for both delimited (shift/reset) and non-delimited (call/cc) continuations in the Avian JVM. See https://github.com/ReadyTalk/avian/blob/master/test/extra/Co... for some mind-bending examples.

Noria is an interesting one: https://github.com/mit-pdos/noria

It's compatible with the MySQL wire protocol and offers extremely efficient, incrementally updating materialized views.

I wrote most of the Avian VM, and I agree that the code generation is quite primitive compared to LLVM's. We've considered using LLVM as an alternative code generator, but hesitated partly because LLVM used to require a shadow stack to support accurate GC. I just checked they're latest docs[1], though, and it seems that there are other options now.

All in all, adding LLVM support to Avian would be challenging but doable. However, Avian's generated code is already fast enough for most purposes, and it's not too hard to fall back to a bit of native code when you need maximum performance. My impression is that Java-on-iOS developers are less concerned about performance and more concerned with ease-of-use (e.g. tool integration) and convenient access to native APIs (e.g. Bro[2]). The RoboVM devs have apparently done a great job on both of those things.

I sympathize with Zechner and the other RoboVM devs. Development on Avian was originally funded by the company I was working at since it neatly addressed a problem we had: extending the lifetime of a large body of client-side Java code in a world that was/is increasingly unfriendly to client-side Java. Once it was good enough for that purpose, there was no business reason to continue investing in it besides bug fixes and maintenance, so we had to move on to other things.

I'd love to keep working on Avian full time and do cool stuff like an LLVM port or trace-based JIT compilation, but it's hard to justify when there are bills to pay. In my case, that means focusing primarily on other, income-producing projects. In RoboVM's case, it means trying a new approach to licensing to make development sustainable. I wish them luck with it.

[1] http://llvm.org/docs/GarbageCollection.html [2] http://docs.robovm.com/advanced-topics/bro.html

You can use Avian with the OpenJDK class library to produce a standalone executable, in which case java.awt.Robot should work. ProGuard could help to keep the size down.

It would also be possible to implement java.awt.Robot from scratch and add it to Avian's class library. That would give you a smaller executable but require significant effort and a lot of platform-specific code.

The best choice depends on what aspect(s) of a "full blown Java VM" you're trying to avoid: e.g. size, installation complexity, licensing issues, etc.

As dkharrat pointed out, you can use the Avian VM with the OpenJDK class library instead of the much more limited default library. However, there's no support for JVMTI, and not everything in the OpenJDK library will work with every combination of platforms and build options.

Technically we don't support running the Avian VM on Android, although it should work with minimal porting. However, we support using the VM with any of three class libraries: Android's, OpenJDK's, or Avian's. So, ironically, you can use Android's class library with Avian on every platform you listed except Android :)

If there's interest in porting Avian on Android, we could do it, but since it already has Dalvik/ART, I'm not sure there's much of a point.

Specifically, it supports native first class continuations, including both call/cc-style and delimited (shift/reset-style), which can form the basis for coroutines, generators, and other fun stuff. It also supports full tail call optimization.

Both of those features work with Java, Clojure, Scala, etc. For example: https://groups.google.com/d/msg/clojure/U4i4nVsYfi8/1GSGgNM8...

More info is available here: http://oss.readytalk.com/avian-web/javadoc-1.2.0/avian/Conti...