Various questions about posts from The Go Blog
703 views
Skip to first unread message
Kamil Ziemian
Aug 17, 2021, 12:13:14 PM8/17/21
to golang-nuts
Hello,
I'm now rereading post "Constants" and in the last section "Numbers" there is a text
BEGINNING
Therefore, although they have different implicit default types, written as untyped constants they can be assigned to a variable of any integer type:
var f float32 = 1
var i int = 1.000
var u uint32 = 1e3 - 99.0*10.0 - 9
var c float64 = '\x01'
var p uintptr = '\u0001'
var r complex64 = 'b' - 'a'
var b byte = 1.0 + 3i - 3.0i
fmt.Println(f, i, u, c, p, r, b)
END
I guess it should say "any number type", but I'm not 100% sure. Am I right?
Kamil
BEGINNING
Therefore, although they have different implicit default types, written as untyped constants they can be assigned to a variable of any integer type:
var f float32 = 1
var i int = 1.000
var u uint32 = 1e3 - 99.0*10.0 - 9
var c float64 = '\x01'
var p uintptr = '\u0001'
var r complex64 = 'b' - 'a'
var b byte = 1.0 + 3i - 3.0i
fmt.Println(f, i, u, c, p, r, b)
END
I guess it should say "any number type", but I'm not 100% sure. Am I right?
Kamil
Ian Lance Taylor
Aug 17, 2021, 3:20:25 PM8/17/21
to Kamil Ziemian, golang-nuts
Ian
Kamil Ziemian
Aug 18, 2021, 4:29:52 AM8/18/21
to golang-nuts
I guess it should say "any number type", but I'm not 100% sure. Am I right?
Thank you for the answer. I'm not good at computer science, so I'm often can't decide is this mistake or is there some subtlety that I'm missing.Small mistake and typos are quite common in blogs and talks and I am always quite unsettled by them (long story why). Unfortunately, they can be also in the presented code, at least in talks that I saw. "Never trust yourself, always run compiler" seems be the moral of the story.
As a aside, today I found in "Why Generics?" (https://blog.golang.org/why-generics) at the end of the section "Ordered types" sentence "In practice this contract would probably go into the standard library. and so really the Min function". Punctuation in natural languages is beyond me, but I guess changing period to coma make it correct.
PS. I know that now Go has Type Parameters Proposal (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md), but I need to wrap my head around generics, so I try to read as much as possible, even about outdated things like contracts.
Kamil
Ian Lance Taylor
Aug 18, 2021, 12:13:31 PM8/18/21
to Kamil Ziemian, golang-nuts
On Wed, Aug 18, 2021 at 1:30 AM Kamil Ziemian <kziem...@gmail.com> wrote:
>
> I guess it should say "any number type", but I'm not 100% sure. Am I right?
>
> Thank you for the answer. I'm not good at computer science, so I'm often can't decide is this mistake or is there some subtlety that I'm missing.
Thanks for pointing it out. I sent https://golang.org/cl/342992 to
>
> I guess it should say "any number type", but I'm not 100% sure. Am I right?
>
> Thank you for the answer. I'm not good at computer science, so I'm often can't decide is this mistake or is there some subtlety that I'm missing.
fix the problem.
> Small mistake and typos are quite common in blogs and talks and I am always quite unsettled by them (long story why). Unfortunately, they can be also in the presented code, at least in talks that I saw. "Never trust yourself, always run compiler" seems be the moral of the story.
>
> As a aside, today I found in "Why Generics?" (https://blog.golang.org/why-generics) at the end of the section "Ordered types" sentence "In practice this contract would probably go into the standard library. and so really the Min function". Punctuation in natural languages is beyond me, but I guess changing period to coma make it correct.
Ian
> PS. I know that now Go has Type Parameters Proposal (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md), but I need to wrap my head around generics, so I try to read as much as possible, even about outdated things like contracts.
>
> Kamil
> wtorek, 17 sierpnia 2021 o 21:20:25 UTC+2 Ian Lance Taylor napisał(a):
>>
>> On Tue, Aug 17, 2021 at 9:13 AM Kamil Ziemian <kziem...@gmail.com> wrote:
>> >
>> > I'm now rereading post "Constants" and in the last section "Numbers" there is a text
>> >
>> > BEGINNING
>> > Therefore, although they have different implicit default types, written as untyped constants they can be assigned to a variable of any integer type:
>> >
>> > var f float32 = 1
>> > var i int = 1.000
>> > var u uint32 = 1e3 - 99.0*10.0 - 9
>> > var c float64 = '\x01'
>> > var p uintptr = '\u0001'
>> > var r complex64 = 'b' - 'a'
>> > var b byte = 1.0 + 3i - 3.0i
>> >
>> > fmt.Println(f, i, u, c, p, r, b)
>> > END
>> >
>> > I guess it should say "any number type", but I'm not 100% sure. Am I right?
>>
>> I think you're right.
>>
>> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8bfe4d66-470f-42c0-b33d-35e16a89be33n%40googlegroups.com.
Kamil Ziemian
Sep 7, 2021, 6:40:31 AM9/7/21
to golang-nuts
Hello,
In the post "Concurrency is not parallelism" by Andrew Gerrand (https://go.dev/blog/waza-talk) under the paragraph starting with "To clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my browser is big blank space. I believe that that I can see rectangle in it, with slightly different hue of with, but I can't be sure.
Is it my browser not working or something goes wrong with the page? Can someone check if he/she has the same problem? I use Mozilla Firefox for Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up Fierfox data.
Best,
Kamil
In the post "Concurrency is not parallelism" by Andrew Gerrand (https://go.dev/blog/waza-talk) under the paragraph starting with "To clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my browser is big blank space. I believe that that I can see rectangle in it, with slightly different hue of with, but I can't be sure.
Is it my browser not working or something goes wrong with the page? Can someone check if he/she has the same problem? I use Mozilla Firefox for Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up Fierfox data.
Best,
Kamil
Jan Mercl
Sep 7, 2021, 6:51:09 AM9/7/21
to Kamil Ziemian, golang-nuts
On Tue, Sep 7, 2021 at 12:40 PM Kamil Ziemian <kziem...@gmail.com> wrote:
> In the post "Concurrency is not parallelism" by Andrew Gerrand (https://go.dev/blog/waza-talk) under the paragraph starting with "To clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my browser is big blank space. I believe that that I can see rectangle in it, with slightly different hue of with, but I can't be sure.
>
> Is it my browser not working or something goes wrong with the page? Can someone check if he/she has the same problem? I use Mozilla Firefox for Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up Fierfox data.
Before someone fixes the go.dev page, you can see the talk anonymously
> In the post "Concurrency is not parallelism" by Andrew Gerrand (https://go.dev/blog/waza-talk) under the paragraph starting with "To clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my browser is big blank space. I believe that that I can see rectangle in it, with slightly different hue of with, but I can't be sure.
>
> Is it my browser not working or something goes wrong with the page? Can someone check if he/she has the same problem? I use Mozilla Firefox for Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up Fierfox data.
(vimeo insists on login, should not be used by go.dev) here:
https://www.youtube.com/watch?v=oV9rvDllKEg
Tested in FF 78.12.0esr devuan/64bit.
Ian Lance Taylor
Sep 7, 2021, 4:23:19 PM9/7/21
to Kamil Ziemian, golang-nuts
On Tue, Sep 7, 2021 at 3:40 AM Kamil Ziemian <kziem...@gmail.com> wrote:
>
> In the post "Concurrency is not parallelism" by Andrew Gerrand (https://go.dev/blog/waza-talk) under the paragraph starting with "To clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my browser is big blank space. I believe that that I can see rectangle in it, with slightly different hue of with, but I can't be sure.
>
> Is it my browser not working or something goes wrong with the page? Can someone check if he/she has the same problem? I use Mozilla Firefox for Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up Fierfox data.
Thanks, sent https://golang.org/cl/348013 to fix this.
>
> In the post "Concurrency is not parallelism" by Andrew Gerrand (https://go.dev/blog/waza-talk) under the paragraph starting with "To clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my browser is big blank space. I believe that that I can see rectangle in it, with slightly different hue of with, but I can't be sure.
>
> Is it my browser not working or something goes wrong with the page? Can someone check if he/she has the same problem? I use Mozilla Firefox for Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up Fierfox data.
Ian
Kamil Ziemian
Oct 30, 2021, 5:17:05 PM10/30/21
to golang-nuts
Hello,
I don't have energy today to read Go language spec or learning how UTF-8 works, so I decided to make a look at Go blog post "Using Go Modules" (https://go.dev/blog/using-go-modules). I have a simple question: is this post up to date?
I guess not, here is my reason why. According to it if I run command "go test" outside $GOPATH and in director without go.mod file I should get result similar to
PASS
ok _/some path/hello 0.020s
When I run it with my go version go1.17.1 linux/amd64, result is
go: go.mod file not found in current directory or any parent directory; see 'go help modules'
This is one of the Go blog post listed on Documentation page (https://golang.org/doc/), so I guess it should have note "If you use Go in version x.y.z or latter, some code may not work", but maybe I just think about it in the wrong way.
From practical reason this particular thing isn't important, because go.mod file is the way to go (or at least this is what I read in the last week).
Best
Kamil
I don't have energy today to read Go language spec or learning how UTF-8 works, so I decided to make a look at Go blog post "Using Go Modules" (https://go.dev/blog/using-go-modules). I have a simple question: is this post up to date?
I guess not, here is my reason why. According to it if I run command "go test" outside $GOPATH and in director without go.mod file I should get result similar to
PASS
ok _/some path/hello 0.020s
When I run it with my go version go1.17.1 linux/amd64, result is
go: go.mod file not found in current directory or any parent directory; see 'go help modules'
This is one of the Go blog post listed on Documentation page (https://golang.org/doc/), so I guess it should have note "If you use Go in version x.y.z or latter, some code may not work", but maybe I just think about it in the wrong way.
From practical reason this particular thing isn't important, because go.mod file is the way to go (or at least this is what I read in the last week).
Best
Kamil
Sean Liao
Oct 30, 2021, 5:27:56 PM10/30/21
to golang-nuts
Technically that behaviour is still available via GO111MODULE=auto.
Go 1.16 changed the default from "auto" to "on".
Kamil Ziemian
Oct 30, 2021, 6:29:57 PM10/30/21
to Sean Liao, golang-nuts
This is probably silly thing, but I will write it down just in case.
I mentioned before Go blog post "Using Go Modules" (https://go.dev/blog/using-go-modules), we first write a function
func Hello() string {
return "Hello, world."
}
and test for it which basically check condition
Hello() == "Hello, world."
In the next step we change our function to
func Hello() string {
return quote.Hello()
}
using the module "rsc.io/quote". But this is "not portable example" and when test on my computer PASS when using the first version of our Hello() function, it FAILS with the second.
According to description quote.Hello() (https://pkg.go.dev/rsc.io/quote#Hello), but from source code we know that in fact it returns a string returned by sampler.Hello(prefs ...language.Tag). The last function "returns a localized greeting. If no prefs are given, Hello uses DefaultUserPrefs." (https://pkg.go.dev/rsc.io/sampler#Hello).
On my computer it correctly detected polish language so quote.Hello() returns "Witaj świecie." and since "Witaj świecie." != "Hello, world." the test now fails.
Best
Kamil
I mentioned before Go blog post "Using Go Modules" (https://go.dev/blog/using-go-modules), we first write a function
func Hello() string {
return "Hello, world."
}
and test for it which basically check condition
Hello() == "Hello, world."
In the next step we change our function to
func Hello() string {
return quote.Hello()
}
using the module "rsc.io/quote". But this is "not portable example" and when test on my computer PASS when using the first version of our Hello() function, it FAILS with the second.
According to description quote.Hello() (https://pkg.go.dev/rsc.io/quote#Hello), but from source code we know that in fact it returns a string returned by sampler.Hello(prefs ...language.Tag). The last function "returns a localized greeting. If no prefs are given, Hello uses DefaultUserPrefs." (https://pkg.go.dev/rsc.io/sampler#Hello).
On my computer it correctly detected polish language so quote.Hello() returns "Witaj świecie." and since "Witaj świecie." != "Hello, world." the test now fails.
Best
Kamil
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/p4YTbDqTUhI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fce2cfcc-993d-4c25-8863-484b67b02870n%40googlegroups.com.
Kamil Ziemian
Nov 8, 2021, 5:24:48 AM11/8/21
to golang-nuts
"Technically that behaviour is still available via GO111MODULE=auto.
Go 1.16 changed the default from "auto" to "on"."
Thank you for that information. It is surprisingly hard to me to learn basic of Go and Go tools, when things don't works as described.
I found few another places where "Using Go Modules" (https://go.dev/blog/using-go-modules) is not up to date with out of box Go version 1.17.2.
1) According to part "Adding a dependency" (end of fourth block of text) "Only direct dependencies are recorded in the go.mod file". But my go.mod file contains lines.
require (
golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c // indirect
rsc.io/sampler v1.3.0 // indirect
)
2) After using "go get golang.org/x/text" command "go list -m all" I get one line more that in blog post
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e
3) After function TestProverb(t *testing.T) is and running "go test" (I'm quite sure that when I did this few years ago, this was the command that I used) I get
hello.go:5:2: no required module provides package rsc.io/quote/v3; to add it:
go get rsc.io/quote/v3
This is easy to solve by running "go get rsc.io/quote/v3", but still annoying when you are going through this post.
Best
Kamil
Sean Liao
Nov 8, 2021, 6:31:12 AM11/8/21
to golang-nuts
Blog posts should really be viewed as a snapshot that is valid when they're published (that's why they contain a date)
The guides under https://golang.org/doc/#getting-started however should be kept up to date with the latest releases
Kamil Ziemian
Nov 8, 2021, 7:04:17 AM11/8/21
to Sean Liao, golang-nuts
"Blog posts should really be viewed as a snapshot that is valid when they're published (that's why they contain a date)"
I agree, but since page that you are referring contains numbers of links to Go Blog posts with description "The official blog of the Go project, featuring news and in-depth articles by
the Go team and guests.", I feel that they should put this disclaimer on this page or move links to posts to another page. "Using Go Module" is among posts linked on Documentation.
Maybe there is a way to suggest such a simple change to this page to people that maintain documentation? Or maybe this is over the top idea?
Best
Kamil
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dabd7534-8aed-4590-96c7-a767d9e5cbcen%40googlegroups.com.
Leam Hall
Nov 8, 2021, 8:54:39 AM11/8/21
to golan...@googlegroups.com
I agree with Kamil. Go is young and growing. Committing to keeping at least the "official" blogs updated will help us on-board new gophers and get them productive quickly.
I appreciate the effort the Go team puts into the blogs and documents. How can we make it easier and better?
Leam
On 11/8/21 06:03, Kamil Ziemian wrote:
> "Blog posts should really be viewed as a snapshot that is valid when they're published (that's why they contain a date)"
> I agree, but since page that you are referring contains numbers of links to Go Blog posts with description "The official blog of the Go project <https://blog.golang.org/>, featuring news and in-depth articles by the Go team and guests.", I feel that they should put this disclaimer on this page or move links to posts to another page. "Using Go Module <https://golang.org/blog/using-go-modules>" is among posts linked on Documentation.
> rsc.io/sampler <http://rsc.io/sampler> v1.3.0 // indirect
> )
>
> 2) After using "go get golang.org/x/text <http://golang.org/x/text>" command "go list -m all" I get one line more that in blog post
>
> golang.org/x/tools <http://golang.org/x/tools> v0.0.0-20180917221912-90fa682c2a6e
> go get rsc.io/quote/v3 <http://rsc.io/quote/v3>
>
> This is easy to solve by running "go get rsc.io/quote/v3 <http://rsc.io/quote/v3>", but still annoying when you are going through this post.
>
> According to description quote.Hello() (https://pkg.go.dev/rsc.io/quote#Hello <https://pkg.go.dev/rsc.io/quote#Hello>), but from source code we know that in fact it returns a string returned by sampler.Hello(prefs ...language.Tag). The last function "returns a localized greeting. If no prefs are given, Hello uses DefaultUserPrefs." (https://pkg.go.dev/rsc.io/sampler#Hello <https://pkg.go.dev/rsc.io/sampler#Hello>).
> To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com <mailto:golang-nuts...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dabd7534-8aed-4590-96c7-a767d9e5cbcen%40googlegroups.com <https://groups.google.com/d/msgid/golang-nuts/dabd7534-8aed-4590-96c7-a767d9e5cbcen%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> --
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAB3gO8ow0PBi%3DRCoxiRSjeEBgUTrWW3dm%2BvzEvr_pdsybwg-nQ%40mail.gmail.com <https://groups.google.com/d/msgid/golang-nuts/CAB3gO8ow0PBi%3DRCoxiRSjeEBgUTrWW3dm%2BvzEvr_pdsybwg-nQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
Systems Programmer (reuel.net/resume)
Scribe: The Domici War (domiciwar.net)
General Ne'er-do-well (github.com/LeamHall)
I appreciate the effort the Go team puts into the blogs and documents. How can we make it easier and better?
Leam
On 11/8/21 06:03, Kamil Ziemian wrote:
> "Blog posts should really be viewed as a snapshot that is valid when they're published (that's why they contain a date)"
>
> Maybe there is a way to suggest such a simple change to this page to people that maintain documentation? Or maybe this is over the top idea?
>
> Best
> Kamil
>
> Maybe there is a way to suggest such a simple change to this page to people that maintain documentation? Or maybe this is over the top idea?
>
> Best
> Kamil
>
> pon., 8 lis 2021 o 12:31 Sean Liao <seank...@gmail.com <mailto:seank...@gmail.com>> napisał(a):
>
> Blog posts should really be viewed as a snapshot that is valid when they're published (that's why they contain a date)
> The guides under https://golang.org/doc/#getting-started <https://golang.org/doc/#getting-started> however should be kept up to date with the latest releases
>
> Blog posts should really be viewed as a snapshot that is valid when they're published (that's why they contain a date)
>
> On Monday, November 8, 2021 at 11:24:48 AM UTC+1 kziem...@gmail.com <mailto:kziem...@gmail.com> wrote:
>
> "Technically that behaviour is still available via GO111MODULE=auto.
> Go 1.16 changed the default from "auto" to "on"."
>
> Thank you for that information. It is surprisingly hard to me to learn basic of Go and Go tools, when things don't works as described.
>
> I found few another places where "Using Go Modules" (https://go.dev/blog/using-go-modules <https://go.dev/blog/using-go-modules>) is not up to date with out of box Go version 1.17.2.
> On Monday, November 8, 2021 at 11:24:48 AM UTC+1 kziem...@gmail.com <mailto:kziem...@gmail.com> wrote:
>
> "Technically that behaviour is still available via GO111MODULE=auto.
> Go 1.16 changed the default from "auto" to "on"."
>
> Thank you for that information. It is surprisingly hard to me to learn basic of Go and Go tools, when things don't works as described.
>
>
> 1) According to part "Adding a dependency" (end of fourth block of text) "Only direct dependencies are recorded in the go.mod file". But my go.mod file contains lines.
>
> require (
> golang.org/x/text <http://golang.org/x/text> v0.0.0-20170915032832-14c0d48ead0c // indirect
> 1) According to part "Adding a dependency" (end of fourth block of text) "Only direct dependencies are recorded in the go.mod file". But my go.mod file contains lines.
>
> require (
> rsc.io/sampler <http://rsc.io/sampler> v1.3.0 // indirect
> )
>
> 2) After using "go get golang.org/x/text <http://golang.org/x/text>" command "go list -m all" I get one line more that in blog post
>
> golang.org/x/tools <http://golang.org/x/tools> v0.0.0-20180917221912-90fa682c2a6e
>
> 3) After function TestProverb(t *testing.T) is and running "go test" (I'm quite sure that when I did this few years ago, this was the command that I used) I get
>
> hello.go:5:2: no required module provides package rsc.io/quote/v3 <http://rsc.io/quote/v3>; to add it:
> 3) After function TestProverb(t *testing.T) is and running "go test" (I'm quite sure that when I did this few years ago, this was the command that I used) I get
>
> go get rsc.io/quote/v3 <http://rsc.io/quote/v3>
>
> This is easy to solve by running "go get rsc.io/quote/v3 <http://rsc.io/quote/v3>", but still annoying when you are going through this post.
>
> Best
> Kamil
> niedziela, 31 października 2021 o 00:29:57 UTC+2 Kamil Ziemian napisał(a):
>
> This is probably silly thing, but I will write it down just in case.
>
> I mentioned before Go blog post "Using Go Modules" (https://go.dev/blog/using-go-modules <https://go.dev/blog/using-go-modules>), we first write a function
> Best
> Kamil
> niedziela, 31 października 2021 o 00:29:57 UTC+2 Kamil Ziemian napisał(a):
>
> This is probably silly thing, but I will write it down just in case.
>
>
> func Hello() string {
> return "Hello, world."
> }
>
> and test for it which basically check condition
>
> Hello() == "Hello, world."
>
> In the next step we change our function to
>
> func Hello() string {
> return quote.Hello()
> }
>
> using the module "rsc.io/quote <http://rsc.io/quote>". But this is "not portable example" and when test on my computer PASS when using the first version of our Hello() function, it FAILS with the second.
> func Hello() string {
> return "Hello, world."
> }
>
> and test for it which basically check condition
>
> Hello() == "Hello, world."
>
> In the next step we change our function to
>
> func Hello() string {
> return quote.Hello()
> }
>
>
> According to description quote.Hello() (https://pkg.go.dev/rsc.io/quote#Hello <https://pkg.go.dev/rsc.io/quote#Hello>), but from source code we know that in fact it returns a string returned by sampler.Hello(prefs ...language.Tag). The last function "returns a localized greeting. If no prefs are given, Hello uses DefaultUserPrefs." (https://pkg.go.dev/rsc.io/sampler#Hello <https://pkg.go.dev/rsc.io/sampler#Hello>).
>
> On my computer it correctly detected polish language so quote.Hello() returns "Witaj świecie." and since "Witaj świecie." != "Hello, world." the test now fails.
>
> Best
> Kamil
>
> sob., 30 paź 2021 o 23:28 Sean Liao <seank...@gmail.com> napisał(a):
>
> Technically that behaviour is still available via GO111MODULE=auto.
> Go 1.16 changed the default from "auto" to "on".
>
> On Saturday, October 30, 2021 at 11:17:05 PM UTC+2 kziem...@gmail.com wrote:
>
> Hello,
>
> I don't have energy today to read Go language spec or learning how UTF-8 works, so I decided to make a look at Go blog post "Using Go Modules" (https://go.dev/blog/using-go-modules <https://go.dev/blog/using-go-modules>). I have a simple question: is this post up to date?
> On my computer it correctly detected polish language so quote.Hello() returns "Witaj świecie." and since "Witaj świecie." != "Hello, world." the test now fails.
>
> Best
> Kamil
>
> sob., 30 paź 2021 o 23:28 Sean Liao <seank...@gmail.com> napisał(a):
>
> Technically that behaviour is still available via GO111MODULE=auto.
> Go 1.16 changed the default from "auto" to "on".
>
> On Saturday, October 30, 2021 at 11:17:05 PM UTC+2 kziem...@gmail.com wrote:
>
> Hello,
>
>
> I guess not, here is my reason why. According to it if I run command "go test" outside $GOPATH and in director without go.mod file I should get result similar to
>
> PASS
> ok _/some path/hello 0.020s
>
> When I run it with my go version go1.17.1 linux/amd64, result is
>
> go: go.mod file not found in current directory or any parent directory; see 'go help modules'
>
> This is one of the Go blog post listed on Documentation page (https://golang.org/doc/ <https://golang.org/doc/>), so I guess it should have note "If you use Go in version x.y.z or latter, some code may not work", but maybe I just think about it in the wrong way.
> I guess not, here is my reason why. According to it if I run command "go test" outside $GOPATH and in director without go.mod file I should get result similar to
>
> PASS
> ok _/some path/hello 0.020s
>
> When I run it with my go version go1.17.1 linux/amd64, result is
>
> go: go.mod file not found in current directory or any parent directory; see 'go help modules'
>
>
> From practical reason this particular thing isn't important, because go.mod file is the way to go (or at least this is what I read in the last week).
>
> Best
> Kamil
>
> wtorek, 7 września 2021 o 22:23:19 UTC+2 Ian Lance Taylor napisał(a):
>
> On Tue, Sep 7, 2021 at 3:40 AM Kamil Ziemian <kziem...@gmail.com> wrote:
> >
> > In the post "Concurrency is not parallelism" by Andrew Gerrand (https://go.dev/blog/waza-talk <https://go.dev/blog/waza-talk>) under the paragraph starting with "To clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my browser is big blank space. I believe that that I can see rectangle in it, with slightly different hue of with, but I can't be sure.
> From practical reason this particular thing isn't important, because go.mod file is the way to go (or at least this is what I read in the last week).
>
> Best
> Kamil
>
> wtorek, 7 września 2021 o 22:23:19 UTC+2 Ian Lance Taylor napisał(a):
>
> On Tue, Sep 7, 2021 at 3:40 AM Kamil Ziemian <kziem...@gmail.com> wrote:
> >
> >
> > Is it my browser not working or something goes wrong with the page? Can someone check if he/she has the same problem? I use Mozilla Firefox for Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up Fierfox data.
>
> Thanks, sent https://golang.org/cl/348013 <https://golang.org/cl/348013> to fix this.
> > Is it my browser not working or something goes wrong with the page? Can someone check if he/she has the same problem? I use Mozilla Firefox for Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up Fierfox data.
>
>
> Ian
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/p4YTbDqTUhI/unsubscribe <https://groups.google.com/d/topic/golang-nuts/p4YTbDqTUhI/unsubscribe>.
> Ian
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
> To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fce2cfcc-993d-4c25-8863-484b67b02870n%40googlegroups.com <https://groups.google.com/d/msgid/golang-nuts/fce2cfcc-993d-4c25-8863-484b67b02870n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/p4YTbDqTUhI/unsubscribe <https://groups.google.com/d/topic/golang-nuts/p4YTbDqTUhI/unsubscribe>.
> --
> You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
> To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com <mailto:golang-nuts...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dabd7534-8aed-4590-96c7-a767d9e5cbcen%40googlegroups.com <https://groups.google.com/d/msgid/golang-nuts/dabd7534-8aed-4590-96c7-a767d9e5cbcen%40googlegroups.com?utm_medium=email&utm_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...@googlegroups.com <mailto:golang-nuts...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAB3gO8ow0PBi%3DRCoxiRSjeEBgUTrWW3dm%2BvzEvr_pdsybwg-nQ%40mail.gmail.com <https://groups.google.com/d/msgid/golang-nuts/CAB3gO8ow0PBi%3DRCoxiRSjeEBgUTrWW3dm%2BvzEvr_pdsybwg-nQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
Systems Programmer (reuel.net/resume)
Scribe: The Domici War (domiciwar.net)
General Ne'er-do-well (github.com/LeamHall)
Kamil Ziemian
Jan 24, 2022, 6:47:11 AM1/24/22
to golang-nuts
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.
Best,
Kamil
Kamil Ziemian
Jan 24, 2022, 9:38:32 AM1/24/22
to golang-nuts
Hello,
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 = &node(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
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 = &node(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
Ian Lance Taylor
Jan 24, 2022, 5:56:46 PM1/24/22
to Kamil Ziemian, golang-nuts
On Mon, Jan 24, 2022 at 6:38 AM Kamil Ziemian <kziem...@gmail.com> wrote:,
Ian
>
> 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 = &node(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.
> 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 = &node(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.
Ian
Kamil Ziemian
Mar 26, 2023, 1:36:59 PM3/26/23
to golang-nuts
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
I consider both changes improvement of Go workflow, but they may be confused for total begginers.
Best regards,
Kamil
Kamil Ziemian
Mar 26, 2023, 1:47:04 PM3/26/23
to golang-nuts
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
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()
}
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
Jan Mercl
Mar 26, 2023, 1:55:52 PM3/26/23
to Kamil Ziemian, golang-nuts
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.
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.
Kamil Ziemian
Mar 26, 2023, 2:01:30 PM3/26/23
to golang-nuts
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
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
Jakob Borg
Mar 26, 2023, 3:27:04 PM3/26/23
to Kamil Ziemian, golang-nuts
On 26 Mar 2023, at 20:01, Kamil Ziemian <kziem...@gmail.com> 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
% 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
t hepudds
Mar 26, 2023, 3:39:55 PM3/26/23
to Kamil Ziemian, golang-nuts
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
"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)
--------------------------------------------------------------------------------
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."
"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
"[...] 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
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/p4YTbDqTUhI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@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.
Reply all
Reply to author
Forward
0 new messages