Not OP, but I think building feature flags yourself really isn’t hard and worth doing. It’s such an important component that I wouldn’t want to depend on a third party

I agree, but it's hard to get the nuances right. It's easy to roll out a feature to half of your user base. It's a bit harder to roll a feature out to half of users who are in a certain region, and have the flag be sticky on them.

We use Unleash at work, which is open source, and it works pretty well.

I generally agree, but see some more nuance. I think feature-flagging is an overloaded term that can mean two things.

First, my philosophy is that long-lived feature branches are bad, and lead to pain and risk once complete and need to be merged.

Instead, prefer to work in small, incremental PRs that are quickly merged to main but dormant in production. This ensures the team is aware of the developing feature and cannot break your in-progress code (e.g. with a large refactor).

This usage of "feature flags" is simple enough that it's fine and maybe even preferable to build yourself. It could be as simple as env vars or a config file.

--

However, feature flagging may also refer to deploying two variants of completed code for A/B testing or just an incremental rollout. This requires the ability to expose different code paths to selected users and measure the impact.

This sort of tooling is more difficult to build. It's not impossible, but comparatively complex because it probably needs to be adjustable easily without releases (i.e. requires a persistence layer) and by non-engineers (i.e. requires an admin UI). This becomes a product, and unless it's core to your business, it's probably better to pick something off the shelf.

Something I learned later in my career is that measuring the impact is actually a separate responsibility. Product metrics should be reported on anyway, and this is merely adding the ability to tag requests or other units of work with the variants applied, and slice your reporting on it. It's probably better not to build this either, unless you have a niche requirement not served by the market.

--

These are clearly two use cases, but share the overloaded term "feature flag":

1. Maintaining unfinished code in `main` without exposing it to users, which is far superior than long-lived feature branches but requires the ability to toggle.

2. Choosing which completed features to show to users to guide your product development.

(2) is likely better served by something off the shelf. And although they're orthogonal use cases, sometimes the same tool can support both. But if you only need (1), I wouldn't invest in a complex tool that's designed to support (2)—which I think is where I agree with you :)

Ruff’s ast is used by Ruff, Ty, and Pyrefly

Thank you! this looks pretty helpful

Pretty sure you can get EU data residency with sentry

https://docs.sentry.io/organization/data-storage-location/

Instagram built a linter with the ability to fix errors which is an improvement over flake8 & pylint: https://github.com/Instagram/Fixit

But Ruff is an even greater improvement over that

That's one of the features of EdgeQL:

    select Movie {
      id,
      title,
      actors: {
        name
      }
    };

https://docs.geldata.com/learn/edgeql#select-objects

Although I think good enough language server / IDE could automatically insert the join when you typed `credit.CLIENT->NAME`

Also interesting, pyrefly uses Ruff’s parser!

https://github.com/facebook/pyrefly/blob/a8626110da034f8e513...

Might be worth checking out https://github.com/DetachHead/basedpyright

But I’ve had the same issue with too many warnings, mypy is better at understanding Python but even slower.

A rewrite of https://github.com/facebook/pyre-check in rust?

Yes, this is a ground up rewrite: https://pyrefly.org/en/docs/pyrefly-faq/#what-is-the-relatio...

My thought exactly! Maybe for performance reasons? (Though I wouldn't expect OCaml to perform that badly, either…)

The web version is actually pretty decent, I use it on windows from time to time and it works great!

It also has some features that the MacOS one doesn't have like, a full screen lyrics view with some nice WebGL animations.

I didn't know about the web view. At least the search area stays visible.

> full screen lyrics view

Another gripe: In the app, when using the full screen player (there is also just a fullscreen mode) the lyrics can often be unreadable depending on the background colours that display. Also, you can't change the font size.

At work we have a lot of sentry errors related to browser extensions doing weird stuff.

Chrome’s Google translate is also notorious for breaking react based sites.

It ends up being a tedious triage process to ignore each new extension issue. We use the client side filtering to reduce our ingest volume. In general we have to have a lot higher thresholds to handle the noise vs our backends.

It's not just noise though; clients are actually experiencing crashes and other issues because of it. I wrote an in-depth article on the Google Translate extension's interference of React (and other webapps): https://martijnhols.nl/blog/everything-about-google-translat...

It's no wonder frontend has a lot more errors, after all it has to support so many more client variations than a typical backend. It can be very hard to make a big webapp that works well for everyone.

> At work we have a lot of sentry errors related to browser extensions doing weird stuff.

Are you referring to the "Object captured as exception" error which Sentry refuses to give any guidance on? We just end of filtering these out client-side.

Ah yeah I remember that one, but can’t remember the origin.

A lot of times the reason sentry can’t do much is because the browser JS VMs have terrible/non-existent stack traces, especially true with things like unhandled rejected promises.