6 ms·
I had the same feeling first. But practically in my code, I found that ok, you need to copy/paste a bit first but then if it works it stays there, you are not "
by Loic 11y ago
I had the same feeling first. But practically in my code, I found that ok, you need to copy/paste a bit first but then if it works it stays there, you are not "sorting" new kind of "types" every day. The time spent on coding is way more "around" the algorithms than "within" them.
I suppose that we will see more and more code generators which will practically remove the need of generics. We already use them without complaining for serialization in JSON/Protocolbuffer/etc...
- jcoffland 11y agoIf you're copying and pasting then you're doing it wrong.
- chillydawg 11y agoNot in go. You're allowed to in go. Because some googlers reckon that's cool.
- coldtea 11y ago>you are not "sorting" new kind of "types" every day You'd be surprised.
- Loic 11y agoI am writing a chemoinformatics database, so for my practical use, these are a lot of lines of codes with pretty involved algorithms and I am practically not annoyed by the lack of generics. For the ones down-voting me, have you coded something in Go, big enough to be a real in production project, where at the end the lack of generics is a real issue (performance because using interfaces or maintenance because copy/paste to have the performance)?
- codygman 11y ago> For the ones down-voting me, have you coded something in Go, big enough to be a real in production project, where at the end the lack of generics is a real issue (performance because using interfaces or maintenance because copy/paste to have the performance)? Didn't downvote you, but yes I have.
- coldtea 11y agoI'm part of a project team that uses quite a lot of Go in production (for analytics work), and lack of generics was particularly painful. >(performance because using interfaces or maintenance because copy/paste to have the performance)? I don't like interfaces (namely, interface{}) for their lack of safety for generic work -- performance comes second to that. And I don't like copy/paste like ever. >For the ones down-voting me, have you coded something in Go, big enough to be a real in production project, where at the end the lack of generics is a real issue (performance because using interfaces or maintenance because copy/paste to have the performance)? Isn't that a sure fire way to selection bias? The ones that ended up coding something significant in Go will usually be those that put up with the Generics issue (or don't even know what they are missing). It's like asking C programmers if they mind missing GC, closures, etc. It's not like the utility of Generics is some open question in PL either. It's a settled matter. Even Go uses them, but doesn't offer them to the programmer, or suggests generic but not type-safe solutions like interface{}.
- colin_mccabe 11y agoI wrote some big things in Go and didn't find the lack of generics particularly problematic. Different languages are good for different things-- Go is good for building things that are relatively concrete. For something like a symbolic math package or a scripting language you might want a different language that makes different tradeoffs.
- alkonaut 11y agoIf code generation is used to make up for something missing in a language (be it generics, metaprogramming etc.) then that's a pretty clear sign something is wrong. It's definitely acceptable to use a workaround for a missing feature once or twice in a language, because no language is perfect, and no language benefits from being burdened with all features imaginable. But if a workaround becomes part of the day-to-day workflow, then you are likely using the wrong language. Examples could be: using (textual) code generation for generics, or using type annotations throughout a dynamic language project.
- thegenius2000 11y agoWell put. Though I would add that though generics are convenient, they are not as needed nearly often enough to be a crucial missing feature in a language. Yes, it's uncanny to copy here and there, and certainly, the Go team should try and resolve this. But from where I'm standing this (i.e. generics) is one of the very few fair criticisms of Go which can be leveled from the Java, C++ or C# communities.
- Arzh 11y agoCode generation is not about a deficiency in the language, C++ has templating but I will often use code generation since you only need to run that once and templating bloats the compile time for ever.
- tacos 11y agoJunior programmer alert.
- nanny 11y ago>I will often use code generation since you only need to run that once and templating bloats the compile time for ever. Don't you need to compile the generated code?
- prodigal_erik 11y agoFor reproducibility you have to regenerate, write, read, and parse it, which I can't imagine being faster than instantiating a template in memory.
- parenthephobia 11y agoI don't think we will. The Go community doesn't hate protocolbuffers, but it does tend to think that generics are evil and shouldn't exist. I'm certain that generic generators will be shunned by the community at large, due to solving a problem they don't believe needs solving. Without the network effect to build up a user and developer-based, they'll languish in obscurity. I sure would like to be wrong, though!
- saturn_vk 11y agoI haven't seen any indication that the community hates the idea of having generics. The contrary seems to be the case.
- serge2k 11y agoSeems like they talk a lot about how it's a problem but don't put the effort into solving it. In other words, they aren't interested in getting generics. Not really.