Comment by kernelbandwidth | Hacker News Reader

Comment by kernelbandwidth | Hacker News Reader

Parent Full thread

kernelbandwidth

The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics!

Rust has generics and traits/typeclasses, and the result is my Rust code uses those features extensively and the presence of those features greatly influences the designs. Similarly, when I write Java, I design with inheritance in mind. I would have trouble showing real world use cases for inheritance in my Rust code, because Rust doesn't have inheritance and so the designs don't use inheritance-based patterns.

Essentially, how does one provide real world evidence for the utility of something that's only hypothetical? You can't write working programs in hypothetical Go 2-with-generics, so examples are always going to be hypothetical or drawn from other languages where those tools do exist.

It reminds me of the old urban planning line "You can't decide on the necessity of a bridge based on the number of people who swim across the river".

Users who have heavy need for genetics have already moved away from Go.

This suggests that both generics and inheritance are unnecessary.

It only suggests you can't easily give an example because the language is forcing a design where such things aren't needed. Sort of like linguistic relativity.

Which still proves the parent's point: it's not necessary. The question is what absolutely can't be done without them (probably nothing) so a better question is how much design/engineering/test time could be saved with them?

On the latter part I'm fairly cynical these days, since I'm presently on a team where the lead embraced a Scala-DSL heavy, functional design and the net result has been a total loss of project velocity because when we need to prototype a new requirement, the push back has been paraphrasing "oh, could you not do that in <core product> and handle it somewhere else?" - so we end up with a bunch of shell scripts cobbled together to do so.

> what absolutely can't be done without them

Of course nothing can't be done without them. With or without generics or inheritance the language is still Turing complete.

And if you look at C you'll see that interfaces and struct methods are also unnecessary, GC is also unnecessary, bound-checked arrays are also unnecessary.

The question is, do you want to write type safe code? which is memory safe? which has bound-checked array? or not? Assembly makes all that stuff unnecessary as well. This is not a good argument, especially when Go std lib is getting all these type unsafe API using interface {} everywhere. That is precisely what generics are for, to allow writing parametric functions (sort) or type safe containers instead of sync.Map like in the std lib.

If you care about type safety and code re-use then generic programming is a necessity. What do you think append, copy or delete are? these are generic functions. All people are asking is the ability to define their own in a type safe fashion.

Are these use cases Russ Cox don't know they exist?

What's unsafe about using one of the C libraries that do bounds checking, etc?

The argument about assembly is a red herring. Let's compare:

1) In addition to writing your business functions, learn these additional control structures to obtain safety

2) When writing your business functions, also use these well reviewed functions that enforce type and memory safety when moving code across interfaces.

3) Port all of your code to assembly, write you own memory safety control structures from scratch.

You see the difference? The choice in your mind between "add control structures to the language" and "do everything painstakingly by hand" but we are advocating a third option, which is: use well reviewed libraries written with only the basic control structures.

The reason I am advocating that is the more control structures you have the harder it is to analyze code. You end up slowly moving your codebase to a point where only people with deep deep knowledge of an advanced programming language can read it.

I think culturally, in 2017, programmers underestimamte how much can be done with just functions and literals and well written helpers.

The reason for that is we are rewarded (psychologically and professionally) for learning new control structures, but not as often for writing better code using the beginner structures.

Thanks to Turing equivalence, all programming languages are unnecessary. We should all go back to writing machine code.

Assemblies over the ages denote that so are loops, functions[0] and named variables, you can do everything using addresses, offsets and jumps.

They sure are useful to readability and maintainability.

[0] which can obviously be used to replace looping constructs anyway

Reply on news.ycombinator.com