Boy do I have news for you about the use of landmines in the Ukraine war…

It’s not too hard to actually do the computations. But there is a ton to learn. I installed my own 14.85 kW system last year, with batteries, and I spent hundreds of hours just researching everything. I know I went overkill, but the hardest part of the project was just getting up to speed on all the requirements to meet code.

Someday I’ll write up my entire experience and share my site plan I used for permitting in the hopes it will help someone else. But doing solar right is a nontrivial investment for a newbie (like me).

I personally think the optimization challenge is fun. I like digging in to low level stuff, reviewing the assembly dumps and processor pipeline architectures. I fail or give up most of the time, but I enjoy learning in the process.

I’m just trying to show how Zig fits my tinkering well, since you said you can’t see how Zig would ever be a good fit for tinkering. I’m not saying it’s a good fit for all forms of tinkering.

It's uncommon but I've definitely seen it done (with media containers like Matroska, not actually LEB128) in extremely high-throughput systems that can't spare any cycles.

Most OSS projects simply don’t have that kind of weight or discipline to follow SQLite’s footsteps.

SQLite is in a whole different league when it comes to funding, corporate support, etc. There are commercial contracts directly tied to its ongoing support and development. As far as I understand SQLite is Hwaci’s bread and butter.

Of course there is always the risk it goes out of business like any other company, but it’s not funded like your typical small open source project and doesn’t even allow open contributions (not necessarily a bad thing IMO but it’s just a totally different type of project).

I screwed up jj a few times while picking it up, but jj’s undo command made that trivial to go back and try again. With git? I know a lot of things can be undone but I can never remember how to do it!

You also don't have to follow what the GP said. I never say `jj describe` before writing code. I write the code then just say `jj commit -m "Foo stuff"`, just like I would in git.

The bigger difference I've noticed is:

1. Switching between changesets just feels more natural than git ever did. If I just run `jj` it shows me my tree of commits (think of it like showing you git's branches + their commits), and if I want to edit the code in one of them I just say `jj edit xyz`, or if I want to create a new commit on top of another one and branch it off in a new direction, I just say `jj new xyz`. It took a little bit for my brain to "get" jj and how it works because I was so used to git's branches, but I'm really enjoying the mental model.

2. `jj undo`. This alone is enough to convert me. I screwed something up when trying to sync something and had a bunch of conflicts I really didn't want to resolve and I knew could have been avoided if I did things differently, but my screwup was several operations ago! So I ran `jj undo`. And ran it again. And again. And again. And then I was back to my clean state several stages ago before I screwed up, despite having made several changes and operations since then. With git? Yeah I could have gotten it fixed and gone back. But every time I've had to do something like that in git, I'm only 25% confident I'm doing it right and I'm not screwing things up further.

3. Rebasing. When I would try to sync git to an upstream GitHub repo that used rebasing for PRs, I would always get merge conflicts. This was because I stack my changes on top of each other, but only merge in one at a time. Resyncing means my PR got a new commit hash, even though none of the code changed, and now git couldn't figure out how to merge this new unknown commit with my tree, even though it was the same commit I had locally, just a different hash. With jj? I never get merge conflicts anymore from that.

Overall the developer experience is just more enjoyable for me. I can't say jj's flow is fundamentally and objectively better than git's flow with branches, but personally and subjectively, I like it better.

It generated an implementation that worked well, but I hated the ~480 lines of code. The structure and flow was just... weird. It was hard to follow and I was seriously bugged by it.

So I asked it to reimplement it with some simplifications I gave it. It dutifully executed, producing a result >600 lines long. The flow was simpler and easier to follow, but still seemed excessive for the task at hand.

So I rolled up my sleeves and started deleting code and making changes manually. A little bit later, I had it down to <230 lines with a flow that was extremely easy to read and understand.

So yeah, I can totally see many SWE-bench-passing PRs being functionally correct but still terrible code that I would not accept.

Ummm, what? https://en.wikipedia.org/wiki/Metric_prefix

Little m is milli, big M is mega. Little g doesn’t exist, only big G.

I keep meaning to see if work will let me open source it.

[1]: https://en.wikipedia.org/wiki/Quadruple-precision_floating-p...

I'm not GP but I would at least consider it. I say that as someone who refuses to build on closed-source tooling or libraries. I'd even consider closed-source if there was an irrevocable guarantee that the source would be released in its entirety (with a favorable open source license) if the license/pricing terms ever changed or the company ceased to exist or stopped supporting that product.

> Along with a guarantee that you get to keep access to older versions (Jetbrains and Sublime Text models)?

I like that for personal tools but I wouldn't build my products or business on top of those. I've had too much trouble getting old binaries to work on new OS versions to consider these binaries to be usable in the long term.

But sure, I agree it would help if battery prices came down.

- $3,300: 10 kWh with 2x EG4 WallMount Indoor 100Ah.

- $3,110: 14 kWh with 1x WallMount Indoor 280Ah.

- $2,690: 10 kWh with 1x Deye RW F10.2 B

- Will Prowse's YouTube channel has reviewed several battery builds that are >10 kWh and near $2,000, but they're DIY assembly.