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

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. :)

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

https://play.golang.org/p/cnAXBEZJm2B

(fixed playground link)

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

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

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

This is a builtin feature of Go.

https://blog.golang.org/go-maps-in-action

https://bugzilla.mozilla.org/show_bug.cgi?id=743107

Randomly deciding to add an extra byte of entropy only adds 1 bit of entropy. Adding the extra byte always adds 8 bits of entropy.

There is no cryptographic reason to do this. It is just to break assumptions about the API.

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

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

Official wasm design doc: https://docs.google.com/document/u/1/d/131vjr4DH6JFnb-blm_uR...

> NOTE: This is not present in go1.11beta1 but will be available in future betas and subsequent releases.

+ Ɛ:=

Add the missing ears

It actually works as long as no `gofmt` applied. Code: https://play.golang.org/p/bMDxAq_l6F0

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.

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.

https://go-review.googlesource.com/c/go/+/106256

That's really good news. :)

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

------------------

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.

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

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

Look at this: https://news.ycombinator.com/item?id=17373220

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.

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.

  if err != nil {
          return nil, err
  }

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

I've just created a live template for that in Go, which just puts my cursor in the wrap message to pass along.

Aw, hell no! That's a very easily detectable (anti)pattern! You can scan even a very large code base for that! As noted in other comments, you should be adding some contextual information at this point.

Contrast this with having too-much magic, where you might have absolutely no trace in code left. You can't usefully search a large code base for all such relevant blanks.

Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment.

I’ll have to think about that a bit. Trivial cases don’t matter. Complex cases are more nuanced.

This is really insightful, thank you.

That's correct. I've heard people describe Go as wanting you to code the sad path first, and then backfill the happy stuff (the business logic) once the error handling is complete. This tracks to my experience. That is, when I program that way, I feel like I'm in sync with the language.

Your users probably don't think so

but for something running on a server somewhere, many inputs are beyond the user's control & the state is long-lived and fragile (if my HN or FB account gets somehow b0rked, that's a serious problem for me), so it's important to handle all possible error conditions in the best possible way. in my experience this is something exceptions make very hard to do.

(& i would still prefer explicit error handling even for front-end software, but i think the argument for exceptions is at least stronger there.)

Must(func()(val, err)) -> LogIf(func()(val, err))

Duck typing can still lead to runtime errors which is practically all accounted for thanks to the compile-time safety of structured typing.

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