bvisness

Everyone knows it is impossible to translate 1000 lines of JS to C in a reasonable amount of time. I mean, 1000 lines is kind of a lot, you know?

I’m not sure how far you can push the generality of the iongraph algorithm. My gut is that it could be made to work somewhat well for any control flow graph with reducible control flow, but I expect there would be many complications.

No LLMs were used, at least not in any substantial way.

The part that is timing out is actually the JS interpreter, not the graph viewer. It’s a total hack to get SpiderMonkey running on the page at all.

The full Frankenstein stack is: SpiderMonkey compiled in arm emulation mode, to a WASI 0.1 module, adapted to a WASI 0.2 component, transpiled to the web with jco, running in some random WASI shim.

We do this because the JS runtime needs inline caches to be filled out before optimization, which requires an JIT and actual execution of machine code. Otherwise you just get a graph full of Unreachable. Frankly I’m amazed it works at all.

I agree that we haven’t gained much yet from looking at large graphs. Usually we can reduce any problem of interest to something small. Still, Graphviz produces very ugly results even for small graphs, whereas this is where iongraph shines.

To be clear, what I think makes the latter graph more readable is particularly that the wires are easier to follow. Yes, it’s subjective, but backed up by my own personal experience. Long term I think we can add more interactive features to help us in such cases, e.g. search and dimming irrelevant wires.

Thanks for the most boring title I could possibly imagine for the article I spent all that time writing interactive animations for.

It’s hilariously terrible. My favorite reaction comes from an acquaintance of mine: “it looks like somebody stuck a scrotum on the Darwin fish”

Hello, I am the engineer in question. I am not actually super familiar with the details of the build system, but from when I saw, the main issues were:

- Lots of constant-time slowness at the beginning and end of the build

- Dubious parallelism, especially with unified builds

- Cargo being Cargo

Overall it mostly looks like a soup of `make` calls with no particular rhyme or reason. It's a far cry from the ninja example the OP showed in his post.

Yes, this is my primary personal motivator as co-champion of the proposal. But, going “fully virtual” is hard because of the very wide array of use cases for wasm.

For example, there are embedded users of wasm whose devices don’t even have MMUs. And even when running on a device with an MMU, the host may not want to allow arbitrary mappings, e.g. if using wasm as a plugin system in a database or something.

It’s likely imo that any “fully virtual” features will be part of the wasm web API and not the core spec, if they happen at all.

This is a delightful take on a style of UI I really love. Separating the UI logic from drawing with a set of draw commands is an excellent and very versatile idea - I first saw it in microui, and the separation allowed me to easily use the library in the browser using WASM and Canvas2D. (https://rxi.github.io/microui_v2_an_implementation_overview....)

Also, doing layout in WASM and rendering to HTML is a great idea that I can't believe I never thought of before.

I think the culture of JS has been reinforced over time, and the result is a novel form of paranoia. npm makes package-sharing easy, developers share trivial packages, people use trivial packages, people rationalize trivial packages, people teach beginners never to write code, beginners think they can never write code, beginners grow up and here we are.

Certainly the language is quirky, but it really doesn't change that much. Frameworks have come and gone but JavaScript itself is still the same. is-number would have looked much the same 15 years ago, if anyone was crazy enough to actually distribute it.

You, specifically.

If we had perfect knowledge, we could choose perfect libraries. But we don't. Maybe someday.

Yeah it's a baffling example to me. WordArt was really popular! People liked using it! The fact that it has aesthetically gone out of favor, years later, has nothing to do with software quality.

That doesn't make sense to me. Unless users are presented with alternatives, they will have no choice but to use the garbage they are given - nor will they be able to recognize how much better software can be.

Better software has to start with the programmers. We're the only ones who ACTUALLY know what the hardware is capable of, and the only ones capable of setting those new expectations. This is why we aimed the manifesto at programmers. It is not the user's fault.

> Ideally there would be superior alternatives to something like Electron while still remaining accessible.

That's exactly why we in the Handmade Network community are building Orca (https://orca-app.dev/). It will take a while, but that's the goal.

Designing the platform APIs around C is generally the right move in our opinion. Of course we want Orca to support multiple languages, but we also want APIs that will bind well to many languages and that will be flexible and performant. Furthermore, WebAssembly today is a great fit for C-like languages, and...less of a great fit for other paradigms.

We already have strong WIP bindings for Odin and Zig, and intend for our documentation to strongly feature all three of C, Odin, and Zig when we launch the next major version.

The next Wheel Reinvention Jam will be in September! We're just finalizing our plans for that jam and our smaller Visibility Jam in July. If you're interested in participating, then join the Handmade Network Discord server (link on our home page at https://handmade.network/).

As I said in the article, JSX is distinct from frameworks like React. The interface between the browser and server is HTML; LuaX allows me to author that HTML in a more structural way before sending it to the browser.

Also I can totally use any tag I want. LuaX powers the RSS feed of my site too, with all its `atom:link` and `pubDate` and `guid` tags. It doesn't care about the names of tags, only the structure.

Yeah, the git history will back me up in any actual copyright dispute. I just have the date in the footer to keep my website from looking old and stale.

I didn’t like any of the other solutions I’d seen! And besides, you’re talking about someone who hosts a yearly Wheel Reinvention Jam… https://handmade.network/jam/2023

In some cases you can use the block system in Go templates, but it is extremely sad. I actually made a proposal for an extension to Go templates that would make the “component” workflow a little easier[1], and used it on my site before switching to LuaX, but at the end of the day I don’t like switching languages and I don’t like recompiling my site while I’m writing. Go templates are fundamentally not what I wanted.

[1] https://github.com/golang/go/issues/54748

As with PHP, that’s outside this part of the system. My personal site looks up paths in the filesystem like old-school PHP, but you could also do some kind of “routing” definitions if you wanted, like…new-school PHP.

No - in fact, I spent about three hours manually syntax highlighting all the code examples in the post!

At some point maybe I’ll make syntax highlighting for my editor, but it’s not a super high priority for me.

It is actually open-source already if you know where to look, but heads up that it’s not documented for public use (and as mentioned, I cut some corners on the parser). https://github.com/bvisness/bvisness.me/blob/main/bhp/transp...

Anything a user tries to do to ask for help is correct behavior that you need to support. It is a crime to tell the user “you asked for help incorrectly”.

I suggest supporting at least all of the following: -h, -help, --help, -?, /h, /?, help, <no flag> (if possible). Other flags don’t have to follow these rules, but I think help can be an exception.

And maybe you should print the help any time the user enters a bad command.

Some of us just wander into the Rust part of the codebase every so often for our work.

I cd’d into the folder with the cargo.toml, ran cargo fmt, and nothing happened. I dunno what else to tell you. Sometimes things just aren’t set up the “right way”, and yet we still have to do our jobs.

Yes, I completely agree. If you want to teach the user the rules, then you follow the rules. The problem with the Python example is that they DID special-case it, but in an unhelpful way.

The problem was a strange monorepo setup where multiple packages came from the same GitHub repo. Then I tried to switch one of them to my fork. The error message did not help me understand this reality at all; I only figured it out the very hard way after blowing up my project in two different ways.

All this time after writing this article, I’m now realizing a better way to sum up the issue:

It’s like when you ask “can I go to the bathroom” and the teacher says “I dunno, CAN you?”