Open lugray opened 6 years ago
but as the point of this exercise is more about packages, maybe a more intuitive package could be used,
I agree. This is the first page of the first chapter of the tour, titled "basic". The only point is to show the syntax for packages and function calls; it would be much better to use something else.
I guess the intention was maybe to show that the tour environment is deterministic? When serving from the appengine, we add this note:
Note: the environment in which these programs are executed is deterministic, so each time you run the example program rand.Intn will return the same number
If this is the reason for using the rand package, I don't think it turned our to be a good idea, for two reasons:
rand.Intn(10)
is fully deterministic, not just on the appengine, but also when run locally using the go toolchain. It's the nature of Intn
, which uses the default source. So the example doesn't really teach anything about the playground determinism.I will send a CL with a proposed modification of this page to use some other package in place of rand
.
Okay, I looked into this and I realized why at the moment we're stuck with a rand
call.
The basics/1
page is about packages. It shows that a package imported as math
is used as math.Sqrt
, while to utilize a package with path math/rand
you need to use the second word, as in rand.Intn
. So for the second example we need to use a package within a package, having a composite path.
The problem is that I skimmed through the whole standard library and math/rand
is, by far, the easiest "nested" package we can use as an example here. Functions in other nested packages, like for example encoding/json
, are not even remotely as easy to use. This is the first lesson of the tutorial, and we're really limited: we didn't introduce variables yet, we didn't talk about arrays or structs or types, or anything, really. rand.Intn
is perfect: it returns a number, and we print it; there's nothing to explain. Unfortunately, it has the whole unintuitive randomness/determinism issue that often confuses users.
It seems like we'll have to either 1) give up showing how to use a nested package 2) keep rand
and try to clarify the part about pseudo-randomness (but maybe removing the mention about seeding, since it's not really the point of this very first slide).
I don't think we want to do (1), so we're left with (2).
I'm not strongly opposed to option 2, but I would actually personally lean towards option 1, allowing nested packages to show up in http://127.0.0.1:3999/basics/11 for "math/cmplx", possibly adding a note there, or just having it as a passive example.
I propose this:
package main
import (
"fmt"
"math/rand"
"time"
)
func main() {
rand.Seed(time.Now().Unix())
fmt.Println("My favorite number is", rand.Intn(10))
}
Interesting... Because when I run the code I do in fact get a random numbers
You will if you run it locally. But your code at https://tour.golang.org/basics/1 will always give My favorite number is 3
.
Okay, I see... Have comments been introduced yet ? Maybe a simple coding comment could point out this nuance of non-randomness.
Is it possible to generate random value?
I tried on Tour of Go UnixNano but without expected result of randomly generated value.
You will if you run it locally. But your code at https://tour.golang.org/basics/1 will always give
My favorite number is 3
.
I am following A Tour of Go, but to my surprise the generated number was always different, which contradicted the description. Any thoughts?
Go 1.20 auto seeds rand, see #1448, can be closed.
Context: http://127.0.0.1:3999/basics/1
This example uses
rand.Intn(10)
, but running the program repeatedly produces the same result, which is surprising. The documentation forrand.Intn
doesn't talk about seeds. Some digging helped me figure out what to do, but as the point of this exercise is more about packages, maybe a more intuitive package could be used, or at least add some text talking about seeds, why the result will always be the same, and a push in te right direction for how to achieve different results.