I've been experimenting with running Claude in headless mode + a continuous loop to decompile N64 functions and the results have been pretty incredible. (This is despite already using Claude in my decompilation workflow).
One thing I don't annoying in really old sources is that sometimes you can't go function by function, because the code will occasionally just use a random register to pass results. Passing the whole file works better at that point.
This sounds interesting! Do you have some good introduction to N64 decompiliation? Would you recommend using Claude right from the start or rather try to get to know the ins and outs of N64 decomp?
This is super cool! I would be curious to see how Gemini 3 fares… I've found it to be even more effective than Opus 4.5 at technical analysis (in another domain).
I found the contrast with workflow systems such as Cadence/Temporal really interesting. You can tell the author has felt the pain of managing real time distributed state machines.
I recently switched from frontend to a backend/ml role at a large tech company.
At a high level the work is pretty similar. Instead of working with design/product you work with data science/product. The conversations do tend to skew more technical. I remember we talked a lot of about user experience on my old team whereas now it's more about the stability of our services/pipelines and the maths behind the models and features.
One thing I'd call out is that, as an engineer, you're largely responsible for productionising what the data scientists come up with. There can be varying degrees of collaboration on the modelling depending on the team/project but at the end of the day you're there to make the thing work in the real world.
Compared to other engineering jobs, I think the work tends to be more experimental, i.e. can you quickly write code to test an idea.
If you're interested in trying it out, go for it. There's a tendency to silo engineers (backend, web, mobile, etc) but code is code and you can ramp on the concepts in a few months :)
On the other hand, if you're loving frontend there's nothing wrong with staying there. The depth is definitely there but you might need to change teams/companies to keep growing.
Very cool. I suspect running on the main thread with requestAnimationFrame for rendering to the canvas would eliminate some of the performance issues without having to rely on postmessage.
Went through this exact process last week. Did they really need to remove CommonsChunkPlugin? Feels like breaking stuff for a slightly nicer API. If this were React we would've had a deprecation warning for a few versions.
> If this were React we would've had a deprecation warning for a few versions.
If this were React, you would have got docs with a release.
Choosing to release before documentation is done, for a tool developers are supposed to use as a black box, which has a lot of strange configuration that is required, is a really strange choice for something with so many breaking changes.
They have [0][1] ("beta" was dropped from the v4 releases at v4.0.0), and are actually in the process of updating the documentation [2]. It's just odd to do that after a release.
Whoops, guess it's a good idea to check things before blurting something out.
In that case I'm not sure what's best, to let newcomers in on the new goodies of v4 or to avoid confusing previous users.
I hope that others find this similarly useful.
reply