Generics are overrated.

[dogan...@dodobyte.com]

Everything in this thread is my personal opinions, they are not necessarily the truth.

My main language was C for a decade. I also liked Python. When i started learning Go, it almost felt like i knew the language in another life. Everything was so obvious.

CSP model of concurrency was new to me though. Interfaces were more familiar due to unix's open,close,read,write interface, which is the greatest idea.

I didn't use generics or templates much (it's kind of stupid for me to talk about it's necessity), therefore this is more like a meta-research.

- Go developers created a great standard library and many great software without generics in the language.

- Many companies switched to Go from the languages that have generics in it.

- A little copying is better than having a big feature in the language.

- Using generics everywhere is more of a design choice than a necessity.

A language that doesn’t have everything is actually easier to program in than some that do. (Dennis Ritchie).

I wrote many different types of software in C. A country wide (a big one) server, two AV engines for two major AV companies etc. I needed generics only few times, but i could handle it in C without using smart tricks. In Go however, there are much safer, better and elegant solutions to achieve the same results. Do we really need a big feature for it?

I didn't hear a complaint about the lack of generics in Go from a C programmer, although i'm sure there are. 

Maybe java programmers use generics more than they are supposed to. Maybe they should stop writing java in Go. I am confident that they would abuse generics if Go had one.

That brings me to my point.

I believe that generics would divide the Go community.

It's well known that everybody uses a subset of C++ language. Google doesn't use exceptions for instance(afaik). I was unfortunate enough to use C++ in my last company and i felt the pain.

Rob Pike himself talked about it. https://talks.golang.org/2012/splash.article (see 4. Pain points)

Now Go is unique because people come to Go from all kind of different languages, (javascript, Python, C,...). see https://blog.golang.org/survey2016-results

If Go 2 has a new fundamental feature like generics, many Go 2 programs will look alien to Go 1 programmers. Some people will not use generics at all while others overuse it.

For a language like Go, this is disastrous because it's against Go's philosophy. I love gofmt because it enforces a standart format and saves our time of debating about indention and other things. What good it is to have a standard format while you have completely different programming styles.

Dear Go experts;

Please provide some best practices to achieve generic behavior for the most common cases, instead of implementing Generics in Go.

Let's end this debate and help keeping Go small and simple. It's the real virtue of Go. 

Thanks.

[Shawn Milochik]

I programmed in about a dozen different languages before Go. None of them had generics. I use Go, love it, and never noticed anything missing when I write everything from command-line tools to complex servers. I've always been puzzled when people represented the lack of generics to be a flaw in Go, sometimes to the point that they claimed the language to be unusable. I personally hope that simplicity continues to rule the governing body of Go and we never get a feature that gives Go more than one obvious way to do things. This would violate the "Lego" policy of the Go group, which is to give us everything we need to build everything we want -- not everything we want.

Go rules!

[Robert Melton]

My primary concern about generics is they may significantly hurt build times, which coming from C++ I am rather sensitive about.  Beyond that I am worried that they might end up NOT being an improvement over all the tools that have already popped up to handle this problem.  There are a lot of ways to generate code for Go already that can be run once and checked into your source repo.  Regenerated if you need to support a new type or fix a bug.  This is very reasonable and rational IMHO.  I have yet to have a significant issue with this approach, outside of tooling phobia.

Even in languages with prolific template support, I have often ended up eschewing them for better, external text processing tools.  I think Mike Acton has something useful to add to the conversation about avoiding templates in C++: https://youtu.be/rX0ItVEVjHc?t=1h11m19s

Questioner: ...you're against templates... how do you deal with code duplication?...

Mike Acton: ... templates, how do you remove code duplication?  One, it is almost certainly not as big a problem as people think it is.  They invent things to duplicate so they can invent templates to solve the problem.  But in the cases where it is potentially useful you can also generate the code.  A template is just a poor man's text processing tool, we have tons of stuff that processes text, you can actually do a really great job with some other tool that does it better.  You don't need templates in order to solve that problem...

/mytwocents

--

Robert Melton | rme...@gmail.com

[stu...@influxdb.com]

The build time issue is an artifact of C++ and templates. When generics were introduced to C# 2.0, they did do not negatively affect build times.

[Henry]

Generics is a non essential feature in that you can live without it. However, it is not without merits. Generics is a bridge to higher level expressions. If Go wants to add "modern" features in the future, it will stumble upon the need for generics in one way or another.

While simple, code duplication can be a pain when you need to change existing code. Instead of making the change in one place, now you need to do it in many different places and you must ensure not to forget any of them. Otherwise, it may cause bugs, some of which may be subtle. It gets worse if the code is some else's work that you may not be thoroughly familiar with. Of course, being engineers that we are, we can find workaround to mitigate the problems using testing, documentation, project organization, IDEs, etc.

There is nothing wrong with Go not having generics. However, dissing generics as if it is useless is just not right. It's all about having the right tool for the job.

[prade...@gmail.com]

What is overrated is the use of "interface { }" and reflection AKA runtime magics which has no place in a modern statically typed language. It's a cop-out, it's dirty and a direct consequence of the absence of generics in Go.

> Please provide some best practices to achieve generic behavior for the most common cases, instead of implementing Generics in Go.

You cannot achieve generic behavior without some form of generics. Look at sync.Map it's not compile time type safe. With generics it would be. 

[Jan Mercl]

On Sat, Jul 29, 2017 at 3:28 PM <prade...@gmail.com> wrote:

> What is overrated is the use of "interface { }" and reflection AKA runtime magics which has no place in a modern statically typed language.

interface{} is not a replacement of generics. Interfaces with a real methods set, like sort.Interface sometimes are.

> It's a cop-out, it's dirty and a direct consequence of the absence of generics in Go.

Not true. interface{} and reflection is, for example, used by fmt.Printf for purpose where generics won't help. Alternatively everything must have a Format() method. But predeclared types cannot have methods.

--

-j

[Roberto Zanotto]

I love playing with package reflect, which is much more powerful than generics by the way (you can't implement gob or json with generics).

[prade...@gmail.com]

Not true. interface{} and reflection is, for example, used by fmt.Printf for purpose where generics won't help. Alternatively everything must have a Format() method. But predeclared types cannot have methods.

write a compile time type safe generic reduce function with the following signature which works for all slices of any element type :

func reduce<A,B>(array []A,out B,in A)B {}

you can't do that in Go .

 used by fmt.Printf for purpose where generics won't help.

Interfaces won't help either when you're basically using them as C (*void) . 

[prade...@gmail.com]

I love playing with package reflect, which is much more powerful than generics by the way (you can't implement gob or json with generics).

You could absolutely do that without runtime reflection. It is called compile time type safe macros ... Oh wait, Rust has them, and generics and a correct implementation of method polymorphism... 

[Jan Mercl]

On Sat, Jul 29, 2017 at 5:18 PM <prade...@gmail.com> wrote:

> write a compile time type safe generic reduce function with the following signature which works for all slices of any element type :
> 
> func reduce<A,B>(array []A,out B,in A)B {}
> you can't do that in Go .

You've nonchalantly changed topic, even though no one said you can do everything without generics. (BTW: You can, ask Mr. Turing for details.)

> Interfaces won't help either when you're basically using them as C (*void) . 

Are you really telling me you consider void*, carrying no type information whatsoever, equal to interface{} which carries full type information? If so, I can't help you, sorry.

--

-j

[dogan...@dodobyte.com]

I was watching rus cox's last talk and he mentioned that not every problem should be solved by language change. Some can be solved by tooling or library change. 

I am curious has any of the generics lovers written a tool that helps for generic behavior. Something like,*

//@generic

func Max(x, y T) T {

    if x > y {

        return x

    }

    return y

}

When the tool sees generic comment, it rewrites the function for each type as called, like Maxi(x, y int) int, Maxf64(x, y float64) float64 etc..

* I know there are many issues with this example but it's just to show my point

I know people wrote tools like goimports, gocode out of real needs, and they are everywhere. 

I just want to know sincerely, if people REALLY need generics so much, or they are just complaining because they are used to it and it's in their favorite programming language.

Thanks.

[Robert Melton]

On Sat, Jul 29, 2017, at 12:36, dogan...@dodobyte.com wrote:

I was watching rus cox's last talk and he mentioned that not every problem should be solved by language change. Some can be solved by tooling or library change. 

I am curious has any of the generics lovers written a tool that helps for generic behavior. Something like,*

There are a bunch https://github.com/taylorchu/generic, https://github.com/cheekybits/genny, https://github.com/joeshaw/gengen, and https://github.com/clipperhouse/gen and I am sure many more that I don't have sitting in my bookmarks.

Also, building a basic one yourself if you don't want to use those tends to be exceptionally straightforward.  

--

Robert Melton | rme...@gmail.com

[dogan...@dodobyte.com]

Also, building a basic one yourself if you don't want to use those tends to be exceptionally straightforward.  

Thanks for examples, i can't tell if they are experimental or viable for production use. But if it's that straightforward, why people complain about it too much.

I implemented hash tables a billion times in C but i never complained about C's lack of map type. Because i understood the design choices and philosophy of C. 

I always dreamed a Ken Thompson version of C++, not necessarily an object oriented version of C but a more modern C. C with automatic memory management, better string handling etc, and still small and simple. 

Now we have it, and it's called Go (Thanks to Pike, Griesemer, Cox, Taylor and everyone). I love it because it's small, simple, modern and it maintains unix's and C's philosophy. 

It just hurts me to see people try to do it what they did to C++, add favorite feature of everyone. I know Go team is much smarter than me and Thompson is the creator of unix philosophy, i am confident that Go will stay as it is, a small simple, pragmatic and powerful language.

Thanks.

[Daniel]

I'm curious: are there use-cases where template generation with gengen/genny/etc are not enough? seems to me that calling "go generate" a few times (when you need to generate generic containers for certain types) is a very fair tradeoff to have generic containers without having to change the language core (or possibly affecting build times for all the other cases that don't need them).

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

"Worse things happen at sea, you know!"

[Robert Melton]

On Sat, Jul 29, 2017, at 13:33, dogan...@dodobyte.com wrote:

Also, building a basic one yourself if you don't want to use those tends to be exceptionally straightforward. 

Thanks for examples, i can't tell if they are experimental or viable for production use.

I am not sure the case where a code generation tool would be "experimental", as they aren't in most cases that clever, they are mostly just saving typing time.  Some of the ones listed are more clever than others -- but I would consider them all "production" ready in so much that they can output code you can use in production.

But if it's that straightforward, why people complain about it too much.

I believe a part of it is tool anxiety.  You have to pick a tool, learn it, vendor it, and train others on it and hope it is maintained / improved going forward.  When this tool is not a blessed part of the language it often causes stress for people.  That said, I use a lot of console tools with Go in my day to day development (over a dozen no less) -- so I feel a tool for generating variations fits very well with the Go ethos.

--

Robert Melton | rme...@gmail.com

[Jesper Louis Andersen]

On Sat, Jul 29, 2017 at 6:36 PM <dogan...@dodobyte.com> wrote:

I just want to know sincerely, if people REALLY need generics so much, or they are just complaining because they are used to it and it's in their favorite programming language.

Generics tend to serve at least two purposes in a programming langauge. 

What you are doing is that you are essentially extending functions such that they have two types of parameters: term parameters (which is what Go has now) and type parameters which instantiate the given function for those types. The output type is always a term[*]. Most generics can be boiled down to this very idea in the end and most of the notation can be reified by expansion.

One reason to want this is simply that it avoids typing. Your example of expanding a Max function for each possible type is a common one.

The other primary reason as to why people want something like this is precision: you can describe the intent of a program more precisely which means that the compiler is able to catch more programming mistakes up front. The obvious benefit here should be when programming in the large with many people working on the same code base. If we can capture more bugs at compile time, they don't end up occurring when running programs.

As secondary reason is that once you start combining generic features, you really need to start relying on the compiler telling and hinting you about where you are mistaken in your use-case. If you had tried a variant based on interface{} and reflect, you are likely to mess it up.

In principle, maps or arrays could have been implemented such that they would require the use of an interface{}. But this would make more brittle programs. Hence, the language defines maps and arrays as generic constructions. If you look at package builtin, it defines (for documentation purposes) builtin.Type and builtin.Type1. These are subsequently used in different invocations where you need the invocation to be generic: copy(), close(), append(), cap(), len(), ...

What proponents of generics are saying is that they want access to the same kind of functionality at the language level so they can define their own functions to work like the ones above. Clearly, the compiler must understand the notion of generic type(!), but it doesn't give that power to the programmer.

You can argue that Turing completeness means you can implement anything with anything as long as it is Turing complete. But by that argument, we could as well be writing assembly still because, after all, you can implement anything in assembly. Programming languages are about applying select restriction in order to achieve more. For instance by building a programming language which doesn't make use of a goto construction, even though assembly is all jumps and program counter manipulation. 

On the other hand, it should be mentioned that Go already has an abstraction feature in the interface construction. And some uses of generics can be resolved simply by rephrasing them in an interface. Yet there are certain things which cannot be expressed if you don't have a type-level variable.

(Aside: I don't write enough Go to have an opinion on whether or not it would be right to add generics to Go. But based on my experience with other languages, I enjoy programming with them there. )

[*] You can explore what it means to have the output be either a term or a type. See e.g., F* or Idris. 

[Shawn Milochik]

As with every community, there's the silent majority and the vocal minority.

It's easy to be confused, and think that the lack generics is a major issue in the Go community. It is not.

The number 500,000 Go developers worldwide has been thrown around a lot this month. (https://research.swtch.com/gophercount)

Evidently most of them are using Go just fine -- as individuals, at startups, and at huge companies.

At every scale, Go's adoption is amazing and the the projects they're building are changing the world:

• You don't need generics to write Docker.
  
• You don't need generics to write Kubernetes.
  
• We could add so much more to this list, but you get my point.

So, let's stop feeding the trolls. The far fewer than 1% of the people who have not yet taken the time to appreciate Go for what it is, and therefore find it lacking in comparison to something they have taken the time to appreciate. I don't mean to belittle those people by calling them trolls, but they are trolling. I'm sure most of them who give the language an honest, unbiased try will come around.

Imagine if Go programmers went to other language mailing lists and complained about the lack of goroutines and channels, which clearly make those other language "unfit for concurrent programming." That would be equally unhelpful.

[Jérôme LAFORGE]

> As with every community, there's the silent majority and the vocal minority.

But when we let the community to manifeste it choice (even if little part of this community that reply to survey) in regarding the 2016 golang survey:

What changes would improve Go most?
1 generics

[Tristan Colgate]

On Sat, 29 Jul 2017, 23:59 Shawn Milochik, <shawn...@gmail.com> wrote:

• You don't need generics to write Kubernetes.

I've had no personal need for generics, but k8s client-go is the one case I've seen where I thought they would help, the informers packages in particular.

https://godoc.org/k8s.io/client-go

(FWIW, I'd rather there was an effort, like the one for dep, to take learnings from the existing generics/templating tools, and see what's needed in the language and tooling to give us one tool in the standard tool chain)

[Russel Winder]

On Sat, 2017-07-29 at 18:59 -0400, Shawn Milochik wrote:
> […]

>
> Imagine if Go programmers went to other language mailing lists and
> complained about the lack of goroutines and channels, which clearly
> make
> those other language "unfit for concurrent programming." That would
> be
> equally unhelpful.

Some of us have been going round various programming language mailing
lists complaining about the lack of dataflow, CSP, etc. support in
languages and their libraries for 30+ years.

Fortunately, over the last 10 years, we have been getting programming
language and libraries doing actors, dataflow, and CSP (or rough
equivalent) properly, and most importantly – getting traction amongst
programmers.

So now we have a number of programming language becoming fit for
concurrent and parallel programming, what is the next evolution? What
comes after Go, Rust, Pony, Nim, D, C++20, etc.?

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[mhh...@gmail.com]

i have not read this,

1. i do go because the type system is helping me,
if i do js, i have no type system, so i have to figure this out by myself, its hard
if i d be doing java, i d end up with complex giant scaled type hierarchy,

both cases, it d more a difficulty than an helper to my attempt to solve a real problem.

2. generics / not generics ?
i d rather think in terms of capability.
- i can t declare a func which returns the type it received, i feel like its a lack of basic capability.
- i can t generalize easily / elegantly some algo, again this looks likes a basic functionality.

should any of this be necessarily over complex, i hope not.

should any existing implementation is the right one, i believe not, for as much as i know (not that much, true :),
because they thought generics as a piece of software to integrate in a complex hierarchy of types (so they needed to parametrized their generics),
they made generics in their ways of thinking.

The day GO has found its way around those two difficulties using its way of thinking,
- how to let the runtime leaks into the static type system (dont pre emptively define the world, locally solves problems)
- elegantly provide re usable algo (be DRY)
it d be an awesome language to write.

As a comparison, quickly i want to talk about php, before php4, there was not a type system,
since php5 they implemented a type system with class hierarchy based on Java and co (so called "leaders"),
IMHO, a total failure, php is no more php, its not java and co either, it became a bloat,
years later, i think about it and wish they took their inspiration from the go language,
they did not.

Do i want GO to become java because "its a leader", really not please, i d rather keep go 1.

3. compile time worries
I found it inadequate to worries yet about the compiler speed without a clear and meaningful change proposal.
Also, i wonder if we are worrying about a compilation time with no-cache, or with a hot cache.
Said as a question, is it a worry about 1% use case, or the 99% use cases ?
The consequence would be, how to re think this worry with new metrics, thresholds, explanations ?

[dogan...@dodobyte.com]

Daily reminder: This thread was about concerns that generics would divide Go community. Not about necessity of generics in general.

Two possible scenarios:

1) Go have programmers from very different backgrounds, some used generics often while others never used it. (e.g. Java and C). So different people will use different features of Go with different style and practices. This is the C++ mistake.

2) Go 2 will have such a fundamental new feature and Go 1 programmers will avoid Go 2. To use old code base with Go 2, you have two options;

 a- Mix Go 1 code with Go 2 code, new code uses generics while old code does not.

 b- Update Go 1 code to utilize generics.

Personally i would rather stay with Go 1. This is the Python mistake.

I may be wrong, this is only my concerns. 

Thanks.

[mhh...@gmail.com]

"This thread was about concerns that generics would divide Go community"

that d would dismiss any attempt to propose generics because it s generics,
instead of the observation that the proposal does breaks everything including the community.

maybe the first thing to do is to ban this word "generics", so we can start thinking about facts,
rather than trying to pull a model and put it into go ?

[Mandolyte]

Just a reminder that Egon Elbre's documentation of all the discussions on this topic is here:

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

[David Collier-Brown]

I came to Go from languages that had generics, but in practice I find that I predominantly used list-of and  set-of.  And I spent a dispropriate amount of time with valgrind making sure my C++ list didn't have leaks (:-()

A question to people who use Java/C++ and friends: what generics do you find you use in production programs?

--dave

[Olivier El Mekki]

I can relate to Shawn's experience, here. I wrote a few programs in C, but mostly used interpreted and untyped languages professionally, before Go. When I started using Go, I fought for a while with the type system, just for the time to get used to it in general in daily usage. Once it was done, I never felt the need for generics, and was surprised to discover it was considered a problem.

Maybe there's an other reason it doesn't get in the way, though. My first year with Go, I used custom types a lot, with embedded types and interfaces. Then I realized I was just trying to do OOP all over again, and was hurt by the same problems (mainly, not knowing at a glance where methods come from and what set of methods are available in a given scope). Nowadays, I mainly do FP style architecture (not trying to enforce any "function purity" like in FP, but mostly writing small packages with a bunch of methods that take simple types as arguments) and usually have a couple types at most (usually, configuration types set at initialization).

Could generics need be a sign that we may try to force OOP on Go, putting types in a central place?

[Henrik Johansson]

I don't miss Javas generics so much for the ability to create generic libraries but for using them.

Things like map, group, filtering etc is so much simpler to write (maybe not always read).

And it is fine to loop explicitly by hand coding but with grouping and perhaps several levels of filtering and mapping it gets messy.

I find that it is actually the "functional" bits I miss most rather than the basic generic types.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Mandolyte]

It's been many years since I was involved in developing complex systems (C++ and Java). But I agree, it was mostly lists and sets with searching and sorting. But I also used them for algorithms a good bit. Thus I would guess that the maintainers of GONUM libraries might benefit (anyone confirm?).

I haven't seen many libraries developed in Go yet, but I think it likely many would benefit from generics. And I think it could simple and readable. I tend to think of it as an analogue to `go generate`. The latter is for package authors... a similar feature for package users is all that is needed.

[roger peppe]

On 30 July 2017 at 08:22, Tristan Colgate <tcol...@gmail.com> wrote:

On Sat, 29 Jul 2017, 23:59 Shawn Milochik, <shawn...@gmail.com> wrote:

• You don't need generics to write Kubernetes.

I've had no personal need for generics, but k8s client-go is the one case I've seen where I thought they would help, the informers packages in particular.

https://godoc.org/k8s.io/client-go

It's always nice to have experience reports of real world cases, so

could you expand on this, please? What specific code are you referring to here,

and how would it be improved if Go had generics?

[Tristan Colgate]

Re-posting to the list.

I should start by saying that I'm not a contributor to client-go, just a user,
so can't speak for their actual experience of developing that package.
As I understand it, much of client-go is generated by tools already, so they have
the particular problem solved, and may well be far happier with what they have than
a generics solution.

The particular package that triggered the "generics" sensation is
http://godoc.org/k8s.io/client-go/informers and http://godoc.org/k8s.io/client-go/listers.
These generate code for efficiently watchig and listing resources on kube cluster using
a nice cacheing mechanism.

All of the individual type specific informers packages have a

func New(f internalinterfaces.SharedInformerFactory) Interface

Interface here is a type in the package such as

type Interface interface {
// HorizontalPodAutoscalers returns a HorizontalPodAutoscalerInformer.
HorizontalPodAutoscalers() HorizontalPodAutoscalerInformer
}

which provides a type-safe way of getting at a the thing being informed on.

Part of me imagines someting like..

import hpaInformer informer<v2alpha1.HorizontalPodAutoscaler>

myInformer := hpaInformer.New(sharedUnderlyingCacheThing)

My hunch is that client-go has quite a few of these situations (the listers package is one,
and general experience with the package suggests there would be others).

Clearly everything is already working pretty well, so there's nothing "impossible" without generics here. The
client-go package is still reasonably pleasant to use (though, as a consequence of all the genration the docs
are very verbose, but low content, it took me a long time to actually work out how to use the shared informers
stuff because I kept start with the voluminous sub packages, rather than the informers package that got lost in the noise).

And, once again, I'm heavily unqualified to comment on this from the package maintainers
PoV, if they felt strongly about this, I'm sure they'd be speaking up already.

[Tristan Colgate]

On Mon, 31 Jul 2017, 18:21 roger peppe, <rogp...@gmail.com> wrote:

> import hpaInformer informer<v2alpha1.HorizontalPodAutoscaler>
>
> myInformer := hpaInformer.New(sharedUnderlyingCacheThing)

So... to me, the implementation of NewHorizontalPodAutoscalerInformer looks
pretty much exactly like what you've got there, where sharedUnderlyingCacheThing
is the result of cache.NewSharedIndexInformer as called currently in the
code. That is, that constructor inside the call to NewSharedIndexInformer
seems a lot like a constructor for sharedUnderlyingCacheThing to me.
I'm not entirely convinced that generics would make the code much
cleaner in this case.

The duplication I'm thinking about is more the multiple packages, one for each type being informed on. If the top level informers package, or function, were templatable by the type being informed on, there would be no need for the per-type packages. As it stands there is little benefit from the godocs for each individual informer. The current docs are verbose well beyond the value they add.

You might want to experiment by refactoring some of that k8s code to use
generics (using whatever your preferred formulation might be) and see
what it might look like, and whether it looks significantly
nicer/simpler/cleaner
as a result

I might look at something for the informers case, but it's worth pointing out that I was thinking generics could provide a difference API, rather than a cleaner implementation of the existing one. 

I suspect that it might not look that much different - whether you're using
type-parametric polymorphism or interfaces, somehow you've got to
plug the specific code into the generic code, and that existing k8s code
doesn't look like it has that much redundant boilerplate to it.

  cheers,
    rog.

[Dan Kortschak]

We use sets in the graph packages, but the number of set types is
pretty limited (sets of nodes and sets of either int or int64) and
map[T] works for that level of use.

The only other place where it might be useful for us is in in place of
generating float32 versions of float64 blas and lapack implementations.

Honestly, I've never really felt a lack.

[Sebastien Binet]

On Tue, Aug 1, 2017 at 2:06 AM, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:

We use sets in the graph packages, but the number of set types is
pretty limited (sets of nodes and sets of either int or int64) and
map[T] works for that level of use.

The only other place where it might be useful for us is in in place of
generating float32 versions of float64 blas and lapack implementations.

the other place I had (very recently) felt they could have been useful:

 - having a mat.Dense of math/big.Rat (in lieu of a mat.Dense of float64)

 

Honestly, I've never really felt a lack.

the other time I felt an urge to reach for generics was when implementing code for reading/writing various scientific data file formats (astro, HEP).

but I was surprised to realize generics weren't *that* necessary after some aclimatation time. (I am coming from C++/python.)

-s

On Mon, 2017-07-31 at 05:50 -0700, Mandolyte wrote:
> It's been many years since I was involved in developing complex
> systems 
> (C++ and Java). But I agree, it was mostly lists and sets with
> searching 
> and sorting. But I also used them for algorithms a good bit. Thus I
> would 
> guess that the maintainers of GONUM libraries might benefit (anyone 
> confirm?).

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[roger peppe]

It's that different API that I'd be interested in exploring - if you
had generics,
how would you redesign the API so that it's cleaner, simpler and smaller
than the existing API?

[Dan Kortschak]

On Tue, 2017-08-01 at 09:21 +0200, Sebastien Binet wrote:
> the other place I had (very recently) felt they could have been
> useful:
>  - having a mat.Dense of math/big.Rat (in lieu of a mat.Dense of
> float64)

I think that would be very hard. The reasons behind this claim are that
there is lot of non-generic code behind the mat.Dense user-facing
implementation; we would need generic BLAS and generic LAPACK, with
appropriate testing.
Having said that, there is no reason not to implement a big.Rat-based
implementation of mat.Matrix for the methods that you need. It would
return reduced precision float64 values from the At method, but have a
RatAt method returning the exact value.

[DV]

I think "need" is indeed one of those special words that means different things for different people.

Go doesn't "need" generics and you technically don't "need" anything except air, water, food, a sharp spear, and shelter, to survive.

I recently started toying with writing quick-n-dirty programs for the original NES and it's amazing to see what people were able to accomplish with 2KB RAM, *one* general-purpose register, no hardware multiply/divide, etc Heck, it's even *fun* to do some of those things using 6502 assembly from scratch! Doesn't mean I sometimes don't wish for certain quality-of-life improvements with that experience, even though I can definitely do it all from scratch, given infinite free time. 

Does Go "need" (in the hunter-gatherer sense) generics? Absolutely not! 

Go to me is an awesome little house on a beach. I love going to it in the summer. Everything is great about it. Almost. It just doesn't have hot water. I have to heat water myself and carry it for a 1/4 mile every time I want to shower. It's kind of annoying, but not a big deal in itself to make me stop going to the awesome super fun summer house. 

I really like functional programming paradigms for data transformation tasks. I like chaining map(...).reduce(....).filter(.....).skip(.....).drop(....).select(....) etc. and building a nice pipeline through which my data can flow. I *can* do it all with loops, of course. Just like I can carry hot water for a 1/4 mile every day. 

I'd love to be able to write generic compile-time type-safe functions but I can live without them. 

[Doğan Kurt]

 it's amazing to see what people were able to accomplish with 2KB RAM, *one* general-purpose register, no hardware multiply/divide,

 

Constraints boost creativity and discipline programmer. You may like this.

Today's mainstream programmers of mainstream languages just don't give a damn about simplicity or smallness. They don't spend any time for thinking a small and elegant design, they just start writing and writing as it's how they are taught.

This is grep from unix v7. It's still compiles* and runs perfectly and it's only 478 sloc. Also see this.

Go to me is an awesome little house on a beach. I love going to it in the summer. Everything is great about it. Almost. It just doesn't have hot water. I have to heat water myself and carry it for a 1/4 mile every time I want to shower. It's kind of annoying, but not a big deal in itself to make me stop going to the awesome super fun summer house. 

You are not only overestimating generics here, you are also underestimating programmers who code in languages without generics, such as C.

*i just needed to replace BSIZE with LBSIZE, it might be a typo.

[Dorival Pedroso]

Agreed!

And I was a "heavy" user of templates (see e.g. http://mechsys.nongnu.org/, including extensive use of "expression templates") ~5 years ago before the "wonders of Go".

Let's focus on making Go faster instead!

Cheers.

Dorival

[as....@gmail.com]

I'm hesitant to accept generics due to the fear of overloaded operators being the next big deal. C# even has properties (user-defined methods dispatched upon an assignment operation). 

[Lucio]

(Some unjustifiable opinionated ramblings from a faraway place, read at your peril.)

It took Dijkstra quite some effort to accept the concept of "interrupts" (quotation anyone?), but eventually he went with it.

Resistance to operator overloading is as admirable as it is futile. Ultimately, the range of base types in a programming language is an arbitrary decision and the operators applied to them is equally an artifact, not divine inspiration. Go slipped badly when it added "+" as the string concatenation operator and I don't remember much resistance to that.

In fact, I have adopted the expression x += 1 in lieu of x++ in all my coding specifically because I don't think the increment operator is necessary at all; a circular shift operator has more merit, but no one asks for that. Nor has anyone, including Rob Pike, suggested that we head the APL route and add any available special symbols as operators. I can see why, of course!

I would expect programming languages one or two generations from now to resemble nature more closely and allow programs to evolve rather than be "written" or coded. For that, the basic building blocks have to change dramatically. But our guidance may well come from the DNA double helix and its very small range of components.

I find generics inelegant, they lack any aesthetic appeal and that was enough for templates to turn me off C++ 2.0, I hope that Go will not adopt similar ugliness. That said, if one could treat types as mutable properties of the language objects (variables that can be transformed between "compatible" types - a lot like interfaces allow presently, but much more visibly, perhaps, I haven't thought that hard about it), then "generic functions" would span such "types" intrinsically and still protect the program from mistakes at compile time. Hmm, if the type assertion was intrinsic rather than explicit, perhaps? We're trying to avoid that, so we need a concept as fresh as "type interface", but more amenable to enumeration, an explicit "type set" perhaps? I seem to remember something like that from "kencc"?

Ultimately, to return to the topic of operator overloading, with C++ they came before templates and templates were the inevitable progression. Interfaces are a different starting point and there is no immediately obvious progression from there, but maybe the Go "leading minds" haven't been looking. Maybe all we lack is the type of theory that went into describing SQL as a mathematical concept, applied to interfaces, just maybe...

A final thought: the Go.1 promise is a wonderful idea, since it encouraged a whole cultural group to look for every conceivable improvement that could be made to a very stable core. But of course it had to apply blinkers. Eventually, someone will peek over the edge of such blinkers and figure what we've all been missing. It is not a critical component, but once it or they are identified, it will be hard to imagine how they could have been missed for so long.

Lucio.

[judson...@google.com]

I program using Go every day at Google, and I enjoy the language, but I feel that the lack of generics is a downer. I also find the language to be like Unix in that it is so simple it takes a genius to understand it. 

[David Collier-Brown]

Ah well, one can always go back to

COPY PAYLIB REPLACING A BY PAYROLL
                      B BY PAY-CODE
                      C BY GROSS-PAY
                      D BY HOURS.

(Courtesy of https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_9.1.1/com.ibm.etools.cbl.win.doc/topics/rlcdscop.htm)

--dave (:-)) c-b

[peterGo]

Lucio,

"It took Dijkstra quite some effort to accept the concept of "interrupts" (quotation anyone?), but eventually he went with it."

E.W. Dijkstra Archive: My recollections of operating system design (EWD1303)

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1303.html

"The third arrangement, known as "the interrupt", circumvents all these dilemmas. While the computer calculates at full speed, a piece of dedicated hardware monitors the outside world for completion signals from communication devices. When a completion is detected, the program under execution is interrupted after the current instruction and in such a fashion that it can be resumed at a later moment as if nothing had happened, thus instantaneously freeing the central processor for a suddenly more urgent task. After the interrupt the processor would execute a standard program establishing the source of the interruption and taking appropriate action."

Peter

[Lucio]

Thank you, Peter.

Maybe someone else can corroborate my impression that Dijkstra did not immediately accept the idea of interrupts and felt it would make programming too difficult?

Lucio.

[Lucio]

Got it. In the same document:

"Halfway the functional design of the X1, I guess early 1957, Bram and Carel confronted me with the idea of the interrupt, and I remember that I panicked, being used to machines with reproducible behaviour. How was I going to identify a bug if I had introduced one? After I had delayed the decision to include the interrupt for 3 months, Bram and Carel flattered me out of my resistance, it was decided that an interrupt would be included and I began to study the problem. To start with I tried to convince myself that it was possible to save and restore enough of the machine state so that, after the servicing of the interrupt, under all circumstances the interrupted computation could be resumed correctly."

Thank you again, Peter.

Lucio.

[Haddock]

In my opinion generics added to Go would make Go really take off. Currently Java developers would not change to Go. With Go having generics this would change and more people would consider Go also when not coming from Java/C#/etc.

[Jan Mercl]

On Tue, Aug 8, 2017 at 1:37 PM Haddock <ffm...@web.de> wrote:

> Currently Java developers would not change to Go.

Never enough of good news.

--

-j

[DV]

On Tuesday, August 8, 2017 at 5:37:42 AM UTC-6, Haddock wrote:

In my opinion generics added to Go would make Go really take off. Currently Java developers would not change to Go. With Go having generics this would change and more people would consider Go also when not coming from Java/C#/etc.

There's no way that any serious Java dev would ever consider Go, generics or not. Why, in Go, you just....write code! In functions! Not a single AbstractSingletonFactoryImpl in sight! </tongueincheek>

I used to do C# for a living, and Java before that. What drew me to Go was that it was *not* C# nor Java. That's actually the beautiful thing about it. 

[Haddock]

Go does not have the modeling power of Java, C#, Python, etc. The language is too simple for that. So Go is not really the real thing for application development. But generics would make it possible to drag many things up.

[Henrik Johansson]

I beg to differ. Most Java apps I have seen over many years almost unanimously suffer from over-modeling. That Go encourages another style of modeling does not make it too simple. It only makes it different which may be good or bad according to taste.

That said, I personally think that generics would be a net win if it was somehow possible to design a version of it that still encourages simple abstractions rather than the complicated mess so often seen.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[David Collier-Brown]

On 10/08/17 02:47 AM, Henrik Johansson wrote:
> I beg to differ. Most Java apps I have seen over many years almost
> unanimously suffer from over-modeling.

A former customer did a deep, thoughtful, *thorough* model of bracket
tournaments, without any attempt to abstract the salient features. Java
represented it beautifully, in complete detail...

So it's now impossible for a single person to keep it in their brain,
and every attempt to change it introduces new, surprising "features".

In effect, the ability to represent anything easily led to our error: we
represented _everything_.

Go (or C) doesn't actually address over-modeling: it's merely harder to
do, and we're less likely to make that error, just as a side-effect (;-))

--dave
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net | -- Mark Twain

[roger peppe]

On 10 August 2017 at 13:39, David Collier-Brown <dave...@gmail.com> wrote:
> On 10/08/17 02:47 AM, Henrik Johansson wrote:
>>
>> I beg to differ. Most Java apps I have seen over many years almost
>> unanimously suffer from over-modeling.
>
>
> A former customer did a deep, thoughtful, *thorough* model of bracket
> tournaments, without any attempt to abstract the salient features. Java
> represented it beautifully, in complete detail...
>
> So it's now impossible for a single person to keep it in their brain, and
> every attempt to change it introduces new, surprising "features".
>
> In effect, the ability to represent anything easily led to our error: we
> represented _everything_.

I remember something similar happening with some Haskell I wrote.
Because the type system was so powerful, it felt wrong not use it to
represent everything, which ended up problematic. Frivolous thought:
I wonder if there's an (far-fetched) analogy to be made between this
and dropout techniques in neural networks - if our type system is really
powerful, it's easy for our type structures to "overfit" to the current
problem being solved, making it less adaptable and maintainable when
the problem changes.

[David Collier-Brown]

I quite agree: I suspect it a tradeoff, in which the more you can easily represent, the more you need to carefully architect exactly *what* you represent.