Hacker News new | past | comments | ask | show | jobs | submit login

Isn't "generics for me but not for thee" already a core part of the Go philosophy?



No, you are trying to justify odd builtin functions choice in retrospect. Nobody has ever said that Go "secret generics" are a core part of the Go philosophy but you.

The reason they exist is because Go language designers could not do without them. The same people that have claimed for years that Go didn't need generics.


I don't think "for me but not for thee" is an attempt at justification, fyi.


I can confirm. It was not an attempt at justification.


> The same people that have claimed for years that Go didn't need generics.

Considering all the successful software that's been written in Go, they weren't exactly wrong.


I don’t think that’s a valid argument. Firstly, successful software has been written in languages that we would call atrocious nowadays.

Also, even if go were better than all other languages, it still might not be perfect.

Let’s say there are 10 ‘objectively good’ programming language features.

If most languages have 7, but go has 8, you still can complain about wanting the two other ones.


> Considering all the successful software that's been written in Go, they weren't exactly wrong.

Considering all the successful software written in PHP...? Or Javascript...? Java...? Your argument absolutely has nothing to do with my point.


I think you're confusing "want" with "need"


Successful software has been written in every mainstream language. That does not mean that these languages all have no room for improvement.

"Langues do not need function calls, successful software has been written in assembly" is a pretty weak argument.


Seems like the infrastructure built with it requires it at a certain point.

https://medium.com/@arschles/go-experience-report-generics-i...


>Considering all the successful software that's been written in Go, they weren't exactly wrong.

How much of that software doesn't use Go's internal generics?


Once upon a type I was also writing successful software in Assembly, Clipper, Turbo Pascal, Turbo Basic, C, ....

It is such a lousy metric "if it is used it is good".

Well PHP and JavaScript are also used, a lot, even more than Go, most likely bringing home much more revenue as well.


By that logic, why update Go with _any_ new features? Just because something can be used as-is doesn't mean that it can't be improved




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: