It's hard to avoid, because (naming aside) the cognitive load is caused by higher order functions, which are hard avoid without causing massive code duplication.

I understand the desire to keep things concrete and avoid high level abstractions, but it's a decision not to automate stuff that can easily be automated. It runs counter to the basic instincts and purpose of our field/industry. That's why it never sticks.

We often forget that our profession (computer programming) belongs to STEM. Some (like Go 1.0 :)) wish to think it is Arts & Humanities. The sooner we realize that yes, it is OK and actually expected to bear a cognitive weight of "(b Box[T]) Map[U any](f func(T) U) Box[U]" the sooner we get back to reality... :)

I think naming conventions might help:

    (b Box[InType]) Map[OutType any](transformFunction func(InType) OutType) Box[OutType]

    def map[U](self, f: Callable[[T], U]) -> Box[U]

    def map[OutType](self, transform_function: Callable[[InType], OutType]) -> Box[OutType]

    public <OutType> Box<OutType> map(Function<InType, OutType> transformFunction)

    public <U> Box<U> map(Function<T, U> f)

I never understood the convention of using single letter names for generic parameters. I guess this started in C++ and every language has copied that convention.

I think that code would be a lot easier to read if the types were called IN and OUT or In and Out or TIn and TOut or something like that.

Indeed, we're now one step away from monads. I know https://go.dev/doc/effective_go hasn't been updated for while, but it also seems to have been forgotten. "Go is an open-source programming language that focuses on simplicity ..." the page begins.

Maybe it's just familiarity, but I think it would look a lot more comprehensible with some punctuation. Just because a syntax is formally unambiguous doesn't mean it looks that way to humans.

    func (b: Box[T]).Map[U: any](f: func(T) -> U) -> Box[U]

It's not good Go code anyway. In Go you would use a for loop. Just because Go has generics nowadays doesn't mean you should abandon good taste and write ML/Haskell/Rust/C# in it.

I really understand your feeling, I escaped from C++ years ago when I was overwhelmed by meta programming (initially i loved it).

But anyway I find this in Go much more bearable.

Right? Sigh. I really dislike this.

There are 37000 programming languages, stop forcing every single one that gets popular to look like this.

It looks more reasonable (literally lol) with syntax highlighting though.

> (b Box[T]) Map[U any](f func(T) U) Box[U]

  Map method 
    of b (of type Box[T]) 
      that takes f 
      (of type function that takes value of type T and returns value of type U (which could be any type))
      and returns value of type Box[U]
  is defined as follows
    return Box[U]{v: f(b.v)}

  func[U any] b:Box[T].Map(f:func(T)->U)->Box[U]:
    return {v: f(b.v)}

  func[U any] Box[T].Map(f:func(T)->U)->Box[U]:
    return {v: f(this.v)}

  // maybe all of the types could be inferred from usage?
  func Box[].Map(f):
    return Box[]{v: f(this.v)}

The Go team is addressing that in the release notes: https://go.dev/doc/go1.27 They think it will only affect use cases where a high number of idle connections were allowed to linger, for instance by setting MaxIdleConns in Transport to 0. They recommend to disable keep alives in that case.

Can you go more into this? I don’t quite follow

I do wonder whether, as a group of people being regularly exposed to text written by LLMs, we'll gradually end up writing and talking like that in our normal language. At that point perhaps text written by LLM and human will be indistinguishable. I already find myself using terms like 'footgun' in jest more than I ever did before!

"The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which." ― George Orwell, Animal Farm

The entire thing is obviously LLM generated. Much better off just reading the release notes.

Worth flagging, real gap, transparent win, center of gravity... I'm tired boss

This post seems to be mostly llm generated

stared at it for a bit and im mostly certain i prefer it to java. at least writing other go = its not bad for me to break apart the signature line on a generic

java feels kinda unhinged the more that i look at it

    public static <T extends Comparable<? super T>> T max(Collection<? extends T> c)

    Map<String, List<Map<Integer, Optional<Pair<String, Function<? super List<? extends Comparable<?>>, ? extends Map<String, ?>>>>>>> config;

It is verbose but inference helps a lot to keep it “tidy”. I always find myself increasing my focus a notch when I start dealing with generics. It’s one of the things I use only if I really “need”.

It does, but at the same time it's not "normal" code; I see it much like Typescript's advanced types, ultimately it's something that mainly lives in libraries.

imho it is much better that C++ equivalent

Probably won't/cannot be ımplemented. C++ and Rust disallow the analogues of this (templated virtual methods/dyn with a trait containing methods taking type parameters) as well.

You can take my place, as the same changes make me want to leave.

Yes, thinking in higher order abstractions is hard for most people.

As of June last year[1] the Go team have pretty much drawn a line under this issue, with a very small amount of wiggle room to possibly reopen it at some point:

"For the foreseeable future, the Go team will stop pursuing syntactic language changes for error handling. We will also close all open and incoming proposals that concern themselves primarily with the syntax of error handling, without further investigation.”

Personally I'm OK with this, I didn't see any of the (many) proposals as a definite improvement. They all had trade-offs.

[1] https://go.dev/blog/error-syntax

No.

I kind of want to leave it there. But that will probably be looked on disfavorably.

I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading:

    val, err := whatever(...)
    if err != nil {
        // handle error
    }
    // use val

    val := whatever(...)
    if err, isErr := val.Error(); isErr {
        // handle error
    }
    realVal := val.Value()
    // use realVal

There's also no win in trying to offer a monadic interface like

    finalVal := whatever(...).OnVal(func (val Value) opt.Option[Result] {
        // use val
    })

Really the solution is, install golangci-lint, turn on errcheck [1], use a pre-commit hook to make it a commit failure if golangci-lint fires, and that pretty much covers the problem in practice.

One of the problems with Option/Result/etc. advocacy... not the pattern itself, the advocacy... is that it is generally are presented, implicitly or explicitly, as if the alternative is C, with its errno and the need to not just check an error value, but remember to go actively seeking out errors constantly, making it easy to forget. But by modern standards, that's completely pathological.

If we rate error handling techniques on a scale from 1 to 10 (best), C here is a 1, and standard Option is maybe an 8 or a 9. The way Go does it is maybe a 6; it is completely true that you can neglect to handle an error (see errcheck comment in previous paragraph), but it is in your face that an error is possible, and that's really most of the problem. Putting Option/Result/etc. is not always a "go from 1 to 9" result. "Go from 6 to 8" is a much less impressive proposition, and the other inconveniences that come with it in Go tend to overwhelm the gain. I use errcheck all the time, and even in the Before Times when I was writing it all by hand it really didn't fire all that often. Especially if I exclude test code. In an AI era this hardly rates at all. AI never neglects the error.

Whether it does the right thing with it, now... that's another story entirely.

Read those error handling clauses if you're writing Go with AI. I really don't like what I've seen AIs do with them by default. What I've seen out of AI has been very thoughtless. Nominally correct in some weak sense, but thoughtless.

[1]: https://golangci-lint.run/docs/linters/configuration/#errche...

Methods on generic types were already a thing. What is new is that methods can now define their own generic parameters, independent of the type they are defined on.

Generics themselves maybe not. Generic methods probably yes. What people want generic methods for is to do deeply nested call chains that were never typical of Go. And if you have deeply nested calls you'll need some way to deal with errors in deeply nested calls, and then a short function syntax to pass to behavior inside those deeply nested calls. Give it a few years and everyone will be writing the same functional slop in Go that they are writing in every other language.

Not here against Generic methods, but I feel the Go team is in a mid-age crisis where they lack of new things to do to prove themselves. See their iterators mini-drama not long ago?

I feel the sumtype/emum/routine demanders should yell a little harder so Go team can find their purpose again.

> generics were a slippery slope. give it a decade and Go will be indistinguishable from c++

Lib boost will have conquered every language by then!!! :D

Jokes aside, generics are unusable in a lot of languages due to their syntax choices. In Go we kinda have the problem that there's no real templating and no real macros, so they're even harder to use.

But I agree somewhat, generics feels to me like an anti pattern in Go.

Also, the way the Go core/stdlib is written, it makes generics so unnecessarily painful to debug. Why they decided to have definitions like "~C" or "~[]S" is beyond me. No human knows what the resulting compile time error means. They should have named these things "Comparable" or "Slicable" or whatever is more expressive. Just stop with this stupid single letter shit.

Tried reading your comment but ran into a lack of usable information.

(I was on the Go team for ages)

Seriously, that's all it was. Just Ian alone proposed and rejected a half dozen of his own different approaches to generics. Finally a language + implementation plan came together that people all liked.

Nobody was ever opposed to generics that I saw.

If bug free binary search implementation can take 16 years, I am ready to buy generics implementation could take 20 years.

> In his landmark book The Art of Computer Programming, legendary computer scientist Donald Knuth noted that although the first binary search algorithm was published by John Mauchly in 1946, the first bug-free version was not published until 1962—taking a staggering 16 years to get right.

It’s also not true that because it wasn’t part of the initial design that it was harder to retrofit. I just don’t understand all this go bashing that happens on this site especially when so much is badly informed speculation. I guess it’s easier to tear something down.

Surely it was pressure from devs to make Go look like every other language they begged to change then abandoned for the new hotness.

Unfortunately nothing changed. They wanted generics all along.

The Go ecosystem was a delicate, special thing. It was a wholesale rejection of the malignant consultancy takeover of programming that had festered and spread for the previous 15 years. Introducing generics was a grievous error, and they just keep making it worse.

It used to be you could look at any Go code from any author and pretty much instantly understand it completely. That’s no longer the case.

It used to be you would work on a problem, just writing the code from top to bottom. No time wasted fiddling with abstractions you’ll never use. You’d grumble about it, but succumbing to the temptation was impossible. That’s no longer the case.

and they're still worse than the 1970s state of the art lol

> what changed in the perspectives of the language maintainers?

The original maintainers moved on to other projects and the new community maintainers came to a consensus through the proposal and governance process.

No

Go Generics work differently than those in Java. They are specialized, meaning that they are not generic at runtime anymore. Instead, the compiler creates a different implementation for each type.

At runtime, there are only List[int], List[string], etc. List[T] is not a thing anymore.