Go's getting generics

basically void pointers

>Java launches without generics because it wants to be "simple"
>Constant pain without generics
>Finally yields and implements them, but it's too late, they are irrevocably broken thanks to backwards compatibility

After all this happens
>Go launches without generics because it wants to be "simple"

Why does this keep happening

instead of making several methods like

DoSomethingToInt(int number){}

DoSomethingToString(string word){}

you can do things like

DoSomething(T thing){}

and then call

DoSomething(number)

and

DoSomething(word)

How do you avoid unexpected behavior with generics? Imagine you have a generic where you add two generics together and the result is an Integer. Wouldn't this fuck up with strings?

Makes sense, thanks.

>where you add two generics together and the result is an Integer
You can't do that, the compiler won't let you. You have to write code that works for any valid value of T. You could constrain T to be a subclass of Number or something but then you can't use it with any other types.

DoSomethingToInt(int number){}

DoSomethingToString(string word){}

hahaha look at these fucking plebs

witness the power of javascript

Dosomething(thing) {
switch(typeof thing) {
case 'string':
doStringThing(thing)
break;
case 'number':
doNumberThing(thing)
break;
}
}

So it prevents that problem, it doesn't cause it.

>some moron passes an array into Dosomething
>nothing happens
>10 steps later you get an opaque 'undefined is not a function' error because some shit didn't happen

Good job, you replaced a trivial compile error with a 10 hour debugging session

Aren't generics evaluated at runtime though ? I thought that's why error messages in C++ looked so horrible when using the STL.

No, they don't even exist at runtime usually. C# being the exception. C++ templates are a whole different type of cancer but they're still compile time only, the error messages just become awful

>too hard to add a default: throw error

in some languages generics are typed at runtime, and those require a runtime system to check and error report bad types

so, they are I don't get it, google use C and python, why they need this?

Faster than python, safer than C.

Attached: a617de14f7edd6cfc13dc7dcfb21bcd0.jpg (600x800, 71K)

based and typepilled.

For fuck sake, what for? Serously they have too much free time, so they decide to complicate compiler even more?

This

Attached: VJfTJeG.jpg (1125x1358, 72K)

>What's the difference between generics and weak typed systems? Aren't those two basically the same?
Performance, compile time bug detection.

Generics are basically compilator copy pasting your function to work with different types so it is still a strong typed system.
Go actually comes with generator for that purposes but people would like to have this functionality in go's syntax

They always intended to add generics from the beginning, but focused on other, more important features first.

why... Generics are dumb

Welcome to decades ago.

Go was never a Jow Forums meme

>they don't even exist at runtime usually
They do, in most languages.

Is it worth my time to learn go? I’ve never programmed before and was considering learning go for my first language.

no

I teach beginners Go and I've found it easier to explain fundamentals with Go over any other language. I'd say go for it.

Dosomething(new String('foo'))

They said they wanted to find a way to implement generics without hurting the syntax and performances first. Nothing to do with "keeping it simple."

Just remember to wear your PR face at all times, lest you piss off someone and get accused of "offensive behavior" and forbidden from participating in the community. Doubly important given that you have to doxx yourself to do so. You don't want to lose your job to a Twitter mob, do you Jow Forums?
news.ycombinator.com/item?id=17147968

>[]k instead of
I knew they were going for a gay syntax, they are gaygle after all

Attached: 1374586983986.jpg (503x580, 39K)

>contracts and interfaces
I like Rust's trait construct better since it covers both static and dynamic interfaces.

based Abe poster

>2009 - Go doesn't need generics
>2010 - Go doesn't need generics
>2011 - Go doesn't need generics
>2012 - Go doesn't need generics
>2013 - Go doesn't need generics
>2014 - Go doesn't need generics
>2015 - Go doesn't need generics
>2016 - Go doesn't need generics
>2017 - Go doesn't need generics
>2018 - Go is getting generics

funny how that shit works

Instead of Copy/Pasting a lot of code to replicate a behavior from one type to another you Copy/Paste less code.
The compiler do the hard copy / pasting for you as it should be.

People call them "generics" I call them CTRL+C/CTRL+V-MODULAR-TRANSLITERATING-GENERATOR.

*dabs*

>more C++ garbage
Fuck this shit. What are some pure languages without feature bloat?

scheme

Based and redpilled.

Yet another meme dies.

Now,...
If only,...
If only the FFI overhead is fixed...
forum.golangbridge.org/t/performance-concern-in-calling-gtk-library-ies/10290

the ffi overhead is insignificant

>traits
I like Haskell's type classes better because it's the original not butchered idea and doesn't try to resemble OOP just to appeal to pajeets. Essentially they are more flexible but maybe they'll add similar features to Rust over time.

>40 times is insignificant

40 x nothing is nothing.
If your programs are performing badly the FFI is not the reason why.
In the extremely unlikely case that the FFI is bottlenecking you, batch commands together and execute them with a single FFI call. This is a problem solved in 3D graphics eons ago.

You can be strongly typed with generics. Hell dependant types are the next thing to complain about.

Nice. I'll learn it now. How likely is it that this is going into the standard? Since it's a draft, part of me thinks that it might not. Also, when will it go into the standard?

The idea is that these drafts will be discussed and perhaps improved upon, then they (it's not just generics) will be implemented during several Go releases, don't know if generics will be first out of the gate, probably error handling.

And there is absolutely no performance hit from doing that and having a dynamically typed language.

Nice, now they only need to add proper types and other stuff to catch up with modern times.
They should add all that stuff, too.

A metaprogramming feature for compile time type polymorphism.

macros for retards

>I don't even know what generics are or why they are wanted. Someone please tell me.

Something that complicates compiler, bloats final program and increases compilation time in order to implement what most pr0 programmers would avoid.

t. cnile

I wish it wouldn't get generics.
Just makes the language less readable, and will be completely overused by everybody while not adding much benefit at all

Is-odd() is an example if I'm reading these replies right

Serves you right for listening to retarded fanboys.

Hopefully we've shaken of all the PL crew and generics won't be abused in Go like they are in Rust, Swift or "modern C++"

>batch commands together and execute them with a single FFI call. This is a problem solved in 3D graphics eons ago.
That is because there you don't have to trade throughput for latency, which can't be said for all use cases of an FFI. In truth, though, FFI with that much discrepancy in memory model can't be solved in a good way.
Therefore, GTK is shit, stop using it and do the only thing you can to at this situation, which is implementing a toolkit in golang itself.

In any case, all no-devs were btfo, which is a good in any outcome

A generic function is a function that can pick an appropriate method based on the types of the arguments given to it.

A macro is a program that writes other programs.

>A generic function is a function that can pick an appropriate method based on the types of the arguments given to it.

>GTK is shit because go can't into FFI

The problem with generics is that they get abused to hell.

When you take a CS course in college they tell you to not use global variables but they don't tell you to not use generics unless you absolutely need them.

That's how you end up with shitshows like Rust, Swift and modern C++ with programs where every fucking type has at least one parameter.

That's how you get abominations like rust's Result type.

Hopefully all the PL enthusiasts got bored with Go and fucked off to Swift and Rust, so maybe they won't shit up the ecosystem completely.

No, it's just(TM) shit.

>A generic function is a function that can pick an appropriate method based on the types of the arguments given to it.
overloading is not generics user

The problem is that those languages have horrifically bloated syntax. look at any FPL and parametric polymorphism is infinitely more elegant.

>A generic function is a function that can pick an appropriate method based on the types of the arguments given to it.
generic != dynamic dispatch

What happens when you pass a data type into a generic and then try to call a method that cannot work with it?

List boolList = new ArrayList();
boolList.add(true);
Integer i = boolList.get(0).divideByTwo();

My code presumes that ArrayList has this new method called divideByTwo().

Attached: 834cda80110b43161de14cdc831a7dba.jpg (619x800, 48K)

The program will not compile. The static type of boolList.get(0) is a Boolean and a Boolean does not have a divideByTwo method.

no, your example presumes that the element at index 0 has a function called "divideByTwo()". You'll get a compiler error.

>What happens when you pass a data type into a generic and then try to call a method that cannot work with it?
You get a compiler error.
>My code presumes that ArrayList has this new method called divideByTwo().
You get a compiler error that Boolean doesn't implement divideByTwo.

Don't give me that look. It belongs to RedHat/GNOME now.

Thats just reflection dumb dumb

I'm retarded. So the point of generics is that you can substitute that generic with a specific type for type safety at compile time, right? That name was misleading me for the longest time because I thought it meant allowing any type to be put in place of what should be a specific type.

clhs.lisp.se/Body/t_generi.htm

Scala is just as bad, if not worse.

>I'm retarded. So the point of generics is that you can substitute that generic with a specific type for type safety at compile time, right?
That's right.
You can also apply constraints to type parameters to make sure they implement some method.
For example if you want to make a generic sorted list, you could specify that the type parameter must have a comparison method that determines which order two elements are supposed to be placed in.

Scala is not FP, it's an abomination.

I wish it was called "Specifics" then! I guess I just brain farted with the terminology. I finally understand it.

Can we finally have Go threads that aren't shitposted to death?

probably?
I mean you still have questionable syntax and error handling

Go is honestly so fucking comfy. Static binaries you can just run without setting up some hellish interpreter environment/VM, not dynamic weak typed garbage like python and JS where all of your tests check for type based runtime errors, easy to read documentation because all functions specify typed parameters, really really good corporate support so there is libraries for everything, no Java style AbstractSingletonProxy bullshit or OOP fracturing where everything is in 1M different files, no C++ style smart pointer/move semantics/copy constructor/overloaded operator that doesn't work how you think it would bullshit.

>i enjoy having to copy-paste and maintain 10 different versions of the same function
Who even needs generics amirite?

>if err != nil

All your points are fine except for the lack of exceptions which seems like it would be a real pita. I even disliked checked exceptions in Java, much less not having them at all. A decent stack trace is so important for diagnosing errors too.

Also, a VM might be heavy, but it also comes with things like high-performance GC and JIT which can help performance a lot.

>i enjoy having to copy-paste and maintain 10 different versions of the same function
I never need to do this though.
I don't know when one would even have to.
Maybe it's because I just code straight to the point in a data-oriented fashion.
How often do you _really_ benefit from genericness? If you would reflect on it, maybe you would realize that you probably don't, especially in C-family languages.
It just adds clutter, and makes the point of the program (transformation of data) unclear.

I'd say generics are more useful on date structures and libraries, I'm not surprised that you never needed generics on your shitty web apps.

>especially in C-family languages
C??? The programming language where people use void pointers, macros and generic selection to get around this very issue? Nice example.
Next you're gonna tell me you never needed to use a void pointer on C.

Wrong
In comparison to C++, Java, C#, Perl and even fucking VB.NET, Go is the irrelevant language.

Attached: mp,550x550,gloss,ffffff,t.3 (1).jpg (550x545, 16K)

>They should add all that stuff, too.
C is dead, replaced by C++ over 20 years ago

>C family languages
I'm not talking about C, but about languages that are in the tradition of C.
Gos empty interfaces are pretty much whats used instead of void pointers.
Macros are just text replacement which was possible by go generate.
The kind of 'generic' polymorphism has much more use in functional languages, but in C-style languages they are rather unnecessary, which is why I was talking about C-family languages.
>I'd say generics are more useful on date structures and libraries
To a certain extent they are useful in such cases, but some things are still true.
Go generate works for data structures already. No need to add anything to the compiler.
Libraries are better served not employing too many generics, since they are better this way.

Never have I ever written go code and thought to myself that I would like it to be more generic.
Interfaces have already been more powerful for me than generics have ever been in other languages.

I think it's a dumb decision to go the way of generics.
The code of everyone will become harder to read. They will unnecessarily use data structures of libraries, without understanding the implication of their use (in 90 percent of the cases an array or map would have served them better.)
It will take longer to parse and compile.
It will only add to the complexity, without much benefit.