
Go 1.10 Beta 1 is released - shabbyrobe
https://groups.google.com/forum/#!topic/golang-dev/SCPpL9PqVbs
======
sjellis
From the release notes, arguably the best feature: "There are no substantive
changes to the language."

Seriously, Go is not a perfect language, but I have come to really appreciate
the stance that the Go team have taken on stability. Looking forward to Go 2,
but very happy to keep on with Go 1.

~~~
issaria
Yeah, good luck getting generics.

~~~
baby
hell no, if generics get into go I'll have to find another favorite language.

~~~
ComputerGuru
Yeah, I can see how having features added to your favorite language while
remaining fully compatible with the code you write today would warrant such a
reaction. I mean, just having them in your language, even if you don’t have to
use them is just so horrible.

~~~
JustSomeNobody
I don't have a dog in this hunt, but if a feature is in a language, someone
will use it which will mean eventually everyone has to.

~~~
geodel
Well the same is true for multiple languages which will mean not everyone has
to use Go. Especially when there are so many interesting languages to choose
from.

------
shabbyrobe
This release finally brings a way to raise an error when an unknown key is
encountered in a JSON object: [https://go-
review.googlesource.com/c/go/+/74830](https://go-
review.googlesource.com/c/go/+/74830)

The error's text is close to useless for even a moderately complex JSON
object, but at least it's possible to catch this condition now.

~~~
jitl
This is the improvement that I’m most excited about for this release. I waded
through some code recently that implemented its own validation in a hacks way
by text-digging the re-serialization of structs... We were unable to put
default (zero) values in our config files...

~~~
majewsky
> We were unable to put default (zero) values in our config files...

Huh? I don't know the details of what you're (de)serializing, but the standard
strategy for default values that are not zero values is to have unpack into a
pointer. For example, if you have a message like

    
    
      { "foo": 23, "bar": 42 }
    

and the "bar" field has a default value of 5, you unpack like:

    
    
      var msg struct {
        Foo int
        Bar *int
      }
      err := json.Unmarshal(data, &msg)
      //handle error
      if msg.Bar == nil {
        defaultValue := 5
        msg.Bar = &defaultValue
      }
    

If you cannot change the type of the message to have a pointer field, you can
implement json.Unmarshaler for the receiving type such that UnmarshalJSON
deserializes into a temporary type, then copies the values into the recipient:

    
    
      type Message struct {
        Foo int
        Bar int
      }
    
      func (m *Message) UnmarshalJSON(in []byte) error {
        var msg struct {
          Foo int
          Bar *int
        }
        err := json.Unmarshal(data, &msg)
        if err != nil {
          return err
        }
        m.Foo = msg.Foo
        m.Bar = 5
        if msg.Bar != nil {
          m.Bar = *msg.Bar
        }
        return nil
      }
    

Now you can deserialize into Message (or into a struct containing a Message or
*Message or []Message or whatever) and it will fill in the correct default
value.

------
delta1
Release notes link:
[https://beta.golang.org/doc/go1.10](https://beta.golang.org/doc/go1.10)

~~~
bsaul
I don’t see anything regarding vendoring. What’s the current official tool for
managing dependencies ?

~~~
Aissen
There's no official tool (yet). The community seems to push dep as a future
official tool though:
[https://github.com/golang/dep](https://github.com/golang/dep)

~~~
lobster_johnson
Dep is very nice. We've been using Glide for more than a year, but it's
incredibly buggy/flaky and has several ugly misbehaviours. Dep isn't finished,
but it's already better than Glide, and we're transitioning over to it.

------
azinman2
> For the X86 64-bit port, the assembler now supports 359 new instructions,
> including the full AVX, AVX2, BMI, BMI2, F16C, FMA3, SSE2, SSE3, SSSE3,
> SSE4.1, and SSE4.2 extension sets. The assembler also no longer implements
> MOVL $0, AX as an XORL instruction, to avoid clearing the condition flags
> unexpectedly.

Is x86 vector support only being added now?

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

~~~
cdoxsey
The go assembly language is a bit idiosyncratic and didn't include all
instructions, which led to
[https://golang.org/doc/asm#unsupported_opcodes](https://golang.org/doc/asm#unsupported_opcodes)
.

The standard library is actually chock full of specialized assembly
implementations of various algorithms. Well worth a look even if you don't use
Go. Here's an example of aes encryption which is a relatively recent
instruction:
[https://golang.org/src/crypto/aes/asm_amd64.s](https://golang.org/src/crypto/aes/asm_amd64.s)

------
dis-sys
Tried my consensus library in go, and it is now 5% faster AGAIN. I like such
magic. ;)

What I am really looking forward to is the NUMA awareness in the runtime. Most
servers are now NUMA machines, in fact AMD Threadripper is NUMA and it costs a
few hundred $ only.

------
59nadir
> There is no longer a limit on the GOMAXPROCS setting. (In Go 1.9 the limit
> was 1024.)

Why was there ever a limit? Is anyone in the know on this?

~~~
shabbyrobe
Looks like it was because an internal structure in the runtime had a fixed
size, but that has changed:
[https://stackoverflow.com/questions/40943065/golang-why-
runt...](https://stackoverflow.com/questions/40943065/golang-why-runtime-
gomaxprocs-is-limited-to-256)
[https://github.com/golang/go/commit/ee55000f6c45d2f5c38d9167...](https://github.com/golang/go/commit/ee55000f6c45d2f5c38d91679def933fdf27c029)
[https://github.com/golang/go/issues/15131](https://github.com/golang/go/issues/15131)

------
qrv3w
> The go get command now supports Fossil source code repositories.

Neat! I've been waiting for this.

