This blog post explores upcasting in Rust using the Any trait. It demonstrates how to safely cast a trait object back to its original concrete type using Any::downcast_ref, highlighting that this is safe and efficient because it's only a type check, not a conversion. The author explains how this mechanism, combined with trait objects, facilitates runtime polymorphism while maintaining Rust's static type safety. The post concludes by suggesting that upcasting to Any, despite seemingly going against its intended direction, offers a practical solution for storing and retrieving different types within a homogenous collection, effectively simulating inheritance for operations like shared functionality invocation.
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.
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.
Preserves is a new data language designed for clarity and expressiveness, aiming to bridge the gap between simple configuration formats like JSON/YAML and full-fledged programming languages. It focuses on data transformation and manipulation with a concise syntax inspired by functional programming. Key features include immutability, a type system emphasizing structural types, built-in support for common data structures like maps and lists, and user-defined functions for more complex logic. The project aims to offer a powerful yet approachable tool for tasks ranging from simple configuration to data processing and analysis, especially where maintainability and readability are paramount.
Hacker News users discussed Preserves' potential, comparing it to tools like JSON, YAML, TOML, and edn. Some lauded its expressiveness, particularly its support for comments and arbitrary keys. Others questioned its practical value beyond configuration files, wondering about performance, tooling, and whether its added complexity justified the benefits over simpler formats. The lack of a formal specification was also a concern. Several commenters expressed interest in seeing real-world use cases and benchmarks to better assess Preserves' viability. Some saw potential for niche applications like game modding or creative coding, while others remained skeptical about its broad adoption. The discussion highlighted the trade-off between expressiveness and simplicity in data languages.
Go's type parameters, introduced in 1.18, allow generic programming but lack the expressiveness of interface constraints found in other languages. Instead of directly specifying the required methods of a type parameter, Go uses interfaces that list concrete types satisfying the desired constraint. This approach, while functional, can be verbose, especially for common constraints like "any integer" or "any ordered type." The constraints package offers pre-defined interfaces for various common use cases, reducing boilerplate and improving code readability. However, creating custom constraints for more complex scenarios still involves defining interfaces with type lists, leading to potential maintenance issues as new types are introduced. The article explores these limitations and proposes potential future directions for Go's type constraints, including the possibility of supporting type sets defined by logical expressions over existing types and interfaces.
Hacker News users generally praised the article for its clear explanation of constraints in Go, particularly for newcomers. Several commenters appreciated the author's approach of starting with an intuitive example before diving into the technical details. Some pointed out the connection between Go's constraints and type classes in Haskell, while others discussed the potential downsides, such as increased compile times and the verbosity of constraint declarations. One commenter suggested exploring alternatives like Go's built-in sort.Interface for simpler cases, and another offered a more concise way to define constraints using type aliases. The practical applications of constraints were also highlighted, particularly in scenarios involving generic data structures and algorithms.
Summary of Comments ( 55 )
https://news.ycombinator.com/item?id=43523238
HN commenters largely discuss the complexity of Rust's
Anytrait and its upcasting mechanism. Several express that while powerful, it introduces significant cognitive overhead and can be difficult to grasp initially. The concept of fat pointers and vtables is mentioned as crucial to understandingAny's behavior. Some question the necessity of such complexity, suggesting simpler alternatives or improvements to the learning resources. One commenter contrasts Rust's approach with Go's interfaces, highlighting the trade-offs between performance and ease of use. The overall sentiment seems to be a mix of appreciation for the power ofAnyand a desire for more accessible explanations and potentially simpler solutions where applicable. A suggestion is made that improvements to the compiler's error messages could significantly enhance the developer experience when working with these features.The Hacker News post "Rust Any part 3: we have upcasts," linking to a blog post about Rust's
Anytrait, has generated a moderate discussion with several interesting points raised.Several commenters discuss the implications and mechanics of upcasting in Rust, specifically in the context of the
Anytrait. One commenter highlights that the design discussed in the article isn't unique to Rust and is conceptually similar to how dynamic casting works in C++. They illustrate this with a C++ code snippet showcasingdynamic_castand its ability to check for cast success. This comparison helps contextualize Rust's approach for those familiar with other systems-level languages.Another commenter delves deeper into the performance implications of using
Any, noting the potential overhead compared to static dispatch. They acknowledge the flexibility offered byAnybut caution against overuse, particularly in performance-sensitive sections of code. This comment raises a practical concern about balancing flexibility and efficiency when employing dynamic typing features.The discussion also touches upon the trade-offs between static and dynamic dispatch. One commenter mentions that although Rust prioritizes static dispatch for performance, the
Anytrait provides a crucial escape hatch for scenarios demanding dynamic dispatch. They suggest that usingAnycan lead to more concise and elegant code in certain situations where the type isn't known at compile time.A further comment emphasizes the importance of understanding the potential costs associated with
Any. While convenient, it introduces runtime overhead due to the need for type checking. This reinforces the earlier point about judicious use ofAnyand highlights the importance of considering performance implications.Finally, one comment thread explores alternative approaches to achieving similar functionality without relying on
Any. They briefly discuss using enums or other statically typed constructs as potential substitutes, offering a different perspective on how to handle situations involving unknown types. This provides alternative solutions for readers who might prioritize compile-time safety and performance over the flexibility offered byAny.The overall sentiment appears to be positive towards the
Anytrait and its utility. However, the comments collectively emphasize the importance of being mindful of its performance characteristics and considering alternative solutions where appropriate. They also provide valuable context and comparisons to other languages, aiding in understanding the design choices made in Rust.