"cargo check" is fast and it's enough for the AI to know the code is correct.

I would argue that because Rust is so strict having the agent compile and run tests on every iterations is actually less needed then in other languages.

I program mostly in python but I keep my projects strictly typed with basedpyright and it greatly reduced the amount of errors the agent makes because it can get immediate feedback it has done something stupid.

Of course you still need to review the code because it doesn't solve logic bugs.

cargo check is faster; it's not fast

With DSC it can drive even 8k@120Hz.

Yes, but can you call a monitor that relies on lossy compression to display in its native resolution professional?

It's not "mildly annoying".

I don't enable strict mode on multiple projects because people don't want to type anything outside of function signatures.

Inferring the type from the first use is 100% the correct choice because this is what users want 99% of the time, for the rest you can provide type information.

Annotating empty collections is one of the few places you need to annotate outside function signatures. It's not a big deal. It doesn't happen that often.

And, when it does, you can just put them when the empty container is assigned:

    things: set[tuple[str, str, int]] = set()
    users: list[User] = []

Many people don't seem to know this exists.

Yes, that's what I was referring to. I get it that Pyrefly wanted to advertise their approach here, but it's weird that they didn't at least acknowledge this. It's what I use because it works on every type check, and I don't need to rely on their particular implementation for this.

In fact, I recently migrated a project from Pyright to Pyrefly for performance reasons, and there was very little I had to change between. The most annoying thing was Pyrefly's lack of exhaustive pattern matching for StrEnum and Literal[...]

It's acknowledged at the end of the "infer any" strategy, but perhaps worded poorly.

> To improve type safety in these situations, type checkers that infer Any for empty containers can choose to generate extra type errors that warn the user about the insertion of an Any type. While this can reduce false negatives, it burdens developers by forcing them to explicitly annotate every empty container in order to silence the warnings.

ie: "type checkers that don't infer container types can emit an error and require users to annotate"

I missed that. At least pyright will only emit an error if `typeCheckingMode` is strict (which forbids `Unknown`). It will happily treat `Unknown` as `Any` in basic mode.

1. He left before Rust stopped being experimental.

2. Maintainers come and go all the time, this is how open source works.

3. The only reason Phoronix reports on this is because anytime they mention Rust it attracts rage bait clicks, for example, your comment.

Well at least one, because this one didn't happen.

https://www.cnbc.com/video/2025/12/03/microsoft-have-not-low...

Is "Microsoft Lowers AI Software Growth Targets as Customers Resist Newer Products" really "way different" than sales quotas? Or more to the point, a statement from Microsoft PR spinning it as "growth targets" doesn't prove they haven't also lowered sales quotas in some divisions.

Even if the Microsoft spokesperson is being completely honest, lower growth targets is still evidence of weakness in the AI bubble.

The llama.cpp issues are strange.

There are official benchmarks of the Spark running multiple models just fine on llama.cpp

https://github.com/ggml-org/llama.cpp/discussions/16578

There wasn't any instructions how the author got ollama/llama.cpp, could possibly be something nvidia shipped with the DGX Spark and is an old version?

Llama.cpp main branch doesn't run on Orins so it's actually weird that it does run on the Spark.

Cool I’ll have a look. All reflections I made were first pass stuff.

hehe, I see what you did there.

it is amusing to use AI to write that...

No it isn't.

They just use an SMS code instead which is not secure at all.

choosing a wrong alternative does not make mandating spyphones good.

why not distribute hw tokens for purposes like this? it has the least flaws IMO.

Yeah I have a similar experience with ty.

Looks like none of these new type checkers are ready yet.

Ty has autocomplete for imports, but it's hidden behind a toggle right now. They are still working on it. They index all the modules and functions, so you can just type the function name and it will suggest the correct import and insert it.

What do you expect AMD to do about gaming on Linux? Port all games to Linux or something?

The only thing they can do is to provide drivers which they do.

OP talked about LLMs, not gaming. It's a different software stack.