anp

IIRC the issue I had with salsa was that there’s no way to compose multiple databases from separate libraries and have them use the same incremental storage without deep integration.

This reminds me of a hypothetical project I would take up if I still had a dog and a small yard: building a poop cleanup map from CV processing of camera footage.

Stepping stone toward a Poopba, obviously.

I think seL4 didn't yet have multicore support when zircon was forked from LK, could be wrong.

I used to work in an environment not dissimilar from what's described above. The uni has some hardware details here: https://in.nau.edu/hpc/details/. Many of my answers would be similar, although the presence of physics, astronomy, and a few other areas motivates GPUs these days apparently. I was doing genomics workloads in the 900-1200gb RAM range with 30+ cores.

There's a pretty interesting NSF-wide project for managing clusters in a more commoditized way as part of https://www.xsede.org. You might describe it as a "private heterogeneous almost-cloud" in its goals? That might be saying a bit much.

Density, latency, storage throughput, etc. were in favor of DIY (plus the pricey professionals to run it) rather than cloud offerings. When I was there (2016) I did some basic math for being able to use a cloud provider for some of our lighter workloads when the local cluster was loaded down. Astronomical without a contract, which is quite the thing to set up, etc.

Worth noting that while they do alright, NAU (first link) is hardly a top-tier university with bleeding edge technical requirements.

It’s wasteful if you assume it could be automated, but helping customers find things is just “service” most of the time.

Isn’t that just the (née sulong) llvm frontend? IIUC GraalVM is deeply dependent on OpenJDK internals.

IIRC V8 can now provide deterministic JIT+heap images in addition to preparsed bytecode images.

EDIT: worth noting that other JS VMs like JSC have these APIs for bytecode too, but i can’t remember off hand whether they can do generated code too.

I bought a Vive Pro Eye specifically to try and develop eye tracking navigation for a system like this. I haven’t done any actual digging yet bc it turns out the NDAs for their SDK are...unfortunate. Definitely an opportunity for a free/open alternative.

What a great question! Because it's implemented as a const/codegen feature I'm not sure what it would mean to support it for proc macros. Probably gnarly design/RFC work?

Rust binary size can be pretty painful, depending on what you're doing. Also, it doesn't look like that document is receiving regular updates, so grain of salt and all.

If anything I expect MLIR to make things more confusing as Rust’s MIR is probably going to be around for the long haul.

I enjoyed this quite a bit. I had read Nikolai's comment back when it was linked in a few discussions and felt familiar with the techniques, but it's really nice to have a detailed catalog with explanations and links :D.

nit re:

    Although designed to help speed up the parsing of 
    XML documents, it turns out they’re also useful for 
    optimizing web-related features.

HTML is syntactically very close to XML in a bunch of ways (cf XHTML's attempt to unify them IIRC?), so it seems almost exactly like the intended use of the instructions based on this description.

Hey, Richard K Morgan said he was ecstatic with the adaptation. I prefer the novels’ Envoys too but am willing to follow the authors lead overall.

In moxie, everything is procedural, as it were. The declarative syntax is a way to invoke "imperative but idempotent" functions, and the core runtime provides tools for wrangling mutability and repetition in those functions.

Familiarity. In short order it’ll be easy enough to write moxie functions without the xml macro, at which point it becomes a matter of preference.

<3

Good to know! I was incorrect to take GPs claim at face value, perhaps.

(BTW I’m not sure if you remember our conversation at React EU in 2017, really enjoyed chatting!)

If moxie brings anything new to the table, it’s only because I copied liberally and shamelessly from React and other successful and interesting projects, learning and improving on them in the process. If it doesn’t bring anything new, then it’s because I copied liberally and shamelessly from successful and interesting projects :P.

I’m flattered to be compared to long standing paradigms I’ve had in mind (and others I am learning of now) while working on this.

> The code looks almost like it is declarative. But really it's just Dart code

I need to figure out how to express this better in the future, but if you swap "Dart" for "Rust," this sentence applies to moxie as well. It's what I mean when I say that the callgraph of functions is used for structure.

moxie-dom is compiled to WebAssembly, and mutates the DOM using APIs from javascript. The Rust isn’t translated into JS, but it does run alongside it. moxie-native doesn’t have anything to do with JS or HTML, aside from reusing some concepts from CSS.

Good idea to make a DOM example for the calculator! I'm very behind on examples.

Someone recently got very close to having the moxie-native calculator working in a browser's wasm/webgl, which will be mindblowing if they get it to work.

I'm not happy with the state of the syntax, but I'm pretty sure it'll take me farther than this attitude.

It's unkind to call someone else's work "awful," even if its meant in a very minor way (even if I agree with it!). It's a low value comment when it doesn't provide any concrete feedback on top of that. Our industry has abysmal standards for discourse and I'm not sure why you think that's important to apologize for and normalize.

Don't see why not, although to do so you'd need to use moxie-native which is still very new.

> And no possible declarative model can capture it. Functions can.

If functions are your declarative model, what would you say?

From far down in the post:

> I have described moxie a few times as "what if a React in Rust but built out of context and hooks?"

Agreed! I have some thoughts about how this can be handled but it’ll be a little bit before we can try them out.

Great idea on the intro. Moved some things around, should be online soon.

Thanks for the kind words <3

> traditional desktop GUI programmers finally realize

FWIW, I'm not a desktop GUI programmer nor am I an...uh...professional GUI programmer of any kind. Not sure exactly who is doing the realizing here, but if they are, then great!?

> the way the Web people do GUIs is right

There are definitely some attractive things about web frameworks' approaches, but it's important to remember that the history of "declarative UI" traces a path back through C++ imgui devtools before React happened.

I see the transition here differently -- the web is so opinionated about the DOM and its rendering engine, the only thing you can iterate on to make yourself more productive is the frontmost application semantics. Full-pipeline UI toolkits have to manage changes across all the various phases of their implementations.

This (I think) creates an environment where the web is a great incubator for application model experimentation.

However, many projects that start on the web have a difficult time faithfully mapping to the semantics of other GUI systems (one of the driving forces behind Electron adoption IMO). This gap is one that moxie hopes to bridge -- ideally we should be able to learn from the highly productive web ecosystem while transferring those learnings further into the UI stack without the overhead and performance cliffs of typical web tools.

> some kind of customized ergo keyboard

I use an ErgoDox, and while my layout isn't customized for writing mox invocations, it hadn't occurred to me that this might be a blind spot in my thinking about ergonomics. Good point!