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

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

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

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

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

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,

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

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

Re: [go-nuts] Re: Generics as builtin typeclasses

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

Re: [go-nuts] Re: Generics as builtin typeclasses

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

Re: [go-nuts] Link: Getting specific about generics

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

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

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

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

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

Re: [go-nuts] Link: Getting specific about generics

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{

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

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

[go-nuts] Re: Generics as builtin typeclasses

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

Re: [go-nuts] Link: Getting specific about generics

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

Re: [go-nuts] Link: Getting specific about generics

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

Re: [go-nuts] Generics as builtin typeclasses

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

[go-nuts] Re: Generics as builtin typeclasses

@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

[go-nuts] Re: Generics as builtin typeclasses

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

Re: [go-nuts] Generics as builtin typeclasses

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

[go-nuts] Generics as builtin typeclasses

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

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

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

Re: [go-nuts] A thought on contracts

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

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

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

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

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

Re: [go-nuts] A thought on contracts

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

Re: [go-nuts] Link: Getting specific about generics

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 {

Re: [go-nuts] A thought on contracts

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

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

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

Re: [go-nuts] A thought on contracts

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

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

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,

Re: [go-nuts] A thought on contracts

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 >

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

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

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

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

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

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

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

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

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

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

Re: [go-nuts] go module for library developer workflow

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

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

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

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

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

[go-nuts] go module for library developer workflow

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

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

>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

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

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,

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

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

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

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,

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

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

Re: [go-nuts] Reference to type satisfying a specified interface

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

Re: [go-nuts] Reference to type satisfying a specified interface

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

Re: [go-nuts] Reference to type satisfying a specified interface

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

Re: [go-nuts] Reference to type satisfying a specified interface

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

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

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

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

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

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

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

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

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