Re: [go-nuts] Re: Go’s runtime vs virtual machine

[andrey mirtchovski]

> most languages offer programs at least some operating system like services 
> via a runtime service layer
> -> in C, this was initially "crt0" the thin c runtime
> -> in Go, the service layer is richer, offering thread management and 
> goroutine multiplexing, garbage collection, and more.
>
> the Go runtime is written in Go mostly and uses C or assembler to connect to 
> the host operating system.
> the Go runtime is linked with the developer's Go code, and the two of them 
> are constitute the output of go build or go install

I would add that, unlike VMs simulating CPUs, there can't be a
matryoshka-doll infinity of Go runtimes resting on other Go runtimes.
There is just one, which interfaces with the underlying OS directly.

-- 
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: Go’s runtime vs virtual machine

[Michael Jones]

I might tell students step by step:

machine code is understood and executed by a machine.
-> the intel instruction to increment a register is decoded and executed by
the CPU's hardware.

virtual code is understood and executed by a program that pretends to be
some virtual CPU.
-> a Java VM might run on an intel CPU and understand and execute Java
virtual machine instructions.

-> a Java VM might run on an intel VM that actually runs on an ARM CPU...
-> ...like a Russian matryoshka doll, there can be any number of outer VMs
before the innermost real CPU.

operating systems provide protection, resource allocation, and services.

most languages offer programs at least some operating system like services
via a runtime service layer
-> in C, this was initially "crt0" the thin c runtime
-> in Go, the service layer is richer, offering thread management and
goroutine multiplexing, garbage collection, and more.

the Go runtime is written in Go mostly and uses C or assembler to connect
to the host operating system.
the Go runtime is linked with the developer's Go code, and the two of them
are constitute the output of go build or go install



On Tue, Sep 4, 2018 at 5:15 PM Christopher Nielsen 
wrote:

> Hi Pablo,
>
> Yes, that sounds like a reasonable differentiation for students. Of
> course, it is more complex than that, but it's a good first principles
> introduction.
>
> Cheers,
> Chris
>
>
> On Tue, Sep 4, 2018, 16:57 Pablo Rozas Larraondo <
> p.rozas.larrao...@gmail.com> wrote:
>
>> Thanks for the answers. I asked this question because I'm preparing some
>> tutorials to explain Go to students and I'm thinking about potential
>> questions and discussions.
>>
>> If I understand it correctly we could say then that Go's runtime has
>> things in common with a VM's runtime (I'm thinking mostly in Java's) such
>> as GC, goroutine (thread) scheduling, etc. However, Go's runtime cannot be
>> considered a VM because it does not compile code to an intermediate
>> language, it executes compiled native code instead.
>>
>> Cheers,
>> Pablo
>>
>>
>>
>> On Wednesday, September 5, 2018 at 3:01:52 AM UTC+10, Jake Montgomery
>> wrote:
>>>
>>> There are a lot of differences, and for the answer to be complete, you
>>> would need to specify which language you wanted to compare it to. But on a
>>> really simple level, thwd's answer is more or less correct. A VM language
>>> is usually compiled into an instruction set for that VM. The VM then
>>> provides a lot of "special sauce." Go is (usually) compiled directly into
>>> machine code to be executed directly on the target system.
>>>
>>> One consequence of this is that the executable can be run without having
>>> any other software installed on the machine. It also  means that the code
>>> for the stuff you inquired about such as the garbage collector, goroutine
>>> scheduling and stack management, is all present in the single executable
>>> compiled by go.
>>>
>>> As for learning more, it depends somewhat on what your experience level
>>> is, and why you want to know. If you are relatively new to programming, I
>>> would recommend just using go for a while, without worrying too much about
>>> the "magic."  If you have a strong background already, you could start
>>> learning about the stuff you mentioned. Garbage collection would be an
>>> interesting place to start. I don't know of any one resource, but there are
>>> a number of interesting videos (gophercon, ect) by principal architects on
>>> the subject. Keep in mind that all these things are constantly evolving, so
>>> any information you get may not apply to the latest version of the
>>> language.
>>>
>>> Good luck.
>>>
>>>
>>>
>>> On Tuesday, September 4, 2018 at 10:50:03 AM UTC-4, thwd wrote:

 A virtual machine has its own instruction set. Go compiles to machine
 code for a given target (which could be a virtual machine).

 On Tuesday, September 4, 2018 at 12:27:49 PM UTC+2, Pablo Rozas
 Larraondo wrote:
>
> The Go documentation provides some explanation about the difference
> between Go’s runtime and a virtual machine here:
>
> https://golang.org/doc/faq#runtime
>
> Does anyone can recommend a good place to learn more about this? I’d
> like to better understand how Go’s garbage collector, goroutine scheduling
> and stack management are handled by the runtime and how it is different
> from a virtual machine.
>
> Thanks,
> Pablo
>
> --
>> 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 

[go-nuts] Re: Why does this struct escape to the heap?

[silviucapota]

Hi Paul,

Check out: https://golang.org/doc/effective_go.html#pointers_vs_values

Basically, in your index1, the opts.isDigit passed to IndexFunc is 
syntactic sugar for ().isDigit -> then the compiler needs to move opts 
on the heap. 

You can either 
a) define an alternate isDigitVal method, e.g. func (opts options) 
isDigitMethodByVal(r rune) bool
or 
b) you can just pass the reference to an original *options from the get go:

func index1Pointer(s string, optsPointer *options) int {
return strings.IndexFunc(s, optsPointer.isDigit)
}

Not sure which one will be faster - you'll need to benchmark. Probably both 
will be about the same, since that single *options allocation tends to zero.

For your index2 function question, I think it's because Go maintains the 
variables from a parent function that are referred in an enclosed function 
(closure) for as long as both are alive. 
I'm guessing that opts.IsDigit(r) is alive and kicking till it returns. 

cheers,
silviu

On Tuesday, 4 September 2018 17:46:09 UTC-4, Paul D wrote:
>
> I'm trying to reduce allocations (and improve performance) in some Go 
> code. There's a recurring pattern in the code where a struct is passed to a 
> function, and the function passes one of the struct's methods to 
> strings.IndexFunc. For some reason, this causes the entire struct to escape 
> to the heap. If I wrap the method call in an anonymous function, the struct 
> does not escape and the benchmarks run about 30% faster.
>
> Here is a minimal example. In the actual code, the struct has more 
> fields/methods and the function in question actually does something. But 
> this sample code illustrates the problem. Why does the opts argument escape 
> to the heap in index1 but not in the functionally equivalent index2? And is 
> there a robust way to ensure that it stays on the stack?
>
>
> type options struct {
> zero rune
> }
>
> func (opts *options) isDigit(r rune) bool {
> r -= opts.zero
> return r >= 0 && r <= 9
> }
>
> // opts escapes to heap
> func index1(s string, opts options) int {
> return strings.IndexFunc(s, opts.isDigit)
> }
>
> // opts does not escape to heap
> func index2(s string, opts options) int {
> return strings.IndexFunc(s, func(r rune) bool {
> return opts.isDigit(r)
> })
> }
>
>
> FYI I'm running Go 1.10.3 on Linux. 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.

[go-nuts] Re: Go’s runtime vs virtual machine

[Volker Dobler]

On Wednesday, 5 September 2018 01:57:33 UTC+2, Pablo Rozas Larraondo wrote:
>
> If I understand it correctly we could say then that Go's runtime has 
> things in common with a VM's runtime (I'm thinking mostly in Java's) such 
> as GC, goroutine (thread) scheduling, etc. However, Go's runtime cannot be 
> considered a VM because it does not compile code to an intermediate 
> language, it executes compiled native code instead.
>

But then one could argue that Go's runtime has things in
common with the operating system such as memory
management and goroutine/thread scheduling, etc.

I probably would explain what the runtime does and why it
does these things. Then explain that these things are
important and that lots of other things provide the same
services, e.g. the kernel or a virtual machine because these
are common hard problems. Lions and and jellyfish both
hunt because they need food but explaining lions in terms
of jellyfish (or the other way around) is probably not helpful
(especially as most students do not have deep understanding
of a lion's or Java VM's internals.)

V.

 

-- 
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 as builtin typeclasses

['Axel Wagner' via golang-nuts]

Oh and of course I make up my own name too, with "pseudo-interfaces" (to
reflect the connection to interfaces in regards to embedding and general
usage).

On Wed, Sep 5, 2018 at 4:12 AM Axel Wagner 
wrote:

> I swear I didn't know about that feedback when I just wrote this ;)
> https://blog.merovius.de/2018/09/05/scrapping_contracts.html
> (i did know about Matt's post and mention it)
>
> I hoped to provide a somewhat extensive argument about why I don't really
> "like" contracts and how interface-based type-parameters can provide the
> same type-safety guarantees and power as the contract design. I'm not sure
> I mention anything new, though, at this point (damn you, real life,
> preventing me from writing this down earlier ^^)
>
> On Tue, Sep 4, 2018 at 11:46 PM alanfo  wrote:
>
>> This idea has similarities to feedback
>>  I've
>> provided myself on the Go 2 generics draft design.
>>
>> However, I've tried to marry it with interfaces and have used the
>> expression 'type group' rather than 'typeclass' so nobody would accuse me
>> of trying to make Go more like Haskell!
>>
>> On Tuesday, September 4, 2018 at 7:57:02 PM UTC+1, Matt Sherman wrote:
>>>
>>> Here’s a riff on generics focused on builtin typeclasses (instead of
>>> user contracts): https://clipperhouse.com/go-generics-typeclasses/
>>>
>>> Feedback welcome.
>>>
>> --
>> 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 as builtin typeclasses

['Axel Wagner' via golang-nuts]

I swear I didn't know about that feedback when I just wrote this ;)
https://blog.merovius.de/2018/09/05/scrapping_contracts.html
(i did know about Matt's post and mention it)

I hoped to provide a somewhat extensive argument about why I don't really
"like" contracts and how interface-based type-parameters can provide the
same type-safety guarantees and power as the contract design. I'm not sure
I mention anything new, though, at this point (damn you, real life,
preventing me from writing this down earlier ^^)

On Tue, Sep 4, 2018 at 11:46 PM alanfo  wrote:

> This idea has similarities to feedback
>  I've
> provided myself on the Go 2 generics draft design.
>
> However, I've tried to marry it with interfaces and have used the
> expression 'type group' rather than 'typeclass' so nobody would accuse me
> of trying to make Go more like Haskell!
>
> On Tuesday, September 4, 2018 at 7:57:02 PM UTC+1, Matt Sherman wrote:
>>
>> Here’s a riff on generics focused on builtin typeclasses (instead of user
>> contracts): https://clipperhouse.com/go-generics-typeclasses/
>>
>> Feedback welcome.
>>
> --
> 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] Link: Getting specific about generics

[Steven Blenkinsop]

On Tuesday, September 4, 2018 at 6:07:32 PM UTC-4, xingtao zhao wrote:

> I was assume that generic interfaces are allowed, which we do not need 
> "self" type.

 

This is *not* equivalent. If you have an interface defined as

 
type Fooer(type T) interface {
 Foo() T
}


this corresponds to a contract written as

 
contract Fooer(s S, t T) {
 interface{ Foo() T }(s)
}


You have two separate type parameters when you're really just trying to 
talk about a single type. You had to write it like this because your 
language is poorly designed. When using the interface, you'd always have to 
write 

 
func DoFoo(type T Fooer(T)) ...


Requiring a generic trait to be used reflexively just so you can talk about 
operations involving multiple values with the same type isn't a good 
design. If would be like saying "we don't have to be able to name the 
receiver variable inside a method because we can always pass the receiver 
value as a separate parameter, like v.String(v)!". This is technically 
true, but if your language is designed like this, I don't want to use it. 
Requiring type constraints to be written like this is the same. You can't 
use the unfamiliarity of a new feature to justify making decisions that 
would be clearly bad ones in a more familiar context.

 

> In terms of convertableTo, it can be put into the operator category, which 
> will be implicitly retrieved from the function body. 

 

"Can" and "should" are two different things. Assume when reading my 
previous and current response that I'm talking about a design where all 
operators and conversions supported by a type parameter have to be 
specified by its contract/interface constraint and can't be implied by the 
body of the function. Having only a partially specified interface makes it 
very easy to accidentally change the interface of your function by, for 
example, calling a function which directly or indirectly performs an 
operation not previously present in your code.

 

> In general, a given concrete type could only satisfy this interface one 
>> way. Having
>
>  
>
> type IntAndFloatTaker interface {
>
>  Taker(type int)
>
>  Taker(type float)
>
> }  
>
>
> I think this is still not allowed, as they have the same function name 
> while different types.

 

That's my point. I'm saying that this could be a useful property. Given a 
parameterized interface I and a type parameter T that implements I(U), 
there can only be exactly one value of U for a given T. This could be used 
to assist type inference. If an interface can contain conversions, however, 
then there are multiple ways the same type can satisfy that interface—since 
a type can support conversions to multiple different types—which means this 
property wouldn't hold. I know you don't think conversions should go in 
interfaces/contracts, but I disagree, so here we are. This property also 
wouldn't hold if generic methods were added to the language. 
Hypothetically, *if* you could have


type Setter(type T) interface {
 Set(T)
}

type S struct{}
func (s S) Set(type T C)(t T) { ... }


and *if* this allowed S to satisfy Setter(T) for any type T that satisfies C, 
then the above property wouldn't hold. The current proposal doesn't suggest 
this, and I think it's probably incompatible with the design goal of 
being implementation agnostic, but it would create a problem if this 
functionality were ever enabled in the future and the previous behaviour 
had been used to inform type inference. The solution used by other 
languages to solve this dilemma is to have type aliases in their equivalent 
of interfaces:


type Setter interface {
 type T
 Set(T)
}

type S struct{}
func (s S) Set(type T C)(t T) { ... }

// This would fail to compile because the compiler can't
// infer the identity of `Setter.T` for `S` based on 
// `S.Set`, since the method can work for any type `T`
// that satisfies `C`:
//
// var _ Setter = S{}
//


Note that my intent here is just to explore the design space. I'm not sure 
whether this is a direction the Go team would be willing to go.

On Tuesday, September 4, 2018 at 6:07:32 PM UTC-4, xingtao zhao wrote:
>
>
>
> On Tuesday, September 4, 2018 at 2:26:58 PM UTC-7, Steven Blenkinsop wrote:
>>
>> If we try to translate contracts into interfaces, the first thing we run 
>> into is that there's no way to refer to the dynamic type of the interface. 
>> Compare:
>>
>>  
>>
>> contract Fooer(t T) {
>>
>>  interface{ Foo() T }(t)
>>
>> }
>>
>>  
>>
>> to
>>
>>  
>>
>> type Fooer interface {
>>
>>  Foo() ???
>>
>> }
>>
>>  
>>
>> There would have to be some sort of self type:
>>
>>  
>>
>> type Fooer interface {
>>
>>  Foo() self
>>
>> }
>>
>>
>> Let's say there's a built in convertibleTo constraint
>>  
>>
>> type FooConvertible interface {
>>
>>  convertibleTo(int)
>>
>>  Foo() self
>>
>> }
>>
>>  
>>
>> For one thing, this looks like a method. (Aside: This is a problem in the 
>> existing generics proposal as 

Re: [go-nuts] Re: Go’s runtime vs virtual machine

[Christopher Nielsen]

Hi Pablo,

Yes, that sounds like a reasonable differentiation for students. Of course,
it is more complex than that, but it's a good first principles introduction.

Cheers,
Chris


On Tue, Sep 4, 2018, 16:57 Pablo Rozas Larraondo <
p.rozas.larrao...@gmail.com> wrote:

> Thanks for the answers. I asked this question because I'm preparing some
> tutorials to explain Go to students and I'm thinking about potential
> questions and discussions.
>
> If I understand it correctly we could say then that Go's runtime has
> things in common with a VM's runtime (I'm thinking mostly in Java's) such
> as GC, goroutine (thread) scheduling, etc. However, Go's runtime cannot be
> considered a VM because it does not compile code to an intermediate
> language, it executes compiled native code instead.
>
> Cheers,
> Pablo
>
>
>
> On Wednesday, September 5, 2018 at 3:01:52 AM UTC+10, Jake Montgomery
> wrote:
>>
>> There are a lot of differences, and for the answer to be complete, you
>> would need to specify which language you wanted to compare it to. But on a
>> really simple level, thwd's answer is more or less correct. A VM language
>> is usually compiled into an instruction set for that VM. The VM then
>> provides a lot of "special sauce." Go is (usually) compiled directly into
>> machine code to be executed directly on the target system.
>>
>> One consequence of this is that the executable can be run without having
>> any other software installed on the machine. It also  means that the code
>> for the stuff you inquired about such as the garbage collector, goroutine
>> scheduling and stack management, is all present in the single executable
>> compiled by go.
>>
>> As for learning more, it depends somewhat on what your experience level
>> is, and why you want to know. If you are relatively new to programming, I
>> would recommend just using go for a while, without worrying too much about
>> the "magic."  If you have a strong background already, you could start
>> learning about the stuff you mentioned. Garbage collection would be an
>> interesting place to start. I don't know of any one resource, but there are
>> a number of interesting videos (gophercon, ect) by principal architects on
>> the subject. Keep in mind that all these things are constantly evolving, so
>> any information you get may not apply to the latest version of the
>> language.
>>
>> Good luck.
>>
>>
>>
>> On Tuesday, September 4, 2018 at 10:50:03 AM UTC-4, thwd wrote:
>>>
>>> A virtual machine has its own instruction set. Go compiles to machine
>>> code for a given target (which could be a virtual machine).
>>>
>>> On Tuesday, September 4, 2018 at 12:27:49 PM UTC+2, Pablo Rozas
>>> Larraondo wrote:

 The Go documentation provides some explanation about the difference
 between Go’s runtime and a virtual machine here:

 https://golang.org/doc/faq#runtime

 Does anyone can recommend a good place to learn more about this? I’d
 like to better understand how Go’s garbage collector, goroutine scheduling
 and stack management are handled by the runtime and how it is different
 from a virtual machine.

 Thanks,
 Pablo

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

[go-nuts] Re: Go’s runtime vs virtual machine

[Pablo Rozas Larraondo]

Thanks for the answers. I asked this question because I'm preparing some 
tutorials to explain Go to students and I'm thinking about potential 
questions and discussions.

If I understand it correctly we could say then that Go's runtime has things 
in common with a VM's runtime (I'm thinking mostly in Java's) such as GC, 
goroutine (thread) scheduling, etc. However, Go's runtime cannot be 
considered a VM because it does not compile code to an intermediate 
language, it executes compiled native code instead.

Cheers,
Pablo

 

On Wednesday, September 5, 2018 at 3:01:52 AM UTC+10, Jake Montgomery wrote:
>
> There are a lot of differences, and for the answer to be complete, you 
> would need to specify which language you wanted to compare it to. But on a 
> really simple level, thwd's answer is more or less correct. A VM language 
> is usually compiled into an instruction set for that VM. The VM then 
> provides a lot of "special sauce." Go is (usually) compiled directly into 
> machine code to be executed directly on the target system. 
>
> One consequence of this is that the executable can be run without having 
> any other software installed on the machine. It also  means that the code 
> for the stuff you inquired about such as the garbage collector, goroutine 
> scheduling and stack management, is all present in the single executable 
> compiled by go.
>
> As for learning more, it depends somewhat on what your experience level 
> is, and why you want to know. If you are relatively new to programming, I 
> would recommend just using go for a while, without worrying too much about 
> the "magic."  If you have a strong background already, you could start 
> learning about the stuff you mentioned. Garbage collection would be an 
> interesting place to start. I don't know of any one resource, but there are 
> a number of interesting videos (gophercon, ect) by principal architects on 
> the subject. Keep in mind that all these things are constantly evolving, so 
> any information you get may not apply to the latest version of the 
> language. 
>
> Good luck.
>
>
>
> On Tuesday, September 4, 2018 at 10:50:03 AM UTC-4, thwd wrote:
>>
>> A virtual machine has its own instruction set. Go compiles to machine 
>> code for a given target (which could be a virtual machine).
>>
>> On Tuesday, September 4, 2018 at 12:27:49 PM UTC+2, Pablo Rozas Larraondo 
>> wrote:
>>>
>>> The Go documentation provides some explanation about the difference 
>>> between Go’s runtime and a virtual machine here:
>>>
>>> https://golang.org/doc/faq#runtime
>>>
>>> Does anyone can recommend a good place to learn more about this? I’d 
>>> like to better understand how Go’s garbage collector, goroutine scheduling 
>>> and stack management are handled by the runtime and how it is different 
>>> from a virtual machine.
>>>
>>> Thanks,
>>> Pablo
>>>
>>>

-- 
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] Link: Getting specific about generics

[xingtao zhao]

On Tuesday, September 4, 2018 at 2:26:58 PM UTC-7, Steven Blenkinsop wrote:
>
> If we try to translate contracts into interfaces, the first thing we run 
> into is that there's no way to refer to the dynamic type of the interface. 
> Compare:
>
>  
>
> contract Fooer(t T) {
>
>  interface{ Foo() T }(t)
>
> }
>
>  
>
> to
>
>  
>
> type Fooer interface {
>
>  Foo() ???
>
> }
>
>  
>
> There would have to be some sort of self type:
>
>  
>
> type Fooer interface {
>
>  Foo() self
>
> }
>
>
> Let's say there's a built in convertibleTo constraint
>  
>
> type FooConvertible interface {
>
>  convertibleTo(int)
>
>  Foo() self
>
> }
>
>  
>
> For one thing, this looks like a method. (Aside: This is a problem in the 
> existing generics proposal as well if generic interfaces are allowed, since 
> interface embedding would become ambiguous.) Presuming that we solve this 
> ambiguity, there's a deeper challenge. If I have a generic interface:
>
>  
>
> type Taker(type T) interface {
>
>  Take() T
>
> }
>
>  
>

I was assume that generic interfaces are allowed, which we do not need 
"self" type. In terms of convertableTo, it can be put into the operator 
category, which will be implicitly retrieved from the function body. 
 

> In general, a given concrete type could only satisfy this interface one 
> way. Having
>
>  
>
> type IntAndFloatTaker interface {
>
>  Taker(type int)
>
>  Taker(type float)
>
> }
>

I think this is still not allowed, as they have the same function name 
while different types.
 

>  
>
> wouldn't work because the same type can't implement both func (...) 
> Take() int and func (...) Take() float. convertibleTo (and convertibleFrom) 
> would be unique in this regard, and could get in the way of (say) being 
> able to infer the type parameters of
>
>  
>
> func Take(type T, U Take)(t T) U { t.Take() }
>
>  
>
> T can be inferred from the argument, and you ought to be able to infer U 
> from T, since T can only implement Taker(type U) for exactly one U. But, 
> if convertibleTo exists, this isn't true in general.
>
>
> This doesn't address operators. You could have builtin constraints for 
> each operator, or each set of operators. Or you could have some sort 
> of builtin method corresponding to each operator. These are certainly 
> doable, but designing and naming the constraints/methods is a whole 
> undertaking which the contracts draft seeks to avoid.
>

As we do not have operator overloading, there are only a few sets of 
operations for each type, for example Numeric, Addable, Hashable, Equality, 
etc, and they can never be changed or extended. These are completely 
hiden/invisible from user as operator constraints are retrieved implicitly. 
So we do not have to name them.

The only thing a contract can do while interface can not, is that we can 
not have constraints on structure fiels, as only methods are allowed in 
interface.
 

>
> On Tue, Sep 4, 2018 at 12:52 PM xingtao zhao  > wrote:
>
>> My five cents:
>>
>> 1) the methods of the type template are defined by interface style
>> 2) operators are retrieved implicitly from function body
>> 3) function-calls inside are also retrieved implicitly from the function 
>> body
>>
>> For graph example, we may declare it as:
>>
>> type Edgeser(type E) interface {
>> Edges() []T
>> }
>> type Nodeser(type N} interface {
>> Nodes() from, to N
>> }
>> type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }
>>
>>
>> On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
>>
>>> On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts 
>>>  wrote: 
>>> > 
>>> > Link: [Getting specific about generics, by Emily 
>>> > Maier](https://emilymaier.net/words/getting-specific-about-generics/) 
>>> > 
>>> > The interface-based alternative to contracts seems like such a natural 
>>> fit- 
>>> > It’s simple, straightforward, and pragmatic. I value those aspects of 
>>> Go’s 
>>> > philosophy and consider them to be features of the language, so it’s 
>>> > encouraging to see a solution that suits them so well. The author also 
>>> does 
>>> > a great job of contextualizing the use cases and debate around 
>>> generics, 
>>> > which I found incredibly helpful. 
>>> > 
>>> > Any thoughts? 
>>>
>>> It's a very nice writeup. 
>>>
>>> It's worth asking how the graph example in the design draft would be 
>>> implemented in an interface-based implementation.  Also the syntactic 
>>> issues are real. 
>>>
>>> Ian 
>>>
>> -- 
>> 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, 

[go-nuts] Why does this struct escape to the heap?

[Paul D]

I'm trying to reduce allocations (and improve performance) in some Go code. 
There's a recurring pattern in the code where a struct is passed to a 
function, and the function passes one of the struct's methods to 
strings.IndexFunc. For some reason, this causes the entire struct to escape 
to the heap. If I wrap the method call in an anonymous function, the struct 
does not escape and the benchmarks run about 30% faster.

Here is a minimal example. In the actual code, the struct has more 
fields/methods and the function in question actually does something. But 
this sample code illustrates the problem. Why does the opts argument escape 
to the heap in index1 but not in the functionally equivalent index2? And is 
there a robust way to ensure that it stays on the stack?


type options struct {
zero rune
}

func (opts *options) isDigit(r rune) bool {
r -= opts.zero
return r >= 0 && r <= 9
}

// opts escapes to heap
func index1(s string, opts options) int {
return strings.IndexFunc(s, opts.isDigit)
}

// opts does not escape to heap
func index2(s string, opts options) int {
return strings.IndexFunc(s, func(r rune) bool {
return opts.isDigit(r)
})
}


FYI I'm running Go 1.10.3 on Linux. 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.

[go-nuts] Re: Generics as builtin typeclasses

[alanfo]

This idea has similarities to feedback 
 I've 
provided myself on the Go 2 generics draft design. 

However, I've tried to marry it with interfaces and have used the 
expression 'type group' rather than 'typeclass' so nobody would accuse me 
of trying to make Go more like Haskell! 

On Tuesday, September 4, 2018 at 7:57:02 PM UTC+1, Matt Sherman wrote:
>
> Here’s a riff on generics focused on builtin typeclasses (instead of user 
> contracts): https://clipperhouse.com/go-generics-typeclasses/
>
> Feedback welcome.
>

-- 
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] Link: Getting specific about generics

[Steven Blenkinsop]

If we try to translate contracts into interfaces, the first thing we run
into is that there's no way to refer to the dynamic type of the interface.
Compare:



contract Fooer(t T) {

 interface{ Foo() T }(t)

}



to



type Fooer interface {

 Foo() ???

}



There would have to be some sort of self type:



type Fooer interface {

 Foo() self

}


Let's say there's a built in convertibleTo constraint


type FooConvertible interface {

 convertibleTo(int)

 Foo() self

}



For one thing, this looks like a method. (Aside: This is a problem in the
existing generics proposal as well if generic interfaces are allowed, since
interface embedding would become ambiguous.) Presuming that we solve this
ambiguity, there's a deeper challenge. If I have a generic interface:



type Taker(type T) interface {

 Take() T

}



In general, a given concrete type could only satisfy this interface one
way. Having



type IntAndFloatTaker interface {

 Taker(type int)

 Taker(type float)

}



wouldn't work because the same type can't implement both func (...) Take()
int and func (...) Take() float. convertibleTo (and convertibleFrom) would
be unique in this regard, and could get in the way of (say) being able to
infer the type parameters of



func Take(type T, U Take)(t T) U { t.Take() }



T can be inferred from the argument, and you ought to be able to infer U
from T, since T can only implement Taker(type U) for exactly one U. But, if
convertibleTo exists, this isn't true in general.


This doesn't address operators. You could have builtin constraints for each
operator, or each set of operators. Or you could have some sort of builtin
method corresponding to each operator. These are certainly doable, but
designing and naming the constraints/methods is a whole undertaking which
the contracts draft seeks to avoid.

On Tue, Sep 4, 2018 at 12:52 PM xingtao zhao  wrote:

> My five cents:
>
> 1) the methods of the type template are defined by interface style
> 2) operators are retrieved implicitly from function body
> 3) function-calls inside are also retrieved implicitly from the function
> body
>
> For graph example, we may declare it as:
>
> type Edgeser(type E) interface {
> Edges() []T
> }
> type Nodeser(type N} interface {
> Nodes() from, to N
> }
> type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }
>
>
> On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
>
>> On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts
>>  wrote:
>> >
>> > Link: [Getting specific about generics, by Emily
>> > Maier](https://emilymaier.net/words/getting-specific-about-generics/)
>> >
>> > The interface-based alternative to contracts seems like such a natural
>> fit-
>> > It’s simple, straightforward, and pragmatic. I value those aspects of
>> Go’s
>> > philosophy and consider them to be features of the language, so it’s
>> > encouraging to see a solution that suits them so well. The author also
>> does
>> > a great job of contextualizing the use cases and debate around
>> generics,
>> > which I found incredibly helpful.
>> >
>> > Any thoughts?
>>
>> It's a very nice writeup.
>>
>> It's worth asking how the graph example in the design draft would be
>> implemented in an interface-based implementation.  Also the syntactic
>> issues are real.
>>
>> Ian
>>
> --
> 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] Link: Getting specific about generics

[xingtao zhao]

On Tuesday, September 4, 2018 at 9:52:07 AM UTC-7, xingtao zhao wrote:
>
> My five cents:
>
> 1) the methods of the type template are defined by interface style
> 2) operators are retrieved implicitly from function body
> 3) function-calls inside are also retrieved implicitly from the function 
> body
>

There is no need for 3). We only need to check if the parameter types 
satisfy the constraint for the functions that are called inside.
 

>
> For graph example, we may declare it as:
>
> type Edgeser(type E) interface {
> Edges() []T
> }
> type Nodeser(type N} interface {
> Nodes() from, to N
> }
> type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }
>
>
> On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts 
>>  wrote: 
>> > 
>> > Link: [Getting specific about generics, by Emily 
>> > Maier](https://emilymaier.net/words/getting-specific-about-generics/) 
>> > 
>> > The interface-based alternative to contracts seems like such a natural 
>> fit- 
>> > It’s simple, straightforward, and pragmatic. I value those aspects of 
>> Go’s 
>> > philosophy and consider them to be features of the language, so it’s 
>> > encouraging to see a solution that suits them so well. The author also 
>> does 
>> > a great job of contextualizing the use cases and debate around 
>> generics, 
>> > which I found incredibly helpful. 
>> > 
>> > Any thoughts? 
>>
>> It's a very nice writeup. 
>>
>> It's worth asking how the graph example in the design draft would be 
>> implemented in an interface-based implementation.  Also the syntactic 
>> issues are real. 
>>
>> Ian 
>>
>

-- 
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] Generics as builtin typeclasses

[Matt Sherman]

@Matthias I don’t mention it in my post but I think that’d be fine, e.g.:

  type Set(type T comparable) []T
  type OrderedSlice(type T orderable) []T


On Tuesday, September 4, 2018 at 3:52:50 PM UTC-4, Matthias B. wrote:
>
> On Tue, 4 Sep 2018 11:57:02 -0700 (PDT) 
> Matt Sherman > wrote: 
>
> > Here’s a riff on generics focused on builtin typeclasses (instead of 
> > user contracts): https://clipperhouse.com/go-generics-typeclasses/ 
> > 
> > Feedback welcome. 
> > 
>
> The main motivation behind generics has always been type-safe 
> containers of custom types. I'm not seeing this in your proposal. 
>
> MSB 
>
>
>

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

[go-nuts] Re: Generics as builtin typeclasses

[Matt Sherman]

@Jon mostly to keep the syntactic spirit of the current proposal. I don’t 
have strong opinions on that.

On Tuesday, September 4, 2018 at 3:56:26 PM UTC-4, Jon Conradt wrote:
>
> Why:
>
> func Sum(type T numeric)(x []T) T {
>
>
> and not just
>
> func Sum(x []T type numeric) T {
>
>
> or
>
> func Sum(x []T Numeric) T {
>
>
>
> Jon
>
> On Tuesday, September 4, 2018 at 11:57:02 AM UTC-7, Matt Sherman wrote:
>>
>> Here’s a riff on generics focused on builtin typeclasses (instead of user 
>> contracts): https://clipperhouse.com/go-generics-typeclasses/
>>
>> Feedback welcome.
>>
>

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

[go-nuts] Re: Generics as builtin typeclasses

[Jon Conradt]

Why:

func Sum(type T numeric)(x []T) T {


and not just

func Sum(x []T type numeric) T {


or

func Sum(x []T Numeric) T {



Jon

On Tuesday, September 4, 2018 at 11:57:02 AM UTC-7, Matt Sherman wrote:
>
> Here’s a riff on generics focused on builtin typeclasses (instead of user 
> contracts): https://clipperhouse.com/go-generics-typeclasses/
>
> Feedback welcome.
>

-- 
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] Generics as builtin typeclasses

[Matthias B.]

On Tue, 4 Sep 2018 11:57:02 -0700 (PDT)
Matt Sherman  wrote:

> Here’s a riff on generics focused on builtin typeclasses (instead of
> user contracts): https://clipperhouse.com/go-generics-typeclasses/
> 
> Feedback welcome.
> 

The main motivation behind generics has always been type-safe
containers of custom types. I'm not seeing this in your proposal.

MSB


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

[go-nuts] Generics as builtin typeclasses

[Matt Sherman]

Here’s a riff on generics focused on builtin typeclasses (instead of user 
contracts): https://clipperhouse.com/go-generics-typeclasses/

Feedback welcome.

-- 
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] Godoc command in the future http server only?

[Paul Jolly]

Just cross referencing with
https://github.com/golang/go/issues/24661#issuecomment-418211394
On Tue, 4 Sep 2018 at 17:33, Jens-Uwe Mager  wrote:
>
> I am using the godoc command to get the complete documentaion of a package 
> vs. the short form the go doc normally generates. For example the following 
> alias:
>
> alias gdf="go list ./...|fzf --preview 'go doc {}' --bind 
> 'enter:execute(godoc {}|less)'"
>
> works for me as a nice terminal go documentation browser for the current go 
> source tree I issue the command from. But this alias relies on godoc 
> delivering the complete package documentation and go doc to do the usual 
> summary. Any way to keep that feature when godoc is going http only in future 
> releases?
>
> --
> 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] A thought on contracts

[roger peppe]

On 4 September 2018 at 17:53, Tristan Colgate  wrote:
> Without though, people maybe encouraged to create getters and setters,which
> is very un-Go.
>   Contracts can match a method explicitly if needed.

Getters and setters are only un-Go if they're used as a matter of
course for field values, I think.

We already have this issue with interfaces - we don't allow an
interface type to specify a field - interfaces only allow methods.

By allowing a contract to specify fields, we preclude a wrapper type
from adapting some other type to fit the same contract.

FWIW the Counters example in the design doc is trivially implementable
with interfaces, so I haven't yet seen decent motivation for this.

  cheers,
rog.
>
>
> On Tue, 4 Sep 2018, 17:49 roger peppe,  wrote:
>>
>> On 4 September 2018 at 17:30, Tristan Colgate  wrote:
>> > This would disallow contracts on presence and type of fields right?
>> >   The existing design permits them, and disallowing them feels a little
>> > arbitrary.
>>
>> It would, yes. But on balance, I think that the presence of selectors
>> in contracts makes for them harder to understand. For example, the
>> rather arbitrary rules about value methods go away if you don't allow
>> selectors. The ambiguity between a field selector and a method
>> selector goes away too. For example, the Stringer contract in the
>> design doc purports to check that there's a method named String, which
>> it does not - it could be a function-valued field instead.
>>
>> So if you've written something like this:
>>
>> func FastString(type T stringer)(x T) string {
>> switch x.(type) {
>> case myType:
>>  return x.String()
>> default:
>>  // Slow path: fall back to fmt.
>>  return fmt.Sprint(x)
>> }
>> }
>>
>> you might expect that fmt.Sprint will call the String method that's
>> defined on x, but that's not guaranteed.
>>
>> The selector operation does so much work in Go that it's hard to
>> classify it as a single operation, and I think that disallowing it
>> lets values focus more on behaviour and less on appearance, as
>> interfaces do.
>>
>> >
>> > On Tue, 4 Sep 2018, 17:17 roger peppe,  wrote:
>> >>
>> >> On 4 September 2018 at 15:41, thwd  wrote:
>> >> > From the draft proposal I gather two open questions:
>> >> >  - How free or restricted should contract bodies be?
>> >> >  - How many implicit constraints can be inferred from usage?
>> >> >
>> >> > If too much syntax is allowed in contract bodies and no implicit
>> >> > constraints
>> >> > are gathered:
>> >> > people will copy and paste function bodies into contracts to cover
>> >> > all
>> >> > constraints.
>> >> >
>> >> > If only restricted syntax is allowed in contract bodies and a lot of
>> >> > implicit constraints are gathered:
>> >> > people will write empty contracts and hope for the compiler to pick
>> >> > up
>> >> > on
>> >> > all the constraints.
>> >> >
>> >> > These two questions are related.
>> >>
>> >> As I understand it, if a contract doesn't allow it, you won't be able
>> >> to
>> >> do it.
>> >> That is, the contract is scanned for "operations" (however they might
>> >> be
>> >> defined), and then it will be a compiler error if a function uses an
>> >> operation
>> >> not permitted in the contract.
>> >>
>> >> An empty contract body permits no operations other than those available
>> >> on every Go value (copying, taking address of, passing as a parameter,
>> >> etc).
>> >>
>> >> So I'm not entirely sure what you mean by "implicit constraints".
>> >>
>> >> That said, it is my opinion that it is very hard to read an arbitrary
>> >> constraint
>> >> body and infer the set of possible operations that can be performed.
>> >> It's not that much easier to look at it and work out what types might
>> >> satisfy
>> >> the contract either.
>> >>
>> >> My suggestion (that I've written up here:
>> >> https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69) is
>> >> that, at least to start with, we allow only a very restricted set of
>> >> contract bodies.
>> >>
>> >> Specifically, in my suggestion, every statement in a contract body
>> >> must consist of exactly one expression.
>> >> Identifiers in the expression can only reference types or the
>> >> contract's parameters.
>> >> The expression must reference at least one of the contract's type
>> >> parameters.
>> >> The expression must exactly one of:
>> >>  - any unary or binary operator (but not a field or method selector)
>> >>  - a function invocation
>> >>  - a type conversion
>> >>  - an index expression
>> >>
>> >> Intuitively I'd like a single statement in the expression to specify
>> >> exactly a single operation which should be clear from the operands of
>> >> the expression.
>> >>
>> >> Thus if you look down the contract and you don't see the operation
>> >> you're looking for, then you can't do it.
>> >>
>> >>   cheers,
>> >> rog.
>> >>
>> >> --
>> >> You received this message because you 

Re: [go-nuts] Re: What am I missing here? FYI, I'm completely new to golang xD

[Robert Engels]

I have no problem with block scope, but when combined with a syntax that is 
create var if not already created when using multiple vars and some are already 
created.  I am sure it is a cause of many hard to track bugs, especially in 
larger methods. The whole thing is brought about by the error handling in go... 
but that’s another topic. :)

Sent from my iPhone

> On Sep 4, 2018, at 10:45 AM, Michael Jones  wrote:
> 
> Block scope is a superpower since Algol.
> 
>> On Tue, Sep 4, 2018 at 7:29 AM Robert Engels  wrote:
>> The real gotcha is this though,
>> 
>> var x int
>> if blah {
>>x,err := somefunc()
>> }
>> 
>> Probably does not do what you think as the value from somefunc() will not be 
>> available outside of the if statement...
>> 
>> This is a poor design choice by golang IMO but it is what it is...
>> 
>>> On Sep 4, 2018, at 9:22 AM, Nate Finch  wrote:
>>> 
>>> Others covered this, but let me try to explain.  In Go, plain = just 
>>> assigns to an already existing variable
>>> 
>>> var x bool  // declares a variable, it starts with the zero value for the 
>>> type
>>> x = true  // assigns a value to the variable
>>> y := true  // declares the variable and assigns it a value
>>> 
>>> Now, the tricky thing is when you have two values being assigned/declared, 
>>> like foo, err := bar().  In this case, as long as either or both variables 
>>> hasn't been declared, then := will declare one or both, and assign to one 
>>> that's already declared.  This makes it easier to do long lists of calls 
>>> that return an error, without having to use err1, err2, etc.  But it does 
>>> kind of muddy the waters for when to use = and when to use :=.
>>> 
>>> := has to always make at least one new variable.  = always just copies a 
>>> value to an existing variable or struct field.  So, like, you can't ever 
>>> use := to put something in a struct field (s.foo := bar will never work).
>>> 
>>> You'll get the hang of it.  You'll use := most of the time, and only = for 
>>> spots where the stuff on the left hand side is already declared. 
>>> -- 
>>> 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.
> 
> 
> -- 
> 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.

[go-nuts] Re: Go’s runtime vs virtual machine

[jake6502]

There are a lot of differences, and for the answer to be complete, you 
would need to specify which language you wanted to compare it to. But on a 
really simple level, thwd's answer is more or less correct. A VM language 
is usually compiled into an instruction set for that VM. The VM then 
provides a lot of "special sauce." Go is (usually) compiled directly into 
machine code to be executed directly on the target system. 

One consequence of this is that the executable can be run without having 
any other software installed on the machine. It also  means that the code 
for the stuff you inquired about such as the garbage collector, goroutine 
scheduling and stack management, is all present in the single executable 
compiled by go.

As for learning more, it depends somewhat on what your experience level is, 
and why you want to know. If you are relatively new to programming, I would 
recommend just using go for a while, without worrying too much about the 
"magic."  If you have a strong background already, you could start learning 
about the stuff you mentioned. Garbage collection would be an interesting 
place to start. I don't know of any one resource, but there are a number of 
interesting videos (gophercon, ect) by principal architects on the subject. 
Keep in mind that all these things are constantly evolving, so any 
information you get may not apply to the latest version of the language. 

Good luck.



On Tuesday, September 4, 2018 at 10:50:03 AM UTC-4, thwd wrote:
>
> A virtual machine has its own instruction set. Go compiles to machine code 
> for a given target (which could be a virtual machine).
>
> On Tuesday, September 4, 2018 at 12:27:49 PM UTC+2, Pablo Rozas Larraondo 
> wrote:
>>
>> The Go documentation provides some explanation about the difference 
>> between Go’s runtime and a virtual machine here:
>>
>> https://golang.org/doc/faq#runtime
>>
>> Does anyone can recommend a good place to learn more about this? I’d like 
>> to better understand how Go’s garbage collector, goroutine scheduling and 
>> stack management are handled by the runtime and how it is different from a 
>> virtual machine.
>>
>> Thanks,
>> Pablo
>>
>>

-- 
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] A thought on contracts

[Tristan Colgate]

Without though, people maybe encouraged to create getters and setters,which
is very un-Go.
  Contracts can match a method explicitly if needed.


On Tue, 4 Sep 2018, 17:49 roger peppe,  wrote:

> On 4 September 2018 at 17:30, Tristan Colgate  wrote:
> > This would disallow contracts on presence and type of fields right?
> >   The existing design permits them, and disallowing them feels a little
> > arbitrary.
>
> It would, yes. But on balance, I think that the presence of selectors
> in contracts makes for them harder to understand. For example, the
> rather arbitrary rules about value methods go away if you don't allow
> selectors. The ambiguity between a field selector and a method
> selector goes away too. For example, the Stringer contract in the
> design doc purports to check that there's a method named String, which
> it does not - it could be a function-valued field instead.
>
> So if you've written something like this:
>
> func FastString(type T stringer)(x T) string {
> switch x.(type) {
> case myType:
>  return x.String()
> default:
>  // Slow path: fall back to fmt.
>  return fmt.Sprint(x)
> }
> }
>
> you might expect that fmt.Sprint will call the String method that's
> defined on x, but that's not guaranteed.
>
> The selector operation does so much work in Go that it's hard to
> classify it as a single operation, and I think that disallowing it
> lets values focus more on behaviour and less on appearance, as
> interfaces do.
>
> >
> > On Tue, 4 Sep 2018, 17:17 roger peppe,  wrote:
> >>
> >> On 4 September 2018 at 15:41, thwd  wrote:
> >> > From the draft proposal I gather two open questions:
> >> >  - How free or restricted should contract bodies be?
> >> >  - How many implicit constraints can be inferred from usage?
> >> >
> >> > If too much syntax is allowed in contract bodies and no implicit
> >> > constraints
> >> > are gathered:
> >> > people will copy and paste function bodies into contracts to cover all
> >> > constraints.
> >> >
> >> > If only restricted syntax is allowed in contract bodies and a lot of
> >> > implicit constraints are gathered:
> >> > people will write empty contracts and hope for the compiler to pick up
> >> > on
> >> > all the constraints.
> >> >
> >> > These two questions are related.
> >>
> >> As I understand it, if a contract doesn't allow it, you won't be able to
> >> do it.
> >> That is, the contract is scanned for "operations" (however they might be
> >> defined), and then it will be a compiler error if a function uses an
> >> operation
> >> not permitted in the contract.
> >>
> >> An empty contract body permits no operations other than those available
> >> on every Go value (copying, taking address of, passing as a parameter,
> >> etc).
> >>
> >> So I'm not entirely sure what you mean by "implicit constraints".
> >>
> >> That said, it is my opinion that it is very hard to read an arbitrary
> >> constraint
> >> body and infer the set of possible operations that can be performed.
> >> It's not that much easier to look at it and work out what types might
> >> satisfy
> >> the contract either.
> >>
> >> My suggestion (that I've written up here:
> >> https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69) is
> >> that, at least to start with, we allow only a very restricted set of
> >> contract bodies.
> >>
> >> Specifically, in my suggestion, every statement in a contract body
> >> must consist of exactly one expression.
> >> Identifiers in the expression can only reference types or the
> >> contract's parameters.
> >> The expression must reference at least one of the contract's type
> >> parameters.
> >> The expression must exactly one of:
> >>  - any unary or binary operator (but not a field or method selector)
> >>  - a function invocation
> >>  - a type conversion
> >>  - an index expression
> >>
> >> Intuitively I'd like a single statement in the expression to specify
> >> exactly a single operation which should be clear from the operands of
> >> the expression.
> >>
> >> Thus if you look down the contract and you don't see the operation
> >> you're looking for, then you can't do it.
> >>
> >>   cheers,
> >> rog.
> >>
> >> --
> >> 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] Link: Getting specific about generics

[xingtao zhao]

My five cents:

1) the methods of the type template are defined by interface style
2) operators are retrieved implicitly from function body
3) function-calls inside are also retrieved implicitly from the function 
body

For graph example, we may declare it as:

type Edgeser(type E) interface {
Edges() []T
}
type Nodeser(type N} interface {
Nodes() from, to N
}
type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }


On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
>
> On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts 
> > wrote: 
> > 
> > Link: [Getting specific about generics, by Emily 
> > Maier](https://emilymaier.net/words/getting-specific-about-generics/) 
> > 
> > The interface-based alternative to contracts seems like such a natural 
> fit- 
> > It’s simple, straightforward, and pragmatic. I value those aspects of 
> Go’s 
> > philosophy and consider them to be features of the language, so it’s 
> > encouraging to see a solution that suits them so well. The author also 
> does 
> > a great job of contextualizing the use cases and debate around generics, 
> > which I found incredibly helpful. 
> > 
> > Any thoughts? 
>
> It's a very nice writeup. 
>
> It's worth asking how the graph example in the design draft would be 
> implemented in an interface-based implementation.  Also the syntactic 
> issues are real. 
>
> Ian 
>

-- 
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] A thought on contracts

[roger peppe]

On 4 September 2018 at 17:30, Tristan Colgate  wrote:
> This would disallow contracts on presence and type of fields right?
>   The existing design permits them, and disallowing them feels a little
> arbitrary.

It would, yes. But on balance, I think that the presence of selectors
in contracts makes for them harder to understand. For example, the
rather arbitrary rules about value methods go away if you don't allow
selectors. The ambiguity between a field selector and a method
selector goes away too. For example, the Stringer contract in the
design doc purports to check that there's a method named String, which
it does not - it could be a function-valued field instead.

So if you've written something like this:

func FastString(type T stringer)(x T) string {
switch x.(type) {
case myType:
 return x.String()
default:
 // Slow path: fall back to fmt.
 return fmt.Sprint(x)
}
}

you might expect that fmt.Sprint will call the String method that's
defined on x, but that's not guaranteed.

The selector operation does so much work in Go that it's hard to
classify it as a single operation, and I think that disallowing it
lets values focus more on behaviour and less on appearance, as
interfaces do.

>
> On Tue, 4 Sep 2018, 17:17 roger peppe,  wrote:
>>
>> On 4 September 2018 at 15:41, thwd  wrote:
>> > From the draft proposal I gather two open questions:
>> >  - How free or restricted should contract bodies be?
>> >  - How many implicit constraints can be inferred from usage?
>> >
>> > If too much syntax is allowed in contract bodies and no implicit
>> > constraints
>> > are gathered:
>> > people will copy and paste function bodies into contracts to cover all
>> > constraints.
>> >
>> > If only restricted syntax is allowed in contract bodies and a lot of
>> > implicit constraints are gathered:
>> > people will write empty contracts and hope for the compiler to pick up
>> > on
>> > all the constraints.
>> >
>> > These two questions are related.
>>
>> As I understand it, if a contract doesn't allow it, you won't be able to
>> do it.
>> That is, the contract is scanned for "operations" (however they might be
>> defined), and then it will be a compiler error if a function uses an
>> operation
>> not permitted in the contract.
>>
>> An empty contract body permits no operations other than those available
>> on every Go value (copying, taking address of, passing as a parameter,
>> etc).
>>
>> So I'm not entirely sure what you mean by "implicit constraints".
>>
>> That said, it is my opinion that it is very hard to read an arbitrary
>> constraint
>> body and infer the set of possible operations that can be performed.
>> It's not that much easier to look at it and work out what types might
>> satisfy
>> the contract either.
>>
>> My suggestion (that I've written up here:
>> https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69) is
>> that, at least to start with, we allow only a very restricted set of
>> contract bodies.
>>
>> Specifically, in my suggestion, every statement in a contract body
>> must consist of exactly one expression.
>> Identifiers in the expression can only reference types or the
>> contract's parameters.
>> The expression must reference at least one of the contract's type
>> parameters.
>> The expression must exactly one of:
>>  - any unary or binary operator (but not a field or method selector)
>>  - a function invocation
>>  - a type conversion
>>  - an index expression
>>
>> Intuitively I'd like a single statement in the expression to specify
>> exactly a single operation which should be clear from the operands of
>> the expression.
>>
>> Thus if you look down the contract and you don't see the operation
>> you're looking for, then you can't do it.
>>
>>   cheers,
>> rog.
>>
>> --
>> 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.

[go-nuts] Godoc command in the future http server only?

[Jens-Uwe Mager]

I am using the godoc command to get the complete documentaion of a package 
vs. the short form the go doc normally generates. For example the following 
alias:

alias gdf="go list ./...|fzf --preview 'go doc {}' --bind 
'enter:execute(godoc {}|less)'"

works for me as a nice terminal go documentation browser for the current go 
source tree I issue the command from. But this alias relies on godoc 
delivering the complete package documentation and go doc to do the usual 
summary. Any way to keep that feature when godoc is going http only in 
future releases?

-- 
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] A thought on contracts

[Tristan Colgate]

This would disallow contracts on presence and type of fields right?
  The existing design permits them, and disallowing them feels a little
arbitrary.

On Tue, 4 Sep 2018, 17:17 roger peppe,  wrote:

> On 4 September 2018 at 15:41, thwd  wrote:
> > From the draft proposal I gather two open questions:
> >  - How free or restricted should contract bodies be?
> >  - How many implicit constraints can be inferred from usage?
> >
> > If too much syntax is allowed in contract bodies and no implicit
> constraints
> > are gathered:
> > people will copy and paste function bodies into contracts to cover all
> > constraints.
> >
> > If only restricted syntax is allowed in contract bodies and a lot of
> > implicit constraints are gathered:
> > people will write empty contracts and hope for the compiler to pick up on
> > all the constraints.
> >
> > These two questions are related.
>
> As I understand it, if a contract doesn't allow it, you won't be able to
> do it.
> That is, the contract is scanned for "operations" (however they might be
> defined), and then it will be a compiler error if a function uses an
> operation
> not permitted in the contract.
>
> An empty contract body permits no operations other than those available
> on every Go value (copying, taking address of, passing as a parameter,
> etc).
>
> So I'm not entirely sure what you mean by "implicit constraints".
>
> That said, it is my opinion that it is very hard to read an arbitrary
> constraint
> body and infer the set of possible operations that can be performed.
> It's not that much easier to look at it and work out what types might
> satisfy
> the contract either.
>
> My suggestion (that I've written up here:
> https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69) is
> that, at least to start with, we allow only a very restricted set of
> contract bodies.
>
> Specifically, in my suggestion, every statement in a contract body
> must consist of exactly one expression.
> Identifiers in the expression can only reference types or the
> contract's parameters.
> The expression must reference at least one of the contract's type
> parameters.
> The expression must exactly one of:
>  - any unary or binary operator (but not a field or method selector)
>  - a function invocation
>  - a type conversion
>  - an index expression
>
> Intuitively I'd like a single statement in the expression to specify
> exactly a single operation which should be clear from the operands of
> the expression.
>
> Thus if you look down the contract and you don't see the operation
> you're looking for, then you can't do it.
>
>   cheers,
> rog.
>
> --
> 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.

[go-nuts] Re: Taking possible EOF as input

[peterGo]

Hunter,

When you write

input.Scan()

you are discarding important information, the return value.

$ go doc bufio.scan
func (s *Scanner) Scan() bool

With the return value, you have an easy test for io.EOF. For example,

scan := input.Scan()
eof := !scan && input.Err() == nil
.
Peter

On Tuesday, September 4, 2018 at 11:28:12 AM UTC-4, Hunter Breathat wrote:
>
>
> I only had stated that bufio.Scan() doesn't return io.EOF as the doc stats 
> that it Err returns nil. Which is fine but hard to check for. But from what 
> I've seen the functionality that im looking for would need to check for the 
> SIG.KILL/EOF  on input. Now whether or not   i shoudlgo and alter the 
> bufio.Scanner to return io.EOF as an Err is a different thing. But that 
> would be a smidge excessive for just 1 minor functionality. 
> On Tuesday, 4 September 2018 09:53:43 UTC-4, peterGo wrote:
>>
>> Hunter,
>>
>> Your main.go file is 171 lines of dense code. If you reduced your issue 
>> to a small, working piece of code, people would be more likely help you.
>>
>> You say "bufio.Scan() doesn't return io.EOF." Why?
>>
>> $ go doc bufio.scanner
>> type Scanner struct {
>> }
>>
>> Scanning stops unrecoverably at EOF, the first I/O error, or a token 
>> too
>> large to fit in the buffer. 
>>
>> $ go doc bufio.scanner.scan
>> func (s *Scanner) Scan() bool
>>
>> Scan advances the Scanner to the next token, which will then be 
>> available
>> through the Bytes or Text method. It returns false when the scan 
>> stops,
>> either by reaching the end of the input or an error. After Scan 
>> returns
>> false, the Err method will return any error that occurred during 
>> scanning,
>> except that if it was io.EOF, Err will return nil.
>>
>> For example,
>>
>> package main
>>
>> import (
>> "bufio"
>> "fmt"
>> "io"
>> "os"
>> )
>>
>> func main() {
>> var input = bufio.NewScanner(os.Stdin)
>> for input.Scan() {
>> text := input.Text()
>> fmt.Println(len(text), text)
>> }
>> if err := input.Err(); err != nil {
>> fmt.Fprintln(os.Stderr, err)
>> return
>> }
>> // input.Scan() == false && input.Err() == nil
>> fmt.Println(io.EOF)
>> }
>>
>> Output:
>>
>> # On Linux, Ctrl-D for eof
>>
>> $ go run eof.go
>> asd
>> 3 asd
>> EOF
>> $
>>
>> Peter
>>
>> On Monday, September 3, 2018 at 12:49:12 PM UTC-4, Hunter Breathat wrote:
>>>
>>> Hey, so I'm currently trying to create a custom shell.
>>>
>>> I am currently trying to implement the EOF exit (^D). Currently, I am 
>>> able to use exit as input and a variety of other
>>> commands, platform-specific; anything, not windows related (WIP), but I 
>>> am having an issue with the EOF causing
>>> an infinite loop. If you could help that would be splendid.
>>>
>>> bufio.Scan() doesn't return io.EOF (So that's a bust even though that's 
>>> the current implementation) 
>>>
>>> GoShell Repo  
>>>
>>> The section you are looking for is in the file: main.go.
>>>
>>> Thanks in advanced
>>> Hunter
>>>
>>> PS.
>>> If you are able to even possible walk me through it would help a bit.
>>>
>>

-- 
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] A thought on contracts

[roger peppe]

On 4 September 2018 at 15:41, thwd  wrote:
> From the draft proposal I gather two open questions:
>  - How free or restricted should contract bodies be?
>  - How many implicit constraints can be inferred from usage?
>
> If too much syntax is allowed in contract bodies and no implicit constraints
> are gathered:
> people will copy and paste function bodies into contracts to cover all
> constraints.
>
> If only restricted syntax is allowed in contract bodies and a lot of
> implicit constraints are gathered:
> people will write empty contracts and hope for the compiler to pick up on
> all the constraints.
>
> These two questions are related.

As I understand it, if a contract doesn't allow it, you won't be able to do it.
That is, the contract is scanned for "operations" (however they might be
defined), and then it will be a compiler error if a function uses an operation
not permitted in the contract.

An empty contract body permits no operations other than those available
on every Go value (copying, taking address of, passing as a parameter, etc).

So I'm not entirely sure what you mean by "implicit constraints".

That said, it is my opinion that it is very hard to read an arbitrary constraint
body and infer the set of possible operations that can be performed.
It's not that much easier to look at it and work out what types might satisfy
the contract either.

My suggestion (that I've written up here:
https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69) is
that, at least to start with, we allow only a very restricted set of
contract bodies.

Specifically, in my suggestion, every statement in a contract body
must consist of exactly one expression.
Identifiers in the expression can only reference types or the
contract's parameters.
The expression must reference at least one of the contract's type parameters.
The expression must exactly one of:
 - any unary or binary operator (but not a field or method selector)
 - a function invocation
 - a type conversion
 - an index expression

Intuitively I'd like a single statement in the expression to specify
exactly a single operation which should be clear from the operands of
the expression.

Thus if you look down the contract and you don't see the operation
you're looking for, then you can't do it.

  cheers,
rog.

-- 
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] help seek: creating and using go package

[Sam Whited]

On Tue, Sep 4, 2018, at 01:33, Sayan Shankhari wrote:
> Probably I am making some nonsense post here and disturbing you but as a 
> beginner, I want to know how in Go I can implement the following. If I can 
> not, please suggest me suitable solution:

Not at all; welcome! If you're just getting started with Go, I recommend that 
you take the tour (https://tour.golang.org). This probably covers most of what 
you want.


> 1. Create a package "myNum"

This is a good resource for getting started with creating Go packages: 
https://golang.org/doc/code.html

It's a tiny bit out of date, there are some experimental features in Go 1.11 
that make using GOPATH obsolete, but it will still work for now.

> 2. containing data type like:
> type Num struct {
> n, d int // numerator, denominator
> }
> 3. and a function to print like
> func printMyNum(x Num) {
> fmt.Println("the fractional number is: %d/%d", x.n, x.d)
> }

Looks like you've already done this, good job :)



In Go, the case of the first letter of an identifier determines if it's 
exported or not.
In your code "Num" will be exported (it can be used from another package), but 
its fields are not (so you won't be able to set "n" or "d" from another 
package). Similarly, "printMyNum" will not be exported, so you won't be able to 
call it from another package.

Here is a more detailed explanation: 
https://stackoverflow.com/questions/38616687/which-way-to-name-a-function-in-go-camelcase-or-semi-camelcase/38617771#38617771

And here is a nice post about how to name things: 
https://blog.golang.org/package-names


I hope that's helpful. Welcome to Go!

—Sam

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

[go-nuts] Re: help seek: creating and using go package

[Yamil Bracho]

And what exactly is the problem ?
Well, If you have to access n and d in the Nunm struct you have to specify 
them in uppercase.

HTH,
Yamil

El martes, 4 de septiembre de 2018, 10:32:40 (UTC-5), Sayan Shankhari 
escribió:
>
> Hello Masters,
> Probably I am making some nonsense post here and disturbing you but as a 
> beginner, I want to know how in Go I can implement the following. If I can 
> not, please suggest me suitable solution:
> 1. Create a package "myNum"
> 2. containing data type like:
> type Num struct {
> n, d int // numerator, denominator
> }
> 3. and a function to print like
> func printMyNum(x Num) {
> fmt.Println("the fractional number is: %d/%d", x.n, x.d)
> }
> 4. access and use it from "main" both the datatype as well as function
> I think for masters, to solve this is a matter of minute. So please help 
> me.
> Thank You.
>

-- 
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: What am I missing here? FYI, I'm completely new to golang xD

[Michael Jones]

Block scope is a superpower since Algol.

On Tue, Sep 4, 2018 at 7:29 AM Robert Engels  wrote:

> The real gotcha is this though,
>
> var x int
> if blah {
>x,err := somefunc()
> }
>
> Probably does not do what you think as the value from somefunc() will not
> be available outside of the if statement...
>
> This is a poor design choice by golang IMO but it is what it is...
>
> On Sep 4, 2018, at 9:22 AM, Nate Finch  wrote:
>
> Others covered this, but let me try to explain.  In Go, plain = just
> assigns to an already existing variable
>
> var x bool  // declares a variable, it starts with the zero value for the
> type
> x = true  // assigns a value to the variable
> y := true  // declares the variable and assigns it a value
>
> Now, the tricky thing is when you have two values being assigned/declared,
> like foo, err := bar().  In this case, as long as either or both variables
> hasn't been declared, then := will declare one or both, and assign to one
> that's already declared.  This makes it easier to do long lists of calls
> that return an error, without having to use err1, err2, etc.  But it does
> kind of muddy the waters for when to use = and when to use :=.
>
> := has to always make at least one new variable.  = always just copies a
> value to an existing variable or struct field.  So, like, you can't ever
> use := to put something in a struct field (s.foo := bar will never work).
>
> You'll get the hang of it.  You'll use := most of the time, and only = for
> spots where the stuff on the left hand side is already declared.
>
> --
> 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.
>


-- 

*Michael T. jonesmichael.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: Taking possible EOF as input

[Jan Mercl]

On Tue, Sep 4, 2018 at 5:28 PM Hunter Breathat 
wrote:


> I only had stated that bufio.Scan() doesn't return io.EOF as the doc
stats that it Err returns nil. Which is fine but hard to check for. But
from what I've seen the functionality that im looking for would need to
check for the SIG.KILL/EOF on input. Now whether or not i shoudlgo and
alter the bufio.Scanner to return io.EOF as an Err is a different thing.
But that would be a smidge excessive for just 1 minor functionality.

.Scan() returns a bool value. io.EOF is not a bool, neither is's a rune ^D.
Typical usage of scanner is to loop in `for s.Scan() { do something }`.
After the loop one checks s.Err(). If it's nil, then scanner input is
exhausted (the underlying readre returned io.EOF). If s.Err() is not nil,
something else happened.

The reason that no ^D is ever seen to signal io.EOF while reading from
stdin - or any file for that matter - is that it would be an in-band
signal, so no files containing that character could be easily processed.

Example:

 jnml@r550:~/tmp> cat main.go
package main

import (
"bufio"
"fmt"
"os"
)

func main() {
s := bufio.NewScanner(os.Stdin)
for s.Scan() {
fmt.Printf("s.Text() returns %q\n", s.Text())
fmt.Printf("s.Err() returns %v\n", s.Err())
}
fmt.Printf("final s.Text() returns %q\n", s.Text())
fmt.Printf("final s.Err() returns %v\n", s.Err())
}
 jnml@r550:~/tmp> go build && ./tmp
after this line we press  and ^D
s.Text() returns "after this line we press  and ^D"
s.Err() returns 
final s.Text() returns ""
final s.Err() returns 
 jnml@r550:~/tmp>

-- 

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

[go-nuts] help seek: creating and using go package

[Sayan Shankhari]

Hello Masters,
Probably I am making some nonsense post here and disturbing you but as a 
beginner, I want to know how in Go I can implement the following. If I can 
not, please suggest me suitable solution:
1. Create a package "myNum"
2. containing data type like:
type Num struct {
n, d int // numerator, denominator
}
3. and a function to print like
func printMyNum(x Num) {
fmt.Println("the fractional number is: %d/%d", x.n, x.d)
}
4. access and use it from "main" both the datatype as well as function
I think for masters, to solve this is a matter of minute. So please help me.
Thank You.

-- 
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] go module for library developer workflow

[Sam Whited]

On Tue, Sep 4, 2018, at 09:58, Yulrizka wrote:
> What is the recommended workflow to easily develop new functionality for 
> lib 'a'?

Add a replace directive to your go.mod file in 'b' while you are developing:

replace github.com/my/a => /home/me/Projects/wherever/a

Unfortunately, you'll have to be careful not to accidentally commit this line.

—Sam

-- 
Sam Whited
s...@samwhited.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.

[go-nuts] Re: Taking possible EOF as input

[Hunter Breathat]

I only had stated that bufio.Scan() doesn't return io.EOF as the doc stats 
that it Err returns nil. Which is fine but hard to check for. But from what 
I've seen the functionality that im looking for would need to check for the 
SIG.KILL/EOF  on input. Now whether or not   i shoudlgo and alter the 
bufio.Scanner to return io.EOF as an Err is a different thing. But that 
would be a smidge excessive for just 1 minor functionality. 
On Tuesday, 4 September 2018 09:53:43 UTC-4, peterGo wrote:
>
> Hunter,
>
> Your main.go file is 171 lines of dense code. If you reduced your issue to 
> a small, working piece of code, people would be more likely help you.
>
> You say "bufio.Scan() doesn't return io.EOF." Why?
>
> $ go doc bufio.scanner
> type Scanner struct {
> }
>
> Scanning stops unrecoverably at EOF, the first I/O error, or a token 
> too
> large to fit in the buffer. 
>
> $ go doc bufio.scanner.scan
> func (s *Scanner) Scan() bool
>
> Scan advances the Scanner to the next token, which will then be 
> available
> through the Bytes or Text method. It returns false when the scan stops,
> either by reaching the end of the input or an error. After Scan returns
> false, the Err method will return any error that occurred during 
> scanning,
> except that if it was io.EOF, Err will return nil.
>
> For example,
>
> package main
>
> import (
> "bufio"
> "fmt"
> "io"
> "os"
> )
>
> func main() {
> var input = bufio.NewScanner(os.Stdin)
> for input.Scan() {
> text := input.Text()
> fmt.Println(len(text), text)
> }
> if err := input.Err(); err != nil {
> fmt.Fprintln(os.Stderr, err)
> return
> }
> // input.Scan() == false && input.Err() == nil
> fmt.Println(io.EOF)
> }
>
> Output:
>
> # On Linux, Ctrl-D for eof
>
> $ go run eof.go
> asd
> 3 asd
> EOF
> $
>
> Peter
>
> On Monday, September 3, 2018 at 12:49:12 PM UTC-4, Hunter Breathat wrote:
>>
>> Hey, so I'm currently trying to create a custom shell.
>>
>> I am currently trying to implement the EOF exit (^D). Currently, I am 
>> able to use exit as input and a variety of other
>> commands, platform-specific; anything, not windows related (WIP), but I 
>> am having an issue with the EOF causing
>> an infinite loop. If you could help that would be splendid.
>>
>> bufio.Scan() doesn't return io.EOF (So that's a bust even though that's 
>> the current implementation) 
>>
>> GoShell Repo  
>>
>> The section you are looking for is in the file: main.go.
>>
>> Thanks in advanced
>> Hunter
>>
>> PS.
>> If you are able to even possible walk me through it would help a bit.
>>
>

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

[go-nuts] Re: Taking possible EOF as input

[Hunter Breathat]

On Monday, 3 September 2018 12:49:12 UTC-4, Hunter Breathat wrote:
>
> Hey, so I'm currently trying to create a custom shell.
>
> I am currently trying to implement the EOF exit (^D). Currently, I am able 
> to use exit as input and a variety of other
> commands, platform-specific; anything, not windows related (WIP), but I am 
> having an issue with the EOF causing
> an infinite loop. If you could help that would be splendid.
>
> bufio.Scan() doesn't return io.EOF (So that's a bust even though that's 
> the current implementation) 
>
> GoShell Repo  
>
> The section you are looking for is in the file: main.go.
>
> Thanks in advanced
> Hunter
>
> PS. 
>
If you are able to even possible walk me through it would help a bit.
>

EDIT: As peterGo had stated that it is a dense section of code so I'll 
narrow it down.

var input = bufio.NewScanner(os.Stdin) // Takes user input
> ...
>
> input.Scan()   //stores user input
> command = input.Text() // Stores user input
> switch command {
> case " ":
>  break
> case "":
>  if err := input.Err(); err == nil && len(command) == 0 {
>   if err != io.ErrUnexpectedEOF {
> // EOF support
>   extras.LeaveEOF()
> 
>   }
>
>  }
> }
> extras.Leave(command) // Check if command is exit or ^D
>
> // So this is the problem area from what I can tell. 
>

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

[go-nuts] go module for library developer workflow

[Yulrizka]

Hello, 

I'm playing around with go module and stumble upon an interesting use-case.

# use-case number 1
Let say for example: 

* I'm a maintainer of a library `github.com/my/a`. with version v0.1.0 
* I also have an app (with main.go) on 'github.com/my/b' which uses the 'a' 
library.

both have go.mod setup properly.

Now the thing is while adding a new feature in ', locally, I want to add 
new functionality in lib 'a' without publishing or tagging it yet.

In the current setup, I'm working outside of GOPATH. I see that lib 'a' 
ends up in `/Users/my/go/pkg/mod/github.com/my/a`

What is the recommended workflow to easily develop new functionality for 
lib 'a'?


Kind regards, 
Ahmy

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

[go-nuts] Re: Go’s runtime vs virtual machine

[thwd]

A virtual machine has its own instruction set. Go compiles to machine code 
for a given target (which could be a virtual machine).

On Tuesday, September 4, 2018 at 12:27:49 PM UTC+2, Pablo Rozas Larraondo 
wrote:
>
> The Go documentation provides some explanation about the difference 
> between Go’s runtime and a virtual machine here:
>
> https://golang.org/doc/faq#runtime
>
> Does anyone can recommend a good place to learn more about this? I’d like 
> to better understand how Go’s garbage collector, goroutine scheduling and 
> stack management are handled by the runtime and how it is different from a 
> virtual machine.
>
> Thanks,
> Pablo
>
>

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

[go-nuts] A thought on contracts

[thwd]

>From the draft proposal I gather two open questions:
 - How free or restricted should contract bodies be?
 - How many implicit constraints can be inferred from usage?

If too much syntax is allowed in contract bodies and no implicit 
constraints are gathered:
people will copy and paste function bodies into contracts to cover all 
constraints.

If only restricted syntax is allowed in contract bodies and a lot of 
implicit constraints are gathered:
people will write empty contracts and hope for the compiler to pick up on 
all the constraints.

These two questions are related.

-- 
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: What am I missing here? FYI, I'm completely new to golang xD

[Robert Engels]

The real gotcha is this though,

var x int
if blah {
   x,err := somefunc()
}

Probably does not do what you think as the value from somefunc() will not be 
available outside of the if statement...

This is a poor design choice by golang IMO but it is what it is...

> On Sep 4, 2018, at 9:22 AM, Nate Finch  wrote:
> 
> Others covered this, but let me try to explain.  In Go, plain = just assigns 
> to an already existing variable
> 
> var x bool  // declares a variable, it starts with the zero value for the type
> x = true  // assigns a value to the variable
> y := true  // declares the variable and assigns it a value
> 
> Now, the tricky thing is when you have two values being assigned/declared, 
> like foo, err := bar().  In this case, as long as either or both variables 
> hasn't been declared, then := will declare one or both, and assign to one 
> that's already declared.  This makes it easier to do long lists of calls that 
> return an error, without having to use err1, err2, etc.  But it does kind of 
> muddy the waters for when to use = and when to use :=.
> 
> := has to always make at least one new variable.  = always just copies a 
> value to an existing variable or struct field.  So, like, you can't ever use 
> := to put something in a struct field (s.foo := bar will never work).
> 
> You'll get the hang of it.  You'll use := most of the time, and only = for 
> spots where the stuff on the left hand side is already declared. 
> -- 
> 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.

[go-nuts] Re: What am I missing here? FYI, I'm completely new to golang xD

[Nate Finch]

Others covered this, but let me try to explain.  In Go, plain = just 
assigns to an already existing variable

var x bool  // declares a variable, it starts with the zero value for the 
type
x = true  // assigns a value to the variable
y := true  // declares the variable and assigns it a value

Now, the tricky thing is when you have two values being assigned/declared, 
like foo, err := bar().  In this case, as long as either or both variables 
hasn't been declared, then := will declare one or both, and assign to one 
that's already declared.  This makes it easier to do long lists of calls 
that return an error, without having to use err1, err2, etc.  But it does 
kind of muddy the waters for when to use = and when to use :=.

:= has to always make at least one new variable.  = always just copies a 
value to an existing variable or struct field.  So, like, you can't ever 
use := to put something in a struct field (s.foo := bar will never work).

You'll get the hang of it.  You'll use := most of the time, and only = for 
spots where the stuff on the left hand side is already declared. 

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

[go-nuts] Re: Taking possible EOF as input

[peterGo]

Hunter,

Your main.go file is 171 lines of dense code. If you reduced your issue to 
a small, working piece of code, people would be more likely help you.

You say "bufio.Scan() doesn't return io.EOF." Why?

$ go doc bufio.scanner
type Scanner struct {
}

Scanning stops unrecoverably at EOF, the first I/O error, or a token too
large to fit in the buffer. 

$ go doc bufio.scanner.scan
func (s *Scanner) Scan() bool

Scan advances the Scanner to the next token, which will then be 
available
through the Bytes or Text method. It returns false when the scan stops,
either by reaching the end of the input or an error. After Scan returns
false, the Err method will return any error that occurred during 
scanning,
except that if it was io.EOF, Err will return nil.

For example,

package main

import (
"bufio"
"fmt"
"io"
"os"
)

func main() {
var input = bufio.NewScanner(os.Stdin)
for input.Scan() {
text := input.Text()
fmt.Println(len(text), text)
}
if err := input.Err(); err != nil {
fmt.Fprintln(os.Stderr, err)
return
}
// input.Scan() == false && input.Err() == nil
fmt.Println(io.EOF)
}

Output:

# On Linux, Ctrl-D for eof

$ go run eof.go
asd
3 asd
EOF
$

Peter

On Monday, September 3, 2018 at 12:49:12 PM UTC-4, Hunter Breathat wrote:
>
> Hey, so I'm currently trying to create a custom shell.
>
> I am currently trying to implement the EOF exit (^D). Currently, I am able 
> to use exit as input and a variety of other
> commands, platform-specific; anything, not windows related (WIP), but I am 
> having an issue with the EOF causing
> an infinite loop. If you could help that would be splendid.
>
> bufio.Scan() doesn't return io.EOF (So that's a bust even though that's 
> the current implementation) 
>
> GoShell Repo  
>
> The section you are looking for is in the file: main.go.
>
> Thanks in advanced
> Hunter
>
> PS.
> If you are able to even possible walk me through it would help a bit.
>

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

[go-nuts] Re: Strange rebuilds of stdlib packages with Go 1.11

[Volker Dobler]

Has anybody experience the same behaviour?
Am I doing something wrong?
Any ideas?

V.


On Friday, 31 August 2018 09:18:44 UTC+2, Volker Dobler wrote:
>
> Building one of our projects with Go 1.11 works fine but I noticed that
> some packages from the stdlib get rebuilt during the build:
>
> $ go version
> go version go1.11 darwin/amd64
>
> $ pwd
> /tmp/modules/ch.redacted.redacted/internal/db
>
> $ cat ../../go.mod
> module git.intern.redacted.net/redacted/ch.redacted.redacted
>
> require (
> git.intern.redacted.net/shared/net.redacted.go-common v1.0.0
> github.com/DataDog/mmh3 v0.0.0-20160824182314-2cfb68475274 // indirect
> github.com/Shopify/sarama v1.17.0
>  [... truncated ...]
> gopkg.in/fsnotify.v1 v1.4.7 // indirect
> gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7 // indirect
> gopkg.in/yaml.v2 v2.2.1 // indirect
> )
>
> $ go build -v
> Fetching https://gopkg.in/fsnotify.v1?go-get=1
> Fetching 
> https://git.intern.redacted.net/shared/net.redacted.go-common?go-get=1
> go: finding github.com/DataDog/mmh3 v0.0.0-20160824182314-2cfb68475274
> go: finding github.com/hpcloud/tail v1.0.0
> go: finding github.com/golang/protobuf v1.2.0
> go: finding github.com/mtchavez/cuckoo v0.1.0
> Parsing meta tags from 
> https://git.intern.redacted.net/shared/net.redacted.go-common?go-get=1 
> (status code 200)
> get "git.intern.redacted.net/shared/net.redacted.go-common": found meta 
> tag get.metaImport{Prefix:"
> git.intern.redacted.net/shared/net.redacted.go-common", VCS:"git", 
> RepoRoot:"
> https://git.intern.redacted.net/shared/net.redacted.go-common.git"} at 
> https://git.intern.redacted.net/shared/net.redacted.go-common?go-get=1
> go: finding git.intern.redacted.net/shared/net.redacted.go-common v1.0.0
> go: finding github.com/fsnotify/fsnotify v1.4.7
> [ ... truncated ... ]
> go: finding golang.org/x/net v0.0.0-20180826012351-8a410e7b638d
> Parsing meta tags from https://golang.org/x/sys?go-get=1 (status code 200)
> get "golang.org/x/sys": found meta tag get.metaImport{Prefix:"
> golang.org/x/sys", VCS:"git", RepoRoot:"https://go.googlesource.com/sys"} 
> at https://golang.org/x/sys?go-get=1
> go: finding golang.org/x/sys v0.0.0-20171216171702-571f7bbbe08d
> go: downloading github.com/go-sql-driver/mysql v1.4.0
> go: downloading github.com/newrelic/go-agent v2.0.0+incompatible
> [ ... truncated ... ]
> go: downloading github.com/pierrec/lz4 v0.0.0-20171218195038-2fcda4cb7018
> go: downloading github.com/golang/snappy 
> v0.0.0-20180518054509-2e65f85255db
> go: downloading github.com/pierrec/xxHash v0.1.1
> golang_org/x/crypto/cryptobyte/asn1
> golang_org/x/net/dns/dnsmessage
> golang_org/x/crypto/curve25519
> [ ... truncated ... ]
> golang_org/x/text/secure/bidirule
> golang_org/x/text/unicode/norm
> *net*
> golang_org/x/net/idna
> golang_org/x/net/http/httpproxy
> *log/syslog*
> *net/textproto*
> *crypto/x509*
> github.com/inconshreveable/log15
> github.com/rcrowley/go-metrics
> golang_org/x/net/http/httpguts
> *crypto/tls*
> *net/http/httptrace*
> github.com/go-sql-driver/mysql
> github.com/Shopify/sarama
> *net/http*
> github.com/newrelic/go-agent/internal/utilization
> github.com/newrelic/go-agent/internal
> github.com/newrelic/go-agent
> git.intern.redacted.net/shared/net.redacted.go-common/logging
> git.intern.redacted.net/redacted/ch.redacted.redacted/internal/charge
> git.intern.redacted.net/redacted/ch.redacted.redacted/internal/db
>
> Everything looks normal (that's why I truncated above output).
>
> Except a handful of stdlib packages which get rebuilt (highlighted in 
> purple).
> These stdlib packages are not imported directly by the package being built
> (here package db).
>
> Why are these stdlib packages being rebuilt?
>
> V.
>
> P.S. No fancy setting:
> $ go env
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/Users/myself/Library/Caches/go-build"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOOS="darwin"
> GOPATH="/Users/myself/go"
> GOPROXY=""
> GORACE=""
> GOROOT="/usr/local/go"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
> GCCGO="gccgo"
> CC="clang"
> CXX="clang++"
> CGO_ENABLED="1"
> GOMOD="/tmp/modules/ch.redacted.redacted/go.mod"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 
> -fdebug-prefix-map=/var/folders/f6/vr81k40j5y35bpj039w1hwfdrvg106/T/go-build500463001=/tmp/go-build
>  
> -gno-record-gcc-switches -fno-common"
>
>

-- 
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] Reference to type satisfying a specified interface

[Eric Raymond]

On Tuesday, September 4, 2018 at 7:13:50 AM UTC-4, Jan Mercl wrote:
>
> I'm worried the suggested editing pass could make the docs better for 
> newbies and less useful for non-newbies in the same time. Maybe the docs 
> for beginner's should be the edited, but separate _version_ of the current 
> docs.
>

Dangerous.  Remember the Single Point of Truth rule.

No, it could be done right so that the outside-in view adds value without 
cruftifying.   I know this because my brain automatically composes those 
edits as soon as I have the knowledge to do 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] Reference to type satisfying a specified interface

[Eric Raymond]

On Friday, August 31, 2018 at 6:55:28 AM UTC-4, ohir wrote:
>
> On Thu, 30 Aug 2018 18:41:48 -0700 (PDT) 
> Eric Raymond > wrote: 
>
> > Oh, actually, I have one other issue; how to translate virtual methods 
> in a 
> > Python base class into Go's object model. 
>
> Inheritance based domain models do not translate directly to go's 
> composition 
> based ones. Forget "virtual". Forget inheritance. 
>

Most of your advice is helpful.  This is not.  Helpful advice would begin 
with a topic sentence  something like "Here is how to use composition to 
emulate superclass behavior."

Remember, I'm not writing code de novo.  I'm translating a large existing 
codebase. The distance I can wander away from its present 
factoring/organization without triggering a dangerous complexity explosion 
is very limited.

-- 
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] Reference to type satisfying a specified interface

[Jan Mercl]

On Tue, Sep 4, 2018 at 1:05 PM Eric Raymond  wrote:

> For me personally this is a relatively minor problem - not my first rodeo
of this kind nor even my dozenth, I have broad experience and know how to
adapt and persist.
> For most newbies it's going to be a serious blocker. I can recommend a
fix: the team could hire a tech writer with an outside-in view (and no
prior knowledge of Go)
> to do a serious editing pass on the documentation.

I'm worried the suggested editing pass could make the docs better for
newbies and less useful for non-newbies in the same time. Maybe the docs
for beginner's should be the edited, but separate _version_ of the current
docs.

-- 

-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] Reference to type satisfying a specified interface

[Eric Raymond]

On Friday, August 31, 2018 at 12:06:44 AM UTC-4, Nigel Tao wrote:
I'm only guessing, but I think Ian's "which docs did you look at" was 
referring to your previous "I was unable to extract this enlightenment 
from the documentation, despite sweating over it pretty hard"

Well, that could be.  I grovelled through a lot of the official Go 
documentation, also third-party stuff I found with search engines.  And 
yes, it did include reading "The Laws of Reflection". Which didn't 
enlighten me, but did adequately prepare me for the short explanation 
upthread that did, so there's that.

It's difficult for me to be specific about how much coverage I achieved, 
because "the documentation", outside of the library pages, is kind of a 
poorly organized blob.   Many individual parts are excellent, but it is 
difficult to know where to find things until one is already familiar enough 
with the territory that finding things has fallen down one's list of 
concerns.

There's also a pervasive problem with the style.  The Go documentation is 
insular and hieratic.  It tends to explain things very well if you already 
inhabit the mindset of a Go programmer, but to not be very good at 
providing an entry into that mindset to people who do not already inhabit 
it. I've seen this movie before, it's a common problem in complex software 
with documentation written by its developers from the inside out.

For me personally this is a relatively minor problem - not my first rodeo 
of this kind nor even my dozenth, I have broad experience and know how to 
adapt and persist. For most newbies it's going to be a serious blocker. I 
can recommend a fix: the team could hire a tech writer with an outside-in 
view (and no prior knowledge of Go) to do a serious editing pass on the 
documentation.

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

[go-nuts] Go’s runtime vs virtual machine

[Pablo]

The Go documentation provides some explanation about the difference between 
Go’s runtime and a virtual machine here:

https://golang.org/doc/faq#runtime

Does anyone can recommend a good place to learn more about this? I’d like to 
better understand how Go’s garbage collector, goroutine scheduling and stack 
management are handled by the runtime and how it is different from a virtual 
machine.

Thanks,
Pablo

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

[go-nuts] Re: Determining memory use of structs containing slices

[Volker Dobler]

On Tuesday, 4 September 2018 10:29:45 UTC+2, Ingo Jaeckel wrote:
>
> What are other idiomatic ways to determine the runtime memory use of a 
> struct which contains (among other things) slices?
>

That depends a lot on your definition of "runtime memory use":
Consider:

a := [100]int16
b := bar{C: a[:]}

Variable a clearly "uses" 200 bytes (maybe plus some for alignment). 
But b.C uses a's memory as the backing array. Attributing a slice's
memory to the slice might result in double counting these 200 bytes.
(Same for structs which contain pointers: Two variables may point to
the same object. Where do you count the memory used?).

Maybe it is best to think of bar's memory usage as 4*8 bytes and not
to attribute C's backing array memory to bar.

V.

-- 
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] Determining memory use of structs containing slices

[Jan Mercl]

On Tue, Sep 4, 2018 at 10:29 AM Ingo Jaeckel  wrote:

> It seems the length of a slice is not considered by unsafe.SizeOf
.

Rightfully so. The size of a slice is a compile-time constant.

> I assume this is a side effect of .SizeOf being evaluated at compile time?

Yes, but let's make clear that unsafe.SizeOf(slice) and len(slice) are
independent, unrelated values.

> What are other idiomatic ways to determine the runtime memory use of a
struct which contains (among other things) slices?

Use unsafe.SizeOf as you do, it works correctly. The items of a slice are
not part of the slice variable/field but are allocated independently
elsewhere. The items are found at [0] when len(slice)

-- 

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

[go-nuts] Determining memory use of structs containing slices

[Ingo Jaeckel]

https://play.golang.org/p/7ZAN9AuEGfD

It seems the length of a slice is not considered by unsafe.SizeOf 
. I assume this is a side effect of 
.SizeOf being evaluated at compile time?

What are other idiomatic ways to determine the runtime memory use of a 
struct which contains (among other things) slices? For instance, I would 
expect an output of 8+8+100*2=216 bytes for bar{A: 100, B: 200, C: 
make([]int16, 100)} if bar is defined as:

type bar struct {
A int64
B int64
C []int16
}

Thanks,
Ingo

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