This paper introduces Deputy, a dependently typed language designed for practical programming. Deputy integrates dependent types into a Lisp-like language, aiming to balance the power of dependent types with the flexibility and practicality of dynamic languages. It achieves this through a novel combination of features: gradual typing, allowing seamless mixing of typed and untyped code; a hybrid type checker employing both static and dynamic checks; and a focus on intensional type equality, allowing for type-level computation and manipulation. This approach makes dependent types more accessible for everyday tasks by allowing programmers to incrementally add type annotations and leverage dynamic checking when full static verification is impractical or undesirable, ultimately bridging the gap between the theoretical power of dependent types and their use in real-world software development.
Spade is a hardware description language (HDL) focused on correctness and maintainability. It leverages Python's syntax and ecosystem to provide a familiar and productive development environment. Spade emphasizes formal verification through built-in model checking and simulation capabilities, aiming to catch bugs early in the design process. It supports both synchronous and asynchronous designs and compiles to synthesizable Verilog, allowing integration with existing hardware workflows. The project aims to simplify hardware design and verification, making it more accessible and less error-prone.
Hacker News users discussed Spade's claimed benefits, expressing skepticism about its performance compared to Verilog/SystemVerilog and its ability to attract a community. Some questioned the practical advantages of Python integration, citing existing Python-based HDL tools. Others pointed out the difficulty of breaking into the established HDL ecosystem, suggesting the language would need to offer significant improvements to gain traction. A few commenters expressed interest in learning more, particularly regarding formal verification capabilities and integration with existing tools. The overall sentiment leaned towards cautious curiosity, with several users highlighting the challenges Spade faces in becoming a viable alternative to existing HDLs.
OCaml offers compelling advantages for machine learning, combining performance with expressiveness and safety. The Raven project aims to leverage these strengths by building a comprehensive ML ecosystem in OCaml. This includes Owl, a mature scientific computing library offering efficient tensor operations and automatic differentiation, and other tools facilitating tasks like data loading, model building, and training. The goal is to provide a robust and performant alternative to existing ML frameworks, benefiting from OCaml's strong typing and functional programming paradigms for increased reliability and maintainability in complex ML projects.
Hacker News users discussed Raven, an OCaml machine learning library. Several commenters expressed enthusiasm for OCaml's potential in ML, citing its type safety, speed, and ease of debugging. Some highlighted the challenges of adopting a less mainstream language like OCaml in the ML ecosystem, particularly concerning community size and available tooling. The discussion also touched on specific features of Raven, comparing it to other ML libraries and noting the benefits of its functional approach. One commenter questioned the practical advantages of Raven given existing, mature frameworks like PyTorch. Others pushed back, arguing that Raven's design might offer unique benefits for certain tasks or workflows and emphasizing the importance of exploring alternatives to the dominant Python-based ecosystem.
protobuf-ts-types is a tool that automatically generates TypeScript types from Protobuf schemas without requiring any code generation or compilation steps. It leverages the Protobuf runtime library to infer types directly, offering a simpler and faster workflow for TypeScript developers working with Protobuf. This eliminates the need for separate code generation tools and keeps the TypeScript types synchronized with the Protobuf schemas, reducing potential errors. The project aims to improve developer experience and efficiency when using Protobuf in TypeScript projects.
Hacker News users generally expressed interest in the project, praising its approach to Protobuf type generation in TypeScript. Several commenters highlighted the advantages of avoiding code generation and runtime dependencies, contrasting it favorably with existing solutions like protoc and protobufjs. Some questioned the handling of specific Protobuf features like oneof and any, and discussions arose around potential performance implications and the project's compatibility with existing JavaScript Protobuf libraries. The author actively engaged with commenters, clarifying design choices and addressing technical questions about the project's inner workings. Overall, the reception was positive, with many seeing the project as a promising alternative for TypeScript Protobuf integration.
Whenever is a Python library providing a Whenever type for representing date and time values in a more robust and intuitive way than native Python types. It's particularly focused on handling Daylight Saving Time (DST) transitions correctly and consistently, avoiding ambiguities and errors common with other approaches. Whenever objects store datetimes as UTC timestamps internally, but allow users to interact with them in local time using a specified timezone. They offer convenient methods for performing date and time arithmetic, comparisons, and formatting, while transparently managing DST transitions behind the scenes. This simplifies working with recurring events or schedules that span DST changes, eliminating the need for complex manual adjustments. The library aims to provide a clear and dependable way to manage date and time information across different timezones and DST rules.
Hacker News users generally praised the whenever library for its focus on type safety and handling of daylight saving time (DST), which are common pain points in Python's datetime handling. Several commenters expressed interest in its approach using tagged unions for representing different kinds of time specifications. Some raised questions about the practical implications of whenever's immutability, particularly concerning performance in tight loops and modification of existing datetime objects. The discussion also touched upon alternatives like pendulum and arrow, with some users suggesting whenever offered a fresh perspective on a persistent problem. A few commenters expressed skepticism about the library's complexity and the potential for over-engineering, preferring simpler solutions where possible.
ArkType is a new TypeScript validation library boasting significantly faster performance than Zod, often cited as 100x faster. It leverages TypeScript's type system to generate highly optimized validators at compile time, resulting in minimal runtime overhead. ArkType aims for full compatibility with Zod's schema syntax, allowing for easy migration. It focuses on ergonomics and developer experience, offering features like autocompletion, type inference, and helpful error messages. While still in early development, ArkType presents a compelling alternative for TypeScript projects needing high-performance validation.
Hacker News users discuss ArkType's claimed 100x speed improvement over Zod, with many expressing skepticism and requesting benchmarks. Some acknowledge the potential value of a faster validator, especially for complex schemas, but question the practicality of the claimed performance difference. Several users point to the importance of schema complexity and input size in benchmarking, suggesting that simple schemas might not showcase ArkType's advantages. Others highlight Zod's strengths, such as its developer experience and comprehensive feature set, and wonder if ArkType can compete in those areas. The lack of clear, comparable benchmark data is a recurring theme, with users calling for more evidence to support the 100x claim. There's also interest in how ArkType handles asynchronous validation and its overall developer experience.
F# offers a compelling blend of functional and object-oriented programming, making it suitable for diverse tasks from scripting and data science to full-fledged applications. Its succinct syntax, strong type system, and emphasis on immutability enhance code clarity, maintainability, and correctness. Features like type inference, pattern matching, and computational expressions streamline development, enabling developers to write concise yet powerful code. While benefiting from the .NET ecosystem and interoperability with C#, F#'s distinct functional-first approach fosters a different, often more elegant, way of solving problems. This translates to improved developer productivity and more robust software.
Hacker News users discuss the merits of F#, often comparing it to other functional languages like OCaml, Haskell, and Clojure. Some commenters appreciate F#'s practicality and ease of use, especially within the .NET ecosystem, highlighting its strong typing and tooling. Others find its functional purity less strict than Haskell's, viewing it as both a benefit (pragmatism) and a drawback (potential for less elegant code). The discussion touches on F#'s suitability for specific domains like data science and web development, with some expressing enthusiasm while others note the prevalence of C# in those areas within the .NET world. Several comments lament the comparatively smaller community and ecosystem surrounding F#, despite acknowledging its technical strengths. The overall sentiment appears to be one of respect for F# but also a recognition of its niche status.
Mads Tofte's "Four Lectures on Standard ML" provides a concise introduction to the core concepts of SML. It covers the fundamental aspects of the language, including its type system with polymorphism and type inference, its support for functional programming with higher-order functions, and its module system for structuring large programs. The lectures emphasize clarity and practicality, demonstrating how these features contribute to writing reliable and reusable code. Examples illustrate key concepts like pattern matching, data structures, and abstract data types. The text aims to provide a solid foundation for further exploration of SML and its applications.
Hacker News users discuss Mads Tofte's "Four Lectures on Standard ML" with appreciation for its clarity and historical context. Several commenters highlight the document as an excellent introduction to ML and type inference, praising its conciseness and accessibility compared to more modern resources. Some note the significance of seeing the language presented shortly after its creation, offering a glimpse into its original design principles. The lack of dependent types is mentioned, with one commenter pointing out that adding them would significantly alter ML's straightforward type inference. Others discuss the influence of ML on later languages like Haskell and OCaml, and the enduring relevance of its core concepts. A few users reminisce about their experiences learning ML and using related tools like SML/NJ.
The blog post "You Need Subtyping" argues that subtyping, despite sometimes being viewed as complex or unnecessary, is a crucial tool for writing flexible and maintainable code. It emphasizes that subtyping allows for writing generic algorithms that operate on a range of related types without needing modification for each specific type. The author illustrates this through examples using shapes and animal sounds, demonstrating how subtyping enables reusable functions that handle different subtypes without explicit type checks. The post further champions subtype polymorphism as a superior alternative to approaches like typeclasses or enums for handling diverse data types, highlighting its ability to gracefully accommodate future type extensions without altering existing code. Ultimately, the author advocates for embracing subtyping as a fundamental concept for building robust and adaptable software systems.
HN users generally disagreed with the premise that subtyping is needed. Several commenters argued that subtyping adds complexity, especially in larger projects, and that its benefits are often overstated. Alternatives like composition and pattern matching were suggested as potentially superior approaches. Some argued that the author conflated subtyping with polymorphism, while others pointed out that the benefits mentioned in the article, like code reuse and extensibility, could be achieved without subtyping. A few commenters discussed the specific example used in the blog post, highlighting its contrived nature and suggesting better alternatives. The overall sentiment was that subtyping is a tool, sometimes useful, but not a necessity.
The Go blog post announces the deprecation of the go/types package's core types in favor of using standard Go types directly. This simplifies type checking and reflection by removing a separate type system representation, making code easier to understand and maintain. Instead of using types.Int, types.String, etc., developers should now use int, string, and other built-in types when working with the go/types package. This change improves the developer experience by streamlining interactions with types and aligning type checking more closely with the language itself. The blog post details how to migrate existing code to the new approach and emphasizes the benefits of this simplification for the Go ecosystem.
Hacker News commenters largely expressed relief and approval of Go's reversion from the proposed coretypes changes. Many felt the original proposal was overly complex and solved a problem most Go developers didn't have, while introducing potential performance issues and breaking changes. Some appreciated the experiment's insights into Go's type system, but ultimately agreed the added complexity wasn't worth the purported benefits. A few commenters lamented the wasted effort and questioned the decision-making process that led to the proposal in the first place, while others pointed out that exploring such ideas, even if ultimately abandoned, is a valuable part of language development. The prevailing sentiment was satisfaction with the return to the familiar and pragmatic approach that characterizes Go.
Niri is a new programming language designed for building distributed systems. It aims to simplify concurrent and parallel programming by introducing the concept of "isolated objects" which communicate via explicit message passing, eliminating shared mutable state and thus avoiding data races and other concurrency bugs. This approach, coupled with automatic memory management and a focus on performance, makes Niri suitable for developing robust and efficient distributed applications, potentially replacing complex actor models or other concurrency paradigms. The language is still under development, but shows promise for streamlining the creation of complex distributed systems.
Hacker News users discussed Niri's potential, focusing on its novel approach to UI design. Several commenters expressed excitement about the demo, praising its speed and the innovative concept of manipulating data directly within the interface. Concerns were raised about the practicality of text-based interaction for complex tasks and the potential learning curve. Some questioned the long-term viability of relying solely on a keyboard-driven interface, while others saw it as a powerful tool for experienced users. The discussion also touched upon comparisons to other tools like spreadsheets and the potential benefits for specific use cases like data analysis and programming. Some users expressed skepticism, finding the current implementation limited and wanting to see more concrete examples of its capabilities.
Gleam v1.9.0 introduces improved error messages, specifically around type errors involving records and incorrect argument counts. It also adds the gleam echo command, a helpful tool for debugging pipelines by printing values at different stages. Additionally, the release includes experimental support for Git integration, allowing Gleam to leverage Git information for dependency resolution and package management. This simplifies workflows and improves dependency management within projects, especially for local development and testing.
Hacker News users discussed the Gleam v1.9.0 release, largely focusing on its novel approach to error handling. Several commenters praised the explicit and exhaustive nature of error handling in Gleam, contrasting it favorably with Elixir's approach, which some found less strict. The discussion also touched upon the tradeoffs between Gleam's stricter error handling and potential verbosity, with some acknowledging the benefits while others expressed concerns about potential boilerplate. A few comments highlighted the language's growing maturity and ecosystem, while others inquired about specific features like concurrency and performance. One commenter appreciated the clear and concise changelog, a sentiment echoed by others who found the update informative and well-presented. The overall tone was positive, with many expressing interest in exploring Gleam further.
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.
The blog post "Gleam, Coming from Erlang" explores the author's experience transitioning from Erlang to Gleam, a newer language built on the Erlang Virtual Machine (BEAM). It highlights Gleam's similarities to Erlang, such as its functional nature, immutability, and the benefits of the BEAM ecosystem like concurrency and fault tolerance. However, the author emphasizes key differences, primarily Gleam's static typing, more approachable syntax inspired by Rust and Elm, and its focus on clearer error messages. While acknowledging some current limitations in tooling and library availability compared to Erlang's mature ecosystem, the post ultimately presents Gleam as a promising alternative for building robust, concurrent applications, particularly for developers coming from other statically-typed languages who might find Erlang's syntax challenging.
Hacker News commenters generally expressed interest in Gleam, praising its friendly syntax and the benefits it inherits from the Erlang ecosystem, like the BEAM VM. Some saw it as a potentially strong competitor to Elixir, appreciating its stricter type system and simpler tooling. A few users familiar with Erlang questioned the necessity of Gleam, suggesting that learning Erlang directly might be more worthwhile. Performance comparisons with Elixir and other BEAM languages were also a topic of discussion, with some expressing hope for benchmarks. A recurring sentiment was curiosity about Gleam's potential to attract a larger community and gain wider adoption. Several commenters also appreciated the author's candid comparison between Gleam and Erlang, finding the article helpful for understanding Gleam's niche.
Astral is a new static type checker being developed for Python that aims to be faster and more ergonomic than existing options like MyPy. It leverages a new type inference algorithm designed for performance and boasts features like auto-completion, goto-definition, and an improved developer experience. The project is still early in development but claims significant speed improvements, with a goal of being at least 5x faster than MyPy on real-world codebases. Astral also intends to offer seamless integration with existing Python tooling and provide enhanced support for popular libraries like NumPy and Pandas.
Hacker News users discuss Astral's potential, drawing parallels to MyPy but with a focus on performance. Some express skepticism about static typing in Python, questioning its necessity and impact on the language's flexibility. Others are interested in Astral's approach to gradual typing and its ability to handle complex codebases. Performance improvements over MyPy are frequently mentioned as a key benefit. Several commenters inquire about specific features, such as handling metaclasses and integration with existing tools. Overall, there's a mix of cautious optimism and interest in seeing how Astral develops.
Dusa is a logic programming language based on finite-choice logic, designed for declarative problem solving and knowledge representation. It emphasizes simplicity and approachability, with a Python-inspired syntax and built-in support for common data structures like lists and dictionaries. Dusa programs define relationships between facts and rules, allowing users to describe problems and let the system find solutions. Its core features include backtracking search, constraint satisfaction, and a type system based on logical propositions. Dusa aims to be both a practical tool for everyday programming tasks and a platform for exploring advanced logic programming concepts.
Hacker News users discussed Dusa's novel approach to programming with finite-choice logic, expressing interest in its potential for formal verification and constraint solving. Some questioned its practicality and performance compared to established Prolog implementations, while others highlighted the benefits of its clear semantics and type system. Several commenters drew parallels to miniKanren, another logic programming language, and discussed the trade-offs between Dusa's finite-domain focus and the more general approach of Prolog. The static typing and potential for compile-time optimization were seen as significant advantages. There was also a discussion about the suitability of Dusa for specific domains like game AI and puzzle solving. Some expressed skepticism about the claim of "blazing fast performance," desiring benchmarks to validate it. Overall, the comments reflected a mixture of curiosity, cautious optimism, and a desire for more information, particularly regarding real-world applications and performance comparisons.
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 ( 1 )
https://news.ycombinator.com/item?id=44041515
Hacker News users discuss the paper "The Lisp in the Cellar: Dependent Types That Live Upstairs," focusing on the practicality and implications of its approach to dependent types. Some express skepticism about the claimed performance benefits and question the trade-offs made for compile-time checking. Others praise the novelty of the approach, comparing it favorably to other dependently-typed languages like Idris and highlighting the potential for more efficient and reliable software. A key point of discussion revolves around the use of a "cellar" for runtime values and an "upstairs" for compile-time values, with users debating the elegance and effectiveness of this separation. There's also interest in the language's metaprogramming capabilities and its potential for broader adoption within the functional programming community. Several commenters express a desire to experiment with the language and see further development.
The Hacker News post titled "The Lisp in the Cellar: Dependent Types That Live Upstairs [pdf]" links to a PDF describing a programming language called Deputy. The discussion in the comments section is relatively brief, with a focus on the practicality and implications of the presented ideas.
One commenter expresses skepticism about the overall benefit of dependent types, questioning if the added complexity is worth the effort and if the advantages primarily apply to specific niches like formal verification. They seem to imply that for general-purpose programming, the trade-offs might not be favorable.
Another commenter points out a perceived similarity between Deputy's approach and the concept of gradual typing. They suggest that Deputy seems to be striving for a system where dependent types can be introduced incrementally, allowing developers to choose where and when to apply the stricter typing discipline.
A third comment delves into the technical details of Deputy's type system, highlighting its use of elaboration and normalization. They specifically mention that values are normalized during elaboration, comparing this approach to how Agda, another dependently typed language, handles type checking. They also raise a question about the implementation of large eliminations, a technical aspect related to how dependent types are handled in practice.
Finally, someone notes the irony in the paper's title, "The Lisp in the Cellar: Dependent Types That Live Upstairs," by pointing out that historically, Lisp has often been associated with more academic or advanced programming concepts, while dependent types are now being brought into that same realm. This comment focuses on the shifting perceptions and adoption of these programming paradigms.
While there are other comments, they are largely short expressions of interest, questions about specific technical details, or requests for clarification. The comments summarized above represent the most substantial points of discussion and offer insights into the community's reaction to the Deputy language and its features.