> The goal is that most of your code can have the assurances of static typing, but you can still opt in to dynamically-typed glue code to handle repls, live code reloading, runtime code generation, malleable software etc.
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).
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.
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.
I'm using zig, but there is also a fair amount of c in this project and I step into it fairly often. Gdb itself works just fine crossing between zig and c.
I use rr pretty often. Most gdb frontends also work using rr, as long as they either have buttons for reverse-step or allow you to enter commands directly. That's why I was kind of bummed out that gede, which was the most functional debugger I tried so far, has neither.
> those are the tradeoff between flexibility and ease
It isn't a required tradeoff. Most of the gdb frontends I tried display the local variables at all time, but also allow writing arbitrary gdb expressions if I want to. Having both is clearly better.
* gdb works on zig code, so it isn't unreasonable to expect gdb frontends to also work
* being on nixos might explain crashes or failing to start, but it's hard to imagine how it could be responsible for various gdb frontends not being able to set breakpoints, run to the correct line or render a pointer to an array of bytes, especially when those same features work fine in gdb
* it also doesn't explain why the memory view in most frontends was buggy or didn't work at all
* I also tried lldb, whose gui I couldn't operate at all, and code-lldb, whose breakage might actually be nix-related since I had to patch a binary (but the error message was complaining about invalid utf8...)
I'm also happy to try non-gdb/lldb debuggers if you have any suggestions.
This is perhaps related to using zig, but it's frustrating that gdb itself works fine with zig but each gdb frontend manages to break in different ways.
[email protected]