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

2023-07-21 Thread ben...@gmail.com
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 type your subject line into a 
search engine and read the articles that come up. You'll learn a lot more, 
and get better answers if you do still have questions after some research.

For example, you might have done some reading and narrowed it down to Gin 
and Echo, and then ask, "I've tried using both Gin and Echo for a small 
test web server, and both seem to work well. Does anyone have experience 
with either framework in production, and can you describe the pros and cons 
from your perspective? I'm trying to make a decision about which to use for 
a JSON API I need to develop." In other words, explain what you've tried, 
be specific, and give some context about what you're trying to achieve. 
This will show you've put in some effort, and help people on the mailing 
list provide better answers.

The following article is a long read, but well worth it to learn how to ask 
better questions (and get better answers):

http://www.catb.org/~esr/faqs/smart-questions.html

Thanks,
Ben


On Saturday, July 22, 2023 at 4:20:53 AM UTC+12 programming programmer 
wrote:

> best framework for web development in golang 

-- 
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/27fa6b13-722a-4518-a10e-8b002b19de4fn%40googlegroups.com.


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

2023-07-05 Thread ben...@gmail.com
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"
"net/http"
"time"
)

func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "sending email in the background")
go sendEmail()
// response is sent, but sendEmail goroutine continues
})
log.Print("listening on http://localhost:8080;)
http.ListenAndServe(":8080", nil)
}

func sendEmail() {
log.Printf("would send an email here")
time.Sleep(time.Second)
log.Printf("done sending email")
}

On Thursday, July 6, 2023 at 2:03:47 AM UTC+12 alex-coder wrote:

Hi All !

So, http server looks like is a request / response processing.
But in case it is nesessary to do something else after the response has 
been sent to the client, how to do it properly ?
Is there any example to read ?

Thank you.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/795ab574-4437-43de-909b-7cceedb5556dn%40googlegroups.com.


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

2023-07-04 Thread ben...@gmail.com


> 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 --type=go --sort=path 'http\.Error\(' -A1
...
pkgsite/internal/worker/server.go
319: http.Error(w, http.StatusText(code), code)
320- return

-Ben

-- 
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/7a727dd2-e39a-4414-b323-6f3ff2a27aa7n%40googlegroups.com.


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

2023-06-14 Thread ben...@gmail.com
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: 
https://pkg.go.dev/go/ast@go1.20.5#Print

On Wednesday, June 14, 2023 at 9:14:37 AM UTC+12 alex-coder wrote:

> Hi All !
>
> Could you please advice me a tool to visualize an ast graph.
>
> Thank you.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/337cc297-6643-49f5-8c4e-cab6b1117b4fn%40googlegroups.com.


Re: [go-nuts] Error Handling

2023-02-09 Thread ben...@gmail.com
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 
errHandle(), *if it's at the top level in main*. I often have a function 
like this in main.go for CLIs. The signature might be:

inFile, err := os.ReadFile("Mydata.txt")
exitOnError(err, "cannot read file")

-Ben

On Wednesday, February 8, 2023 at 11:01:53 AM UTC+13 Richard Masci wrote:

> You said: "and FTR, I'd also consider your function a bad idea, but that's 
> none of my business" <- I'll be the first to say not all my ideas are good 
> ones, maybe this one isn't? Thanks for your response.
>
>
> On Tue, Feb 7, 2023 at 4:45 PM Axel Wagner  
> wrote:
>
>> No, that is not possible. Only a `return` statement can return.
>> You *can* unwind the stack, using `panic` or `runtime.GoExit` (which is 
>> what `t.Fatal` does) but it's a bad idea in general (and FTR, I'd also 
>> consider your function a bad idea, but that's none of my business).
>>
>> On Tue, Feb 7, 2023 at 10:39 PM Rich  wrote:
>>
>>> In most of my code I create a function to handle errors. looks something 
>>> like this:
>>>
>>> func errorHandle(err error, str string, ex bool) {
>>>  if err != nil {
>>>   fmt.Printf("error: %s -- %v\n",str, err)
>>>  }
>>>  if ex {
>>> os.Exit(1)
>>>  }
>>> }
>>>
>>> This cleans up my code:
>>> inFile, err := os.ReadFile("Mydata.txt")
>>> errorHandle(err,"read mydata.txt",true) // The true will exit
>>>
>>> So you see that I can exit the program when there is an error, what I 
>>> want to know is if it's possible to do the same thing inside a function, to 
>>> where I don't exit the program but return from the function:
>>>
>>> func OpenFile( filename string) []byte {
>>> inFile,err := os.ReadFile(filename)
>>> errReturn(err, "read "+filname,true)
>>>
>>> When there is an error it would return from the OpenFile function,
>>>
>>> -- 
>>> 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/2eec0130-3deb-4f60-a13e-d7c9d132771dn%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/c77b336e-85a8-4e3e-a64d-e5e3f1759c68n%40googlegroups.com.


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

2022-11-23 Thread ben...@gmail.com
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:
>>>
>>> I am tasked to start a go service in a python shop. However, for 
>>> production environments, we have to use python based supervisord to manage 
>>> the Go process if it ever goes down.
>>>
>>> The Go deployment is extremely easy. But the python setup is just 
>>> painful to automate (compared with Go code).
>>>
>>> How do you manage the Go service on production and restart the Go 
>>> service if it goes down?
>>>
>>> Chris
>>>
>>>

-- 
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/b29d35cb-0d95-4a0e-a869-842d56dead8bn%40googlegroups.com.


[go-nuts] Re: Go 1.20 release date

2022-11-22 Thread ben...@gmail.com
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 piotr.w...@gmail.com wrote:
>
>> Hi,
>>
>> is the date of the 1.20 release roughly known? I need some goodies it 
>> promises to provide.
>>
>> Best regards, Piotr 
>>
>

-- 
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/68bc781e-faae-4338-91f8-8c911363f0cdn%40googlegroups.com.


[go-nuts] Re: fmt package documentation

2022-07-05 Thread ben...@gmail.com
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, July 5, 2022 at 12:28:33 PM UTC+12 aetr...@gmail.com wrote:

> The documentation of the formatting language 
> inhttps://cs.opensource.google/go/go/+/master:src/fmt/doc.go;l=132 doesn't 
> render the "other flags" section well. It all runs together:
> source: 
> Other flags: 
>'+'always print a sign for numeric values; 
>guarantee ASCII-only output for %q (%+q) 
>'-'pad with spaces on the right rather than the left (left-justify 
> the field) 
>'#'alternate format: add leading 0b for binary (%#b), 0 for octal 
> (%#o), 
>0x or 0X for hex (%#x or %#X); suppress 0x for %p (%#p); 
>for %q, print a raw (backquoted) string if strconv.CanBackquote 
>returns true; 
>always print a decimal point for %e, %E, %f, %F, %g and %G; 
>do not remove trailing zeros for %g and %G; 
>write e.g. U+0078 'x' if the character is printable for %U (%#U). 
>' '(space) leave a space for elided sign in numbers (% d); 
>put spaces between bytes printing strings or slices in hex (% x, % 
> X) 
>'0'pad with leading zeros rather than spaces; 
>for numbers, this moves the padding after the sign; 
>ignored for strings, byte slices and byte arrays
> 
> rendered-
> Other flags:
>
>- always print a sign for numeric values; guarantee ASCII-only output 
>for %q (%+q)
>- pad with spaces on the right rather than the left (left-justify the 
>field) # alternate format: add leading 0b for binary (%#b), 0 for octal 
>(%#o), 0x or 0X for hex (%#x or %#X); suppress 0x for %p (%#p); for %q, 
>print a raw (backquoted) string if strconv.CanBackquote returns true; 
>always print a decimal point for %e, %E, %f, %F, %g and %G; do not remove 
>trailing zeros for %g and %G; write e.g. U+0078 'x' if the character is 
>printable for %U (%#U). ' ' (space) leave a space for elided sign in 
>numbers (% d); put spaces between bytes printing strings or slices in hex 
>(% x, % X) 0 pad with leading zeros rather than spaces; for numbers, this 
>moves the padding after the sign
>
> -
>
> Maybe there's already an issue open for this: it's hard to query for 
> src/fmt/doc.go: the terms are too common.
>
> -- Allen
>

-- 
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/d0af953d-274b-4140-b0d0-1ec0d86a25e4n%40googlegroups.com.


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

2022-06-13 Thread ben...@gmail.com
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 go1.19beta1 linux/amd64

-Ben

On Tuesday, June 14, 2022 at 3:11:20 PM UTC+12 Duke wrote:

> On Friday, June 10, 2022 at 11:51:02 a.m. UTC-6 anno...@golang.org wrote:
>
>>
>> If you have Go installed already, the easiest way to try go1.19beta1
>> is by using the go command:
>> $ go install golang.org/dl/go1.19beta1@latest
>> $ go1.19beta1 download
>>
> I did this on my Linux distro, but nothing happened! Where does it get 
> DLed to?
> `which go' is the old version still.
>  
>

-- 
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/d4e0e17f-d03b-4a67-b37f-d532690d4fcan%40googlegroups.com.


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

2022-06-11 Thread ben...@gmail.com
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 
pointer-vs-value optimization 
(https://go-review.googlesource.com/c/go/+/355789 -- not mentioned in the 
Go 1.19 release notes).

-Ben

On Sunday, June 12, 2022 at 9:27:27 AM UTC+12 Ian Lance Taylor wrote:

> On Sat, Jun 11, 2022 at 12:30 AM Amnon  wrote:
> >
> > What are the biggest, and most exciting changes coming in 1.19?
>
> The draft release notes are at https://tip.golang.org/doc/go1.19 .
>
> 1.18 was a big release with a lot of exciting changes. 1.19 is more
> of a relaxed, catch your breath release. Personally I think the most
> exciting change is runtime/debug.SetMemoryLimit.
>
> 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/0c28323b-b15c-49f8-9056-13e0231c52ddn%40googlegroups.com.


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

2022-06-10 Thread ben...@gmail.com
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 of a program written in another 
language is likely to result in non-idiomatic Go code and reinforce bad 
habits (bad in the context of Go, not the other language).

I agree it might be painful, and might lead to non-idiomatic Go! But it 
sounds like a really good challenge, and will no doubt teach you a lot 
along the way. It looks like you've already learned something from this 
thread. :-)

Is the app you're converting open source, and if so, can you provide a link 
to the code that leads to the import cycle? With concrete code examples it 
might be easier to advise you how to refactor to avoid the cycle.

One other thing: I've seen a lot of projects in Java (but not just Java: 
C#, JavaScript, even Go) that break things up into very small pieces. One 
5-line class per file, dozens of files and directories for something 
simple, that sort of thing. In Go (I think) it's more common to have larger 
packages.

-Ben

-- 
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/da9f27ba-6320-4ec8-b7cb-2e038dfdbda4n%40googlegroups.com.


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

2022-04-11 Thread ben...@gmail.com


> 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 each 
> invocation of f[0].
>

Understood. But I think there are two reasons this code in the playground 
should still show an error:

1) The existing Go compilers don't do tail-call optimization, so keeping 
the discussion real and concrete, they will overflow the stack.
2) Even if they did implement tail-call optimization, this would be an 
infinite loop, so it should show a timeout error, like an infinite for loop 
does: https://go.dev/play/p/GH67vNtpZyp

-Ben
 

-- 
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/e4822715-caab-40b5-a345-9f5604e248cfn%40googlegroups.com.


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

2022-04-10 Thread ben...@gmail.com
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 take a stab at answering from my perspective:

Go is fun because the language is:

* Easy to learn: I learned it coming from years of Python and some C. You 
can be productive in Go in a couple of weeks. My first medium-sized project 
in Go was porting a web backend from Python to Go, and I found it a lot of 
fun (https://benhoyt.com/writings/learning-go/).
* Builds fast: even large programs compile and build in seconds (not 
minutes or hours). Go caches builds of packages that haven't changed, 
meaning the time from editing code to running it is very short, sometimes 
close to instantaneous.
* Runs fast: Go compiles to reasonably fast native code. Coming from an 
interpreted language like Python, this is great when you need to do 
something like loop over the characters in a string.
* Solid stdlib: enough quality stuff in the standard library to get a lot 
done quickly.
* Concrete focus: good Go code (like the stdlib) tends toward concrete 
types and simple patterns rather than abstract interfaces, factories, and 
deep nesting.
* Excellent tooling: "go build" builds your project with no ceremony. "go 
test ./..." runs all your tests. "go run" builds and runs a program in one 
step. The caches for the above just work.

The above is why Go is fun for me. That leaves out Go's other unique 
features (though arguably these are more "useful" than "fun"):

* Unique take on types and interfaces that doesn't result in an inheritance 
mess.
* Statically typed. For medium-sized to large projects, this really helps 
reassure you when refactoring (compared to Python, JavaScript, and so on).
* Generic slices and maps: right from Go 1 (that is, pre-Go 1.18-generics), 
Go always had type-safe growable arrays and hash tables, two of the most 
useful data structures.
* (Some) control over memory allocation. You don't usually have to worry 
about it, but when you need to reduce allocations, you can: make(), reuse 
buffers, and so on.
* Goroutines and channels. Concurrency is never easy, but at least with Go 
the primitives are built into the language and relatively straight-forward 
to learn.
* The above means functions aren't colored -- all libraries are sync, use 
"go" to make them async. See: 
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
* io.Reader and io.Writer. These are simple but amazing tools for composing 
I/O (I'm comparing to things like the vague mess that is Python's 
"file-like objects").
* Go modules. Relatively new in the scheme of things, but it's a really 
good system. (It's also well built, for example: 
https://go.dev/blog/supply-chain)
* The Go community's focus on few dependencies. So much better than the 
pain and fragility of a node_modules directory with 1500 entries.
* Easily-deployable binaries. Instead of having to ship around a big 
runtime and stdlib, to deploy a Go program, you just copy the binary to the 
target machine. (And Go 1.16's "embed" means you can even include your 
static files, templates, and so on.)
* Incredible cross-compilation. Just set two environment variables (GOOS 
and GOARCH) and type "go build", and have a macOS or Windows binary a few 
seconds later.

I'm sure others have their own lists...

-Ben


On Monday, April 11, 2022 at 8:53:55 AM UTC+12 kziem...@gmail.com wrote:

> Hello,
>
> I lack a motivation to read Go spec (long story) and I seek few stories 
> along the line "Go is fun", which it is, to motivate myself. Google didn't 
> give me any results, maybe you can tell me few reasons, why Go is fun?
>
> I feel that it is fun, but can't tell why.
>
> Best,
> Kamil Ziemian
>

-- 
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/a9c42337-c8ca-45b5-9f2d-839237705600n%40googlegroups.com.


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

2022-04-05 Thread ben...@gmail.com
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, 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 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/e8da32d0-da48-4504-9ee1-969fcbb57e98n%40googlegroups.com.


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

2022-04-05 Thread ben...@gmail.com


> 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 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/4f4dd528-2a87-4e9e-b14a-714c48e8a96dn%40googlegroups.com.


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

2022-04-05 Thread ben...@gmail.com


> 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 stopped, and print an 
error in the latter case? Even if it was just something generic like "out 
of memory" or even "program stopped". Currently it prints nothing, which 
looks like a success.

-Ben
 

-- 
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/4c8d27bf-3339-4e32-b314-90bb46bb9ac1n%40googlegroups.com.


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

2022-04-05 Thread ben...@gmail.com
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?

https://go.dev/play/p/ILbGVj0dfWg

It seems like a quirk (bug?) in the way this particular error is handled. 
This confused my colleague (who's new to Go) because he (correctly) 
expected it to show some kind of overflow/recursion error.

For comparison, here's what the Go runtime says locally for this code:

$ go run t.go
runtime: goroutine stack exceeds 10-byte limit
runtime: sp=0xc020160398 stack=[0xc02016, 0xc04016]
fatal error: stack overflow
... full stack trace elided ...

Should I report a golang/go issue?

-Ben

-- 
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/88798dd0-8728-437a-8858-5b377d94e251n%40googlegroups.com.


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

2022-03-18 Thread ben...@gmail.com
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 
start with "//" (optionally preceded by whitespace), and then send the 
result to encoding/json.

On Friday, March 18, 2022 at 1:59:21 PM UTC+13 r...@rwx.gg wrote:

> It is my sincere hope that Go will never support anything as poorly 
> designed as JSON5, using reflection is already slow enough. Comments were 
> never intended for JSON and never should be added, ever. But since most 
> discerning development shops are moving to Protobuf for everything that 
> matters, perhaps that would be less of a problem.
>
> On Monday, March 14, 2022 at 12:07:37 PM UTC-4 fliter wrote:
>
>> I need to add comments to json, but now json version does not support it
>>
>

-- 
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/789fe6c3-0ce7-456a-9b96-a86aac2a849an%40googlegroups.com.


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

2022-03-18 Thread ben...@gmail.com
Thanks for the feedback, folks. I think we'll end up using an explicit 
"log-trim" regex for this. -Ben

On Thursday, March 17, 2022 at 3:03:08 PM UTC+13 Rob 'Commander' Pike wrote:

> I would approach the problem a different way and ask the question, how 
> do I split the string 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 
>
> On Thu, Mar 17, 2022 at 11:44 AM ben...@gmail.com  
> wrote: 
> > 
> > 
> >> 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 (and timestamps) in a certain 
> format, and so on. 
> > 
> > The service manager has configuration per service, and that's where 
> we're going to specify the time.Parse (or perhaps regex) layout. 
> > 
> > -Ben 
> > 
> > 
> > -- 
> > 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/17f2caf4-765b-4e14-845d-5b0d8bde064dn%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/429138a0-cac0-4e96-8248-a1af3c73abf0n%40googlegroups.com.


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

2022-03-16 Thread ben...@gmail.com


> 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 (and timestamps) in a certain 
format, and so on.

The service manager has configuration per service, and that's where we're 
going to specify the time.Parse (or perhaps regex) layout.

-Ben
 

-- 
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/17f2caf4-765b-4e14-845d-5b0d8bde064dn%40googlegroups.com.


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

2022-03-15 Thread ben...@gmail.com
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 error if there's extra text 
after the timestamp.

If the timestamp were in a fixed format (like the one above) we could just 
hard-code it to grab the first two fields, or even the first N characters. 
However, in our case the format of the timestamp is user-controlled, so 
we're planning to let the user specify a custom time.Parse layout for their 
logs.

We can hack around this with the following "introspect the error message" 
workaround (see runnable code at https://go.dev/play/p/CWuSk0te7-p):

t, err := time.Parse(layout, line)
if e, ok := err.(*time.ParseError); ok && 
strings.HasPrefix(e.Message, ": extra text: ") {
prefix := line[:len(line)-len(e.ValueElem)]
t, _ = time.Parse(layout, prefix) // parsing just the 
prefix should succeed
err = nil
}
// use t, err

This works, and it seems unlikely the Go team will change that "extra text" 
message, but that's certainly not guaranteed, and it's bad form to rely on 
the formatting of error messages. It also means we need to call time.Parse 
again, when it's already done the work once.

Does anyone have suggestions for how to best parse "time prefixes"? 
Currently we're thinking of either the above hack, or copying the 
time.Parse code into our repo and modifying it to suit (there's a clear 
place that returns "extra text", so that would be annoying, but easy enough 
to do).

This seems like it would be a useful feature for others, and I'm surprised 
there are not open issues about this already (I couldn't find any). Maybe I 
could open an issue to suggest that ParseError could have a new method 
ExtraText as follows:

// ExtraText returns the extra text after the parsed time value in the 
original string.
// If this error is not an "extra text" error, return "", nil.
func (*ParseError) ExtraText() (extra string, parsed Time)

But of course, even if that method were added, it would have to wait till 
at least Go 1.19, so for our project we need a way forward either way.

Thanks,
Ben

-- 
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/790d818f-009c-42c2-9be6-b8cf6c170444n%40googlegroups.com.


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

2022-02-03 Thread ben...@gmail.com
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 code, but also 10-20% faster. It'll get even 
faster when Go implements "switch" using jump tables (looking forward to 
https://go-review.googlesource.com/c/go/+/357330/).

-Ben

-- 
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/d010af1b-3d15-40a5-be37-bbb1b3603c82n%40googlegroups.com.


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

2021-12-07 Thread ben...@gmail.com
Heh, nice! I made it three bytes smaller by defining "const t = true" (true 
was used in 2 places). https://go.dev/play/p/-3SvzKYjGSr ... I can't think 
of any ways to reduce its (formatted) size further off the top of my head, 
but I'm sure there's bound to be something.

On Tuesday, December 7, 2021 at 2:47:41 AM UTC+13 axel.wa...@googlemail.com 
wrote:

> `new` is not a keyword, it is a predeclared identifier 
> <https://go.dev/ref/spec#Predeclared_identifiers>.
> Here's a valid program that contains every keyword 
> <https://go.dev/ref/spec#Keywords> exactly once: 
> https://go.dev/play/p/YxfkoYDTN4h
>
> On Mon, Dec 6, 2021 at 2:34 PM Michael Ellis  wrote:
>
>> Nice! Noticed it didn't have "new" so I changed the counter initializer 
>> in main() from
>>
>> var c = counter
>>
>> 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 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 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/851b403a-dc73-487f-b10e-e1608cb8cda2n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/851b403a-dc73-487f-b10e-e1608cb8cda2n%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/378e15b4-11f5-4084-860f-250fe92bd33bn%40googlegroups.com.


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

2021-12-05 Thread ben...@gmail.com
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 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/9573bf5e-0bd3-4632-8b5c-15b64d093d08n%40googlegroups.com.


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

2021-11-24 Thread ben...@gmail.com
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 
address the corporate-ness, and one minor quirk:

1) Putting the "Companies using Go" at the top makes it seem *really* 
corporate- rather than programmer-oriented. Why can't we lead with "Try 
Go", then "What's possible with Go", and only then "Companies using Go"?

2) The download link is for the Windows binary, and I'm running Linux. 
Would be nice if it could try to auto-detect based on my User-Agent, which 
includes the words "X11", "Ubuntu", and "Linux". Not quite as good for 
cache-ability, I know, but definitely a nicer user experience.

I like how go.dev looks quite good on a phone! Oh, and that they've kept 
the cute gopher(s).

-Ben

On Thursday, November 25, 2021 at 9:21:33 AM UTC+13 Hein Meling wrote:

> I also don’t like it very much… it is just too noisy. But I haven’t spent 
> enough time with it to really make a note of concrete issues.
>
> :) Hein
> On Tuesday, November 23, 2021 at 7:46:19 PM UTC+1 poe...@gmail.com wrote:
>
>> Am I the only one who thinks this? The old site golang.org had a simple 
>> and elegant design and appearance. It presented just most important 
>> information and essentials; the front page was small and straight to the 
>> point, and the navigation and site as a whole emphasized information and 
>> tools to get real work done. It was like the site embodied the principles 
>> and values of the Go language itself: simple, practical, and efficient; no 
>> bullshit. A site for programming professionals designed by programming 
>> professionals.
>>
>> Contrast with the new site go.dev: emphasizing and cluttered with sales 
>> pitch and persuasion tactics (as if Google's own successful usage and 
>> support for Go wasn't already enough to sell most people) and auxiliary 
>> information not directly relevant or helpful to the programming task at 
>> hand. The site looks and feels like it was designed by a third-party 
>> freelancer who just took a generic business template and added the color 
>> blue (the color of Go's logo). It displays no unique personality nor does 
>> it reflect the qualities of the Go language itself, unlike the old site. 
>> Sloppy margins and typography and obfuscated with auxiliary content, it 
>> seems no careful thought or subtlety has been given to its design or 
>> presentation.
>>
>> I can't think of one thing I like about the new site compared to the old 
>> one, and would like to see the old site make a comeback.
>>
>

-- 
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/e403cfac-3cea-446f-b334-a64993fa47a0n%40googlegroups.com.


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

2021-11-03 Thread ben...@gmail.com


> 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 every test, you can use a 
top-level test function for the "suite", and sub-tests with t.Run() for the 
individual tests, with the sub-tests closing over the db variable. Like so:

func TestDatabaseThings(t *testing.T) {
db := connectToDB(t)

t.Run("Foo", func (t *testing.T) {
fmt.Println(db, "test foo stuff") // use "db" and test stuff
})

t.Run("Bar", func (t *testing.T) {
fmt.Println(db, "test bar stuff") // use "db" and test stuff
})
}

-Ben

-- 
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/ba07e1df-e62a-4461-8f62-29b45255b7acn%40googlegroups.com.


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

2021-10-26 Thread ben...@gmail.com
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)
// handle err
request.Header.Set("X-My-Auth", "abcd1234")
response, err := client.Do(request)
// handle err
// handle response

Runnable code example here:
https://play.golang.org/p/cocv1avzNCo

And of course you can roll your own function to create a new request with 
auth headers already applied. Would this kind of thing work for you?

-Ben

On Tuesday, October 26, 2021 at 2:05:15 PM UTC+13 mi...@ubo.ro wrote:

> I find myself in need to handle various authentication schemes such 
> "proprietary" oauth2 schemes and NTLM. The easy and clean way to do it (API 
> wise) would be using a http.RoundTripper but looks like it forbids you from 
> even reading the response headers.
>
>  In the end I just made a ``func 
> DoHTTPRequestWithAuthenticationHandling(cl *http.Client, req 
> *http.Request)(*http.Response, error)`` function that just wraps  net/
> http.Client.Do(), clones the request and response if it's necessary and 
> negotiates the authentication scheme. It's basically what I wanted to do 
> within http.RoundTripper except now the user of the http.Client needs to 
> always remember to execute the requests the right way (i.e. using a 
> different function) instead of http.Do.
>
> Is there a better way to do it? Would it be a good idea  in Go 2.0  make 
> http.Client an interface to prevent this kind of limitation/workarounds?
>

-- 
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/f644c0aa-e7eb-4465-8b9f-d7214e11b7c9n%40googlegroups.com.


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

2021-10-03 Thread ben...@gmail.com
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 usage patterns, site design, etc. 
>>
>
> Yeah, fair enough. I shouldn't have side-tracked my own discussion. :-)
>
> -Ben
>

-- 
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/1d814ee1-a658-4285-b660-64c44dc4b0can%40googlegroups.com.


Re: [go-nuts] Creating a MQTT library

2021-09-19 Thread ben...@gmail.com


> 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 
> returns true.
> Message() []byte
> // Error returns the error reading the next message, if any.
> Error() err
> }
>
> and let the user use their own channels/goroutines, if they need it.
>
> That is what I would consider idiomatic Go. I would not consider it 
> idiomatic to return/accept channels as part of your API anymore.
>

I definitely agree with Axel on the blocking / non-blocking thing. 
Digressing from the main point, but it may be more idiomatic to just return 
a concrete type, like *mqtt.Reader or *mqtt.Connection (if your package 
name is "mqtt"). The concrete type will have the iterator methods, plus any 
others for MQTT-specific stuff. For example:

reader, err := mqtt.Dial("url") // reader is type *mqtt.Reader
if err != nil { ... }
for reader.Next() {
msg, err := reader.Message()
if err != nil { ... }
}
if reader.Err() != nil { ... }

The reason is that then it's easy for callers to call MQTT-specific methods 
on the concrete type as well. In parts of the program that *take* a message 
reader, however, you'll probably use a locally-defined interface with just 
the methods you need. If the mqtt package defines the interface, it'll 
invariably include more methods than most people need.

Other considerations:

* Perhaps call the error method just Err(). That's common, for example, 
bufio.Scanner.Err.
* Maybe make mqtt.Reader.Message() return an mqtt.Message struct, which has 
Bytes() and Text() methods, as well as other MQTT message-specific stuff 
(topic, message ID, etc).

-Ben

-- 
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/2ef6571d-3e9d-4220-bc61-f3ff5e2aa2bfn%40googlegroups.com.


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

2021-08-25 Thread ben...@gmail.com
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 
GitHub.com:

* 
https://cs.opensource.google/go/go/+/refs/tags/go1.17:src/os/exec/exec.go;l=189 
-- this loads in 4-5 seconds for me, with two client-side "loading..." 
states shown
* https://github.com/golang/go/blob/go1.17/src/os/exec/exec.go#L189 -- this 
loads in 1-1.5 seconds, with no loading states

I believe GitHub is faster because it serves the code in the initial HTML 
response, whereas cs.opensource.google serves a bunch of JavaScript that 
(after a couple of steps) loads the source. I believe the golang.org source 
used the GitHub approach -- at least, it was similar speed to GitHub so I 
never noticed this or needed to check.

I'm located in New Zealand, so it is no doubt further away from their 
origin servers than Google employees testing this stuff. (I asked a 
colleague from Australia, and he gets ~5s for cs.opensource, ~1s for 
GitHub.) I have a fast internet connection. The tests above are in the 
latest Firefox under Linux, but I've also tested using Chromium and get 
very similar results (on my first go in Chromium, which didn't have any 
cached, it was ~8s for cs.opensource.google and ~2s for GitHub, after that 
it was similar to the above).

It's frustrating, because most 3rd party packages (hosted on GitHub) get 
the faster GitHub view-source experience, but the core stdlib gets the slow 
experience!

Someone has suggested moving to GitHub in this issue: 
https://github.com/golang/go/issues/47202 ... however, it was more about 
the UI and got closed with "if you have suggestions for 
cs.opensource.google, use the Send Feedback button". I submitted feedback 
using that button, though I doubt that'll cause anyone to do a major 
rewrite of their architecture.

It seems to me that pages taking 4x as long to load is a series regression 
that hurts usability, at the very least outside the U.S. I use those stdlib 
source links a lot, and it's a bit of a killjoy to wait 4-8s each time.

I'm happy to open a new issue on this, but thought I'd see if others have 
input first.

-Ben

-- 
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/2e87b2f4-6828-44f9-807c-a83b08671d3an%40googlegroups.com.


[go-nuts] Re: Go 1.17 is released

2021-08-17 Thread ben...@gmail.com
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 
instead!

$ time goawk_go1.16 'BEGIN { for (i=0; i<1; i++) s += i; print(s) }'
49995000
real0m10.158s ...
$ time goawk_go1.17 'BEGIN { for (i=0; i<1; i++) s += i; print(s) }'
49995000
real0m6.268s ...

Overall for GoAWK I get an 18% speed increase on my micro-benchmarks 
between Go 1.16 and 1.17 (see 
https://github.com/benhoyt/goawk/commit/1f314f421273b3dc164ff4e5d41363f4ac4d160f)
 
and I measured an 8% speed increase on my "slightly more real-world" 
benchmarks that also do I/O 
(https://github.com/benhoyt/goawk/blob/master/benchmark_awks.py).

After some pointers from people (see 
https://news.ycombinator.com/item?id=28203608) and some digging into the 
assembly, I found that many of the function-call heavy methods in 
interp/interp.go do a lot less stack manipulation (as expected) but are 
also 60-70% of the size of the versions compiled with Go 1.16. The overall 
binary is not 60-70% smaller, of course (it's "only" 7% smaller), but the 
fact that these hot-loop interpreter functions are so much smaller is a 
good indication they're doing a lot less -- as confirmed by the perf 
numbers.

I know that some people haven't gotten as much as 5% improvement, and a few 
things actually slowed down, but I just wanted to share a success story.

-Ben

On Tuesday, August 17, 2021 at 10:08:11 AM UTC+12 Michael Knyszek wrote:

> Hello gophers,
>
> We just released Go 1.17
>
> To find out what has changed in Go 1.17, read the release notes:
> https://golang.org/doc/go1.17
>
> You can download binary and source distributions from our download page:
> https://golang.org/dl/
>
> If you have Go installed already, an easy way to try go1.17
> is by using the go command:
> $ go get golang.org/dl/go1.17
> $ go1.17 download
>
> To compile from source using a Git clone, update to the release with
> "git checkout go1.17" and build as usual.
>
> Thanks to everyone who contributed to the release!
>
> Cheers,
> Michael and Dmitri for the Go Team
>

-- 
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/a532710d-0261-4695-8f93-277a43cfe80dn%40googlegroups.com.


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

2021-07-14 Thread ben...@gmail.com
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 noticed that word sized datatypes can be stored directly in the data 
> field of an iface/eface, but I'm confused on how marking works with these 
> kinds of inline cases. I checked the mark routines in the runtime/gcmark.go 
> and couldn't find special casing for interfaces. How does the runtime know 
> when not to follow an interface's data pointer? Does it just scan that word 
> conservatively? How does the func's pointer map fit into this?
>
> In the current implementations the data field of an interface value is
> always a pointer. It was once true that small scalar values were
> stored directly in interface values, but that is no longer true today.
>
> 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/0e940dea-7e1a-41a4-ad8f-4784a943be98n%40googlegroups.com.


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

2021-06-06 Thread ben...@gmail.com


> 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 (others might find it useful or 
interesting too).

-Ben

-- 
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/b5336366-997a-44f2-bf20-ab6fe0e97264n%40googlegroups.com.


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

2021-03-24 Thread ben...@gmail.com
> 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 comparing to 
various legal systems, in which there is almost always the possibility of 
appeal, even for heinous crimes. Another aspect is that sometimes people 
change and realize their mistake later, sometimes even because of an 
excommunication like this. What's the rationale for "no possibility of 
appeal"?

-Ben


On Wednesday, March 24, 2021 at 3:01:37 AM UTC+13 can...@google.com wrote:

> Over the last few days, multiple reports were received at 
> con...@golang.org regarding public conduct on golang-nuts, as well as 
> conduct in private channels.  After review, permanent bans were given to 
> multiple individuals, with no possibility for appeal.  Further corrective 
> actions like temporary bans and final warnings are being deliberated, 
> pending further investigation. 
>
> As stated in our Code of Conduct , we believe 
> that healthy debate and disagreement are essential to a healthy project and 
> community. However, it is never ok to be disrespectful. 
>
> When evaluating a response to a report and making decisions on a 
> corrective action, the Go CoC committee takes into account the
>
> * severity of the conduct violation
> * impact of conduct on individuals who report to con...@golang.org
> * impact of conduct on the community (bystanders, those not directly 
> involved in CoC reports) 
> * conduct history in all Go project spaces, assessing patterns of behavior 
> across multiple sites versus one-off or "most recent only" conduct 
> incidents. 
> * impact to people of marginalized groups
>
> The last two factors also necessitate a public response, to assure those 
> who witness unacceptable behavior, particularly in public places, that 
> appropriate and fair corrective action was taken.  
>  
> We pledge  to make participation 
> in the Go project* and our community a harassment-free experience for 
> everyone. 
>
> Thank You,
> Carmen Andoh
> on behalf of the Go CoC committee
>
> *Go project spaces include all golang-* googlegroups, github/golang/go 
> issue repo, and other online forums where the Go CoC is in effect. 
>

-- 
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/cbda73ba-78a4-4f9a-ad2b-59e6e6ce2c19n%40googlegroups.com.


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

2021-02-17 Thread ben...@gmail.com
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 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.
>
> The transpiller:
> C Front end: https://pkg.go.dev/modernc.org/cc/v3
> Go back end: https://pkg.go.dev/modernc.org/ccgo/v3
>
> How it works:
> The front end produces type annotated ASTs for the translation units,
> the back end links the ASTs and renders them as Go code.
>
> Pitfalls:
> The linker is memory only and memory hungry. ccgo has not yet any
> object file format for separating the compilation and linking phases.
>
> Unsupported:
> Most gcc extensions. Many C99-specific things. They are being added as
> needed when I run into a blocking issue with some C -> Go project.
> Recently for example: https://gitlab.com/cznic/tk
>
> Feel free to ask more specific questions. Perhaps off-list or at the
> issue tracker(s). There are also Slack channels #sqlite and
> #modernc_cc at gophers.slack.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/2c32fed5-e29c-404e-b44a-b77328b309cbn%40googlegroups.com.


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

2021-02-16 Thread ben...@gmail.com
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 7:38:12 AM UTC+13 Jan Mercl wrote:

> On Sat, Jan 23, 2021 at 7:02 PM sup...@lieferpool.de
>  wrote:
>
> > If you want sqlite3 support without cgo, you might check out
> > https://github.com/cvilsmeier/sqinn-go
>
> Shameless plug: https://pkg.go.dev/modernc.org/sqlite
>

-- 
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/37809716-6deb-4b8b-be81-08a3c618cb17n%40googlegroups.com.


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

2020-12-22 Thread ben...@gmail.com
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 BenchmarkValue(b *testing.B) {
> for n := 0; n < b.N; n++ {
> sv := IntValue(0)
> for i := 0; i < 1000; i++ {
> iv := IntValue(int64(i))
> sv, _ = add(nil, sv, iv) // add is the "real" lua runtime 
> function that adds two numeric values.
> }
> }
> }
>
> Results with the "scalar" version
>
> $ go test -benchmem -run=^$ -bench '^(BenchmarkValue)$' ./runtime
> goos: darwin
> goarch: amd64
> pkg: github.com/arnodel/golua/runtime
> cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
> BenchmarkValue-8  122995  9494 ns/op   0 
> B/op  0 allocs/op
> PASS
> ok  github.com/arnodel/golua/runtime1.415s
>
> Results without the "scalar" version (noscalar build tag)
>
> $ go test -benchmem -run=^$ -tags noscalar  -bench '^(BenchmarkValue)$' 
> ./runtime
> goos: darwin
> goarch: amd64
> pkg: github.com/arnodel/golua/runtime
> cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
> BenchmarkValue-8   37407 32357 ns/op   13768 
> B/op   1721 allocs/op
> PASS
> ok  github.com/arnodel/golua/runtime1.629s
>
> That looks like a pretty big improvement :)
>
> The improvement is also significant in real workloads but not.so dramatic 
> (given they don't spend all their time manipulating scalar values!)
>
>

-- 
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/95987174-9372-4a02-ba5c-8148cab31810n%40googlegroups.com.


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

2020-12-21 Thread ben...@gmail.com
Nice! Do you have any benchmarks on how much faster the "scalar" version is 
than the non-scalar?

On Tuesday, December 22, 2020 at 12:58:19 AM UTC+13 arn...@gmail.com wrote:

> Just an update (in case anyone is interested!).  I went for the approach 
> described below of having a Value type holding a scalar for quick access to 
> values that fit in 64 bits (ints, floats, bools) and an interface fo for 
> the rest.
>
> type Value struct {
> scalar uint64
> iface interface{}
> }
>
> That significantly decreased memory management pressure on the program for 
> many workloads, without having to manage a pool of say integer values.  It 
> also had the consequence of speeding up many arithmetic operations.  Thanks 
> all for your explanations and suggestions!
>
> -- 
> Arnaud
>
> On Wednesday, 16 December 2020 at 11:15:32 UTC Arnaud Delobelle wrote:
>
>> Ah interesting, I guess that could mean I would need to switch to using 
>> reflect.Value as the "value" type in the Lua runtime.  I am unclear about 
>> the performance consequences, but I guess I could try to measure that.
>>
>> Also, looking at the implementation of reflect, its seems like the Value 
>> type I suggested in my reply to Ben [1] is a "special purpose" version of 
>> reflect.Value - if you squint at it from the right angle!
>>
>> -- 
>> Arnaud
>>
>> [1]
>> type Value struct {
>> scalar uint64
>> iface interface{}
>> }
>> On Wednesday, 16 December 2020 at 00:56:52 UTC Keith Randall wrote:
>>
>>> Unfortunately for you, interfaces are immutable. We can't provide a 
>>> means to create an interface from a pointer, because then the user can 
>>> modify the interface using the pointer they constructed it with (as you 
>>> were planning to do).
>>>
>>> You could use a modifiable reflect.Value for this.
>>>
>>> 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 need to use v.Int().
>>> Of course, reflection has its own performance gotchas. It will solve 
>>> this problem but may surface others.
>>> On Tuesday, December 15, 2020 at 12:04:54 PM UTC-8 ben...@gmail.com 
>>> wrote:
>>>
>>>> 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   string// String value (for typeStr)
>>>> n   float64   // Numeric value (for typeNum and typeNumStr)
>>>> }
>>>>
>>>> Code here: 
>>>> https://github.com/benhoyt/goawk/blob/22bd82c92461cedfd02aa7b8fe1fbebd697d59b5/interp/value.go#L22-L27
>>>>
>>>> Initially I actually used "type Value interface{}" as well, but I 
>>>> switched to the above primarily to model the funky AWK "numeric string" 
>>>> concept. However, I seem to recall that it had a significant performance 
>>>> benefit too, as passing everything by value avoided a number of 
>>>> allocations.
>>>>
>>>> Lua has more types to deal with, but you could try something similar. 
>>>> Or maybe include int64 (for bool as well) and string fields, and 
>>>> everything 
>>>> else falls back to interface{}? It'd be a fairly large struct, so not sure 
>>>> it would help ... you'd have to benchmark it. But I'm thinking something 
>>>> like this:
>>>>
>>>> type Value struct {
>>>> typ valueType
>>>> i int64 // for typ = bool, integer
>>>> s string // for typ = string
>>>> v interface{} // for typ = float, other
>>>> }
>>>>
>>>> -Ben
>>>>
>>>> On Wednesday, December 16, 2020 at 6:50:05 AM UTC+13 arn...@gmail.com 
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> The context for this question is that I am working on a pure Go 
>>>>> implementation of Lua [1] (as a personal project).  Now that it is more 
>>>>> or 
>>>>> less functio

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

2020-12-20 Thread ben...@gmail.com
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 appear 
right away. So I realized it made sense, and gives you more control. And 
it's so easy to wrap it in a bufio.NewWriter() ... Flush() if you need 
buffering.

I ran into this exact same issue when implementing GoAWK ... a 10-line fix 
gave me a 10x speedup. 
https://github.com/benhoyt/goawk/commit/60745c3503ba3d99297816f5c7b5364a08ec47ab

-Ben

On Monday, December 21, 2020 at 12:27:43 AM UTC+13 arn...@gmail.com wrote:

> Ah, that is it, thank you!
>
> On Sunday, 20 December 2020 at 11:06:05 UTC Jan Mercl wrote:
>
>> On Sun, Dec 20, 2020 at 11:53 AM Arnaud Delobelle  
>> wrote:
>>
>> > TLDR; a simple test program appears to show that Go's (*os.File).Write 
>> is 10x slower than C's fputs (on MacOS).
>>
>> Apples and oranges. fputs buffers, os.File does not. Rewrite the
>> benchmark using bufio.
>>
>

-- 
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/909fa4da-1c74-4c33-98c1-185e6bae9d40n%40googlegroups.com.


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

2020-12-15 Thread ben...@gmail.com
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   string// String value (for typeStr)
n   float64   // Numeric value (for typeNum and typeNumStr)
}

Code here: 
https://github.com/benhoyt/goawk/blob/22bd82c92461cedfd02aa7b8fe1fbebd697d59b5/interp/value.go#L22-L27

Initially I actually used "type Value interface{}" as well, but I switched 
to the above primarily to model the funky AWK "numeric string" concept. 
However, I seem to recall that it had a significant performance benefit 
too, as passing everything by value avoided a number of allocations.

Lua has more types to deal with, but you could try something similar. Or 
maybe include int64 (for bool as well) and string fields, and everything 
else falls back to interface{}? It'd be a fairly large struct, so not sure 
it would help ... you'd have to benchmark it. But I'm thinking something 
like this:

type Value struct {
typ valueType
i int64 // for typ = bool, integer
s string // for typ = string
v interface{} // for typ = float, other
}

-Ben

On Wednesday, December 16, 2020 at 6:50:05 AM UTC+13 arn...@gmail.com wrote:

> Hi
>
> The context for this question is that I am working on a pure Go 
> implementation of Lua [1] (as a personal project).  Now that it is more or 
> less functionally complete, I am using pprof to see what the main CPU 
> bottlenecks are, and it turns out that they are around memory management.  
> The first one was to do with allocating and collecting Lua "stack frame" 
> data, which I improved by having add-hoc pools for such objects.
>
> The second one is the one that is giving me some trouble. Lua is a 
> so-called "dynamically typed" language, i.e. values are typed but variables 
> are not.  So for easy interoperability with Go I implemented Lua values 
> with the type
>
> // Go code
> type Value interface{}
>
> The scalar Lua types are simply implemented as int64, float64, bool, 
> string with their type "erased" by putting them in a Value interface.  The 
> problem is that the Lua runtime creates a great number of short lived Value 
> instances.  E.g.
>
> -- Lua code
> for i = 0, 10 do
> n = n + i
> end
>
> When executing this code, the Lua runtime will put the values 0 to 1 
> billion into the register associated with the variable "i" (say, r_i).  But 
> because r_i contains a Value, each integer is converted to an interface 
> which triggers a memory allocation.  The critical functions in the Go 
> runtime seem to be convT64 and mallocgc.
>
> I am not sure how to deal with this issue.  I cannot easily create a pool 
> of available values because Go presents say Value(int64(1000)) as an 
> immutable object to me, so I cannot keep it around for later use to hold 
> the integer 1001.  To be more explicit
>
> // Go code
> i := int64(1000)
> v := Value(i) // This triggers an allocation (because the interface 
> needs a pointer)
> // Here the Lua runtime can work with v (containing 1000)
> j := i + 1
> // Even though v contains a pointer to a heap location, I cannot 
> modify it
> v := Value(j) // This triggers another allocation
> // Here the Lua runtime can work with v (containing 1001)
>
>
> I could perhaps use a pointer to an integer to make a Value out of.  This 
> would allow reuse of the heap location.
>
> // Go code
> p :=new(int64) // Explicit allocation
> vp := Value(p)
> i :=int64(1000)
> *p = i // No allocation
> // Here the Lua runtime can work with vp (contaning 1000)
> j := i + 1
> *p = j // No allocation
> // Here the Lua runtime can work with vp (containing 1001)
>
> But the issue with this is that Go interoperability is not so good, as Go 
> int64 now map to (interfaces holding) *int64 in the Lua runtime.
>
> However, as I understand it, in reality interfaces holding an int64 and an 
> *int64 both contain the same thing (with a different type annotation): a 
> pointer to an int64.
>
> Imagine that if somehow I had a function that can turn an *int64 to a 
> Value holding an int64 (and vice-versa):
>
> func Int64PointerToInt64Iface(p *int16) interface{} {
> // returns an interface that has concrete type int64, and points 
> at p
> }
>
> func int64IfaceToInt64Pointer(v interface{}) *int64 {
> // returns the pointer that v holds
> }
>
>  then I would be able to "pool" the allocations as follows:
>
> func NewIntValue(n int64) Value {
> v = getFromPool()
> if p == nil {
> return Value(n)
> }
> *p = n
> return Int64PointerToint64Iface(p)
> }
>
> func ReleaseIntValue(v Value) {
> addToPool(Int64IPointerFromInt64Iface(v))
> }
>
> func 

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

2020-11-19 Thread ben...@gmail.com
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, September 17, 2015 at 2:16:06 PM UTC+12 Th3x0d3r wrote:

> What I'm trying to do is:
>
> out, err := exec.Command("echo","%PROCESSOR_ARCHITECTURE%").Output()
>
> but same result:
>
> *exec: "echo": executable file not found in %PATH%*
>
>

-- 
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/c8873199-57e1-47b0-9b2b-7c9c49af8288n%40googlegroups.com.


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

2020-08-04 Thread ben...@gmail.com

>
> 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 would quickly become a well-known idiom, just like people know 
> that "error" is "interface{Error() string}" or "fmt.Stringer" is 
> "interface{String() string}".
>

That's fair enough -- I think you're right.

Actually the current use of "interface{}" is a bit odd because it is the 
> only case where an interface is commonly used as an anonymous type rather 
> than by an identifier.
>

Interesting point. My brain usually thinks of "interface{}" as a special 
concept/syntax (and I suspect I'm not alone), even though I know it's not!

I assume that in current Go the empty interface is supposed to be an ugly 
> duckling to discourage its overuse, but in a world with type parameters it 
> will play an important role as the unbounded constraint and it should 
> deserve its own identifier.
>

Very well stated, and I agree.

-Ben

-- 
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/a38219fb-9a33-48e1-929b-d17080bb9125n%40googlegroups.com.


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

2020-07-02 Thread ben...@gmail.com
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 uneasy.

For example, the Smallest() function in this proposal takes a slice of []T, 
where T is "type T constraints.Ordered", a type-list based constraint. That 
means Smallest() will only work with the built-in types specified in the 
type list (or types with one of those as an underlying type), and can't be 
used with more complex struct types.

For it to work for other types, you'd have to write a second version of 
Smallest() -- code duplication -- that took a method-interface based 
constraint like so:

type CustomOrdered(type T) interface {
Less(other T) bool
}

Arguably Smallest() would still be quite useful even if it only works for 
builtin integer and float point types, but with the type-list Ordered it 
wouldn't work for (say) big.Int, a custom Decimal type, or a more complex 
struct type.

But I think this is worse for ordering-based *data structures* like Tree of 
T. If done with the type-list Ordered, the tree could only store built-in 
types, which isn't that useful. Using a constraint like CustomOrdered would 
work and be more flexible ... but then a basic Tree(int) wouldn't work. 
You'd have to do Tree(MyInt) and convert everything from int to MyInt on 
the way in, and MyInt back to int on the way out -- a bunch of type 
conversion boilerplate.

Or you'd end up writing two versions of your generic Tree: BuiltinTree that 
uses Ordered (type lists), and CustomTree that uses CustomOrdered 
(interface with Less). Not very nice.

(Here's some Go2Go code which shows this for Smallest: 
https://go2goplay.golang.org/p/Rbs374BqPWw)

I'm not sure how the proposal solves this for something like Smallest() ... 
I don't think it does. For ordered data structures, like the Map example, 
it passes in a custom "compare" function to the initializer and kind of 
side-steps the issue. Which isn't bad for data structures as it'd still 
eliminate a lot of code, but it would be kind of a pain for little 
algorithms like Smallest().

Thoughts?

-Ben

-- 
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/7f471eba-be08-4d32-a50a-22939f63b76dn%40googlegroups.com.


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

2020-06-30 Thread ben...@gmail.com
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 the 
files to see what the build constraint is.

Then again, if Go got rid of filename-based constraints, people could still 
name their files like that for visibility purposes, but the actual build 
constraint would be in "// +build" or "//go:build" rules in the file itself.

-Ben

One thing I'd really like to see is the eventual deprecation of 
>>> filename-based build constraints (e.g. file_linux.go).
>>> They make it hard for users (not everyone knows the name of all 
>>> architectures), hard for tooling (tools
>>> need to maintain a list of current architectures) and potentially 
>>> compatibility-breaking (adding
>>> a new architecture can change the meaning of existing files). Could we 
>>> eventually mandate
>>> in-file build constraints instead?
>>>
>>

-- 
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/82154e18-c273-4969-8a8c-f7a04dda5109n%40googlegroups.com.