
Go 1.11 Beta 1 is released - bigato
https://groups.google.com/forum/#!msg/golang-nuts/vpVOVVMLa08/oQQQWX3rCgAJ
======
cpeterso
This change is interesting:

crypto: randomly read an extra byte of randomness in some places.

[https://go-review.googlesource.com/c/go/+/64451](https://go-
review.googlesource.com/c/go/+/64451)

Firefox has a similar testing feature called "chaos mode" that tries to shake
out bugs by doing things like randomly forcing short file or socket reads or
changing hashtable iteration order. Due to the increased chance of buggy
behavior or performance issues, this isn't the sort of thing you would do in
production (unless you're on Netflix's chaos engineering team. :)

~~~
pquerna
I thought an "interesting" part of the change was actually how they made a 50%
chance work for the extra read. They select across a closed channel twice --
and it results in a mostly even distribution of chance.

    
    
        for i := 0; i < 100000; i++ {
            select {
            case <-closedChan:
                a++
            case <-closedChan:
                b++
            case <-closedChan:
                c++
            case <-closedChan:
                d++
            }
        }
    

Results in an almost even distribution across the select choices!

[https://play.golang.org/p/cnAXBEZJm2B](https://play.golang.org/p/cnAXBEZJm2B)

(fixed playground link)

~~~
zimpenfish
You're printing `b` three times in that Playground which makes it a look
skewed.

    
    
        a: 25100
        b: 25080
        c: 25080
        d: 25080
    

vs

    
    
        a: 24973
        b: 25010
        c: 25013
        d: 25004

~~~
cup-of-tea
So it's deterministic. I got the same numbers.

~~~
akavel
On the Playground or on your PC? The Playground has an execution cache, so the
same input code always gives the same (thus "deterministic") result.

~~~
cup-of-tea
Ah OK, it was on the playground. Is it deterministic when not cached?

~~~
dosshell
It is not deterministic on playground if it is not cached.

You can add dummy code to the file to break free from the cache.

~~~
rejschaap
Adding some white space also does the trick

------
bigato
Go 1.11 Release Notes:
[https://tip.golang.org/doc/go1.11](https://tip.golang.org/doc/go1.11)

\- Go 1.11 adds experimental, integrated support for package versioning (vgo).

\- Go 1.11 adds an experimental port to WebAssembly (js/wasm).

~~~
ssutch3
Official vgo proposal:
[https://github.com/golang/proposal/blob/master/design/24301-...](https://github.com/golang/proposal/blob/master/design/24301-versioned-
go.md) Github tracking issue:
[https://github.com/golang/go/issues/24301](https://github.com/golang/go/issues/24301)

Official wasm design doc:
[https://docs.google.com/document/u/1/d/131vjr4DH6JFnb-
blm_uR...](https://docs.google.com/document/u/1/d/131vjr4DH6JFnb-
blm_uRdaC0_Nv3OUwjEY5qVCxCup4/edit)

------
tbrock
Anyone ever notice that the assignment + declaration syntax looks like a
sideways gopher? :=

~~~
Twisol
I've seen it called the Zoidberg operator, too -- but I can see the gopher now
that you mention it!

------
stephen
Wow, vgo seems pretty reasonable. ...I have to take one of my "damn it, go"
complaints back.

Interesting to see their critique of bundler/et el...AFAICT isn't this vgo min
version just old-school Maven resolution + semver major version in the import
path?

Tools to auto-bump semver by examining the code's own public API would be
nice.

~~~
Sajmani
The "go release" command is intended to support selecting the right version
for a new package release. The golang.org/cmd/api command detects incompatible
API changes and so can serve as the basis for an auto-bump feature.

I'd also like to see a command to generate a new major version as a wrapper of
the previous major version (or vice versa), to simplify creating major
versions that can coexist within the same program.

------
justinclift
Oh, it's looking like the ground work for future RISC-V support is happening
too.

[https://go-review.googlesource.com/c/go/+/106256](https://go-
review.googlesource.com/c/go/+/106256)

That's really good news. :)

~~~
hugelgupf
Almost complete, but stalled, and based on Go 1.8:
[https://github.com/riscv/riscv-go](https://github.com/riscv/riscv-go)

------
rlbaker
I'm not fully versed in the what the transition to the `vgo` proposal will
look like, so pardon my ignorance.

Will it be available behind an environmental variable like the vendor
experiment was?

------
rurounijones
[EDIT] Will leave the questions up have delved deeper into this myself and the
above questions I have are basically answered but I am surprised at the route
taken. Seems like everyone should be including the major version in their
import path from the very beginning and every subsequence version which
seems... ehhhhh.

\------------------

Not a Go dev:

Is the mantra of "the new package must be backwards compatible with the old
package.", which is an underlying requirement for vgo to work, actually
followed in the Go ecosystem? It seems crazy to me that a package would have
to change its name if it wants to introduce a backwards incompatible change.

Has this happened in practice? How does it work? Are people going to suffix
packages with "Really major major" version numbers separately from the actual
version number?

The criticisms of bundler in the proposal seem to be be a bit wierd when the
solution is to force a new paradigm on developers to make vgo's job easier.

Why even use Semantic versioning at that point since a major version can never
be incremented.

~~~
pjmlp
I the context of versions I think Rickey puts it best, actually there are no
guarantees of compatibility.

Even a minor update can eventually break someone's code that relied on the
bug.

"Spec-ulation – Rich Hickey"

[https://www.youtube.com/watch?v=oyLBGkS5ICk](https://www.youtube.com/watch?v=oyLBGkS5ICk)

------
dis-sys
Free lunch is over for me. For the past 4 releases, each delivered 3-5%
performance boost to my Go application. Go 1.11beta1 marks the end of that, it
is sadly 1-2% slower than Go 1.10.

Not complaining, just trying to hear numbers from other developers using their
production software...

~~~
bradfitz
If something got slower, file a bug with details. We look into all such
reports.

------
stcredzero
I think I just realized something about golang as I was walking down the hall.
This is something which confuses many people in a way which many respond to
with unwarranted emotion, since they are unable to make this connection.

Since Go uses Duck Typing, having certain methods is effectively a Type
Annotation for a given type implementing an Interface. Many programmers,
failing to realize this, become outraged at "boilerplate." It is a design
trade-off forcing the programmer to specify all cases when implementing an
interface, in much the same way that golang's exception handling eschews tools
that let you create clever catch-alls and requires you to specify everything.
It's just the "no magic" tradeoff.

~~~
jfoutz
> requires you to specify everything

That's not my experience. checking for errors is completely optional. I'm
probably just a bad lazy programmer that leans to hard on the compiler. I like
the catch everything and then refine error handling as i get more
understanding of failure modes (i'm from java, i avoid runtimeexception).

Go makes me feel like i need to understand all possible error cases for every
line as i type it. I feel like i have to handle it right now, forever, or i'll
forget that line can have an error. I really miss being able to gradually
refine error handling, because i can rely on the compiler to remind me about
all the stuff that can go wrong.

~~~
sagichmal
Indeed, Go's position is that your style of programming produces fragile
programs, and that it is better to consider the failure modes of each
expression as you type it, rather than afterwards.

~~~
erik_seaberg

      if err != nil {
              return nil, err
      }
    

is ceremony that requires no thought and adds no value. There should be sugar
for this so it doesn't completely swamp the tiny minority of cases that
actually do something.

~~~
sacado2
I actually rarely type that very snippet. In like 3/4 of the cases, I make the
error more specific, like

    
    
        if err != nil {
            return nil, fmt.Errorf("could not parse file %s: %v", path, err)
        }
    

the remainder being either the snippet you put above or more complex error
management.

~~~
erik_seaberg
You can enrich err.Error(), but when you do you lose the type of the original
error and any other fields it may have had. This is something the language can
and should do more reliably (i.e., sugar could mutate err.Error() and prepend
"MyStruct.myMethod failed: ", or better yet add a damn stack trace).

------
wiremine
What are some good use cases for compiling Golang code to wasm?

~~~
pietroglyph
Writing most of your front/backend business logic in Go is one possibility,
but I think that easily moving complex logic to the web as a platform
(especially for web demos, see these[0] example with gopherjs) is the most
compelling possibility. Generally, I'm excited that this democratizes the web
programming space, because the best use cases are often the ones no one has
thought of yet.

[0]:
[https://hajimehoshi.github.io/ebiten/](https://hajimehoshi.github.io/ebiten/)

------
shabbyrobe
Ok, ninja edit, this whole comment was based on a misunderstanding and adds no
value to the discussion. I've been corrected below, the rest does not need to
be preserved. Downvote it to the bottom for me please; I can't seem to delete
it.

~~~
Thaxll
They never said vgo would be production ready for 1.11, they said experimental
until 1.12: [https://github.com/GoogleCloudPlatform/runtimes-
common/issue...](https://github.com/GoogleCloudPlatform/runtimes-
common/issues/683)

~~~
shabbyrobe
Thanks for pointing that out, I've been trying very hard to keep up but
somehow missed that detail. Perhaps it should be in the release notes!

