Version 6.0 of the Unicode standard, released in October 2010, added support for emoji. Aside from the classics like 😃 (SMILING FACE WITH OPEN MOUTH), 👍 (THUMBS UP SIGN), and 💩 (PILE OF POO), the standard also included several national flags like these:

🇺🇸 🇩🇪 🇬🇧 🇯🇵 🇮🇹

In fact, the standard included every national flag, and in a way that won’t require the standard to be changed when new countries come into being. How did the Unicode Consortium pull this off?

What they did is both crazy and genius. Instead of assigning a codepoint to each flag, which is the obvious way to do it (and the way the rest of the emoji are encoded), the standard defines twenty-six “regional indicator symbols”, from U+1F1E6 REGIONAL INDICATOR SYMBOL LETTER A to U+1F1FF REGIONAL INDICATOR SYMBOL LETTER Z. In order to include a country’s flag in your text, you first look up the country’s two-letter ISO 3166-1 code and then write the two regional indicator symbols corresponding to those letters. A font with support for that flag treats the two-codepoint sequence as a ligature, replacing the combination with a single pictogram.

✓

✓

One Chance is a Flash game developed by Dean Moynihan and released on Newgrounds on December 2, 2010. It has been frequently cited in video games literature as an interesting and moving use of permadeath mechanic (permanent death).

In the game, the player controls a scientist who has created a cancer-attacking “cure”; when it is released in a gas form it begins to cause the extinction of all life by unexpectedly targeting all living cells, rather than just cancer cells. The player is given six days to create an antibiotic, after which point one of several endings may be achieved depending on the choices made. A web browser cookie prevents the game from being played more than once.

A small, simple game that makes you feel something.

✓

Modern applications tend to be composed from relationships between smaller applications. Secure modern applications thus need a way to express and enforce security policies that span multiple services. This is the “server-to-server” (S2S) authentication and authorization problem (for simplicity, I’ll mash both concepts into the term “auth” for most of this post).

Designers today have a lot of options for S2S auth, but there isn’t much clarity about what the options are or why you’d select any of them. Bad decisions sometimes result. What follows is a stab at clearing the question up.

[…]

Do the simplest thing that makes sense for your application right now. A true fact we can relate from something like a decade of consulting work on these problems: intricate S2S auth schemes are not the norm; if there’s a norm, it’s “nothing at all except for ELBs”. If you need something, but you have to ask whether that something oughtn’t just be bearer tokens, then just use bearer tokens.

Unfortunately, if there’s a second norm, it’s adopting complicated auth mechanisms independently or, worse, in combination, and then succumbing to vulnerabilities.

It’s a great list. They conclude that MTLS is the best option for containers talking to each other:

If your inter-service auth problem really decomposes to inter-container (or, without containers, inter-instance) auth, MTLS starts to make sense. The container-container MTLS story usually involves containers including a proxy, like Envoy, that mediates access. If you’re not connecting containers, or have ad-hoc components, MTLS can really start to take on a CORBA feel: random sidecar processes (here stunnel, there Envoy, and this one app that tries to do everything itself). It can be a pain to configure properly, and this is a place you need to get configurations right.

If you can do MTLS in such a way that there is exactly one way all your applications use it (probably: a single proxy that all your applications install), consider MTLS. Otherwise, be cautious about it.

They recommend to never use JWTs:

JWT is a standard that tries to do too much and ends up doing everything haphazardly. Our loathing of JWT motivated this post, but this post isn’t about JWT; we’ll write more about it in the future.

As a bonus, they recommend macaroons for client-to-server authentication and authorization:

Macaroons are inexplicably underused. They’re the Velvet Underground of authentication mechanisms, hugely influential but with little radio airplay. Unlike the Velvets, Macaroons aren’t overrated. They work well for client-server auth and for s2s auth. They’re very flexible but have reassuring format rigidity, and they elegantly take advantage of just a couple simple crypto operations. There are libraries for all the mainstream languages. You will have a hard time coming up with a scenario where we’d try to talk you out of using them.

✓

The RED method is a monitoring methodology coined by Tom Wilkie based on what he learned while working at Google. RED is derived from some best practices established at Google known as the “Four Golden Signals,” developed by Google’s SRE team.

[…]

RED stands for rate, errors, and duration. These represent the three key metrics you want to monitor for each service in your architecture:

• Rate - The number of requests the service is handling per second.
• Error - The number of failed requests per second.
• Duration - The amount of time each request takes.

Using these three metrics, you can get a solid understanding of how your services are performing. The number of requests gives you a baseline for how much traffic is going to your service. The portion of those requests that are errors lets you know if a service is functioning within your SLO. Finally, the duration of time it takes for each request to be handled by your service gives you insight into the overall user experience of your application.

Rob Ewaschuk, writing for Google, on those four golden signals :

Latency

The time it takes to service a request. It’s important to distinguish between the latency of successful requests and the latency of failed requests. For example, an HTTP 500 error triggered due to loss of connection to a database or other critical backend might be served very quickly; however, as an HTTP 500 error indicates a failed request, factoring 500s into your overall latency might result in misleading calculations. On the other hand, a slow error is even worse than a fast error! Therefore, it’s important to track error latency, as opposed to just filtering out errors.

Traffic

A measure of how much demand is being placed on your system, measured in a high-level system-specific metric. For a web service, this measurement is usually HTTP requests per second, perhaps broken out by the nature of the requests (e.g., static versus dynamic content). For an audio streaming system, this measurement might focus on network I/O rate or concurrent sessions. For a key-value storage system, this measurement might be transactions and retrievals per second.

Errors

The rate of requests that fail, either explicitly (e.g., HTTP 500s), implicitly (for example, an HTTP 200 success response, but coupled with the wrong content), or by policy (for example, “If you committed to one-second response times, any request over one second is an error”). Where protocol response codes are insufficient to express all failure conditions, secondary (internal) protocols may be necessary to track partial failure modes. Monitoring these cases can be drastically different: catching HTTP 500s at your load balancer can do a decent job of catching all completely failed requests, while only end-to-end system tests can detect that you’re serving the wrong content.

Saturation

How “full” your service is. A measure of your system fraction, emphasizing the resources that are most constrained (e.g., in a memory-constrained system, show memory; in an I/O-constrained system, show I/O). Note that many systems degrade in performance before they achieve 100% utilization, so having a utilization target is essential.

In complex systems, saturation can be supplemented with higher-level load measurement: can your service properly handle double the traffic, handle only 10% more traffic, or handle even less traffic than it currently receives? For very simple services that have no parameters that alter the complexity of the request (e.g., “Give me a nonce” or “I need a globally unique monotonic integer”) that rarely change configuration, a static value from a load test might be adequate. As discussed in the previous paragraph, however, most services need to use indirect signals like CPU utilization or network bandwidth that have a known upper bound. Latency increases are often a leading indicator of saturation. Measuring your 99th percentile response time over some small window (e.g., one minute) can give a very early signal of saturation.

Finally, saturation is also concerned with predictions of impending saturation, such as “It looks like your database will fill its hard drive in 4 hours.”

✓

There are many in-depth articles and videos from SMEs of companies like Okta talking about the potential dangers and inefficiencies of using JWT tokens[1]. Yet, these warnings are overshadowed by marketers, YouTubers, bloggers, course creators, and others who knowingly or unknowingly promote it.

If you look at many of these videos and articles, they all just talk about the perceived benefits of JWT and ignore the deficiency. More specifically, they just show how to use it but don’t talk about revocations and additional complexities that JWT adds in a real production environment. They also never compare it with the existing battle-tested approaches deep enough to really weigh the pros and cons.

[…]

The biggest problem with JWT is the token revoke problem. Since it continues to work until it expires, the server has no easy way to revoke it.

A nice summary of the issues. You don’t tend to see many JWT critiques.

✓

The neurotransmitter dopamine plays a crucial role in the brain’s reward processing, with studies showing that it contributes more to the motivation for rewards than to the pleasure of receiving them. For a rat in a box, chocolate increases the release of dopamine by 55%, sex by 100%, nicotine by 150%, cocaine by 225%, and amphetamines, the active ingredient in speed, meth, MDMA, and Adderall (used to treat ADHD and narcolepsy) by 1000%. According to one study, abusing dopamine levels alters our ability to delay gratification, with addicts referring to their futures as only nine days long, compared to 4.7 years for the non-addicted participants.

Even though amphetamines are an order of magnitude more potent than sex, sex has an unusual property in that it can be prolonged for hours, whereas the highest high of cocaine only lasts a few minutes.

✓

The software developer job interview doesn’t work. Companies should stop relying on them. The savviest teams will outcompete their peers by devising alternative hiring schemes.

Years from now, we’ll look back at the 2015 developer interview as an anachronism, akin to hiring an orchestra cellist with a personality test and a quiz about music theory rather than a blind audition. Being good at navigating hiring processes requires a basket of skills that isn’t correlated with job performance. The world is full of people who can speak expertly about programming, but can’t effectively code. The majority of people who can code can’t do it well in an interview. Our hiring process therefore systematically misprices candidates. It’s a moral problem and a market failure. Profit from its correction.

✓

✓

Contemporary AI systems are now becoming human-competitive at general tasks,[3] and we must ask ourselves: Should we let machines flood our information channels with propaganda and untruth? Should we automate away all the jobs, including the fulfilling ones? Should we develop nonhuman minds that might eventually outnumber, outsmart, obsolete and replace us? Should we risk loss of control of our civilization? Such decisions must not be delegated to unelected tech leaders. Powerful AI systems should be developed only once we are confident that their effects will be positive and their risks will be manageable. This confidence must be well justified and increase with the magnitude of a system’s potential effects. OpenAI’s recent statement regarding artificial general intelligence, states that “At some point, it may be important to get independent review before starting to train future systems, and for the most advanced efforts to agree to limit the rate of growth of compute used for creating new models.” We agree. That point is now.

Therefore, we call on all AI labs to immediately pause for at least 6 months the training of AI systems more powerful than GPT-4. This pause should be public and verifiable, and include all key actors. If such a pause cannot be enacted quickly, governments should step in and institute a moratorium.

Unsurprisingly, there don’t seem to be any official signatories from OpenAI or Midjourney , who are beating the pants off everyone else at an unforseen and unbelievable rate. It’s almost as if this isn’t a consensus.

The creative and intelligent were perfectly fine with technology enabling the offshoring of manufacturing jobs and ending other jobs, because it didn’t affect them. They can learn to code, they said. Well, now the shoe is on the other foot. Technology is poised to “take ‘r job ” of perhaps many of those creative and intelligent people. What’s good for the goose is good for the gander.

✓

I wish to preach, not the doctrine of ignoble ease, but the doctrine of the strenuous life, the life of toil and effort, of labor and strife; to preach that highest form of success which comes, not to the man who desires mere easy peace, but to the man who does not shrink from danger, from hardship, or from bitter toil, and who out of these wins the splendid ultimate triumph.

It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat. Shame on the man of cultivated taste who lets refinement to develop in to fastidiousness that unfits him for doing the rough work of a work day world.

The social benefits are especially significant here because, after all, gratitude is a social emotion. I see it as a relationship-strengthening emotion because it requires us to see how we’ve been supported and affirmed by other people.

Indeed, this cuts to very heart of my definition of gratitude, which has two components. First, it’s an affirmation of goodness. We affirm that there are good things in the world, gifts and benefits we’ve received. This doesn’t mean that life is perfect; it doesn’t ignore complaints, burdens, and hassles. But when we look at life as a whole, gratitude encourages us to identify some amount of goodness in our life.

The second part of gratitude is figuring out where that goodness comes from. We recognize the sources of this goodness as being outside of ourselves. It didn’t stem from anything we necessarily did ourselves in which we might take pride. We can appreciate positive traits in ourselves, but I think true gratitude involves a humble dependence on others: We acknowledge that other people—or even higher powers, if you’re of a spiritual mindset—gave us many gifts, big and small, to help us achieve the goodness in our lives.

Don’t miss the list of benefits. The whole article is a good read.

✓

There’s a condition that afflicts many innocent, hard-working people around the world every day. Its victims suffer from light sensitivity, disorientation, lethargy, sleep deprivation, and depression. There is no cure, but some drugs temporarily alleviate its symptoms. Many people manage to live somewhat normal lives through proper treatment. I’m referring, of course, to waking up before 9:00 AM, which I had to do all this week and expect to continue doing until my body gives out. Please donate to my relief fund.

I’m preserving it here for posterity.

It’s Christmas and I have the usual problem of deciding what to give you. I know you might enjoy many things — books, games, clothes.

But I’m very selfish. I want to give you something that will stay with you for more than a few months or years. I want to give you a gift that might remind you of me every Christmas.

If I could give you just one thing, I’d want it to be a simple truth that took me many years to learn. If you learn it now, it may enrich your life in hundreds of ways. And it may prevent you from facing many problems that have hurt people who have never learned it.

The truth is simply this:

No one owes you anything.

I recommend reading the whole letter. It’s great advice.

✓

Part 2:

Some gems:

• They were posted one “sprint” apart. 🤣
• “It’s really Waterfall with meetings every two weeks.”
• “That’s Greg. His birthday is on day 2 of sprint 7.”
• “We don’t even define requirements until after production.”
• “I lost my job because I’m a horrible developer. Now I’m an Agile coach.”
• “Always change. Never finish.”
• “Folks who don’t have anything valuable to add deserve meetings.”
• “I’m so used to it, I don’t even hear the Waterfall.”
• “Don’t give customers what they need; give them what they ask for.”
• “The company was working fine before I introduced Scrum.”
• “That’s why they have me: to make Waterfall look like Scrum.”

“I Grew Up in a Corset. Time to Bust Some Myths. (Ft. Actual Research)”

“How Victorian Men Taught Us to Hate Corsets: The Biggest Lie in Fashion History”

“how actresses talk about wearing corsets in movies”

“if people in the future talked about bras the way we talk about corsets”

“period drama costume designers these days”

“curb your corset stereotypes”

“Reacting to Vogue’s ‘Everything You Need to Know About the Corset’ cause we haven’t suffered enough.”

Articles

• Bridgerton Keeps Perpetuating One of Hollywood’s Most Stubborn Myths
• Everything You Know About Corsets Is False
• Five Myths About Corsets And The Truth Behind Corsetry
• Make No (Whale)Bones About It: Debunking those Corsetry Myths
• The Corset: The Myth and the Reality
• The Truth About Corsets: Busting the Myths
• What ‘Bridgerton’ Gets Wrong About Corsets

Why you might find this approach interesting:

• Type variable declarations are implicit
• Type arguments for functions are implicit
• Type variable constraints can be omitted for the empty interface
• Methods can be generic
• Operations are represented with generics as normal methods
• It can simplify the Go language specification

Check out the More ideas section at the end for things beyond generics.

Define comparison operations for all types

For the types that don’t yet have them:

• Functions: Compare the corresponding memory addresses. The time complexity is constant.
• Maps: Compare the corresponding *runtime.hmap (pointer) values. The time complexity is constant.
• Slices: Compare the corresponding runtime.slice (non-pointer struct) values. The time complexity is constant.

Examples:

// Functions

func F1() {}
func F2() {}

var _ = F1 == F1 // True
var _ = F1 != F2 // True

// Maps

var M1 = map[int]int{}
var M2 = map[int]int{}

var _ = M1 == M1 // True
var _ = M1 != M2 // True

// Slices

var S1 = make([]int, 2)
var S2 = make([]int, 2)

var _ = S1 == S1 // True
var _ = S1 != S2 // True

var _ = S1 == S1[:] // True because the lengths, capacities, and pointers are equal
var _ = S1 != S1[:1] // True because the lengths aren't equal
var _ = S1[:1] != S1[:1:1] // True because the capacities aren't equal
var _ = S1 != append(S1, 0)[:2:2] // True because the pointers aren't equal

Define the nil value for all types

The predeclared identifier nil is now assignable to all types, and is the zero (nil ) value for its type. For example, array, boolean, numeric, string, and structure types all now have a nil value, which is their respective zero value.

Examples:

// Assignment

var _ [N]T = nil
var _ bool = nil
var _ int = nil
var _ string = nil
var _ struct{} = nil

// Conversion

var _ = [N]T(nil)
var _ = bool(nil)
var _ = int(nil)
var _ = string(nil)
var _ = struct{}(nil)

// Comparison

var _ = [N]T{} == [N}T(nil) && [N]T{} == nil // True
var _ = false == bool(nil) && false == nil // True
var _ = 0 == int(nil) && 0 == nil // True
var _ = "" == string(nil) && "" == nil // True
var _ = struct{}{} == struct{}(nil) && struct{}{} == nil // True

Generic abstractions

A type variable is a placeholder type that is substituted with another type called a type argument. A type variable can appear within type, variable, function, and method declarations; interface methods; and function literals. The type arguments permitted by a type variable must be assignable to an interface called its constraint. Type variables look like identifiers with a $ prefix, and cannot be blank . The case of the first character has no meaning, although type variables are case-sensitive. Type variables with identical names and constraints are identical.

Examples:

var _ $a
var _ $b
var _ $c
var _ $A
var _ $B
var _ $C
var _ $foo
var _ $BAR
var _ $baz_BOZ

Generic functions

A type variable is bound by the same or nearest outer function signature that contains it in a parameter type. Constraints default to an empty interface if unspecified. Constraints can optionally be specified for some or all type variables in a non-empty, unordered set.

A type variable bound by a function signature is part of its function type. One such type is assignable to another such type if they are identical; or if they are identical after renaming the type variables in one of them; or if the corresponding constraints are assignable; or if a type variable in the source type consistently corresponds to a type in the target type that isn’t a type variable.

To ensure parametricity , all type arguments must be valid, and the function value must behave the same regardless of the type argument. A type variable permits use of only constraint methods, assignment operations, comparison operations, method expressions, and method values. A type variable doesn’t permit use of type conversions, type assertions, or type switches. Reflection of a type variable reveals only its constraint.

Using type variables:

// $A is constrained by C, which has method M(int) int

var x $A = nil // Valid because x and nil have identical type variables (via assignability)

var _ func(C, int) int = C.M // Method expression
var _ func(int) int = x.M // Method value

var _ = x == x // Valid because x and x have identical type variables
var _ = x == nil // Valid because x and nil have identical type variables (via assignability)
var _ = x == 123 // Invalid because x and 123 don't have identical type variables

var _ = $A(x) // Invalid because type conversions aren't permitted
var _ = C(x) // Same as above
var _ = MyType(x) // Same as above
var _ = interface{}(x) // Same as above
var _ = interface{ M(int) int }(x) // Same as above

var _ = x.($A) // Invalid because type assertions aren't permitted
var _ = x.(C) // Same as above
var _ = x.(MyType) // Same as above
var _ = x.(interface{}) // Same as above
var _ = x.(interface{ M(int) int }) // Same as above

var _ = func() { switch x.(type) {} } // Invalid because type switches aren't permitted

Specifying generic functions:

// C, C1, and C2 are constraints
// [...] is a non-empty, unordered set of type variables and constraints

// Function declarations

func F($A) // $A is constrained by interface{}
func F[$A interface{}]($A) // Same as above

func F($A, $B) // $A and $B are constrained by interface{}
func F[$A interface{}]($A, $B) // Same as above
func F[$B interface{}]($A, $B) // Same as above
func F[$A, $B interface{}]($A, $B) // Same as above
func F[$B, $A interface{}]($A, $B) // Same as above

func F[$A C]($A) // $A is constrained by C

func F[$A C]($A, $B) // $A, $B are constrained by C, interface{}, respectively
func F[$B C]($A, $B) // $A, $B are constrained by interface{}, C, respectively

func F[$A C, $B C]($A, $B) // $A, $B are constrained by C
func F[$A, $B C]($A, $B) // Same as above

func F[$A C1, $B C2]($A, $B) // $A, $B are constrained by C1, C2, respectively

func F[$A, $B C1, $C, $D C2]($A, $B, $C, $D) // $A, $B and $C, $D are constrained by C1 and C2, respectively
func F[$D, $C C2, $B, $A C1]($A, $B, $C, $D) // Same as above

func F[$A, $B, $C C]($A, $B, $C) // $A, $B, $C are constrained by C

// Method declarations

func (T) M($A)
func (T) M[$A interface{}]($A)
// ...
// Same as function declarations above

// Interface methods

interface { M($A) }
interface { M[$A interface{}]($A) }
// ...
// Same as function declarations above

// Function literals

func($A) {}
func[$A interface{}]($A) {}
// ...
// Same as function declarations above

// Nested functions

func F(a $A) $A {
    // $A below is bound by the function literal
    return func(a $A) $A { return a }(a)
}

func F(a $A, b $B) ($A, $B) {
    // $A below is bound by the function literal
    // $B below is bound by F
    return func(a $A) ($A, $B) { return a, b }(a)
}

func F(a, b $A) $A {
    choose := func(b bool) $A { // $A here bound by F
        var result $A // $A here bound by F
        if b {
            result = a
        } else {
            result = b
        }
        return result
    }
    return choose(a == b)
}

// Shorthand for combining multiple constraints into one

func F[$A C]($A)
func F[$A interface{ C }]($A) // Same as above

func F[$A interface{ C1; C2 }]($A)
func F[$A (C1, C2)]($A) // Same as above

func F[$A interface{ C1; C2; C3 }]($A)
func F[$A (C1, C2, C3)]($A) // Same as above

Using generic functions:

func F(x, y $A) $A {
    return x
}

var _ = F(1, 2) + 3
var _ = F(1i, 2i) + 3i
var _ = F(1.0, 2.0) + 3.0
var _ = F('1', '2') + '3'
var _ = F("1", "2") + "3"
var _ = F(false, true) && false
var _ = F([]int{1}, []int{2})[0]
var _ = F([1]int{1}, [1]int{2})[0]
var _ = F(map[int]int{1:1}, map[int]int{2:2})[1]
var _ = F(make(chan int), make(chan int))->
var _ = F(url.URL{}, url.URL{}).Scheme
var _ = *F(&url.URL{}, &url.URL{})
var _ = F(func(){}, func(){})()
var _ = F(net.IP{}, net.IP{}).String()

Type arguments are substituted for type variables using type inference , perhaps some form of unification .

Generic function types:

// Assignable because of identical types

var _ func($A) = func($A) {}
var _ func($A, $B) = func($A, $B) {}

var _ func[$A C]($A) = func[$A C]($A) {}
var _ func[$A C1, $B C2]($A, $B) = func[$A C1, $B C2]($A, $B) {}

// Assignable because of equivalent type variable names

var _ func($A) = func($B) {}
var _ func($A, $B) = func($C, $D) {}

var _ func[$A C]($A) = func[$B C]($B) {}
var _ func[$A C1, $B C2]($A, $B) = func[$C C1, $D C2]($C, $D) {}

// Assignable because of equivalent type variable constraints

var _ func[$A interface{}]($A) = func[$A interface{}]($A) {}
var _ func[$A interface{ M() }]($A) = func[$A interface{}]($A) {}
var _ func[$A interface{ M1(); M2() }]($A) = func[$A interface{ M1() }]($A) {}

// Assignable because of compatible behavior

var _ func(int) = func($A) {}
var _ func(int) int = func(a $A) $A { return a }

func F(g func($A) int, x int) int {
    return g(x)
}

func G($A) int {
    return 123
}

func H(a $A) $A {
    return a
}

var _ = F(G, 456) // == 123
var _ = F(H, 456) // == 456

Generic types

A generic type declaration abstracts the underlying type. It’s implied by specifying a non-empty, ordered list of type variables and, optionally, their constraints. Constraints default to an empty interface if unspecified. The identifier for such a declared type is called a type constructor when used to construct types, and a value constructor when used to construct values. The body cannot be a lone type variable or a lone recursive reference.

Declaring generic types:

// [...] is a non-empty, ordered list of type variables and, optionally, constraints

type T[$A] int // Valid
type T[$A] $A // Invalid
type T[$A] T[$A] // Invalid

type T func($A) // T is not generic, but its underlying type is
type T[$A] func($A) // T is generic, but its underlying type is not
type T[$A] func($B) // T and its underlying type are generic

type T[$A] func($A) // $A is constrained by interface{}
type T[$A interface{}] func($A) // Same as above
type T[$A C] func($A) // $A is constrained by C

type T[$A C, $B C] func($A, $B) // $A and $B are constrained by C
type T[$A, $B C] func($A, $B) // Same as above

// $A and $B are constrained by C1
// $C is constrained by C2
// $D and $E are constrained by C3
// $F and $G are constrained by interface{}
type T[$A, $B C1, $C C2, $D, $E C3, $F, $G] func($A) ($A)

Using generic types:

// Generic type construction

var _ A[B]
var _ A[$B]
var _ $A[B]
var _ $A[$B]

var _ A[B, C]
var _ A[B, C, D]

var _ A[B[C[D]]]
var _ A[A[A[B]]]

// Generic parameter types

type List[$A] struct {
    as []$A
}

var _ List // Invalid
var _ List[int] // Valid

func (l List[$A]) First() $A {
    return l.as[0]
}

// Method sets for List[$A] and List[int] are different
func (l List[int]) FirstNegated() int {
    return -l.First()
}

func (l List[$A]) Contains(a $A) bool {
    for _, z := range l.as {
        if z == a {
            return true
        }
    }
    return false
}

func (l List[int]) ContainsNegated(a int) bool {
    return l.Contains(-a)
}

func (l List[$A]) Equivalent(l2 List[$A]) bool {
    if len(l.as) != len(l2.as) {
        return false
    }
    for i := range l.as {
        if l.as[i] != l2.as[i] {
            return false
        }
    }
    return true
}

// Generic value construction

// Zero values should be useful
var _ List[int]
var _ List[int] = List[int]{}

// Invalid currently in this design, although arguably it can work with type inference
var _ = List{[]int{}}
var _ List[int] = List{[]int{}}

func NewListItem(a $A) *List[$A] {
    return &List[$A]{as: []$A{a}}
}

var _ *List[int32] = NewListItem(1)

func NewListItems(as []$A) *List[$A] {
    return &List[$A]{as: as}
}

var _ *List[int] = NewListItems([]int{1, 2, 3})

// Generic value initialization

func (l *List[$A]) Init() {
    l.as = make([]$A, 0, 16)
}

// Generic generic types

func F(f func($T[$A]) $A, x $T[$A]) $A {
    return f(x)
}

var _ int = F(func(xs []int) int { return xs[0] }, []int{123}) // == 123

Generic interface method receivers

Instead of adding a new feature like type sets to enable interfaces to encompass predeclared types, we’ll expand the expressive power of interfaces to describe methods that behave equivalent to operations, then declare methods for the operations of predeclared types. This unifies predeclared and user-declared types under methods and interfaces, which simplifies the Go language and user code.

Enable specifying interface method receivers:

var _ interface { M() }
var _ interface { $A M() } // Same as above
var _ interface { ($A) M() } // Same as above
var _ interface { (a $A) M() } // Same as above

var _ interface { $A M($A) }
var _ interface { $A M() $A }
var _ interface { $A M($A) $A }

var _ interface { $A M($B) }
var _ interface { $A M($B) $A }
var _ interface { $A M($B) $B }

var _ interface { MyType M() } // Invalid because it's pointless
var _ interface { $A M($A) } = myValue // Invalid because it's pointless

var _ interface { M($A) } // $A does not match the receiver, it's separate
var _ interface { $B M($A) } // Same as above

Now we can do:

type Number interface {
    $A Add($A) $A
}

type MyInt struct {
    my int
}

func (x MyInt) Add(y MyInt) MyInt {
    return MyInt{my: x + y}
}

type MyFloat struct {
    my float64
}

func (x MyFloat) Add(y MyFloat) MyFloat {
    return MyFloat{my: x + y}
}

func _() {
    var myInt = MyInt{1} // OK
    var myFloat = MyFloat{2} // OK
    var num1 Number = myInt // Makes sense
    var num2 Number = myFloat // Makes sense
    var num3 /* ??? */ = num1.Add(num2) // Invalid because the return type is unknown, because Number hides MyInt
    // An interface method with a receiver type variable in a parameter can only be used when its interface is used as a constraint
}

func Add[$A Number](a, b $A) $A {
    return a.Add(b)
}

var _ MyInt = Add(MyInt{1}, MyInt{2})
var _ MyFloat = Add(MyFloat{1}, MyFloat{2})

Generalize and simplify the language

Declare and implement predeclared types and their operations in a core package in the standard library:

package core // import "core"

// Details hidden
type Array[$N, $T] // $N allows integer constants only here
type Bool
type Channel[$T]
type Complex64
type Complex128
type Float32
type Float64
type Int
type Int8
type Int16
type Int32
type Int64
type Map[$K Comparable, $V]
type Rune
type Slice[$T]
type String
type Uint
type Uint8
type Uint16
type Uint32
type Uint64
type Uintptr

type Byte = Uint8
type Rune = Int32

// Operation methods

// ...

// Implementation of methods hidden
func (x Int) Add(y Int) Int
// ...
func (x Int8) Multiply(y Int8) Int8
// ...
func (x Int16) Quotient(y Int16) Int16
// ...
func (x Int32) Subtract(y Int32) Int32
// ...
// ...

func (s Slice[$T]) Append($T) Slice[$T]
func (s Slice[$T]) AppendSlice(Slice[$T]) Slice[$T]
func (s Slice[$T]) Cap() int
func (s Slice[$T]) Copy(Slice[$T]) int
func (s Slice[$T]) Get(int) $T
func (s Slice[$T]) Len() int
func (s Slice[$T]) Set(int, $T)
func (s Slice[$T]) Slice(int, int) Slice[$T]
func (s Slice[$T]) SliceCap(int, int, int) Slice[$T]
// ...

// ...

// Built-in functions

// ...

func (Channel) Cap() int
func (Channel) Close()
func (Channel) Len() int

func Append(Slice[$A], $A) Slice[$A]

func Len[$A interface { Len() int }](a $A) int {
    return a.Len()
}

func Cap[$A interface { Cap() int }](a $A) int {
    return a.Cap()
}

func (Map[$K, $V]) Delete($K)

func (Complex64) Imag() float32
func (Complex64) Real() float32

func (Complex128) Imag() float64
func (Complex128) Real() float64

// ...

Declare useful abstractions for those types:

package core // import "core"

// ...

type Comparable interface {
    $N Equals($N) bool
    $N NotEquals($N) bool
}

type Orderable interface {
    Comparable
    $N Greater($N) bool
    $N GreaterEquals[$N Comparable]($N) bool
    $N Less($N) bool
    $N LessEquals[$N Comparable]($N) bool
}

type Number interface {
    Orderable
    $N Add($N) $N
    $N Multiply($N) $N
    $N Quotient($N) $N
    $N Subtract($N) $N
}

type Integer interface {
    Number
    $N Remainder($N) $N
    $N BitAnd($N) $N
    $N BitClear($N) $N
    $N BitLeft(int) $N
    $N BitOr($N) $N
    $N BitRight(int) $N
    $N BitXor($N) $N
}

// ...

Incorporate existing types into those new abstractions where applicable:

package big // import "math/big"

// ...

func (*Int) Add(*Int) *Int
// Obviously pick a name other than Add for Number.Add so it doesn't conflict with existing methods, if possible

// ...

package mypackage

// ...

func Add[$N Number](x, y $N) $N {
    return x.Add(y)
}

func _() {
    var x1, y1, z1 big.Int
    var x2, y2, z2 core.Int
    z1 = Add(x1, y1)
    z2 = Add(x2, y2)
    // ...
}

Change every package to implicitly dot-import the core package:

package mypackage

import . "core" // Implied, but allowed explicitly

var _ Int // core.Int

type Float32 // ...

var _ Float32 // mypackage.Float32
// Where conflicts arise, local declarations take precedence over core declarations

The core package can be qualified:

package mypackage

import "core" // Qualified import, overrides the dot-import

var _ core.Int

The qualifier can be specified like usual:

package mypackage

import thecore "core" // Qualified import, overrides the dot-import

var _ thecore.Int

Change the predeclared identifiers to refer to the core package where applicable:

// Universe block
// Pseudocode

import "core"

type int = core.Int
type string = core.String
type bool = core.Bool
type int32 = core.Int32
// ...

func append = core.Append // Now a full function value
func len = core.Len // Now a full function value
func cap = core.Cap // Now a full function value
// ...

// ...

Optional: Change order operators to be consistent with method semantics:

type B bool

var _ B = 1 < 2 // Invalid now because comparison operations now result in typed booleans

// Automatically fix existing code with "go fix" or "go fmt":

var _ B = B(1 < 2)

Change language constructs to use interfaces for user-declared types:

package core // import "core"

// ...

type Iterable[$T] interface {
    Iterator() Iterator[$T]
}

type Iterator[$T] interface {
    HasNext() bool
    Next() $T
}

func (Slice[$T]) Iterator() Iterator[$T]

// ...

package mypackage

func _() {
    var xs []int = // ...

    for x, y := range xs {
        // ...
    } // Emits the usual instructions for iterating slices

    for x, i := 0, xs.Iterator(); i.HasNext(); x++ {
        y := i.Next()
        // ...
    } // Equivalent, but calls methods

    var ys Iterable[int] = MyStruct{/* ... */}

    for x, y := range ys {
        // ...
    } // Emits the method call equivalent if not a built-in iterable type
}

type MyInt struct {
    my int
}

func (m MyInt) Add(m2 MyInt) MyInt {
    return MyInt{my: m.my + m2.my}
}

// func (m MyInt) Subtract(MyInt) MyInt...
// func (m MyInt) Multiply(MyInt) MyInt...
// All core.Number methods...

func _() {
    var _ = MyInt{1}.Add(MyInt{2})
    var _ = MyInt{1} + MyInt{2} // Same as above because MyInt fully implements the core.Number interface
    var _ = 1 + 2 // Emits the usual instructions for adding integers

    // Same deal for all operations:
    // x << y : x.BitLeft(y)
    // x >> y : x.BitRight(y)
    // &^ : x.BitAndNot()
    // x & y : x.BitAnd(y)
    // x[y] : x.Get(y)
    // x[y] = z : x.Set(y, z)
    // &x[y] : x.GetAddressable(y)
    // ...
}

Emit efficient code for core methods corresponding to operations via function inlining or direct instructions:

var n1, n2 core.Int = 1, 2
var n3 core.Int = n1 + n2
var n4 core.Int = n1.Add(n2) // Same implementation as above, no method call under the hood
var n5 int = 1.Add(2) // Same implementation as above, roughly, no method call under the hood

Add generic type aliases:

type Map[$K Comparable, $V] struct {
    ks []$K
    vs []$V
}

type Dictionary = Map

var _ Dictionary[int, string]

type Callback[$A] = func() $A
type Coordinate[$A Number] = [2]$A
type Counter[$A Comparable] = Map[$A, Int]
type List[$A Orderable] = []$A
type Reference[$A] = *$A
type Set[$A Comparable] = Map[$A, struct{}]

Simplify the language specification by moving descriptions of semantics now specified by generics and the core package into the core package documentation where applicable:

package core // import "core"

// ...

// Uint8 is the set of all unsigned 8-bit integers (0 to 255).
// The value of an n-bit integer is n bits wide and represented using two's complement arithmetic.
// ...
type Uint8

// Integer...
// ...
// For two integer values x and y, the integer quotient q = x / y and remainder r = x % y satisfy the following relationships:
//
//     x = q*y + r  and  |r| < |y|
//
// with x / y truncated towards zero ("truncated division").
// ...
type Integer interface {
    // ...
}

// Orderable...
// Comparison operators compare two operands and yield a typed boolean value.
// In any comparison, the first operand must be assignable to the type of the second operand, or vice versa.
// The equality operators == and != apply to operands that are comparable.
// ...
type Orderable interface {
    Comparable
    $N Greater($N) Bool
    $N GreaterEquals[$N Comparable]($N) Bool
    $N Less($N) Bool
    $N LessEquals[$N Comparable]($N) Bool
}

// ...

Go spec:

The Go Programming Language Specification

[...]

Integer literals

[...] Literals are syntactic sugar for values of types that implement the Integer interface in the core package. See that package for more information. [...] [Or you could list all the possible types that literals can represent, whatever presents best.]

That’s it for generics. There might be more that could be done to simplify and generalize Go with generics, but not without horribly breaking compatibility.

More ideas

While I have you, here are some additional ideas for how to strengthen Go.

Sum types

Go has product types :

type T struct {
    X int
    Y rune
    Z string
} // A value of T has a value for each field at a time

// NumPossibleValues(T) = NumPossibleValues(int) * NumPossibleValues(rune) * NumPossibleValues(string)
// Note the "*" for "product"

Go doesn’t have sum types :

type T sum {
    X int
    Y rune
    Z string
} // A value of T has a value for one field at a time

// NumPossibleValues(T) = NumPossibleValues(int) + NumPossibleValues(rune) + NumPossibleValues(string)
// Note the "+" for "sum"

Other names (more or less) for sum types are coproduct types, tagged unions, and algebraic data types.

Two useful features of sum types:

• Each field has a name to distinguish it, so there can be multiple fields with the same type
• Fields can’t be added, changed, or removed without changing the meaning of the type, so code using the type can know which fields to expect

To see a need for sum types, look at how go/ast.Expr uses an unexported, useless method to limit which types can implement it. It does this so go/ast code only has to handle go/ast types. Grammars, enumerations, and other types that have distinct cases can all be modeled well by sum types. All built-in Go types are sum types that have multiple cases: all the numbers for numeric types, nil and non-nil channels/maps/slices/functions/pointers, empty and non-empty strings, etc.

Here’s a way to add user-declared sum types to Go:

type Expr switch {
    case Index struct {
        X *Expr
        Lbrack token.Pos
        Index *Expr
        Rbrack token.Pos
    }
    case KeyValue struct {
        Key *Expr
        Colon token.Pos
        Value *Expr
    }
    default Bad struct { // The default case is the zero/nil value
        From, To token.Pos
    }
}

func F(e Expr) Expr {
    switch e {
    case Expr.Index{}:
        // e has type Expr here
    case Expr.KeyValue{}:
        // e has type Expr here
    case Expr.Bad{}:
        // e has type Expr here
    default:
        // e has type Expr here
    }

    switch x := e {
    case Expr.Index{}:
        // x has type struct {
        //     X *Expr
        //     Lbrack token.Pos
        //     Index *Expr
        //     Rbrack token.Pos
        // } here
    default:
        // x has type Expr here
    }

    switch e {
    case Expr.Index{}: // Zero value for the case
    case Expr.Index{nil, 0, nil, 0}: // Same as above
    case Expr.Index{X: nil, Lbrack: 0, Index: nil, Rbrack: 0}: // Same as above
    }

    switch e { // "case var" matches patterns of literals or variables
    case var Expr.Index{}: // Any Expr.Index value
    case var Expr.Index{x, l, i, r}: // Same as above
        // x has type *Expr here
    case var Expr.Index{X: x, Lbrack: 55, Index: i, Rbrack: 75}:
        // x has type *Expr here
    }

    var Expr.Index{x, l, i, r} = e
    // x has type *Expr here

    // Structures are consistent:
    type S struct { X int }
    var _ = S{}
    var _ S = S{}
    var S{x} = S{}
    var S{x} S = S{}
    var S{X: x} = S{}
    var S{X: x} S = S{}
    var S{X: _} = S{}
    var S{X: _} S = S{}
    switch (S{}) {
    case var S{}: // Any S value
    case var S{x}: // Same as above
        // x has type int here
    case var S{_}: // Same as above
    case var S{X: x}: // Same as above
        // x has type int here
    case var S{X: _}: // Same as above
    case S{55}:
    }

    return Expr.Bad{123, 456}
}

var _ switch {
    case Red // The type defaults to struct{}
    case Green
    default Blue
} // Value is Blue{}

var _ switch {
    case Red
    case Green
    default Blue
} = switch {
    case Red
    case Green
    default Blue
}.Red{} // Value is Red{}

// Syntactic sugar for sum types
type Color {
    case Red
    case Green
    default Blue
}

// Syntactic sugar for sum-of-product types
type Expr {
    case Index {
        X *Expr
        Lbrack token.Pos
        Index *Expr
        Rbrack token.Pos
    }
    case KeyValue {
        Key *Expr
        Colon token.Pos
        Value *Expr
    }
    default Bad {
        From, To token.Pos
    }
}

Here’s a way to adapt built-in core types into sum types where applicable:

package core // import "core"

// ...

type Pointer[$T] {
    case Pointer {
        Value $T
    }
    default Nil
}

var _ *Int = &Int{}
var _ Pointer[Int] = &Int{}

func _() {
    var p *Int = // ...
    switch p {
    case nil:
    case Pointer[Int].Nil{}: // Same as above
    case Pointer[Int].Pointer{123}: // Forces dereference to compare values
    case var Pointer.Pointer{v}: // Forces dereference to assign value to v
        // v has type int here
    }
}

// For all built-in nil-able types:

type Map[$K Comparable, $V] {
    case Map // Details hidden
    default Nil
}
// ...

var _ map[int]int // == nil == Map[int, int].Nil{}
var _ Map[Int, Int] // == nil == Map[Int, Int].Nil{}

Tuple types

Semantics:

package core // import "core"

type Tuple0 struct{} // The unit type, the tuple equivalent of struct{}

// No Tuple1

type Tuple2[$A, $B] struct {
    A $A
    B $B
}

type Tuple3[$A, $B, $C] struct {
    A $A
    B $B
    C $C
}
// ...

type Tuple20 // ...

package mypackage

func _() {
    var _ = Tuple0{}
    var _ Tuple0 = Tuple0{}

    var x = Tuple2[int, int]{1, 2}
    var x Tuple2[int, int] = Tuple2[int, int]{1, 2}

    _, _ = x.A, x.B
    x.A, x.B = 3, 4 // x is changed

    switch x {
    case var Tuple2{y, z}:
        y, z = 0, 0 // x is unchanged
    case var Tuple2{y, _}:
    case var Tuple2{_, z}:
    case var Tuple2{_, _}:
    case var Tuple2{1, _}:
    case var Tuple2{_, 2}:
    case Tuple2{1, 2}:
    }

    switch i := interface{}(x); i.(type) {
    case Tuple2[int, int]:
    }

    type T Tuple2[int, int]
    var _ = T{1, 2}
}

Syntactic sugar:

func _() {
    var _ = {} // Tuple0
    var _ {} = {} // Same as above

    var x = {1, 2} // Tuple2
    var x {int, int} = {1, 2} // Same as above

    switch x {
    case var {y, z}:
        y, z = 0, 0
    case var {y, _}:
    case var {_, z}:
    case var {_, _}:
    case var {1, _}:
    case var {_, 2}:
    case {1, 2}:
    }

    switch i := interface{}(x); i.(type) {
    case {int, int}:
    }

    type T {int, int}
    var _ = T{1, 2}
}

Constructing and deconstructing tuples:

func _() {
    var {x, y} = {1, 2} // New variables x, y are assigned 1, 2, respectively
    var {x2, y2} {int, int} = {1, 2} // New variables x2, y2 are assigned 1, 2, respectively

    var {x3, y3} = {1, 2}
    var {x4, _} = {1, 2}
    var {_, y4} = {1, 2}
    var {_, _} = {1, 2}

    {x, y} = {1, 2}
    {x, _} = {1, 2}
    {_, y} = {1, 2}
    {_, _} = {1, 2}
}

Functions now take and give tuples where applicable:

func T(x, y int) (int, int) {
    return {x, y}... // Same as "return x, y"
    // "..." deconstructs a tuple into multiple result values in this context
}

func _() {
    var t {int, int} = T(1, 2)... // "..." constructs a tuple from multiple result values in this context
    T(t...) // "..." deconstructs a tuple into multiple argument values in this context

    var {x1, y1} {int, int} = T({1, 2}...)...

    var x2, y2 = T(1, 2)
    var x3, y3 = {1, 2}...

    x3, y3 = T(1, 2)
    x3, y3 = {1, 2}...
}

Sum types work nicely with tuple types:

type Expr switch {
    case Add {*Expr, *Expr}
    case Sub {*Expr, *Expr}
    default Num int
}

func Eval(e Expr) Expr {
    switch e {
    case var Expr.Add{l, r}:
        var Expr.Num{x}, Expr.Num{y} = Eval(*l), Eval(*r)
        return Expr.Num{x + y}
    case var Expr.Sub{l, r}:
        var Expr.Num{x}, Expr.Num{y} = Eval(*l), Eval(*r)
        return Expr.Num{x - y}
    case var Expr.Num{_}:
        return e
    }
}

var x, y, z Expr
var _ = Eval(Expr.Add{&x, &y}) == z // True

Represent function signatures with structures

Last one. Let’s get crazy.

Notice that structures:

type Args struct {
    x, y int
    f, g float32
    s, t string
}

look like function signatures:

func Args(
    x, y int,
    f, g float32,
    s, t string,
)

That’s kinda weird, isn’t it? Shouldn’t different things be different, if we want feature orthogonality?

What happens if you make a function signature like a structure type, or vice versa?

You can have vararg structure values:

type OneOrMore struct {
    One int
    More ...int
}

var _ = OneOrMore{1, 2, 3, 4}
var _ = OneOrMore{1, myInts...}

That’s kinda cool.

You can have compact, one-line structure types like function signatures:

type Args struct{ x, y int, f, g float32, s, t string }

That’s kinda nice.

You can have value constructors that can act like real functions:

var _ = Args{1, 2, 3.4, 5.6, "7", "8"} // Equivalent to:
var _ = Args(1, 2, 3.4, 5.6, "7", "8") // Looks like a function call, but implemented like Args{...}
var _ func(int, int, float32, float32, string, string) Args = Args // Acts like a function value if not called immediately

That’s kinda neat.

You can use structures as bulk arguments and results:

func F(x, y int) (z int, err error)

func _() (int, error) {
    var arg struct{ x, y int }
    var result struct{ z int, err error }
    arg.x = 1
    arg.y = 2
    result = F(arg...)... // "..." adapts between structures and signatures
    z := result.z
    err := result.err
    if z > 0 {
        return z + 1, err
    }
    return result...
}