You might find https://blog.jez.io/history-of-sorbet-syntax/ interesting, written by one of the primary contributors to Sorbet.

Sorbet is a bit different from TypeScript because it has runtime type checking, not just static.

If I remember correctly, the namespaces feature (now released as Ruby::Box) had some pretty severe performance penalties (possibly even for code that doesn't use it?).

Does anyone know if that's been improved?

I work in a large Sorbet codebase (though it isn't a Rails one) and it's a huge boon IMO. The number of tests we don't need to write because of Sorbet is really nice.

It does occasionally require structuring your code differently, but I find the type-system-encouraged approach often gives a more elegant and harder-to-misuse interface in the end.

You work in a large Ruby codebase that _isn't_ Rails?! Are you hiring??

I was assuming Stripe, but would love to hear of others!

Very curious to hear about the specific cases where types make tests unnecessary.

I spend my working life swapping between Ruby and typescript projects and the typescript project is utter garbage with poor test coverage that needs a day of human QA for every build whereas the Ruby project is well tested such that we know that CI passing means it’s good to be released.

Types don't make testing in general unnecessary, but it removes a class of error handling that runtime type checking handles for you. You can really trust the types when using Sorbet.

(I also work in a 40m+ loc non-rails ruby codebase that is almost entirely typed with Sorbet.)

Haha “tell me you work at Stripe without telling me you work at Stripe”

I think so: it looks like "UniFi Teleport" is also based on Wireguard.

You can also do this with a travel router like one of GL.iNet's and Tailscale subnet routers.

UniFi teleport is also very buggy with frequent disconnects. Tailscale and WireGuard proper don’t have those issues for me.

It's a bit surprising they did that, to be honest. I work at a similarly-sized, HN-popular tech company and our security team is very strict about less-trusted (third party!!) code running on another domain, or a subdomain at the very least, with strict CSP and similar.

But in the age of AI, it seems like chasing the popular thing takes precedence to good practices.

Jenkins Groovy is awful and full of footguns. Have you ever run into a serialization exception?

It's too powerful and there are too many of its implementation details exposed to the user.

I haven't seen a serialization exception, but I have run into plenty of footguns with YAML (ref GitHub Actions).

The DSL semantics can be weird with when things like params/env expansions in options block are evaluated.

This thread is largely commentary on the technical aspects of GitHub Actions.

The fact the business gives away free compute is irrelevant and more a discussion of their marketing budget.

Three people could be a group of friends. More than 100 is clearly different.

Given that there are usually _zero_ people rallying in Lansing, this is notable enough for the local newspaper.

What I don't really understand is why they've tied the reader app so tightly to the entire custom OS. It seems like it used to be more standalone, and these days that is essentially impossible?

I've never heard of this, and I'm not seeing much on Google.

What spaces are you in that you see this??

Twitter