Generic methods arrive in Golang, but they weren't the top dev demand

The Go team has approved generic methods, reversing a longstanding position in the language's FAQ. The proposal, from Go co-designer Robert Griesemer, now moves to implementation. A key issue – that Go interfaces cannot include generics – will remain. The earlier view was that since generic methods cannot implement interfaces …

[chololennon]

Here we "go" again...

How many programming languages started with the selling motto, "simpler than C++"? Java, Go, etc. At some point in their own history they had to introduce C++ features (like generics) because otherwise the language didn't scale well with large projects. In this regard, I always cite the following Python example: for years Pythonistas justified with strong silly arguments the nonsense of not having a simple switch case (you can use a dictionary or if elif, they always said, OMG!). Since Python 3.10 the language has a match case statement, why? if it wasn't "necessary". TypeScript as a replacement for JavaScript is another big example ("types are not needed", yeah, until your project grows. The same applied to Python before the introduction of Type Hints in v3.5).

In the end all programming languages end up being much more complex than when they started, which is reasonable. The problem, IMHO, is denying the need for a feature, or the stupid comparison with C++ (maybe in the future, Rust will have proper ctors, method overloading, or do while loops :-P who knows?).

[Elongated Muskrat]

Re: Here we "go" again...

TypeScript as a replacement for JavaScript is another big example ("types are not needed", yeah, until your project grows.

TypeScript, also known colloquially as AnyScript for obvious reasons (reasons: any)

[chololennon]

Re: Here we "go" again...

> TypeScript, also known colloquially as AnyScript for obvious reasons (reasons: any)

Well, that's a problem with the mindset of some (dynamic) programmers (*). I used a lot of TypeScript in production code without a single "any" (no type, no code review approval). If a team/company decided that TypeScript must be used, then they must enforce its correct usage; there should be not place for lazy programmers.

(*) I come from static languages so I understood the benefits of types, especially in huge code bases.

[Elongated Muskrat]

Re: Here we "go" again...

Yeah, well-written TypeScript is better than well-written JavaScript, but because it's so trivial to circumvent its type safety, and developers* who are familiar with JavaScript or who are working with legacy JavaScript code are likely to be under pressure to "just make it work", what you often end up with is hastily-written JavaScript peppered with :any, hence TypeScript being colloquially known as AnyScript.

*if you can call most JavaScript programmers developers; many are closer to script kiddie.

[sured]

Re: Here we "go" again...

A switch Vs. if-else argument is kind of moot in any language as they both satisfy the logic you want and probably optimize identically.

Typescript being needed is a argument of syntax Vs. function. Is the syntax needed if you can use the benefits of Typescript without using Typescript syntax?

I do feel comparing C++ to simpler languages is legitimate for arguing the denial of features in simpler languages, same as your sentiment. Any language can be a role model.

IMO, the only people who start new Go projects are the people who are already tattooed by previous Go projects. However, for the applied areas Go currently has, Go seems a better choice than Java or .Net.

[O'Reg Inalsin]

Re: Here we "go" again...

Typescript is in the process of being rewritten. Originally written in Typescript (self) it is now being rewritten in Go.

https://devblogs.microsoft.com/typescript/typescript-native-port/

[Elongated Muskrat]

Re: Here we "go" again...

What aspect is in the process of being rewritten? The compiler that turns it into JavaScript that a browser can execute? A server-side execution environment of some kind?

TypeScript itself is just a language specification; it's written in English. Surely the whole point of scripting languages is portability, so an execution environment written in Go (amongst others) should be no great surprise.

[Kevin McMurtrie]

Re: Here we "go" again...

Go created its own problems by having so many insane fanatics. They must use Go even where it doesn't fit, so everyone around them wishes it was more like the languages that should have been used. The maintainers of Go insist that it's perfect and you're doing it wrong. It easily became my least favourite modern software language.

[Bebu sa Ware]

Re: Here we "go" again...

I always think when better known languages engage in a little argy·bargy over generics and polymorphism, that Bertrand Meyer's Eiffel has been doing both since almost forever.

There was a cartoon of a Unix graybeard flicking a PFY a coin saying "here's a dime kid - get yourself a proper OS." (More or less.)

A smug French Eiffel programmer might flick Euro to coding polloi say "here is a Euro - get yourself a proper language! †." :)

_{† If you pardon my French perhaps Prenez cet Euro et achetez un langage informatique moins merdique.}

[42656e4d203239]

Re: Here we "go" again...

>>Prenez cet Euro et achetez un langage informatique moins merdique

Miles Kington would have been impressed... Franglais without the Anglais! I don't know if merdique translates to shittified/shit-like but it should!

[trevorde]

Re: Here we "go" again...

Did a small project in Go a few years ago. It's got some nice features but I couldn't decide if it was an upmarket C++ or a downmarket C#.

[mili]

And draw us from evil

It's sad - I thought this from the beginning: Robert, now you're saying generics won't come, but once all planned features are in, there might be no better candidate than to work on generics.

Ok, generics make things simpler for the human coder in some cases, but they also obfuscate and cause drama, because they are abstract.

The nagging mostly comes from all the wrong people, those who want to infiltrate a clean and straightforward programming language with all the unhealthy stuff from their other choices.

[NetMage]

Re: And draw us from evil

Exactly how are generics abstract?

[Elongated Muskrat]

Re: And draw us from evil

Taking the following: (C# because the syntax is clear*)

public int FindHigherInt(int i1, int i2) => ( i1 < i2 ? i2 : i1 );

public T FindHigherComparable<T>(T p1, T p2) where T : IComparable => ( p1.CompareTo(p2) < 0 ? p2 : p1 );

The second, using a generic, is more abstract that the first, using a concrete type, because the type itself has been abstracted, in this case to any type that implements IComparable.

It's the same way that an interface is an abstraction from the implementation.

*may not compile, no warranties are provided, code is for demonstration purposes only, doesn't deal with equality, etc. etc.