[go-nuts] Re: All Forms of Wishful Generics

I agree that this is one of the two large risks. The other is whether the language remains comparatively easy to learn. The next largest problem after those two is "what exactly do you mean by generics"? Some people want code stenciling, like C++ (it's fast, it's easy to understand, code size

[go-nuts] Re: All Forms of Wishful Generics

> > This seems deeply insightful to me. Thanks Michael. It's not just maps, slices, append, and make. Every single operator could > be considered too to be "generic" because each operates on an indefinite > number of types. > But Go gains much from the special-case syntax and semantics

[go-nuts] Re: All Forms of Wishful Generics

On Monday, 19 February 2018 12:06:09 UTC+2, RickyS wrote: > > Back when I first learned about the diamond problem with multiple > inheritance, I've known we need someone to invent the next and better thing > after inheritance. I do hope somebody smarter than me is somewhere trying. > Or even

Re: [go-nuts] Re: All Forms of Wishful Generics

+1 On Monday, February 19, 2018 at 12:37:14 PM UTC-5, Michael Jones wrote: > > Matthew Juran wrote: *"...but if you use maps, slices, append, make, you > are already using generics."* > > This seems deeply insightful to me. Perhaps a better question than the > self-defeatingly open question of

Re: [go-nuts] Re: All Forms of Wishful Generics

On Mon, Feb 19, 2018 at 9:29 PM Rob Pike wrote: > Jesper, > > I find myself in rare but mild disagreement about your claims for > stack-based virtual machines. Please have a look at this short paper about > the Dis VM from Inferno: http://flint.cs.yale.edu/jvmsem/doc/inferno.ps

Re: [go-nuts] Re: All Forms of Wishful Generics

Jesper, I find myself in rare but mild disagreement about your claims for stack-based virtual machines. Please have a look at this short paper about the Dis VM from Inferno: http://flint.cs.yale.edu/jvmsem/doc/inferno.ps We found a JIT for Dis could be tiny, especially compared to Java JITs, and

Re: [go-nuts] Re: All Forms of Wishful Generics

On 19 February 2018 at 17:36, Michael Jones wrote: > Matthew Juran wrote: "...but if you use maps, slices, append, make, you are > already using generics." > > This seems deeply insightful to me. Perhaps a better question than the > self-defeatingly open question of "how

Re: [go-nuts] Re: All Forms of Wishful Generics

Matthew Juran wrote: *"...but if you use maps, slices, append, make, you are already using generics."* This seems deeply insightful to me. Perhaps a better question than the self-defeatingly open question of "how should Go embrace generics?" would be "what change would allow maps, slices, append,

Re: [go-nuts] Re: All Forms of Wishful Generics

> > I would probably never use it, like many people who comes to Go from C. But if you use maps, slices, append, make, you are already using generics. Maybe this is unfounded, but I'm far from convinced that generics would > make my experience of Go better. I'm really thinking here of, are we

Re: [go-nuts] Re: All Forms of Wishful Generics

I disagree that generics would decrease readability at the call site. Perhaps within the library where it is used but maybe not even there. The only complexity is within the compiler and other internals. This is not irrelevant by far but the carte blanche "generics is bad" is most often hyperbole.

[go-nuts] Re: All Forms of Wishful Generics

On Monday, February 19, 2018 at 4:04:12 PM UTC+1, Ignazio Di Napoli wrote: > > data2 := found.(float32) // THIS PANICS AT RUNTIME, data2 is int > Sorry, found is int. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

[go-nuts] Re: All Forms of Wishful Generics

The only time I "needed" generics was for an r-tree container I wrote. I'd been much happier if I could statically catch my errors about contained data type, instead of catching them at runtime with panics during conversion. For example: x := 0.0 y := 0.0 data := 1

[go-nuts] Re: All Forms of Wishful Generics

> > I think everybody here is aware that some people really want generics and > that generics would probably be useful for everybody. Instead of restating > that why not share what you think about this version of Go generics? > > IMO this is not a proven statement. One of the things that for me

Re: [go-nuts] Re: All Forms of Wishful Generics

On Sun, Feb 18, 2018 at 4:47 AM Lars Seipel wrote: > > Go already has a NaCl backend which might fit the bill. See > misc/nacl/README for how to set it up. It links to a design document > (https://golang.org/s/go13nacl) with some background. > > The sucessor of that

[go-nuts] Re: All Forms of Wishful Generics

Yeah! And since I've learnt English mostly from SciFi and Fantasy movie heroes (with a misplaced sense of self-righteousness), I make boo boos from time to time - which are not that harmful and entertain people! :) There are other things that I might be interested to be improved about Go

[go-nuts] Re: All Forms of Wishful Generics

1. Oh, I'm all for improvement. I just want somebody to invent something in the field of re-use that is as much a breakthrough as Cooperating Sequential Processes was to the field of multi-processing. Go would be a good place to install that invention, as it is still a simple

[go-nuts] Re: All Forms of Wishful Generics

This is a great talk on designing PLs, by Brian Kernighan in which he describes (too) how Perl stops being relevant by providing too little, too late. Again, improvements can be made in term of things other than just the syntax or

[go-nuts] Re: All Forms of Wishful Generics

Dogan, Why does it have to be a breaking change? And there are other things too that are equally - if not more - important to me (the provided link to the list). RickyS, The success of Go in the field of application development (besides it's success in the devops and infrastructure sector)

[go-nuts] Re: All Forms of Wishful Generics

Generics would divide the Go community. I would probably never use it, like many people who comes to Go from C. People who are already experienced Go programmers also likely to avoid it. Java programmers on the other hand will surely overuse it. There it is, you have two different Go code

[go-nuts] Re: All Forms of Wishful Generics

Back when I first learned about the diamond problem with multiple inheritance, I've known we need someone to invent the next and better thing after inheritance. I do hope somebody smarter than me is somewhere trying. Or even has succeeded. And back when I first learned about the code bloat

Re: [go-nuts] Re: All Forms of Wishful Generics

Lars, That's nice! Yet it's a sandboxed execution context. The Safe Packages mentioned above are just Go packages, with source code. And when the day comes for a proper dependency manager, I would like to be able to tell the DM fail on import any unsafe packages - except for a list that I

Re: [go-nuts] Re: All Forms of Wishful Generics

On Sat, Feb 17, 2018 at 01:10:29AM -0800, dc0d wrote: > There are other things too, that I would like to have in Go; like a faster > FFI/CGO, or safe packages by restricting features so that a Go package > cannot harm the hosting machine or application, like Safe Tcl Go already has a NaCl

[go-nuts] Re: All Forms of Wishful Generics

> > Competition is good, only when the Go team feels the heat of competition > they will think about working on their type system seriously. I think everybody here is aware that some people really want generics and that generics would probably be useful for everybody. Instead of restating

[go-nuts] Re: All Forms of Wishful Generics

Indeed it's a form of package/block level code-specialization, so called generics. There is a proposal for package level generics by me too. My main concern here was to have this feature without invalidating current Go code bases, by allowing the rebinding of Type Aliases

[go-nuts] Re: All Forms of Wishful Generics

Agreed. But it's not necessarily a "obsolescence" vs "being crushed (...)" thing. With the brainpower behind Go, sure the best things will happen. I'm not saying that Go has to add generics (or not). In fact generics is just one of the things that I would like to see in Go. There are other

[go-nuts] Re: All Forms of Wishful Generics

I certainly don’t want what happened to C++ to happen to Go. If it’s a choice between obsolescence or being crushed under the weight of self inflicted complexity, I’ll gladly vote with my feet for the former. -- You received this message because you are subscribed to the Google Groups

[go-nuts] Re: All Forms of Wishful Generics

Go is hot right now just like Rails or Node.js used to be hot. So people feel compelled to use the hip thing right now even when they hate it because of fear of missing out. There are better languages out there like Ada who do everything Go does, including concurrency but better and have

[go-nuts] Re: All Forms of Wishful Generics

Can you write some examples that use these types? Matt On Friday, February 16, 2018 at 6:37:47 AM UTC-6, dc0d wrote: > > “There are only two kinds of languages: the ones people complain about and > the ones nobody uses.” > > ― Bjarne Stroustrup, > > I use other programming languages too -

[go-nuts] Re: All Forms of Wishful Generics

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup, I use other programming languages too - obviously. And I will continue to think of better ways to perform Go, if not complaining. Meanwhile this

[go-nuts] Re: All Forms of Wishful Generics

Have a look at Rust, Ada or even C++, they all have some form of generic programming and are fast or faster than Go. Bonus, none of these use garbage collection. Don't hold your breath with Go getting any substantial changes in its type system. Move on. Developers should use tools that suit