thraxil

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)

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?

The risk isn't that much that your employer gaining access to your email (though you may potentially be risking the contents of emails that you view from that machine getting saved and accessed by someone at the company). It's more that you've legally entangled things. If your employer is sued or investigated, a judge can issue a subpoena for them to turn over records. If those records show that employees accessed external accounts from work systems, now they can get a subpoena to access those accounts and any other devices that have accessed those. I've seen this happen to friends. Employer gets sued and as part of discovery, they had to hand over all of their personal devices because they hadn't kept church and state separate. Took them many months and significant legal expenses to get their stuff back. If you never access personal stuff from your work devices and never access work stuff from your personal devices, you'll never be in that position.

It seems like you've kind of missed both of my points.

If you're doing canary deploys to a fleet of 2000 nodes, it might take hours for the config to make it to all of them (I've seen systems where a fleet upgrade can take a week to make it all the way out). If your feature flags are configured that way, there's a long time that the state of a flag will be in that in-between state. We put feature flags in the database not config/environment so that we can turn a feature on or off more or less atomically. Ie, an admin goes into the management interface, flips a flag from off to on and then every single request that the system serves after that reflects that state. As long as you're using a database that supports transactions, you absolutely can have a clear point in time that delineates before/after that change. Rolling out a config change to a large fleet, you don't get that.

On the second point, what I'm saying is that (talk to your friendly local SRE if you don't believe me), a large percentage of production incidents in large systems are because of configuration changes, not application changes. This is because those things are significantly harder to really test than application code. Eg, if someone sets an environment variable for the production environment like `REDIS_IP=10.0.0.13` how do you know that's the correct IP address in that environment? You can add a ton of linting, you can do reviews, etc, but ultimately, it's a common vector for mistakes and it's one of the hardest areas to completely prevent human error from creating a disaster. One of the best strategies we have is to structure the system so you don't have to make manual environment/config changes that often. If you implement your feature flag system with environment variables/config, you'll be massively increasing the frequency that people are editing and changing that part of the system, which increases the chances of somebody making a typo, forgetting to close a quote, missing a trailing comma in a json file, etc.

Where I work we make production config changes maybe once a week or so and it's done by people who know the infrastructure very well, there's a bunch of linting and validation, and the change is rolled out with a canary system. In contrast, feature flags are in the database and we have a nice, very safe custom UI so folks on the Product and Support teams can manage the flags themselves, turning them on/off for different customers without having to go through an engineer; they might toggle flags a dozen times a day.

I would add two things:

It's often important that flag changes be atomic. Having subsequent requests get different flag values because they got routed to different backend nodes while a change is rolling out could cause some nasty bugs. A big part of the value of feature flags is to help avoid those kind of problems with rolling out config changes; if your flags implementation suffers from the same problem, it's not very useful.

Second, config changes are notorious as the cause of incidents. It's hard to "unit test" config changes to the production environment the same way you can with application code. Having people editing a config every time they want to change a flag setting (we're a tiny company and we change our flags multiple times per day) seems like a recipe for disaster.

If I had to use HTMX for work, then I would've guaranteed used it wrong.

As someone who's been doing web dev since the 90's and is currently leading a project that's built with HTMX and having onboarded a few younger/junior "react devs", you're not wrong. What I've seen is that there's a whole generation now who just don't know how to do things in a different way than by building a SPA. The difficulty onboarding those devs is always in getting them to unlearn the patterns that React/Angular/etc. have ingrained in them. I've reviewed PRs that were a mess of complicated HTMX attributes, backend logic switching on headers, etc. and pointed out that all of it could be replaced by just, like, using a plain old HTML form submit or `<a href="..."`. I wish I were kidding. They almost always start out massively overusing HTMX out of a fear of triggering the dreaded full page reload. But in a non-SPA world, with a fast backend, full page reloads take milliseconds because there aren't MBs of JS to download and execute and a bunch of client-side state to reconstruct.

It's also harder to find HTMX dev's when there's so much React devs

For someone who is familiar with basic web technology (like the 20 year old version with HTTTP/HTML and minimal JS/CSS), it only takes 15 minutes or so to learn HTMX (then maybe a few days of building where you pull up the docs occasionally to remember the names of the attributes). The idea of someone calling themselves an "HTMX dev" the same way we have "React devs" is ridiculous.

The Agile Manifesto is what kicked it all off. Scrum, etc. and all the other "agile" stuff that people complain about now just latched onto the word. The equivalent would be that if Jesus had personally written down his thoughts and we still had a copy floating around, you totally could point to that and say that it's the true, original version and anything else is just an interpretation that should be taken with a grain of salt.

I feel like there's this no true Scotsman thing going on with agile. Whenever someone describes their actual experiences with agile, there's always at least one person who speaks up and decries it as as not real agile and what agile should be.

It's not mysterious or confusing. The original definition is at https://agilemanifesto.org/

Yeah, and I was live migrating entire VMs between hosts on a Xen cluster 10-15 years ago. It was easy for me to get working, reliable, and I was far from an expert.