MurphyA/hacker-news huggingface dataset:
by impulser_ | 2025-08-21 21:49:40+00:00
I think the goal is to make uv a complete package manager for Python while still giving you the option to use the parts separately.

uv is like cargo for python.

If you only need a fast type checker you can just use ty, if you just need a fast formatter and linter you can just use ruff.

Combining ruff and ty doesn't make sense if you think about like this.
by charliermarsh | 2025-08-21 21:49:53+00:00
To clarify, `ruff` and `uv` aren't being merged. They remain separate tools. This is more about providing a simpler experience for users that don't want to think about their formatter as a separate tool.

The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.
by jp57 | 2025-08-21 21:50:37+00:00
I think folks have missed what I think would have been clever about the implentation I (apparently) dreamt up. It's not that "it's just a tape library", it's that it would have used the existing FC and picker infrastructure that Amazon had already built, with some racks containing drives for removable media. I was thinking that it would not have been some special facility purely for Glacier, but rather one or more regular FCs would just have had some shelves with Glacier media (not necessarily tapes).

Then the existing pickers would get special instructions on their handhelds: Go get item number NNNN from Row/shelf/bin X/Y/Z and take it to [machine-M] and slot it in, etc.
by ameliaquining | 2025-08-21 21:50:39+00:00
Yeah, in that case I think the link to boats's work obscures the point a bit.

I take what might be a slightly different read of matklad's point; I don't think Rust has much compromised its vision in terms of which broad features to support, but it has on a couple occasions chosen to ship something that wasn't perfect because being useful requires taking only a bounded amount of time to iterate on design.

So Rust 1.0 shipped without async, even though it was known to be needed for some of Rust's core use cases, because it was too far from being ready and it wouldn't do to wait forever. Once that decision was made, it had implications for how async could work; in particular, really doing it right requires linear types, but this wasn't appreciated when Rust 1.0 shipped and it's not a backwards-compatible change, so by 2018 it was off the table. The choice was, do async in a way that works with the existing design decisions, at the cost of some elegance, or don't do it at all. The former choice is not just more "industrial", I would argue that it coheres better, because waiting for multiple events at the same time is a core feature that a language for foundational software has to have, and the combinator-based approach that people were using in 2018 cohered poorly with the rest of the language (e.g., requiring unnecessary heap allocations). So this wasn't really a compromise to coherence.

(This also happened on a lesser scale when async/await first shipped—e.g., specific "async" syntax instead of a more general coroutine feature—because of eagerness to ship something that year. boats has claimed that this was a matter of existential survival for the language; I'm not sure I agree. But while async/await is a bit less conceptually pure than fully general coroutines, I don't believe that any of today's common complaints about async are downstream of the decision at that time to try to ship something quickly; there don't seem to have been a lot of obvious mistakes from then.)

(My understanding is that const has a similar story but I'm less familiar with the design space there, because people haven't exhaustively chronicled its history like they've done with async, perhaps because it's not as heatedly controversial.)
by bithive123 | 2025-08-21 21:50:49+00:00
I think that if replacing programmers with "AI" was going well, the people doing it wouldn't shut up about it.

So no, I don't think programming as a job will end soon, because there's no reason to think that it could. No plausible story I've seen about how that would even happen.

I do want to see big expensive products being built and released entirely by C-suites after laying off all their programmers/writers/directors/people who actually know how to do stuff. That should put an end to this madness pretty quickly.
by toss1 | 2025-08-21 21:51:44+00:00
Don't blame it on the PMs (except to the extent they are separating the engineers from the customers).

The closer you can get the engineers to the users, the better your product will be, and this goes all the way to the backend and architecture.

This is true no matter how skilled and well-intentioned are the PMs or sales reps.

I've seen one single layer between the builders and users to help modulate high and constant user demand can help.

Beyond that, even two layers can strangle a project. One project my company was doing for IBM was moving along nicely with the developers talking to the actual users every few weeks as progress was made & delivered. I moved off the project, then IBM inserted a manager to "consolidate the communications" (take all the users' input and boil it down), and a manager at my company (not the engineers) talked to him. The project became one of those endless slogs of feature creep, yet no great success — ultimately deployed for some years, but not the resounding improvements in workflow efficiency they hoped and saw in the beginning.

Absolutely EVERYONE on both teams was competent and really wanted the project to be a great success. But adding the intervening layers, while it seemed more efficient, had only the opposite effect.

Seriously, it ALL happens where the rubber meets the road. Get your developers as close to the end-users' keyboards and screens as possible. Talking directly to the users is great. Even better if you can arrange to have them BE a user for a day or two.
by hammock | 2025-08-21 21:52:06+00:00
>I'm in the American southwest (but not arid desert like parts of Arizona/Nevada/Utah)

Doesn’t matter whether you are in the desert or not, only matters if you are in a shared watershed with them. There is huge agricultural demand for water and water rights in those areas which translates to high prices for the areas where they can source water (like your presumably more-watered location)
by whodidntante | 2025-08-21 21:52:24+00:00
True, but I was around and saw first hand how Zuckerberg dominated social networking. He was pretty ruthless when it came to both business and technology, and he instilled in his team a religious fervor.

There is luck (and skill) involved when new industries form, with one or a very small handful of companies surviving the many dozens of hopefuls. The ones who do survive, however, are usually the most ruthlessness and know how to leverage skill, business, markets.

It does not mean that they can repeat their success when their industry changes or new opportunities come up.
by taeric | 2025-08-21 21:52:27+00:00
Fair questions, I think. I am just pointing out that if you have a lot of options when on foot, you almost certainly have more with a car. And you would have an easier schedule if you own your own car.

I say this as someone that enjoys the long slow walks. They are amazing. But if the goal is to get to the store/office and back, on foot is not as convenient as in a car.

The only times this is not the case, is when something has made the car not possible. Usually this boils down to "it can be prohibitively expensive to park a car at your destination."
by dawnofdusk | 2025-08-21 21:52:32+00:00
Agree. Science communicators should stick to talking about well-established or at least peer reviewed results. They do not need to be peddling fringe crackpottery. I don't think Tim's prose is magnificent, but the work speaks for itself: he wrote a serious technical document which stands alone with no response. Serious, credentialed physicists should platform these types and not grifters.
by extraisland | 2025-08-21 21:52:53+00:00
> These days, Windows doesn't seem to be in a much better state. I've been watching friends and coworkers complain about getting the Battlefield 6 beta to work. One of them had to do a fresh install of his computer, because he was using MBR partitions (which is now a no-no, apparently) and bricked it while trying to convert to a GPT scheme.

Well you are talking about a beta. The entire point is to get it out to some of the public to get feedback before final release. Secure boot is probably a requirement for the anti-cheat. IIRC it is a requirement for Windows 11 and Windows 10 is EOL soon.

Changing how the partitions work is just dangerous and you should backup before you try converting it.

That doesn't seem to be an indictment of Windows IMO.

> I use a pretty quirky setup on Linux and I find something that doesn't work properly out of the box maybe once every 2 years. I play a lot of popular multiplayer games with friends, but none of the billion dollar AAA blockbusters.

That hasn't been my experience at all. The point that I was making that it is super variable depending on the distro, GPU, game, launcher.

I am not distro-hopping to solve problems (I'd learned that didn't work almost two decades ago).

I just don't want to deal with it tbh. Rebooting into Windows takes less time that faffing with launch options.
by tgsovlerkhgsel | 2025-08-21 21:53:01+00:00
If a maintainer asks me to jump through too many stupid hoops, I'll just not contribute to the software.

That said, requiring adequate disclosure of AI is just fair. It also suggests that the other side is willing to accept AI-supported contributions (without being willing to review endless AI slop that they could have generated themselves if they had the time to read it).

I would expect such a maintainer to respond fairly to "I first vibecoded it. I then made manual changes, vibecoded a test, cursorily reviewed the code, checked that the tests provide good coverage, ran both existing and new tests, and manually tested the code."

That fair response might be a thorough review, or a request that I do the thorough review before they put in the time, but I'd expect it to be more than a blatant "nope, AI touched this, go away".
by 1attice | 2025-08-21 21:53:15+00:00
I assume this is about AI, but I'd like to set the lens a bit wider than that.

Since the eighties, software (as problem/solution space) has expanded to fit the hardware available. At first we scaled with the density of transistors, and then, in the nineties, we scaled with the unfolding multitude of Internet-enabled use cases. Then, in the late aughts, we scaled again, this time with the unfolding multitude of mobile and embedded use cases.

Think of it as a sort of hot-air balloon -- each of these initial spurts is kind of like the guy in the balloon pulling the rope to heat the air; the balloon goes up. And each time we got to pull that rope, we got to go higher, and explore more and more of the problem/solution space, transforming the world as we went.

The thing is, hot air balloons can only rise so high -- they have a contextual window that includes the lower and middle parts of Earth's atmosphere. But you can't get a hot-air balloon into orbit -- the context window gives out; you'd need to go back to earth and start from scratch (maybe build a rocket.)

What I find striking about AI isn't that it can replace all or most coders, it's that (to continue the metaphor) it makes the existing air in the balloon more buoyant -- there is less need for the guy pulling the rope to pull that rope (so if your job is rope-pulling-guy, watch out.) Yet -- and this is the crucial part -- AI is being _sold_ as if it's _more atmosphere_. I.e., someplace for both money and talent to _go_; a reason to keep pulling that rope.

For a while, it looked as if it was both -- a way to pull on the rope less frequently, and _also_ a new problem/solution space to go with the ol' balloon basket. But I'd reckon the _excitement_ about AI largely had to do with the second interpretation.

Now the picture is less certain. For some activities, AI still seems genuinely revelatory/apocalyptic, depending on which side of the manager/labour dyad you fall. Yet recent studies (frequently alluded to here on HN already, scroll around) seem to show limited bottom-line benefit for a lot of use cases. This might mean there is UX work to be done, or it might mean that we're bumping up against the top of the balloon's useful range, skidding along the ceiling of the problem/solution space.

So, ironically, if AI turns out to be very useful, in the same way that word processing, email, and maps all proved useful, programming sticks around as a lucrative profession, modulo some changes in how we market and think about ourselves as engineers. We will use AI to build the new AI things that people want.

But if, for whatever reason, AI turns out to be less of a big deal than it initially seemed, then we rope-pullers are now in a situation where there is less need to pull that rope, as there is nowhere left to go (and worse, the balloon is simply more buoyant now, and needs fewer rope-pullers).

So if AI is a big deal, the party continues; if AI is _not_ a big deal, it's time to get other skills, as a stagnant market leaves the investment capital nowhere to go and our skill-set becomes commoditized. (Time to get a union.)
by Fade_Dance | 2025-08-21 21:53:20+00:00
The residuals question maybe more important than it at first seems.

A lot of these cars at the very top of the food chain do hold their value or even appreciate. At the very least the buyers do seem to be at least pretending to be making "an investment" in order to justify the purchase. This is deeply entrenched in the hypercar world, for example when it comes to working your way up the Ferrari ladder, part of the explicit draw is that after enough spending you get access to the limited high-end releases which hold their value. The buyers could theoretically flip their allocations for a profit (although they would be banned if they were to do that, and it takes a lot of spending to get to that position so it's not incentivized).

The F40s and McLaren f1s of the world transition from hypercar to collectible classic. I do think that the battery situation genuinely makes the perspective buyers uncomfortable. The hybrid battery in a P1 is 150,000.

Ferrari has a program where for the low price of about 10k per year, the buyer gets a new hybrid battery at the 8 and 16 year mark. This is probably the sort of approach that the EV hypercar manufacturers have to pursue in order to alleviate customer concerns. Unlike metal parts that sit in a warehouse (and a secondary universe of high end restomod stuff), it might genuinely be an issue if these battery chemistries aren't available in the coming decades when it comes to resale value.
by benreesman | 2025-08-21 21:54:12+00:00
It's really difficult to do Python projects in a sound, reproducible, reasonably portable way. uv sync is in general able to build you only a package set that it can promise to build again.

But it can't in general build torch-tensorrt or flash-attn because it has no way of knowing if Mercury was in retrograde when you ran pip. They are trying to thread a delicate an economically pivotal needle: the Python community prizes privatizing the profits and socializing the costs of "works on my box".

The cost of making the software deployable, secure, repeatable, reliable didn't go away! It just became someone else's problem at a later time in a different place with far fewer degrees of freedom.

Doing this in a way that satisfies serious operations people without alienating the "works on my box...sometimes" crowd is The Lord's Work.
by eschaton | 2025-08-21 21:54:13+00:00
You’re basically saying “if a rule can be broken, it will be, therefore rules are useless.”

If someone really wants to commit fraud they’re going to commit fraud. (For example, by not disclosing AI use when a repository requires it.) But if their fraud is discovered, they can still be punished for it, and mitigating actions taken. That’s not nothing, and does actually do a lot to prevent people from engaging in such fraud in the first place.
by scarface_74 | 2025-08-21 21:54:15+00:00
I don’t get paid to “write code”. I use my 30 years of professional industry experience to either make the company money or to save the company money and in exchange for my labor, they put money in my account and formerly RSUs in my brokerage account.

It’s not about “passion”. It’s purely transactional and I will use any tool that is available to me to do it.

If an LLM can make me more efficient at that so be it. I’m also not spending months getting a server room built out to hold a SAN that can store a whopping 3TB of storage like in 2002. I write 4 lines of Yaml to provision an S3 bucket.
by ameliaquining | 2025-08-21 21:54:48+00:00
Do those features actually cause difficulty for anyone other than compiler engineers, compared to not having them? I haven't personally seen, e.g., newbies stumbling over them; they're actually designed remarkably well to fade into the background and Just Work (i.e., you don't notice they're there, but you definitely would notice if they went away). Yes, there's something to be said for minimalism in language design, but Rust without those features still isn't very minimalistic, so dropping them would seem to bring about most of the costs of minimalism without the benefits.
by Nextgrid | 2025-08-21 21:55:00+00:00
Docker is effectively just a packaging format on Linux - it's not a VM (unlike on Windows/Mac where running Docker involves running a hidden Linux VM on which containers are scheduled). So I don't see why you wouldn't use it if it makes things easier (like not having to worry about distro specifics, since there is generally one canonical Docker image for major pieces of software)?
by blurbleblurble | 2025-08-21 21:55:04+00:00
Of course. I don't actually think the maintainer guidelines here are entirely unreasonable, even if I'd personally modify them to reduce reactive panic.

My little essay up there is more so a response to the heated "LLM people vs pure people" comments I'm reading all over this discussion. Some of this stuff just seems entirely misguided and fear driven.
Ask HN: What tools are you spending your money on?
by sprainedankles | 2025-08-21 21:55:09+00:00
While I'm able, I'd like to start converting some savings into tangible tools and things that have near and/or long term benefits. Things like power tools, a small solar backup power system, a 3D printer, and a greenhouse are things I've been thinking about, but I'd love to hear what others are choosing to invest in and why (for enjoyment? to prep for a disaster/economic downturn? because it's on sale right now??)

For additional context, I'm relatively new to homeownership and enjoy building/making things!
by tzs | 2025-08-21 21:55:26+00:00
You are overlooking location. The ideal place to grow crops is a place with great soil, good weather, a long growing season, and abundant water, but there aren't a lot of those. Of those four things, water is the only one that can be reasonably transported.

Data centers have fewer constraints. It should be possible to place more or all of them in places where water is abundant.
by therealfiona | 2025-08-21 21:55:56+00:00
After 7 years, and me wanting to move off EKS since I got the job 4 years ago, we are moving to ECS (I rose to power of Lead recently, but my engineers also thought it was a great move as they're sick of all the K8s BS).

The time sink required for the care and feeding just isn't worth it. I pretty much have to dedicate one engineer about 50% of the year to keeping the dang thing updated.

The folks who set it all up did a poor job. And it has been a mess to clean up. Not for lack of trying, but for lack of those same people being able to refine their work, getting pulled into the new hotness and letting the clusters rot.

Idk your workload, but mine is not even suited for K8s... The app doesn't like to scale. And if the leader node gets terminated from a scale down, or an EC2 fails, processing stops while the leader is reelected. Hopefully not another node that is going down in a few seconds... Most of the app teams stopped trying to scale their app up and down because of this ...

I would run on ECS if AWS was my cloud at a start up. Then if scaling was getting too crazy, move to EKS.

But for the love of God ... Keep your monitoring and logging separated from your apps. Give it its own ECS cluster, or buy a fully managed solution. It is hard to record downtime if your monitoring goes down during your K8s upgrade.
by shermantanktop | 2025-08-21 21:56:12+00:00
Do they lose moral agency? Having practical reasons to take an action is not the same as ceding moral agency.

We are not perfect creatures and sometimes do immoral things, for various reasons. But we did those things, nobody else did them.

That also suggests a practical guideline: whatever your rationale for taking action, anticipate living with that rationale for years and years. If you can’t see it looking the same 10 years from now, perhaps that is a strong clue.
by littlestymaar | 2025-08-21 21:56:22+00:00
Mistral may not be the smartest chat assistant out there, but I've stopped using others entirely given how slow they are compared to Mistral (which runs inference with Cerebras).

Waiting for an AI to complete its task isn't a fun thing at all, and I'd chose the fast 70% correct response any day over the slow 90% correct one. Because by the time the slow one gives you its first attempt, you'd have clarified you need and fixed the output from the fast one.

Sure if we get to the point where the slow system is 100% right, then it's no big deal if it's slow, but we're still far from that point.
by lillecarl | 2025-08-21 21:56:24+00:00
Kubernetes already has simple secrets, good enough for me.

I would provision buckets with Terraform/tofu, we just use ingress so idk about API gateways.

The eye opener for me was "I can just do this in Kubernetes", which is pretty much always true (though not always right).

Kubernetes + Prometheus + Grafana (with friends), cert-manager, CSI, LB and some CNI you have something resembling what I'd use from $cloud provider.

Deploying K3s is really easy, it can definitely be a time-sink when you're learning but the knowledge transfers really well.

You also don't really need all Kubernetes features to use it, you can deploy K3s on a single VM and run your pods with hostnetworking and local path mounts, essentially turning it into a fancy docker-compose which you can grow with instead of throw out.

I value FOSS and being able to run "anywhere" with the same tools. K8s and Postgres gets me there, I haven't worked on any "web scale" projects though but I know both can scale pretty high.
by charliermarsh | 2025-08-21 21:56:42+00:00
Good questions. I don't think we'd ever deprecate Ruff because `uv format` exists, and adding `uv format` won't have any impact on Ruff's release cycles or development. The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.

A lot of users just want a simpler experience. They want to install uv, run `uv run` to run their project, `uv format` to format it, etc. The idea here is to experiment with providing that functionality and see if folks find it useful. Maybe they won't want it! It's experimental :)
by replygirl | 2025-08-21 21:57:25+00:00
i expect to hear "hey replygirl, can we upgrade from ruff to uv format?" from 5 of my coworkers in the next month, and "what's the difference between ruff and uv format?" from another 10. per interaction i expect 2 minutes of reading and explaining, plus an average 5 minutes listening to the other party wax philosophical. so the convenience costs my job $400
by gigatexal | 2025-08-21 21:58:12+00:00
Meh. The CDK doesn’t look terrible. It’s still not ideal. But even if this compiles to a mess of CF it’s still better than writing CF by hand and that’s only because CF is so bad to begin with.

https://dev.to/kelvinskell/getting-started-with-aws-cdk-in-p...