Re: [go-nuts] Re: Generics are overrated.

2017-08-10 Thread David Collier-Brown

On 10/08/17 09:09 AM, roger peppe wrote:

On 10 August 2017 at 13:39, David Collier-Brown  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.

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.


--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

--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-10 Thread roger peppe
On 10 August 2017 at 13:39, David Collier-Brown  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.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-10 Thread 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

--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-10 Thread 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.

On Thu, 10 Aug 2017, 08:37 Haddock,  wrote:

>
>
> Am Mittwoch, 9. August 2017 23:29:13 UTC+2 schrieb 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 justwrite code! In functions! Not a single
>> AbstractSingletonFactoryImpl in sight! 
>>
>> 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.
>>
>
> 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.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-08 Thread Jan Mercl
On Tue, Aug 8, 2017 at 1:37 PM Haddock  wrote:

> Currently Java developers would not change to Go.

Never enough of good news.

-- 

-j

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-05 Thread judsonwilson via golang-nuts
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. 

On Saturday, July 29, 2017 at 3:59:55 PM UTC-7, Shawn Milochik wrote:
>
> 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.
>
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-03 Thread 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.*

On Thursday, August 3, 2017 at 6:10:24 PM UTC+2, DV wrote:
>
> 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. 
>
>
> On Saturday, July 29, 2017 at 4:59:55 PM UTC-6, Shawn Milochik wrote:
>>
>> 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.
>>
>>
>>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-03 Thread 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. 


On Saturday, July 29, 2017 at 4:59:55 PM UTC-6, Shawn Milochik wrote:
>
> 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.
>
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-01 Thread 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.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-01 Thread roger peppe
On 31 July 2017 at 19:35, Tristan Colgate  wrote:
>
>
> On Mon, 31 Jul 2017, 18:21 roger peppe,  wrote:
>>
>>
>> > import hpaInformer informer
>> >
>> > 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.

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?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-08-01 Thread Sebastien Binet
On Tue, Aug 1, 2017 at 2:06 AM, Dan Kortschak  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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-31 Thread 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.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-31 Thread Tristan Colgate
Re-posting to the list.

On Mon, 31 Jul 2017, 14:15 roger peppe,  wrote:

> On 30 July 2017 at 08:22, Tristan Colgate  wrote:
>
>>
>>
>> On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  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?
>


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

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.




>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-31 Thread roger peppe
On 30 July 2017 at 08:22, Tristan Colgate  wrote:

>
>
> On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  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?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-30 Thread 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.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: This is a digitally signed message part


Re: [go-nuts] Re: Generics are overrated.

2017-07-30 Thread Tristan Colgate
On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  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)

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-30 Thread 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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-29 Thread 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.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-29 Thread Jesper Louis Andersen
On Sat, Jul 29, 2017 at 6:36 PM  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.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-29 Thread Robert Melton
On Sat, Jul 29, 2017, at 13:33, dogan.k...@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 | rmel...@gmail.com

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-29 Thread 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).



On Sat, Jul 29, 2017 at 1:04 PM, Robert Melton  wrote:

>
> On Sat, Jul 29, 2017, at 12:36, dogan.k...@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 | rmel...@gmail.com
>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"Worse things happen at sea, you know!"

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-29 Thread dogan . kurt

>
> 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.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-29 Thread Jan Mercl
On Sat, Jul 29, 2017 at 5:18 PM  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(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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Generics are overrated.

2017-07-29 Thread Jan Mercl
On Sat, Jul 29, 2017 at 3:28 PM  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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.