So you'd rather take a half-dozen, half-assed implementations of templates, macros, flaky cast-to-interface things and a bunch of incompatible weirdness rathern than a singular, reasonably effective pattern that's been proven successful over literally hundreds of programming languages?
Re:Toward Go 2
by slantedview on Thursday July 13, 2017 @03:37PM
(#14764464)
> Conversely, I would stop using Go in my projects if it introduces generics
Depending how they're implemented, you might not have to use them (even via libraries). Not using the language altogether is a bit dramatic.
Re:Toward Go 2
by erikpukinskis on Thursday July 13, 2017 @05:46PM
(#14765559)
That's never really true, because using a language means using other people's libraries, and using libraries means debugging and extending them, so you eventually end up needing to work with anything the language can serve up.
This is my beef with JavaScriot these days... They introduced a slew of new, in my opinion insane, control structures, and while I can avoid them in my code, they are still slowly polluting my dependencies, and adding obscure runtime requirements for my projects.
If Go wants to be more sophisticated, there are other sophisticated languages I can use out there like Haskell, Rust, F#, Scala, etc. The problem I have learned in my career is "sophistication" usually gets in the way of getting things done because now you have all these clever developers full of hubris creating these novel implementations that nobody else in the world understands, and your project fails but hey -- at least you have a dope, terse, generic implementation -- totally rad.