It could probably be improved, but HTTP does support this already:

https://datatracker.ietf.org/doc/html/rfc2616#section-14.15

And since this proposed protocol operates over TCP, there's relatively little that can be done to achieve the performance goals vs what you can already do with HTTP.

And because "everything" already speaks HTTP, you can get pretty close to max performance just via client side intelligence talking to existing backend infrastructure, so there's no need to try to get people to adopt a new protocol. Modern CDNs have gobs of endpoints worldwide.

A relatively simple client can do enough range requests in parallel to saturate typical last-mile pipes, and more intelligent clients can do fancy things to get max performance.

For example, some clients will do range requests against all IPs returned from DNS resolution to detect which servers are "closer" or less busy, and for really large downloads, they'll repeat this throughout the download to constantly meander towards the fastest sources. Another variation (which might be less common these days), is if the initial response is a redirect, it may imply redirects are being used as a load distribution mechanism, so again clients can ask again throughout the download to see if a different set of servers gets offered up as potentially faster sources. Again, all of this works today with plain old HTTP.

It's not uncommon now for popular professional streamers to get early access to new features/modes because the game companies know that those players can help build or retain the player base.

But taking a step back, for fast games (like an FPS), the latency requirements drive you to send semi-secret info to the client (like the positions of other players), and so that's where things start to break down. But the traffic in the other direction is a problem too, as you have all of the scenarios in which the messages to the server (e.g. aim info, timing of weapon of firing) can be spoofed or engineered.

The motivation for the client-side anti-cheat systems is to extend as far as possible the envelope of what is considered trustworthy - i.e. if they can't solve the latency problem, then they try to make the client more trusted.

It's impossible to completely solve the problem, so it's about finding a solution that solves as much of the problem as possible. Unfortunately the main thing going for kernel anti-cheat is that most users don't care that they have to let someone root their machines to play a game, though the tide would likely turn if there were a high publicity exploit.

  - you are a tiny minority and not the target customer
  - online multiplayer games are an absurdly big business (i.e. there are huge incentives here)
  - no, you can't completely solve this server side
  - elite players are insanely good - they are by definition outliers, so looking for statistical outliers is not in itself a solution
  - game companies are highly incentivized to work with (or at least not antagonize) the elite players (so just throwing them in matches with cheaters is not a solution)
  - the stakes are high both for the devs and their users, so "pretty good" anti-cheat is usually insufficient

I hope to see more discussion on possible solutions and tradeoffs - this is a challenging technical problem whose solution (if there is one) is fairly valuable.

[edit: hopefully fixed the tone, per feedback]

As far as the results go, though, I don't see any realistic scenario where this is a net win vs a symlink. :)

My hope is one of the Next Big Things in programming languages is the widespread adoption of incremental typing systems.

So during the early stages of dev you get the productivity benefits of dynamic and loose/duck typing as much as you want, and then as the code matures - as the design firms up - you begin layering in the type information on different parts of the program (and hopefully the toolset gives you a jump start by suggesting a lot of this type info for you, or maybe you specify it only in places where the type info can't be deduced).

Then those parts of the program (and hopefully eventually the entire program) are strongly and statically typed, and you get all of the associated goodies.

NASA has involved the private sector for over half a century. Taking that out of the equation leaves you with SpaceX absolutely killing it and Boeing bumbling along despite getting bigger contracts from the government, so it's hard for me to draw this same conclusion.

> a benefactor with unbelievable wealth being able to hoard the best engineers

Hmm.. the implication here doesn't ring true at all. "Oh how I wish I could work at Boeing where all the real innovation happens, but here I am stuck at SpaceX due to these darn golden handcuffs". I hope SpaceX people get paid a lot, but I suspect the draw for most is what they are doing and the speed at which they are doing it.

https://www.youtube.com/watch?v=pPL7OZF1iI4

Agreed. Even today, for many people there is no fatal tension between science and religion (often in large part because they serve to answer different questions).

My personal rule of thumb is that if I see an apparent contradiction between religion and science, it just means I have an incorrect/incomplete understanding of some area of religion or science (or both).

Developer productivity.

> Maintainers seem happy to introduce breaking changes without major version bumps

Nah. Keep in mind that this is a PEP, not an announcement of what is going to happen, see also https://peps.python.org/pep-0313/ .