Re: [go-nuts] Re: Error handling

[DrGo]

@Miguel Angel Rivera Notararigo

Thanks for taking the time to write... 

In my proposal, people are free to add as much context as they want... but 
as a demonstration, I am using the example from 
Ross Cox's paper on error handling that is used by all error handling 
proposals to show case their approach. I do not think Ross will 
take your criticism personally :) I on the other hand take exception to 
your generalization re people who complain about error handling in Go.
I am sure you did not make that claim without having some sort of solid 
research to support it. But, Go designers themselves admit that this is an 
issue and have written
tons on it.

In one or two replies above we were discussing how error handling opinions 
can become religions each with its own priests who think they are the only 
saved faction, and that their rituals are the only right approach for all 
situations.

Best wishes,


On Thursday, August 3, 2023 at 9:07:52 PM UTC-6 Miguel Angel Rivera 
Notararigo wrote:

func CopyFile(src, dst string) error {
r, err := os.Open(src)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
defer r.Close()

w, err := os.Create(dst)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

if _, err := io.Copy(w, r); err != nil {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

if err := w.Close(); err != nil {
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
}

I think it is a bad example, how do you know where CopyFile failed?

The "copy ..." part shouldn't be in there, you should add valuable context 
to your errors, if CopyFile fails, the caller already knows it was a copy 
error because the function has a big "Copy" on his name right? you should 
do this instead:

func CopyFile(dst, src string) error {
  r, errOS := os.Open(src) // Avoid shadowing errors, don't use err
  if errOS != nil {
return fmt.Errorf("cannot open source: %v", errOS)
  }

  defer r.Close()

  w, errCD := os.Create(dst)
  if errCD != nil {
return fmt.Errorf("cannot create destination: %v", errCD)
  }

  defer w.Close()

  if _, err := io.Copy(w, r); err != nil { // Local scope error, so err is 
fine
os.Remove(dst)
return fmt.Errorf("cannot copy data from source: %v", err)

  }

  if err := w.Close(); err != nil {
os.Remove(dst)
return fmt.Errorf("cannot close destination", err)
  }
}

// Caller should do this.
if err := CopyFile("dst.txt", "src.txt"); err != nil {
  // Here is where you should add 'copy' to the error message.
  return fmt.Errorf("cannot copy '%s' to '%s': %v", src, dst, err)
}

People complaining about Go's error handling regularly don't handle errors, 
they just throw them like exceptions.

If you really hate Go's error handling, just use:

func catch(err error) {
  if err != nil {
panic(err)
  }

  // And use recover somewhere
}

Which is a bad practice, but at least we (the people who like how Go handle 
errors) can still handle our errors without any language change.

On Tue, Aug 1, 2023, 13:06 DrGo wrote:

Thanks. 
The keystroke saving is not the motivation. The aim is to reduce the code 
reader’s mental load. My approach allows for clearer code where the main 
program logic is not dwarfed by the error handling code while maintaining 
the explicitly of error handling and the possible error-induced 
interruption in program flow. It avoids creating new if scope when one is 
not desired and offers opportunities for further deduplication of error 
handling code although each error is still handled individually. Compare 
the following; which one would you prefer to read a lot of?

- current approach; error handling to program logic ratio: 13:5 

func CopyFile(src, dst string) error {
r, err := os.Open(src)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
defer r.Close()

w, err := os.Create(dst)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

if _, err := io.Copy(w, r); err != nil {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

if err := w.Close(); err != nil {
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
}

- new approach ratio 5:5
func CopyFile(src, dst string) error {
r, err := os.Open(src) *orelse* return fmt.Errorf("copy %s %s: %v", src, 
dst, err)
defer r.Close()

w, err := os.Create(dst); *orelse* return fmt.Errorf("copy %s %s: %v", src, 
dst, err)
err := io.Copy(w, r) *orelse* {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

err := w.Close() *orelse* {
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
}

On Sunday, July 30, 2023 at 9:27:27 PM UTC-6 Marcello H wrote:

I think the current error handling is just fine.
For the extra typing, they invented keyboard snippets and such.

But for this proposal, I would like to see how a return with multiple 
values would look to get a better understanding.
```
// translate this in the proposed solution?

Re: [go-nuts] Re: Error handling

[Miguel Angel Rivera Notararigo]

func CopyFile(src, dst string) error {
r, err := os.Open(src)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
defer r.Close()

w, err := os.Create(dst)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

if _, err := io.Copy(w, r); err != nil {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

if err := w.Close(); err != nil {
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
}

I think it is a bad example, how do you know where CopyFile failed?

The "copy ..." part shouldn't be in there, you should add valuable context
to your errors, if CopyFile fails, the caller already knows it was a copy
error because the function has a big "Copy" on his name right? you should
do this instead:

func CopyFile(dst, src string) error {
  r, errOS := os.Open(src) // Avoid shadowing errors, don't use err
  if errOS != nil {
return fmt.Errorf("cannot open source: %v", errOS)
  }

  defer r.Close()

  w, errCD := os.Create(dst)
  if errCD != nil {
return fmt.Errorf("cannot create destination: %v", errCD)
  }

  defer w.Close()

  if _, err := io.Copy(w, r); err != nil { // Local scope error, so err is
fine
os.Remove(dst)
return fmt.Errorf("cannot copy data from source: %v", err)
  }

  if err := w.Close(); err != nil {
os.Remove(dst)
return fmt.Errorf("cannot close destination", err)
  }
}

// Caller should do this.
if err := CopyFile("dst.txt", "src.txt"); err != nil {
  // Here is where you should add 'copy' to the error message.
  return fmt.Errorf("cannot copy '%s' to '%s': %v", src, dst, err)
}

People complaining about Go's error handling regularly don't handle errors,
they just throw them like exceptions.

If you really hate Go's error handling, just use:

func catch(err error) {
  if err != nil {
panic(err)
  }

  // And use recover somewhere
}

Which is a bad practice, but at least we (the people who like how Go handle
errors) can still handle our errors without any language change.

On Tue, Aug 1, 2023, 13:06 DrGo  wrote:

> Thanks.
> The keystroke saving is not the motivation. The aim is to reduce the code
> reader’s mental load. My approach allows for clearer code where the main
> program logic is not dwarfed by the error handling code while maintaining
> the explicitly of error handling and the possible error-induced
> interruption in program flow. It avoids creating new if scope when one is
> not desired and offers opportunities for further deduplication of error
> handling code although each error is still handled individually. Compare
> the following; which one would you prefer to read a lot of?
>
> - current approach; error handling to program logic ratio: 13:5
>
> func CopyFile(src, dst string) error {
> r, err := os.Open(src)
> if err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> defer r.Close()
>
> w, err := os.Create(dst)
> if err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> if _, err := io.Copy(w, r); err != nil {
> w.Close()
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> if err := w.Close(); err != nil {
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> }
>
> - new approach ratio 5:5
> func CopyFile(src, dst string) error {
> r, err := os.Open(src) *orelse* return fmt.Errorf("copy %s %s: %v", src,
> dst, err)
> defer r.Close()
>
> w, err := os.Create(dst); *orelse* return fmt.Errorf("copy %s %s: %v",
> src, dst, err)
> err := io.Copy(w, r) *orelse* {
> w.Close()
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> err := w.Close() *orelse* {
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> }
>
> On Sunday, July 30, 2023 at 9:27:27 PM UTC-6 Marcello H wrote:
>
>> I think the current error handling is just fine.
>> For the extra typing, they invented keyboard snippets and such.
>>
>> But for this proposal, I would like to see how a return with multiple
>> values would look to get a better understanding.
>> ```
>> // translate this in the proposed solution?
>> func myFirstFunction() (string, err) {
>>result, err := myFunction()
>>if err != nill {
>>return rest, err
>>}
>> }
>> ```
>>
>> Op maandag 31 juli 2023 om 04:32:01 UTC+2 schreef DrGo:
>>
>>> Another possibility Jeremy is that the orelse block is executed if any
>>> of the returned error values is not nil.
>>>
>>> On Sunday, July 30, 2023 at 8:14:58 PM UTC-6 DrGo wrote:
>>>
 Thanks...
 yes indeed. Too many requirements but I think this solution comes close
 to meeting them. If a rare function returns more than one error value (yet
 to see one in the wild) then the compiler should reject orelse use and the
 user can fallback on the (the if err!= nil) approach.

 On Sunday, July 30, 2023 at 6:02:57 PM UTC-6 Jeremy French wrote:

> Also, errors are values, which means - although uncommon - a function
> could return two or more 

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

[Jinbao Chen]

Thanks for the relpy. I have opened an issue on github: 
https://github.com/golang/go/issues/61730

On Thursday, 3 August 2023 at 17:49:25 UTC+8 Michael Knyszek wrote:

> That line (the full sentence is "The garbage collector now includes 
> non-heap sources of garbage collector work (e.g., stack scanning) when 
> determining how frequently to run.") is unrelated. It only refers to a 
> change in accounting for what gets included in the GOGC calculation, not a 
> change in what was marked and scanned by the GC.
>
> On Thursday, August 3, 2023 at 1:41:35 AM UTC-4 Qingwei Li wrote:
>
>> I notice that Go1.17.7 still allocates the array on heap by calling 
>> newobject while Go1.18 allocates the array on stack. I also notice that in 
>> the release note of Go1.18 that "The garbage collector now includes 
>> non-heap sources of garbage collector work". Does the GC in 1.18 and 
>> following versions of Go ignore some global memory area when marking?
>>
>> On Thursday, August 3, 2023 at 1:03:31 AM UTC+8 Jinbao Chen wrote:
>>
>>> I use go1.20.5 to compile the following code. 
>>> package main
>>>
>>> func use(...interface{}) {
>>>   
>>> }
>>>
>>> func main() {
>>> testCases := [...][][]int{
>>> {{42}},
>>> {{1, 2}},
>>> {{3, 4, 5}},
>>> {{}},
>>> {{1, 2}, {3, 4, 5}, {}, {7}},
>>> }
>>> for _, testCase := range testCases {
>>> use(testCase)
>>> }
>>> }
>>> In the generated SSA and assembly code, I notice that the Go compiler 
>>> generates some instructions that store a stack pointer(point to the 
>>> stack-allocated array) into a global slice header.
>>>
>>> Just like the assembly code below, the MOV instruction at 0x4585bf 
>>> stores a stack pointer into a global object: 
>>>   0x458589 48c7442408   MOVQ $0x0, 0x8(SP) 
>>>   0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP) 
>>> testCases := [...][][]int{
>>>   0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP) 
>>>   0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP) 
>>>   0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB) 
>>>   0x4585b8 750e JNE 0x4585c8 
>>>   0x4585ba 488d442408 LEAQ 0x8(SP), AX 
>>>   0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP) 
>>>   0x4585c6 eb11 JMP 0x4585d9 
>>>   0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI 
>>>   0x4585cf 488d442408 LEAQ 0x8(SP), AX 
>>>   0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB) 
>>>
>>> I have read the comments in slicelit 
>>> ,
>>>   
>>> but I didn't find any operations that can generate such stores. As far as I 
>>> know, pointers to stack objects cannot be stored in global objects. So is 
>>> this a compiler bug? Or the Go compiler does this on purpose to achieve 
>>> some optimization I don't know yet?
>>>
>>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e7fc85da-8df8-43ee-b611-c57cbc142fa9n%40googlegroups.com.

Re: [go-nuts] Error handling

[DrGo]

I think the proposal goes beyond saving few keystrokes.. as demonstrated in 
several of my replies above. The issue is readability and avoiding creating 
new scope with the current shortcut approach if x, err:=fn();  err!=nil.

On Wednesday, August 2, 2023 at 2:58:42 PM UTC-6 Wojciech S. Czarnecki 
wrote:

> Dnia 2023-07-29, o godz. 22:57:15
> DrGo  napisał(a):
>
> > This involves introducing a new keyword "orelse" that is a syntactic 
> sugar for an "if err!=nil" block.
>
> You can implement it as a snippet under any editor in use today.
>
> If your goal is to personally have it in just one line, you can turn off 
> gofmt and write `; if err !=nil {; return err }`
>
> I'd like to point out that considering 
>
> > It is an error to not return an error from an orelse block.
>
> The `return err` in examples still is a boilerplate, so the overall 
> savings are just four utf-8 bytes, ie. {\n}\n.
>
> I understand sentiment, 'cos there is a huge camp of devs claiming that 
> any error handling proper is one that is done by something/someone up the 
> callstack, even future-me — for this camp idiomatic Go can be annoying.
>
> But note that for the most pleasant coder experience the `orelse return 
> err` is way too much of text to write. 
>
> I would better stay with ^^ digraph instead. Lets name it a 'bat operator'.
>
> func CopyFile(src, dst string) error { 
> r, err := os.Open(src) ^^ 
> defer r.Close()
> w, err := os.Create(dst) ^^
> defer w.Close()
> err = io.Copy(w, r) ^^
> err = w.Close() ^^
> }
>
> > It also works well with named returns. e.g., 
>
> func returnsObjorErro() (obj Obj, err error) {
> obj, err := createObj() ^^ //returns nil and err
> } 
>
> > otherwise ^^ is like "else" so e.g., it can be followed by a block if 
> > additional cleanup or error formatting etc is needed before returning, eg
>
> w, err := os.Create(dst) ^^ {
> 
> return err 
> }
>
> P.S — bat operator is easily implementable in an IDE with 
> onFileOpen/onFileWrite hooks.
> Its the piping of content to tools (VSCode and GoLand) that bars me from 
> personally using it.
>
> Hope this helps,
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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/dfa8041e-7e16-4ef5-a97b-a7282ba6b5c4n%40googlegroups.com.

Re: [go-nuts] Error handling

[DrGo]

Fully agree.. I think my proposal is targeted primarily at that group 
although recognizing the strength and ability of group #1 to block any 
discussion

On Wednesday, August 2, 2023 at 1:30:00 PM UTC-6 TheDiveO wrote:

> Sorry to f'up on myself, but I would like to add regarding #1: at least my 
> personal impression is that for #1 it looks very difficult to improve this 
> in any meaningful way. It looks to me as if #2 is actually where the 
> improvements would bear large fruit as it makes Go more welcoming and 
> productive to those types of devs and/or types of Go modules, that is, 
> applications.
>
> On Wednesday, August 2, 2023 at 9:27:23 PM UTC+2 TheDiveO wrote:
>
>>
>> Ben Hoyt's blog post Scripting with Go: a 400-line Git client that... 
>>  mentions error handling from a 
>> perspective that made me clear for the first time why I'm always in two 
>> minds when it comes to Go's error handling:
>>
>>1. the perspective of a prod-code package writer that will be used in 
>>larger contexts: "[Go's error handling is] *simple and explicit [...] 
>>It's not a big deal when writing production code, because then you want 
>>more control over error handling anyway -- nicely-wrapped errors, or 
>>human-readable messages [...]*"
>>2. from a "script" developer perspective, where "*all the error 
>>handling you need is to show a message, print a stack trace, and exit the 
>>program*".
>>
>> There might be more angles to it, but Ben's sentiment rings a bell with 
>> my own "customer" experience.
>>
>> So we can at least expect to have two "camps of judges" when it comes to 
>> error handling improvement proposals. Some of the judges might be acutely 
>> aware of the at least two different angles, but some of the comments not 
>> least in this thread ("language designers" as kind of gods who must ignore 
>> their customers, seriously?) seem to indicate that this isn't always the 
>> case. Not least, I also fall into the less desirable category of the 
>> ignoramus.
>>
>> So, maybe we should in the future always ask when it comes to a proposal: 
>> which of the two perspectives does the proposal tackle? I'm under the 
>> assumption that it might have been #2 in most of the proposals. The often 
>> vivid negative responses should then be classified as belonging to #1 
>> and/or #2. If the proposal is about #2, then #1 proponents don't 
>> contribute, but simply make life hard for the #2 customers of the Go 
>> language. Same for the opposite combination.
>>
>> On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote:
>>
>>> Fair enough … I understand that people have different styles 
>>>
>>> On Wednesday, August 2, 2023 at 12:54:20 AM UTC-6 Brian Candler wrote:
>>>
 FWIW, I'm in the "I like how it is now better than any other proposal 
 so far" camp; I think this happens as you get used to the Go way. Go is Go.

 The only thing I would consider is making *interface* types (only) 
 implicitly usable in a boolean context, e.g.

 if err { ... }

 However, I suppose people would ask "why not pointers? why not 
 channels?" etc.  I'm not suggesting it should become like Python where 
 every non-zero value is treated as "true".  Interface values are special, 
 and there's very little you can do with a nil interface (whereas for 
 example, a nil pointer can still have methods called on it).  But this 
 does 
 add a special case, and Go already has its share of surprises you have to 
 learn.

 On Tuesday, 1 August 2023 at 22:41:38 UTC+1 DrGo wrote:

> Yes. Go is no longer the simple language it was. I suspect because of 
> internal pressures within Google as evidenced by multiple innovations 
> that 
> seem to come from nowhere eg dir embedding and associated fs package that 
> duplicated perfectly good ways of doing things. The module system while 
> useful is quite complex. Generics and all the associated packages 
> inflated 
> the mental burden of learning and reading Go code significantly. And 
> having 
> the go 1 compatibility guarantee means that old stuff remains valid code 
> and must be learned too. 
>
> On Tuesday, August 1, 2023 at 2:59:07 PM UTC-6 Victor Giordano wrote:
>
>> Yeah.. I mean, the "idiom" `err != nil return` err is something of 
>> the language. I complain about the boilerplate that idiom produces and 
>> that 
>> is fact fact (no one can deny it).
>>
>> You know, your approach implies making the language a little more 
>> complicated as new ways to deal with errors appear. I do understand that 
>> some folks provide some push back on the idea simply because there is 
>> nothing wrong with the language right now regarding error handling. 
>>
>> As I see things, the language was simple in their origins, but from 
>> time to time they complicated 

Re: [go-nuts] Error handling

[DrGo]

Great point! 
Gophers like any human tribes can become victims of absolutest thinking. In 
the gophers' case, tenets like "there should be only way of doing things" 
while admirable and justified most of the time can inhibit discussions 
about possible improvements. There are times where it is perfectly 
acceptable to have two ways to do something; and I argue that something as 
important and fundemental as error handling is one of those things. Your 
explanation above demonstrates the case.


 

On Wednesday, August 2, 2023 at 1:27:23 PM UTC-6 TheDiveO wrote:

>
> Ben Hoyt's blog post Scripting with Go: a 400-line Git client that... 
>  mentions error handling from a 
> perspective that made me clear for the first time why I'm always in two 
> minds when it comes to Go's error handling:
>
>1. the perspective of a prod-code package writer that will be used in 
>larger contexts: "[Go's error handling is] *simple and explicit [...] 
>It's not a big deal when writing production code, because then you want 
>more control over error handling anyway -- nicely-wrapped errors, or 
>human-readable messages [...]*"
>2. from a "script" developer perspective, where "*all the error 
>handling you need is to show a message, print a stack trace, and exit the 
>program*".
>
> There might be more angles to it, but Ben's sentiment rings a bell with my 
> own "customer" experience.
>
> So we can at least expect to have two "camps of judges" when it comes to 
> error handling improvement proposals. Some of the judges might be acutely 
> aware of the at least two different angles, but some of the comments not 
> least in this thread ("language designers" as kind of gods who must ignore 
> their customers, seriously?) seem to indicate that this isn't always the 
> case. Not least, I also fall into the less desirable category of the 
> ignoramus.
>
> So, maybe we should in the future always ask when it comes to a proposal: 
> which of the two perspectives does the proposal tackle? I'm under the 
> assumption that it might have been #2 in most of the proposals. The often 
> vivid negative responses should then be classified as belonging to #1 
> and/or #2. If the proposal is about #2, then #1 proponents don't 
> contribute, but simply make life hard for the #2 customers of the Go 
> language. Same for the opposite combination.
>
> On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote:
>
>> Fair enough … I understand that people have different styles 
>>
>> On Wednesday, August 2, 2023 at 12:54:20 AM UTC-6 Brian Candler wrote:
>>
>>> FWIW, I'm in the "I like how it is now better than any other proposal so 
>>> far" camp; I think this happens as you get used to the Go way. Go is Go.
>>>
>>> The only thing I would consider is making *interface* types (only) 
>>> implicitly usable in a boolean context, e.g.
>>>
>>> if err { ... }
>>>
>>> However, I suppose people would ask "why not pointers? why not 
>>> channels?" etc.  I'm not suggesting it should become like Python where 
>>> every non-zero value is treated as "true".  Interface values are special, 
>>> and there's very little you can do with a nil interface (whereas for 
>>> example, a nil pointer can still have methods called on it).  But this does 
>>> add a special case, and Go already has its share of surprises you have to 
>>> learn.
>>>
>>> On Tuesday, 1 August 2023 at 22:41:38 UTC+1 DrGo wrote:
>>>
 Yes. Go is no longer the simple language it was. I suspect because of 
 internal pressures within Google as evidenced by multiple innovations that 
 seem to come from nowhere eg dir embedding and associated fs package that 
 duplicated perfectly good ways of doing things. The module system while 
 useful is quite complex. Generics and all the associated packages inflated 
 the mental burden of learning and reading Go code significantly. And 
 having 
 the go 1 compatibility guarantee means that old stuff remains valid code 
 and must be learned too. 

 On Tuesday, August 1, 2023 at 2:59:07 PM UTC-6 Victor Giordano wrote:

> Yeah.. I mean, the "idiom" `err != nil return` err is something of the 
> language. I complain about the boilerplate that idiom produces and that 
> is 
> fact fact (no one can deny it).
>
> You know, your approach implies making the language a little more 
> complicated as new ways to deal with errors appear. I do understand that 
> some folks provide some push back on the idea simply because there is 
> nothing wrong with the language right now regarding error handling. 
>
> As I see things, the language was simple in their origins, but from 
> time to time they complicated a little more some things, for example 
> "what 
> about generics?"  (are they really necessary?, I mean... I think using 
> interfaces provides all the genericity you may need). So I guess there is 
> 

Re: [go-nuts] Realpath?

[Carlos Henrique Guardão Gandarez]

Hey there!

I created a new lib to return a real path in Go.
https://github.com/gandarez/go-realpath

Thanks.

On Thursday, January 18, 2018 at 4:28:09 PM UTC-2 rgo...@redhat.com wrote:

>
>
> On Monday, 16 July 2012 13:55:53 UTC+3, Rémy Oudompheng wrote:
>>
>> Did you have a look at filepath.EvalSymlinks? 
>>
>> Rémy. 
>>
>
> Confirmed to be working. Thanks Remy. 
>

-- 
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/7fefe6d0-7185-47b3-8e9e-bcb99ae0ebcfn%40googlegroups.com.

[go-nuts] Re: Any option to substitute plug-in package ?

[alex-coder]

Hi All,
Currently I walk through the next book about native go development and find 
out that it is possible to use the plugin, 
but with limitations, so it became interesting what alternatives there are.

Thank you.

четверг, 3 августа 2023 г. в 12:09:21 UTC+3, Christoph Berger: 

> WebAssembly comes to mind - see, for example, https://wazero.io/
>
> A plugin would then be a .wasm binary that can be compiled in any language 
> that supports WebAssembly as target.
>
> Disclaimer: I have not yet tried this approach.
>
> On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:
>
> Hi All !
> Plug-in package is very interesting, but in case the development under 
> windows it does not work,
> So, any hint to use some option instead will be highly appreciated.
>
> 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/5ad7ddd5-c6de-486a-be89-4b6daf008729n%40googlegroups.com.

[go-nuts] How to convert an svg to a png (or gif) image?

['Mark' via golang-nuts]

I know this has been asked before, just wondered if there were any pure-Go 
solutions?

-- 
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/e8a39bee-742a-4491-809a-b2230ef8ea26n%40googlegroups.com.

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

['Michael Knyszek' via golang-nuts]

That line (the full sentence is "The garbage collector now includes 
non-heap sources of garbage collector work (e.g., stack scanning) when 
determining how frequently to run.") is unrelated. It only refers to a 
change in accounting for what gets included in the GOGC calculation, not a 
change in what was marked and scanned by the GC.

On Thursday, August 3, 2023 at 1:41:35 AM UTC-4 Qingwei Li wrote:

> I notice that Go1.17.7 still allocates the array on heap by calling 
> newobject while Go1.18 allocates the array on stack. I also notice that in 
> the release note of Go1.18 that "The garbage collector now includes 
> non-heap sources of garbage collector work". Does the GC in 1.18 and 
> following versions of Go ignore some global memory area when marking?
>
> On Thursday, August 3, 2023 at 1:03:31 AM UTC+8 Jinbao Chen wrote:
>
>> I use go1.20.5 to compile the following code. 
>> package main
>>
>> func use(...interface{}) {
>>   
>> }
>>
>> func main() {
>> testCases := [...][][]int{
>> {{42}},
>> {{1, 2}},
>> {{3, 4, 5}},
>> {{}},
>> {{1, 2}, {3, 4, 5}, {}, {7}},
>> }
>> for _, testCase := range testCases {
>> use(testCase)
>> }
>> }
>> In the generated SSA and assembly code, I notice that the Go compiler 
>> generates some instructions that store a stack pointer(point to the 
>> stack-allocated array) into a global slice header.
>>
>> Just like the assembly code below, the MOV instruction at 0x4585bf stores 
>> a stack pointer into a global object: 
>>   0x458589 48c7442408   MOVQ $0x0, 0x8(SP) 
>>   0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP) 
>> testCases := [...][][]int{
>>   0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP) 
>>   0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP) 
>>   0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB) 
>>   0x4585b8 750e JNE 0x4585c8 
>>   0x4585ba 488d442408 LEAQ 0x8(SP), AX 
>>   0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP) 
>>   0x4585c6 eb11 JMP 0x4585d9 
>>   0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI 
>>   0x4585cf 488d442408 LEAQ 0x8(SP), AX 
>>   0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB) 
>>
>> I have read the comments in slicelit 
>> ,
>>   
>> but I didn't find any operations that can generate such stores. As far as I 
>> know, pointers to stack objects cannot be stored in global objects. So is 
>> this a compiler bug? Or the Go compiler does this on purpose to achieve 
>> some optimization I don't know yet?
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/74ee4bb3-da1b-4db9-a3df-e38d1df28b2dn%40googlegroups.com.

[go-nuts] Re: Any option to substitute plug-in package ?

[Christoph Berger]

WebAssembly comes to mind - see, for example, https://wazero.io/

A plugin would then be a .wasm binary that can be compiled in any language 
that supports WebAssembly as target.

Disclaimer: I have not yet tried this approach.

On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:

Hi All !
Plug-in package is very interesting, but in case the development under 
windows it does not work,
So, any hint to use some option instead will be highly appreciated.

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/aa602732-8a37-4ebb-bd48-4efffd34144en%40googlegroups.com.

[go-nuts] Re: Any option to substitute plug-in package ?

[Brian Candler]

I believe Hashicorp's go-plugin was developed long before Go's stdlib 
plugin functionality was made available.

But they still use it. It's well established and tested, the architecture 
has security benefits, and it works cross-platform. It also makes it easier 
for plugins to be distributed by third parties: they don't have to be 
compiled with the exact same toolchain. In fact, they don't even have to be 
written in Go.

Of course, shared libraries will be much faster - so it depends on your use 
case, whether you need large volumes of low-latency calls.

If your production environment is Linux, and the only issue is around 
*development* under Windows, then you can look into WSL or virtual machines.

On Thursday, 3 August 2023 at 07:17:49 UTC+1 alex-coder wrote:

> Hi All,
>
> so, binary code plugin as a RPC - frankly, never thought about :-)
>
> What is written in go spec is a 
> >> dynamically discovering and loading *shared lib*
> as I see it but community developed much further
>
> Thank you.
>
> среда, 2 августа 2023 г. в 15:03:38 UTC+3, TheDiveO: 
>
>> It really depends on what you want to achieve...
>>
>>1. dynamically discovering *out-of-process* RPC plugins ... 
>>Hashicorp's might be the most famous one.
>>2. dynamically discovering and loading *shared lib *plugins ... this 
>>needs some plumbing above the pure stdlib plugin functionality. 
>> Personally, 
>>I find the shared libs to be finicky and haven't yet done a real project 
>>that needed this variant (but I wrote a go-plugger 
>> module as an example).
>>3. statically binary-builtin plugins: this actually is what I tend to 
>>use in several of my own projects, where there is no need for dynamically 
>>extending but instead to easily maintain and use a fixed set of "plugins" 
>>and that set of plugins tends to slowly grow. The plugin mechanism might 
>>help organizing, such as my own go-plugger 
>> supporting type-safe plugin 
>>APIs and ordering and iterating plugins at runtime. For instance, I use 
>>this mechanism to simplify adding new types to factories, or to 
>> "decorate" 
>>containers with additional labels, such as in Docker compose contexts, or 
>>k8s contexts, or ...
>>
>>
>> On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:
>>
>>> Hi All !
>>> Plug-in package is very interesting, but in case the development under 
>>> windows it does not work,
>>> So, any hint to use some option instead will be highly appreciated.
>>>
>>> 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/c3905d16-f759-42e1-a838-ee667a96e481n%40googlegroups.com.

[go-nuts] Re: Any option to substitute plug-in package ?

[alex-coder]

Hi All,

so, binary code plugin as a RPC - frankly, never thought about :-)

What is written in go spec is a 
>> dynamically discovering and loading *shared lib*
as I see it but community developed much further

Thank you.

среда, 2 августа 2023 г. в 15:03:38 UTC+3, TheDiveO: 

> It really depends on what you want to achieve...
>
>1. dynamically discovering *out-of-process* RPC plugins ... 
>Hashicorp's might be the most famous one.
>2. dynamically discovering and loading *shared lib *plugins ... this 
>needs some plumbing above the pure stdlib plugin functionality. 
> Personally, 
>I find the shared libs to be finicky and haven't yet done a real project 
>that needed this variant (but I wrote a go-plugger 
> module as an example).
>3. statically binary-builtin plugins: this actually is what I tend to 
>use in several of my own projects, where there is no need for dynamically 
>extending but instead to easily maintain and use a fixed set of "plugins" 
>and that set of plugins tends to slowly grow. The plugin mechanism might 
>help organizing, such as my own go-plugger 
> supporting type-safe plugin 
>APIs and ordering and iterating plugins at runtime. For instance, I use 
>this mechanism to simplify adding new types to factories, or to "decorate" 
>containers with additional labels, such as in Docker compose contexts, or 
>k8s contexts, or ...
>
>
> On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:
>
>> Hi All !
>> Plug-in package is very interesting, but in case the development under 
>> windows it does not work,
>> So, any hint to use some option instead will be highly appreciated.
>>
>> 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/ee812683-6265-45d0-9de5-711859094a8bn%40googlegroups.com.