andenacitelli

Successfully tracked down the Hyrum's Law one, nice work

> downstream developers will learn to depend on every possible behavior your API accomplishes, even the unintended ones

https://xkcd.com/1172/

+1 for Mise, it has just totally solved the 1..N problem for us and made it hilariously easy to be more consistent across local dev and workflows

some discussion in https://news.ycombinator.com/item?id=44303052, which seems to have been posted first

some discussion in https://news.ycombinator.com/item?id=44303052, which seems to have been posted first

Their status page has updated w/ a GitHub Copilot degraded perf warning. Seems like they're at least aware of it

Yep. Some of it's working fine, but various file downloads are giving 500/503

Say what you want, Astral ships impressively fast and their stuff works well. Python has been looking for better tooling for a long time.

I’ve had this same thought. Ruff doesn’t support extensions / custom lint rules that I’m aware of, so maybe don’t get your hopes up.

AWS supports Valkey for Elasticache, and they actually bill it 33% cheaper. We use it and it works well.

Yes, this is it. You can usually find some discounted or free way to get most books, but I had classes where you literally submitted homework through the same system you accessed the book through, and it was like $150.

They yanked the relevant change and pushed a new one with a revert, this is now resolved

Took them seemingly forever to do. The reversion, sure, that might take a bit to proof, but the yank should have been done way sooner

From what I gather this has basically derailed CI for the morning for the majority of places out there. Only workaround is pinning build-time dependencies, which only pip and uv seem to let you do well. Poetry is SOL / heavily cache-dependent as to whether it works.

A full rewrite instead of finding a way to gradually increment already feels like a lot of risk. Asking your core dev team to potentially pick up an entirely new skillset in Rust would introduce too much on top and probably cause people to flake from the project.

Totally agree something like Rust would be good in a vacuum, but existing contributors and ecosystem would present problems. Having tooling built in the same ecosystem as the end product makes it way easier to contribute.

"Pandas alternative" kind of undersells it -- it's drastically faster and supposedly has a much more intuitive interface. The limits of how long you can keep doing things entirely in-memory (and postpone the move to something like Spark) get higher and higher.

The installation and first five minutes of any kind of product is hugely make or break. I keep my resume in LaTeX via Overleaf, but probably wouldn’t bother with it if I had to get LaTeX running locally, which has always seemed fairly complex to me (though I’m admittedly no LaTeX has expert and may entirely be wrong).

“AI” (as absurdly broad of a term as it is) has legitimate use case. It isn’t JUST hype. However, because of the buzz, it’s being shoehorned into so many places it really just isn’t the proper fit for, and it’s hard to figure it where.

However, there ARE plenty of areas it IS the right fit for. Lots of “fuzzy” systems that would struggle to be rule-based and generalizable benefit hugely from LLMs and other fuzzy / intentionally broadly scoped tooling.

Source — I work at a “chat with your data” startup, and our product just categorically wouldn’t be worthwhile if the above weren’t true :)

Yes, but it’s true in the general case. Defaults are usually the defaults for a reason — someone putting thought into what makes sense for most users.

I don’t closely follow the space, but Anker has always seemed like reasonable quality at a reasonable price. Maybe I’m easily marketed to or something. But I’ve had quite a few adapters and cables and such from them and have never had an issue.

I think Rust only really shines when you factor in the longer-term lifetime (pun unintended) of the code. If you’re just focused on how much time it takes to get something working — in other words, a PoC / MVP — it doesn’t seem surprising to me that it’s significantly slower.

The promise to me lies in the entire classes of errors you systemically prevent from happening (given no unsafe code) and just generally how much easier it is to write maintainable and bug-free code.

These mechanisms are part of a very broad set of tooling that slows you down short-term but pays off in huge quantities over any even medium-term timeframe in an actual business product intended to be long-living.

Granted, Rust has its tradeoffs just like any other language — from what I hear, refactoring and fighting the compiler in certain domains like gamedev gets annoying — but it seems much more positive than negative.

Totally agree. Maybe if OP phrased it as “Urgency” instead of “Scarcity”, I would have agreed. But these are two distinct concepts that just happen to cause similar outcomes. Almost similar to a concept of an “incorrect” or “false” abstraction in SWE land.

Hi friend -- your resume link seems to be broken

+1

Simple and stable, no more complex than it needs to be, never run into any issues w/ it

vantage.sh ec2 instances page

Akkio has a pretty good chatbot for this as well as a much longer tail of data transformation and predictive modeling / AutoML features.

Disclaimer: I work at Akkio, but think we have a really nice, value-add product and an excellent team behind it :)

Another example of this is AWS CDK. There are a few “levels” of constructs - high level ones that are simpler and apply “presets” that are enough for 80% of users, but the core low level ones still exist if you have a nonstandard use case.

Well I guess we need to figure out how to regression test humans then!

Reminds me of when I jailbroke an old iPhone and the only thing I really actually used the jailbreak for was making a long press on the volume buttons a previous / next song button. I actually really miss it.

You can also use something like stubgen to generate function definition signatures for dependencies for mypy to validate, then make your own changes to those files with better types if you wish.

I don’t think it’s very scalable, and having the library itself or a stubs package come with types is the only “good”-feeling route, but you at least have a somewhat decent path to still getting it decent without any intervention on the library’s part. It may even be sufficient, if (like in most situations) you only use a few functions from a library (which may in turn call others, but you only care about the ones your code directly touches), and therefore only need to type those ones.

Haven't used it directly myself. We mostly just use it for DataFrame crunching via pandas and/or polars (our usage is mixed) which tends to benefit nicely from columnar access.

Can we just all converge on Parquet + Arrow and call it a day please? Too much effort being put into 1..N ways to solve a problem that would be better put towards a single standard.

We work with Parquet + Arrow every day at $DAYJOB in a ML and Big Data context and it's been great. We don't even think we're using it to its fullest potential, but it's never been the bottleneck for us.