So excited for this. I talked to the ERSC folks last year about joining but it was a little early for me. Still incredibly excited about what they're building and glad to see one of my favorite people joining the effort.
Pretty cool! While I was at Recurse I took a stab at building a library like webview client mentioned in the post. https://github.com/zephraph/webview. Deno was my first target. I really enjoy deno's tooling overall, it's nice to be able to just import a server script as a URL and limit its permissions.
I'm really bullish on mise as a tool. It's quickly become one of my goto tools when starting a new project. Being able to have one config file to manage tools (node, python, rust, go, etc) as well as a simple makefile replacement makes it incredibly convenient. I pretty much always setup a `postinstall` hook so all someone has to do is `mise install` one of my projects and they'll get all the correct tool versions as well as having dependencies installed (like running `npm install`) automatically.
I feel it's significantly more practical than something like nix which feels like it has a steep learning curve.
Having started with Mise, and now being primarily a Nix user — Mise still has the edge for what it does. It supports pinning exact versions of many more languages than devenv does. When devenv doesn't support pinning the version you need, it's straight back to the pain and complexity of overlays and overrides and so on.
Any hands on experience using it? I’ve looked at both this and devenv but have some level of reluctance to go with an opinionated wrapper like these as I feel like the second you need to do anything outside of the bounds of what they allow you to do you’re back in regular Nix land anyway
I've been using flox for around a year and have been pretty happy with it. It's had a few growing pains, but overall has been very reliable. I adopted it as I wanted something to install up to date development tools on top of my OS (Debian stable) and looked at flox and devenv, I went with flox as it supported zsh, which devenv didn't at the time.
I only have a few CLI/TUI programs installed with it, I try to keep it to a minimum. Just my editor, several language servers, AI tools and some other VM/container tooling. I haven't needed to break out of the happy path with it as of yet. I follow Nix progress with hopes of it eventually maturing into something better to use directly, but given the current state I prefer the wrappers at this point.
I’ve been using devenv for about 6 months now. I’ve started new projects with it and migrated old ones to use it as well. I’ve also set up my org’s repositories with it. Onboarding devs to projects is simple. All everyone needs on their local machine is git, nix, and devenv. Bonus points for using it with direnv for automatic shell activation when you enter a directory. Direnv allows for IDE integrations as well for project dependencies.
Sounds very interesting - I've been using just & docker (-compose) to manage my monorepo projects after a short frustrating stint with moon&proto. I like the simplicity of just, but onboarding can still be cumbersome, especially across platforms.
yes! I set up a new project with mise. It makes it so much easier for new people to get started without having to do a bunch of manual steps. Awesome tool.
Hey, yeah, this is a fun idea. I built a little toy llm-tdd loop as a Saturday morning side project a little while back: https://github.com/zephraph/llm-tdd.
This doesn't actually work out that well in practice though because the implementations the llm tended to generate were highly specific to pass the tests. There were several times it would cheat and just return hard coded strings that matched the expects of the tests. I'm sure better prompt engineering could help, but it was a fairly funny outcome.
Something I've found more valuable is generating the tests themselves. Obviously you don't wholesale rely on what's generated. Tests can have a certain activation energy just to figure out how to set up correctly (especially if you're in a new project). Having an LLM take a first pass at it and then ensuring it's well structured and testing important codepaths instead of implementation details makes it a lot faster to write tests.
This is awesome! I built a similar tool as an experiment while at Recurse: https://github.com/zephraph/webview. Didn’t really do any heavy lifting though, just reused some of Tauri’s crates. Does Bun run on the same process as the GUI binding? OSX steals the main thread when rendering a native window which made me lean towards separating the processes. Still wonder if there’s a better way.
I’m using bun for the main process. Bun runs a zig binary which can call objc/c methods. So the “main native application thread” is technically the zig process.
Then there’s all kinds of fancy rpc between bun and zig and between bun and browser contexts.
The calendar is available in the sidebar (on desktop) which I tend to use quite often. On mobile if you swipe down it should hide the keyboard and you can switch to the calendar while keeping your draft open on the email tab.
I generally agree that the workflow could be improved though.
I've been wondering the same! Haven't really had the time to dig into stable content addressing (and I assume the loose semantics of something like JavaScript would make that exceedingly hard).
Maybe? At the AST level, it can might be complicated I guess, but not really. At runtime JIT though… yeah sure. The various expressions of the same AST are bountiful.
But I would love to run an analysis on every npm module published, and find the same AST subexpressions, functions, etc. Do the same thing: remove the identifiers and hash the AST parts. Even go back and see how people named the same function in different ways!
I chatted with Eric on my podcast recently. It’s essentially just a special prompting syntax. The thing I found surprising is that it’s quite good at making chatbot like command interfaces. Hallucinations are still a problem but it still does a surprisingly good job of storing state between commands.
I watched the interview and think I get what's going on. In essence, he's been exploring prompt engineering since before it was cool, starting back in 2020. He and others have discovered some of the 'rough edges' of LLMs and have figured out a way to sand them down via prompting. Additionally, they've discovered ways to maximize their abilities, e.g., inference.
The demos are impressive. I'm excited to give it a try, as I have a lot of ideas for personal software tools where I'm the only customer, but not enough time or skill to build them myself.
Steve, if you come to NYC hit me up!