why-el

Because of your multiple "I am tired of saying this, but this text was written by me and not an LLM" in your blog posts, I want to tell you that I read it word for word. :D I know this comment adds not much but I felt it needed to be said.

So far a Rust rewrite's success rate directly, probably super linearly, correlates with the presence of a good, well designed test suite. This is why Bun's rewrite and others are successful. I anticipate that this will be true for the 37Signals rewrites.

I want to learn a couple of things once they are done:

1. Once the test suite assistance is over, how do features get built in their backends and continue to maintain the same quality. LLM test writing is a bit trickier as it often favors what Randy Coulman called tautological tests back in the day. It takes a lot of work to get them not to do this, so I am guessing folks at 37Signals will read at least this part. I can't imagine zero Rust read at all.

2. Over the years they had a few innovations in their domain design, ones that Rails made easier to do, for instance their delegated type pattern. Will Rust replicate this, and how would one know without reading it, or perhaps it does not matter? Furthermore, how do newer patterns emerge? and how does our arsenal of better abstractions keep growing?

I don't have the answers but I am glad there is a chance we can learn said answers.

> a register is a mechanical device to power and maintain,

surely a million times less expensive than a subscription to a POS....this is not a strong argument.

I would assume they actually moved off of litestream here no? otherwise how can their frequent manual checkpointing even succeed when litestream locks for the same behavior.

For sure. The literal first two pages of any book, essentially the back of the cover and the title page, always host a huge list of pages plus summary of something interesting i saw in the book. For instance, it will say something like:

* p85, interesting semaphore usage

or some such. This also condenses the books to important things so I can do a speed read to recall the most important parts.

For Oauth I'd like to borrow what I would describe humbly as a better analogy, and it comes from Douglas Crockford, and so adapting it from him commenting on Monads in Functional Programming, it goes something like this:

"OAuth is a simple idea, but with a curse: once you understand it, you lose the ability to explain it."

Chomsky never argued it was words (and how couldn't it be words, for there are millions of words from 100s of 1000s of languages), just a configuration to eventually learn those words.

I am not sure if this will help you, but have an extended, deep conversation with ChatGPT about your resume. Tell it who you are, what you excel at, and list projects and technologies. Then, paste a couple of the job postings that did not work for you.

This might sound silly to you, but it absolutely works, because it will distill your experience better, ask you to re-arrange and generalize, and more importantly, it is far superior to us in finding unique key word combinations that work.

the user who wants it? and a premature retort: if the feedback is "the user / PM / stakeholder could be wrong", then... that's where we are. A "refiner" LLM can be fronted (Replit is playing with this for instance).

To be clear: this is not something I do currently, but my point is that one needs to detach from how _we_ engineers do this for a more accurate evaluation of whether these things truly do not work.

I am not so sure. Code by one LLM can be reviewed by another. Puppeteer like solutions will exist pretty soon. "Given this change, can you confirm this spec".

Even better, this can carry on for a few iterations. And both LLMs can be:

1. Budgeted ("don't exceed X amount")

2. Improved (another LLM can improve their prompts)

and so on. I think we are fixating on how _we_ do things, not how this new world will do their _own_ thing. That to me is the real danger.

> "ask you"

I get the concern, however. But, short of nuking the actual .git directory, the upsides are worth it, in my opinion. Cursor offers filtering via a mini-prompt in its YOLO mode, so does Windsurf. The idea is killer, it allows it to progressively build and also correct its own errors. e.g. Cursorrules can be told to run tests after a feature is generated, or typecheck, or some other automated feedback-loop your codebase offers. That's pretty neat!

Better yet, setup a dev container first. Then, at most, your local DB is the only concern. If still paranoid (as you should be), suspend your network while the agent is working. :D

I was hoping the LLM is the staff engineer? can read both ways.

your incident lingo will be fun.

not to be confused with "Drunk Magnus", a very strong player.

Love it.

> this post is only about buffering that happens inside the program, your operating system’s TTY driver also does a little bit of buffering sometimes

and if the TTY is remote, so do the network switches! it's buffering all the way down.

I learned the following:

- Everything public in Slack. Create a fun-sounding moto that discourages DMs. Even if a DM happens, and the back and forth resulted in a consensus, share that consensus in a public channel (which makes it searchable).

- Record your team meetings, preferably with software that can AI-summarize. Folks on vacation / leave can get the rundown easily.

- Encourage the sharing of solutions to various problems (technical or otherwise) in Slack. If a developer is stuck, and someone helped them in a huddle or a pairing app, share the solution afterwards (again, makes it searchable). Discourage the over-sharing of screenshots (of your application and other things). Again, not searchable. If one must be shared, describe it. For instance, many devs share a picture of a stack-trace. Not super helpful for others. Grab the text and dump it to Slack.

- Have a good pairing software setup, unblocks for when Slack back and forth is too tedious. I like Tuple (tuple.app).

- Connect your issue tracker to Slack, if you use one, makes creating issues easy. Linear does this well.

- If feasible, have your team meet in person, cadence up to you, but at least once. Meeting the people in real life humanizes them more. I know it sounds silly to say, but it's very true in my experience. Your people will seem even lovelier.

I like this analogy a lot. It's possible that forced externalization of thoughts accidentally causes the omission of crucial data. That is, much more goes on in your head, you probably laid out the whole algorithm, but being asked to state it on the spot and in clear, serial words is causing you to bork it by taking shortcuts.

Hm, I thought Happy Eyeballs (HE) was mainly concerned with IPv6 issues and falling back to IPV4. I didn't think it was this RFC in which finally some words were said about round-robin specifically, but it looks like it was (from this article).

Is it true then that before HE, most round-robin implementations simply cycled and no one considered latency? That's a very surprising finding.

To be inspired by something really has no bearing on how the _inspired_ thing is built. I think you place much emphasis on that but really it does not bring much to the argument. One can say that a plane was inspired by a bird (and it is, since we wouldn't to build one if we didn't see birds flying), but a plane is not designed like a bird.

I also somewhat contest that "interesting behavior comes from the emergent runtime interaction of tons of tiny components". There can be very tight, hierarchical structures to programs designed in the way Alan Kay talks about. He is promoting clear, manageable interactions, not emergent unpredictability, which is something I am sure you came across (we all did), but I would not go so far as describe the whole model of Kay as "fundamentally misguided". He talks of "clear fences", which can be understood to refer to things like "actor-based" models, with controlled, clear messages, as done in languages such as Erlang.

also covered by the great philosopher Bertrand Russell: https://harpers.org/archive/1932/10/in-praise-of-idleness/.

I am confused by this comment:

> open source stuff with long history of maintenance and improvement

improvement and maintenance is continent on usage, and having been used at Netflix, this project is in a better place to have already faced whatever bug you are worried about (and let's be real, 99% of applications wont ever get the luck to exercise code paths sophisticated enough to find bugs Netflix has not found already).

You might be unnecessarily projecting here. You don't have evidence to support that open sourcing this might have been for any other reason than it is simply good for the community to have.

The same reason Babbage never built the full Difference Engine. Design of this sort allows some tinkering unbothered by the constraints of actually building it (if you know history of the Difference Engine you know how many ideas it unleashed even if never really built to completion except in recent times for display at a London Museum :p).

newspeak is for dramatic (and dare I say, rather fun) effect. I think his point is straightforward and not confused: one style and one liner for the entire programming language prohibits personal expression of style. A linter to enforce your own personal / team styles is a good idea. I don't see the confusion. You might disagree with one or both, but to me it seems logically consistent with the premise of the article which is that personal style is important in programming.

I didn't mean to say it's all IO, that would be wrong. Rails is feature-rich, ActiveRecord for instance spends plenty of time in the CPU (manipulating its internal state). But the idea that Rails/Ruby is slow is outdated and does not jive with any monitoring and metrics we collected even in extremely busy environments. Of course one would gain some percentage of speed if say your backend is some compiled language, but that would mean possibly slower development cycles, hiring, and so on. Billion dollar companies run Rails, and, crucially, show relentless speed in execution (for instance, Stripe). If anything, Rails has the strongest case yet for performance / feature set.

In my experience most Ruby apps (Rails in particular) develop this idea that Ruby is the bottleneck when in reality most of the time it's something else entirely (mostly DB or network IO). Of course you found compiled languages faster! that's by definition. You also tried Ruby on CPU sensitive code bases ("Advent of Code or Project Euler solutions"), that's textbook "ruby is slower than C". Rails pays dividends in the web and in large code bases with many engineers.

addressed in the FAQ: https://www.interdb.jp/pg/faq.html. Short answer is no.

There is a another famous one, focusing on Postgres: https://www.interdb.jp/pg/.

Not quite I don't think. For a busy database, The Heroku followers will not catch up to your upgraded database as quickly, so during an upgrade using Heroku's physical replication (as opposed to logical), there will be a time period where your freshly upgraded primary is on its own as the followers are being issued and brought up to date.

I've learned only one constant with git in my years as a programmer: master your own employer's git use cases, and pray to god for three things:

1. you don't change places often and thus git patterns.

2. you don't accidentally ship and commit a multi-GB file to your remote.

3. you don't change the git process on yourself and your colleagues without an extremely solid reason.

Document your chosen git patterns, even in 2023.