anp

Yeah, I'm not the biggest fan of the syntax still either. That said, the phrasing of your comment is unkind and its contents don't provide any useful feedback.

Ah, that's a good reference for a more modern "control loop" idea. I agree that there are many similarities with that specification and I need to read in more depth. Thanks!

Honestly, there's limited advantage over vanilla HTML5 if HTML is actually what you were going to write. The website at moxie.rs is plain HTML/CSS/etc. The reason to reach for tools like this on the web is if you want interactive state, complex data transformations, etc.

I think it will be hard for moxie-dom to compete directly on ergonomics with purely web-focused tools (especially JS frameworks), because the underlying tools will always need to maintain some distance from platform semantics.

Fairly well, although I need to manually format it. VSCode's syntax highlight for rust doesn't do anything fancy for tags and attributes, but literals and block expressions are highlighted correctly.

It seems like Materialize has some interesting approaches in mind:

https://www.youtube.com/watch?v=zWSdkGq1XWk

Thanks for the tip! Should show up shortly.

Heartily agreed re: Materialize, and I've also been nerd-sniped by Adapton, although less literally than incr_dom.

I think there are some very strong parallels between the approach Svelte has taken and what I'm trying out in moxie-dom:

https://twitter.com/anplolol/status/1121128610918567936?s=20

screenshot? how does reader mode look on your phone?

Author here. I'm trying out an optional email Q&A format on the post, but will also be keeping an eye out here.

How do you feel about using someone's name?

I think BuddyBuild is an interesting point similar to Fastlane because they were IIRC acquired and shut down the cross-platform side of their operation. I’ve always been curious about the motives for that move, given the apparent organizational disagreement at Apple over the value of developer experience.

*: https://www.buddybuild.com/blog/buddybuild-is-now-part-of-ap...

Id say that in Rust’s case, we’ve already seen several painful examples of Hyrum’s law.

http://www.hyrumslaw.com/

It does depend on this yes, but the random seed isn’t part of the public API. An RNG API in std would need to pick an algorithm and make that part of its stability guarantees.

(past edit window) This was written with hostility I don’t feel. Sorry Raph!

The API you describe, IIUC, can’t be serviced faithfully on the OSes targeted by std while being backed by real entropy.

How do you accommodate breaking changes to the public interface of std?

I agree that in many cases a much simpler API would suffice, but it strikes me as odd to suggest adding a convenient but insufficient-for-security API to the same standard library that protects HashMap against DoS.

In a Rust implementation of your example, you might not necessarily spawn the two sub-operations as separate tasks. Awaiting them directly in a parent async function (probably using FuturesUnordered, like Promise.all in JS) will cause all of their work to be scheduled, prioritized, cancelled, etc. together because they’ll be a part of the same task. There’s a 1-many relation from tasks to Futures in Rust.

Was this work a part of the post's unnamed self-driving car company project?

> The idea that you can ignore the real hardware is particularly unhelpful in Rust, because it's a great fit to low-level problems where the real hardware is a big deal. For example, at work, we have a Rust program where we routinely need to think about NUMA placement and cache coherency protocols. Those don't exist in the Rust abstract machine at all!

If I understand Ralf's overall model here, I think they'd argue that this sort of reasoning must be done within the context of the abstract machine's behavior for std::ptr::{read,write}_volatile, no?

> If you want JavaScript's behavior around failure, you make the final value a Result, it's not built-in.

Fun bit history: the first pass at Futures did return an error type explicitly: https://docs.rs/futures/0.1.28/futures/future/trait.Future.h.... IIUC the idea was that Futures were for performing I/O which is effectively always fallible. I assume that it's an easy design decision to make looking at all of the other languages with similar designs. I'm very glad Rust has nicely orthogonal "deferred"/"fallible" types now.

How’s the OCaml multi core rollout going these days? IIRC shared memory parallelism requires FFI still.

What’s your opinion on the password management that chrome offers these days?

Pattern matching as is in Rust has many notable precedents that IIRC the C# folks considered as prior art, not least of which being F#.

This resonates quite strongly with me, and I would recommend Suikoden 1/2 for the same reasons.

I could have sworn std aborted on allocation failure, not panicked. Am I misremembering?

It's good that you include "shameless plug" in these posts to clarify, but it would be much much clearer if you included more explicit phrasing along the lines of "I only post to HN to plug my project called SaferCPlusPlus, not ever to talk about the submitted article. You can see here: https://news.ycombinator.com/threads?id=duneroadrunner."

I’ve longed for something similar in writing JavascriptCore bindings. Something lighter weight than swig but which still has an IR for describing the full API surface for codegen plugins would be immensely useful.

Well this interpretation certainly explains some of the reactions that word has gotten in my use of it!

I talked about this a little bit in the meetup talk I linked and I intend to write a bit more about this, but I'll try to summarize.

There are kind of three prongs here:

First, using criterion.rs does a ton for giving us more stable metrics. It handles things like warmups, accounting for obvious statistical outliers in the sample runs, postprocessing the raw data to provide more meaningful statistics, etc. I'm currently using a fork of the library which additionally does this recording and processing of a variety of metrics we get from `perf_event_open` on Linux but which I assume you could get through ETW or Intel/AMD's userspace PMC libraries.

Second, I try to provide a stable environment so that results over long time deltas are comparable and we can store the data for offline analysis rather than having to checkout recent prior commits and compare the current PR/nightly/etc against them. Prior to the current deployment I was using cgroups to move potentially competing processes off of the benchmark cores which produced some nice results. However I had some issues with the version of the cpuset utility I installed on the debian machines and I haven't sorted it out yet.

Third, we do a few things with the time-series-esque data we get from measuring multiple toolchains to try and only surface relevant results. Those are mostly in src/analysis.rs if you want to poke around. It basically boils down to calculating the Kernel Density Estimate of the current toolchain's value being from the same population (I hope these terms are halfway correct) as all prior toolchains' value.

I hope that with a few extensions to the above we can get close to being reliable enough to include in early PR feedback, but I think the likely best case scenario is a manually invoked bot on PRs followed by me and a few other people triaging the regressions surfaced by the tool after something merges.

Here are a few issues that I think will help improve this too:

https://github.com/anp/lolbench/issues/20

https://github.com/anp/lolbench/issues/17

https://github.com/anp/lolbench/issues/14