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

[Mandolyte]

+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

[Jesper Louis Andersen]

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

[Rob Pike]

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

[roger peppe]

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

[Michael Jones]

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

[matthewjuran]

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

[Henrik Johansson]

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

[Jesper Louis Andersen]

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

[dc0d]

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

[Lars Seipel]

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.