Thanks a lot for the powerful and detailed explanation, Dan. Though one
surely needs to be careful when coding, I'm keeping my initial point to
improve the document or any improvements like Robert suggested as below.
> developers shouldn’t have to read the code to understand the invariants
of an
it redirects with a status code and location header, it just also sends a
body
the comments in the code explains why
https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/net/http/server.go;l=2410
- sean
On Sun, Feb 23, 2025, 19:10 Vladislav (wennerryle)
wrote:
> I solved gophercises and
Hey everyone! I'm diving into Go (Golang) and looking for like-minded
people to learn and grow with. Whether you're a beginner or have some
experience, let's collaborate, share resources, and build cool projects
together. If you're interested, drop a comment or DM m
#Golang #LearnTogether
I solved gophercises and on the second exercise I wrote this code:
func mapHandler(
provider func(string) (string, error),
w http.ResponseWriter,
r *http.Request) {
longUrl, err := provider(r.URL.Path)
if err != nil {
w.WriteHeader(http.StatusNotFound)
fmt.Fprintln(w, err.Error())
return
}
w.He
Go Wiki: GOPATH
https://go.dev/wiki/GOPATH
peter
On Sunday, February 23, 2025 at 9:59:13 AM UTC-5 peterGo wrote:
> On Saturday, February 22, 2025 at 7:52:53 PM UTC-5 Björn Försterling wrote:
>
> Hello,
>
> according to "The Go Programming Lanuage" (Alan A. A. Donovan/Brian W.
> Kernigha
On Saturday, February 22, 2025 at 7:52:53 PM UTC-5 Björn Försterling wrote:
Hello,
according to "The Go Programming Lanuage" (Alan A. A. Donovan/Brian W.
Kernighan)
page 291 the "GOPATH" should have a subdirectory named "src".
However that dir is not present on my system:
The Go programming
On Sun, Feb 23, 2025 at 1:12 PM Gavra wrote:
> I have a heap profile that shows that many allocations are generated in a
function that runs in a go routine. Unfortunately, I can't see the
caller(s) to this function, implying I cannot detect the one holding the
reference (and causing the mem leak)
Hi,
I have a heap profile that shows that many allocations are generated in a
function that runs in a go routine. Unfortunately, I can't see the
caller(s) to this function, implying I cannot detect the one holding the
reference (and causing the mem leak).
1. Can I extract this information from t
