xavdid

It depends! It's more about growing complexity than LoC. Like if I'm pulling more and more functionality out of cyclopts[0] for arg parsing. Each time I have to go to the docs instead of getting in-editor suggestions it's a little bit more annoying. The earlier I swap over, the nicer it is.

[0]: https://cyclopts.readthedocs.io/en/stable/

Ah, this is great! It's a step towards solving my biggest complaint with PEP 723 scripts: bad editor support.

I loved the idea on paper, but without manually creating a matching venv & installing my deps, I wouldn't get in-editor completions during development. That was fine for small things, but intolerable as the script grew. So it's still not a feature I've used much, since it made more sense to just make a real dev environment.

I'm glad to see there'll be improvements here!

Off topic, but TIL that .foundation is a TLD!

I got hit with a cryptominer on my mac mini the other day. I only noticed because I happened to sitting in the room with it and noticed the fans were working overtime. There was a process, "icloud-services", which was using 100% of the CPU. It's sort of an indictment of Apple that my first inclination was "they've got a bug that's got an infinite loop" instead of "this is malicious software".

After a reboot, I traced it back to a folder in `Library/Application Support` which included a `config.json` that mentioned gulf[.]moneroocean[.]stream, so I knew I'd been popped. Cleanup was easy enough (the files themselves, plus the launch daemon), but it's annoying.

I don't do dev work on that machine (it's really just for plex & stuff) so it must have been some sort of vulnerability in Plex (but not the one described in OP) or macOS itself. Interestingly, I was up to date on my Plex install, but my macOS version was behind what was apparently an important security update related to an RCE (Sequoia 15.8).

If you ever find yourself in southern Louisiana, the Tabasco factory on Avery Island is worth the visit! You can see the factory floor, try as many variants of the sauce as you want, and learn a ton about the history of the company.

It's also a beautiful property complete with a ecologically important bird sanctuary. Just a fascinating day!

Discord learned this back in 2020 and published a great blog post on it: https://discord.com/blog/why-discord-is-switching-from-go-to...

It doesn't mention the most annoying tell- content that fades in as you scroll down a page. I'm seeing this everywhere recently and it's so distracting

Depends how much you want to automate, but all you really need is a VPN (or so I am told). There are some good docker containers that bundle the VPN, Transmission, and a dead-man's switch for the connection (allegedly)

Yeah I feel like this is the nuance that gets lost.

I hate ads, but mentioning other first party services feels very different than selling parts of the system UI like a billboard.

These service upsells should be dismissible but they seem fairly inoffensive. The App Store ads, on the other hand, are just atrocious

Right, your hobby is either 3D printing or maintaining a 3D printer, but not both

I traded a Prusa MK3S for a secondhand Bambu P1S and it was night and day. I believe the prusa could have gotten to a place where it printed well and consistently, but the P1S *just works*. It printed better out of the gate with 0 tinkering than the Prusa did after I had spent hours calibrating, testing, and re-calibrating it.

I wanted the Prusa to be just as good, which is why I started with it. I wanted to support the open ecosystem, but not at the expense of not getting to do what I actually set out to (print things nicely). It's a shame! Maybe I was holding it wrong (but again, with the Bambu, I didn't have to worry about it).

I would not personally sign onto (or put money) behind a DHH-run project because of his frankly abhorrent political views:

- https://po-ru.com/2026/07/29/it-doesnt-matter-whether-matz-i...

- https://blogs.gnome.org/alatiera/2025/11/06/dhh-and-omarchy-...

That makes sense as a personal preference for him, but it's odd for that to still be the company/project stance. Like, surely he knows he's the minority for not wanting highlighting?

I love these release notes but I really wish they would add syntax highlighting to the Go blog. I'm always a little bit surprised/disappointed whenever I land on a go.dev link since I know the code will be just a little harder to visually parse than it needs to be.

There's also different building pressures. Before, companies would want to build / power / maintain the smallest amount of data center hardware they could while still serving their needs. Overprovisioning just meant worse opex number.

Now, because supply is so constrained relative to demand, there's no limit. More is always better, which leads to a crazy amount of construction (as its negative effects).

Even using staticcheck directly is slow. Just very surprising- do all other Go writers not use a 3rd party linter (and just use `go vet`)?

> Linting is really good as well.

Maybe we are using different tools (or we've set it up wrong) but I'm consistently surprised at how slow Go's linting is (using golangci-lint). Takes nearly 5 minutes on our codebase after any change (which means I just don't run it locally or in-editor). It's remarkable how poor the experience is after using tools like Python's Ruff (instant) or Rust's Clippy. I'd have expected a fast, default setup that I could tune.

Event JS's Eslint, which runs in actual JS, takes 21 seconds for a full sweep (which I don't normally run, since the in-editor hints are so fast)

It's surprising, because so many of Go's dev tools are so well thought out!

Bummer. Airtable's a killer product and I've been using and evangelizing it for nearly 10 years at this point. Built whole side projects around it (and its API), plus organized a ton of personal information. I've made some custom integrations too which have just kept working without maintenance for years. I've got fairly regular backups of all my data, but still. Hurts my heart a little.

Best case scenario it keeps working without totally jacking up the prices. But also starting to think about long-term alternatives. BaseRow seems reasonable, as does spinning all of my many bases into a single big Django monolith (something I've had in the back of my head for while anyway). But it's been nice not having to micro manage this service. Pretty good mobile app, too. Enjoyed it while it lasted, I guess!

Unfortunately it's a hard requirement. Apologies- you sound great on paper!

Stripe | Hybrid (50% of time in Toronto office) | Senior Go developer

We're looking for a senior-level Go developer who can design and ship idiomatic code our users love to work with. We can all write Go that compiles, but don't always know what best practices for 3rd party code are (in the Go ecosystem specifically). Ideal candidates are a part of the Go community / ecosystem and know what the current best practices are. They also probably have TypeScript experience (most of our tooling is TS) and in a perfect world, Ruby/PHP ecosystem knowledge (the other languages we're currently seeking expertise in). But, if we get a Go expert who's willing to learn a bunch of TypeScript, that probably works!

JD and application: https://stripe.com/careers/listing/backend-engineer-develope...

The best way to apply is to go through the form on the site. Happy to answer questions here though! It's a fairly unique role.

> People will claim real harms but the connections are spotty at best.

This is a wild claim because it's trivially provable. There's been tons of reporting around the effect they have on the immediate vicinity, and that's without even getting into the unknown long-term effects.

Here's a decent piece, but there's plenty more out there if you look at all: https://www.youtube.com/watch?v=t-8TDOFqkQA

Is every single mad person doing investigative reporting and / or living next to a data center? No. But something doesn't have to personally affect me to know it's harmful.

There's a sign next to a bridge that says "Weight Limit: 10 tons". Calvin asks how they know the limit and his dad says they build the bridge, then drive progressively heavier trucks across it until it falls down. Then they rebuild it exactly how it was and put up the sign for the how heavy the last truck was.

One of my favorites!

https://www.reddit.com/r/calvinandhobbes/comments/u3dqja/how...

If my cloud provider brings my startup down, it's my problem. If they bring all the startups down, that's their problem.

Stripe publishes a very similar doc: https://support.stripe.com/questions/stripe-shares-or-stock-...

Sure, where you draw the line will vary between projects. As long as its exact placement doesn't matter too much.

For me personally, I tend to draw the line at write operations. So in your example, I'd want a dry run to verify the permissions that it can (if I expect those to be a problem). But if that can't easily be done without a write, then maybe it's not worth it. There are also situations where you want a dry run to be really fast, so you forego some checks (allowing for more surprises later). Really just depends.

Yes, but it depends on the context.

For little scripts, I'm not writing unit tests- running it is the test. But I want to be able to iterate without side effects, so it's important that the dry mode be as representative as possible for what'll happen when something is run for real.

I like this pattern a lot, but it's important that the code in the dry path is representative. I've been bitten a few too many times by dry code that just runs `print("would have updated ID: 123")`, but not actually running most of the code in the hot path. Then when I run it for real, some of the prep for the write operation has a bug / error, so my dry run didn't actually reveal much to me.

Put another way: your dry code should do everything up until the point that database writes / API calls / etc actually happen. Don't bail too early

We recently welcomed a new baby and have been discussing whether she'll ever learn to drive. I love bets with long time horizons, so we put together a survey so friends and family could pick a side. We kept thinking of fun questions to ask, so it grew into the survey I've linked above, which we're opening to the public.

It's short, fun, and totally informal. Thanks for looking!

There's a little more context about the project on my blog: https://xavd.id/blog/post/predicting-the-future/

Not all the way down to 4KB, but https://512kb.club/ matches this vibe