xavdid

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

This was originated (or at least popularized) in an episode of Archer from season 1. It remains maybe my favorite 5 minutes of comedy ever out to screen. It's just so tight!

https://youtube.com/watch?v=dNYMQpcqscA

Ah, these are great! f-strings are so powerful, but I can never remember the arcane little syntax. Definitely bookmarking this.

that's fascinating - I've definitely been saying "you've" and "tie". I assumed this was "picks"

If you're interested in some (light) science behind rivalry and/or the Michigan/OSU rivalry, I highly recommend the documentary "Rivals: Ohio State vs. Michigan". It's a fun look into why a rivalry drives better performance.

https://www.imdb.com/title/tt22937658/

I don't remember if it links to it, but this pairs well with https://cryptopals.com/, which are practical examples of many of these theories.

I found this to be an interesting new direction from Airtable, a product I've really enjoyed. I hope it doesn't muck up the core functionality too much.