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.

Have you looked at the W3C's SOLID standard? I haven't looked deeply into what you're doing, but it sounds like a less interoperable version of what SOLID already does. https://solidproject.org/TR/protocol

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.

No. Right now I'm upset that Google has removed (or at least is in the process of removing) the Gemini 2.0 flash model. We use it for some pretty basic functionality because it's cheap and fast and honestly good enough for what we use it for in that part of our app. We're being forced to "upgrade" to models that are at least 2.5 times as expensive, are slower and, while I'm sure they're better for complex tasks, don't do measurably better than 2.0 flash for what we need. Yay. We've stuck with the GCP/Gemini ecosystem up until now, but this is kind of forcing us to consider other LLM providers.

Last time I went through SOC 2 we talked to our auditor about this. His view was that there are and basically always have been auditors/companies that will sign off on anything without verifying it if you're paying them. The rest of the industry knows who they are though. If you are taking things seriously and hire an auditor who does, that's one of the things that they look at when you're reviewing the reports from the services/subprocessors that you use. Ie, you can get a SOC 2 that doesn't mean anything but then any of your customers who know/care will flag it and it won't be worth anything.

Shameless self-promotion, but my own post on Ratchets from a few years back: https://thraxil.org/users/anders/posts/2022/11/26/Ratchet/ Similar basic idea, slightly different take.

Leonard Susskind's "The Theoretical Minimum" series is a great start. His corresponding Stanford lectures are on youtube as well and are a nice supplement.

Working heavily in Python for the last 20 years, it absolutely was a big deal. `pip install` has been a significant percentage of the deploy time on pretty much every app I've ever deployed and I've spent countless hours setting up various caching techniques trying to speed it up.

Nope. Out of the box GCP Cloud SQL instance.

Yep. We have tables that use UUIDv4 that have 60M+ rows and don't have any performance problems with them. Would some queries be faster using something else? Probably, but again, for us it's not close to being a bottleneck. If it becomes a problem at 600M or 6B rows, we'll deal with it then. We'll probably switch to UUIDv7 at some point, but it's not a priority and we'll do some tests on our data first. Does my experience mean you should use UUIDv4? No. Understand your own system and evaluate how the tradeoffs apply to you.

I switched from EE to CS (well, "Computer Engineering" technically) in the late 90s. Not specifically due to Smith charts, but that's relatable. For me it was just realizing that I was procrastinating on doing my EE problem sets, which just started to seem like endless grinding of differential equations, by playing around with whatever we were doing in the couple CS classes I had. I wouldn't say I've made "a large fortune" in software, but it's kept me gainfully employed for a few decades so I think it worked out.

Obviously nothing solid to back this up, but I kind of feel like I was seeing emojis all over github READMEs on JS projects for quite a while before AI picked it up. I feel like it may have been something that bled over from Twitch streaming communities.

Erlang/Elixir supervision trees also rely on process linking, which is implemented in BEAM and doesn't have a real equivalent in most other language runtimes (modulo some attempts at copying it like Akka, Proto.Actor, etc, but it's fairly uncommon).

Yeah, I switched from XMonad (which I used for over a decade) to Sway a few years back. Spent some time trying to duplicate the XMonad behaviour but eventually just realized that spending a few hours getting used to the Sway approach and slightly changing my workflow was a lot easier.

The description of the "meta framework":

  * Thesis/Starting Argument  
  * Counter-Argument (paper requirement from Naval War College)  
  * Rebuttal (different perspective, not your starting argument)

Sounds like someone discovering a variation on the thesis-antithesis-synthesis dialectical method from philosophy for the first time: https://en.wikipedia.org/wiki/Dialectic

Paine is likely well versed in the philosophy and knows exactly what she's doing. Pointing this out in case anyone wants to go deeper on this kind of approach. Much ink has been spilled over the years on different approaches, criticisms, etc.

I've always just gone to the youtube channel page, view source, search for "rss", copy the URL and paste it into my feed reader. It would be great if it was more discoverable, but it's not really like you need a whole separate tool.

You can write a parser and type checker for pretty much any language in pretty much any language. It's just text files as input and text as output.

Like a globe?