[go-nuts] Re: Why isn't go more popular?

[tapi...@gmail.com]

Personally, Go will become more popular if we could develop gfx/gui apps in 
Go with ease.

On Thursday, August 5, 2021 at 10:20:49 PM UTC-4 santino.f...@gmail.com 
wrote:

> When you see the ranking of the most liked programming languages, go is 
> near c++, a really "hated app". But since is efficient and produces really 
> clean code, why no wants like 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4fff3df0-f7a0-428f-bf9f-2e26cf2512acn%40googlegroups.com.

[go-nuts] gofmt error formatting suggestion

[burak serdar]

Here is an idea to make reading code a bit easier: If gofmt can format this:

f, err:=os.Open(file)
if err!=nil {
   return err
}

as:

f, err:=os.Open(file); if err!=nil { return err }

it would make reading code easier by pushing the error passing code to the
right. This formatting would only be used for passing errors without any
handling.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrX6ZF85JDV7oNZDM-NwaL%3DAAYXg-oXwS_DSTZwaYd%3DZg%40mail.gmail.com.

Re: [go-nuts] The behavior of the function variable which points to the struct method

['Dan Kortschak' via golang-nuts]

On Tue, 2021-08-10 at 15:54 -0700, E Z wrote:
> I quite agree with your above conclusion, and the test results also
> prove it. That seems to be the way it's designed right now, but what
> I find a little hard to understand here is why it's not designed as
> "The pointer to function assignment captures the current variable
> state."

But that is exactly what it does do.

Dan


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5e6717eea1a9f3555e825baaef75b3ff33703676.camel%40kortschak.io.

Re: [go-nuts] The behavior of the function variable which points to the struct method

[E Z]

" The pointer to function assignment captures the current receiver." 
I quite agree with your above conclusion, and the test results also prove 
it. That seems to be the way it's designed right now, but what I find a 
little hard to understand here is why it's not designed as "The pointer to 
function assignment captures the current variable state."

In my opinion, if the function assignment captures the current variable, 
not the receiver, it seems more acceptable. I wrote an example to demo it 
through closure as the following:
/***
type Zoo struct {
Animal string
}

func (z Zoo) Display(){
fmt.Printf("Current animal is:%s\n", z.Animal)
}

func ZooDisplay(cur *Zoo) func() {
return func(){
cur.Display()
}
}
func main(){
gz := &Zoo{
Animal: "Monkey",
}
pf := gz.Display
pf2 := ZooDisplay(gz)

pf()   //display "Current animal is Monkey"
pf2() //display "Current animal is Monkey"
gz.Display()//display "Current animal is Monkey"

gz.Animal="Tiger" 

pf() //display "Current animal is Monkey"
pf2()   //display "Current animal is Tiger"
gz.Display()  //display "Current animal is Tiger"
}
***/

`ZooDisplay` is a closure to capture the current variable state, here it's 
`gz`,   and if we do so, the output of `pf2()` will always same as the 
output of  `gz.Display()`. This should make it easier to understand and 
less error-prone. 
It's a little weird that the second `pf()` and `gz.Display()` get different 
results from the current design. I don't think we want to get different 
results later on just because of a simple assignment(`pf := gz.Display`).

On Tuesday, August 10, 2021 at 3:05:03 PM UTC-7 bse...@computer.org wrote:

> On Tue, Aug 10, 2021 at 3:50 PM E Z  wrote:
>
>> It works when I changed the code as your suggested. That's great, thanks.
>>
>> And I'm still a little confused here, you know when we use the struct 
>> method directly, it is only when the function is called that the type of 
>> receiver determines whether the passed struct is a pointer or a copied 
>> value. But when using a function pointer, why does it decide whether to 
>> bind a pointer or a copied value at the time of assignment, but not at the 
>> time of function called? 
>>
>> It seems that these two behaviors are not consistent. Is there any 
>> benefit to doing so? I didn't find much information on this topic on 
>> Google. Is there any extended reading on this topic?
>>
>
> It is consistent. The pointer to function assignment captures the current 
> receiver.
>
> func (z Zoo) Display()
> func (z *Zoo) DisplayPtr()
>
> fptr:=gz.Display  --> Captures gz, since Display gets gz by value, 
> captures gz by value
>
> fptr2:= gz.DisplayPtr -> Captures gz, since DisplayPtr gets gz by 
> reference, captures *gz
>
> That is:
>
> gz:=&Zoo{}
> fptr2:=gz.DisplayPtr
> gz=&Zoo{}
> fptr2() -> This will call the DisplayPtr with the first value of gz, not 
> the second
>
>  
>
>>
>> On Tuesday, August 10, 2021 at 12:07:26 PM UTC-7 bse...@computer.org 
>> wrote:
>>
>>> On Tue, Aug 10, 2021 at 12:01 PM E Z  wrote:
>>>
 I feel confused when I use the function pointer which point to the 
 struct method. Here is the test code:

 /***
 package main

 type Zoo struct {
 Animal string
 }

 func (z Zoo) Display(){
 fmt.Printf("Current animal is:%s\n", z.Animal)
 }

>>>
>>> This method has a value receiver. When pf is assigned to gz.Display, it 
>>> is assigned with its receiver, which is a copy of gz.
>>>
>>> Change the method to func (z *Zoo) Display(), and it will work as you 
>>> expect.
>>>  
>>>

 func main(){
 gz := &Zoo{
 Animal: "Monkey",
 }

 pf := gz.Display
 pf()   //display "Current 
 animal is Monkey"
 gz.Animal="Tiger"
 pf()//display "Current 
 animal is Monkey"
 gz.Display() //display "Current animal is 
 Tiger"
 }
 ***/
 As the code is shown above,  even though I changed the value of the 
 member field of the Zoo instance gz,  the function pointer call that 
 followed still prints the unmodified value.

 Can someone help explain why? In my opinion, The function pointer pf 
 should bind to the instance gz and its method(note that gz here is a 
 pointer variable),  if so anytime I change the value of the variable gz,  
 pf should reflect the changes.  

 Thanks,
 Ethan

 -- 
 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.
 To view this dis

Re: [go-nuts] The behavior of the function variable which points to the struct method

[burak serdar]

On Tue, Aug 10, 2021 at 3:50 PM E Z  wrote:

> It works when I changed the code as your suggested. That's great, thanks.
>
> And I'm still a little confused here, you know when we use the struct
> method directly, it is only when the function is called that the type of
> receiver determines whether the passed struct is a pointer or a copied
> value. But when using a function pointer, why does it decide whether to
> bind a pointer or a copied value at the time of assignment, but not at the
> time of function called?
>
> It seems that these two behaviors are not consistent. Is there any benefit
> to doing so? I didn't find much information on this topic on Google. Is
> there any extended reading on this topic?
>

It is consistent. The pointer to function assignment captures the current
receiver.

func (z Zoo) Display()
func (z *Zoo) DisplayPtr()

fptr:=gz.Display  --> Captures gz, since Display gets gz by value, captures
gz by value

fptr2:= gz.DisplayPtr -> Captures gz, since DisplayPtr gets gz by
reference, captures *gz

That is:

gz:=&Zoo{}
fptr2:=gz.DisplayPtr
gz=&Zoo{}
fptr2() -> This will call the DisplayPtr with the first value of gz, not
the second



>
> On Tuesday, August 10, 2021 at 12:07:26 PM UTC-7 bse...@computer.org
> wrote:
>
>> On Tue, Aug 10, 2021 at 12:01 PM E Z  wrote:
>>
>>> I feel confused when I use the function pointer which point to the
>>> struct method. Here is the test code:
>>>
>>> /***
>>> package main
>>>
>>> type Zoo struct {
>>> Animal string
>>> }
>>>
>>> func (z Zoo) Display(){
>>> fmt.Printf("Current animal is:%s\n", z.Animal)
>>> }
>>>
>>
>> This method has a value receiver. When pf is assigned to gz.Display, it
>> is assigned with its receiver, which is a copy of gz.
>>
>> Change the method to func (z *Zoo) Display(), and it will work as you
>> expect.
>>
>>
>>>
>>> func main(){
>>> gz := &Zoo{
>>> Animal: "Monkey",
>>> }
>>>
>>> pf := gz.Display
>>> pf()   //display "Current animal
>>> is Monkey"
>>> gz.Animal="Tiger"
>>> pf()//display "Current
>>> animal is Monkey"
>>> gz.Display() //display "Current animal is
>>> Tiger"
>>> }
>>> ***/
>>> As the code is shown above,  even though I changed the value of the
>>> member field of the Zoo instance gz,  the function pointer call that
>>> followed still prints the unmodified value.
>>>
>>> Can someone help explain why? In my opinion, The function pointer pf
>>> should bind to the instance gz and its method(note that gz here is a
>>> pointer variable),  if so anytime I change the value of the variable gz,
>>> pf should reflect the changes.
>>>
>>> Thanks,
>>> Ethan
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/60c6523c-dbce-4530-aa51-06f2c1223ca8n%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/651e712a-9f81-4b90-a56c-1fc4b4e8b174n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrifLCDEHyRqNH6vzYVV0hmH9VGfpf55pJQSJy9QdGsPg%40mail.gmail.com.

Re: [go-nuts] Why isn't go more popular?

[Fabio Nascimento]

Totally agree

Em sexta-feira, 6 de agosto de 2021 às 10:54:54 UTC-3, frave...@gmail.com 
escreveu:

> On Aug 5, 2021, at 10:27 PM, Ian Lance Taylor  wrote:
> > 
> > On Thu, Aug 5, 2021 at 7:20 PM Santi Ferra
> >  wrote:
> >> 
> >> When you see the ranking of the most liked programming languages, go is 
> near c++, a really "hated app". But since is efficient and produces really 
> clean code, why no wants like it ?
> > 
> > What rankings are you looking at?
>
> Seconded. I would question those rankings, at least for code that's used 
> for forward-looking purposes; in my experience, Go is rapidly replacing 
> Java and in a number of cases Python for backend applications, and it has a 
> lot of first-party support for things like API clients, telemetry, etc. 
> that comes before those languages in many cases as well.
>
> I feel like most people who dislike Go generally haven't used it. Having 
> used it quite a bit, there are things I don't like a lot about it, but 
> they're things that I feel like I can easily overlook given all the things 
> it improves for me. Those are the things people who haven't really given it 
> much use tend to seize on, in my experience (e.g. "Go doesn't have 
> generics", "Go doesn't really have a good way to make an iterator", etc.).
>
> Rankings aren't generally very useful because they try to turn a massive 
> vector quantity into a scalar for everyone's purposes, when in reality 
> different people put different weights on things. It's much more likely 
> that you're seeing the effects of "which language is most used", and Go is 
> a lot younger than most of the other languages in those rankings.
>
>
> - Dave
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c066657a-fbec-4c11-b9ed-91adf333630cn%40googlegroups.com.

Re: [go-nuts] The behavior of the function variable which points to the struct method

['Dan Kortschak' via golang-nuts]

On Tue, 2021-08-10 at 14:50 -0700, E Z wrote:
> It works when I changed the code as your suggested. That's great,
> thanks.
>
> And I'm still a little confused here, you know when we use the struct
> method directly, it is only when the function is called that the type
> of receiver determines whether the passed struct is a pointer or a
> copied value. But when using a function pointer, why does it decide
> whether to bind a pointer or a copied value at the time of
> assignment, but not at the time of function called?
>
> It seems that these two behaviors are not consistent. Is there any
> benefit to doing so? I didn't find much information on this topic on
> Google. Is there any extended reading on this topic?
>

When you do this, `pf := gz.Display', you are capturing the state of gz
as it is. This fixes the animal.

Dan


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a5b5ba862f417f144182f0462e13c867532d9a32.camel%40kortschak.io.

Re: [go-nuts] The behavior of the function variable which points to the struct method

[E Z]

It works when I changed the code as your suggested. That's great, thanks.

And I'm still a little confused here, you know when we use the struct 
method directly, it is only when the function is called that the type of 
receiver determines whether the passed struct is a pointer or a copied 
value. But when using a function pointer, why does it decide whether to 
bind a pointer or a copied value at the time of assignment, but not at the 
time of function called? 

It seems that these two behaviors are not consistent. Is there any benefit 
to doing so? I didn't find much information on this topic on Google. Is 
there any extended reading on this topic?

On Tuesday, August 10, 2021 at 12:07:26 PM UTC-7 bse...@computer.org wrote:

> On Tue, Aug 10, 2021 at 12:01 PM E Z  wrote:
>
>> I feel confused when I use the function pointer which point to the struct 
>> method. Here is the test code:
>>
>> /***
>> package main
>>
>> type Zoo struct {
>> Animal string
>> }
>>
>> func (z Zoo) Display(){
>> fmt.Printf("Current animal is:%s\n", z.Animal)
>> }
>>
>
> This method has a value receiver. When pf is assigned to gz.Display, it is 
> assigned with its receiver, which is a copy of gz.
>
> Change the method to func (z *Zoo) Display(), and it will work as you 
> expect.
>  
>
>>
>> func main(){
>> gz := &Zoo{
>> Animal: "Monkey",
>> }
>>
>> pf := gz.Display
>> pf()   //display "Current animal 
>> is Monkey"
>> gz.Animal="Tiger"
>> pf()//display "Current animal 
>> is Monkey"
>> gz.Display() //display "Current animal is 
>> Tiger"
>> }
>> ***/
>> As the code is shown above,  even though I changed the value of the 
>> member field of the Zoo instance gz,  the function pointer call that 
>> followed still prints the unmodified value.
>>
>> Can someone help explain why? In my opinion, The function pointer pf 
>> should bind to the instance gz and its method(note that gz here is a 
>> pointer variable),  if so anytime I change the value of the variable gz,  
>> pf should reflect the changes.  
>>
>> Thanks,
>> Ethan
>>
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/60c6523c-dbce-4530-aa51-06f2c1223ca8n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/651e712a-9f81-4b90-a56c-1fc4b4e8b174n%40googlegroups.com.

Re: [go-nuts] The behavior of the function variable which points to the struct method

[burak serdar]

On Tue, Aug 10, 2021 at 12:01 PM E Z  wrote:

> I feel confused when I use the function pointer which point to the struct
> method. Here is the test code:
>
> /***
> package main
>
> type Zoo struct {
> Animal string
> }
>
> func (z Zoo) Display(){
> fmt.Printf("Current animal is:%s\n", z.Animal)
> }
>

This method has a value receiver. When pf is assigned to gz.Display, it is
assigned with its receiver, which is a copy of gz.

Change the method to func (z *Zoo) Display(), and it will work as you
expect.


>
> func main(){
> gz := &Zoo{
> Animal: "Monkey",
> }
>
> pf := gz.Display
> pf()   //display "Current animal
> is Monkey"
> gz.Animal="Tiger"
> pf()//display "Current animal
> is Monkey"
> gz.Display() //display "Current animal is
> Tiger"
> }
> ***/
> As the code is shown above,  even though I changed the value of the member
> field of the Zoo instance gz,  the function pointer call that followed
> still prints the unmodified value.
>
> Can someone help explain why? In my opinion, The function pointer pf
> should bind to the instance gz and its method(note that gz here is a
> pointer variable),  if so anytime I change the value of the variable gz,
> pf should reflect the changes.
>
> Thanks,
> Ethan
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/60c6523c-dbce-4530-aa51-06f2c1223ca8n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoFhtb0Zs%3DOVBX-7X1CzXp4yf%2BpeCeR9N_efPQGo67u%3Dg%40mail.gmail.com.

[go-nuts] The behavior of the function variable which points to the struct method

[E Z]

I feel confused when I use the function pointer which point to the struct 
method. Here is the test code:

/***
package main

type Zoo struct {
Animal string
}

func (z Zoo) Display(){
fmt.Printf("Current animal is:%s\n", z.Animal)
}

func main(){
gz := &Zoo{
Animal: "Monkey",
}

pf := gz.Display
pf()   //display "Current animal is 
Monkey"
gz.Animal="Tiger"
pf()//display "Current animal 
is Monkey"
gz.Display() //display "Current animal is Tiger"
}
***/
As the code is shown above,  even though I changed the value of the member 
field of the Zoo instance gz,  the function pointer call that followed 
still prints the unmodified value.

Can someone help explain why? In my opinion, The function pointer pf should 
bind to the instance gz and its method(note that gz here is a pointer 
variable),  if so anytime I change the value of the variable gz,  pf should 
reflect the changes.  

Thanks,
Ethan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/60c6523c-dbce-4530-aa51-06f2c1223ca8n%40googlegroups.com.

Re: [go-nuts] What does io.Closer.Close do?

[Ian Lance Taylor]

On Mon, Aug 9, 2021 at 6:13 PM Ian Gudger  wrote:
>
> io.Closer simply says "Closer is the interface that wraps the basic Close 
> method," but does not document its Close method.
>
> Effective Go says:
> "There are a number of such names and it's productive to honor them and the 
> function names they capture. Read, Write, Close, Flush, String and so on have 
> canonical signatures and meanings. To avoid confusion, don't give your method 
> one of those names unless it has the same signature and meaning." 
> (https://golang.org/doc/effective_go#interface-names)
> ...but does not elaborate on what the canonical meanings are.
>
> So what is the canonical meaning of a Close method?

I would say that the canonical meaning is to indicate that the value
will no longer be used.  After calling Close, further uses of the
value are invalid.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVh08%2BWHTWpqb_kYmjLfNVSba8%2BN7KMWC%3DzZvz1ONShpA%40mail.gmail.com.

[go-nuts] Re: What does io.Closer.Close do?

[jake...@gmail.com]

Just to clarify, the statement " Close will return an error if it has 
already been called"  on  os.File.Close  
is explicitly not the behavior guaranteed by io.Closer 
, which specifically states: " The behavior 
of Close after the first call is undefined. Specific implementations may 
document their own behavior." 

My understanding is that this is the result of a historical oversight, but 
can not be changed now. 

On Tuesday, August 10, 2021 at 2:46:12 AM UTC-4 Brian Candler wrote:

> It's for file-like objects that should be closed when they're no longer 
> being used, in order to reclaim resources promptly.  The details depend on 
> the underlying type, but see for example os.File.Close 
> :
>
> "Close closes the File, rendering it unusable for I/O. On files that 
> support SetDeadline, any pending I/O operations will be canceled and return 
> immediately with an error. Close will return an error if it has already 
> been called."
>
> On Tuesday, 10 August 2021 at 02:13:30 UTC+1 i...@iangudger.com wrote:
>
>> io.Closer simply says "Closer is the interface that wraps the basic Close 
>> method," but does not document its Close method.
>>
>> Effective Go says:
>> "There are a number of such names and it's productive to honor them and 
>> the function names they capture. Read, Write, Close, Flush, String and so 
>> on have canonical signatures and meanings. To avoid confusion, don't give 
>> your method one of those names unless it has the same signature and 
>> meaning." (https://golang.org/doc/effective_go#interface-names)
>> ...but does not elaborate on what the canonical meanings are.
>>
>> So what is the canonical meaning of a Close method?
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/97072cbf-1b98-474b-8484-4e0546f1d8a0n%40googlegroups.com.

[go-nuts] Support for Automating Source Code Documentation

[Felipe Ebert]

Hi, 

I am currently working on designing a bot to support open-source software 
development: the idea is that the bot can analyze code review comments, 
detect those related to explaining the reasons behind the implementation 
choices and suggest these reasons as source code comments. As the first 
step of this design process we would like to ask developers involved in 
code reviews to answer a survey (we expect it to take not more than 25 
minutes): https://forms.office.com/r/9nD4HtNbTK

Thanks in advance,

--
Felipe Ebert
Eindhoven University of Technology, The Netherlands

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/016d500a-6544-49fd-a173-aecbdbd6466an%40googlegroups.com.

Re: [go-nuts] What's going on while using "append" in memory?

[Marvin Renich]

* Henry  [210810 01:26]:
> Just sharing some tips.
> 
> When working with slices, it is often a good idea to lend a helping hand to 
> the compiler. 
> 
> Don't declare something like this, unless you have no other choices.
> ```
> var slice []int
> ```

I believe this is bad advice.

First, if «slice» is to be used to hold a view into a backing array
generated elsewhere, e.g. the result of another function, attempting to
pre-allocate a backing array that will never be used is wasteful.

If you are using «slice» to build a result, and you have a good idea
what the final size of the result will be, preallocating something a bit
larger than the typical result indeed can be a good idea.

If you know for sure exactly what the initial size is going to be, than
preallocating with make() won't hurt, but doesn't do any better than
letting the first append do the allocation.

However, trying to _guess_ the initial size is often a waste of an
allocation.

  var slice []int

allocates the three-word slice header, but does not allocate any backing
array.  The first append will allocate a backing array of the correct
size.

Suppose you have a good idea that the initial size will be 5, so you
write

  var slice = make([]int, 0, 5)

But than it turns out that the initial size is really 6:

  slice = append(slice, data[i:j]...)

where j-i is 6, now the initial allocation of 5 elements was wasted.

If you are appending single elements in a loop, as in your simple
examples, than your advice is somewhat more sound.  In those cases, the
"initial" size is always 1, but the "final" size is its size at the end
of the loop, so making an initial estimate makes a lot more sense.

The take-away is that slice variables are used in many different ways,
and your advice holds in specific use cases, such as building a result
by appending one element at a time.  It does not hold in many real, more
sophisticated, use cases.

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/YRJrRpCVoXiS8c73%40basil.wdw.

Re: [go-nuts] Re: Email threading package?

[Jim Idle]

Hi,

I was going to need to write this anyway, so I took today to write it and
the company decided we can open source it. I have literally just pushed it
to github, so please report any problems if you try it out. I have not
proofread and checked the documentation yet, so I have made it 0.9.0 for
the next day or so, after which it will be released. I hope this helps:

https://github.com/gatherstars-com/jwz

I have tested it on hundreds of thousands of emails using the enmime email
parsing package to generate the envelopes - this is a very good package by
the way if you need a parser.

Cheers,

Jim


On Sat, Aug 7, 2021 at 1:40 PM 'Sebastien Binet' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> There's that:
>
> https://git.sr.ht/~emersion/go-emailthreads
>
> (Quickly scanning the sources, it seems it "just" performs a topological
> sort, though)
>
> hth,
> -s
>
> Aug 7, 2021 00:41:41 Tuhin Nair :
>
> Hey, this is a long shot but any chance you found a Go implementation for
> the JWZ algorithm?
>
> On Monday, July 20, 2015 at 6:14:32 AM UTC+5:30 a...@develooper.com
> wrote:
>
>> Hi,
>>
>> Has anyone made an (open source) package to thread emails -- ideally a
>> variation of http://www.jwz.org/doc/threading.html ? (I wanted to
>> upgrade an old NNTP -> web gateway to Go to make it easier to maintain and
>> it seems like nobody has done this part yet as open source -- or really
>> much email parsing stuff).
>>
>> Searching the internet for "golang email thread" (and variations) brings
>> a lot of results referencing other email threads. :-)
>>
>>
>> Ask
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/89dddc34-3bdf-4cc7-8503-3d43a36ab771n%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ddc0e3bd-696f-48a6-9911-b7873a6b3b48%40sbinet.org
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGPPfg_fOLm8AFfgeuTwGRw%2Bv5BFY6Vwyk2d2R4E5gmcJi2z0A%40mail.gmail.com.