unjuno

thank you

LLM pretraining might be viewed as learning useful state representations from sequences, rather than having humans explicitly design the states in advance.

In many conventional software systems, we define states and transitions ourselves: idle, sending, completed, error, and so on. LLM pretraining works differently: the model learns from large numbers of sequences to predict what is likely to come next.

I don’t mean that an LLM literally constructs discrete internal states. Rather, it learns latent representations of context that are useful for prediction. In that sense, these representations might be thought of as a kind of learned state.

This seems closely related to abstraction. Abstraction is not simply throwing information away, but abstracting away differences that are irrelevant to prediction while preserving those that matter.

Two sequences may look very different on the surface, yet rely on similar underlying features to predict what comes next. Even a rare feature should be preserved if it changes the prediction.

From this perspective, pretraining can be seen as a form of useful compression: learning representations that preserve what matters for prediction while abstracting away what does not.

How far can abstraction, compression, and prediction be understood as different aspects of the same process?

By “world model,” I mean a model continuously updated from experimental or sensor data, not just an LLM trained on text.

The problem with circular transactions is that they can make companies look healthier than they really are, distort investment decisions, and cause widespread damage when the cycle breaks.

The most interesting part of this to me is not “Rust to C” by itself, but the fact that it widens the pool of people who can help debug portability problems.

There are relatively few people who understand Rust’s compiler internals, LLVM backends, and obscure target support deeply. But there are many engineers who understand C compilers, ABIs, linkers, makefiles, cross-compilation, old operating systems, and weird platform-specific compiler behavior.

If Rust can be lowered into target-specific C, then some problems stop being exclusively “Rust compiler problems” and also become C toolchain problems. That means more people can inspect the generated C, build failures, linker errors, ABI mismatches, and compiler-specific behavior.

C is obviously not a magic portability layer. ABI details, integer widths, alignment, TLS, aliasing, and undefined behavior still matter. But as an ecosystem boundary, C gives many more engineers a way to participate in debugging and porting work.

I think that social/maintenance aspect may be more important than the language translation itself.