So a lack of builds coupled with AI boom at the same time created a perfect storm with no new capacity coming online for years after demand rapidly escalated.

I used GPUI and the one-dark theme from Zed and it's super smooth, the code is super easy to understand and I love the way it looks.

Not quite as simple as the VB6 and forms apps of my youth but as a Rust dude I definitely grokked it easily and was surprised how much of it I was able to do myself once the agent had helped with wiring up the scaffold.

Poor correctness guarantees, especially w.r.t concurrency. Nil pointer. Why.

LLMs are like a magnifying function. Whatever you put in you get back 10x over.

In the case of Go, in goes verbosity, Nil pointers, poor concurrency and synchronisation primitives (or poor performance of the safe ones, leading to sync.Mutex everywhere anyway). Also Go prioritises local readability over global understandability which is a poor tradeoff for LLMs with limited context windows.

So the LLM generates absolutely monstrously huge amounts of very hard to review very likely incorrect code.

No thanks.

Rust > Go.

In goes powerful, terse type system. Strong correctness guarantees not just around memory and pointers but also data races. A tendency towards using the type system to model invariants instead of relying on procedural guards and runtime assertions etc. Producing denser code is an LLM feature, it increases context window efficiency. Similarily the typesystem takes something that the LLM can spend a bunch of thinking tokens on to create a powerful global constraint. This fixes the global reasoning/context problem by pushing it back onto the typesystem.

Depending on the quality of your robot you will get different quality of code out but the ceiling is much higher. With Go better robots don't help much, even the highest quality robots output insanely verbose Go. Sort of just like with people... sort of like the language was designed as a lowest common denominator tool...

For a seasoned Rust programmer the output probably won't be hard to review, it will be easy to look at the types and either say "yeah that should probably be correct" or "no robot, do better".

You simply can't actually review the output of the slop cannons with Go, there is too much, looking at a struct tells you almost nothing about how correct the thing likely is, etc. The tests don't help either because there is going to be 10x the usual amount of those too so trying to review those for correctness is the same Sisyphean endeavour.

In Afghanistan, there are some mountains, but they are in the middle. The Taliban fucked off into the mountains and they couldn't do jack.

Iran on the other hand is a plateau fortress lined by mountains on all (accessible to US/western allies) sides. A land invasion of Iran means no supply lines and no way out. The words "one does not simply" come to mind. It is essentially the ultimate meat grinder unless you can win decisively in days, which is impossible because the entire apparatus you are trying to destroy is distributed within aforementioned mountains and operates with decentralised/autonomous command that has been preparing for this exact eventuality (being invaded by an opponent with vastly more firepower and overwhelming air superiority) for the last 40 years. Not to mention absolute fucking hellscape it will be for troops on the ground with FPV drones and Shahed flying into clusters of US marines and being broadcast on Telegram.

A land invasion of Iran is empire suicide. You can't win, you can't go home and you are left with just pouring an infinite amount of resources and lives into the most asymmetric and geographically hostile theatre of all time.

The TLDR here is that Groq LPUs are completely deterministic hardware, including for floating point.

Disclaimer: Formerly of Groq, now of NVIDIA, still working on LPUs.

This is harder to do on other architectures that themselves aren't fully deterministic though.

Also entirely on STM32 now too which is rock solid and the easiest embedded programming has ever felt. probe-rs, defmt, embassy w/async HAL. Life is good man.

However if you are using a string inverter you will want to wash all the ones on the same string in one go if you can, you don't really want them generating different voltage or you will miss out on a lot of power.

Sandy has gone into it on various podcasts and mediums. It's pretty clear he doesn't consider Carmack responsible but rather someone he refuses to name (but is quite obviously Tim Willits) that caused pretty much all the problems.

My read is Carmack is saying he is sorry he lacked the awareness and experience to manage the people stuff.

He lost his dream team, I'm sure it's something he has thought about a lot.

I think the only real solution is to add increasingly strict guardrails that can be enforced with a combination of more AI agents and actual executable contracts. The other aspect is through using languages and tools that densify correctness. i.e languages like Rust that have very rich type system so both review and design can be focused on a small by volume slice which is the core types. The other main tools for densifying correctness are formal methods, (model checking, etc), fuzzing/property based testing and static analysis.

All of these tools are cheaper to use than they once were because of lot of the minutiae can be handled AI agents while core invariants can receive heavy human scrutiny.

IMO generative AI is here to stay in development so may as well get ahead of the game and start using these tools to try get the best out of it.

For higher level patterns again the APIs are the same so anything building on libibverbs or aforementioned ucx etc are pretty compatible from a high level ideas perspective. If you are new to RDMA in general definitely start with raw verbs instead of using abstractions like MPI if you really want to build a good intuition and then move to MPI once you understand what it is doing for you.

I would separate the knowledge into maybe 3 distinct buckets.

The baseline: device/host boundary, SIMT programming etc.

The intermediate: kernel architecture, CUDA graph vs persistent kernels, warp specialisation/divergence avoidance techniques etc.

The advanced: architecture specifics so tcgen05, TMA, SMEM/HBM, memory throughput vs compute biases in various arch impls., GEMM, FHMA, all the tricks that make modern fused kernels very fast. Also would bucket most GPU Direct RDMA/GPU NetIO/friends here too.

The baseline hasn't changed much and probably won't, the intermediate knowledge has also remained pretty reliably stable for ~10 years with only things like graphs changing stuff. Tile might become more relevant than it is today but for now CUDA, cuBLAS, friends are where it's worth investing knowledge.

You do want to use Rust with LLMs.

The reason you want it is simple, it's more constrained.

LLMs thrive on constraint and drown in freedom.

The further you can constraint the solution space the more likely you are to end up with a solution you like/is actually good.

Rust has several properties that make it really good for LLMs:

* Really robust type system that is also very expressive, if guided LLMs can implement most of the invariants in types which substantially increases the chances of success.

* Great compile time errors, the specificity and brevity (vs say C++ template expansion) means token efficient correction of syntax and/or borrow mistakes etc.

* Protection against subtle errors at compile time, namely data races and memory safety issues.

* Great corpus of well designed code and patterns, higher quality on average than some other ecosystems more favored by begineers/mass-market programming.

* Stdlib is strong, small-ish number of blessed crates.

* Context friendly, type signatures, errors, etc are all dense information.

* Also bias towards compile time checks means less runtime tests which means less toolcall time (and less tests needed overall) which in turn makes the process a ton faster.

I have been continually using Rust, Python and Kotlin since ~Jan this year and keeping track of my thoughts and I increasingly bias towards Rust now where I would have previously chosen Python or Kotlin instead just because I am lazy and I prefer the tool that the computer writes better so I have to write less lol.

1200 years is a serious timescale, I think humans generally struggle reasoning about long durations or very vast distances. Which leads to them instead postulating how all these other more present, more recent and nearer things can be to blame when what you really need to do is zoom out (in space and/or time).

It's always been poo, the YAML is bad, the reliability is bad and the cost is bad.

So there is really no redeeming features because even if you tout forge integration it's UI is, you guessed it, also bad.

Putting aside the anti-pattern of using vendor YAML for literally anything (please don't do that) you are distinctly better off with literally any other CI/orchestration service. Buildkite is good, dynamic pipeline = good, there are other good options. If you are a serious person you will find good things to use.

Getting back to vendor YAML, please just use a real build system instead. Define all the actual logic there with entry points/targets the YAML hits. Also generally make sure that you don't need the actual CI system to be up to do releases, deployments etc. A sufficiently elevated local user should be able to run the appropriate target with the appropriate credentials to get the job done in absence of said CI system.

Not to mention being able to quickly deliver counter-attacks to like for like infrastructure when theirs has been attacked. i.e the Ras Laffan counter punch after South Pars was attacked and the UAE aluminium plants after their steel mills were hit etc.

They have also already essentially taken AWS Bahrain permanently offline at this stage.

So they are certainly capable of it but simply hitting the target removes the leverage of using it in a negotiation. If it's already gone you can't say "we won't hit X if you agree to terms Y before time Z".

Now that a war is started it has to be finished or the GCC is left far worse off with Iran in a much stronger strategic position in the region despite a decimated military.