I'm kind of sad that they didn't allow you to use inuktitut characters as a joke about this classic comment.
https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
Golang generics proposal has been accepted
121–130 of 176 posts
Re: Golang generics proposal has been accepted
#122IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large code…
> Even templates in C++ are notorious for puking near impossible to decipher errors. "Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.
This is why I've always hated C++. Taking something like templates, and abusing the turing-completeness of it. If I wanted macros I would use a language that actually supports them so I wouldn't have to resort to byzantine hacks. Stuff like this is why lots of people would rather use C over C++.
Re: Golang generics proposal has been accepted
#123Earlier quoted context omitted.
Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.
I think you want generics for many useful sum types (e.g. options) so you don't have to repeat your sum type definition everywhere it is used. Also, you can have options and matching without sum types (e.g. scala).
btw. scala 3 might change that. there is a language feature which can be turned on to have explicit nulls, which will be in the form of union/sum types: https://dotty.epfl.ch/docs/reference/other-new-features/expl...
Re: Golang generics proposal has been accepted
#124Earlier quoted context omitted.
I'm made out of meat, the compiler is always going to be millions of times faster than that. Are generics actually slower than codegen plus parsing the same method body over and over with different types?
> meat Flesh to me. (vegan) :)
Heh, it's a reference to https://www.mit.edu/people/dpolicar/writing/prose/text/think...
Re: Golang generics proposal has been accepted
#125Earlier quoted context omitted.
PHP was also hugely successful, success is not the criterion by which this kind of feature should be decided. The bottom line is that generics allows the production of safer, more robust, more evolvable, more documented, more performant, code. Along with static typing, generics are simply a feature that no language created recently should be without.
and less readable, less auditable, less understandable, etc.
These are all subjective aspects which often confuse unfamiliarity with obfuscation.
I can read generic code in multiple languages even when I'm not fluent in these languages.
Once you get used to generic code, it actually becomes easier to read and understand than code where everything is type cast or Object typed all over the place.
Re: Golang generics proposal has been accepted
#126IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large code…
4) It's standard library is also big, modern and well documented.
Re: Golang generics proposal has been accepted
#127IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large code…
> Even templates in C++ are notorious for puking near impossible to decipher errors. "Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.
I love-hate C++ templates because deep down they are just macros and you don't have to obsess about constraints like in Java and C#.
To me it's pretty interesting how the three big static OO languages have implemented generics: super flexible permissive macros in C++ (with murderous error messages), type erasure in Java (gross) and actual generics in the runtime (C#). For everyday usage it doesn't matter much but I always like thinking about what's going on under the hood.
Re: Golang generics proposal has been accepted
#128Earlier quoted context omitted.
> Even templates in C++ are notorious for puking near impossible to decipher errors. "Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.
This is why I've always hated C++. Taking something like templates, and abusing the turing-completeness of it. If I wanted macros I would use a language that actually supports them so I wouldn't have to resort to byzantine hacks. Stuff like this is why lots of people would rather use C over C++.
Doesn't C++ exactly support C macros? In what way is using C macros "better" than using the exact same macros in C++?
Re: Golang generics proposal has been accepted
#129Earlier quoted context omitted.
For me the desire to use generics shows up once I've invested some time in making fancy types. When I work in C that point is never reached since problems are solved "the C way". Personally I'm a huge fan of generics but I can understand how the keepers of Go might be reluctant to go down the path of C++, Java and C#.
I think that C# has a successfull implementation because it isn't just about syntax sugar. The runtime knows it. Generics+structs allows many optimizations.
So true and portable across languages.
Re: Golang generics proposal has been accepted
#130Nobody will have anything to complain about once go has generics, we'll never hear about Golang on Hacker News again! It'll just be the Rust people complaining. ;)
There’s always error handling.