BiteCode_dev

This is a good thing and a required first step, but it's a drop in the sea.

All MacOS, iOS, Windows and Android are all produced by the USA. Virtually all chips as well.

It is foolish to assume there are not backdoors in every one of them.

Meaning we should assume the USA can shut down the entire Europe's IT if they really want to.

Then you got the authentication systems, security software (antivirus, proxies like cloudflare, crowdstrike and so on), the various Saas (docs editors, drives, ticket systems, chats...), the payment systems (including Visa and swift, but also Paypal, google pay, stripe, etc), the software stores, the root DNS, the SSL root certificates and a ton of network hardware.

Given the current political situation, it's a very bad spot to be in.

The minority reports vibe is getting stronger by the minutes.

It's not a trick; it's the closest they can get away with lying with plausible deniability.

To sell you ads that are mostly lies already.

No it's not fraud, it's a growth hack. And it's not lying, it's advertising, it's not spam, it's a cold email, it's not patent trolling, it's IP protection.

But maybe it's maybelline.

And ipdb if you want ipython repl.

The music "boss_battle" rocks. Where does it come from?

Also window.document.forms gets you direct access to all forms, "name" automatically attach an attribute to the parents and "this" rebind to the current element on inline event handler.

The DOM API may have been very messy at creation, but it is also very handy and powerful, especially for binding to a live programming visual environment with instant remote update capabilities.

GPS is moving to a different control center. This coincides with self reports of accuracy degradation in the service and actual gaps in data recorded on https://galmon.eu/.

The wonderful animation is brought to you by <marquee>

The success of webassembly has not been the "universal language for the web clients" we all expected.

But it has been "damn, that's a pretty good sandbox we all can compile to".

And of course, it means we can now have safe Python execution services from user input thanks to stuff like pyodide now.

It would be much, much better:

- Improved incentive for the IT and medias industry. Users and viewers are the customers again.

- Removal of the culture of normalized lying that infects everyone to the point people don't see it anymore.

- Natural selection of product by actually asking people for money. Can't pay 2 euros / month for facebook? It deserves to die.

- Redirection of resources from marketing to useful things. Billions going back to R&D, quality control, etc.

- Brand forced to rely on quality and word of mouth again. No more temporary product trick. No more "one month brand lifetime" hack. No more "PR will save this disaster".

- Improved skin in the game. And you will see less reputation-damaging behavior because of this. Think twice about doing A/B testing, fake sales, use too many notifications. You need those saavy power users to spread the word now.

- Disappearance of old and new artificial social norms solely created by marketing firms to sell stuff that parasites our reality. No need for everybody to look the same, no need for diamonds for engagement rings, no "whole white family having breakfirst in a big house and everything is clean and they are all happy and hot" to sell coffee, no "big red guy with a beard" created by coca cola.

- Getting back on specs. You can't sell perfume and cars on an vague idea anymore.

- Children won't get conditioned from a young age to want stuff they don't need, think ideas they don't really have, and adopt behaviors that are harmful for them just so that a marketer can get 3% more engagement.

- Creating massive volume of bad content will not be a successful strategies anymore, since it's not about displaying ads. So content quality go up.

- Streets get nicer, with no more ads display. Clothes as well, with no more big logo making you look like a billboard.

- No more ads in your mail box! And you can redirect the money from the gov marketing budget to actually find email spammers as well.

- Removal of a huge means of accumulation and centralization of power. Right now, it's pay to win, and the more money you have, the more you can run ads, the more you can sell. Which means a small local shop cannot easily compete with a big one. But without ads, it's actually close to its own clients, and has an advantage to get their attention organically.

- People get back some part of their attention span.

The benefits are not superficial; they are immense!

Ads are a plague on our societies.

Evolving as humans requires us to find a way to ban them.

I doubt I will see it in my lifestyle, but we need to get rid of this parasite if we want to go to the next level.

At the begining of the project, the runs are fast, but as the project gets bigger, the runs are slower:

- there are bigger contexts

- the test suite is much longer and slower

- you need to split worktree, resources (like db, ports) and sometimes containers to work in isolation

So having 10 workers will run for a long time. Which give plenty of time to write good spec.

You need good spec, so the llm produce good tests, so it can write good code to match these tests.

Having a very strong spec + test suite + quality gates (linter, type checkers, etc) is the only way to get good results from an LLM as the project become more complex.

Unlike a human, it's not very good at isolating complexity by itself, nor stopping and asking question in the face of ambiguity. So the guardrails are the only thing that keeps it on track.

And running a lot of guardrail takes time.

E.G: yesterday I had a big migration to do from HTMX to viewjs, I asked the LLM to produce screenshots of each state, and then do the migration in steps in a way that kept the screenshit 90% identical.

This way I knew it would not break the design.

But it's very long to run e2e tests + screenshot comparison every time you do a modification. Still faster than a human, but it gives plenty of time to talk to another llm.

Plus you can assign them very different task:

- One work on adding a new feature

- One improves the design

- One refactor part of the code (it's something you should do regularly, LLM produce tech debt quickly)

- One add more test to your test suite

- One is deploying on a new server

- One is analyzing the logs of your dev/test/prod server and tell you what's up

- One is cooking up a new logo for you and generating x versions at different resolutions.

Etc.

It's basically a small team at your disposal.

All web providers do this, not just google.

I have hosting that regularly shut down my servers based on legal demands from jurisdictions that should have no reach my service whatsoever, or on total bogus claim.

If I refuse to act, they shut me down. If I'm late in acting, they shut me down.

Zero check on the legitimacy on the claim, zero trust in my debunking the claim.

The reality is, it's not economically viable to do so. I'm not giving them enough money to be worth it. So as long as I'm a small actor, anything that looks remotely legit is just processed as-is with no recourse.

The entire world can basically impose its view on me as long as they find a convincing way to tell my hosting "you are at risk".

And it's not one single provider either. Most of them do that: domain name, vps hosts, proxies, caches, etc.

The system is broken.

Agreed, but then said optical markers regularly positioned in tunnels and a map of the tube is enough to position yourself already. That's likely how it works right now, and it's fine.

Not at all.

Some of those number are very important:

- Set membership check is 19.0 ns, list is 3.85 μs. Knowing what data structure to use for the job is paramount.

- Write 1KB file is 35.1 μs but 1MB file is only 207 μs. Knowing the implications of I/O trade off is essential.

- sum() 1,000 integers is only 1,900 ns: Knowing to leverage the stdlib makes all the difference compared to manual loop.

Etc.

A few years ago I did a Python rewrite of a big clients code base. They had a massive calculation process that took 6 servers 2 hours.

We got it down to 1 server, 10 minutes, and it was not even the goal of the mission, just the side effect of using Python correctly.

In the end, quadratic behavior is quadratic behavior.

If you really need it, they publish a dump regularly and you can query that.

For simple use cases, you have the web search, and you can curl it.

Besides, the chances that you get to that age, with his good health, on a diet of Coke and McDonald's when sitting all day are very low.

Much lower than the chance it's just marketing.

Does it have a similar system to Jetstream? If yes, does it address the reliability issues Jetstream has been criticized about lately?

> There needs to be an initial chapter for teaching Python in case the reader doesn't have the background.

I can't stand books that start with a half-baked Python tutorial. It's not only wasting the time of people who know, but worse, it's wasting the time of people who don't.

Because a one-chapter explanation on the topic is always going to be so superficial that the people who actually need it will never have the details they actually require to get up to speed. You will give them the illusion of understanding, only to let them hit a wall the first time they try any.

Before uv, install python package was a topic that required a lot more than a quick intro, explaining virtualenv, branching depending on OSes, even backtracking how to source the Python installer.

Better to just say "mastering this is a requirement prior reading the book" and be done with it.

There are full books on the topic that can actually help.

Replace this useless chapter with more content to which the book is actually dedicated.

While it's true that the exposure of top European firms can be often 50%+ of total revenue from U.S, that:

- Doesn't make them non viable without the American market, just less rich.

- Doesn't reflect the 5 to 10 times higher price Americans pay for the same drugs.

You can have a healthy industries with plenty of billions to be around and have decently priced drugs.

What you get in the US is uber profitable industries and people scrapping around.

It's a very charitable explanation.

My experience with the people around me who are in this situation is rather either:

- They just don't care. Society and others are not on their radar.

- They don't think it's that bad.

- They think it's not great, but the benefit is too good so they ignore the voice at the back of their head. Or they have a lifestyle and that takes priority.

- They think it's bad, but the friction to live according to their own moral view of the world is higher than their desire to adhere to such a moral view.

When I was 20, I declined interview offers from Facebook and Google. Huge opportunity cost. My friends looked at me like I was dumb.

I have friends regularly coming to me with ideas that are about spamming, selling personal data or basically fraud. They don't see a problem with it.

When you talk to people and say "advertising is basically normalized lying at the scale of the entire society", people just give you a blank stare.

There is no need to look for coercion every time you see something bad to explain it. The human population is diverse and they all draw the line of what's acceptable in different places.

It's not rocket science.

This is not like IT where the Americans are completely dominant and clearly superior.

The European pharma companies are doing more than fine, despite their main market being heavily regulated and price-controlled.

The less charitable explanation is that US companies want to charge outrageous prices, and the American system let them to, so they do it.

That's what the USA are: a machine to prioritize profits over people. Sometimes it turns out fine, like for the startup scene. Sometimes it's terrible, like when lives at stake.

Other explanations sound like heavy copium to me.

Can you tell us more? Espacially, how does they both fair with auth.

Why, because it's free?

At least one worker for each virtual cpu core you get for CPU. I got 16 on my laptop. My servers have much more.

If I have 64 cores, and 20 dependencies, I do want the 20 of them to be uncompressed in parallel. That's faster and if I'm installing something, I wanna prioritize that workload.

But it doesn't have to be 20. Even say 5 with queues, that's 100ms. It adds up.

And kill many apps, maybe even OSes.

When most of what a user can do can be done from one single UI, the low friction will win.

And since all the data must be sent to the service, and that a super intelligent AI analysis all this data, the spying that is already considered outrageous today will reach unprecedented level.

Now, associate that with the fact the last year people in charge of said systems kissed the ring of the power that be in the most disgusting way. Add what we learned about surveillance from 3 letters agency.

You get your dystopia. It's not an if now. It's a when.

We need to solve that problem now. Once we hit it, we will lose the ability to solve it.

And I'm not sure where you could go on earth to escape it.

The golden rule to understand the success of uv is to remind yourself how big and diverse the python community is. Your context is only a tiny fraction of the contexts in which python is going to be executed.

E.G: if you compare it to your machine, it's a different thing that if you compare it to a locked down corporate machines.

I have clients that have Python setup so bad installing all deps for a project takes... 18 minutes. Those are not crazy projects either. It's just the context that is bad. And you won't be able to change the context. But we are in talk to change the package manager to uv.

There are so many different setups that are different than yours. If you are a professional trainer, and you get a new group every week, having 12 people installing their env in a blink is a win. If you are a researcher and you want to download the top 100 pypi packages and attempt to install them, speed is a bliss. If you are a blogger and try a lot of new stuff for an article, it's great. If you are working at repl.io and you get millions of venv created every day, boy does that matter. If you are sysadmin in charge of deploying kub pods, you might be looking at serious savings. Etc.

Speed affects many things:

- CI runs

- AI iterations

- docker builds

- isolated builds over multiple versions of python

But it also unlocks some use cases.

E.G:

- uvx is great only because uv is fast. Because uv calls are virtually instants, using uvx feels like magic.

- "uv run --with" exist only because overlaying a new venv on top of the other is basically free. And it's a killer feature.

- You never create lock files in uv. Because the operation is transparently done in the background since it's so fast. I can't recall the last time I ran uv sync. Because uv run automatically call it, since it's so fast you don't notice. So you just skip the middle man and go straight to coding.

I was a big proponent of "speed is not that important". Until I got speed.

And then I realized I missed a lot, because they are things you just can't do if you are slow.

Without the sci-fi, if you take people with 10 to 12 kids, you have great accidental, natural, objective experiments here.

You can study those kids and compare them to the reported lifestyle of the parents at the time before their conception.

For the latter point, you are blinded by your own competence.

Bootstrapping a clean python env is the single biggest problem for people that are not daily coding in python.

That's half of the community in the python world.

When you write sqla that's not obvious, because you know a lot. But for the average user, uv was a savior.

I wrote a pretty long article on that here:

https://www.bitecode.dev/p/why-not-tell-people-to-simply-use

We also discuss it with brett cannon there:

https://www.bitecode.dev/p/brett-cannon-on-python-humans-and

But the most convincing argument is to teach python to kids, accountants, mathematicians, java coders and sysadmin.

After 20 years of doing that, I saw the same problems again and again.

And then uv arrived. And they disapeared for those people.

Real thread are very recent and didn't exist when uv was created. So you needed multiprocesses.

HTTP range strikes again.

As for 20 ms, if you deal with 20 dependencies in parallel, that's 400ms just to start working.

Shaving half a second on many things make things fast.

Althought as we saw with zeeek in the other comment, you likely don't need multiprocessing since the network stack and unzip in the stdlib release the gil.

Threads are cheaper.

Maybe if you'd bundle pubgrub as a compiled extension, you coukd get pretty close to uv's perf.