And this is exactly how

Just like a spontaneous, “natural and organic” continuation to the previous post (which implicitly confirm that it has properly captured at least some aspect of reality [as it is]).

I have had to delete some nice movies in order to download and try that over-hyped “5M downloads” Nvidia’s meme-model Nemotron-3-Nano-30B"

I have a small set of highly sophisticated prompts which I use to measure the apparent quality of a generated slop of the 4 major data-center-sized LLMs.

I used the same prompt to feed the Nemotron-3-Nano-30B.

This is what it produced (among other things):

3. Typestate (explicit state transitions)

// src/layer3/mod.rs – separate file `state.rs`
pub enum Connection {
    Closed,
    Open,
}
pub struct TcpSocket {
    // no public fields; only transitions are expressible via methods
}
impl TcpSocket {
    pub fn new() -> Self {
        Self { /* hidden impl */ } // starts closed
    }
    /// Consumes `self` and moves to the `Open` state.
    pub fn open(self) -> Self {
        // compile‑time guarantee: only `open` can be called on a closed socket
        Self {}
    }
    /// Consumes `self` and moves to the `Closed` state again.
    pub fn close(self) -> Self {
        Self {}
    }
    /// Can only be called when the socket is `Open`.
    pub fn write(self, _data: &[u8]) -> Self {
        Self {}
    }
}

Each method consumes self and returns a different type (or a different /carrier). The compiler prevents illegal calls such as write() on a closed socket./

There are some fact about this slop.

It has nothing to do with the actual Typestate pattern, which is [an implementation of] a type-level state machine with a bunch of “moving” transducers between distinct types, which represent all the possible states
This is exactly what people are calling a “hallucination” – it mentioned the enum, but failed to even use them – to write a set of parameterized types representing the different states.
Those without a proper education and actual understanding of the Typestate pattern would be misled into thinking that this is a correct implementation of the pattern (or at least a proper outline).
This is exactly the kind of slop which is being passed as “correct” by the LLMs to the unsuspecting users, who are not aware of the fact that they are being over-contently fed with an utter garbage.

Yes, it is a bit of a low blow to compare a “local” 30B model with the data-center monsters, but the point is not about the comparison, but the fact that it produced garbage which is being passed as “correct” code.

One more time – the code is outrageously wrong, even as an “outline”. It literally has nothing to do with a correct implementation of the Typestate pattern, which has a very different overall structure (of the algebraic data types involved) and, most importantly, the returned type must not the same one, which is the main reason behind the whole “pattern”. This is just bullshit

And this is your “state-of-the-art” LLM “understanding” by Nvidia with the “valuation” of almost 5 trillions.

Pay attention.

3. Typestate (explicit state transitions)#

3. Typestate (explicit state transitions)