quixoticaxolotl

Americans should understand their own immigration system before making these claims. Look at the numbers and the dynamics, and H1Bs aren't a threat to you:

- The number of new H1Bs issued per year is 85,000, capped by law.

- The total number of H1B holders today is around ~500,000, per USCIS and DHS.[0]

- H1Bs require bachelor degrees minimum to be granted a visa, which means they only compete for white-collar jobs. Let's assume all these H1Bs are software engineers, for sake of argument, and not university professors.

- The total labour pool for tech is around 6.7 _million_ per the Bureau of Labour Statistics (https://www.bls.gov/cps/cpsaat11b.htm, look at computing and mathematical operations section)

This works out to about ~7 percent of the total labor force consisting of H1Bs today. At 85k per year, it would take about five years to double that population to about 1 million. In that same time span, the US is expected to add 4 or 5 million in population growth alone - I don't know how you want to assume the tech labor pool grows, but I think it is silly to claim the population of H1Bs is a threat to the country's domestic labor pool.

You specifically talk about undercutting wages. H1Bs are supposed to be paid fair wages for their roles as everyone else per wage parity rules, precisely because they're not supposed to be preyed on or represent a displacement to Americans through cheap labor. Companies that attempt to skirt these rules use two techniques: deliberate underlevelling, so that highly qualified folks are categorized as lower-tier workers in occupations / categories other than their actual expertise so that companies can claim a lower wage, and contracting them to other employers at those wage rates. Meanwhile, the H1Bs for those companies can't actually enjoy job portability and escaping these constraints because switching jobs requires a transfer petition and risk, nor can they report their employer because getting fired means deportation. That is how H1Bs end up undercutting wages: not by design, but by abuse and captivity.

I have little patience for this sort of hand-wringing because the ire tends to be pointed and directed at H1B holders for simply existing - not at the institutions that game immigration law, not at a system that stifles legal immigration and blocks other pathways, not at a system that is too busy making the lives of immigrants harder than actually holding abusive actors accountable. There'a a perfectly reasonable system of reform that targets abuse and benefits everyone, but nativists don't want to exist with "foreigners", so they choose to punch down instead of up and claim self-defense. Such reasoning is, frankly, puerile.

> And we're heading toward a world where software companies let their users change the product themselves, since with an LLM that's easy. So if a company builds a good opinionated domain language for its product, everything its users build on top of it will be much better, because they start from the company's opinions and not from scratch.

This is a bold assertion, and one I think undermines the merits of the argument.

"Change the product themselves" - I haven't seen any software company or discussion propose doing this. I'm not sure how it'll work. It sounds like it blurs the line between configuration (letting the user toggle certain classes of existing behaviour) and forking (the user now owns the contract with the product).

Perhaps the idea is something like an embedded scripting language as used in some games, where users can write custom snippets to glue together what they want. Or a relational language to generate custom visualizations from raw data. These are the only forerunners of the concept that have found actual market fit to date that I'm aware of.

It's hard to generalize where else this would be useful outside of these domains, and in any domain I can think of - UI interfaces, data analysis, procedural generation - there is already a dominant language runtime bound to the environment (Javascript in browsers, C# in Unity) exposed to customers. Would Common Lisp be able to displace them? If so, why and how would it improve?

Merits on the basis of the runtime itself are meaningful, but the runtime needs to be popular for the value of the PL to be seen.

Note that the Shakespeare quote in the beginning is an example of antimetabole, not a pun.

Astro does this by design as part of its content collections: https://docs.astro.build/en/guides/content-collections/

They are already solving the problem with search engines, they're just using an LLM as a first pass to create better embeddings to run a similarity match on first. The difference in latency is likely made up for in accuracy.

Why? What purpose does it serve? Who benefits from it?

I think this is a false equivalence. Cloudflare doesn't espouse the position that ethnic cleaning is good, and afaik nothing it does in China enables that.

Further, DHH isn't calling for the deportation of illegal immigrants in parks. He's calling for the deportation of all people tagged with a specific label with no discrimination. The blog post talks about exactly that difference.

I agree that we live in an ecosystem where, in some industries, all options are terrible. That doesn't mean that, among those bad options, you can't exercise discernment and good judgment. I'm similarly a pragmatist from a different angle - I do believe the marginal dollar value I add to a company's bottom line doesn't change much of anything, and that voting with your wallet only works with collective action to be more than theater - but I also think that makes OP's conscientiousness admirable. Pragmatism isn't apathy or agnosticism, and shouldn't be conflated as such.

People claiming Andrew Kelley's remarks in this thread can't possibly be personal attacks surprise and sadden me.

If someone insults your ability to do your job, paints you as an opportunistic sellout, and thanks the stars for your riddance, saying someone shouldn't feel hurt because "we can separate personal from professional lives" says more about your inability to perceive your own hurtfulness than it does of that person's benevolence.

The minimum bar for tactful communication is to be courteous and empathetic. None of this had that.

Helping a mega-corporation make an extra buck is not "service to society".

If you meant doing a service job at a small business, where you can have real ownership over how it treats its customers, I would agree with you.

One benefit is that this can run in serverless / sandboxed containers where OS primitives are not exposed or heavily limited. I immediately thought of Cloudflare Workers, which runs on V8 and exposes WASM-only interfaces, using Workers AI.

Further, servers still have hosting value, but any business running agents is almost certainly going to want a sandbox that limits what code runs for agentic work, so targeting _sandbox_ environments is probably the better bet long-term. And, yes, you could implement your proposal in any chroot jail or gvisor, but nobody wants to get their hands dirty finnicking with that - programmatic access control beats file-based access control for the simple reason it's managed for you.

If anything, my critique of OP's implementation is actually the opposite of yours: they've chosen the right primitive and layer, but people really need contextual access control rather than RBAC. Sort of like ongoing zero trust. If it was possible to inspect the context, decide if it was a bad idea to allow the tool call, without exposing the decider to untrusted context, you could have something that really changes things.

How does one measure unique users here in a way different from classic p99? I usually associate p99 with an SLO of some kind, and each request as a "unique user" for the service, so at first it seems like the same thing - measuring p99 with a SLO would say 1% of users are allowed to experience a time longer than our acceptable minimum T, and you're measuring the percentage of requests ("users") experiencing T and trying to keep it below 1% (e.g.).

Is the difference more about measuring a request "across services"? That is, the total cumulative p99 across services must be small i.e. linking all requests to a user and then measuring that? Or is the difference elsewhere?

If the former: are you taking traces and graphing that? What's your methodology?