Readit NewsThe WebAssembly community should really focus more the developer experience of using it. I recently completed a project where I wrote a compiler¹ targeting it and found the experience to be rather frustrating.
Given that Wasm is designed with formal semantics in mind, why is the DX of using it as a target so bad? I used binaryen.js to emit Wasm in my compiler and didn't get a feeling that I am targeting a well designed instruction set. Maybe this is a criticism of Binaryen and its poor documentation because I liked writing short snippets of Wasm text very much.
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.
One limitation of JSON is its limited set of types. For example, for decimal numbers one has to resort to stringly typing representation because DB connection libraries assume that JSON numbers are floating point. Note that JSON numbers are just sequences of digits, nothing more. There is no attached precision semantic.
Another example is UUIDs. Instead of transferring 16 bytes, the libraries deal with wasteful string representation. I'm sure you can bring another examples.
Nonetheless, for majority of data JSON as DB output format is alright.
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).
The OLAP world has much nicer type systems eg https://duckdb.org/docs/stable/sql/data_types/union.html.
jamii commented on Evidence that AI is destroying jobs for young people derekthompson.org/p/the-e... · Posted by u/duck
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.
jamii commented on Evidence that AI is destroying jobs for young people derekthompson.org/p/the-e... · Posted by u/duck
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.
https://docs.google.com/spreadsheets/d/1z0l0rNebCTVWLk77_7HA...
>> func (thing Thing) String() string {
if thing == nil {
return nil
}
str = ...
return &str
}
It seems like the "..." of str = ... is the interesting part.
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:
func (thing *Thing) String() (string, bool) {
if thing == nil {
return "", false
}
str := ...
return str, true
}
I like the single C file, but Docker if you want all the examples approach, that's really convenient for embedded.
Test coverage looks good as well, be interesting to see the metrics.
This would be quite cool for adding scripting to medical devices, avoiding the need to revalidate the "core" each time you change a feature.
An interesting comparison would be against an embedded WASM bytecode interpreter like https://github.com/bytecodealliance/wasm-micro-runtime, which is still much larger at 56.3K on a Cortex M4F. Maybe WASM is just a more complicated instruction set than the smallest RISCV profile?