Codegen is a super flexible and versatile tool, and simply having a strong generics feature does not mean you can avoid it: at $DAYJOB we use codegen even for C++ for e.g. grpc/openapi types, generating rapidjson streaming unmarshallers, etc not even counting Qt's moc/uic.

I understand and agree, I've run many a Java project that used codegen to emit Protobuf/Avro IDLs as types.

But Go having actual generics, and accordingly removing some need for codegen, is not a bad thing at all.

No, I do believe Go will be improved if it allows library maintainers to implement some things like new collection types and utilities using generics.

I for one won't be using more advanced functional coding though, it's a lot more difficult to read / parse and the language is not designed with functional programming in mind. I'm sure people are already working on a functional programming library so you can do map / reduce / filter and the like, but readability and performance will be dreadful.

Strongly agree. Some people like to be on this endless treadmill of cutting edge features, like in this case parametric polymorphism but I refuse to be dragged in. They just make the code more complex with no benefit.

Next thing you know they will try to force me into structured programming (I'm sure there are people already working on do...while). They can pry goto from my dead cold hands.

Look, I'd just kill for a generic Set, tbh.

I've come to prefer code quantity over code complexity. I mean, what the fuck is

    def traverseImpl[F[_], A, B](fa: Option[A])(f: A => F[B])(implicit F: Applicative[F]) =
      fa map (a => F.map(f(a))(Some(_): Option[B])) getOrElse F.point(None)

This is probably less readable than it has to be due to the lack of whitespace. I don't know the language (Scala?), but I don't think it's too hard to work it out. First, the '[F[_], A, B]' part are type parameters, where I assume the 'F[_]' part is just a bad notation for a type of kind '* -> *' (i.e. a higher-ranked type). The next value parameter has type 'Option[A]', and after that we have 'A => F[B]'. This confirms my suspicion that 'F' is a higher-ranked type - and probably a functor or something. The 'f' parameter is a function for converting a value of type 'A' into a value of type 'F[b]', which looks like it's tranforming a value and putting it into a functor or something. The final '(implicit F: Applicative[F])' hints at deep problems in the language, but I think it basically just says something like 'the higher-rank type F must implement the trait/typeclass/whatever Applicative'.

That's the type. The expression makes little sense to me, but I suspect you removed a bunch of dots and maybe some parens, and it should actually look like this:

          fa.map (a => F.map(f(a))(Some(_): Option[B])).getOrElse(F.point(None))

So this function essentially just operates on an option value inside of some functorial context. This seems like a building block function that you might use often, but probably not write very frequently.

(If you didn't remove anything, then I suppose this language has infix 'map' and 'getOrElse' operators. I think that's bad, but it's not related to the type system.)

scala has infix everything ‘operators’. f(x) can be written as f x and f.g(x) can be written as f g x if the parser manages to figure out what it means (I’m sure they phrase that differently)

Idea, I think, is to make the repl look more like a CLI, but it also may be a fight against punctuation.

Its only hard to read because you don't know the language, otherwise, its fairly straightforward. Although the Applicative type would require some research. I would much rather use a language like this, that can create enough abstraction to enforce consistency throughout the codebase, rather than relying on boilerplate conventions. Just had a bug this week in Go where a previously defined "err" variable was re-used instead of creating yet another "err" variable, which caused the actual error never to get checked.

This function is certainly hairy, but its use in the codebase might very well be intuitive and simplify code that would otherwise be way less expressive. I personally think it can be worth it.

Transform fa using f, collecting the results as an option

What is funny about it? People have worked around deficiency of systems since forever in almost every field. Is it something you have never seen in real life?

C++ and Java also used codegen before they got templates and generics respectively, but since Go's matra is to relearn history, they had to have a go at it.