> Hey Claude, write a set of guidelines for how Claude should build Rust web apps. Like Ruby on Rails, you know, but in Rust. Claude doesn't automatically know how to do this so I'm counting on you, Claude, to teach it. Make sure it's opinionated. I don't care what the opinions are, but it's gotta have them.
Edit: oh my God, not only is the framework just markdown files, it has an MCP server for agents to read the markdown files. Ok, I'm convinced it's a parody.
The "web stack" is a bunch of markdown files. It's more of a wish list than a framework.
Also: "No line of the framework was typed by hand."
So it's not even your wish list.
I could prompt Claude "write down best practices for building web apps in rust, then build <my idea> as a web app in rust following those practices." How would that differ?
I can't tell if this is a satire of "markdown engineering" or not. Poe's law in action.
I get what you are saying. If you write a "recognizer" with parser combinators (like a regex without capture groups) and then want to convert that recognizer to an actual AST parser, you have to change it more deeply than just choosing what pieces to capture. You have to carefully follow a trail of left/right capture/discards to figure out what actually ends up in a function input. It's tree-shaped not linear-list-of-captures.
Some parser combinator environments are better than others. Haskell's applicative style is pretty good:
(\x y z -> ...) <$> parser1 <*> parser2 <*> parser3
F#'s FParsec has pairwise operators `.>>`, `>>.`, and `.>>.` for capture-left-ignore-right, capture-right-ignore-left, and capture-both-and-tuple. These rapidly get unwieldy:
Still, what a pain when you mix in some "ignored" parts in between the "captured" parts. Ugly and awkward to follow.
pipe3 (whitespace >>. parser1) (char '(' >>. parser2 .>> char ')') (whitespace >>. parser3 .>> whitespace) (fun x y z -> ...)
I wrote a library some years ago to alleviate my issues with that F# flavor of this problem. My solution is very similar to yours in that it also asks the user to think of it as like regex "capture groups"!
My approach is more symbolic-operator flavored than yours though. In mine you always start a chain of parsers with `%%`, separate with `--` and end with `-|> function`.
If you want to capture any part of the chain you use the unary prefix operator `+.` to mark it captured and it will get passed through to the consuming function.
"Rent-Seeking" is trying to capture eternally recurring payment for something you did or acquired one time.
Mathematicians acquired their skills over long hours of study, but weren't asking to be paid just to sit around passively being smart, but to keep working on new results. It is the lost opportunity to do work they are lamenting, not the lost opportunity to sit on their laurels. So no, it doesn't sound like rent-seeking.
> It sucks if you’re a rent seeker, but I’m enjoying this post-IP world
Oh yes, this new world is terrible for rent seekers. It's like the kum-bah-yah free software world Stallman might have imagined. Information wants to be free and all. Can't stop the signal. Very counterculture. Like the Adobe clone apps.
Except for the closed SOTA model weights, out of reach hardware, and the resulting $200 subscription rent now paid readily both by anybody trying to create something new, and anybody who wants to rip it off. That particular flavor of rent seeking is booming.
I myself am a "rent-seeker" in an alternative sense of "I seek a way to pay for my own continued shelter via my creative output" and it definitely seems like it's gonna suck for me.
> Except for the closed SOTA model weights, out of reach hardware, and the resulting $200 subscription rent now paid readily both by anybody trying to create something new, and anybody who wants to rip it off. That particular flavor of rent seeking is booming.
SOTA only provides agents that are easier to manage. Such agents will likely also be made available in open models, as it is primarily a post-training issue.
Even if it never comes, the best open models are already capable of performing these tasks.
Yep. Current open weight models that you can run on prosumer hardware are on par if not better than Opus 4.6. And Opus 4.6 was deemed revolutionary in terms of performance.
The sensitivity of my bank password is much lower than a seed phrase because most bank transactions can be reversed as long as I notice them in time and prove my identity to my bank.
With bitcoin nothing is reversible so every step of the process is a huge security risk where you can fall off a cliff and experience financial permadeath of "your" crypto, assuming a sufficiently motivated attacker.
Thanks for your work on Solvespace. I have been using it for years. When I no longer had access to commercial CAD programs I tried all the open source stuff. My conclusions were:
* OpenSCAD -- cool idea, good for a few types of highly procedural parts, but most of the time I'd rather a parametric sketch-based interface over pure code.
* FreeCAD -- the most features of any open source CAD, but poor UI, tendency to crash, and the advanced features like loft kind of fall flat compared to commercial equivalents. You think you'll be able to model a part, but it becomes extremely frustrating if you actually need the advanced tools.
* SolveSpace -- pretty stable and reliable. Fast, compact, great sketching interface, good discoverable UI. You can predict what types of parts you can model with it and what types you can't. Doesn't try to do everything but is good at what it does.
You can tell which one is my favorite! N features done to a good level of polish and with somebody making sure it all "makes sense together" beats 10xN features all 80% done and haphazardly mashed together in different menus/workbenches, for any tools I want to rely on.
I am noodling around with a slopcoded CAD tool of my own these days, just out of curiosity to see how far Opus5.5/GPT6 can get doing it in F# and to experiment with some workflow concepts that match the way I like to design parts. But like you said, progress is slow. For stuff I actually want to get done, SolveSpace remains my go-to, and I greatly admire its coherent design.
He did certain things, like went to a certain college, got married and had kids at particular ages, went to a certain type of grad school, took and quit certain jobs at certain times. I went through and asked, of each observation, the Bayesian question of whether the probability of that observation differed in the worlds where the hypothesis was true and false. In all 12 of my cases, where I was doing it by hand in an Excel spreadsheet using Bayes' Theorem in its probability form, I judged the observation was more likely in the world where he was indeed avoiding the Vietnam draft.
I started over with Gemini with the prompt "can you evaluate the final odds for a hypothesis, given a number of observations that could be evidence for or against that hypothesis". It first laid out Bayes' Theorem in its odds form, and then asked me to lay out the hypothesis and set of observations.
I did so, with it leading me through asking for three or four observations at a time. Gemini came up with its own assessment of the odds for each one, justifying the odds it gave based on historical background context like draft rules around going to college; worked up the running odds as it went; and provided a narrative interpretation.
Gemini's final tally of observations was 10 in favor, 2 neutral, and 2 against, where my own by-hand analysis in a spreadsheet had come out 12-0 in favor (Gemini came up with a couple more things like inquiring about his 1969 draft lottery number). The individual odds we came up with independently were largely quite comparable. Gemini's final aggregated odds were 124,000-to-1 in favor where my spreadsheet analysis had 4600-to-1. Its final narrative assessment was that the history I described appeared to be a classic case of "draft hedge."
I'd love to take a principled stance on this because I do consider code an art or at least a craft and I appreciate a program written in a unique and clever way. In retrospect, SO MANY of my personal projects[0][1][2][3] over the years were DSLs that affected how you write something and how pretty or type-safe the code ends up being. They are libraries that can only be appreciated by another programmer, they mean nothing to an end user. It appears that whole genre of library will mean nothing to anybody in a few years. Shoulder of Orion, Tannhauser Gate, etc. etc.
Yet, it's utterly hopeless to try to take the same stance visual artists are nobly holding. Of the programs I use daily, how many have I ever even glanced at the source code? I could count them on my fingers. And I'm in the target audience: a programmer, enthusiastic about the trade, one who has contributed to open source...
Conclusion: within a rounding error of NOBODY cares about the code. Of the weavers who were displaced by the automated looms, or the furniture-makers displaced by mass produced pressboard, some of the most skilled could still ply their trade for the rich who wanted to flex their bespoke handmade goods. Programmers writing code by hand will not even have that luxury market. It makes me depressed but I don't see any way around it.
My hope is that I can use my knowledge, willingness to spend long hours fighting with a computer, and industry experience to at least make better software with agents than the average vibecoder. I sadly don't think I'll get anywhere trying to play John Henry vs. the Steam Drill, trying to beat it with my hand-typed code. Maybe somebody who's 10x the dev I am can do that, and Godspeed to them, but I thought I was pretty decent and I don't have a chance.
Hell, it's not even possible to prove any code was written by hand, other than by having uploaded it pre-2024ish. For this reason I really feel bad for those coming up right now, who have the same enthusiasm and fascination for Real Programming that I did, but no way to prove themselves and no motivation to in a world that values that skill less all the time.
This particular project is so low effort I'm leaning towards it being parody.
See: https://rustoffrails.org/how-it-was-built
> Hey Claude, write a set of guidelines for how Claude should build Rust web apps. Like Ruby on Rails, you know, but in Rust. Claude doesn't automatically know how to do this so I'm counting on you, Claude, to teach it. Make sure it's opinionated. I don't care what the opinions are, but it's gotta have them.
Edit: oh my God, not only is the framework just markdown files, it has an MCP server for agents to read the markdown files. Ok, I'm convinced it's a parody.
reply