[go-nuts] Re: best framework for web development in golang

Hi "programmer programmer", Perhaps you're young and inexperienced, but this post and your previous one come across as poor questions, even lazy and spammy. There are a lot of articles on the internet that answer this very thing: just

[go-nuts] Re: How to run extra routine for http server properly ?

For simple things, you can fire up a goroutine to do the "something else" after the request finishes. For example, I've used this before to kick off sending an email to a customer in the background (you'll want to handle/report errors somehow though): package main import ( "fmt" "log"

Re: [go-nuts] Why not return after calling http.Error()

> Every example of http Handler that I have seen so far looks like this: Yes, that's definitely odd. I just grepped my Go source directory (which includes the Go compiler and stdlib and a bunch of other Go code), and almost all of them have a "return" on the next line. For example: $ rg

[go-nuts] Re: tool for ast graph visualization

Hi Alex, could you please give a bit more context about what language or kind of AST you're referring to, and what you mean by visualize? As Vraj mentioned, Graphviz is good for the general case. If you just want to "visualize" Go AST in a text format, you can use go/ast.Print:

Re: [go-nuts] Error Handling

I agree with Axel that a function like errReturn is a bad idea, though if Go updates/improves error handling, it's possible we'll get something like that (some of the error handling proposals have been similar to errReturn). However, I don't see anything wrong with a function like Richard's

[go-nuts] Re: any Go based supervisor alternative?

Part of my day job is working on Canonical's "Pebble" (https://github.com/canonical/pebble), a simple service manager written in Go. Unique features: layered configuration, and an HTTP-over-unix-socket API. It's GPLv3 licensed. -Ben On Monday, July 21, 2014 3:51:12 PM UTC-7, ChrisLu wrote:

[go-nuts] Re: Go 1.20 release date

You can also use the "gotip" command (https://pkg.go.dev/golang.org/dl/gotip) to pull the latest, unreleased version from the Go development tree. -Ben On Wednesday, November 23, 2022 at 2:24:12 AM UTC+13 Amnon wrote: > Feb 2023 is a good bet. > > On Tuesday, 22 November 2022 at 10:24:07 UTC

[go-nuts] Re: fmt package documentation

At the default URL https://pkg.go.dev/fmt the same thing happens for me too. However, at https://pkg.go.dev/fmt@master it formats correctly (pre-formatted block like in the source). So I assume this has been fixed and the default will be updated soon (when 1.19 comes out?). -Ben On Tuesday,

[go-nuts] Re: Go 1.19 Beta 1 is released

It doesn't replace the default "go" binary, but creates a new versioned one in the usual go-install path (~/go/bin, which a lot of folks add to their PATH). So you have to type "go1.19beta1" instead of "go": $ which go1.19beta1 /home/duke/go/bin/go1.19beta1 $ go1.19beta1 version go version

Re: [go-nuts] Re: Go 1.19 Beta 1 is released

I'm quite looking forward to the performance improvements we'll get for free (i.e., by just upgrading): sort will be faster, large switch blocks will be faster due to now using jump tables (good for interpreter opcode-dispatch loops), and regexp will be a little faster due to a

Re: [go-nuts] Elementary Question About Calling Functions in Different Packages

Kurtis has given some great answers about the general problem. I do have a bit of a counterpoint to this statement, however: > > As a learning exercise I'm converting a large app into Go. > > That's going to be a painful way to learn Go. Worse, doing a straightforward, mechanical, translation

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

> Depending on implementation, infinite recursion is not guaranteed to blow > the stack for the program given. The function call is in tail position, so > a tail-call optimization (TCO) pass would be able to rewrite the program > into an infinite loop by reusing the existing stack frame for

[go-nuts] Re: Why is Go fun?

Reading the spec probably isn't the best way to experience the "fun" in any case. (Though the spec is worth a read once you've use the language a bit -- as far as specs go, it's concise and readable.) "Fun" is quite a personal thing, but similar people often have similar experiences, so I'll

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

Oh wait, looks like it's public: https://github.com/golang/playground On Wednesday, April 6, 2022 at 3:32:11 PM UTC+12 ben...@gmail.com wrote: > Sure, report an issue against the playground. I honestly have no idea >> how difficult this would be to fix. >> > > Thanks, don

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

> Sure, report an issue against the playground. I honestly have no idea > how difficult this would be to fix. > Thanks, done: https://github.com/golang/go/issues/52176 The source for the Playground is private, correct? -Ben -- You received this message because you are subscribed to the

Re: [go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

> The playground isn't intended to be an exact replica of running a > program on a real machine. If the program uses too many resources it > will simply be stopped. > Both fair enough. But surely the runner can distinguish when the program ran successfully to completion versus when it was

[go-nuts] Why does infinitely-recursing code not give stack overflow in Playground?

Normally the Go Playground gives errors when a runtime panic or other error occurs, including "timeout running program" for programs that run too long. I'm wondering why the Playground doesn't show a stack overflow error (or any error) for this infinitely-recursing program?

[go-nuts] Re: When will the official encoding/json package support parsing json5？

Yeah, Go's encoding/json will almost certainly never support json5. However, one very simple approach: if you're using JSON for a config file and just need ability to add // line comments, you can just write a simple transformer which reads the file line by line and filters out lines that

Re: [go-nuts] Re: Parsing a time as a prefix of a larger string

ring to separate the time? The time parser doesn't > have to be the one to do this. For instance, uou could require a > marker (if the word INFO or its substitute isn't already one), such as > a spaced hyphen: > > 2006-01-02 15:04:05 - INFO this is a log message > > -rob >

[go-nuts] Re: Parsing a time as a prefix of a larger string

> How does the user control the format of the timestamp? How do you get the > time.Parse layout? > The project is a lightweight service manager, so the user "controls" the format of the timestamp based on the service they're running. For example, if they're running nginx, it will output logs

[go-nuts] Parsing a time as a prefix of a larger string

We're making a log processing program that needs to parse times from the prefix of a larger string, in this case in a log line such as: 2006-01-02 15:04:05 INFO this is a log message We need to parse the "2006-01-02 15:04:05" part as a timestamp. Unfortunately, time.Parse always returns an

[go-nuts] Optimizing GoAWK with a bytecode compiler and virtual machine

Recently I switched (so to speak) my GoAWK interpreter from using a tree-walking interpreter to a bytecode compiler with a virtual machine, and got a noticeable performance boost. Write-up here if you're interested: https://benhoyt.com/writings/goawk-compiler-vm/ TLDR: It's significantly more

Re: [go-nuts] Re: Do you have a minimal runnable go code that contain all key words in go?

t; to >> >> p := new(counter) >> var c = *p >> >> https://go.dev/play/p/2vw4w44qSWm >> >> >> On Sunday, December 5, 2021 at 4:10:54 PM UTC-5 ben...@gmail.com wrote: >> >>> Not strictly "minimal" -- it uses some keywords twice, and

[go-nuts] Re: Do you have a minimal runnable go code that contain all key words in go?

Not strictly "minimal" -- it uses some keywords twice, and I'm sure it's longer than it needs to be, but here you go: https://go.dev/play/p/XPoqfI8RmyH On Monday, December 6, 2021 at 4:54:04 AM UTC+13 cuiw...@gmail.com wrote: > show me you code -- You received this message because you are

[go-nuts] Re: New site go.dev is awful

I don't think it's awful, and Carla's right, there's always going to be debate about these changes and a settling period. However, I do think the criticism of it being too corporate-looking now is valid. Two pieces of concrete feedback (in case the maintainers are listening), one on how to

Re: [go-nuts] Anyway to wrap or tweak a test file before running go test?

> func connectToDB(t *testing.T) *postgres.DB { > t.Helper() > // set up the connection, using t.Fatalf if an error occurs > return conn > } > > func UserTest(t *testing.T) { > db := connectToDB(t) > } > Yeah, that's a good way. And if you want to avoid re-connecting to the db

[go-nuts] Re: How to negotiate authentication over HTTP ? (the Go way)

I'm not sure what these proprietary auth schemes look like (and don't know much about oauth2 or NTLM), but for many kinds of auth you'd just set headers in the request and read them in the body. For example: request, err := http.NewRequest("GET", "https://httpbin.org/get;, nil) //

Re: [go-nuts] Source links on cs.opensource.google are slow (links for stdlib on pkg.go.dev)

For the record, I've just opened https://github.com/golang/go/issues/48752 to track this. On Thursday, August 26, 2021 at 3:29:09 PM UTC+12 ben...@gmail.com wrote: > Every site you access probably uses Google analytics or something similar. >> >> It is often used to understand

Re: [go-nuts] Creating a MQTT library

> Neither. Return a blocking iterator, something like > > type Iterator struct { > // Next blocks until a new message is available or the stream ends and > returns if a new message is available. > Next() bool > // Message returns the current message. Must only be called after Next

[go-nuts] Source links on cs.opensource.google are slow (links for stdlib on pkg.go.dev)

With the switch to pkg.go.dev (which in itself I quite like after getting used to it), the view-source links also changed from the golang.org source viewer, which was fast, to cs.opensource.google, which is rather slow. For example, here is the code I've been looking at just now, compared to

[go-nuts] Re: Go 1.17 is released

Thank you, Go team, for all your work on this! I (and I think many others!) love all these behind-the-scenes changes that make our lives better. I went to look for that 5% performance boost in my GoAWK interpreter (due to the new register-based calling convention), and found a 38% improvement

Re: [go-nuts] How are interfaces marked by the GC?

Out of interest, why was that changed? Was the optimization not worth it? Did it just require too much special handling so the code was unclear? On Wednesday, July 14, 2021 at 8:32:06 AM UTC+12 Ian Lance Taylor wrote: > On Tue, Jul 13, 2021 at 1:29 PM Kristoffer Semelka > wrote: > > > > I

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

> I recently translated a substantial C library into Go, and watching all > the pointers disappear, at least syntactically (there were still slices), > was marvelous. > Side point: Rob, is this open source? If so, I'd be interested to see the side-by-side comparison of the C vs Go code

[go-nuts] Re: A message from the CoC committee

> permanent bans were given to multiple individuals, with no possibility for appeal I don't disagree with the bans, but this part -- the "no possibility for appeal" seems very ... totalitarian. What if a mistake was made? (Again, not saying it was here, but in general, to err is human.) I'm

Re: [go-nuts] Re: SQLite3 Support without CGo

Thanks a lot for that -- I appreciate the links. On Wednesday, February 17, 2021 at 10:58:48 PM UTC+13 Jan Mercl wrote: > On Tue, Feb 16, 2021 at 10:52 PM ben...@gmail.com > wrote: > > > Jan, is there any write-up about modernc.org/sqlite? I've dabbled in > automated conver

Re: [go-nuts] Re: SQLite3 Support without CGo

Jan, is there any write-up about modernc.org/sqlite? I've dabbled in automated conversion, and I'm very curious if there's more information about how it works, any pitfalls / unsupported stuff, etc, but having trouble finding anything like that in the repos. On Sunday, January 24, 2021 at

[go-nuts] Re: Interfaces holding integers and memory allocations

Wow -- yes, that's pretty significant! (Though point taken about "real workloads".) Thanks for sharing this. On Tuesday, December 22, 2020 at 11:44:25 PM UTC+13 arn...@gmail.com wrote: > Luckily, I have the "no scalar" version with a build tag. Here is a > simple benchmark: > > func

[go-nuts] Re: Interfaces holding integers and memory allocations

gt; >>> var i int64 = 77 >>> v := reflect.ValueOf().Elem() >>> >>> At this point, v now has .Type() of int64, and is settable. >>> >>> Note that to get the value you can't do v.Interface().(int64), as that >>> allocates. You

Re: [go-nuts] Performance issue with os.File.Write

And os.Stdout (and friends) are all regular *os.File objects (which as Jan said, don't buffer). It was non-intuitive to me that stdout didn't buffer by default, because it's such a bad thing for efficiently writing lots of output, but I guess it makes sense when you want terminal output to

[go-nuts] Re: Interfaces holding integers and memory allocations

Nice project! It's a pity Go doesn't have C-like unions for cases like this (though I understand why). In my implementation of AWK in Go, I modelled the value type as a pseudo-union struct, passed by value: type value struct { typ valueType // Type of value (Null, Str, Num, NumStr) s

[go-nuts] Re: exec: "date": executable file not found in %PATH%

If you do want to find the processor architecture, instead of shelling out, can you use runtime.GOARCH? See https://golang.org/pkg/runtime/#pkg-constants -- it has a value like "amd64", similar to PROCESSOR_ARCHITECTURE on Windows. It also works on different platforms/OSes. On Thursday,

Re: [go-nuts] A few thoughts on type parameters

> > Which at first seems like a good idea, but then unless "any" is built in >> or this becomes a well-known idiom, it won't be as self-documenting. Other >> people will have to look up the definition to see "oh, I see, this is just >> short-hand for an empty constraint". > > > I'm sure it

[go-nuts] Generics: type-list vs method-based constraints -- not orthogonal?

Hi folks, This thread on lobste.rs made me wonder if the difference between type-list constraints and method-interface constraints is going to cause a bunch of issues or code duplication. There's a lack of orthogonality here that makes me

Re: [go-nuts] draft design for // +build replacement

FWIW, I *like* the filename-based constraints. I can look at the source for the OS package (https://golang.org/src/os/) and immediately go to the _windows.go files to see how they do things on Windows (for example). It's really obvious from the directory listing, and I don't have to dig into