Re: [go-nuts] "go-import" is great, we need "go-delete"

Agreed. Better to have the Go tooling state “xxx module has been marked as a security risk” during compilation. On Feb 6, 2025, at 12:56 PM, 'Sean Liao' via golang-nuts wrote:a delete in the control of the module author would make it worse, as you can serve malicious modules for a while, then del

Re: [go-nuts] "go-import" is great, we need "go-delete"

> On Jan 4, 2025, at 11:53 AM, Christoph Berger > wrote: > > > We need "go-delete". Security is not important to us. There should be a > > balance between people that need security and people that don't need it. > > Security might not be important to you, but it is important for the clients >

Re: [go-nuts] "go-import" is great, we need "go-delete"

> On Feb 6, 2025, at 1:55 PM, 'Sean Liao' via golang-nuts > wrote: > > a delete in the control of the module author would make it worse, as you can > serve malicious modules for a while, then delete and hide it, making it > unsuitable, unlike the current situation. > > - Sean Yes. Immediate

Re: [go-nuts] 100% CPU on load of my go application

We run a simple go program and we see the same syscalls so that really provides nothing. I think we will keep an eye on it and understand it better. On Thu, Feb 6, 2025, 16:35 Sharon Mafgaoker wrote: > Can you try to start it locally on your machine? > > > Sharon Mafgaoker – Senior Solutions Arc

[go-nuts] Re: Best Practices for Error Handling in Go APIs

Hi Jeremy, I really appreciate all the materials you have shared. I could understand that wrapping errors with informative messages is one of important best practice treating errors. I'll keep it mind that :) It was also very helpful to read errors section in Effective Go which you have shared

Re: [go-nuts] "go-import" is great, we need "go-delete"

a delete in the control of the module author would make it worse, as you can serve malicious modules for a while, then delete and hide it, making it unsuitable, unlike the current situation. - sean On Thu, Feb 6, 2025, 13:44 MKS Archive wrote: > On Jan 4, 2025, at 11:53 AM, Christoph Berger < >

Re: [go-nuts] "go-import" is great, we need "go-delete"

Hi Mike, My understanding is that the folks operating the proxy have already removed that: "note that the module in question is no longer available from the module proxy" https://github.com/golang/go/issues/66653#issuecomment-2637831755 Best regards, --thepudds On Thursday, Feb

Re: [go-nuts] 100% CPU on load of my go application

Can you try to start it locally on your machine? Sharon Mafgaoker – Senior Solutions Architect M. 050 995 99 16 | sha...@cloud5.co.il On Thu, 6 Feb 2025 at 16:27 Robert Engels wrote: > I would start by testing on the latest Go version. You really haven’t > provided anywhere enough details

Re: [go-nuts] 100% CPU on load of my go application

On Thu, Feb 6, 2025 at 9:38 AM Elad Gavra wrote: > We run a simple go program and we see the same syscalls so that really > provides nothing. I think we will keep an eye on it and understand it > better. > > The main benefit to running the binary outside a container is that you get more flexibili

Re: [go-nuts] "go-import" is great, we need "go-delete"

Allowing not-the-author to delete a module, in general, is obviously also very bad. There is already a process in place to request deletion a module from the proxy. See the last entry here: https://proxy.golang.org/ This thread isn't really connected to this news story, honestly. A manual process f

Re: [go-nuts] Best Practices for Error Handling in Go APIs

Hi Mike, thank you so much for sharing your thoughts and all those resources with concrete examples. Those really help me to understand how errors in go work and how it is different from errors in Java. Based on what you've shared, here's how I understand it: In essence, because an error in Go

Re: [go-nuts] Best Practices for Error Handling in Go APIs

Watch out for that article is pretty old, predating stdlib wrapping etc. On Thu, 6 Feb 2025 at 14:29, Byungjun You wrote: > Hi Mike, thank you so much for sharing your thoughts and all those > resources with concr

Re: [go-nuts] 100% CPU on load of my go application

I would start by testing on the latest Go version. You really haven’t provided anywhere enough details to help. I suspect if your app is not starting at all you have a bad image. On Feb 6, 2025, at 7:32 AM, Gavra wrote:Hi,We encountered an issue where our application consumed 100% CPU. The app wa