thraxil

I'm reasonably comfortable with Rust but especially for smaller projects like the kind of low traffic scratch-my-own-itch web apps where security or correctness weren't terribly important that I was talking about, there's no question it was not as productive as something like Python or Ruby in the pre-LLM world (especially for someone with decades of Django/Rails experience). Now though, I'll use it even for a quick one-off dataviz experiment because the only real "cost" is an extra line or two of prompting to tell it to use Rust and Axum. OK, and compile times, I guess. But on a small codebase even that's not too bad.

Yeah, I've been using Django since 0.97 (almost 20 years) and have made similar switches on my personal apps, converting to Go, Elixir/Phoenix, or Rust/Axum depending on the app and my mood. Performance with Django was "fine" and I never had problems, but it's hard to argue with a 10x reduction in memory usage and latency. If I had to do it myself, the friction of dealing with Rust wouldn't be worth it, but with LLMs, it's not a factor.

"Mirror" mode was my favorite feature on the Koala Pad app back in the 1980s.

> Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved.

I would argue that if flipping a feature flag isn't faster than doing a rollback, your feature flags are not functional. They should be essentially instantaneous and the first thing to reach for as soon as you've identified a problem.

> Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved.

This I totally agree with. Using feature flags well requires some discipline on the team's part to stay on top of them and remove them once they've served their purpose.

The other thing that I think people tend to forget is that there are plenty of situations where N+1 queries just aren't that big a deal. Not every view in every application that every developer builds needs to handle massive amounts of traffic with low latency and high cardinality tables. I've built so many apps where there's one or two users, small amounts of data, etc. And even on apps that do have a lot of traffic, there are often internal/admin/maintenance views that don't have the same requirements and no one will notice an N+1 where N = 5 in the worst possible case.

Every time ORMs get discussed, it seems to be dominated by people who are like "but my app has 5 billion concurrent users doing 2 million requests per second and if there's an extra 5ms on my requests, it will all explode!" and can't comprehend that not everyone is building the same kind of systems all the time. Great, maybe an ORM isn't appropriate for your situation.

As someone who's used Django since 0.97 and loves it, Content Types are one of those features that I recommend avoiding. It looks amazing at first but you will eventually regret it.

> Having that in mind, the next project was entirely in Pylons. All was good, until we were asked to add Unicode support.

How long ago was this? I feel like unicode has kind of been a solved problem in Python since python3 came out. In the python2 days it was, indeed, miserable.

You realize he's not a native English speaker, right? His English grammar is better than my Italian, so I don't feel the need to criticize.

Not every application uses LLMs the same way. For some use-cases, price per 1M tokens is absolutely meaningful. Eg, we do a lot of pretty basic classification/entity-extraction/summarization type work on large inputs (100k tokens per request being very common). It's pretty easy stuff; Gemini 2.0 Flash was perfectly adequate, quite fast, and cost $0.10 per 1M tokens (and even less when we could make use of the batch API). Every newer more powerful model obviously can handle the same work but costs significantly more. When we're deciding what model to use, price per 1M tokens is definitely a meaningful metric.

Inrupt, TBL's company, is doing SOLID for enterprise customers.

Interesting to read the comments and see the reaction here.

I didn't use Fable (just Opus and Gemini) but I recently ported the `djlint` Python library to Rust, also relying heavily on LLMs (but not trying to one-shot it). `djlint` is a library to lint and reformat HTML and Django template files (and some other formats but I haven't tackled them yet as I don't really have any need). It's currently unmaintained (for a couple years at least) but was part of our CI/CD and the reformat in particular is very slow on a large codebase with thousands of templates. For our code, it took about 4 minutes to run. I generated a Rust port in a similar way, aiming for byte-for-byte output compatability. The Rust version runs on the same code in a fraction of a second; fast enough to put in a pre-commit hook. Some of that was the raw Python->Rust conversion, but a lot was some optimization work that I did afterwards. The Python version was heavily regexp-based, basically running a big slow regexp for every rule that it implements, sometimes running the regexp in a loop starting with each tag it encounters as it goes through each file. For the Rust version, I switched it to properly tokenize the files and then match rules on the AST in a single (or relatively few in some cases) pass. Honestly, there's still a lot of low hanging fruit to make it faster but it's already such a big improvement that I'm pretty happy with it. I'm sure those optimizations could've been done in Python but if I'm the one maintaining the code now, I'd much rather deal with Rust than Python with or without LLM assistance.

I took his Introduction to Cryptography class when he was a visiting professor at Columbia. Absolute master of an old-school chalkboard lecturer. They don't make them like that any more.

Yeah. Back when Gemma2 came out we benchmarked it and were looking at open models. For our use case though, while the tasks are pretty simple, we do need a pretty large context window and Gemini had a big lead there over the open models for quite a while. I'll probably be evaluating the current batch of open models in the near future though.

Thanks. Yeah, for now we're moving to 3.1 flash lite as that's the new cheapest at $.25/1M and is also still "good enough". 2.5 flash is more expensive at $.30/1M (looks like Deep Infra charges the same as GCP/VertexAI for it). I might check them out for Gemma though. We benchmarked Gemma2 when that came out and it wasn't remotely usable for us largely because the context window was way too small. It looks like 3 or 4 might be worth evaluating though.