cornholio

You can have a universal variable length field, for example 2 bytes for strings < 32768, then four bytes, 8 bytes etc. On the critical short string path, it costs just a single bit test. The glyph vs byte issues need to be dealt with in both formats.

The subdivision issue is a good perspective, but i would argue the performance impact of cloning substrings is dwarfed by the redundant full string reads to find length.

The point is that knowing what you don't know allows you to hedge your bets on events far into the future; my child will need to become productive 20 years from now and maintain it for 40-50 years. So, it's a bit like trying to educate a kid born in the 60s for the web era, you can't and you shouldn't even try.

What you can do though, is to offer them broad exposure to things that are interesting to them and their generation; my eastern block clone of the 8bit/48KB Spectrum computer didn't really help me excel at math, reading or history, nor was it to be the future of technology, but it did change my life significantly by letting me understand and relate to people that I couldn't otherwise have business dealings decades later.

It seems imprudent to cut children off from futuristic technology just because of a moral panic that it causes brain rot. Unless we know it's soma, a drug so powerful that it subdues volition and curtails intellectual development; we don't.

The counterargument is that kids will live in a world different from our own.

For example, in many countries children lost the ability to write cursive; that used to be a critical skill comparable to literacy itself. But in our current society, that's no longer the case and you can be very successful without it, but there are other skills, such as using technology, that became critical.

Any definitive claim to know what are the right things kids should learn in a moment of rapid technological shift is probably garbage and just a projection of our own biases.

> rewriting a big widely used project in a stricter language is always a good thing

Always might be a too strong word. Rust is, by design, a language with low development velocity.

So you risk: 1. ossification of the current architecture and deferment of important features; or 2. reliance on AI coding to recover velocity.

Maybe for some 2 does not look like a risk, but I think it's too early to call. We have yet to see the effects of extensively using these tools on large scale projects, for years and decades.

If radiator temperature is critical you can just run a heat pump to boost it. Modern heat pumps can get pretty close to the Carnot limit for the temperature interval, for example a pump cooling to 300K and dumping out heat at 400K (125°C) will have a theoretical COP limit of 4 and a practical limit of 2.5-3.

That means that for every 3 units of heat your chips emit, you will use a 4th unit to spin the pump. If your panels generate 150kW, you will only have 113kW available for compute and the rest is cooling. Radiators will more than halve vs 340K operation, so it's net beneficial.

It's all a giant techno-economic optimization problem: the extra mass of solar panels you need vs saved radiators vs mass of the pump, the die temperatures you achieve and corresponding performance, durability and chip price point etc.

I'm not sure they can actually respect that 30 days absolute commitment. Let's say some internal tool flags a suspect conversation, it bubbles up and a human operator reads it and it looks like evidence of a crime. Then, that employee is legally bound in many jurisdictions to prevent the destruction of that piece of evidence.

It's one thing to commit to a "everything is deleted when you press delete" automatic policy. It's quite another to say "we'll keep some stuff for up to 30 days, look inside it for any malfeasance, then pinky promise we'll delete it".

I'm not entirely sure how that dismisses the CEO's putative argument: they go big on AI precisely because shipping end-to-end is hard, so they think they shouldn't waste resources on tasks that can be automated.

The structure of a good argument would be something like: certain tasks are fundamentally human and impossible to automate (which and why?) and by pushing AI use beyond what is optimal you are actually hurting your employees ability to do those hard parts.

A weaker but still useful argument is that most everything can probably be automated, but frontier models aren't there yet.

Focusing on pure energy efficiency might be missing the point of economic efficiency.

An RO desalination plant needs electric energy to drive the pumps, which might be generated by panels which are 15-20% efficient. So, if you can have cheap thermal desalination panels, they come out ahead even if 6x less energy eficient, you avoid the whole expensive and fragile desalination plant and you gain a low skill, distributed setup.

The LVCVA is a public authority and the Loop contract had substantial penalties in place, about 30% of the total ~$50 mil amount, tied to various tiers of service the system needed to hit. So right off the bat not only do you have good financial incentives for a good process, but strong legal risk and public scrutiny if things go bad. While the test was not public (for these very reasons), it was attended by auditors from BDO LLP - LVCVA's long standing auditor (and not one hired for the occasion by BoringCo).

The accounting company affirmed the test results, CFO Ed Finger told the board that the auditors observed 157 unique rides and there were no negative findings. These are all public records and board minutes anyone can request and consult.

Essentially, according to what was reported in the media, they had the few hundred volunteers board packed Teslas (3 pax + driver), ride the system, disembark and take another ride, while remaining within the station limits.

I wouldn't call the 4400pphpd result an "extrapolation" - it's a real, instantaneous capacity number once the system reaches steady state, just like you don't have to drive for an entire hour to express your speed in km/h or mi/h.

The figure is of course not indicative for the real rush hour capacity of the station infrastructure, especially the underground stations that have escalators etc., when they are packed with disoriented tourists carrying luggage and not necessarily making an effort to move fast and hit good numbers.

Hence, I think my original point stands firm, Boring has demonstrated vehicle rates that can beat light rail, the basic premise of cheap narrow tunnels is sound. To actually demonstrate competitive numbers in real life scenarios will require larger vehicles, better organized ingress flows and procedures, more and perhaps larger stations etc. But these are all tweakable factors depending on actual demand at a specific station, they can run a mix of vehicles and expand infra where it makes financial sense, but only IF the tunnels have good vehicle rates, ie. no more than seconds of headway with extraordinarily rare in-tunnel break downs.

Hitting almost 4000 was a requirement of the LVCC bid and they actually hit 4400.

This is all public info available from unbiased sources; preferring schadenfreude and rage inducing bait is, of course, a choice you are entitled to.

Loop demonstrated 4500 people per hour with Teslas with human drivers. Hence, the assertion that it can be competitive with most light rail systems is entirely reasonable, assuming, as I said, "they get adequate, automated, larger vehicles". For example, the much hyped but so elusive Robovans.

The largest subways in the world can reach 80,000 pphpd (crush load) but the vast majority of US systems are under 20k, and those are numbers Loop can likely reach with larger vehicles:

https://www.reddit.com/r/BoringCompany/comments/s4r6l4/chart...

Only a handful of the largest US systems really hit the capacities the only heavy rail subways can support, and they do so with eye watering costs, see the famous $2.5 billion mile in New York's Second Avenue extension. So a $10-20mil/mile system with 1/4-1/2 the capacity of a full subway could, if demonstrated, completely change the game in many cities.

It's interesting how Loop criticism has evolved over the years: initially, it was claimed Boring Co has no chance of duplicating or significantly improving on the speed and cost of state of the art used by tunneling companies, or that the entire concept is fundamentally impossible or cost-prohibitive to build. After building the first stations, it changed to capacity concerns or that it's not Hyperloop, an completely unrelated high speed concept.

Now, after Loop demonstrated vehicle rates that would beat most light rail projects and many subway systems too - assuming they get adequate automated larger vehicles - the criticism seems to be that it's not build out yet to a significant size, or that it has minor usability quirks.

I sure hope these people understand just how foolish that position risks to become if Boring Co continues good execution and build outs the entire system as planed.

> the great problem of our age is deciding who controls technology

Isn't that just an instance of the political problem for all ages: who controls what, who gets to rule and who obeys, the fundamental power struggle apparent in all human history.

Extend the definition of technology to the broadest sense, from the material that allow us control over the physical reality: steam, computing; to the organizational, that enable collective human action: states, factories and assembly lines; and the ideological, that legitimize certain power arrangements: religion, nationalism, democracy, human rights etc.

A feudal lord's power rested on land (material), the manorial system (organizational), and the divine right of kings or religious sanction (ideological). Even if peasant revolts happen from time to time, the arrangement is stable because the peasantry accept it as legitimate and have no economic alternative; so even when revolting they cannot imagine a different political order. Technological (broad) leaps like the Enlightenment and the Industrial Revolution change the political possibility space so arrangements like feudalism are no longer stable, but others like capitalism, liberal democracy etc. become possible.

Political actors observe these technological shifts and struggle for control, relevance and power. The old elites are contested by the new kids on the block, wielding the new technologies: the aristocrat by the bourgeois, pastoralist tribes by agricultural states, autocrats stuck with traditional propaganda by the kids with smartphones and social media.

The present struggle around AI is therefore to be expected; what's more interesting is the type of political possibility space it opens up: is it one where having the bulk of society educated and productive, capable of running the machines is the key factor pushing the country forward in the international technological competition, like we've see post-war, forcing the national elites to cater to their needs, invest in their populations and broadly share the economic output and the political power? Or is it more likely one where the key competitive factor is the size of your datacenters and automated defense factories, where the bulk of people are irrelevant for the architecture of power?

Because if it's the latter, the entire idea that democracy will somehow manage to survive and influence who gets what becomes problematic. In the new technological-historical space, democracy becomes structurally unfavorable and thus, unlikely to persist long term.

That's a JIT. Yes, you can do all sorts of optimizations in a JIT, because you do it at runtime using runtime information, and always keeping an escape hatch, so the static code bails when invoked with data it was not compiled to handle. This kind of hatch is used here with <any> wrapping.

JIT is a technique to accelerate dynamic languages at runtime to near machine performance while keeping dynamic ergonomics; but it can't transcend the AOT / runtime wall.

Typescript is a dynamic language. Without changing the language, there is fundamentaly no way to resolve at compile time decisions that can be made only at runtime (ie, they are data driven). Monomorphization helps pin down (some) dynamic types but the fundamental problem remains.

But why would you wrap some proprietary solution around your neck instead of rolling your own custom solution or extending some open source?

The answer for most things pertaining to encloudification seems to be "because it's easy and we are already using cloud provider X". Death by a thousand clickops.

If I understood correctly, the model will get it right because it knows when it isn't right.

As someone who's vibecoding my own self-hosted language (via a typescript to c++ transpiler and bootstrap), I can tell you mainline commercial models like Opus 4.7 aren't quite there yet. I'm getting 10KB source files balloon into 80MB outputs for now.

The main problem is that the the problem space is vast and highly interconnected, the LLM needs to reason about the entire language every time it suggest an architectural change, but it can't, so it suggests local changes that make sense to me - a language hobbyist - then runs into much more difficult problems down the road.

Maybe Mythos with a lot of (competent) human hand-holding and pre-design can do it.

Money laundering is the action of obfuscating the origin of criminal proceeds; victims or clients of criminals do not generally commit money laundering, for example buying drugs is not a form of AML violation regardless of the legality of the purchase itself or the fact that the funds will later be laundered by the traffickers.

KYC is a tool to prevent money laundry and it's typically an obligation of financial institutions. Sending money to an anonymous (to you) recipient is generally not a KYC violation if you are not in the money transmitting business and you aren't doing the payment on behalf of someone else.

There are infinite shades of gray in this topic, of course, but I can't see AML being relevant in this particular case.

I used to do the CodeWarrior installer for Freescale/NXP embedded product lines in the 2010s and InstallShield became completely unworkable as a tool for a massive dev tool. Even today, a 400MB+ installer is difficult, let alone in the age of mechanical HDDs.

I had to choose between NSIS and Wix - and while native installer formats were clearly the future even back then, the performance and compression advantages of NSIS were so great that it was a clear choice. Solid LZMA was simply impossible to beat by any deflate/zlib/mszip oriented tool.

The joy of the dev team was palpable, the new installer was about 60% smaller and installed in one third the time.

It's a joke. But you got it all wrong, it's not praise + sarcasm, it's double sarcasm.

I agree, Python allows anyone to write bad code, but makes up for it by running the code slow enough that it can't do real damage.

> Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languages might allow.

I question this. Yes, strong enforcement of invariants at compile time helps the LLM generate functional code since it gets rapid feedback and retraces as opposed to generating buggy code that fails at runtime in edge cases.

On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code. If the initial architecture is bad or lacking, growing the code base incrementally as LLMs typically do will tend towards spaghettification. So I fear a program that compiles and even runs ok, but no longer human readable or maintainable.

It's a move to block competitor AI agents while securing access for your own, classic ladder kick. The market for autonomous agents providing services and doing online work will be gigantic so, unless you want your own bots locked out from ie properties guarded by Amazon, CloudFlare, Microsoft etc., you will need a bargaining chip.

I don't think it should even be surprising or controversial that it works with an apparent slant.

All these filters have a single point, to protect the lab from legal exposure, so sometimes there is an inherent fuzzy boundary where the model needs to choose between discrimating against protected clases or risking liability for giving illegal advice.

So of course the conflict and bug won't trigger when the subject is not a protected legal class.

On the other hand, allowing people to feed their sweet addictions only re-enforces and desensitizates them further. So while you are probably safe drinking ungodly amounts of aspartame water, you won't find equivalent substitutes for sugar in other foods and you might suffer rebound consumption there, perhaps to a much higher total caloric intake versus just drinking sugary water in moderation.

Another thing to watch out for is caffeine input which is often associated with sweetened drinks. Caffeine is a diuretic and you will see yourself drinking can after can of diet coke while not quite quenching your thirst or properly hydrating yourself. This is documented to lead to intense muscle pain and unexplained migraines for people who do physical work and abuse these types of drinks, and can't be good for your kidneys long term, even under the assumption that sweeteners are 100% safe.

Overall, just drink plenty of water and use everything else in moderation seems like a solid advice.

That sounds like a good reason to keep the exam model, since boys are already at a strong and widening educational disadvantage compared to girls.

All that kinetic energy needs to go somewhere. It's irrelevant if the asteroid burns up in the atmosphere or if trillions of tiny parachutes heat the atmosphere.

I guess you could devise some scheme where kinetic energy is shed or transformed into useful tasks; for example, delivering to Venus an amount of water similar to Earth requires an icy ball half the diameter of the Moon - and the kinetic energy of this mass traveling at 10km/s is about half of the energy required to spin up Venus to a 24h cycle. So some space elevator like contraptions could hypothetically catch the snowballs and lay them on the surface while at the same time spinning up the planet.

But if you have the required clarketech it's unclear why bother with planets instead of creating exponentially larger and better habitats.

Terraforming is an exceptionally energetic endeavor. Even if you had the perfect combination of icy asteroids with just the right amount of water, nitrogen, oxigen etc. and the means to hurl them towards Mars, this kinetic event would be so energetic that it would take centuries to millennia before the surface would cool to habitable temperatures. it's not physically possible to do it ex in the span of a human lifetime.

Ar the scale terraforming entails, the crust reactions with the new atmosphere are closer to a rounding error.

git is not a new idea, various features of git existed in various SCMs for decades. The distributed aspect existed in Bitkeeper too, for example.

But it took a big brain with a systemic view of the problem and solutions space to bring them all together - in a lighting fast implementation to boot.