Stories with Tag Go 1.18

• Good-bye core types; Hello Go as we know and love it

  permalink

  Posted: 2025-03-26 16:18:14

  Verbose tl;dr

  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.

  This blog post, titled "Good-bye core types; Hello Go as we know and love it," announces the deprecation of the term "core types" in Go programming language documentation and community discussions. The authors explain that the term "core types" historically referred to a specific set of predeclared, named types in Go, including numerics like int, uint, and float64, as well as string and bool. These types held a special status because they were directly represented in the Go specification and were not defined using type aliases or other type definitions. This distinguished them from composite types like slices and maps, which are built upon these core types.

  However, the post argues that this distinction between "core" and other types has become less relevant and more confusing over time. The introduction of new types like rune and byte (which are aliases of int32 and uint8 respectively) blurred the lines, as these new types, despite being aliases, exhibited similar behavior and importance to the original core types. Furthermore, the distinction never held much practical significance for Go programmers. The way programmers interacted with both "core" and other types was largely consistent, and the internal representation differences were not generally a concern in day-to-day coding.

  The authors detail how this categorization was leading to inconsistencies and complexities within the documentation and within the language itself. For instance, the documentation sometimes used the term "basic types" interchangeably with "core types", contributing to the ambiguity. The blog post thus proposes to move away from the concept of "core types" altogether. Instead, the Go documentation will simply refer to these as "predeclared types," emphasizing that they are readily available for use without requiring explicit definition by the programmer. This simplification aims to improve clarity and reduce confusion for both new and experienced Go developers.

  Finally, the post reassures readers that this change is purely terminological. The functionality and behavior of these types remain completely unchanged. No existing Go code will break as a result of this decision. The core functionality and spirit of Go, which emphasizes simplicity and ease of use, are preserved. This adjustment simply removes an unnecessary and confusing categorization, leaving the familiar and beloved aspects of Go intact. The authors encourage the community to adopt this new terminology and help make the Go ecosystem more consistent and beginner-friendly.

  • Go
  • Golang
  • Core Types
  • Type Parameters
  • Generics
  • programming language
  • Software Development
  • Go 1.18
  • Type Inference
  • Static Typing

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

  Verbose tl;dr

  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.

  The Hacker News post "Good-bye core types; Hello Go as we know and love it" (linking to a Go blog post about the removal of "core types" from the language specification) generated a moderate amount of discussion, with a mixture of opinions.

  Several commenters expressed relief and approval of the change. They saw the "core types" concept as unnecessary complexity in the language specification and appreciated its removal. The simplification of the spec was seen as a positive step, making the language easier to understand and reason about. Some felt that the "core types" concept never truly added value and its removal was overdue. This sentiment was echoed by a few who suggested that the concept had caused confusion among Go developers.

  A couple of commenters questioned the practical impact of the change. They wondered whether this simplification would lead to any tangible differences in how Go code is written or performs. One commenter specifically asked if this change would influence how generics are handled or used. However, there wasn't a definitive answer provided within the thread to these questions.

  One commenter provided more context by linking to a GitHub issue discussing the removal of "core types". This added another layer to the conversation, though the content of that linked issue was not summarized within the Hacker News thread itself.

  Finally, at least one commenter expressed a degree of apathy toward the change, stating it didn't affect their daily coding. This indicated that while some saw this as a significant simplification, others perceived it as a relatively minor detail. The overall tone of the discussion was relatively calm and technical, without any strong negativity or heated debate.

• Constraints in Go

  permalink

  Posted: 2024-11-17 08:44:29

  Verbose tl;dr

  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.

  This blog post, titled "Constraints in Go," delves into the concept of type parameters and constraints introduced in Go 1.18, providing an in-depth explanation of their functionality and utility. It begins by acknowledging the long-awaited nature of generics in Go and then directly addresses the mechanism by which type parameters are constrained.

  The author meticulously explains that while type parameters offer the flexibility of working with various types, constraints are essential for ensuring that these types support the operations performed within a generic function. Without constraints, the compiler would have no way of knowing whether a given type supports the necessary methods or operations, leading to potential runtime errors.

  The post then introduces the concept of interface types as the primary mechanism for defining constraints. It elucidates how interface types, which traditionally specify a set of methods, can be extended in generics to include not just methods, but also type lists and the new comparable constraint. This expanded role of interfaces allows for a more expressive and nuanced definition of permissible types for a given type parameter.

  The article further clarifies the concept of type sets, which are the set of types that satisfy a given constraint. It emphasizes the importance of understanding how various constraints, including those based on interfaces, type lists, and the comparable keyword, contribute to defining the allowed types. It explores specific examples of constraints like constraints.Ordered for ordered types, explaining how such predefined constraints simplify common use cases.

  The author also provides practical examples, demonstrating how to create and utilize custom constraints. These examples showcase the flexibility and power of defining constraints tailored to specific needs, moving beyond the built-in options. The post carefully walks through the syntax and semantics of defining these custom constraints, illustrating how they enforce specific properties on type parameters.

  Furthermore, the post delves into the intricacies of type inference in the context of constraints. It explains how the Go compiler deduces the concrete types of type parameters based on the arguments passed to a generic function, and how constraints play a crucial role in this deduction process by narrowing down the possibilities.

  Finally, the post touches upon the impact of constraints on code readability and maintainability. It suggests that carefully chosen constraints can improve code clarity by explicitly stating the expected properties of type parameters. This explicitness, it argues, can contribute to more robust and easier-to-understand generic code.

  • Go
  • Golang
  • Constraints
  • Type Parameters
  • Generics
  • programming
  • Software Development
  • Type System
  • Static Typing
  • Code Reusability
  • Interfaces
  • Go 1.18
  • Go Programming Language
  • Generics in Go
  • Type Constraints in Go

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

  Verbose tl;dr

  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.

  The Hacker News post titled "Constraints in Go" discussing the blog post "Constraints in Go" at bitfieldconsulting.com generated several interesting comments.

  Many commenters focused on the comparison between Go's type parameters and interfaces, discussing the nuances and trade-offs between the two approaches. One commenter, the_prion, pointed out the significant difference lies in how they handle methods. Interfaces group methods together, allowing a type to implement multiple interfaces, and focusing on what a type can do. Type parameters, on the other hand, constrain based on the type itself, focusing on what a type is. They highlighted that Go's type parameters are not simply "interfaces with a different syntax," but a distinctly different mechanism.

  Further expanding on the interface vs. type parameter discussion, pjmlp argued that interfaces offer better flexibility for polymorphism, while type parameters are superior for code reuse without losing type safety. They used the analogy of C++ templates versus concepts, suggesting that Go's type parameters are similar to concepts which operate at compile-time and offer stricter type checking than interfaces.

  coldtea added a practical dimension to the discussion, noting that type parameters are particularly useful when you want to ensure the same type is used throughout a data structure, like a binary tree. Interfaces, in contrast, would allow different types implementing the same interface within the tree.

  Another key discussion thread centered around the complexity introduced by type parameters. DanielWaterworth questioned the readability benefits of constraints over traditional interfaces, pointing to the verbosity of the syntax. This sparked a debate about the balance between compile-time safety and code complexity. peterbourgon countered, arguing that the complexity pays off by catching more errors at compile time, reducing runtime surprises, and potentially simplifying the overall codebase in the long run.

  Several commenters, including jeremysalwen and hobbified, discussed the implications of using constraints with various data structures, exploring how they interact with slices and other collections.

  Finally, dgryski pointed out an interesting use case for constraints where implementing a type set library becomes easier and cleaner using generics, contrasting it with the more cumbersome method required before their introduction.

  Overall, the comments reflect a general appreciation for the added type safety and flexibility that constraints bring to Go, while acknowledging the increased complexity in some cases. The discussion reveals the ongoing exploration within the Go community of the optimal ways to leverage these new language features.