[go-nuts] Re: Unicode variable name error

[Jason Phillips]

Per the Go spec[1], an identifier consists of a Unicode letter followed by 
zero or more Unicode letters or digits. The character పే is in the Unicode 
category nonspacing mark rather than the category letter.

If you choose a Telugu letter then your code compiles as expected[2].

[1] - https://go.dev/ref/spec#Identifiers
[2] - https://play.golang.com/p/E7Qbl7uueyO

On Sunday, November 6, 2022 at 1:02:20 AM UTC-4 nikhil...@gmail.com wrote:

> Hi, 
>
> https://play.golang.com/p/uXOgD0PNc-p
>
> I was trying to declare unicode variable name as Go supports it. 
> The language I used is Telugu. It's corresponding chart (
> https://unicode.org/charts/PDF/U0C00.pdf)
>
> But I get the compilation issue. Am I missing anything ? 
> If I write Japanese variable name it works. What is the difference? 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/25aeab4e-159a-44b8-bf4a-6a0d070e3166n%40googlegroups.com.

[go-nuts] Unicode variable name error

[Nikhilesh Susarla]

Hi, 

https://play.golang.com/p/uXOgD0PNc-p

I was trying to declare unicode variable name as Go supports it. 
The language I used is Telugu. It's corresponding chart 
(https://unicode.org/charts/PDF/U0C00.pdf)

But I get the compilation issue. Am I missing anything ? 
If I write Japanese variable name it works. What is the difference? 

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4dafbb30-8884-40ea-be63-2684c5b2facbn%40googlegroups.com.

Re: [go-nuts] Error Interfaces

[Nikhilesh Susarla]

Thank you for the clarification.

On Sat, Nov 5, 2022 at 10:37 PM Axel Wagner 
wrote:

> To be clear: The recommendation is *not* to compare strings. The
> recommendation is to compare errors by identity and not consider errors
> created by different packages to be equal.
>
> If you desperately need your error to be considered "the same" as another,
> the most correct way would be to implement `Is(other error) bool`, e.g.
>
> type notQuiteEOF struct {}
> func (notQuiteEOF) Error() string {
> return "not quite EOF, but almost"
> }
> func (notQuiteEOF) Is(other error) bool {
> return other == io.EOF
> }
>
> This allows errors to be considered "the same" under `errors.Is`, while
> not actually being the same and it's probably the recommended mechanism to
> "imitate" an error from a different package.
>
> On Sat, Nov 5, 2022 at 6:00 PM Nikhilesh Susarla 
> wrote:
>
>> The error is coming from other package. So, then have to compare strings.
>> I guess
>>
>> On Sat, 5 Nov 2022 at 22:28, Sean Foley  wrote:
>>
>>> If the error is created by your code, then just reuse the same one.
>>>
>>> See
>>> https://cs.opensource.google/go/go/+/refs/tags/go1.19.3:src/io/io.go;drc=90b40c0496440fbd57538eb4ba303164ed923d93;l=44
>>>
>>> If the error is created by code other than your own, and that code does
>>> not reuse the same error, then compare strings.
>>>
>>>
>>> On Sat, Nov 5, 2022 at 12:39 PM Nikhilesh Susarla <
>>> nikhilesh1...@gmail.com> wrote:
>>>
 Oh I see.
 What is the best way to compare errors?
 Here in the above example I can do e.Error() == ErrNotFound.Error() //
 which returns true
 Is there any other way rather than string comparison ?

 Thank you

 On Sat, Nov 5, 2022 at 10:03 PM Axel Wagner <
 axel.wagner...@googlemail.com> wrote:

> Oh and this behavior is documented, of course:
> https://pkg.go.dev/errors#New
>
> On Sat, Nov 5, 2022 at 5:32 PM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> Every invocation of `errors.New` returns a new unique error value,
>> even if the same error text is used.
>> That is intentional. It would be confusing, if package A chose the
>> same error sentinel text as package B and suddenly their sentinels 
>> compare
>> as equal.
>> If you want error identity between values, you have to actually copy
>> the error value (or implement your own, which may very well not do it 
>> this
>> way).
>>
>> On Sat, Nov 5, 2022 at 5:29 PM Nikhilesh Susarla <
>> nikhilesh1...@gmail.com> wrote:
>>
>>>
>>> Same interface comparison
>>>
>>> https://play.golang.com/p/9hHlTDosYzz
>>>
>>> Why is the equals too still returning false?
>>>
>>> Any more details on this?
>>>
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/ee3d53d3-d3c8-4a3b-801a-af6060316e3an%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/CAMt-viXeFOgh42DtvD4cJiEvhUDR-PaD8GvOEDfuytLdeKE4GQ%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMt-viUCSAtcZSSf7XeQoAf%3D4z%3D0bqd77jTUceSW%3DNoFtZk9zA%40mail.gmail.com.

Re: [go-nuts] Underscore symbol

[David Finkel]

On Sat, Nov 5, 2022 at 4:57 AM Chris Burkert 
wrote:

> I am curious: from a compiler perspective, does that mean that by using _
> simply less assembler instructions are created by not handling those
> registers which relate to _?
>
>
That kind of depends on what you mean by "not handling". Since it's a
compile-time error (in the GC compiler) to have an unused variable, you'd
have to do something else with that value.
Depending on what type that ignored return value is, whether the call is
inlined and whether the call is using the newer, register-based calling
convention the compiler *may* be able to prune instructions related to that
variable.

Here are a few scenarios off the top of my head (in no particular order and
by no means exhaustive, but some of them are interesting -- and some are
completely hypothetical optimizations as I haven't looked at a lot of the
relevant compiler code myself):

   - The call doesn't get inlined, and it's a trivial value that can be
   passed around in a register, so that return register is simply never read
   (and gets clobbered at some later point when it's needed)
   - The call is inlined, and the variable that it's returned from doesn't
   interact with anything in the callee, so the code for generating that
   return variable can be removed during a dead-code removal pass
   - The call is inlined and that return value is a pointer to something on
   the heap, in which case the stack pointer-liveness map for that point in
   the function will mark that pointer as dead (I'm not certain about this
   one) -- this might let the heap object get GC'd from that moment.
   - The call is assembly so it's eligible for neither the newer
   register-calling convention nor inlining, so the spot on the stack for that
   return value just gets ignored until the function returns (or that
   stack-space gets allocated to another variable)
   - cgo can't return multiple values, but if you ignore the return value
   in AMD64 calling conventions it's a register that can be ignored. (although
   it may be a pointer to something elsewhere in memory, in which case gets
   more interesting)
   - The call is inlined and the return value is a pointer which would
   normally be marked as escaping but because the pointer gets ignored, the
   compiler can go back to stack-allocating. (I'm not sure if the compiler has
   a second escape-analysis pass like this, but it could be interesting)


Marcel Huijkman  schrieb am Sa. 5. Nov. 2022
> um 09:18:
>
>> When I explain it during my training I always say it is a trashcan
>> variable, anything you put in is to be ignored on the spot.
>>
>> On Friday, November 4, 2022 at 10:10:20 PM UTC+1 Konstantin Khomoutov
>> wrote:
>>
>>> On Fri, Nov 04, 2022 at 04:58:35AM -0700, Canuto wrote:
>>>
>>> > I'm just starting out with go ...
>>> > I have searched for lights on this string but without success.
>>> > What does this sign mean " _, err " , what the underscore symbol means
>>> here?
>>>
>>> If you're starting with Go, please start with the Go Tour [1].
>>> For instance, the use of this underscore sign is covered in [2].
>>>
>>> 1. https://go.dev/tour/
>>> 2. https://go.dev/tour/moretypes/17
>>>
>>> --
>> 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/6c745c54-b212-4bb6-8e40-00273e6ee2fan%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/CALWqRZo-n%3D_16Ug8Rids3E502dFZcW5PPZueGKfDqA%2Bcg30X6A%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANrC0BjkRus%2B-kV5Wdq7vwiLinqiuRyX7o5LbtXnDh_BHqD%2BxQ%40mail.gmail.com.

Re: [go-nuts] Refactor Asynchronous JS to Go

[Kurtis Rader]

On Sat, Nov 5, 2022 at 1:58 PM Shubh Karman Singh 
wrote:

> I am refactoring a JS library to Go. I have some questions but I'm not
> able to find some concrete answers for this.
> 1. What's the idiomatic way to refactor Asynchronous JS APIs to Go?
> 2. How to refactor Callbacks from JS to Golang? I have seen some Go code
> which takes function as an input parameter. Is the intent same here?
>

I've been programming for more than four decades. In that time I've
personally rewritten three apps in a different language. I've also read
several post translation reports for other projects. The most
important lesson is that it is usually a mistake to perform a literal
translation. In fact, of the rewrites I've participated in or read about a
literal translation was appropriate in only one case. That was the first
one I ever did: translating Donald Knuth's TeX typesetting program from
Pascal to C.

I haven't written any Javascript in over a decade. But translating its
async API pattern to idiomatic Go is likely to involve starting a goroutine
for each async op and having the goroutine communicate a result via a
channel. For your second question, yes, functions are first-class objects
in Go and can be passed to other functions to perform a specialized
operation or act as a callback.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD_vVxKcvaeg-S2RJwNXs64s_O-tHhJsGBDaX9yB8V8Xyg%40mail.gmail.com.

[go-nuts] Re: Refactor Asynchronous JS to Go

[Rusco]

Some time ago I compared Functional Reactive Programming FRP with Golang 
Channels (CSP), might be useful to you as a starter:

https://rusco.github.io/



On Saturday, 5 November 2022 at 20:58:54 UTC sksin...@gmail.com wrote:

> Hi, 
> I am refactoring a JS library to Go. I have some questions but I'm not 
> able to find some concrete answers for this. 
> 1. What's the idiomatic way to refactor Asynchronous JS APIs to Go? 
> 2. How to refactor Callbacks from JS to Golang? I have seen some Go code 
> which takes function as an input parameter. Is the intent same here? 
>
>
>
>

-- 
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/30db79ea-2592-48ed-8529-4ba4a21b2f80n%40googlegroups.com.

[go-nuts] Refactor Asynchronous JS to Go

[Shubh Karman Singh]

Hi,
I am refactoring a JS library to Go. I have some questions but I'm not able
to find some concrete answers for this.
1. What's the idiomatic way to refactor Asynchronous JS APIs to Go?
2. How to refactor Callbacks from JS to Golang? I have seen some Go code
which takes function as an input parameter. Is the intent same here?

-- 
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/CACvy5SdjEoLwYuTHDNSr80QbhwJY1tJVx9wANM06EvLFLiAAuA%40mail.gmail.com.

Re: [go-nuts] Error Interfaces

['Axel Wagner' via golang-nuts]

To be clear: The recommendation is *not* to compare strings. The
recommendation is to compare errors by identity and not consider errors
created by different packages to be equal.

If you desperately need your error to be considered "the same" as another,
the most correct way would be to implement `Is(other error) bool`, e.g.

type notQuiteEOF struct {}
func (notQuiteEOF) Error() string {
return "not quite EOF, but almost"
}
func (notQuiteEOF) Is(other error) bool {
return other == io.EOF
}

This allows errors to be considered "the same" under `errors.Is`, while not
actually being the same and it's probably the recommended mechanism to
"imitate" an error from a different package.

On Sat, Nov 5, 2022 at 6:00 PM Nikhilesh Susarla 
wrote:

> The error is coming from other package. So, then have to compare strings.
> I guess
>
> On Sat, 5 Nov 2022 at 22:28, Sean Foley  wrote:
>
>> If the error is created by your code, then just reuse the same one.
>>
>> See
>> https://cs.opensource.google/go/go/+/refs/tags/go1.19.3:src/io/io.go;drc=90b40c0496440fbd57538eb4ba303164ed923d93;l=44
>>
>> If the error is created by code other than your own, and that code does
>> not reuse the same error, then compare strings.
>>
>>
>> On Sat, Nov 5, 2022 at 12:39 PM Nikhilesh Susarla <
>> nikhilesh1...@gmail.com> wrote:
>>
>>> Oh I see.
>>> What is the best way to compare errors?
>>> Here in the above example I can do e.Error() == ErrNotFound.Error() //
>>> which returns true
>>> Is there any other way rather than string comparison ?
>>>
>>> Thank you
>>>
>>> On Sat, Nov 5, 2022 at 10:03 PM Axel Wagner <
>>> axel.wagner...@googlemail.com> wrote:
>>>
 Oh and this behavior is documented, of course:
 https://pkg.go.dev/errors#New

 On Sat, Nov 5, 2022 at 5:32 PM Axel Wagner <
 axel.wagner...@googlemail.com> wrote:

> Every invocation of `errors.New` returns a new unique error value,
> even if the same error text is used.
> That is intentional. It would be confusing, if package A chose the
> same error sentinel text as package B and suddenly their sentinels compare
> as equal.
> If you want error identity between values, you have to actually copy
> the error value (or implement your own, which may very well not do it this
> way).
>
> On Sat, Nov 5, 2022 at 5:29 PM Nikhilesh Susarla <
> nikhilesh1...@gmail.com> wrote:
>
>>
>> Same interface comparison
>>
>> https://play.golang.com/p/9hHlTDosYzz
>>
>> Why is the equals too still returning false?
>>
>> Any more details on this?
>>
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/ee3d53d3-d3c8-4a3b-801a-af6060316e3an%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/CAMt-viXeFOgh42DtvD4cJiEvhUDR-PaD8GvOEDfuytLdeKE4GQ%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGwe72T-RO8-dam2aizuGL5S4va%3Dzob8inFTegijUvjFA%40mail.gmail.com.

Re: [go-nuts] Error Interfaces

[Nikhilesh Susarla]

The error is coming from other package. So, then have to compare strings. I
guess

On Sat, 5 Nov 2022 at 22:28, Sean Foley  wrote:

> If the error is created by your code, then just reuse the same one.
>
> See
> https://cs.opensource.google/go/go/+/refs/tags/go1.19.3:src/io/io.go;drc=90b40c0496440fbd57538eb4ba303164ed923d93;l=44
>
> If the error is created by code other than your own, and that code does
> not reuse the same error, then compare strings.
>
>
> On Sat, Nov 5, 2022 at 12:39 PM Nikhilesh Susarla 
> wrote:
>
>> Oh I see.
>> What is the best way to compare errors?
>> Here in the above example I can do e.Error() == ErrNotFound.Error() //
>> which returns true
>> Is there any other way rather than string comparison ?
>>
>> Thank you
>>
>> On Sat, Nov 5, 2022 at 10:03 PM Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> Oh and this behavior is documented, of course:
>>> https://pkg.go.dev/errors#New
>>>
>>> On Sat, Nov 5, 2022 at 5:32 PM Axel Wagner <
>>> axel.wagner...@googlemail.com> wrote:
>>>
 Every invocation of `errors.New` returns a new unique error value, even
 if the same error text is used.
 That is intentional. It would be confusing, if package A chose the same
 error sentinel text as package B and suddenly their sentinels compare as
 equal.
 If you want error identity between values, you have to actually copy
 the error value (or implement your own, which may very well not do it this
 way).

 On Sat, Nov 5, 2022 at 5:29 PM Nikhilesh Susarla <
 nikhilesh1...@gmail.com> wrote:

>
> Same interface comparison
>
> https://play.golang.com/p/9hHlTDosYzz
>
> Why is the equals too still returning false?
>
> Any more details on this?
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ee3d53d3-d3c8-4a3b-801a-af6060316e3an%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/CAMt-viXeFOgh42DtvD4cJiEvhUDR-PaD8GvOEDfuytLdeKE4GQ%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMt-viXynaUDEyzi_xuT_ASHZ_ay-14gANVYWx4f%3DKgLovVrCA%40mail.gmail.com.

Re: [go-nuts] Error Interfaces

[Sean Foley]

If the error is created by your code, then just reuse the same one.

See
https://cs.opensource.google/go/go/+/refs/tags/go1.19.3:src/io/io.go;drc=90b40c0496440fbd57538eb4ba303164ed923d93;l=44

If the error is created by code other than your own, and that code does not
reuse the same error, then compare strings.


On Sat, Nov 5, 2022 at 12:39 PM Nikhilesh Susarla 
wrote:

> Oh I see.
> What is the best way to compare errors?
> Here in the above example I can do e.Error() == ErrNotFound.Error() //
> which returns true
> Is there any other way rather than string comparison ?
>
> Thank you
>
> On Sat, Nov 5, 2022 at 10:03 PM Axel Wagner 
> wrote:
>
>> Oh and this behavior is documented, of course:
>> https://pkg.go.dev/errors#New
>>
>> On Sat, Nov 5, 2022 at 5:32 PM Axel Wagner 
>> wrote:
>>
>>> Every invocation of `errors.New` returns a new unique error value, even
>>> if the same error text is used.
>>> That is intentional. It would be confusing, if package A chose the same
>>> error sentinel text as package B and suddenly their sentinels compare as
>>> equal.
>>> If you want error identity between values, you have to actually copy the
>>> error value (or implement your own, which may very well not do it this way).
>>>
>>> On Sat, Nov 5, 2022 at 5:29 PM Nikhilesh Susarla <
>>> nikhilesh1...@gmail.com> wrote:
>>>

 Same interface comparison

 https://play.golang.com/p/9hHlTDosYzz

 Why is the equals too still returning false?

 Any more details on this?

 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.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/ee3d53d3-d3c8-4a3b-801a-af6060316e3an%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/CAMt-viXeFOgh42DtvD4cJiEvhUDR-PaD8GvOEDfuytLdeKE4GQ%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKL%3DS7EvH1oZJS7aw%3DtpD-LWCL58uHxGZL-u%2BML7dLkuMMQkRA%40mail.gmail.com.

Re: [go-nuts] Error Interfaces

[Nikhilesh Susarla]

Oh I see.
What is the best way to compare errors?
Here in the above example I can do e.Error() == ErrNotFound.Error() //
which returns true
Is there any other way rather than string comparison ?

Thank you

On Sat, Nov 5, 2022 at 10:03 PM Axel Wagner 
wrote:

> Oh and this behavior is documented, of course:
> https://pkg.go.dev/errors#New
>
> On Sat, Nov 5, 2022 at 5:32 PM Axel Wagner 
> wrote:
>
>> Every invocation of `errors.New` returns a new unique error value, even
>> if the same error text is used.
>> That is intentional. It would be confusing, if package A chose the same
>> error sentinel text as package B and suddenly their sentinels compare as
>> equal.
>> If you want error identity between values, you have to actually copy the
>> error value (or implement your own, which may very well not do it this way).
>>
>> On Sat, Nov 5, 2022 at 5:29 PM Nikhilesh Susarla 
>> wrote:
>>
>>>
>>> Same interface comparison
>>>
>>> https://play.golang.com/p/9hHlTDosYzz
>>>
>>> Why is the equals too still returning false?
>>>
>>> Any more details on this?
>>>
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/ee3d53d3-d3c8-4a3b-801a-af6060316e3an%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/CAMt-viXeFOgh42DtvD4cJiEvhUDR-PaD8GvOEDfuytLdeKE4GQ%40mail.gmail.com.

Re: [go-nuts] Error Interfaces

['Axel Wagner' via golang-nuts]

Oh and this behavior is documented, of course: https://pkg.go.dev/errors#New

On Sat, Nov 5, 2022 at 5:32 PM Axel Wagner 
wrote:

> Every invocation of `errors.New` returns a new unique error value, even if
> the same error text is used.
> That is intentional. It would be confusing, if package A chose the same
> error sentinel text as package B and suddenly their sentinels compare as
> equal.
> If you want error identity between values, you have to actually copy the
> error value (or implement your own, which may very well not do it this way).
>
> On Sat, Nov 5, 2022 at 5:29 PM Nikhilesh Susarla 
> wrote:
>
>>
>> Same interface comparison
>>
>> https://play.golang.com/p/9hHlTDosYzz
>>
>> Why is the equals too still returning false?
>>
>> Any more details on this?
>>
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/ee3d53d3-d3c8-4a3b-801a-af6060316e3an%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/CAEkBMfGxq5NNEsoKqobGNaizf5oTLX%2BfGv4FkuNSSBm_hjFU%3Dw%40mail.gmail.com.

Re: [go-nuts] Error Interfaces

['Axel Wagner' via golang-nuts]

Every invocation of `errors.New` returns a new unique error value, even if
the same error text is used.
That is intentional. It would be confusing, if package A chose the same
error sentinel text as package B and suddenly their sentinels compare as
equal.
If you want error identity between values, you have to actually copy the
error value (or implement your own, which may very well not do it this way).

On Sat, Nov 5, 2022 at 5:29 PM Nikhilesh Susarla 
wrote:

>
> Same interface comparison
>
> https://play.golang.com/p/9hHlTDosYzz
>
> Why is the equals too still returning false?
>
> Any more details on this?
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ee3d53d3-d3c8-4a3b-801a-af6060316e3an%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/CAEkBMfHdC%2BHfQ8Re7LoT2RCrukXV%2Bo6YmiRtHr32ie_B3fS7TA%40mail.gmail.com.

[go-nuts] Error Interfaces

[Nikhilesh Susarla]

Same interface comparison 

https://play.golang.com/p/9hHlTDosYzz

Why is the equals too still returning false? 

Any more details on this? 

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ee3d53d3-d3c8-4a3b-801a-af6060316e3an%40googlegroups.com.

Re: [go-nuts] WebAssembly and Filesystem access

[Konstantin Khomoutov]

On Fri, Nov 04, 2022 at 02:08:08PM -0700, 'Kevin Chowski' via golang-nuts wrote:

[...]
> I am on a project which primarily ships a Go command line interface (CLI), 
> but we have aspirations of using the wasm compilation mode to also 
> distribute a simple webapp version of it, while sharing most of the code.
[...]
> The next big hurdle is the fact that we cache things on disk 
> for later reuse, so things are failing out-of-the-box any time we attempt 
> to touch the filesystem. Luckily, in our case, the fact that we are 
> touching the filesystem is a bit incidental (its used as a cache for making 
> consecutive CLI invocations faster), and as long as the system was 
> consistent for the lifetime of the main Go process things will work just 
> fine.
> 
> We /could/ pass a filesystem object across the codebase, and maybe we will 
> one day we will anyway for some other reasons, but I'd rather not have to 
> do that just to get further with this webapp prototype: it's a lot of 
> tedious plumbing, and there is a nontrivial amount of code to touch.
> 
> So instead I decided to try some global-mutable-at-startup variables for 
> things like os.OpenFile, os.Remove, etc, that should be easy to cleanup if 
> we decide not to move forward with the prototype; but even then, there are 
> plenty of random things I have to do to get this to work. I've spent about 
> 2 hours on this direction so far and I keep hitting unexpected roadblocks - 
> thus this email seeking out a new strategy.
> 
> Are there any plans to automatically support filesystems on wasm-compiled 
> Go applications? Even an ephemeral, in-memory filesystem would basically 
> solve all of my problems without having to change any code on my end, which 
> would be nice.

I'm not a Go developer, but I'd say it is unlikely due to the combination of
these two facts:

 - The os package was implemented as a sort-of grab bag of many features
   one expects on a typical OS (hence the name). The fact the filesystem
   operations were implemented in that package directly and not elsewhere
   is the direct manifestation of that approach.
   An environment in which WASM runs in a browser is too different from that
   provided by a typical OS, so I cannot see how one could sensibly implement
   in GOOS=js.

 - Even if some sort of FS emulation were to be implemented for GOOS=js,
   the question is: which one exactly? Keeping stuff in memory in just one
   way of doing things. While I'm not a web developer, I know of at least
   session storage and local storage which provide for two levels of
   persistence beyond keeping stuff in memory. Which one to pick for
   implementing stuff from the os package?

> In lieu of that, does anyone have any tips about how I could go about doing 
> this in a better way?

If you need a hard-and-fast solution, I'd propose you're trying to abstract
your stuff away on a wrong level. I think it would be cleaner to factor out
your persistence code into a set of functions "store this stuff" and "load
that stuff"; the default implementations would call out to the os package, and
the wasm implementation would use either approach you select: keeping things
in memory, using local storage etc.

I mean, trying to implement and pass around through the whole codebase
something like a "filesystem accessor" switchable at runtime is only worth it
if your code makes heavy use of the filesystem in nontrivial way. I'd say that
it's better to abstract away high-level store/load operations.

-- 
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/20221105115837.zbnyd6kc6xvuistb%40carbon.

Re: [go-nuts] Underscore symbol

[Chris Burkert]

I am curious: from a compiler perspective, does that mean that by using _
simply less assembler instructions are created by not handling those
registers which relate to _?

Marcel Huijkman  schrieb am Sa. 5. Nov. 2022
um 09:18:

> When I explain it during my training I always say it is a trashcan
> variable, anything you put in is to be ignored on the spot.
>
> On Friday, November 4, 2022 at 10:10:20 PM UTC+1 Konstantin Khomoutov
> wrote:
>
>> On Fri, Nov 04, 2022 at 04:58:35AM -0700, Canuto wrote:
>>
>> > I'm just starting out with go ...
>> > I have searched for lights on this string but without success.
>> > What does this sign mean " _, err " , what the underscore symbol means
>> here?
>>
>> If you're starting with Go, please start with the Go Tour [1].
>> For instance, the use of this underscore sign is covered in [2].
>>
>> 1. https://go.dev/tour/
>> 2. https://go.dev/tour/moretypes/17
>>
>> --
> 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/6c745c54-b212-4bb6-8e40-00273e6ee2fan%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/CALWqRZo-n%3D_16Ug8Rids3E502dFZcW5PPZueGKfDqA%2Bcg30X6A%40mail.gmail.com.

Re: [go-nuts] Underscore symbol

[Marcel Huijkman]

When I explain it during my training I always say it is a trashcan 
variable, anything you put in is to be ignored on the spot.

On Friday, November 4, 2022 at 10:10:20 PM UTC+1 Konstantin Khomoutov wrote:

> On Fri, Nov 04, 2022 at 04:58:35AM -0700, Canuto wrote:
>
> > I'm just starting out with go ...
> > I have searched for lights on this string but without success.
> > What does this sign mean " _, err " , what the underscore symbol means 
> here? 
>
> If you're starting with Go, please start with the Go Tour [1].
> For instance, the use of this underscore sign is covered in [2].
>
> 1. https://go.dev/tour/
> 2. https://go.dev/tour/moretypes/17
>
>

-- 
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/6c745c54-b212-4bb6-8e40-00273e6ee2fan%40googlegroups.com.

Re: [go-nuts] go[runtime.rt0_go]: why should 104 be subtracted from g0 stack 64k?

[liiu liiu]

Thanks for the info. I submit a pull request to remove it.

Ian Lance Taylor  于2022年11月5日周六 06:01写道：

> On Thu, Nov 3, 2022 at 7:46 AM liiux...@gmail.com 
> wrote:
> >
> > asm_amd64.s
> >
> > Please explain why 104 should be subtracted from g0 stack?
>
> Interesting question.  The number 104 appears to date back to the
> first implementation of split stacks in
> https://go.googlesource.com/go/+/b987f7a757f53f460973622a36eebb696f9b5060.
> That change introduces a 104 byte stack guard, and I believe that that
> stack guard has been carried forward over the years.  I don't really
> know whether it still makes any sense today.  Probably it doesn't.
>
> 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/CAJhgtRNfi0v645AHcSxJ5A4sH3pr1UpPz9y%3D%3D%2BpZZw4OGs_%2BAA%40mail.gmail.com.