Stories with Tag Types

• MichiganTypeScript: A WebAssembly runtime implemented in TypeScript types

  permalink

  Posted: 2025-02-26 16:26:18

  Verbose tl;dr

  MichiganTypeScript is a proof-of-concept project demonstrating a WebAssembly runtime implemented entirely within TypeScript's type system. It doesn't actually execute WebAssembly code, but instead uses advanced type-level programming techniques to simulate its execution. By representing WebAssembly instructions and memory as types, and leveraging TypeScript's type inference and checking capabilities, the project can statically verify the behavior of a given WebAssembly program. This effectively transforms TypeScript's type checker into an interpreter, showcasing the power and flexibility of its type system, albeit in a non-practical, purely theoretical manner.

  The GitHub repository "MichiganTypeScript/typescript-types-only-wasm-runtime," also known as MichiganTypeScript, presents a novel approach to WebAssembly (Wasm) runtime implementation. Instead of using traditional programming languages like C++, Rust, or JavaScript, this project leverages the TypeScript type system itself to emulate a Wasm runtime environment entirely within the type checker. This means no actual JavaScript code is generated or executed; the entire runtime logic, including loading Wasm modules, executing instructions, managing memory, and handling system calls, is encoded and enforced through complex type definitions and manipulations.

  MichiganTypeScript achieves this by representing Wasm concepts as TypeScript types. For example, Wasm instructions are modeled as type-level functions, memory is represented using tuples, and the stack is simulated using recursive type definitions. The execution of a Wasm program within this system involves a series of intricate type transformations, where the TypeScript compiler effectively "steps through" the program by applying type-level functions that correspond to Wasm instructions. The compiler's type checking mechanism verifies that these transformations are valid according to the defined Wasm semantics.

  The primary objective of this project is not to create a practical, performant Wasm runtime for real-world applications. Instead, it serves as an exploration of the boundaries of TypeScript's type system and a demonstration of its expressive power. By implementing a complex system like a Wasm runtime purely within the type system, the project showcases the potential of using types for advanced static analysis, program verification, and potentially even code generation in the future. While currently limited in terms of the Wasm features it supports and the size of programs it can handle, MichiganTypeScript represents a compelling experiment in pushing the limits of type-driven development. The project highlights the increasing sophistication of type systems in modern programming languages and opens up new avenues for research into leveraging them for tasks traditionally performed by runtime environments.

  • TypeScript
  • WebAssembly
  • Wasm
  • Runtime
  • Type System
  • Types
  • compiler
  • virtual machine
  • javascript
  • Web Development
  • Programming Languages
  • Static Typing
  • MichiganTypeScript

  Summary of Comments ( 5 )
  https://news.ycombinator.com/item?id=43185174

  Verbose tl;dr

  Hacker News users discussed the cleverness of using TypeScript's type system for computation, with several expressing fascination and calling it "amazing" or "brilliant." Some debated the practical applications, acknowledging its limitations while appreciating it as a demonstration of the type system's power. Concerns were raised about debugging complexity and the impracticality for larger programs. Others drew parallels to other Turing-complete type systems and pondered the potential for generating optimized WASM code from such TypeScript code. A few commenters pointed out the project's connection to the "ts-sql" project and speculated about leveraging similar techniques for compile-time query validation and optimization. Several users also highlighted the educational value of the project, showcasing the unexpected capabilities of TypeScript's type system.

  The Hacker News post titled "MichiganTypeScript: A WebAssembly runtime implemented in TypeScript types" sparked a discussion with several interesting comments.

  Many users expressed fascination and amusement at the project, highlighting the ingenuity and absurdity of implementing a Wasm runtime purely within TypeScript's type system. Some saw it as a clever demonstration of the power and flexibility of TypeScript's type system, pushing its boundaries beyond what might be considered practical. Others viewed it more as a playful experiment or a form of esoteric programming.

  One commenter questioned the practical implications of the project, wondering about its potential use cases beyond being a proof of concept. This sparked a small thread discussing the potential for verifying Wasm modules at compile time or exploring new possibilities in type-level computation. However, the general consensus seemed to be that the project's primary value lies in its demonstration of the theoretical possibilities, rather than immediate practical applications.

  Several users pointed out the similarities to other projects that explore the computational capabilities of type systems, particularly within languages like Idris and Haskell. This highlighted the connection between TypeScript's advanced type features and the concepts found in dependently-typed languages.

  There was also some discussion regarding the performance and scalability of such an approach. Some commenters expressed skepticism about the feasibility of using this for real-world Wasm execution, anticipating potential performance bottlenecks.

  A few users highlighted the educational value of the project, suggesting that it could be a useful tool for learning about both TypeScript's type system and the inner workings of Wasm.

  Finally, some comments simply expressed amazement and appreciation for the creativity and technical skill demonstrated by the project's creators. Phrases like "mind-blowing," "absolutely bonkers," and "amazingly pointless" were used to capture the general sentiment of bewildered admiration.

• TypeScript types can run DOOM [video]

  permalink

  Posted: 2025-02-26 15:05:02

  Verbose tl;dr

  This YouTube video demonstrates running a playable version of DOOM within a TypeScript type definition. By cleverly exploiting the TypeScript compiler's type system, particularly recursive types and conditional type inference, the creator encodes the game's logic and data, including map layout, enemy behavior, and rendering. The "game" runs entirely within the type checker, with output rendered as a string that visually represents the game state. This showcases the surprising computational power and complexity achievable within TypeScript's type system, though it's obviously not a practical way to develop games. Instead, it serves as a fascinating exploration of the boundaries of what can be accomplished with type-level programming.

  The YouTube video "TypeScript types can run DOOM [video]" demonstrates a highly unconventional and computationally intensive approach to implementing game logic. Instead of using traditional runtime code, the creator leverages the TypeScript type system to effectively emulate a simplified version of the classic game DOOM. This is achieved by encoding game state, map data, and game logic rules within complex, nested type definitions.

  The video showcases how TypeScript's type checker, during compilation, evaluates these intricate types. This evaluation process mimics the execution of the game logic. For instance, the type system determines the player's position, checks for collisions with walls based on the map data encoded within the types, and even simulates projectile movement and enemy interactions, all at compile time.

  Due to the inherent limitations of the type system, the resulting "game" is not visually rendered in a traditional sense. Instead, the output of this compile-time computation is represented abstractly through type errors. These carefully crafted type errors are designed to convey information about the game's state. For example, a specific type error might indicate that the player has encountered a wall, picked up an item, or defeated an enemy.

  The creator demonstrates the process of constructing these types, explaining the underlying principles and the logic behind their design. They show how different aspects of the game, such as movement, collision detection, and even basic enemy AI, are translated into type-level computations. This involves using advanced TypeScript features, like conditional types, mapped types, and recursive types, to represent game logic within the confines of the type system.

  The overall project serves as an impressive, albeit impractical, demonstration of the power and flexibility of the TypeScript type system. It highlights the Turing completeness of TypeScript's type system, albeit in a highly constrained and unconventional manner. The video is not meant to advocate for this approach in real-world game development but rather showcases the unexpected capabilities and potential of type systems for complex computations, pushing the boundaries of what's typically considered possible with a type checker.

  • TypeScript
  • Types
  • Doom
  • Game Development
  • WebAssembly
  • Wasm
  • javascript
  • programming
  • video
  • Demo
  • performance
  • Compilation
  • Gaming
  • Software Development

  Summary of Comments ( 138 )
  https://news.ycombinator.com/item?id=43184291

  Verbose tl;dr

  HN users were generally impressed with the technical feat of running DOOM in a TypeScript type. Several pointed out the absurdity and impracticality of the project, with one user calling it "peak type abuse." Discussion touched on the Turing completeness of TypeScript's type system, its potential misuse, and the implications for performance. Some wondered about practical applications, while others simply appreciated it as a clever demonstration of the language's capabilities. A few users questioned the definition of "running" in this context, arguing that it was more of a simulation than actual execution. There was some debate about the video's explanation clarity and a call for a blog post with a more thorough breakdown.

  The Hacker News post titled "TypeScript types can run DOOM [video]" (linking to a YouTube video demonstrating a TypeScript type system complex enough to encode and "run" a simplified version of DOOM) generated a variety of comments, predominantly focused on the cleverness of the implementation and the implications for type systems.

  Several commenters expressed amazement and admiration for the technical feat. Phrases like "absolutely insane," "mind-blowing," and "this is wild" were common. This sentiment reflects the unexpected power and complexity demonstrated by manipulating TypeScript's type system to perform computations typically handled by runtime code.

  A significant thread of discussion revolved around the practical implications (or lack thereof) of this demonstration. Many acknowledged the impracticality of this approach for actual game development or any performance-sensitive task. Commenters pointed out the significant performance overhead and the unwieldy nature of encoding logic within a type system. However, some suggested that the underlying principles could potentially have applications in areas like formal verification and compile-time computation, even if encoding a game within types remains a novelty.

  Some commenters explored the theoretical boundaries of this approach. They questioned how far such a system could be pushed and speculated about the computational completeness of sufficiently advanced type systems. The discussion touched upon topics like Turing completeness and the theoretical limits of computation within type systems.

  A few comments focused on the educational value of the demonstration. They highlighted the project's ability to illustrate the power and flexibility of type systems, even if the specific application is impractical. This suggests the video could be a valuable tool for learning about type systems and their potential.

  Some technical details of the implementation were also discussed, including the use of recursive types and the limitations imposed by the TypeScript type system. Commenters debated the elegance and readability of the code, with some expressing concerns about the complexity and maintainability of such an approach.

  Finally, some comments injected humor into the thread, making lighthearted remarks about the absurdity of running DOOM in a type system and the potential for future "type-driven" applications.

  Overall, the comments on Hacker News reflected a mix of awe, skepticism, and curiosity about the implications of running DOOM within TypeScript's type system. While acknowledging the impracticality of the specific application, many appreciated the technical ingenuity and the potential for future explorations of type system capabilities.