The `comparable` in generics can contain `any`. So, there will be more misleading.

This page summarizes the projects mentioned and recommended in the original post on /r/golang

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • go

    The Go programming language

    Make interface-types not comparable for purposes of constraint-satisfaction. That way, you just can't instantiate a generic function which uses == on a type-argument using interface-types. That would work, but it seems a strange deviation from how the language currently works - it does allow you to compare interface-types. It also would disallow some valid use-cases - i.e. it's often fine to instantiate a generic function using interface-types, even if it uses comparisons, as long as you make sure to only use comparable dynamic types. It would also disallow some backwards-compatibility wrappers - e.g. we'd probably like to provide a generic atomic.Value and leave the existing one in as type Value = GenericValue[interface{}]. Which would then be disallowed (see this discussion)

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts