3 ms·
Rather than writing multiple functions that take different types as args and return different types (say int8, int16, int32, etc.) but do the exact same thing,
by w8rbt 8y ago
Rather than writing multiple functions that take different types as args and return different types (say int8, int16, int32, etc.) but do the exact same thing, with generics, you can instead write one function that takes a number (which could be any int type) and return a number, and you only wrote one function. That is generics in a nutshell. The function is generic, not specific to one type.
Generics allow for less code, thus they are easier to debug, test and reason about. I've used them a lot in C++ and I do miss them in Go. It's not a deal breaker for me either way, but for people who write larger, more complex code, not having them makes it more difficult (more code to write, test and maintain).
C does not have generics either. Go is a lot like C in this regard.
- mrfusion 8y agoWouldn’t this make golang slow though? Isn’t that what people claim makes python slow?
- w8rbt 8y agoNo. C++ is very fast. It has generics.
- AsyncAwait 8y agoAlso, very slow to compile.
- shakna 8y agoIn a ahead-of-time compiled language probably not. The generic function is just a code generator for several functions that will get called in the right places, generated and put in the right places by the compiler, and then get optimised as per normal. And no, being a dynamic language is not what makes Python slow. Lua, Nim and Scheme are all examples of dynamic languages with fast implementations.
- mrfusion 8y agoNow I have to ask, what would you say does make python slow?
- shakna 8y agoDesign choices, to be blunt. Some of it is simple stuff, like CPython being interpreted, so PyPy get's a huge boost by JITting. Some of it is much harder stuff, like the way Python is designed to store objects in memory (a list is a pointer to a contiguous space of pointers to things that might be pointers...), and everything that hangs off each object (everything has a dict), and the awful GIL ([0]). Awful for performance, great for thread-safety. Every single part of a language design has trade-offs. It depends on what you're trying to do whether or not they help you, or hinder you. Sometimes you change how you're doing things because priorities change, and get a radical improvement, like Python's 3.6 Dict. Most of the time, you don't. One step at a time. Not being able to break backwards compatibility hinders the designer, if they realise a trade-off they've made was a mistake. So you get stuck with some features you'd rather not have. [0] https://wiki.python.org/moin/GlobalInterpreterLock https://wiki.python.org/moin/GlobalInterpreterLock
- johncolanduoni 8y agoTo be fair, all of the aspects of the language itself you mentioned apply to JavaScript (save perhaps differences in how literally it takes `int`, etc. being objects vs. JavaScript's unboxed `number`, etc.). I suspect most of the difference is that one has had three of the largest corporations in the country competing to have the fastest implementation, in some cases for decades, and the other hasn't.
- zbentley 8y agoI think a bigger reason is that Python prioritizes simplicity of internal implementation. To be sure, the internal implementation of CPython (the only one I'm familiar with) is complicated as hell. But it's a whole lot simpler than any fast JavaScript runtime I've ever used. I think that's the result of a conscious choice by the maintainers/BDFL/community in Python, not a side effect of it having less funding (assuming that's the case).
- notduncansmith 8y agoI don’t think it necessarily impacts the runtime (though it could). This could be my naïveté, but I don’t see why generics in Go couldn’t work analogously to the way they do in TypeScript, just a way for the compiler to verify the correctness of code accessing an interface{}.
- pjmlp 8y agoC has minimal generics support since C11.