Re: [go-nuts] Various questions about posts from The Go Blog

[t hepudds]

Hi Kamil,

FWIW, you probably would be better off going through the official module
tutorials:

  "Tutorial: Get started with Go" --
https://go.dev/doc/tutorial/getting-started.html
  "Tutorial: Create a Go module" --
https://go.dev/doc/tutorial/create-module

Those are listed at the start of the official Go documentation page (
https://go.dev/doc/).

The blog posts you are going through and asking about are older (from 2019
or so, I think), and as such are snapshots in time to some degree.

The behavior of the 'go' tool has changed somewhat since those blog posts
were first published. Two notable examples of changes in behavior, which
might explain some of what you encountered:


Go 1.16 release (https://go.dev/doc/go1.16#go-command)

"Build commands like go build and go test no longer modify go.mod and
go.sum by default. Instead, they report an error if a module requirement or
checksum needs to be added or updated [...]. Module requirements and sums
may be adjusted with go mod tidy or go get."


Go 1.17 release (https://go.dev/doc/go1.17#go-command)

"[...] the go.mod file for each module needs to include more detail about
the transitive dependencies relevant to that module. If a module specifies
go 1.17 or higher in its go.mod file, its go.mod file now contains an
explicit require directive for every module that provides a
transitively-imported package. (In previous versions, the go.mod file
typically only included explicit requirements for directly-imported
packages.)"

FWIW, both of those changes were large improvements, and were heavily based
on feedback from the broader community.

Best regards,
thepudds


On Sun, Mar 26, 2023 at 2:01 PM Kamil Ziemian  wrote:

> Jan Mercl you right that only TestHello is broken, but it is still broken.
> As I said, the fact that such simple code in not portable is disturbing. I
> guess most of the code is tested on OS with English as the main language,
> at least code for this blog post seems to be, so you can guess what else
> may be broken but such silly bug? I guess not much, but this is still
> disturbing.
>
> I have another problem, I don't understand what happened since version
> 1.13 of Go with go.mod file. According to the post "Using Go Modules"
> https://go.dev/blog/using-go-modules "Only direct dependencies are
> recorded in the go.mod file". Today it seems that go.mod also list indirect
> dependencies, which is very good idea.
>
> But I cannot understand why in the blog post we have in go.mod file
> require rsc.io/quote v1.5.2
> so "rsc.io/quote" is considered direct dependency, while go.mod produced
> by Go 1.20 give me
> rsc.io/quote v1.5.2 // indirect
> so now "rsc.io/quote" is indirect dependency, even when I write in package
> import "rsc.io/quote"
>
> I would be glad for any word of explanation.
>
> Best regards,
> Kamil
>
> niedziela, 26 marca 2023 o 19:55:52 UTC+2 Jan Mercl napisał(a):
>
>> The only broken thing in the code below is the TestHello function.
>> rsc.io/quote uses rsc.io/sampler where the Hello func
>> (https://pkg.go.dev/rsc.io/sampler#Hello) is documented to return a
>> localized string by default. Localized, in the sense of respecting the
>> user's locale. That is not compatible with your test function
>> expecting to always get the same string regardless of locale. That's a
>> bug.
>>
>> On Sun, Mar 26, 2023 at 7:47 PM Kamil Ziemian 
>> wrote:
>>
>> > According to the law that any change can break your program/workflow, I
>> want to mention that code shown in "Using Go Modules"
>> https://go.dev/blog/using-go-modules is broken in funny way.
>> >
>> > Consider code below
>> > package hello
>> >
>> > import "rsc.io/quote"
>> >
>> > func Hello() string {
>> > return quote.Hello()
>> > }
>> >
>> > We also have test file
>> > package hello
>> >
>> > import "testing"
>> >
>> > func TestHello(t *testing.T) {
>> > want := "Hello, world."
>> > if got := Hello(); got != want {
>> > t.Errorf("Hello() = %q, want %q", got, want)
>> > }
>> > }
>> >
>> > So I run `go test' and get
>> > --- FAIL: TestHello (0.00s)
>> > hello_test.go:9: Hello() = "Witaj świecie.", want "Hello, world."
>> > FAIL
>> > exit status 1
>> > FAIL example.com/hello 0.002s
>> >
>> > What happened? My first language is polish, so my system, Ubuntu 22.04,
>> use it as main language. In some way "rsc.io/quote" figure it out and
>> now function quote.Hello() returns "Witaj świecie.", which in polish mean
>> "Hello, world.". Since we compered result we get with string "Hello,
>> world." we obviously fail the test.
>> >
>> > This is just teaching example, so this is not so big deal, but fact
>> that some code of this type is not portable between OS with different

Re: [go-nuts] Various questions about posts from The Go Blog

['Jakob Borg' via golang-nuts]

On 26 Mar 2023, at 20:01, Kamil Ziemian  wrote:

But I cannot understand why in the blog post we have in go.mod file
require rsc.io/quote v1.5.2
so "rsc.io/quote" is considered direct dependency, while 
go.mod produced by Go 1.20 give me
rsc.io/quote v1.5.2 // indirect
so now "rsc.io/quote" is indirect dependency, even when I 
write in package
import "rsc.io/quote”

That doesn’t happen for me though:

% cat hello.go
package hello

import "rsc.io/quote"

func Hello() string {
return quote.Hello()
}

% go mod init example.com/hello
go: creating new go.mod: module example.com/hello
go: to add module requirements and sums:
go mod tidy

% go mod tidy
go: finding module for package rsc.io/quote
go: found rsc.io/quote in rsc.io/quote v1.5.2

% cat go.mod
module example.com/hello

go 1.20

require rsc.io/quote v1.5.2

require (
golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c // indirect
rsc.io/sampler v1.3.0 // indirect
)

-- 
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/067B34F7-F369-4622-8CBD-5BE3BA44DC3C%40kastelo.net.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Jan Mercl you right that only TestHello is broken, but it is still broken. 
As I said, the fact that such simple code in not portable is disturbing. I 
guess most of the code is tested on OS with English as the main language, 
at least code for this blog post seems to be, so you can guess what else 
may be broken but such silly bug? I guess not much, but this is still 
disturbing.

I have another problem, I don't understand what happened since version 1.13 
of Go with go.mod file. According to the post "Using Go Modules" 
https://go.dev/blog/using-go-modules "Only direct dependencies are recorded 
in the go.mod file". Today it seems that go.mod also list indirect 
dependencies, which is very good idea.

But I cannot understand why in the blog post we have in go.mod file
require rsc.io/quote v1.5.2
so "rsc.io/quote" is considered direct dependency, while go.mod produced by 
Go 1.20 give me
rsc.io/quote v1.5.2 // indirect
so now "rsc.io/quote" is indirect dependency, even when I write in package
import "rsc.io/quote"

I would be glad for any word of explanation.

Best regards,
Kamil

niedziela, 26 marca 2023 o 19:55:52 UTC+2 Jan Mercl napisał(a):

> The only broken thing in the code below is the TestHello function.
> rsc.io/quote uses rsc.io/sampler where the Hello func
> (https://pkg.go.dev/rsc.io/sampler#Hello) is documented to return a
> localized string by default. Localized, in the sense of respecting the
> user's locale. That is not compatible with your test function
> expecting to always get the same string regardless of locale. That's a
> bug.
>
> On Sun, Mar 26, 2023 at 7:47 PM Kamil Ziemian  wrote:
>
> > According to the law that any change can break your program/workflow, I 
> want to mention that code shown in "Using Go Modules" 
> https://go.dev/blog/using-go-modules is broken in funny way.
> >
> > Consider code below
> > package hello
> >
> > import "rsc.io/quote"
> >
> > func Hello() string {
> > return quote.Hello()
> > }
> >
> > We also have test file
> > package hello
> >
> > import "testing"
> >
> > func TestHello(t *testing.T) {
> > want := "Hello, world."
> > if got := Hello(); got != want {
> > t.Errorf("Hello() = %q, want %q", got, want)
> > }
> > }
> >
> > So I run `go test' and get
> > --- FAIL: TestHello (0.00s)
> > hello_test.go:9: Hello() = "Witaj świecie.", want "Hello, world."
> > FAIL
> > exit status 1
> > FAIL example.com/hello 0.002s
> >
> > What happened? My first language is polish, so my system, Ubuntu 22.04, 
> use it as main language. In some way "rsc.io/quote" figure it out and now 
> function quote.Hello() returns "Witaj świecie.", which in polish mean 
> "Hello, world.". Since we compered result we get with string "Hello, 
> world." we obviously fail the test.
> >
> > This is just teaching example, so this is not so big deal, but fact that 
> some code of this type is not portable between OS with different languages 
> is a bit disturbing.
>

-- 
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/86f5e89b-f65b-4936-9d59-75192e8fa6d2n%40googlegroups.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Jan Mercl]

The only broken thing in the code below is the TestHello function.
rsc.io/quote uses rsc.io/sampler where the Hello func
(https://pkg.go.dev/rsc.io/sampler#Hello) is documented to return a
localized string by default. Localized, in the sense of respecting the
user's locale. That is not compatible with your test function
expecting to always get the same string regardless of locale. That's a
bug.

On Sun, Mar 26, 2023 at 7:47 PM Kamil Ziemian  wrote:

> According to the law that any change can break your program/workflow, I want 
> to mention that code shown in "Using Go Modules" 
> https://go.dev/blog/using-go-modules is broken in funny way.
>
> Consider code below
> package hello
>
> import "rsc.io/quote"
>
> func Hello() string {
> return quote.Hello()
> }
>
> We also have test file
> package hello
>
> import "testing"
>
> func TestHello(t *testing.T) {
> want := "Hello, world."
> if got := Hello(); got != want {
> t.Errorf("Hello() = %q, want %q", got, want)
> }
> }
>
> So I run `go test' and get
> --- FAIL: TestHello (0.00s)
> hello_test.go:9: Hello() = "Witaj świecie.", want "Hello, world."
> FAIL
> exit status 1
> FAIL example.com/hello 0.002s
>
> What happened? My first language is polish, so my system, Ubuntu 22.04, use 
> it as main language. In some way "rsc.io/quote" figure it out and now 
> function quote.Hello() returns "Witaj świecie.", which in polish mean "Hello, 
> world.". Since we compered result we get with string "Hello, world." we 
> obviously fail the test.
>
> This is just teaching example, so this is not so big deal, but fact that some 
> code of this type is not portable between OS with different languages is a 
> bit disturbing.

-- 
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/CAA40n-UvP9FzMzUyTVzFdKnb%2BHo_zjnonvyUa%3DtchEWu7JV4Ug%40mail.gmail.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Hello,

According to the law that any change can break your program/workflow, I 
want to mention that code shown in "Using Go Modules" 
https://go.dev/blog/using-go-modules is broken in funny way.

Consider code below
package hello

import "rsc.io/quote"

func Hello() string {
return quote.Hello()
}

We also have test file
package hello

import "testing"

func TestHello(t *testing.T) {
want := "Hello, world."
if got := Hello(); got != want {
t.Errorf("Hello() = %q, want %q", got, want)
}
}

So I run `go test' and get
--- FAIL: TestHello (0.00s)
hello_test.go:9: Hello() = "Witaj świecie.", want "Hello, world."
FAIL
exit status 1
FAIL example.com/hello 0.002s

What happened? My first language is polish, so my system, Ubuntu 22.04, use 
it as main language. In some way "rsc.io/quote" figure it out and now 
function quote.Hello() returns "Witaj świecie.", which in polish mean 
"Hello, world.". Since we compered result we get with string "Hello, 
world." we obviously fail the test.

This is just teaching example, so this is not so big deal, but fact that 
some code of this type is not portable between OS with different languages 
is a bit disturbing.

Best regards,
Kamil

niedziela, 26 marca 2023 o 19:36:59 UTC+2 Kamil Ziemian napisał(a):

> Hello,
>
> I try to learn how to use Go modules and Google PhD, recomended me Go blog 
> post "Using Go Modules" https://go.dev/blog/using-go-modules. It seems a 
> bit outdated and I want ask, if it so, should I use other source? I should 
> mention that I like Go blog.
>
> Example of things outdated, considering Go 1.20.
> 1) Running `go test' in directory without Go module doesn't run a test, 
> but writes something like "go: cannot find go module but find .git/confing 
> in ...".
> 2) After adding `import "rsc.io/quote"` to package hello, running go test 
> doesn't download for you rsc.io/quote, but insted you get
> hello.go:3:8: no required module provides package rsc.io/quote; to add it:
> go get rsc.io/quote
>
> I consider both changes improvement of Go workflow, but they may be 
> confused for total begginers.
>
> Best regards,
> Kamil
> poniedziałek, 24 stycznia 2022 o 23:56:46 UTC+1 Ian Lance Taylor 
> napisał(a):
>
>> On Mon, Jan 24, 2022 at 6:38 AM Kamil Ziemian  
>> wrote:, 
>> > 
>> > I have one more think to say about Go blog post "Why generics?". Again, 
>> nothing really important. 
>> > 
>> > In the section "Generic data structures" in the second counting from 
>> the end code example we have line. 
>> > > *pn = (E){val: v} 
>> > It is commented by the sentence "Notice the type argument E to the type 
>> node.". Maybe it should be "Notice the type argument E send to the type 
>> node."? Currently it sound odd to my ears. 
>> > 
>> > Also, I found out that in "Go 1.18 Beta 1 is available, with generics" (
>> https://go.dev/blog/go1.18beta1) written by Russ Cox on behalf of the Go 
>> team, post "Why generics?" is referenced in prominent place in third 
>> paragraph. I think it another reason to add block text to "Why generics?" 
>> to make clear for readers that they need to be aware, that actually 
>> implementation in beta of Go 18 at syntax level is quite different than 
>> that presented in this blog post. 
>> > 
>> > Best, 
>> > Kamil Ziemian 
>> > poniedziałek, 24 stycznia 2022 o 12:47:11 UTC+1 Kamil Ziemian 
>> napisał(a): 
>> >> 
>> >> Hello, 
>> >> 
>> >> Since with release of Go 1.18 we will have Go's generics, I started a 
>> preparation tour around Go blog and YouTube. And here is one suggestion and 
>> one unimportant comment of mine about blog post "Why Generics?" (
>> https://go.dev/blog/why-generics). 
>> >> 
>> >> This post is in my opinion very valuable, fortunately Go team abandons 
>> change few ideas to better ones, like removing concept of "contracts" in 
>> the name of new functionality of interfaces. In such situation I propose to 
>> add at the top of the page text block saying "Caution. Implementation of 
>> generics in Go different from draft discussed here. To learn about actual 
>> implementation of generics check [link to relevant materials]." 
>> >> 
>> >> Now unimportant comment. At the end of the section "Ordered types" we 
>> have paragraph 
>> >> "In practice this contract would probably go into the standard 
>> library, and so really the Min function (which will probably also be in the 
>> standard library somewhere) will look like this. Here we’re just referring 
>> to the contract Ordered defined in the package contracts." 
>> >> All this text use one kind of font, which contrast with all the rest 
>> of the post. Names of Go functions such as "Min" and meta-types as 
>> "Ordered" to this point was always typed with different font. I think this 
>> is simple, unimportant mistake. 
>>
>>
>> Thanks, I sent https://go.dev/cl/380574 to address these issues. 
>>
>> Ian 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from 

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Hello,

I try to learn how to use Go modules and Google PhD, recomended me Go blog 
post "Using Go Modules" https://go.dev/blog/using-go-modules. It seems a 
bit outdated and I want ask, if it so, should I use other source? I should 
mention that I like Go blog.

Example of things outdated, considering Go 1.20.
1) Running `go test' in directory without Go module doesn't run a test, but 
writes something like "go: cannot find go module but find .git/confing in 
...".
2) After adding `import "rsc.io/quote"` to package hello, running go test 
doesn't download for you rsc.io/quote, but insted you get
hello.go:3:8: no required module provides package rsc.io/quote; to add it:
go get rsc.io/quote

I consider both changes improvement of Go workflow, but they may be 
confused for total begginers.

Best regards,
Kamil
poniedziałek, 24 stycznia 2022 o 23:56:46 UTC+1 Ian Lance Taylor napisał(a):

> On Mon, Jan 24, 2022 at 6:38 AM Kamil Ziemian  wrote:,
> >
> > I have one more think to say about Go blog post "Why generics?". Again, 
> nothing really important.
> >
> > In the section "Generic data structures" in the second counting from the 
> end code example we have line.
> > > *pn = (E){val: v}
> > It is commented by the sentence "Notice the type argument E to the type 
> node.". Maybe it should be "Notice the type argument E send to the type 
> node."? Currently it sound odd to my ears.
> >
> > Also, I found out that in "Go 1.18 Beta 1 is available, with generics" (
> https://go.dev/blog/go1.18beta1) written by Russ Cox on behalf of the Go 
> team, post "Why generics?" is referenced in prominent place in third 
> paragraph. I think it another reason to add block text to "Why generics?" 
> to make clear for readers that they need to be aware, that actually 
> implementation in beta of Go 18 at syntax level is quite different than 
> that presented in this blog post.
> >
> > Best,
> > Kamil Ziemian
> > poniedziałek, 24 stycznia 2022 o 12:47:11 UTC+1 Kamil Ziemian napisał(a):
> >>
> >> Hello,
> >>
> >> Since with release of Go 1.18 we will have Go's generics, I started a 
> preparation tour around Go blog and YouTube. And here is one suggestion and 
> one unimportant comment of mine about blog post "Why Generics?" (
> https://go.dev/blog/why-generics).
> >>
> >> This post is in my opinion very valuable, fortunately Go team abandons 
> change few ideas to better ones, like removing concept of "contracts" in 
> the name of new functionality of interfaces. In such situation I propose to 
> add at the top of the page text block saying "Caution. Implementation of 
> generics in Go different from draft discussed here. To learn about actual 
> implementation of generics check [link to relevant materials]."
> >>
> >> Now unimportant comment. At the end of the section "Ordered types" we 
> have paragraph
> >> "In practice this contract would probably go into the standard library, 
> and so really the Min function (which will probably also be in the standard 
> library somewhere) will look like this. Here we’re just referring to the 
> contract Ordered defined in the package contracts."
> >> All this text use one kind of font, which contrast with all the rest of 
> the post. Names of Go functions such as "Min" and meta-types as "Ordered" 
> to this point was always typed with different font. I think this is simple, 
> unimportant mistake.
>
>
> Thanks, I sent https://go.dev/cl/380574 to address these issues.
>
> 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/c59285e5-4dde-4e0c-a9e9-036f84439352n%40googlegroups.com.

[go-nuts] Performance of byte-arrays as map keys

[Amit Lavon]

Hi gophers,

Some code I am writing uses byte-arrays ([X]byte) as keys in a map. I 
benchmarked the performance of map operations using different X's and found 
that 4 and 8 are about twice as fast compared to 5, 6, 7 (see below).

Can someone explain this phenomenon?
I'd like to learn about it so I can take it in consideration when choosing 
key types.


Code:

type byteArray interface {
[4]byte | [5]byte | [6]byte | [7]byte | [8]byte
}

func benchmarkMaps[T byteArray](b *testing.B) {
m := map[T]int{}
var t T
for i := 0; i < b.N; i++ {
m[t]++
}
}

func BenchmarkMaps(b *testing.B) {
b.Run("4", benchmarkMaps[[4]byte])
b.Run("5", benchmarkMaps[[5]byte])
b.Run("6", benchmarkMaps[[6]byte])
b.Run("7", benchmarkMaps[[7]byte])
b.Run("8", benchmarkMaps[[8]byte])
}

Results:

4: 17.01 ns/op
5: 36.02 ns/op
6: 38.24 ns/op
7: 29.92 ns/op
8: 16.58 ns/op

go1.20

-- 
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/6dbfd235-6eb1-475b-a248-9ac9991e05e5n%40googlegroups.com.