Pointing people at the spec is probably the best decision the Go team ever made. Why wonder about things when you can have true authority in an honestly very short piece of text? No guessing, just an exact description of what's going to happen.

(I was in there recently reading about operator precedence recently and discovered an operator I didn't know existed, "bit clear (AND NOT)", &^. Amusingly, I needed to do that operation but wasn't sure if I needed parentheses for X & (^Y) or not. I still don't know why it's a dedicated operator, however. The spec rarely says WHY, just WHAT.)

The one that got me was the implicit wrapping of structs into interface types. As an example, the below code segfaults with `fatal error: panic while printing panic value: type runtime.errorString`:

    package main
    
    type SomeError struct {
        SomeMessage   string
    }
    
    func (se *SomeError) Error() string {
        return se.SomeMessage
    }
    
    func doSomethingSomeWay() *SomeError {
        return nil
    }
    
    func DoSomething() error {
        return doSomethingSomeWay()
    }
    
    func main() {
        err := DoSomething()
        if err != nil {
            panic(err)
        }
    }

      func doSomethingSomeWay() *SomeError {

Go101 is a jewel of a resource. It’s a spec written by an impartial observer not worried about trying to make golang look good but instead giving you the understanding to avoid all the edge cases

https://go101.org/

> interface{} and any behavior differences,

I'm curious now. They are type aliases. In which situations there is a difference in behavior?

   func f[T any]() {}
   func f[T interface{}]() {}

   func f(x any) {}
   func f(x interface{}) {}

In go, the stdlib impl is actually:

    func Clone[S ~[]E, E any](s S) S {
      if s == nil {
        return nil
      }
      return append(S([]E{}), s...)
    }
    

For comparison, `vec.clone()` in the rust stdlib is:

    pub trait Clone: Sized {
      fn clone(&self) -> Self;
    }

    impl<T: Clone> Clone for Vec<T> {
      fn clone(&self) -> Self {
        <[T]>::to_vec(&**self)
      }
    }

I think the rust one is much easier to read. The go one has an if statement, which means the go one has higher cyclomatic complexity, and is thus harder to understand and reason about.

The rust one does have "&**self", which looks a little strange perhaps, but overall seems simpler than the go one.

I'm okay with code like this being tucked away in the std lib (or a 3rd party library) IF it makes my own code easier, and in this case it does since calling it is just

    c := Clone(ms)

(which is highlighted in the article)

You have to click through to read the assignability rules. A very short summary is that people often create new types based on core types. For example:

   type Name string

Now you can define methods on Name:

   func (n Name) Foo() { ... }
   ...
   x := Name("Me")
   x.Foo()

But, you can't use Name and string interchangeably:

   func StringFoo(x string) { ... }
   StringFoo(Name("Me")) // does not compile

In the case of generics, maybe you want to write a function that can handle any string:

   func Bar[T string](x T) { ... }
   Bar(Name("Me"))
   Bar("Me")

This doesn't compile, because Name isn't assignable to string. The fix is to declare the type parameter as [T ~string]. (The compile error suggests this, in fact. You can also write string(Name("Me")) but if T were being used as the type of the return value, the returned value would be type string, not type Name.)

In the case of slices, it can be more complicated. These types all seem similar, but aren't the same:

  []string
  []Name
  type StringSlice []string
  type NameSlice []Name

The idea of the article is figuring out how to write a generic type signature that would accept any of these and return the right type.

Finally, you can rename types and use them interchangeably if you don't want the "safety" of making a new type:

  type Name = string

Now you can't write methods on Name, but you can use Name and string interchangably. (This, incidentally, is how "any" works. The package builtin contains "type any = interface{}".)

If the complaint about syntax is not using <T type> to denote type parameters like Java and C++, [] simplifies the parser. You can read the original generics proposal for all the details.

The language and way of writing feels very weird. The concepts are simple genetics but for some reason I don’t get the idea of underlying type. Wish they used a more formal language

My guess is that originally, the post didn't have "// body omitted" below.

The actual implementation requires having the `S` type to refer to, and the point of this post is to explain why the `S` type has to be named. By writing it as they did, the "// body omitted" one _could_ have had the same body, even without an 'S' type to refer to.

I bet the "// body omitted" bit of the post got refactored, and the reason for making the first one different from the stdlib impl got lost.

The generic function is cloning a slice so you need to allocate a new backing array. (think deep-copy)

Here that's just a one-liner that works.

I need to check but I think that if you need to keep the same capacity, you may want to preallocate manually.

The logic for inferring types plays out better for the first. Go limits the depth of searching for type inferences, to keep compilation fast/small/simple. It’s always possible to be more explicit but nice to infer when calling generic code.

Is the order of function parameters significant?