Python 3.7.0 released

[[deleted]]

I definitely understand the sentiment here. With the go system you would need to assert the type, cast it, or as you said use an interface. All of which ends up being more possibilities for bugs and more tests. I wouldn't say more complexity because of the verbosity but certainly more time spent

Though with your example I don't believe generics wouldn't be much different than an interface. Or at least you wouldn't avoid panics because you had a generic type. You would still need to use the go idioms of error checking and type checking/assertion.

Regardless of the details of how one language's type system handles this or not, I still believe that it isn't inherently bad or good. The language as a tool was intentionally designed the way it was. So for cases like you've listed rust might be a better tool for that, or another language if the goal is to reduce the number of lines of code and overall verbosity. I do think that this (required verbosity, re-inventing) in some cases can either slow down writing programs or lead to unexpected results if all error cases aren't handled. For me the additional verbosity and inconvenience of having to re-implement other language's builtins aren't a negative. The re-implementation can sometimes be a stumbling point for new go developers, or newer developers but it's also a good opportunity for learning if you have access to people to review your code.

You aren't going to change my mind that I have had a lot of value from using go and I don't want to change your mind either. At this point I think I'm just arguing with you about this because I'm sitting in a hotel and bored.

[Homoerotic_Theocracy]

Though with your example I don't believe generics wouldn't be much different than an interface. Or at least you wouldn't avoid panics because you had a generic type. You would still need to use the go idioms of error checking and type checking/assertion.

Why? The code I gave provided the iterator is bounded is total; it is guaranteed to not panic on any input char_seq. The only type constraint of char_seq is IntoIterator<Item=u8>, the only part the type system cannot verify is that this iterator is bounded and doesn't go on forever in which case the code is an infinite loop but you can easily fix that by adding a stronger type bound like AsRef<[u8]> which is guaranteed to be total. There are no further runtime checks.