I posted two real world problems where Generics would be useful to me,
earlier in the thread. Saw no response, and now continued claims that no
real world problems have been provided? I'm not sure if that is
disingenuous, or merely an artifact of the client someone is using causing
replies
On Mon, Jan 4, 2021 at 9:20 AM Volker Dobler
wrote:
> On Sunday, 3 January 2021 at 18:43:22 UTC+1 ren...@ix.netcom.com wrote:
>
>> I do believe (hope) David was kidding. Anonymous product types (and
>> similar constructs) are the root of all evil.
>>
>
> Yes, you need dependent product types.
On Sun, Jan 3, 2021 at 6:32 PM roger peppe wrote:
> FWIW I'm certain that the lack of tuples in Go was a very deliberate
> decision - one of Go's more significant ancestors, Limbo, had tuples.
> Anonymous product types have their disadvantages too (you don't get to
> name the members, so code
On Sunday, 3 January 2021 at 18:43:22 UTC+1 ren...@ix.netcom.com wrote:
> I do believe (hope) David was kidding. Anonymous product types (and
> similar constructs) are the root of all evil.
>
Yes, you need dependent product types. Especially anonymous ones.
(Just be be clear: I _am_ kidding.)
I do believe (hope) David was kidding. Anonymous product types (and similar
constructs) are the root of all evil.
> On Jan 3, 2021, at 11:32 AM, roger peppe wrote:
>
> FWIW I'm certain that the lack of tuples in Go was a very deliberate decision
> - one of Go's more significant ancestors,
FWIW I'm certain that the lack of tuples in Go was a very deliberate
decision - one of Go's more significant ancestors, Limbo, had tuples.
Anonymous product types have their disadvantages too (you don't get to name
the members, so code can end up significantly harder to understand), which
I
On Thu, Dec 31, 2020 at 9:45 PM da...@suarezhouse.net
wrote:
> Real use cases have been provided it appears for both why generics can be
> good and how they can be used negligently (love the sextuple example BTW).
Some future language will invent the idea that you should be able to create
Thinking about this some more, I am not sure it is viable. Important
operations, like “putIfAbsent” would not be possible with the current Go map
syntax.
That being said, many of the Java collections interfaces declare “optional”
methods, and I guess that could be used here. It would be easy
On Fri, Jan 1, 2021 at 12:40 PM robert engels wrote:
>
> I was thinking more of an internal api - maybe stdlib authors only - writing
> code similar to map.go to create an alternate map type, and allow selecting
> of that map type in the make() call. It would be more difficult to write the
>
I was thinking more of an internal api - maybe stdlib authors only - writing
code similar to map.go to create an alternate map type, and allow selecting of
that map type in the make() call. It would be more difficult to write the
collections implementation, and the methods available are fixed
On Fri, Jan 1, 2021 at 10:25 AM robert engels wrote:
>
> To Ian’s point, what if I could declare a map that had the semantics of a
> concurrent hash map without adding generics? I think something like this
> gives Go a leg up, rather than just making it “closer to Java” as some
> complain.
100% - I use generics all the time in Java - but do these cases warrant the
inclusion of generics in Go? There is more to that than use cases - which is
why this thread is a bit misdirected. Go is strange in that way - it has a few
built-in type safe containers that are very versatile. If these
I share some of the OP's concerns. At the moment, I am horrified at the
syntax of some of the more advanced generics examples in the proposals,
particularly when you throw contracts, methods and stuffs into the mix.
There are just way too many brackets to my liking. In a typical IDEs, they
use
On Dec 31, 2020, at 11:54 AM, 'Axel Wagner' via golang-nuts
wrote:
>
> On Thu, Dec 31, 2020 at 5:46 PM robert engels wrote:
> I’ll state for the record again, I was originally very dismayed that Go did
> not offer generics - after developing with it for a while that is far less of
> an issue
> The real magic is being able to discern what the things are that can be
useful enough to justify their cost, not just to stop. Stopping is trivial
- you could just set the Go repository to archive mode and it will never
change again.
One of the key Go values is simplicity. Keeping langage spec
On Fri, Jan 1, 2021 at 2:14 PM Space A. wrote:
> So magic here is being able to say "stop".
>
The real magic is being able to discern what the things are that can be
useful enough to justify their cost, not just to stop. Stopping is trivial
- you could just set the Go repository to archive mode
You will always find use cases for anything even for absolutely useless
things. Because real life is full of paradoxes, and people are always
irrational. And you may be adding features again and again and you still
will have more to add. This way anything including programming language
becomes a
On Fri, Jan 1, 2021 at 8:15 AM Robert Engels wrote:
> Of course. But you don’t design a language (or any other product) for the
> 5% - you design it for the 95 (80?} percent - if you want you have
> customers/users and stay relevant (in business).
>
I take it. I don't have data to make
Of course. But you don’t design a language (or any other product) for the 5% -
you design it for the 95 (80?} percent - if you want you have customers/users
and stay relevant (in business).
> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts
> wrote:
>
>
>> On Thu, Dec 31, 2020
On Thu, Dec 31, 2020 at 6:51 PM robert engels wrote:
> Go has been in existence for 10+ years and has fairly wide adoption in
> some areas - so it is not hard to make the case that generics are “not an
> important thing”
>
This has been brought up in That Other Thread, so let me copy what I
Real use cases have been provided it appears for both why generics can be
good and how they can be used negligently (love the sextuple example BTW).
I know many things in programming can be used the wrong way but does
generics potentially cross a threshold where the writer should add an
On Thu, Dec 31, 2020 at 5:42 AM Kevin Chadwick wrote:
>
> On 12/30/20 6:38 PM, Ian Lance Taylor wrote:
> > I don't think this is accurate. Surveys express a clear and
> > consistent desire for generics that is far ahead of requests for
> > operator overloading or other language features. (To
On Thu, Dec 31, 2020 at 4:56 AM Space A. wrote:
>
> ok, so please read it finally and tell which point exactly you think was
> against CoC and in what of my messages and in which exact thread, but do not
> put my words out of context. And explain why you responded just now, and to
> my message
Here's one real life example that I came across recently.
I have a CRUD API that supports a bunch of different entity types. They all
support a superset of the same operations.
Each method represents a single HTTP call.
If the generics proposal was implemented, I'd be able to define a common
> hi Space,
Hey,
> i do not care about this discussion in general
> i would not want to enter into a discussion with you
So it's up to you, isn't it? Should I invite you? Or maybe anyone else
should? I don't know you and don't care about your existence (as you said,
I don't mean any
Go has been in existence for 10+ years and has fairly wide adoption in some
areas - so it is not hard to make the case that generics are “not an important
thing” - depends on what you are trying to do with it and what your perspective
on “the right way” is.
> On Dec 31, 2020, at 10:54 AM,
On Thu, Dec 31, 2020 at 5:46 PM robert engels wrote:
> I’ll state for the record again, I was originally very dismayed that Go
> did not offer generics - after developing with it for a while that is far
> less of an issue to me than the error handling.
>
Just to illustrate that the plural of
95% was a recalled-guess. I previously linked to an academic paper that studied
uses of generics in Java, and I believe that was the number - regardless it was
a very, very high percentage.
Interestingly, I had a previous client that was a case-study in generics gone
wrong. No kidding, they
hi Space,
i do not care about this discussion in general and learned to trust the
go developers to be thoughtful and reasonable.
i wouldn't write this normally, but in case you are not aware it might
actually help: i did read the last couple of your messages to this list
again and came to
On 12/30/20 6:38 PM, Ian Lance Taylor wrote:
> I don't think this is accurate. Surveys express a clear and
> consistent desire for generics that is far ahead of requests for
> operator overloading or other language features. (To avoid
> misunderstanding I'll say again that changes to the Go
Hi,
ok, so please read it finally and tell which point exactly you think was
against CoC and in what of my messages and in which exact thread, but do
not put my words out of context. And explain why you responded just now,
and to my message to a person who obviously *violated* its terms by
Space A,
> So switching from subject to my personality and telling me what I should
> and what shouldn't, to whom to listen, and what to read is something in
> line with "code of conduct" which you appeal as the argument of last resort?
>
I've seen how you carry yourself on this list, and you
Hi Martin,
You've been very willing in this thread to listen to feedback, and I
appreciate that. I hope it doesn't feel like I'm ganging up on you, but I
want to comment on one other point I disagree with in your original premise.
I believe that the resilience of Go against unnecessary change is
Agreed.
I had proposed a different approach, where the built-in map and slice could
have alternative implementations chosen during make(). 95% of generics usage is
collections. I think this would have retained the simplicity of Go a bit better
than generics - but at the end of day - generics
I would like a type-safe version of sync.Map().
On Wednesday, 30 December 2020 at 23:02:48 UTC ren...@ix.netcom.com wrote:
> I don't know how Go users can be ‘anti interface’ - literally 95% of the
> stdlib is based on interfaces. If you use the stdlib, you use interfaces.
>
> On Dec 30, 2020,
I don't know how Go users can be ‘anti interface’ - literally 95% of the stdlib
is based on interfaces. If you use the stdlib, you use interfaces.
> On Dec 30, 2020, at 9:44 AM, Jesper Louis Andersen
> wrote:
>
> On Wed, Dec 30, 2020 at 3:37 PM Jan Mercl <0xj...@gmail.com
>
Nice.
> You should listen to people who have been doing this much longer than you
Thanks, are you sure you know for how long I've been doing *this* to be
able to compare?
> before discarding all their points as "bullshit"
Have *you* actually read and listened because this is not what I've said?
>
This topic has shown little other than that a few people here are unwilling to
consider points of view other than their own and declare that very real
problems are not real.
You should listen to people who have been doing this much longer than you have
before discarding all their points as
"runtime type-casting"
"type safety something"
"boilerplate"
"amount of code"
"benefit something"
"greatly simplified" (for whom?)
This topic has clearly shown that most people pro-generic have no *real
world* problems that they struggle to solve, yet most of them don't even
understand what
On Wed, Dec 30, 2020 at 7:38 PM Ian Lance Taylor wrote:
> I don't think this is accurate. Surveys express a clear and
> consistent desire for generics that is far ahead of requests for
> operator overloading or other language features.
No ordering or quantitative comparison was implied. Just
On Wed, Dec 30, 2020 at 6:38 AM Jan Mercl <0xj...@gmail.com> wrote:
>
> FTR: Popular vote also demands exceptions or hidden execution control
> for errors, operator overloading and other things that IMO Go avoided
> intentionally. Because there's no good reason to have just yet another
>
On 12/30/20 2:36 PM, Jan Mercl wrote:
> Because there's no good reason to have just yet another
> Java/C++/you-name-it programming language.
I get that point but I have lots of reasons to prefer Go over those. Mostly
readability (but also using utf-16, is just wrong). I know Ian is reportedly
On Wed, Dec 30, 2020 at 3:37 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> Don't get me wrong. No doubt there are use cases which cannot be
> solved reasonably without generics. No doubt there are many other
> cases where generics will be an elegant and still readable solution
> either.
>
>
I don't
On Wed, Dec 30, 2020 at 3:09 PM Jesper Louis Andersen
wrote:
> Almost. It requires me to cast, so I'm wrapping it in a set of functions
> which makes that cast. With generics, I can get rid of that boilerplate.
(Casting? Method receivers have static types.) So some use cases boil
down to
On Sun, Dec 27, 2020 at 7:51 PM Jan Mercl <0xj...@gmail.com> wrote:
> On Sun, Dec 27, 2020 at 3:51 PM Jesper Louis Andersen
> wrote:
>
> > I need a heap over any type which can be ordered, and its needs to drag
> around any type of satellite data.
>
> I'm confused. Isn't that what
>
On Sun, Dec 27, 2020 at 3:51 PM Jesper Louis Andersen
wrote:
> I need a heap over any type which can be ordered, and its needs to drag
> around any type of satellite data.
I'm confused. Isn't that what
https://golang.org/pkg/container/heap/#Interface provides already?
--
You received this
If Go with generics wax released tomorrow I have about 8 kubernetes
controllers that I'd be porting to use a type safe version of the work
queue to.
This isn't theoretical, I will do this week 1 of generics being available.
It is all production code.
On Thu, 24 Dec 2020, 06:15 Martin Hanson,
On Thu, Dec 24, 2020 at 7:15 AM Martin Hanson
wrote:
> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
>
Maintaining type safety is a lot easier with generics. Right now, my
Indeed. I'm working on a boolean logic package that has a number of different
bitfield oriented backends, all of which will have a lot of very needlessly
repetitive code without generics. If generics weren't coming "soon" I'd
consider writing a generator to build it, but generics are the much
On Thu, Dec 24, 2020, 1:18 AM Martin Hanson
wrote:
> I'm sorry, but this is not real life problems. This is exactly the problem
> with this proposal. It's based on nothing but small theoretical examples.
>
Sorry, I don't understand.
Here are some of the example applications which Ian mentions
I second this. Linear Algebra code would dramatically benefit from
generics. Code would become much more simpler if you could write Tensor and
Matrix code independent of the type of the numeric values used by those
types.
Practical applications are graphics libraries, geography applications
I agree.
A lot of Gonum code would be greatly simplified with the availability
of generics, particularly the linear algebra part. The graph packages
would be richer and we could do more things with tensor-like
operations.
On Wed, 2020-12-23 at 23:54 -0800, Marcin Romaszewicz wrote:
> Those are
On Thu, Dec 24, 2020 at 8:30 AM Martin Hanson
wrote:
> I write this from my understanding of the "Proposal selection criteria",
> which clearly states, that in order for a proposal to be accepted, it has
> to "address an important issue for many people".
>
It does. There is absolutely zero
Hi,
I apologize but I must disagree.
Those *are* real life examples.
At least they're extracted from these.
Especially the 'chans' package (the set of generic functions that apply to any
'chan T') or the 'mapreduce' one.
You can't discard those away from the back of your hand.
-s
Sent from
Those are simple examples of real world problems. I've been writing Go
since the very beginning, having worked at Google when it was released and
since I enjoy the language so much, I try to write all the backend server
code in Go that I can. In these years, I've had to write many code
generators
While the example of ReverseSlice doesn't appear in my work experience, the
concept of writing functions for slices independent of type is pretty
common for me.
Not having to copy to/from []someInterface or having to write (or go
generate) multiple versions of the code differing only on the type
Oh, I almost forgot, it also clearly does not "have minimal impact on everybody
else", which is another proposal selection criteria. Go code becomes much more
complex to read and understand from all the examples I have seen.
You can even find several YouTube videos with people trying to analyze
I write this from my understanding of the "Proposal selection criteria", which
clearly states, that in order for a proposal to be accepted, it has to "address
an important issue for many people".
This is why I'm asking for real life problem examples, not theoretical ones.
I do not believe that
I'm sorry, but this is not real life problems. This is exactly the problem with
this proposal. It's based on nothing but small theoretical examples.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
On Wed, Dec 23, 2020 at 10:15 PM Martin Hanson
wrote:
>
> I have been arguing passionately against adding generics to Go because
> I truly believe that it is going against the simplicity of Go and the
> philosophy behind the design of Go.
>
> I believe that the resilience of Go against
I have been arguing passionately against adding generics to Go because
I truly believe that it is going against the simplicity of Go and the
philosophy behind the design of Go.
I believe that the resilience of Go against unnecessary change is of
vital importance. The experience provided by Ken
61 matches
Mail list logo
