sunshowers

I think you might be fundamentally misunderstanding distro maintainers' role in the ecosystem. Your job is not to question your upstreams' development practices or technologies used, beyond the basics like it being FOSS -- it is to adapt to them.

There are plenty of other points in the design space here. For example, I think once a sufficient number of people have built a binary and verified that it is the same hash (publishing the hashes to an irrevocable transparency log), caching those binaries doesn't increase the supply chain surface. The point you have chosen is quite out there, and it isn't reasonable to expect others to conform to it, and it certainly isn't reasonable to say that Rust isn't the right choice for a project because it negatively impacts you.

This is entirely self-inflicted on your part!

> Rust is not actually the right tool for all problems.

Rust is certainly the right tool for this problem, your own decisions notwithstanding.

Perhaps I'm missing something, but I don't associate Rand with LVT.

I'm responding to the argument made in general, yes, if you read the post I was responding to.

> Bad immigration policy can and does negatively affect opportunities and salaries.

It is true by definition that some immigration policies are worse than others — for example, a policy of no immigration at all (which is a kind of immigration policy) would be very bad for opportunities and salaries.

Well, the general economic consensus is that for income taxes, the revenue-maximizing peak of the Laffer curve is around 65-70% [1]. Revenue maximization isn't necessarily the right primary goal, though.

[1] https://en.wikipedia.org/wiki/Laffer_curve#Income_tax_rate_a...

You understand that people get better at things over time?

I came in on an H1B as an IC3 at Meta. Now, with the skills I gained during my career, I maintain core infrastructure that has a massive benefit to the industry and is critical to tech companies of all sizes (I learned last week that a major auto manufacturer uses my infrastructure as well). Immigration's benefit to society is tail-distributed, which is why it's important to have broad-based immigration (you can't predict who will be at the tails).

Unlike offshoring, immigration increases supply and demand at the same time.

Also: https://en.wikipedia.org/wiki/Lump_of_labour_fallacy

all H1B posts turn into Klan rallies.

My complaint is directed at the Rust Foundation, not the authors, to be clear. Yes, it's free labor, but the Foundation ought to have standards.

I showed Bryan the post while in a meeting room with him, left the room, and a few minutes later heard a very loud, very exasperated primal scream coming from the room!

Well, one example is that patterns in code now can make you recall bugs you've seen in the past. I had this realization where I used an LLM to do a big refactor, and it fixed a bug along the way that I should have realized was much more urgent than the refactor, having seen an identical bug in the past (it was related to prefix-checking in a set that wasn't constructed to do that kind of prefix-checking). Had I done the refactor by hand I'd likely have realized it much quicker.

Right, when used incompetently. When used competently they can carefully reason through every edge case and flag things no human would have picked up on.

One example: in some old code I wrote I had assumed that the Rust Hash impl for a type is stable over time. This is not the case in general, but writing a custom hasher for a complex type is incredibly annoying, so I took that shortcut. That was fine for years, but came back to bite me this week as I was trying to update a dependency.

How much incidental complexity is due to that kind of thing? An LLM code review would flag this instantly, and one would also write a stable hash function for you.

This whole week I've been dealing with incidental complexity created by shortcuts taken and edge cases not handled in code written in the before times, both in mine and in others'. I realized at some point yesterday that these kinds of shortcuts would no longer be accepted with competent LLM use.

Are you aware of comparative advantage? What matters is opportunity cost, not raw output. (Also, unit labor cost is wage per hour divided by output per hour, so the number of hours worked is not really relevant. In other words, longer hours make workers richer and not their output cheaper.)

This was worked out by David Ricardo 200 years ago. You still benefit from trade even if (granting the argument) you are worse at producing everything.

This is only tangentially related, but libuv and mio's Windows implementations use the undocumented AFD readiness-based poll interface [1], since there isn't a documented readiness-based interface on Windows. The undocumented interface is now effectively stable since, among other reasons, Microsoft uses Tokio in some of its products.

[1] https://github.com/tokio-rs/mio/blob/master/src/sys/windows/...

> Can I get non-interger display scaling yet?

I'm using 1.25 scale on Niri + DMS right now, on a dual 4k monitor (G9 57) at 240Hz. Probably the most demanding single monitor setup right now.

By security scanners, the moment a crate is uploaded to crates.io. The way forward here is dependency cooldowns enabled by default for ordinary users (and crates.io changed to show the old version until the new one is a day or two old). Essentially, security scanners get to vet a package for a day or two before ordinary users see it in everyday development.

Every Rust crate is heavily scrutinized these days using LLMs (which also caught this issue). The days when no one looked at dependencies are gone.

BTW not sure how you feel about LLMs but merge conflicts are not really an issue with them any more.

Lots of people want to buy our stuff!

I mean, really no one is fully independent — we are all dependent on each other for the necessities of life. But in this context "independent" means "not a subsidiary of another company".

Right -- customers don't have to port their stuff to a new platform or arch or anything. It's just normal x86_64 Linux/Windows VMs, or Terraform if they're so inclined.

We are trying to build a sustainable long-term business! It's just that you need enormous amounts of money to get there when shipping this large a product.

The idea behind VC funding generally is that you need large infusions of capital to get to the point where the business becomes sustainable long-term. The first one is the most expensive, and so on. Hardware is capital-intensive compared to SaaS, and especially so in the current environment.

It's not actually secret — it's open source! We talk openly about our architecture.

Bryan has a good take on the incentive structures holding back commodity hardware vendors: https://m.youtube.com/shorts/O8GSWKpK79s

That's wonderful! Good luck.

Indeed, and I happened to have been part of the creation story for one of them :) https://lobste.rs/s/ghdv6w/i_see_future_jj#c_nx6flj (not otherwise affiliated, though)

GitHub has a chance to get a generation of developers on to better coding practices. LLMs make it more feasible than ever to maintain high-quality patch series/stacked diffs — they can take care of all the mundane things like rebase conflicts for you. If I were in charge I would take this responsibility very seriously.

I guess the next best thing would be to port spr to this. (Probably time to start looking at this to be honest!) This makes me quite sad.

I use `spr` which translates a local rebase + amend workflow into a GH-friendly new-commit + merge on the remote (which is then squashed). They are kind of equivalent from a 30k foot view but the dev experience when working with source control locally is dramatically different. And in particular I regularly have stacks of dozens of commits in flight -- if each commit were a series of commits then I would probably lose it.

The seeming lack of engagement with prior art is so frustrating.