The best part of try blocks is the ability to use the ? operator within them. Any block can return a result, but only function blocks (and try blocks) can propagate an Err with the ? operator.
One small boon of AI is that making small interactive web components for demonstrations is now a few-minutes diversion instead of an hour or more. I have no idea if that's what OP did, but I've been happy with generating low-stakes code for blog posts.
The timing of this share is crazy, since I was just looking around a few days ago to see if there were any guides or even kits for doing photolithography at home. It's part of my mission to demystify modern technology for my kids. I couldn't find anything, so this is excellent to see. Far too complex for my kids ages, but it might be cool to replicate at least part of this amazing project when they're older.
The Hacker Fab [1] project at Carnegie Mellon is creating and publishing guides to building simple fab equipment including photolithography and a sputtering system. For somewhat more complex equipment, I appreciate [2] from the founders of InchFab [3].
But maybe the easiest way to do (very low resolution) photolithography at home is to use dry film photoresist, which is like tape you can stick onto a copper PCB you then expose and etch; a cheap roll is ~$20 from eBay/Amazon.
Silk screen printing is probably the easiest way to introduce the concepts to kids. There are a lot of maker spaces/artist collectives and classes that have the basic tools and resources to do it.
It's not lithography, but you can build a working processor out of small surface mount chips, and you can solder these chips with lead-free solder. That seems very achievable for a motivated engineer, and probably involves much less toxic chemicals?
I'm one of the git users you describe who are resistant to jj. jj sounds great, Steve Klabnik's endorsement is very convincing, and I would probably love it, but here's the issue: I've used git for 17 years and have internalized its idiosyncracies sufficiently to practically never run into problems, and help anyone on my team who does.
jj is harder to adopt for people with a thorough mental model of git, because it's harder to accept jj commands at face value. I know it's modifying my git tree, so I feel compelled to grok exactly what it's doing, but that's distracting and time consuming.
People like me should probably trial jj exclusively for two weeks, to shed that antijjotic resistance and form a more clear-headed opinion.
> jj is harder to adopt for people with a thorough mental model of git
No, it really isn’t. I have used git since shortly after it was first released and I’ve written a git implementation.
I switched to jj in one day. And the amount of git arcana I have to keep in working memory is now basically nil. My VCS now works in almost a 1:1 mapping with how my brain wants to interact with my repo rather than having to go through a translation layer.
If you understand what git commands are doing, what jj does is essentially trivial to add to your mental model.
I also get the benefit of being able to use workflows that I always want to use in git but which are an enormous pain in practice. And I get access to wildly powerful new workflows I didn’t even consider because they would be outlandish in git.
What I will say is this: there is certainly an adjustment period, and I also totally hear you about how learning internals can be time consuming.
I think you can get a lot of the way there with at least the core concept with something like this, if you'll indulge me:
With git, you build up stuff on your filesystem. You then select which bits go into a diff in your index, and then when you're done, you stamp out a commit.
With jj, you instead start by creating a commit. In this case, it's empty. Then, every time you run a jj command, it does a snapshot, and this produces a new commit. However, because we want to have a stable identifier for a commit, we introduce a new one: the change id. This is basically an alias for the latest commit snapshot that was made. Your git history is just made up of each of these latest commits for each change.
... does that make any sense? Obviously there's more to all of the features than this, but that's sort of the core way that the histories map to each other.
I'm sure there's a proper name for what you described, but I call it Rip van Winkle syndrome. He helps everyone in the town with their needs, while allowing his own property to fall to ruin.
reply