andenacitelli

I haven't actually tried it out, but have done a bit of research in the name of scoping a competing product, and my verdict is that it's probably too immature to be worth production usage. It also makes the design decision to delegate most of the actual hard work (the type checking) to the type checker of Erg, a strongly typed superset of Python, which leaves a lot of decisions and agency out of the purview of Pylyzer itself. There will always be limitations that can only be resolved upstream.

Granted, maybe there's value in this just being a wrapper, and it's best to just deduplicate the work. However, it just sits a little wrong to me that it's not type checking Python, it's doing a transpilation step of sorts and type checking that.

I wonder if a better use of time would be to just focus on making mypy faster. We already have too many tools, and it's often better to just focus on making the existing stuff better rather than developing a new tool (relevant XKCD [1]). There's gotta be ways to make mypy faster, even if it takes some breaking changes.

One consideration there would probably be how many committal decisions mypy has made. One of the main reasons a new tool might be better than an old one is that it can be built fresh, with all the lessons learned but (essentially) none of the baggage of bad design decisions.

Another thing I've also weighed is that developing any kind of static analysis tool whose source code is not in the language it analyzes (such as Ruff) immediately blocks you off from a large portion of maintainers. Your maintainers cannot be your end users unless they work with both Python and Rust. While Python is definitely one or more magnitudes slower than Rust, I can't imagine that mypy is at the point where the language choice itself is the only bottleneck.

[1] https://xkcd.com/927/

I dug into Pylyzer a few weeks back when scoping out alternatives for faster type checkers, as we have a lot of brittle Python code that we are gradually migrating in at $DAYJOB. I got the idea in my head to basically build mypy but in Rust, similar to what Ruff has done.

My research agrees with your assessment. While I'm sure it's a lot faster (I think the README implies it's one or two magnitudes faster) it just doesn't sit right to me that it's essentially just transpiles to Erg and delegates the actual hard work to the Erg typechecker. This works, but I feel like it fundamentally limits what Pylyzer is capable of, and how much control it really has over the underlying type checking process, as to it, the Erg type checker is essentially a black box.

It's a wrapper (a non-trivial one, to its credit -- especially considering everything is a wrapper if you look at it the right way -- but still a wrapper) rather than an actual full solution.

There's also really only one maintainer (who seems to do a decent job, but I don't seem to recall much more than just bug fixes). Makes me hesitant to really depend on it sticking around long-term or having features that meaningfully progress in the future.

This is absolutely hilarious. Prompt engineering is such a mixed bag of crazy stuff that actually works. Reminds me of how they respond better if you put them under some kind of pressure (respond better, or else…).

I haven’t looked at the prompts we run in prod at $DAYJOB for a while but I think we have at least five or ten things that are REALLY weird out of context.

This has also been my experience. Linting works decently but formatting has been buggy, so I actually have time toy projects where I lint with Biome but format with Prettier.

Yes, we built an integration to ingest data from Hubspot at $DAYJOB and it was one of the worst we’ve had to deal with. They’re horribly inconsistent with what is documented and what isn’t. Even Meta’s has been better.

It also makes portability a pain. Switching from an app with Firebase calls littered through the frontend and data consistency issues to something like Postgres is a lengthy process.

This is sometimes so hard to remember. There’s so much content on optimizing for page size — and admittedly, it does matter a lot in some industries like e-commerce and/or if you have users in less developed countries — but quite a lot of situations kind of just let you ignore it.

I work in B2B and we frankly put way more effort in than we should have to optimize bundle size before just making the assumption that everyone has a good connection and we didn’t really need to worry about it.

Woah, 200k LoC is considered medium? I work at a Series A startup and our entire product (which is actually much more than a CRUD app) is only in the high tens of thousands, so that’s just a funny thought for me.

My theory is that because Rust is a low level language you tend to miss out on higher level primitives that promote more code reuse. Another theory is that Rust is mature but not quite as mature as something like Java, so there are fewer mature dependencies for you to delegate your work to.

Thoughts on what’s accurate? For context, I’ve written a bit of Rust myself, but am definitely a beginner.

I’m predominantly inattentive type but focus isn’t actually my most severe symptom. That would be executive dysfunction.

I lucked into SWE being a hyperfocus of sorts, so luckily work isn’t awful if I’m not on meds, but holy cow is anything else just complete drudgery. Feels like everything is behind a wall of “startup energy” that is so hard to get through, especially without external accountability.

Rejection sensitivity is also part of it for me. I felt like I could never think fast or organized enough in the moment when talking (I would lose my train of thought in the middle of sentences), so I would get anxious coming in and try and plan, but there’s only so much you can plan for, and it just is a bad cycle to get in. Therapy and internalizing things don’t actually have that high stakes is helpful but only mostly a fix.

I’m a SWE at a Series A startup with predominantly inattentive ADHD. The need for me to jump around a bunch of things rather than just tunnel on the same area is a godsend. I struggle to really go deep or commit to long-running efforts, but if I can just jump into each thing for a few hours and constantly rotate things, I get an insane amount of work done.

Most jobs would not afford me this, but I lucked into a great role that plays into it rather than fights it.

Any thought on how this compares to Meltano and also their Singer SDK? We use it at $DAYJOB because it gives us a great hybrid of standardizing so we don’t have to treat it differently downstream while still letting us customize,

We migrated a few months back and it was an excellent decision. Just so much simpler and comes with way more out-of-the-box.

Hard agree. This article makes good points but I feel like Poetry just simplifies so much of it and makes it so much less manual. We’ve used it at $DAYJOB for months and it’s been awesome. In the same sense as the article — it’s been sufficiently boring to rarely be the source of problems, and when it is, it’s almost always our fault rather than a design flaw in Poetry.

Requests works just fine for 99% of use cases and is much more prevalent, meaning it has a lot more hits on Google if you’re debugging something. Not saying it’s better, just sufficient for most use cases.

We run our most important ones (main api endpoint health check, homepage browser check) anywhere from every minute to every five minutes depending on time of day. We only use one region because our users are mostly in the US. Less vital but still important ones are every fifteen minutes or so.

We overlap “peak” and “non-peak” schedules. The peak one runs during work hours every minute. The “non-peak” ones run 24/7 (no easy way to exclude the time periods that peak runs, otherwise we’d exclude this) but more infrequently, every five minutes.

We use Datadog, but try and be fairly barebones about it because it’s really expensive at scale and we only rarely actually catch issues with them because our CI process has gotten much better. We also used Checkly in the past and had no real complaints, just switched to Datadog to keep everything in one place.

I personally know them as synthetic tests. They are generally tests you run at a cadence against your live, production site.

Most services offer both:

- “API” where they can just send a basic GET request and assert the response is 2xx (we use these for our main api endpoint)

- “Browser” tests, which is more like Playwright in that it’s an actual browser (albeit usually headless) - we run these against our main homepage and assert some important pieces of text are present (in other words, checking we didn’t push a broken bundle or something).

Browser tests usually cost more by about a magnitude because they cost drastically more compute (still not THAT much, but it’s expensive at scale).

Notion doesn’t really shine when it’s used as a markdown alternative or an editor, though their editing experience IS excellent (though admittedly, for simple cases, no app can really beat the simplicity of Markdown).

The things you can do with dynamic content (database) really make it more than a wiki. People can, and do, plan their whole life in it. Project management, SEO-indexable pages, lots of surprisingly cool stuff. I used to use it quite frequently, though my ADHD causes me gravitate a bit more heavily towards organizational mechanisms like it to cope.

Using it to make impromptu priority lists that will do a lot of the reorganization for me as I slot new content in is really nice. It’s a bit of overhead but it’s often worth it for anything nontrivial. I keep a backlog in it and use it for scratch work and rough design docs (final copy goes in our actual deployed-from-markdown docs).

Uniqlo has a similar system for some stores where you just throw the items in and it automatically senses them. It’s probably more feasible for them because they do much more of the supply chain for their products and basically have an item all the way from manufacture to retail sale, so they probably cut a lot of the middlemen costs.

Spent some time with this kind of system in WoW, TradeSkillMaster. Figuring out an accurate valuation was difficult and one of the biggest differentiators of how successful you were.

This would vary by item, but was most commonly some combination of recent minimum buyouts (usually over the last two weeks) historically value (several months), and much more. Common items would usually be mostly recent value driven, whereas lower-supply items might have a larger component of historical weighed in, as there might be quite a bit of fluctuation day to day and you care much more just about the general trend.

All sorts of nuance to it. You can do more complex stuff like only doing your price estimations off items that actually sold, set values based on a percentage of any other value, and much, much more. It gets really complex but is really cool at scale.

Apple’s SE series is actually really nice if you don’t like the trend of bigger phones - it’s the same (or similar) internals as the new ones but in a small form factor (4.9 inches? Whatever the 6s had). I don’t want a large phone that barely fits in my pocket, but I want decent internals, so I have one. Apple is by no means a perfect company but I think the SE was one of their correct decisions.

Some have substance, but most are simply thin wrappers with no real defensible moat. Best to let time tell what’s successful.

Don’t Docker themselves have a tool for this, Docker Scout? Pops up with how many known vulnerabilities are in each layer when you go to the page for a specific tag on Docker Hub.

I think it’s a somewhat new product so it may not be too widespread yet, but it seems to work pretty well from my admittedly uninformed perspective.

My budgeting app (Monarch) has a system with a lot of parallels. It tries to automatically profile your transactions into a sensible category based on the statement text, and also allows you to set up persistent rules on top to categories it may have messed up. It still has a “we couldn’t categorize this, please help” list it gives you, but I find its recommendations fairly good and I get maybe one transaction a month it can’t figure out.

Anecdotally, but my company adopted Datadog a few months ago and all their sales / solution engineering folks would usually be calling in from an in-person office. Rules out 100% remote, if nothing else.

Yes. Worst that should happen is getting a 404 or something. A crash due to requesting a piece of data that has not yet been created is poor design.

A little concerned about FastAPI’s low bus factor, and the docs being only example-driven rather than reference docs gets occasionally annoying, but other than that it’s been nice and we aren’t regretting running it in prod.

BitWarden (and possibly other password managers) has a mechanism where you can specify people that can take over and view your credentials in the event of your untimely demise. Probably isn’t an immediate process or anything, but gives me a lot of peace of mind.

Webhooks tend to make a lot more sense in event-driven applications . They introduce additional complexity when it comes to all sorts of edge cases - agree that a pull system is probably much easier to do error handling for, my only concern would probably be performance.

Cool site. Seems like a great learning resource, nice work. (No affiliation, just a sucker for good docs)