Wasm-mvp is very simple, especially if you drop the floating point instructions. But WAMR supports a lot of extensions - https://github.com/bytecodealliance/wasm-micro-runtime?tab=r.... There is a garbage collector, jit, WASI, threads, debugger support etc.
I've tried using binaryen, and I've also tried emitting raw wasm by hand, and the latter was far easier. It only took ~200 lines of wasm-specific code.
Yeah, json is annoying because of the limited types, but postgres arrays/rows are annoying because of the lack of sum/union types (if your UI has a heterogenous list of elements).
I made a stupid simple model where hiring in all age brackets rose slowly until 2021 and then fell slowly. That produces very similar looking graphs, because the many engineers that were hired at the peak move up the demographic curve over time. Normalizing the graph to 2022 levels, as the paper seems to do, hides the fact that the actual hiring ratios didn't change at all.
Wow, that's hilarious. So essentially hiring could be identical across all age groups, but due to a glitch in the analysis (young people don't stay young, who knew?), it appears that younger people are losing jobs more than the rest.
I'm not sure I understand. Your model shows that different group buckets (eg 20-24yo vs 25-29yo) peak at different years (in your figure, 2022 vs 2024) despite being driven by the same dynamics. Is that expected? I (naively?) expected the same groups to rise, fall and have peaks at the same times.
One of the dynamics is that people get older so they move into different buckets.
We can make the model way simpler to make it clearer. Say in 2020 we hired 1000 20-24yo, 1000 25-29yo etc and then we didn't hire anyone since then. That was five years ago, so now we have 0 20-24yo, 1000 25-29yo, 1000 30-34yo etc and 1000 retirees who don't show up in the graph.
Each individual year we hired the exact same number of people in each age bracket, and yet we still end up with fewer young people total whenever hiring goes down, because all the people that got hired during the big hiring spike are now older.
The ... is the useful part. We actually want that string, so we can't avoid allocating it.
But the &str at the end is an additional heap allocation and causes an additional pointer hop when using the string. The only reason the function returns a pointer to a string in the first place is so that the nil check at the beginning can return nil. The calling code always checks if the result is nil and then immediately dereferences the string pointer. A better interface would be to panic if the argument is nil, or if that's too scary then:
I don't think Austral uses second-class references. Even the page you linked says:
> But is it worth it? Again, the tradeoff is expressivity vs. simplicity... Austral’s linear types and borrowing is already so simple. Austral’s equivalent of a borrow checker is ~700 lines of OCaml. The only downside of Austral is right now you have to write the lifetimes of the references you pass to functions, but I will probably implement lifetime (region) elision.
The whole post was about how that doesn't solve the problem perfectly - there is no way to interactively edit the output.
> by embracing LISP principles directly
This could just as easily have been javascript+json or erlang+bert. There's no lisp magic. The core idea in the post was just finding a way for code to edit it's own constants so that I don't need a separate datastore.
Eventually I couldn't get this working the way I wanted with clojure and I had to write a simple language from scratch to embed provenance in values - https://news.ycombinator.com/item?id=43303314.
This is an old prototype. I ended up making a language for it from scratch so that I could attach provenance metadata to values, making them directly editable even when far removed from their original source.
