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 "how should Go embrace generics?" would > be "what change would allow maps, slices, append, and make to be > implemented as user code in Go 2?" > > On Mon, Feb 19, 2018 at 8:53 AM, > > wrote: > >> 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 really >>> sure they would make large unfamiliar codebases more comprehensible? Every >>> feature of a language can be abused, so are they worth the abuse that they >>> would allow? >> >> >> Sometimes having another built-in function would be helpful, and generics >> would provide a way to write those without changing the compiler. What I’ve >> seen is that built-in functions and new types expanding on the map/slice >> pattern will not make it into Go 2 without a major reason. >> >> The other call for generics is interface{}. The Go 1 uses of interface{} >> can make strange code that maybe would be more comprehensible another way. >> >> Matt >> >> On Monday, February 19, 2018 at 9:50:53 AM UTC-6, Henrik Johansson wrote: >>> >>> 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. >>> >>> I can also "do without" generics and in fact even though Go lacks it I >>> prefer Go to all other languages that I know. I still would appreciate a >>> generics version in Go's spirit. >>> >>> On Mon, Feb 19, 2018, 16:06 Ignazio Di Napoli wrote: >>> 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 this group and stop receiving emails from it, send an email to golang-nuts...@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...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Michael T. Jones > michae...@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: 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 > > There is a chance I'm just wrong here. The webassembly paper[0] mentions the size of the program as being important. They compare this size to older models such as NaCl and asm.js, and they note the stack based instruction set makes for a smaller "binary size". However, I have a feeling that a well-engineered VM, register-based or not, is likely to be able to compete in size of the produced executable. The obvious reason for wanting that size down is bandwidth usage on the internet. While caching can play a role, transfer sizes does matter in the end, especially given mobile. My experience, though YMMV, is that when a VM is based on registers and matches a real-world CPU more closely, it is easier to write a compiler/JIT from the bytecode to the machine instructions. On the other hand, if the VM is based on a stack, it is easier to write a compiler from a high-level language to the bytecode. In short, you pick a "split point" of abstraction and this makes one or the other easier to implement. Efficiency was not something I touched upon in the post, but I have a hunch that the experiences of Dis carries over: a VM close to the machine is easier to get to run fast, with a fraction of the investment. The brilliance of WebAssembly is that it is really both models in one. The "transfer format" over the wire is a stack-based instruction set. But the instructions are built in such a way that we can derive a register machine from it at any point in the program (statically!). So you obtain a relatively easy compile target, and small bytecode "binaries". But once you want to execute the program, you first convert the machine to something else, probably resembling Dis, and then you proceed to handle that new machine. [0] https://people.mpi-sws.org/~rossberg/papers/Haas,%20Rossberg,%20Schuff,%20Titzer,%20Gohman,%20Wagner,%20Zakai,%20Bastien,%20Holman%20-%20Bringing%20the%20Web%20up%20to%20Speed%20with%20WebAssembly.pdf -- 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: 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 at the time outperformed Java. -rob On Tue, Feb 20, 2018 at 12:26 AM, Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > 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 project is WebAssembly. > > WebAssembly is a really good design, where the virtual machine is formally > specified, with a testbed implementation in Ocaml. One of the defining > features is that the VM is a stack-vm with a twist: > > * Stack-based VMs usually have smaller opcodes (since you don't have to > specify registers to operate on) > * Stack-based VMs are usually easier to target > * WebAsm's VM is built in a way such that the layout of the stack is > statically known at compile time. > > The latter means that you can compile it to a register-based VM, which > tend to be faster at execution. > > Ok, C programs can only be implemented in it if you provide a shadow > stack. But given that C generally allows too much of the programmer, this > is perfect :) Also note, I don't think Go would need a shadow stack, but > there might be a subtlety somewhere which mandates it. > > -- > 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: 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 should Go embrace generics?" would be > "what change would allow maps, slices, append, and make to be implemented as > user code in Go 2?" 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 associated with each of these language features, IMHO. I'm sure one could make a language where maps, slices, pointers, etc were all just generic types and operations. I'm sure there are many such languages already. Such a language would make for a very different experience than Go provides, though. If maps are just user code in Go 2, what about map literals? If slices are just user code, do we have to be wary that everything that looks like an index operation might have arbitrary side-effects? If channels are just user code, can we still have a select statement? The difficulty of generics is not to provide some number of generic container types, but how to provide a *general* way of specifying operations generically over types. [By the way, I think any discussion on generics in Go is hampered by the fact that the term itself is not well defined. Everyone has their own idea what "generics" might mean, and it's easy to talk at cross purposes.] -- 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: 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, and make to be implemented as user code in Go 2?" On Mon, Feb 19, 2018 at 8:53 AM, wrote: > 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 really >> sure they would make large unfamiliar codebases more comprehensible? Every >> feature of a language can be abused, so are they worth the abuse that they >> would allow? > > > Sometimes having another built-in function would be helpful, and generics > would provide a way to write those without changing the compiler. What I’ve > seen is that built-in functions and new types expanding on the map/slice > pattern will not make it into Go 2 without a major reason. > > The other call for generics is interface{}. The Go 1 uses of interface{} > can make strange code that maybe would be more comprehensible another way. > > Matt > > On Monday, February 19, 2018 at 9:50:53 AM UTC-6, Henrik Johansson wrote: >> >> 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. >> >> I can also "do without" generics and in fact even though Go lacks it I >> prefer Go to all other languages that I know. I still would appreciate a >> generics version in Go's spirit. >> >> On Mon, Feb 19, 2018, 16:06 Ignazio Di Napoli wrote: >> >>> >>> 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 this group and stop receiving emails from it, send >>> an email to golang-nuts...@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. > -- Michael T. Jones michael.jo...@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: 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 really > sure they would make large unfamiliar codebases more comprehensible? Every > feature of a language can be abused, so are they worth the abuse that they > would allow? Sometimes having another built-in function would be helpful, and generics would provide a way to write those without changing the compiler. What I’ve seen is that built-in functions and new types expanding on the map/slice pattern will not make it into Go 2 without a major reason. The other call for generics is interface{}. The Go 1 uses of interface{} can make strange code that maybe would be more comprehensible another way. Matt On Monday, February 19, 2018 at 9:50:53 AM UTC-6, Henrik Johansson wrote: > > 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. > > I can also "do without" generics and in fact even though Go lacks it I > prefer Go to all other languages that I know. I still would appreciate a > generics version in Go's spirit. > > On Mon, Feb 19, 2018, 16:06 Ignazio Di Napoli > wrote: > >> >> 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 this group and stop receiving emails from it, send an >> email to golang-nuts...@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: 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. I can also "do without" generics and in fact even though Go lacks it I prefer Go to all other languages that I know. I still would appreciate a generics version in Go's spirit. On Mon, Feb 19, 2018, 16:06 Ignazio Di Napoli wrote: > > 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 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: 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 project is WebAssembly. WebAssembly is a really good design, where the virtual machine is formally specified, with a testbed implementation in Ocaml. One of the defining features is that the VM is a stack-vm with a twist: * Stack-based VMs usually have smaller opcodes (since you don't have to specify registers to operate on) * Stack-based VMs are usually easier to target * WebAsm's VM is built in a way such that the layout of the stack is statically known at compile time. The latter means that you can compile it to a register-based VM, which tend to be faster at execution. Ok, C programs can only be implemented in it if you provide a shadow stack. But given that C generally allows too much of the programmer, this is perfect :) Also note, I don't think Go would need a shadow stack, but there might be a subtlety somewhere which mandates it. -- 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: 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 trust. On Sunday, February 18, 2018 at 7:17:56 AM UTC+3:30, Lars Seipel wrote: > > 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 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. > -- 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: 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 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. -- 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.