[go-nuts] Re: Guidance on techniques that can help me write a comprehensive test for my go library.

[Marcello H]

Normally, the way to use the functions/methods of the external library is 
by having an interface with all the function definitions.

Then you can generate a mock that offers the same functionality.
With such a mock, you can give all kinds of results back to the caller.

Do you have your project in a public GIT?

Op woensdag 5 juni 2024 om 15:41:03 UTC+2 schreef Ai Readone:

> Hello Everyone,
>
> I am currently writing a go library that Integrates various Google cloud 
> services.
>
> The aim of the library is to eliminate duplicate implementations across 
> various services of the same software.
>
>
> I am having challenges on how to write a comprehensive test for my 
> library, the main challenges are coming from testing function and methods 
> that performs remote call to Google cloud APIs
>
> I want to be able to mock every function in my library.
>
> I am familiar with majorly table-testing technique but I am open 
> to suggestions that requires me to learn new technologies too.
>
> Thanks in advance for your time and help.
>

-- 
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/a79ed2ea-5d89-4cb1-9c3f-1e4eb09d78aen%40googlegroups.com.

Re: [go-nuts] Unused local constants not a compiler error

[Marcello H]

In golanglint_ci, there's a 'unused' linter, which will detect unused const 
vars too.

Op vrijdag 3 mei 2024 om 00:18:02 UTC+2 schreef Ian Lance Taylor:

> On Thu, May 2, 2024 at 2:48 PM will@gmail.com  
> wrote:
> >
> > Was this always the case? Is this a bug? Seems like it should be a 
> compiler error, like unused local variables.
>
> Yes, it's always been the case. It would probably be painful to change it 
> now.
>
> 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/90684dd6-7d05-4a61-8209-1b0f9fcc828an%40googlegroups.com.

[go-nuts] Re: Trying to understand aversion to main package

[Marcello H]

My main acts just like a mini bootstrap to do as less as possible and hand 
the real action over to start.Run()
But is is still testable.

```

var mainRunner = runner

/* -- Methods/Functions -- */

// runner starts the application and can be overwritten in a test for 
mocking.
func runner() error {
return start.Run() //nolint:wrapcheck // not needed here
}

/*
main is the bootstrap of the application.
*/
func main() {
err := mainRunner()
if err != nil {
fmt.Println("Error:\n", libErrors.GetError(err))
}
}
```
In an internal test, the mainRunner is mocked and can emulate an error if 
needed.
func Test_Main_Error(t *testing.T) {
mainRunner = func() error {
return errors.New("test error")
}

defer func() {
mainRunner = runner
}()

captured := libCapture.Direct(func() {
main()
})

assert.Contains(t, captured, "test error")
}

Op donderdag 15 februari 2024 om 10:05:11 UTC+1 schreef Brian Candler:

> On Thursday 15 February 2024 at 00:08:44 UTC Jerry Londergaard wrote:
>
> If code is outside of the main function but still in the main package, it 
> seems its testable like other functions?
>
>
> Yes indeed.
>  
>
> I suspect though if one is putting tests in package main_test, then I 
> guess you can't import the main package to test it :(
>
>
> Works fine as far as I can see:
> https://go.dev/play/p/7UtYP2j8hg6
>
> (Tests don't run in the playground, unless you explicitly invoke a runner, 
> but you can run this locally to demonstrate)
>

-- 
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/83536ffc-8a80-4fbb-8a26-8dafe2b764e5n%40googlegroups.com.

Re: [go-nuts] Re: need a package to read/write shell history flat file database

[Marcello H]

This package (FZF) is also using the history file, perhaps there's 
something usable inside.
https://github.com/junegunn/fzf

Op zondag 11 februari 2024 om 06:41:11 UTC+1 schreef Kurtis Rader:

> Thanks, but that requires me to implement the code I would rather not have 
> to reinvent given that shells like Bash, Ksh, and Fish already have code to 
> do what I need. The problem is that those solutions are written in C and 
> C++ respectively rather than Go. While I consider myself an expert in C 
> (having started programming with it around 1985) I am only minimally 
> competent in C++. I'll translate the Fish C++ code into Go if I have to but 
> am hoping there is a published Go equivalent to save me that effort.
>
> P.S., This is to remove the dependency on a daemon process to update a 
> BoltDB database by the Fish shell. The BoltDB dependency (go.etcd.io/bbolt) 
> greatly increases the size and complexity of the Fish shell. The opaque 
> binary database managed by BoltDB is also annoying. It would be preferable 
> to use a flat file database using JSON or text protobufs for storing 
> command history.
>
> On Sat, Feb 10, 2024 at 9:15 PM 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> On Sat, 2024-02-10 at 21:01 -0800, Kurtis Rader wrote:
>> > The only solution I can find that gets close to my requirements is
>> > https://github.com/ergochat/readline, but AFAICT it does not handle
>> > updates to the on-disk history file by concurrently executing
>> > processes.
>>
>> There is also https://pkg.go.dev/github.com/peterh/liner, which also
>> does not handle history persistence, but which makes it relatively easy
>> to add.
>>
>> -- 
>> 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/e37a98a811c8e1cccfef8feffafef5260e7e5e56.camel%40kortschak.io
>> .
>>
>
>
> -- 
> 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/ef46ee58-f20d-47c1-baef-fdf63681c2e9n%40googlegroups.com.

Re: [go-nuts] Re: 'go run hello.go' taking ~30 seconds on windows

[Marcello H]

You could leave it on, but exclude the directories that you use (also the
temp one)
https://www.thewindowsclub.com/exclude-a-folder-from-windows-security-scan

Op wo 20 sep 2023 om 04:55 schreef Hoo Luu :

> Windows defender slows apps first time ran. I had replaced several hard
> disks(HDDs and SSDs) and reinstalled OS systems(win7,win10,win11), nothing
> changed. After turning off  windows defender, everything returns to normal.
>
> 在2023年6月24日星期六 UTC+8 02:00:20 写道：
>
>> Hi Declan,
>>
>> What's the full code? Also have you tried using
>> https://learn.microsoft.com/en-us/sysinternals/downloads/procmon and see
>> what it does?
>>
>>
>>
>> On Friday, June 23, 2023 at 10:04:24 AM UTC+5:30 Henry wrote:
>>
>>> I am running Windows 11 with Kaspersky. I don't have such problems. When
>>> it comes to Windows, it isn't as simple as blaming your AV. Windows is a
>>> complex OS and it is doing many different things in the background (e.g.
>>> doing maintenance, installing updates, etc.).  You should open your Task
>>> Manager and see what is hogging your resources. You also need some decent
>>> hardware as Windows is a bit resource hungry. You may also check if there
>>> is an error with Windows itself. See  Using System File Checker in
>>> Windows - Microsoft Support
>>> 
>>>
>>> On Thursday, June 22, 2023 at 7:47:59 PM UTC+7 Jet Li wrote:
>>>
 Like to note that if you mean Windows Defender, there is no way to
 disable that after Build 20H2 iirc where I was task to deploy Windows 10
 and could not find the option in Windows Group Policy settings after the
 update, if Go app are affected by Windows Defender. Your only option is to
 use older Windows build and alternative OS, mileage may vary.

 Another option, could be impossible to backup VM image as it's on macOS
 https://multipass.run/
 On Thursday, 22 June 2023 at 19:52:56 UTC+8 Wojciech S. Czarnecki wrote:

> Dnia 2023-06-18, o godz. 22:52:58
> tokintmash  napisał(a):
>
> > Hello,
> >
> > Was there a solution to this? I am having the same issue. Win 10
> machine
> > and compiling and running simple lines of code takes ages.
>
> The answer is always the same: turn off your antivirus software for
> your development tree.
>
> Such delays are due to "heuristics" usually implemented by uploading
> your exe to the vendor.
> Root cause is that after 12 years AV vendors still can not cope with
> what they pereceive
> a "non standard" linker, ie. a Go's one.
>
> hope this helps,
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
 --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/IR8v3B1pPCI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/2dcbf249-88d0-4bbd-a0fd-2d3b11d3ea8bn%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/CADBSaR1t39RCA1hz-kQ%2BR8BHP9rTXEN0ADvokoDDVC%3D9MFQC7Q%40mail.gmail.com.

Re: [go-nuts] Re: [slog] customize defaultHandler

[Marcello H]

After playing with it some more:

This also does the trick

h := NewHandler(os.Stdout, {Level: slog.LevelDebug, TimeFormat:
time.DateTime})
l := slog.New(h)
slog.SetDefault(l)

slog.Debug("hello")
slog.Info("hello")
slog.Warn("hello")
slog.Error("hello")





type MyOptions struct {
// Enable source code location (Default: false)
AddSource bool

// Minimum level to log (Default: slog.LevelInfo)
Level slog.Leveler

// ReplaceAttr is called to rewrite each non-group attribute before it is
logged.
// See https://pkg.go.dev/log/slog#HandlerOptions for details.
ReplaceAttr func(groups []string, attr slog.Attr) slog.Attr

// Time format (Default: time.StampMilli)
TimeFormat string
}

type MyHandler struct {
opts MyOptions
prefix string // preformatted group names followed by a dot
preformat string // preformatted Attrs, with an initial space
timeFormat string

mu sync.Mutex
w io.Writer
}

func NewHandler(w io.Writer, opts *MyOptions) *MyHandler {
h := {w: w}
if opts != nil {
h.opts = *opts
}
if h.opts.ReplaceAttr == nil {
h.opts.ReplaceAttr = func(_ []string, a slog.Attr) slog.Attr { return a }
}
if opts.TimeFormat != "" {
h.timeFormat = opts.TimeFormat
}

return h
}

func (h *MyHandler) Enabled(ctx context.Context, level slog.Level) bool {
minLevel := slog.LevelInfo
if h.opts.Level != nil {
minLevel = h.opts.Level.Level()
}
return level >= minLevel
}

func (h *MyHandler) WithGroup(name string) slog.Handler {
return {
w: h.w,
opts: h.opts,
preformat: h.preformat,
prefix: h.prefix + name + ".",
}
}

func (h *MyHandler) WithAttrs(attrs []slog.Attr) slog.Handler {
var buf []byte
for _, a := range attrs {
buf = h.appendAttr(buf, h.prefix, a)
}
return {
w: h.w,
opts: h.opts,
prefix: h.prefix,
preformat: h.preformat + string(buf),
}
}

func (h *MyHandler) Handle(ctx context.Context, r slog.Record) error {
var buf []byte
if !r.Time.IsZero() {
buf = r.Time.AppendFormat(buf, h.timeFormat)
buf = append(buf, ' ')
}

levText := (r.Level.String() + " ")[0:5]

buf = append(buf, levText...)
buf = append(buf, ' ')
if h.opts.AddSource && r.PC != 0 {
fs := runtime.CallersFrames([]uintptr{r.PC})
f, _ := fs.Next()
buf = append(buf, f.File...)
buf = append(buf, ':')
buf = strconv.AppendInt(buf, int64(f.Line), 10)
buf = append(buf, ' ')
}
buf = append(buf, r.Message...)
buf = append(buf, h.preformat...)
r.Attrs(func(a slog.Attr) bool {
buf = h.appendAttr(buf, h.prefix, a)
return true
})
buf = append(buf, '\n')
h.mu.Lock()
defer h.mu.Unlock()
_, err := h.w.Write(buf)
return err
}

func (h *MyHandler) appendAttr(buf []byte, prefix string, a slog.Attr) []
byte {
if a.Equal(slog.Attr{}) {
return buf
}
if a.Value.Kind() != slog.KindGroup {
buf = append(buf, ' ')
buf = append(buf, prefix...)
buf = append(buf, a.Key...)
buf = append(buf, '=')
return fmt.Appendf(buf, "%v", a.Value.Any())
}
// Group
if a.Key != "" {
prefix += a.Key + "."
}
for _, a := range a.Value.Group() {
buf = h.appendAttr(buf, prefix, a)
}
return buf
}


Op di 29 aug 2023 om 09:16 schreef 'Sean Liao' via golang-nuts <
golang-nuts@googlegroups.com>:

> cycle:
> https://go.dev//issues/61892
>
> default handler, copied/exported:
> https://pkg.go.dev/github.com/jba/slog/handlers/loghandler
>
> - sean
>
>
> On Tue, Aug 29, 2023 at 7:53 AM Marcello H  wrote:
>
>> Yesterday, I came up with the same question and found this:
>> "github.com/lmittmann/tint"
>>
>> (This solution still uses os.Stdout, but I think this can do what you
>> need.)
>>
>> An example:
>> logOptions := {
>> NoColor: true,
>> Level: slog.LevelError,
>> TimeFormat: time.DateTime,
>> }
>> logHandler := tint.NewHandler(os.Stdout, logOptions)
>> logger := slog.New(logHandler)
>> slog.SetDefault(logger)
>> slog.Info("this does not show")
>> slog.Debug("this debug info does not show")
>> logOptions.Level = slog.LevelInfo
>> slog.Info("this is now visible")
>> slog.Debug("this debug info still does not show")
>> logOptions.Level = slog.LevelDebug
>> slog.Info("this is still visible")
>> slog.Debug("this debug info also shows")
>> Op dinsdag 29 augustus 2023 om 03:00:01 UTC+2 schreef Mike Schinkel:
>>
>>> Hi Tamás,
>>>
>>> Have you actually tried that and gotten it to work? It does not compile
>>> for me but this does (note method call vs. property reference):
>>>
>>> slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler()}))
>>>
>>> However, when delegating the Handle() method it seems to cause an
>>> infinite
>>> loop:
>>>
>>> func (m MyHandler) Handle(ctx context.Context, r slog.Record) error {
>>> return m.Handler.H

[go-nuts] Re: [slog] customize defaultHandler

[Marcello H]

Yesterday, I came up with the same question and found this:
"github.com/lmittmann/tint"

(This solution still uses os.Stdout, but I think this can do what you need.)

An example:
logOptions := {
NoColor: true,
Level: slog.LevelError,
TimeFormat: time.DateTime,
}
logHandler := tint.NewHandler(os.Stdout, logOptions)
logger := slog.New(logHandler)
slog.SetDefault(logger)
slog.Info("this does not show")
slog.Debug("this debug info does not show")
logOptions.Level = slog.LevelInfo 
slog.Info("this is now visible")
slog.Debug("this debug info still does not show")
logOptions.Level = slog.LevelDebug 
slog.Info("this is still visible")
slog.Debug("this debug info also shows")
Op dinsdag 29 augustus 2023 om 03:00:01 UTC+2 schreef Mike Schinkel:

> Hi Tamás,
>
> Have you actually tried that and gotten it to work? It does not compile
> for me but this does (note method call vs. property reference):
>
> slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler()}))
>
> However, when delegating the Handle() method it seems to cause an infinite
> loop:
>
> func (m MyHandler) Handle(ctx context.Context, r slog.Record) error {
> return m.Handler.Handle(ctx, r)
> }
>
> See https://goplay.tools/snippet/qw07m0YflLd
>
> I know about this because just this past weekend I was trying to write a
> TeeHandler to output the default to the screen and JSON to a file just this
> past weekend and ran into an infinite loop problem with the default 
> handler.
>
> I tried my best to figure out why it needed to be structured the way it was
> in that it seems to call itself recursively. I wanted to post a question to
> this list to see if there was a workaround, or if not to see if there might
> be interest in allowing it to work, but I could not get my head around it 
> so
> eventually gave up and just used the TextHandler instead.
>
> Shame though. It would be nice to be able to reuse the default handler but
> AFACT it is not possible (though if I am wrong I would love for someone to
> show me how to get it to work.)
>
> -Mike
>
>
> On Monday, August 28, 2023 at 12:50:50 PM UTC-4 Tamás Gulácsi wrote:
>
> slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler}))
>
> vl...@mailbox.org a következőt írta (2023. augusztus 28., hétfő, 15:06:37 
> UTC+2):
>
> Hi, 
>
> When reading trough the log/slog documentation, it seems one can create 
> a logger with a different handler, which is either NewTextHandler or 
> NewJSONHandler. 
>
> Why can't I configure the defaultHandler? Let's say I want my logger to 
> behave exactly like the defaultHandler, but output to a logfile or 
> Stdout instead. 
>
> The defaultHandler's output is different compared to the NewTextHandler: 
>
> slog.Info("ok"), gives me: 
>
> INFO ok 
>
> The NextTextHandler gives me: 
>
> level=INFO msg="ok" 
>
>
> Regards, 
>
>

-- 
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/df136f1e-0283-46fa-a0b7-ce17a0722fd9n%40googlegroups.com.

Re: [go-nuts] go1.21.0 panics when loading plugin

[Marcello H]

Can you isolate the problem?
If the issue is within the regex, you might be able to put that in a 
separate program to test if it happens there too.

Op woensdag 9 augustus 2023 om 00:51:01 UTC+2 schreef Bernd Fix:

> On 8/8/23 18:16, Kurtis Rader wrote:
> > Did you also recompile the plugin with the new Go toolchain? It's a
> > requirement of plugin support that the main program and all plugins be
> > compiled with the same toolchain.
>
> Yes, the loading program and the module were both compiled with the same 
> toolchain. After the first occurence of the issue, I removed everything 
> below $GOPATH and cleaned the cache, just to make sure everything got 
> recompiled correctly - but the problem persists.
>
> If loading and loaded module differ, I would expect a panic like "plugin 
> was built with a different version" (I remember seeing that once) - but 
> certainly not a panic in a regular expression parser.
>
> > 
> > On Tue, Aug 8, 2023 at 11:12 AM Bernd Fix  wrote:
> > 
> >> After switching from go1.20.7 to go1.21.0 one of my applications
> >> compiles without warnings or errors, but fails at run-time with the
> >> following panic when loading a plugin:
> >>
> >> panic: regexp: Compile(`^([\w./]+)/((?:\w+)|[*])(.+)?$`): error parsing
> >> regexp: invalid escape sequence: `\w`
> >>
> >> goroutine 1 [running]:
> >> regexp.MustCompile({0x7fee026ddc4f, 0x1e})
> >> .../golang/src/regexp/regexp.go:319 +0xb4
> >> google.golang.org/grpc/internal/binarylog.init()
> >>
> >> .../ext/pkg/mod/
> >> google.golang.org/gr...@v1.57.0/internal/binarylog/env_config.go:135 
> 
> >> +0xf9
> >> plugin.open({0xc146b0, 0xe})
> >> .../golang/src/plugin/plugin_dlopen.go:95 +0x51c
> >> plugin.Open(...)
> >> .../golang/src/plugin/plugin.go:80
> >>
> >> The above regex compiles fine in go1.21.0 directly, so I wonder what is
> >> happening here.
> >>
> >> After switching back to 1.20.7 and a full recompilation, the application
> >> works fine again...
> >>
> >> Cheers, Bernd.
> >>
> >> --
> >> 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/d208fed7-dec3-8865-b332-1d693122edda%40hoi-polloi.org
> >> .
> >>
> > 
> > 
>
> -- 
> "Es sind nicht die besten Massen, die für Brot und Spiele den Verlust
> der Freiheit verschmerzen." (Kautsky, 1919, "Diktatur des Proletariats")
>
>

-- 
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/91198fba-a405-4eda-b6ed-0ab0fb1cf1a2n%40googlegroups.com.

[go-nuts] Re: Go 1.21.0 is released

[Marcello H]

https://go.dev/dl/go1.21.0.windows-arm64.zip

It is found when you click on "Other Ports"

Op dinsdag 8 augustus 2023 om 18:53:10 UTC+2 schreef Jan Mercl:

> On Tue, Aug 8, 2023 at 5:24 PM  wrote:
>
> > We have just released Go 1.21.0.
> >
> > To find out what has changed in Go 1.21, read the release notes:
> > https://go.dev/doc/go1.21
> >
> > You can download binary and source distributions from our download page:
> > https://go.dev/dl/#go1.21.0
>
> It looks like the download page is missing Go 1.21.0 for windows/arm64.
>

-- 
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/42ac6783-8f0a-435a-ab2f-f0c99b014a29n%40googlegroups.com.

Re: [go-nuts] Error handling

[Marcello H]

If I look at the following example:
```
err := io.Copy(w, r) *orelse* {
DoSomethingElse()
}
```
This can be written usually as:
```
if io.Copy(w, r) != nil {
DoSomethingElse()
}
```
which is LESS boilerplate. So only for the case when there is multiple
return values, there is some savings in typing.

```
result, err := makeSomeNoise() *orelse* {
DoSomethingElse()
}
```
vs
```
result, err := makeSomeNoise() if err != nil {
DoSomethingElse()
}
```
Ehm, this saves 16-9 = 7 keyboard entries.
If you ask me, this still reads consistent with the "normal" way we handle
errors.

What happens if all of a sudden, the makeSomeNoise returns 2 errors? Then
you have to undo the orelse construction, for what I understand.

The more I think of this, the more I like to type those extra keyboard
entries  to have a clear look about what happens in the program.

Just my 2 cents




Op di 1 aug 2023 om 03:31 schreef robert engels :

> For some perspective. Go’s error handling mimics C (for the most part).
> They had a decade to decide how to improve the error handling when they
> designed C++. They came up with exceptions. Java is C++ like. They had a
> decade to improve error handling. They came up with exceptions + throws.
>
> The Go designers do not want exceptions in any way shape or form, so
> you’re pretty much going to be stuck with what you have (all of the decent
> proposals are “exception like”- exceptions by another name) so learn to
> love it or use a different language.
>
> On Jul 30, 2023, at 2:02 AM, Brian Candler  wrote:
>
> Just to be clear: are you hard-coding the variable name "err" into the
> semantics of "orelse"?  That is, you can't assign the error return to a
> variable of any other name?
>
> I disagree that this makes the job of linters any easier than it is
> today.  For example, if you'd written
>
> ...
>err = io.Copy(w, r)
> err = w.Close() orelse return err
> }
>
> then you'd still need to detect "value assigned but not used" in the
> linter (assuming it doesn't become *compulsory* to use "orelse" on any
> assignment to a variable called "err")
>
> On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote:
>
>> I looked at the long list of proposals to improve error handling in go
>> but I have not seen the one I am describing below. If I missed a similar ,
>> can you pls direct me to where I can find it. If not what do you think of
>> this approach.
>>
>> This involves introducing a new keyword "orelse" that is a syntactic
>> sugar for an "if err!=nil" block.
>>
>> The example code in Russ Cox's paper[1] will look something like this:
>>
>> func CopyFile(src, dst string) error {
>> r, err := os.Open(src) orelse return err
>> defer r.Close()
>> w, err := os.Create(dst) orelse return err
>> defer w.Close()
>>   err = io.Copy(w, r) orelse return err
>> err = w.Close() orelse return err
>> }
>>
>> It is an error to not return an error from an orelse block.
>>
>> In my eyes, this has the same explicitness and flexibility of the current
>> style but is significantly less verbose. It permits ignoring the error,
>> returning it as is or wrapping it. Because orelse is not used for any other
>> purpose, it would be easy for reviewers and linters to spot lack of error
>> handling.
>>
>> It also works well with named returns. e.g.,
>>
>> func returnsObjorErro() (obj Obj, err error) {
>>   obj, err := createObj() orelse return  //returns nil and err
>> }
>>
>> otherwise orelse 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) orelse {
>>   
>>   return err
>> }
>>
>> Similarity to "else" hopefully means that it is easy to learn. It is
>> obviously backward compatible
>>
>> What do you think?
>>
>> [1]
>> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
>>
>
> --
> 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/330e88d9-8072-4614-ae56-8ce9c59517f3n%40googlegroups.com
> 
> .
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/dRLR4hxxI8A/unsubscribe.
> To unsubscribe from this group and all its topics, 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/60596671-D3AC-49D4-8575-F8EB3D9B6BF6%40ix.netcom.com
> 

[go-nuts] Re: Error handling

[Marcello H]

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 error values.  Which would orelse evaluate?  Even 
>>> if you arbitrarily chose one, that would violate the explicit vs implicit 
>>> code flow principle.  
>>>
>>> My sympathies, OP.  I too hate the "if err!= nil" boilerplate, and have 
>>> suggested my own idea for fixing it, which was similarly dismantled for 
>>> good reasons by those more knowledgeable than me.  The truth is, this 
>>> problem/issue has so many restrictions placed on it (currently idiomatic 
>>> principles, backwards compatibility promise, explicit vs implicit, etc) 
>>> that the set of possible solutions is VERY narrow, possibly infinitely so.
>>>
>>> On Sunday, July 30, 2023 at 3:51:49 PM UTC-4 Brian Candler wrote:
>>>
>>> err := io.Copy(w, r) *orelse* {
>>> w.Close()
>>> os.Remove(dst)
>>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>>> }
>>>
>>> My question still stands. Semantically, what value exactly does the 
>>> "orelse" condition test is not equal to nil?
>>>
>>> - does it test the value from the preceding assignment? If so, is 
>>> "orelse" only valid immediately following an assignment expression? The 
>>> original posting didn't say this.  And if it *is* linked to an assignment 
>>> expression which assigns multiple values, does it only look at the last 
>>> value? (Again, that was not specified)
>>>
>>> - does it always test a variable called "err"? The original posting said 
>>> it was equivalent to "if err!=nil" but a later post contradicted this
>>>
>>> - does it test the value from the 'return' expression at the end of the 
>>> block following orelse? Except in this case, it can't because it's buried 
>>> inside fmt.Errorf
>>>
>>> On Sunday, 30 July 2023 at 17:55:34 UTC+1 DrGo wrote:
>>>
>>> Good point Harri,
>>>
>>> This is what the correct version will look like using this proposal 
>>>
>>> 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)
>>> }
>>> }
>>>
>>> In a more complex func, the error formatting/handling code can be 
>>> further deduplicated by extracting it into a closure. 
>>> e.g., 
>>>
>>> func CopyFile(src, dst string) error {
>>> copyErr:= func(err error) {
>>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>>> } 
>>> r, err := os.Open(src) *orelse* return copyErr(err) 
>>> defer r.Close()
>>>
>>> w, err := os.Create(dst); *orelse* return copyErr(err)
>>> err := io.Copy(w, r) *orelse* {
>>> w.Close()
>>> os.Remove(dst)
>>> return copyErr(err)
>>> }
>>>
>>> err := w.Close() *orelse* {
>>> os.Remove(dst)
>>> return copyErr(err)
>>> }
>>> }
>>>
>>> On Sunday, July 30, 2023 at 8:17:31 AM UTC-6 Harri L wrote:
>>>
>>> IMHO, you have used the irrelevant example (== 2nd code block) from Russ 
>>> Cox's paper. The paper says:
>>> > This code is not nice, not clean, not elegant, *and still wrong:* 
>>> like the previous version, it does not remove dst when io.Copy or 
>>> w.Close fails.
>>>
>>> I want to compare your proposal with the third example from the paper, 
>>> which does (proper) error annotation and cleanup. Thanks.
>>> On Sunday, July 30, 2023 at 8:57:15 AM UTC+3 DrGo wrote:
>>>
>>> I looked at the long list of proposals to improve error handling in go 
>>> but I have not seen the one I am describing below. If I missed a similar , 
>>> can you pls direct me to where I can find it. If not what do you think of 
>>> this approach. 
>>>
>>> This involves introducing a new keyword "orelse" that is a syntactic 
>>> sugar for an "if err!=nil" block.
>>>

[go-nuts] Re: I made a CLI tool, and I'm curious about your ideas

[Marcello H]

No matter what other people say, as a first project, I think it is great 
because it gives you the opportunity to practise how a project is made.
I doubt if I would use it since it is done by hand almost at the same speed.
Also, I don't like the idea that it forces me into a certain layout.
So the idea I have, would be: if there's a configuration that will tell the 
application how the structure is created.
(Let's say, like some template which the user can adjust.)

Just my two cents, and please don't be bothered by my "negative" comments.
Op donderdag 13 juli 2023 om 22:35:16 UTC+2 schreef Sandesh Gade:

> Hi, 
>
> I am curious to know if you've evaluated whether there is any benefit to 
> your tool rather than just running  `go mod init projectName`?
> I don't see any improvements that the `gnt` tool brings to the table other 
> than an unnecessary wrapper/opinionated project layout/structure on top of 
> `go mod init`. 
>
> I am reminded of a Jeff Goldblum quote from the movie Jurassic Park, *"Your 
> Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t 
> Stop To Think If They Should"*
>
> On Thursday, July 6, 2023 at 12:13:31 PM UTC-4 Alper Akca wrote:
>
>>
>>
>> [image: gnt.png]
>> I am a beginner in Golang. I made a cli tool for creating a Go project. 
>> You can easily create a new Go project using the 'gnt create projectName' 
>> command. This command creates a 'bin', 'cmd/projectName/main.go' 
>> directories and the go module file. Those who are good at golang can give 
>> me ideas. GitHub repository link below:
>> https://github.com/lnxwizard/gnt
>>
>>

-- 
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/af8e0568-eb49-4a53-9b27-59285ad86040n%40googlegroups.com.

Re: [go-nuts] Help me study resources or guides

[Marcello H]

You could take a look at:
https://mehdihadeli.github.io/awesome-go-education/


Op dinsdag 23 mei 2023 om 14:33:18 UTC+2 schreef Zhang Jie (Kn):

> 1. https://go101.org, from beginner to true gopher
> 2. go perf book, search it from github, this will teach you some 
> optimization techniques
> 3. here's a reading list about golang internals: 
> https://hitzhangjie.notion.site/149643669e0846e6b8e3294d04a6df0d?v=e1cea88688ec4102ae5d9af8cf9ac4c7
> ,
> actually, there's some Chinese golang books that describe the 
> internals, like go语言设计实现，go语言原本. Even though they're good, but there's 
> already many good articles, I keep updating this reading list.
> 4. 100-go-mistakes, this book will show you common mistakes among gophers, 
> and it will make you understand golang better.
>
> On Wednesday, May 3, 2023 at 9:14:40 PM UTC+8 Kamil Ziemian wrote:
>
>> Hello,
>>
>> I now try to read "Go Language Specification", which you must read to 
>> became true Gopher. If you want to read this document, I offer all my help, 
>> but not overestimate me. Recently I even doubt if I'm programmer at all, 
>> maybe just advanced hobbyist.
>>
>> Because Go Spec my by too much for the begining I strongly advice you go 
>> trough all the "A Tour of Go".
>> https://go.dev/tour/welcome/1
>> "A Tour of Go" is easy, outside few excercise that need a background 
>> knowledge in things like networking. In any case, if you will have any 
>> question about "A Tour of Go" feel free to ask.
>>
>> One thing I think is worth of pointing out in the context of "A Tour of 
>> Go". When we talk about language itself, not its toolchain, there was only 
>> Big addition with big "B" to it since the version 1.0 was introduced in the 
>> 2012. By it I mean generics (or like Rob Pike call them more correctly: 
>> parametric polymorphism) introduced with Go 1.18 around February 2022. The 
>> part of "A Tour of Go" is that introduce generics is the only part that I 
>> don't like. It is too short and too sketchy for my taste.
>>
>> I learn quite a lot about generics reading proposal of them, at the time 
>> where was no implementation of them in the language, but I cannot these 
>> proposals as a learning materials. Ian Lance Taylor, which is one of the 
>> highest Go authorities in the world, once stated here that even the last 
>> proposal of generics isn't what is in the language, due to some changes 
>> make during the phase of implementation (at least this is what I understood 
>> from his words). Taylor said that if you know how generics works in Go, you 
>> should read Go Spec, which I currently doing. As a result, I cannot give 
>> you any point where to learn generics, since I still don't know if 
>> particular part of is appropriate for the beginners and I don't know an 
>> good ones at this moment. Maybe someone else can point to such good 
>> resource.
>>
>> At the bright side of things, I think generics are the last thing that 
>> you should learn in Go. They are important, but since are the last Addition 
>> with big "A" to the language, you should leave them to the end. At least in 
>> the my opinion.
>>
>> Best regards,
>> Kamil Ziemian
>> wtorek, 2 maja 2023 o 18:52:56 UTC+2 Rajesh Pandian napisał(a):
>>
>>> HI Nyilynn,
>>>
>>> I have watched Matt's Golang videos about concurrency and few others and 
>>> I have to say it is Brilliant!  I highly recommend it. (And Thank you Matt 
>>> for the brilliant content!!  )
>>>
>>> If you are interested in books then "Learning Go" from O'reilly was also 
>>> helpful to me. If you want start from absolute basic then "Head First Go" 
>>> is a good book too. I have all these two and the "The Go programming 
>>> language book which I frequently refer to as it's written by Brian W. 
>>> Kernighan and Alan A. A. Donovan which is a must have book if you reading 
>>> Go.
>>>
>>> And finally, practice and practise! As a Mandalorian would say "This is 
>>> the way" 
>>>
>>> Regards,
>>> Rajesh
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Friday, April 28, 2023 at 8:52:34 PM UTC+5:30 Matt KØDVB wrote:
>>>
 You can find my video class at 
 https://www.youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6; 
 people seem to like it

 Matt

 On Apr 26, 2023, at 9:45 PM, Nyilynn Htwe  wrote:

 I am starting to learn GO programming language with this course 
 . Can you all 
 guide me how to learn and how to be geek at Go? 
 Thank you for reading

 -- 
 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/e12e-c9c9-4481-b0eb-c33a6632b768n%40googlegroups.com
  
 

Re: [go-nuts] Redfining loop variable semantics - what's the plan?

[Marcello H]

The "scary" thing is, that if people don't have enough tests, they are 
probably not aware of such a bug, or can they still be aware somehow?

Op maandag 3 april 2023 om 20:19:33 UTC+2 schreef drc...@google.com:

> And if there is a problem, let us know.  Probably around the time 1.21 is 
> released we should write up "how to debug this problem if you see it" but 
> we've been working on the tools to automate the search if/when such a bug 
> appears.
>
> On Saturday, March 25, 2023 at 10:12:43 AM UTC-4 Eli Bendersky wrote:
>
>> On Sat, Mar 25, 2023 at 2:33 AM Amnon  wrote:
>>
>>> Thanks for a very succinct response.
>>>
>>> So if I understand the CL, there will be no change in behaviour in 1.21, 
>>> unless you set GOEXPERIMENT=loopvar
>>>
>>> - Amnon
>>>
>>
>> That's correct. You (and everyone else) can play with this GOEXPERIMENT 
>> in 1.21 (or now, if using gotip). The most useful thing to do would be to 
>> run your tests with this experiment set and see what breaks. 
>>
>> Looking towards the future, this is also related to the forward 
>> compatibility proposal: https://github.com/golang/go/issues/57001
>>
>> Eli
>>
>>
>>
>>  
>>
>>>
>>>
>>>
>>> On Saturday, 25 March 2023 at 06:56:23 UTC Sean Liao wrote:
>>>
 https://go.dev/issue/57969

 - sean

 On Sat, Mar 25, 2023, 06:45 Amnon  wrote:

> Hi Gophers,
> Last year there was a discussion about removing one of the 
> more common gotchas in Go.
>
> To quote from the discussion:
>
> the problem is that loops like this one don’t do what they look like 
> they do:
>
> var all []*Item
> for _, item := range items { all = append(all, ) } 
>
> That is, this code has a bug. After this loop executes, all contains 
> len(items) identical pointers, each pointing at the same Item, 
> holding the last value iterated over. This happens because the item 
> variable is per-loop, not per-iteration:  is the same on every 
> iteration, and item is overwritten on each iteration. 
> https://github.com/golang/go/discussions/56010
>
> What was the resolution of this discussion?
> Was the proposed change accepted?
> Will it be released in Go 1.21 or 1.22?
>
> It is hard to figure this out from the discussion. There are hundreds 
> of comments,
> but there is no clear marking of the resolution (apart from the 
> discussion now being closed) either at the top of bottom of the 
> discussion.
>
>
> -- 
> 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/5d88208e-fbbf-44d5-b693-50deff176fedn%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...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/aba5e0bd-c676-45f0-a7b7-ce6e23985124n%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/9e479270-3523-423f-9e69-fa7d821ec20dn%40googlegroups.com.

Re: [go-nuts] How to encode/decode string to binary in golang

[Marcello H]

You can also use gob for that.

Here are 2 functions from my library that can help.

import "encoding/gob"

/*
encodeGob encodes a model to gob bytes.
*/
func encodeGob(data any) ([]byte, error) {
var (
buf bytes.Buffer
enc = gob.NewEncoder() // Will write to network.
)

err := enc.Encode(data)

return buf.Bytes(), errors.Wrap(err, "encodeGob")
}

/*
decodeGob decodes gob bytes to a model.
*/
func decodeGob(decVal []byte, data any) (err error) {
buf := bytes.NewBuffer(decVal)
dec := gob.NewDecoder(buf)
err = dec.Decode(data)

return errors.Wrap(err, "decodeGob")
}

Op dinsdag 14 maart 2023 om 00:06:31 UTC+1 schreef robert engels:

> Am arbitrary byte can be encoded in 2 HEX characters - only a 2x increase 
> in size not 8x.
>
> On Mar 13, 2023, at 2:35 PM, Volker Dobler  wrote:
>
> On Monday, 13 March 2023 at 17:41:42 UTC+1 Van Fury wrote:
>
> Relating to my previous question, I have been reading but it is still not 
> clear to me what raw binary is, how is it different from
> text formatted binary (fmt.Sprintf("%b", s1s2Byte))?
>
> "text formated binary" takes a stream of bytes  and for each bit in
> this stream output "0" or "1" as letters, i.e. the bytes 48==0x30
> and 49==0x31. An eightfold blowup in size.
> Try understanding how _text_ is encoded as bytes.
>  
> Computers work on streams of bytes.
> The meaning/interpretation of a single byte can vary:
> Not all number can be stored in a single byte and
> text has to be encoded by bytes too.
> Please forget about "raw binary", there is no such thing.
> String variables are a stream of bytes and do not need any encoding,
> especially not something like "raw binary" that doesn't exist.
> A stream of bytes can be _printed_ (encoded) as decimal, hexadecimal,
> octal, base64 or even as bit ('0' and '1'). sometimes this is necessary
> because the underlying protocol cannot transmit possible byte values.
> When dealing with "binary" streams this cannot happen (it happens e.g.
> when using JSON to transmit data).
> You have to make clear what the output/encoding space should be
> (and why!): There is a inconsistency between wanting "binary" and
> a textual bit stream (which is not "binary" but text) and hexadecimal
> encoding (also not binary but text).
> You manoeuvred yourself in a corner by focusing on the solution
> instead of the actual problem.
>
> V.
>  
>
> In my problem above I need to encode s1+s2 to raw binary before sending 
> the result to the server
> which then decodes the raw binary back to s1+s2.
>
>
>
> On Mon, Mar 13, 2023 at 5:39 PM Van Fury  wrote:
>
> Do you mean encoding should be
> rawdata := fmt.Print("%016d%s%s", len(s1), s1,s2) 
> or
> rawdata := fmt.Printf("%016d%s%s", len(s1), s1,s2) 
>
>
>
> On Monday, March 13, 2023 at 4:36:50 PM UTC+2 Alex Howarth wrote:
>
> You might be looking for strconv.ParseUint() 
> https://pkg.go.dev/strconv#ParseUint
>
> https://go.dev/play/p/qAO9LfLD41D
>
> On Mon, 13 Mar 2023 at 07:24, Van Fury  wrote:
>
>
> Sorry I did not frame my question properly but what I would like to do is 
> to
> encode concatenated s1 and s2 into raw binary and then decode the raw 
> binary
> back to s1 and s2. 
>
>
> On Friday, March 10, 2023 at 11:36:09 PM UTC+2 Alex Howarth wrote:
>
> If s1 and s2 are a fixed length then you can just slice up the decoded 
> string based on the lengths. If they are of a variable length, you'll need 
> a separator in the input string to later split on when decoded (s3 := s1 + 
> ":" + s2 etc)?
>
> On Fri, 10 Mar 2023 at 10:33, Van Fury  wrote:
>
> Hi,
>
> I have two hexadecimal string values and would like to concatenate the two 
> strings and
>
>1. encode the result to binary
>2. decode the resulting binary back to hexadecimal string
>
> I did the following but I was finding it difficult to decode the result 
> back. I ignore error check in this case.
>
> What i did so far:
>
> s1 := "1d28ed66824aa2593e1f2a4cf740343f" 
>
> s2 := "dee2bd5dde763885944bc9d65419"
>
> s3 := s1 + s2 
>
> s1s2Byte, _ := hex.DecodeString(s3)
>
> randAutnBin := fmt.Sprintf("%b", s1s2Byte)
>
> result:
>
> [11101 101000 11101101 1100110 1010 1001010 10100010 1011001 10 
> 1 101010 1001100 0111 100 110100 11 1100 11100010 
> 1001 1011101 1100 1110110 111000 1101 10010100 1001011 11001001 
> 11010110 1010100 11001]
>
> I would like to decode the binary result back the hexadecimal string to 
> get s1 and s2.
>
> Any help?
>
> Van
>
> -- 
>
> 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/ad3a981b-cf22-47cd-9fe6-8db83a097b42n%40googlegroups.com
>  
> 
> .
>
>
> -- 
> You received 

[go-nuts] Re: Best way to mark unused parameters/error values reported by linter

[Marcello H]

This was not about false positives ;-)
Your choice, but the linter could still find a lot of good things in the 
code.
Anyway: you're not typing the comment only for yourself, but also for 
others to understand, right?

Op woensdag 8 maart 2023 om 12:38:20 UTC+1 schreef Carla Pfaff:

> If a linter reports false positives I don't use it. I would never uglify 
> my source code to please a linter.
>

-- 
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/6fab230b-0323-4532-8338-c698971d1a46n%40googlegroups.com.

[go-nuts] Re: Resolve the error

[Marcello H]

are you able to connect a database client to the same database?
To me, this message means:
- database is not running at 127.0.0.1:3306

But perhaps also look at the logs of the database itself

Op woensdag 8 maart 2023 om 15:19:43 UTC+1 schreef yeshwanthchowdary 
jampala:

> Hi sir/madam 
> I'm yeshwanth
> Im getting error from MySQL please correct it and if possible can you 
> connect me by any
>

-- 
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/c0ab90ef-6757-4145-bf05-7939e9e2a8b5n%40googlegroups.com.

Re: [go-nuts] Best way to mark unused parameters/error values reported by linter

[Marcello H]

The point I was making is not simply to ignore a linter outcome, but add
the reason behind it.

It might be a bad comment in your opinion, but that was not the point.

Op di 7 mrt 2023 om 18:42 schreef Kurtis Rader :

> On Mon, Mar 6, 2023 at 10:38 PM Marcello H  wrote:
>
>> What I do (and is a good practice), is adding behind the comment more
>> info.
>>
>> //nolint:errcheck // no need to test it, because it was tested before
>> with stat
>
>
> I appreciate that you're replying to what I hope is just a bad example but
> please, never do that. It's a security bug. And even without a malicious
> actor the path might change between the stat and the open. If you need to
> check some attributes of the file always open it first (and check that the
> open succeeded) then use the Stat method of the File object (
> https://pkg.go.dev/os#File.Stat).
>
>
>> Op maandag 6 maart 2023 om 23:05:42 UTC+1 schreef Steven Hartland:
>>
>>> I would use the following if I truly wanted to ignore an error, but I
>>> would question if ignoring the error from os.Open was ever a good idea.
>>> If you want to handle a file not found error then do so, don't just ignore
>>> the error.
>>> file, _ := os.Open(name) //nolint: errcheck
>>>
>>> On Mon, 6 Mar 2023 at 20:14, Sergei Dyshel  wrote:
>>>
>>>> Hello all,
>>>> I'm incorporating golangci-lint
>>>> <https://golangci-lint.run/usage/linters/> linter aggregator in my
>>>> codebase and facing a dilemma  on how to mark false positives for these 2
>>>> linters:
>>>>
>>>>- errcheck - reports unchecked errors.
>>>>- unparam - reports unused function parameters.
>>>>
>>>> The "official" way is to use special comment directives that make
>>>> linter ignore the line:
>>>>
>>>> func foo(
>>>> name string,
>>>> //nolint:unparam
>>>> age int,
>>>> ) {
>>>> //nolint:errcheck
>>>> file, _ := os.Open(name)
>>>> 
>>>>
>>>> Another, may be more portable way, would be using special functions
>>>> which do nothing:
>>>>
>>>> // defined in some library utilities package
>>>> func IgnoreErr(err error) {}
>>>> func Unused(a any) {}
>>>>
>>>> func foo(
>>>> name string,
>>>> age int,
>>>> ) {
>>>> Unused(age)
>>>> file, err := os.Open(name)
>>>> IgnoreErr(err)
>>>> ...
>>>>
>>>> What do you think the proper/idiomatic/better way among these two?
>>>>
>>>> --
>>>> 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/6fc8a933-b68c-4e07-a4ee-98c4fe01ba8dn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/6fc8a933-b68c-4e07-a4ee-98c4fe01ba8dn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>> 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/26a4f5d9-f590-4d40-a333-d0bfbe191ca3n%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/26a4f5d9-f590-4d40-a333-d0bfbe191ca3n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> 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/CADBSaR3gvCMdyKRSSfiPMO9S95cd9TphSkNKaAPSEskFsRLP0A%40mail.gmail.com.

Re: [go-nuts] Best way to mark unused parameters/error values reported by linter

[Marcello H]

What I do (and is a good practice), is adding behind the comment more info.

//nolint:errcheck // no need to test it, because it was tested before with 
stat

Op maandag 6 maart 2023 om 23:05:42 UTC+1 schreef Steven Hartland:

> I would use the following if I truly wanted to ignore an error, but I 
> would question if ignoring the error from os.Open was ever a good idea. 
> If you want to handle a file not found error then do so, don't just ignore 
> the error.
> file, _ := os.Open(name) //nolint: errcheck
>
> On Mon, 6 Mar 2023 at 20:14, Sergei Dyshel  wrote:
>
>> Hello all,
>> I'm incorporating golangci-lint 
>>  linter aggregator in my 
>> codebase and facing a dilemma  on how to mark false positives for these 2  
>> linters:
>>
>>- errcheck - reports unchecked errors.
>>- unparam - reports unused function parameters.
>>
>> The "official" way is to use special comment directives that make linter 
>> ignore the line:
>>
>> func foo(
>> name string,
>> //nolint:unparam
>> age int,
>> ) {
>> //nolint:errcheck
>> file, _ := os.Open(name)
>> 
>>
>> Another, may be more portable way, would be using special functions which 
>> do nothing:
>>
>> // defined in some library utilities package
>> func IgnoreErr(err error) {}
>> func Unused(a any) {}
>>
>> func foo(
>> name string,
>> age int,
>> ) {
>> Unused(age)
>> file, err := os.Open(name)
>> IgnoreErr(err)
>> ...
>>
>> What do you think the proper/idiomatic/better way among these two?
>>
>> -- 
>> 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/6fc8a933-b68c-4e07-a4ee-98c4fe01ba8dn%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/26a4f5d9-f590-4d40-a333-d0bfbe191ca3n%40googlegroups.com.

[go-nuts] Re: Reading .xls file with golang

[Marcello H]

or use another library ;-)
https://github.com/plandem/xlsx
https://github.com/qax-os/excelize

-- 
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/1c570b59-00cb-4683-a349-67e883af4891n%40googlegroups.com.

[go-nuts] Re: Go, VSCODE IDE, Delve debugger: am having problem debugging my console app

[Marcello H]

You could try to debug it from within VSC.

Op donderdag 9 februari 2023 om 15:19:24 UTC+1 schreef Daniel Jankins:

> Hi,  I can not get the console app to run with the debugger.  When I start 
> the debugger I do not get the console display only 
>
> Starting: C:\Users\djankins\go\bin\dlv.exe dap --listen=127.0.0.1:52239 
> from c:\Users\djankins\Repositories\UT\adpf-simulation\GUI
> DAP server listening at: 127.0.0.1:52239
> Type 'dlv help' for list of commands.
>
>
> On Wednesday, January 31, 2018 at 12:50:02 AM UTC-5 evan wrote:
>
>> i can debug my web app server code with no problem with the Go, VSCODE, 
>> and Delve setup.
>>
>> the client connecting to that web app is a console app, which primarily 
>> does the following:
>>
>> gets json data from the server, stuffs the data into the table widget of 
>> the terminal user interface (3rd party Go package) for display, lets users 
>> edit the data, etc
>>
>> the console app runs fine when i go run client.go. but when i want to 
>> debug the code, the client app doesn't show up :-)
>>
>> so i'm currently forced to log println's out to a file so i can keep 
>> moving forward.
>>
>> any suggestion what i can do so that i can start up my console app in 
>> debug mode and when it shows up, interact with it until i get to preset 
>> breakpoints, etc (or other set of steps that might work)?
>>
>> i'm working in a windows 10 development machine, go version 1.9.2, and 
>> VSCODE 1.19.3
>>
>> thanks for any help!
>>
>

-- 
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/cd495fef-49f7-4485-b1ad-6453d53c5578n%40googlegroups.com.

Re: [go-nuts] Re: memory issues

[Marcello H]

You could actually make a stress test inside a main_test.go with a
benchmark for example, run that locally and see.

It works over here btw.

package main_test

import (
"net/http"
"net/http/httptest"
"testing"

"github.com/gorilla/mux"
"github.com/stretchr/testify/assert"
)

func pingServer(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("pong"))
}

func Router() *mux.Router {
router := mux.NewRouter()
router.HandleFunc("/ping", pingServer).Methods("GET")
return router
}

func Test_Ping(t *testing.T) {
r, _ := http.NewRequest("GET", "/ping", nil)
w := httptest.NewRecorder()

Router().ServeHTTP(w, r)

assert.Equal(t, 200, w.Code, "OK response is expected")
}

func Benchmark_Ping(b *testing.B) {
r, _ := http.NewRequest("GET", "/ping", nil)
w := httptest.NewRecorder()

b.ResetTimer()

for i := 0; i < b.N; i++ { // use b.N for looping
Router().ServeHTTP(w, r)
assert.Equal(b, 200, w.Code, "OK response is expected")
}
}


Op vr 10 feb. 2023 om 00:47 schreef James Dornan :

> I did, with the same results.
>
> I've attached stack trace from docker logs and the files to recreate this
> issue, Dockerfile and main.go.
>
> Steps to recreate
> docker build -t pingtest .
>
> docker run -p 8001:80 pingtest
>
> ab -c 500 -n 5  http://localhost:8001/ping
>
> The result for my, from ab, was this.
> ab -c 500 -n 5  http://10.1.1.101:8001/ping
>
>─╯
> This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
>
> Benchmarking 10.1.1.101 (be patient)
>
> Test aborted after 10 failures
>
> apr_socket_connect(): Connection reset by peer (104)
> Total of 366 requests completed
>
> On Thursday, February 9, 2023 at 3:02:08 AM UTC-5 Marcello H wrote:
>
>> I would trim down the problem, by making a very small program that gets
>> the XML file from a local disk and then just do the XSLT on it.
>> That would give you less environment to oversee and debug.
>> Perhaps then, make the xml as small as possible.
>> Also mention which libs you use or make a playground version of the
>> problem, so people might be able to understand more about the problem.
>>
>> Op donderdag 9 februari 2023 om 00:03:03 UTC+1 schreef James Dornan:
>>
>>> I have a go web service that acts as a proxy that gets XML documents
>>> from a remote system and processes them through XSLT, returning the result,
>>> if any. I have tried a number of options over the last few days and cannot
>>> seem to nail down the cause.
>>>
>>> Does anyone know how to address this or debug the issue? Thanks.
>>>
>>> Version 1.20 (on Alpine Linux 3.17)
>>>
>>> Build statement
>>>
>>> go build \
>>> -tags musl \
>>>  -ldflags '-extldflags "-static -lz -llzma -lgcrypt -lgpg-error"' \
>>> -gcflags=all="-wb=false -d=checkptr" \
>>>   -a  main.go
>>>
>>> runtime: marked free object in span 0x7f58c3422308, elemsize=96
>>> freeindex=3 (bad use of unsafe.Pointer? try -d=checkptr)
>>> 0xc000398000 alloc marked
>>> 0xc000398060 alloc marked
>>> 0xc0003980c0 alloc marked
>>> 0xc000398120 free  unmarked
>>> 0xc000398180 free  unmarked
>>> 0xc0003981e0 free  unmarked
>>> 0xc000398240 alloc marked
>>> 0xc0003982a0 alloc marked
>>> 0xc000398300 free  unmarked
>>> 0xc000398360 alloc marked
>>> 0xc0003983c0 alloc marked
>>> 0xc000398420 alloc marked
>>> 0xc000398480 free  unmarked
>>> 0xc0003984e0 free  unmarked
>>> 0xc000398540 free  unmarked
>>> 0xc0003985a0 free  unmarked
>>> 0xc000398600 free  unmarked
>>> 0xc000398660 free  unmarked
>>> 0xc0003986c0 free  unmarked
>>> 0xc000398720 free  unmarked
>>> 0xc000398780 free  unmarked
>>> 0xc0003987e0 alloc marked
>>> 0xc000398840 alloc marked
>>> 0xc0003988a0 free  unmarked
>>> 0xc000398900 free  unmarked
>>> 0xc000398960 free  unmarked
>>> 0xc0003989c0 free  unmarked
>>> 0xc000398a20 free  unmarked
>>> 0xc000398a80 free  unmarked
>>> 0xc000398ae0 free  unmarked
>>> 0xc000398b40 free  unmarked
>>> 0xc000398ba0 free  unmarked
>>> 0xc000398c00 free  unmarked
>>> 0xc000398c60 free  unmarked
>>> 0xc000398cc0 free  unmarked
>>> 0xc000398d20 free  unmark

[go-nuts] Re: memory issues

[Marcello H]

I would trim down the problem, by making a very small program that gets the 
XML file from a local disk and then just do the XSLT on it.
That would give you less environment to oversee and debug.
Perhaps then, make the xml as small as possible.
Also mention which libs you use or make a playground version of the 
problem, so people might be able to understand more about the problem.

Op donderdag 9 februari 2023 om 00:03:03 UTC+1 schreef James Dornan:

> I have a go web service that acts as a proxy that gets XML documents from 
> a remote system and processes them through XSLT, returning the result, if 
> any. I have tried a number of options over the last few days and cannot 
> seem to nail down the cause.
>
> Does anyone know how to address this or debug the issue? Thanks.
>
> Version 1.20 (on Alpine Linux 3.17)
>
> Build statement
>
> go build \
> -tags musl \
>  -ldflags '-extldflags "-static -lz -llzma -lgcrypt -lgpg-error"' \
> -gcflags=all="-wb=false -d=checkptr" \
>   -a  main.go
>
> runtime: marked free object in span 0x7f58c3422308, elemsize=96 
> freeindex=3 (bad use of unsafe.Pointer? try -d=checkptr)
> 0xc000398000 alloc marked
> 0xc000398060 alloc marked
> 0xc0003980c0 alloc marked
> 0xc000398120 free  unmarked
> 0xc000398180 free  unmarked
> 0xc0003981e0 free  unmarked
> 0xc000398240 alloc marked
> 0xc0003982a0 alloc marked
> 0xc000398300 free  unmarked
> 0xc000398360 alloc marked
> 0xc0003983c0 alloc marked
> 0xc000398420 alloc marked
> 0xc000398480 free  unmarked
> 0xc0003984e0 free  unmarked
> 0xc000398540 free  unmarked
> 0xc0003985a0 free  unmarked
> 0xc000398600 free  unmarked
> 0xc000398660 free  unmarked
> 0xc0003986c0 free  unmarked
> 0xc000398720 free  unmarked
> 0xc000398780 free  unmarked
> 0xc0003987e0 alloc marked
> 0xc000398840 alloc marked
> 0xc0003988a0 free  unmarked
> 0xc000398900 free  unmarked
> 0xc000398960 free  unmarked
> 0xc0003989c0 free  unmarked
> 0xc000398a20 free  unmarked
> 0xc000398a80 free  unmarked
> 0xc000398ae0 free  unmarked
> 0xc000398b40 free  unmarked
> 0xc000398ba0 free  unmarked
> 0xc000398c00 free  unmarked
> 0xc000398c60 free  unmarked
> 0xc000398cc0 free  unmarked
> 0xc000398d20 free  unmarked
> 0xc000398d80 free  unmarked
> 0xc000398de0 free  unmarked
> 0xc000398e40 free  unmarked
> 0xc000398ea0 free  unmarked
> 0xc000398f00 alloc marked
> 0xc000398f60 free  unmarked
> 0xc000398fc0 alloc marked
> 0xc000399020 alloc marked
> 0xc000399080 free  unmarked
> 0xc0003990e0 free  unmarked
> 0xc000399140 alloc marked
> 0xc0003991a0 alloc marked
> 0xc000399200 alloc marked
> 0xc000399260 free  unmarked
> 0xc0003992c0 free  unmarked
> 0xc000399320 free  unmarked
> 0xc000399380 free  unmarked
> 0xc0003993e0 free  unmarked
> 0xc000399440 free  unmarked
> 0xc0003994a0 free  unmarked
> 0xc000399500 free  unmarked
> 0xc000399560 free  unmarked
> 0xc0003995c0 free  unmarked
> 0xc000399620 alloc marked
> 0xc000399680 free  unmarked
> 0xc0003996e0 free  marked   zombie
> 0x00c0003996e0:  0x00c000104b60  0x
> 0x00c0003996f0:  0x  0x
> 0x00c000399700:  0x  0x
> 0x00c000399710:  0x0100  0x
> 0x00c000399720:  0x  0x
> 0x00c000399730:  0x  0x
> 0xc000399740 free  unmarked
> 0xc0003997a0 alloc marked
> 0xc000399800 alloc marked
> 0xc000399860 free  unmarked
> 0xc0003998c0 free  unmarked
> 0xc000399920 free  unmarked
> 0xc000399980 free  unmarked
> 0xc0003999e0 free  unmarked
> 0xc000399a40 free  unmarked
> 0xc000399aa0 free  unmarked
> 0xc000399b00 free  unmarked
> 0xc000399b60 free  unmarked
> 0xc000399bc0 free  unmarked
> 0xc000399c20 free  unmarked
> 0xc000399c80 free  unmarked
> 0xc000399ce0 free  unmarked
> 0xc000399d40 free  unmarked
> 0xc000399da0 free  unmarked
> 0xc000399e00 free  unmarked
> 0xc000399e60 free  unmarked
> 0xc000399ec0 free  unmarked
> 0xc000399f20 free  unmarked
> 0xc000399f80 free  unmarked
> fatal error: found pointer to free object
>
> runtime stack:
> runtime.throw({0x84f468?, 0xc000399740?})
> /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7f589bc43780 
> sp=0x7f589bc43750 pc=0x4357fd
> runtime.(*mspan).reportZombies(0x7f58c3422308)
> /usr/local/go/src/runtime/mgcsweep.go:846 +0x2e5 fp=0x7f589bc43800 
> sp=0x7f589bc43780 pc=0x424d25
> runtime.(*sweepLocked).sweep(0x7f589bc43928?, 0x0)
> /usr/local/go/src/runtime/mgcsweep.go:634 +0x9f6 fp=0x7f589bc438f0 
> sp=0x7f589bc43800 pc=0x424696
> runtime.(*mcentral).uncacheSpan(0x7f589bdf73b8?, 0xc00029a000?)
> /usr/local/go/src/runtime/mcentral.go:228 +0xa5 fp=0x7f589bc43918 
> sp=0x7f589bc438f0 pc=0x416da5
> runtime.(*mcache).releaseAll(0x7f58c34173c8)
> /usr/local/go/src/runtime/mcache.go:291 +0x145 fp=0x7f589bc43980 
> sp=0x7f589bc43918 pc=0x416805
> runtime.(*mcache).prepareForSweep(0x7f58c34173c8)
> /usr/local/go/src/runtime/mcache.go:328 

[go-nuts] Re: 'go run hello.go' taking ~30 seconds on windows

[Marcello H]

It can also be something to exclude the tmp directory in which Go compiles 
when you do a 'go run'
(I assume you meant that when saying 'build and run')

What happens if you just build?
- Is this slow
what happens if you just execute?
- Is this slow?

What happens if you go install some-tool and run that?
- is that slow?

Op woensdag 14 december 2022 om 21:03:26 UTC+1 schreef thepud...@gmail.com:

> Hi Declan,
>
> Virus scanners can slow things down significantly on Windows, including 
> virus scanners can go into overdrive if you are touching many files, 
> touching files with atypical extensions, or building and then immediately 
> executing a new binary.
>
> To start, you could try temporarily disabling your virus scanner and see 
> if it helps.
>
> If it does help, you might be able to benefit from finer grain changes. 
> Most virus scanners support exclusion lists if you have sufficient 
> privileges. You could try for example excluding (1) the directories with 
> your Go code, (2) the directory shown in 'go env GOCACHE', (3) possibly the 
> directory shown in 'go env GOMODCACHE', and possibly others.
>
> I would be curious to hear your results.
>
> Even if this is not the particular problem you hit, it is something other 
> gophers hit, and it would be nice to document this somewhere if it isn't 
> already.
>
> Separately, I thought that Rust for example would add some default 
> exclusions for Windows Defender, which could be an option for the Go 
> Windows installer. However, I'm not seeing that just now based on some 
> quick spot checking, so maybe that's something Rust only used to do, or 
> perhaps I am thinking of something else.
>
> Finally, especially if you are in a corporate environment, there can be 
> other security agents, network services, proxies, and other agents that can 
> interfere with development performance beyond virus scanners.
>
> Regards,
> thepudds
>
> On Wednesday, December 14, 2022 at 12:57:40 PM UTC-5 Declan Finn wrote:
>
>> Hi,
>>
>> Platform: Windows 10
>> Go Version: 1.19.4
>>
>> Compile and run of the most basic helloworld program is extremely slow on 
>> my windows machine, taking roughly 30 seconds every time.
>> Whereas the exact same program, using the same go version, compiles and 
>> runs in under 1 second on my Ubuntu machine.
>> Why is it so slow on windows?
>> I asked a collogue to do the same test on his windows machine and he sees 
>> the same slowness.
>> Any help would be greatly appreciated.
>>
>>
>>

-- 
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/13d8ed63-2d9a-4852-9ac7-ce0c0215a553n%40googlegroups.com.

Fwd: [go-nuts] Linting

[Marcello H]

Sorry, but I didn't state (and so does the linter) that any code is
deficient.
Normal usage of a linter is not to satisfy a linter, but to do some basic
code review.
(Most new linters can skip certain code lines these days too.)

I know that  the number of lines in a single function is just a matter of
taste.
But I also know that a function with too many lines is also harder to
maintain.
If you study those functions that are "too long", you will find that it
could probably be split up in a more readable and maintainable way.

The only worry I have is that complex code is very hard to maintain,
perhaps only by a single person.
What happens if that person isn't available anymore? The best time to
maintain code to  a more maintainable version, is at the moment of creation
or not much later,
because only then it lives still "in the mind" of the creator. A linter can
help detect those "blindspots" of a developer and can point out where those
are.

With the new guidelines, one can expect to see the Go code as an example of
those guidelines.
(one of them being maintainable software)

Does anybody have to fix all of it now? Of course not, but perhaps when a
developer is touching one of those functions and understands what it does,
then it is still the ideal time to rewrite it a bit.

But perhaps I'm just a sucker for quality and maintainability and I'm
barking up the wrong tree.
I very much want Go to survive, so for me that means that people should not
be afraid to maintain parts of the code.
(and that's why I said not to touch all those high complexity parts,
because I find it highly confusing; so i'm not fit for that job.)

Op wo 14 dec. 2022 om 23:33 schreef Amnon :

> This long discussion started with the question why the Go source is not
> linted.
> But I think the OP has answered his own question by providing us with a
> list of 963 places
> where the linter has decided that the code is deficient.
> But what is notable, is that he has not given a single example where any
> of these 963 warning has any value.
> He has not taken even one of these warnings and show how "fixing" it leads
> to better code.
> 411 of these warnings are for functions which are longer than the 150
> lines which are "allowed".
> So I would ask: "allowed by whom?"
> I am a big fan of short functions, as are the authors of the Go standard
> library. But surely the optimal length of a function depends
> on the context. I am not too bothered, about the length of functions in
> the output of code generation, for instance. And I am OK with
> code with a very regular structure - like a switch statement handling many
> cases to take many lines.
> Some of these linters do seem to be quite bureaucratic - imposing
> arbitrary rules irrespective of whether they make sense in the actual
> context.
> Code written in corporations (because it usually is in corporations) where
> these linters are imposed, have a particular smell, with all kinds
> of convolutions and ugliness designed to appease the linter.
> If you see code where every line begins with
>
> _, _ =
>
> Or where you always see
>
> defer func() { _ = res.Body.Close())()
>
> rather that
>
>defer res.Body.Close()
>
> you know that this is the product of a programmer toiling under the
> dictates of a linter.
> Because if you are discussing some code with a knowledgeable reviewer, you
> can defend your decisions.
> You can explain why writing to a byte.Buffer can not fail (unless we are
> out of memory, in which case any error
> handling will fail too). But if you are told off by a linter, there is no
> appeal. The linter has no discretion.
> It is not open to discussion. It will not consider your arguments. Your
> job is to do what the linter tells you.
> Because the linter is always right. Because the computer is always right.
> And you, as a mere human, are always wrong.
>
> I would say that go vet is an exception - its warnings almost always point
> to real problems in the correctness of code,
> or unnecessary complexity. I often also run staticcheck on my own code. It
> often makes useful observations, some of which
> lead to useful changes. But beyond these two, linters often do more harm
> than good. One very high quality linter with
> few false positives is far more valuable that a large number of linters
> which make nonsensical complaints.
> golangci_lint is particularly bad in this respect - making it easy to run
> loads of low quality linters, which cry wolf all the time and
> train programmers to ignore warnings.
>
> So I would appeal Ian and the rest of the Go team, to resist the pressure
> to adopt these "great linters" - not to invest months of work
> "fixing" these 963 "problems" identified by these linters. And focus on
> carrying on doing what you are doing - producing,
> rocks solid releases, well thought out enhancements, and code which can
> serve as a template we can all emulate
> to produce good, clear, idiomatic code.
>
>
> On Tuesday, 13 December 2022 

Re: [go-nuts] Linting

[Marcello H]

I have no complaints, let me be clear about that. Just advice, for all I've
learned in my cariere is that maintenance is happening more than the first
version of something creative.
But I've still got hope that one day I might understand some complex coding
that I didn't write myself.

I'm happy to help, if an author of something "complex" can guide me. The
only thing I can do now, is be a messenger.


Op di 13 dec. 2022 om 20:52 schreef Ian Lance Taylor :

> On Tue, Dec 13, 2022 at 2:31 AM Brian Candler  wrote:
> >
> > With that in mind, I'd respectfully suggest that your starting point
> should be to pick one of these "over complex" functions, understand it
> fully, and rewrite it in what you consider to be a simpler/clearer way
> which does not break any functionality, *and* which does perform any worse
> than the original code (*).  Then you can submit it as a pull request for
> review.  Rinse and repeat.
>
> With respect, I'm going to suggest not doing that.  If code is working
> correctly, then changing it, even to simplify it, may cause it to stop
> working correctly.  In fact, this is more likely to happen if the
> original code is complex.  The best approach to complex working code
> is to only change it if there is a good reason to do so: because the
> requirements have changed, or because there is some way to make it run
> measurably faster, or because it is a regular source of bugs.
>
> Also I hope we can all agree that blind adherence to any specific
> definition of complexity is misguided.  For example, a function that
> is basically a big switch statement with a bunch of cases is often
> easier to understand as a single function rather than a collection of
> different ones.  I hope we can all agree that reducing the number of
> code complexity reports to zero is not a goal.  I'll note that the
> list of complaints here seems to me to be biased toward breaking up
> large functions into smaller functions.  In some cases that can make
> the code easier to understand.  In other cases it does not.  Judgement
> is required.
>
> Ian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/MM3W5oNw4-0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAOyqgcXGWbAEVy89cMFXmwS-%3DPYZ%3D6NEYQ-i6NnzyfMmZ8W7MA%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/CADBSaR3U11nDPwHZcSiV7R%3DTtndjUycO_ir76h-R5OjJWxGOAA%40mail.gmail.com.

Re: [go-nuts] Linting

[Marcello H]

I totally understand that you put the ball back to me. My message is not to
blame anybody and I think I didn't do that. People might be offended, but
I'm just the messenger.
The trick is, if we want software to survive, we should always check if it
is understandable and maintainable and that is my message.
The people who were willing to write solutions for complex problems are
really awesome, because they also made Go the way it is today.
But what happens if such a person is not able to do that anymore? Would
others still comprehend what the original author had meant to do?
We can be ahead of that, by looking at useful insights, like code
complexity or number of lines that will give us hints about what could be
improved.

I've said before, I want to help, but won't touch overly complex code.
Because for me it's a waste of time understanding the code,
while the original author can probably fix it in a breeze.
(This is why linting regularly is so important: it will warn the author
something is off.)

I really hope nobody is offended and keeps up the good work.






Op di 13 dec. 2022 om 11:31 schreef Brian Candler :

> I'd say that in an entire programming language and runtime environment
> like Go, there is much which is inherently complex.  Just think about
> things like garbage collection <https://blog.golang.org/ismmkeynote> and
> asynchronous preemption.  A linter which creates dumb metrics like "number
> of lines of code in a function" is unable to appreciate the semantics of
> what is required to perform the job.
>
> Also consider that what you are saying *could* be construed as an insult
> to the incredibly clever and dedicated people who have worked on this for
> years. The implication is "you're not doing a very good job", or "why
> didn't you think of using a tool like this?" (duh!)
>
> With that in mind, I'd respectfully suggest that your starting point
> should be to pick one of these "over complex" functions, understand it
> fully, and rewrite it in what you consider to be a simpler/clearer way
> which does not break any functionality, *and* which does perform any worse
> than the original code (*).  Then you can submit it as a pull request for
> review.  Rinse and repeat.
>
> (*) Even marginal performance regressions are going to hurt somebody
> somewhere.  There's much history in github issues that is worth reading -
> just search for "bench" or "benchmark".
>
> On Tuesday, 13 December 2022 at 08:48:34 UTC marc...@gmail.com wrote:
>
>> Ok, I made a list with functions that are hard to understand because of
>> the complexity. This is a calculated cognitive code complexity, but it
>> serves me quite well when doing code reviews.
>> The author of such a function might think that it's pretty easy to
>> understand, but code complexity is how others look at code.
>> (code ideally is maintainable by others as well)
>>
>> Following the "Go Style Guide", it should have Clarity, Simplicity, etc.
>>
>> I've put the threshold at 25 (which I normally have at 12). So everything
>> above a complexity of 25 is reported.
>>
>> I also think that functions with a higher number of lines are also harder
>> to understand, maintain etc.
>> I've put the threshold at 150 (which I normally have at 50). So
>> everything above 150 lines is reported.
>>
>> Both lists are attached, but what should I do with them?
>>
>>
>>
>>
>> Op zo 11 dec. 2022 om 21:42 schreef Ian Lance Taylor :
>>
>>> On Sun, Dec 11, 2022, 2:03 AM Marcello H  wrote:
>>>
>>>> Ok, but does my answer really matter? Because in the end it's what any
>>>> linter will tell us about the software.
>>>> And since it is not hard to do, my suggestion always is to make use of
>>>> some of the great linters that exist.
>>>>
>>>> In a new project I always start off with all the linters (in
>>>> golangci_lint) active, and then deactivate the ones that I don't want.
>>>> You can also do it the other way around, just a matter of "how to begin
>>>> with linting".
>>>> The advantage of using some linter would be that it is also a kind of
>>>> quality fixation on the code.
>>>> Perhaps deciding on which linter(s) to use at first and then slowly
>>>> "inject" more.
>>>>
>>>> This post is not about finger-pointing btw, because if needed, I would
>>>> offer my help with this.
>>>> But I won't touch the functions with the high cognitive complexity ;-)
>>>>
>>>
>>> We do use a linter on the Go standard library: go vet

Re: [go-nuts] Refresher tutorial

[Marcello H]

https://mehdihadeli.github.io/awesome-go-education/

Op zondag 11 december 2022 om 00:10:03 UTC+1 schreef Ken MacDonald:

> Thanks, Sean & Eli for the recommendations- I’ll check them out. - Ken
>
> Sent from my iPad
>
> On Dec 10, 2022, at 1:01 PM, 'Sean Liao' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> 
>
> consider something like https://learnxinyminutes.com/docs/go/
> if you just need a brief refresher on syntax/core concepts
>
> - sean
>
> On Sat, Dec 10, 2022, 17:17 Ken  wrote:
>
>> Hi, when I first learned golang, there was a nice tutorial avaiable. I’m 
>> in need of a refresher as I haven’t used it in quite a while, but know 
>> there are 100’s of tutorials. Would like to find a recommended one where I 
>> could quickly brush up on functionality and syntax. Thanks! Ken
>>
>> Sent from my iPhone
>>
>> -- 
>> 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/18BE6E52-574A-47D8-BFC7-CF9779F535DD%40gmail.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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAGabyPoea2yS0UW0EVQRHvXP8%2B7fNZq3nkM%3DoTSU5nisOkP3tQ%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/fcff94dd-3442-469a-858a-4c7aaff44bb9n%40googlegroups.com.

Re: [go-nuts] Linting

[Marcello H]

Ok, but does my answer really matter? Because in the end it's what any
linter will tell us about the software.
And since it is not hard to do, my suggestion always is to make use of some
of the great linters that exist.

In a new project I always start off with all the linters (in golangci_lint)
active, and then deactivate the ones that I don't want.
You can also do it the other way around, just a matter of "how to begin
with linting".
The advantage of using some linter would be that it is also a kind of
quality fixation on the code.
Perhaps deciding on which linter(s) to use at first and then slowly
"inject" more.

This post is not about finger-pointing btw, because if needed, I would
offer my help with this.
But I won't touch the functions with the high cognitive complexity ;-)

Op za 10 dec. 2022 om 22:34 schreef 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com>:

> On Sat, 2022-12-10 at 14:44 +0100, Marcello H wrote:
> > golangci_lint ...
> >
> > Op za 10 dec. 2022 om 13:17 schreef Brian Candler
> > :
> > > The question remains, which linter(s) are you using?
>
> golangci_lint is not really an answer to this question since it's just
> a collection of linters, many of which have arguable utility/value.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/MM3W5oNw4-0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/9827b253f9d8cc8c821874675adad2130612060e.camel%40kortschak.io
> .
>

-- 
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/CADBSaR08GT4U2q0pMq%2BxNuHaWNZPmNY4%3DKh_nYrczjcVmYQnZA%40mail.gmail.com.

Re: [go-nuts] Linting

[Marcello H]

golangci_lint and my own (for the cognitive code complexity)

Op za 10 dec. 2022 om 13:17 schreef Brian Candler :

> The question remains, which linter(s) are you using?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/MM3W5oNw4-0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/bd99406a-130d-4405-bbc6-4ff6ef37eca9n%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/CADBSaR3t31DJiYQ5o9YkyQAtqNfwsCaMsR%2BYZ6L2KAf%2BOKVWHg%40mail.gmail.com.

Re: [go-nuts] Linting

[Marcello H]

I agree that not all linting is useful, but when I see certain outcome that 
is questionable, I would be investigating that a bit more if it was my code.
For example:
There is code that uses deprecated functionality, that could easily be 
changed to the newer version of that.

There are:
- lots of ineffective assigns to be found (which means for some occasions 
extra work for nothing)
- structs that could be made more memory efficient
- type assertions that should be checked
- unnecessary conversions
- parts with unchecked errors
- parts that have a high cognitive code complexity
  > for example "go/src/cmd/compile/internal/ssa/regalloc.go"
  func (s *regAllocState) regalloc(f *Func)
  who can read this?

So yes, linters can be useful as well

Op zaterdag 10 december 2022 om 10:30:00 UTC+1 schreef Brian Candler:

> On Friday, 9 December 2022 at 19:09:34 UTC Ian Lance Taylor wrote:
>
>> 1) Linters are optional and opinionated, and it kind of matters which 
>> linter you mean.
>
>
> And of course, go itself already comes with the grandaddy of all linters - 
> "go vet ".
>

-- 
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/cad99b3b-be54-4cfc-8699-edd42f01423cn%40googlegroups.com.

[go-nuts] Linting

[Marcello H]

Since we have great linters, I wonder why it seems that the Go source
itself isn't linted?
(Because when I do lint it, I see a lot of suggested improvement)

-- 
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/CADBSaR2Z2QfnLR7tfcfBYtH8Ltwk59n2PP%2BWdqOaEWpdQUsmmA%40mail.gmail.com.

[go-nuts] Re: Hide Golang Code from Exported package

[Marcello H]

if you produce an executable, nobody sees the actual Go code.
build it with:
go build -ldflags "-s -w"

or you could try to obfuscate it:
https://github.com/burrowers/garble

or you can make a self-extracting executable


Op woensdag 7 december 2022 om 19:09:31 UTC+1 schreef nsing...@gmail.com:

> Hi All,
> We are looking for a way to distribute a Golang Package. but We ant to 
> hide the Code which we have written. 
> We went Through Creating A DLL to distribute but it crashes at different 
> point while running. As we have distribute to Both linux and windows . And 
> i found that for linux we can use plugin. But the crash for windows dll  
> after importing the file is concerning for us and its happening at random 
> points in the code also "bad sweepgen in refill".  
> If there is any other way to distribute the code without showing the 
> source code please Tell
> Thanks
> Neeraj
>

-- 
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/572afb6e-9934-4bdc-ab75-bf1175415e07n%40googlegroups.com.

[go-nuts] Re: Looking Backend Dev Learning Resources

[Marcello H]

https://mehdihadeli.github.io/awesome-go-education/

Op woensdag 30 november 2022 om 14:12:46 UTC+1 schreef 
christoph...@gmail.com:

> If you know the basics of Go already, Effective Go 
>  and the Go FAQ are 
> good starting points for learning what idiomatic Go is like and why certain 
> decisions in the language design were made.
>
> On Saturday, November 26, 2022 at 11:37:29 AM UTC+1 sksin...@gmail.com 
> wrote:
>
>> Dear fellow Gophers, 
>>
>> I have been looking for resources to learn the backend development in Go. 
>> I want some good resources which talk about how to write Idiomatic Go Code, 
>> the Best Practices to follow, Anti-Patterns to avoid and writing an overall 
>> secure server. Any good resources are highly appreciated. 
>>
>> Thanks and Regards
>> SK Singh
>>
>

-- 
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/44137ee3-f7e1-4abb-ae49-dcda50861f27n%40googlegroups.com.

[go-nuts] Re: a way to access the full information that contains datas from database in golang

[Marcello H]

I saw an old discussion about this (and it might have a solution too)
https://github.com/golang/go/issues/16652

Op maandag 8 augustus 2022 om 17:12:11 UTC+2 schreef mandel...@gmail.com:

> There should be a way to access the full information a driver has for 
> result columns.
>

-- 
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/cca9440b-ec45-49f9-88b5-65850d9472f5n%40googlegroups.com.

[go-nuts] Re: Using Go Lang as a tiny server program at localhost , won't execute request

[Marcello H]

This is not how it works. it's not like PHP.

your server has to know the route(s) to a handler. That handler will take 
care of that particular hot.
In that hit you decide what to send back as a web-response.

Op donderdag 4 augustus 2022 om 21:16:53 UTC+2 schreef John Dutcher:

> I have a tiny server program in Go language (main2.go) running and 
> 'listening' on port 8080 in a Windows command prompt session. While running 
> I point a browser to http://localhost:8080/main2.go and main2.go executes 
> and places a small html form into the browser window to fill and submit. If 
> the form ACTION has any requested target for some other Go program or HTML 
> element resident in the same Windows folder as main2.go, the element 
> request is ignored  ONLY 'main2.go' gets triggered to execute instead 
> in response to the POST request 'submitted'.
>
> I have tried all variations I can think of in the POST ACTION URL format 
> to get the POST to run an element in the Windows folder called 'main.go' 
> (instead of main2.go):
>
> ACTION examples:
> http://localhost:8080/main.go
> localhost:8080/main.go
> /main.go
> ../main.go
> ./main.go
>
> BUT, if I load the ACTION URL with something like 'https://www.google.com' 
> it brings the home page for Google right into the browser window no problem.
>
> Why can it not run main.go, which again, resides in the same Windows 
> folder as main2.go which is the Go program running as the swerver ?
>

-- 
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/1610ce0f-d21a-4c3e-8409-fb7888468681n%40googlegroups.com.

[go-nuts] Re: Small language change for additional type safety (Go2?)

[Marcello H]

Ok, I get your point. And I for sure don't mind, as long as it is optional.

Op donderdag 4 augustus 2022 om 13:41:40 UTC+2 schreef aphill...@gmail.com:

> Hi Marc, thanks for your comment:
> >  The thing is, if you try to cover this for a mistake, then we can cover 
> every mistake, right?
> Not at all.  I think the idea is to try to catch at compile-time common 
> mistakes, that are easily made, can be missed during testing and can have 
> serious consequences.  There have been numerous additions to the language 
> for this reason and many other proposals some of which will probably be 
> implemented in Go2 (eg https://github.com/golang/go/issues/20733 which I 
> also thought of).
>
> I guess it comes down to an assessment of how common this is, seriousness 
> etc.  I couldn't find a discussion of this anywhere but in my experience it 
> is a very common problem for beginners but something we experienced Gophers 
> forget about.
>
>
> >  There is probably a linter which can check this, or you can write a 
> linter yourself.
> This is not a general solution for the millions of beginner Go 
> programmers.  Moreover, most do not run linters or even know what is 
> available.  And really the *only* Go "linter" (in the sense I think you 
> mean) should be *go vet*.  (Golint is more about style guidelines. Other 
> linters that people have written have good ideas but should be added to the 
> official tools - go vet of better the compiler - to be useful.)
>
> It would be a (small) step if *go vet* detected the problem but many 
> don't use *go vet. *My understanding of the unofficial current strategy 
> for handling dubious code is:
>
> 1. "go vet" to report the problem if it's possible that the code could be 
> correct AND there is no simple workaround to avoid it
> 2. compiler error is there is dubious code that could be clarified with a 
> simple code change (like type cast)
>
> Thanks again for the feedback.  It has helped me clarify what I want to 
> say in the proposal.
>
> On Wednesday, 3 August 2022 at 22:44:43 UTC+10 marc...@gmail.com wrote:
>
>> I would vote against it.
>> The thing is, if you try to cover this for a mistake, then we can cover 
>> every mistake, right?
>> There is probably a linter which can check this, or you can write a 
>> linter yourself.
>> (Also, if you happed to make this mistake more than once, tell your 
>> fellow developers, that they have to have extra attention when you write a 
>> loop.)
>>
>>
>> Op dinsdag 2 augustus 2022 om 07:12:01 UTC+2 schreef aphill...@gmail.com:
>>
>>> Just thought I'd run this one by you...
>>>
>>> I used to often forget to specify the 2nd variable in a for-range:
>>>
>>> sum := ""
>>> for v := range []string{"1", "2", "3"} {
>>> sum += v
>>> }
>>>
>>> luckilly (or because Go is so good at type safety) this generates the 
>>> error:
>>>
>>>   invalid operation: sum += v (mismatched types string and int)
>>>
>>> I used to do this quite a bit which lead (when using an int slice) to 
>>> one (maybe more that I haven't found yet :) bugs.  But for someone coming 
>>> from a language with a for-range statement (like Python) it seems this type 
>>> of bug is even more common:
>>>
>>> sum := 0
>>> for v := range []int{1, 2, 3} {
>>> sum += v // no error as they're both int
>>> }
>>>
>>> Ideally you write tests to catch these sorts of things, but even with 
>>> 100% coverage poor tests may not reveal the bug.  Then, if you're lucky, 
>>> you get unexpected results or it could leave a nasty bug lurking in some 
>>> rarely-executed piece of code.
>>>
>>> A small fix to the language would avoid this problem.  If for-range 
>>> indices had a different type then the above code could produce an error 
>>> like.
>>>
>>>   invalid operation: sum += v (mismatched types int and *for range 
>>> index*)
>>>   
>>> The name of the new type could be something like *intforrangeindex*. 
>>>  Perhaps something shorter, like *intindex*, if searching existing (Go 
>>> 1) code reveals no potential conflicts, which I suspect it wouldn't.
>>>
>>> BTW My gut was that *intindex *should be a signed int type but maybe 
>>> unsigned would not be a problem.
>>>
>>> This would be a proposal for Go 2 as it would not be backward 
>>> compatible.  However, existing code could be easily converted (go fix ?) by 
>>> just adding a type cast.  For example, if the above code was actually 
>>> intended it could be written as:
>>>
>>> sum := 0
>>> for v := range []int{1, 2, 3} {
>>> sum += int(v)
>>> }
>>>
>>> I think this is a small but worthwhile addition to type safety.
>>>
>>> Note that go vet does not currently detect this problem but maybe it 
>>> should.  A language change is better though, since not all code is vetted.
>>>
>>> I was also thinking that *intindex* could be a hidden internal type but 
>>> of course you can declare a loop index like this:
>>>
>>> var i int // type would change to intindex in Go 2
>>> for 

[go-nuts] Re: Small language change for additional type safety (Go2?)

[Marcello H]

I would vote against it.
The thing is, if you try to cover this for a mistake, then we can cover 
every mistake, right?
There is probably a linter which can check this, or you can write a linter 
yourself.
(Also, if you happed to make this mistake more than once, tell your fellow 
developers, that they have to have extra attention when you write a loop.)


Op dinsdag 2 augustus 2022 om 07:12:01 UTC+2 schreef aphill...@gmail.com:

> Just thought I'd run this one by you...
>
> I used to often forget to specify the 2nd variable in a for-range:
>
> sum := ""
> for v := range []string{"1", "2", "3"} {
> sum += v
> }
>
> luckilly (or because Go is so good at type safety) this generates the 
> error:
>
>   invalid operation: sum += v (mismatched types string and int)
>
> I used to do this quite a bit which lead (when using an int slice) to one 
> (maybe more that I haven't found yet :) bugs.  But for someone coming from 
> a language with a for-range statement (like Python) it seems this type of 
> bug is even more common:
>
> sum := 0
> for v := range []int{1, 2, 3} {
> sum += v // no error as they're both int
> }
>
> Ideally you write tests to catch these sorts of things, but even with 100% 
> coverage poor tests may not reveal the bug.  Then, if you're lucky, you get 
> unexpected results or it could leave a nasty bug lurking in some 
> rarely-executed piece of code.
>
> A small fix to the language would avoid this problem.  If for-range 
> indices had a different type then the above code could produce an error 
> like.
>
>   invalid operation: sum += v (mismatched types int and *for range index*)
>   
> The name of the new type could be something like *intforrangeindex*. 
>  Perhaps something shorter, like *intindex*, if searching existing (Go 1) 
> code reveals no potential conflicts, which I suspect it wouldn't.
>
> BTW My gut was that *intindex *should be a signed int type but maybe 
> unsigned would not be a problem.
>
> This would be a proposal for Go 2 as it would not be backward compatible. 
>  However, existing code could be easily converted (go fix ?) by just adding 
> a type cast.  For example, if the above code was actually intended it could 
> be written as:
>
> sum := 0
> for v := range []int{1, 2, 3} {
> sum += int(v)
> }
>
> I think this is a small but worthwhile addition to type safety.
>
> Note that go vet does not currently detect this problem but maybe it 
> should.  A language change is better though, since not all code is vetted.
>
> I was also thinking that *intindex* could be a hidden internal type but 
> of course you can declare a loop index like this:
>
> var i int // type would change to intindex in Go 2
> for i = range []int{1, 2, 3} {
> sum += i
> }
>

-- 
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/8ef777a3-69b4-4087-a196-6bf688554ff8n%40googlegroups.com.