I've found that the guardrails of a strong, expressive type system are amazing for LLMs, especially if you don't use the top-of-the-line models but stick to the cheaper options. Agents need feedback to do their magic, and the type system is great for that.
But on the other hand, the compile time of Rust is really counterproductive. On large, established projects, most prompts I write now spend more time compiling on my machine than they spend outputting tokens. In a way this is great because the tokens are the expensive part, but it does mean that when faster LLMs will come, they will not meaningfully improve iteration speed for me.
I wonder how much of the compile time of Rust is inherent to the type system. There might be room for a language with slower runtime speed (GC?), but as good of a type system as Rust, so long as compile times are much faster. Switching languages has never been easier, anyone have any suggestions? IMO hard requirements are algebraic types and error handling based on them.
Compile times in Rust are partly the amount of analysis that occurs, partly that it uses LLVM which is optimized for creating fast code at runtime but not necessarily fast-compiling code, and partly the fact that the Rust compiler is inefficient and does the same work twice or recompiles things it doesn’t need to.
But you can speed things up a lot by organizing your project into separate crates (which are compiled in parallel) and tweaking compiler flags. I speed up a large project by 7x this way.
Also, if you’re using fat LTO in release builds, switch to thin. It’s almost as fast at runtime and much much faster to compile.
Even incremental builds can be slow depending on eg. what macros you use. For example, i had bad surprises with askama which is a delight in most cases, but really makes compilation slower as you add more templates. On a project with ~20 templates, incremental build in debug mode now takes ~40s on a very fast machine.
I love python for some stuff, but i definitely would not say it has an expressive type system. Enums are a second-class citizen, and typed dicts are definitely not as convenient as i would like. And to my knowledge, type checkers don't support proper exception catching rules; rust also has no guarantee that a function won't panic, but usage of Result type makes it less of a problem (because panic is more or less exclusively for unrecoverable invariant violations), and there's ecosystem tools to make sure you don't ever panic.
If by enums you mean sum-type ADTs (like in Rust), then Python is certainly quite expressive - it has union types, which can represent polymorphic variants - those are slightly more expressive than pure Rust-style ADTs since you can arbitrarily subset or extend the enum cases.
@dataclass @final class CaseA[T]:
field: T
type MyEnum[T] = CaseA[T] | CaseB
This also gets exhaustiveness checking in `match` statements (depending on the type checker). Overall, enums have a similar style to Scala and Java >=21 (mixing OO + ADT). I guess syntactically it can be slightly verbose depending on the exact situation...
I wouldn't call them second class, but yeah, not a lot of existing libraries use this style.
Typed dicts (with the latest PEPs) are an improvement over any other language besides TypeScript. Yes, in TS, certainly `Partial` / `Pick` / `Omit` and intersection types make modeling the web API swamp easier, and that's one place TS is superior to anything else.
Python does have the Type Manipulation PEP 827 [1] out to give it similar powers to TS, but I feel that's unlikely to be implemented soon / as-is.
Having an effect system for exceptions would be nice indeed. That's actually something I'm looking into (having an "allowed exceptions" annotation for functions and then checking it at test-time via failure injection and possibly in type checkers).
Auditing Rust is much easier and faster than either Go or Python. They both contain a lot of footguns that are not always immediately apparent from visible code. Rust is much more explicit.
This is assuming equal familiarity with all languages but I presume this comment is more referring to talent pools & experience. A good engineer can traverse & review many languages but most are quite restricted in the scope of what they can easily read - they miss a footgun or two in python but they're not grokking any of the rust whatsoever.
I'm not smart enough to know why; I do know that 27B is greater for short/interactive on blackwell, but the intellgence leap of the MoE in Qwen3.8-Flash-Next is quite remarkable.
I'm pretty convinced the pathway to local models will be MoE, especially if they can find a way to keep tweasing out things like PLE into the slow bandwidth lanes.
The Taalas architecture makes loading weights free, but they basically has to pay the same silicon for every weight, whether it's used or not. MoE models are more efficient than dense models per weight you load, but less efficient per weight you have to store.
MoE models are the path to local models with traditional system architectures, but they are antithetical to what Taalas was doing. If you spent all the money to etch 125B weights into silicon, you'd want to activate them all for each token, instead of only touching 6B. You cannot match the 125B sparse model with a 27B dense one, but you might be able to match it with a 60B or so one.
Yes, and we are already accounting for it. The objects as seen by us are actually very deep in infrared, when you correct for the redshift to match the key absorbtion lines of hydrogen, they still remain very red.
Appreciated. May I ask regarding the determination of the magnitude of correction to apply? Is it a case-to-case basis? In other words, is it very sensitive to the distance assumped for the LRDs?
The light curve is not smooth, there is a clear spectrum caused by absorption lines. You find the pattern in the lines that you know to be hydrogen, and measure how much redder it is than it would be without redshift.
In SSME, most of the LOX never goes through a preburner.
The SSME uses the same kind of fuel-rich combustion chambers for both preburners. This presents a problem for the oxidizer side because any leaking along the shaft between ox pump and turbine in either direction would be catastrophic. This is resolved by an extremely expensive and complex multi-stage helium-purged rotating seal.
One of the cool parts about most FFSC designs, and the raptor in particular, is that they can afford slight leaking from high pressure to low pressure through any seal in the system and it's broadly safe, and only marginally reduces performance. This allows them to be made much more cheaply.
I'm pretty sure that the heat exchanger is going to end up being one part they have to put back in. Pushing CO2 and H2O (both ices at prop temp) into the tanks just seems so ill-advised to me. The amounts of contamination are small, but there are just so many different ways that can go wrong.
> You can do that with backprop too. Nothing says you can't inference on a set of weights at the same time as you produce an updated copy from them.
Nothing but economics.
Inference requires dramatically more memory, meaning it gets radically more expensive, if you are doing backprop alongside. This is why it is not done, despite the obvious advantages. If this doesn't require storing as much data for updates, it might make such systems more feasible.
I have clearly communicated the constraints of use on my site using robots.txt, which is the established standard for communicating things like these. You are expected to fetch it and figure it out. It is not necessary to build walls and lock doors when a no trespassing sign is clearly visible.
Seriously, though, making robots.txt have the weight of law would be a massive improvement for the ecosystem in general.
But on the other hand, the compile time of Rust is really counterproductive. On large, established projects, most prompts I write now spend more time compiling on my machine than they spend outputting tokens. In a way this is great because the tokens are the expensive part, but it does mean that when faster LLMs will come, they will not meaningfully improve iteration speed for me.
I wonder how much of the compile time of Rust is inherent to the type system. There might be room for a language with slower runtime speed (GC?), but as good of a type system as Rust, so long as compile times are much faster. Switching languages has never been easier, anyone have any suggestions? IMO hard requirements are algebraic types and error handling based on them.
reply