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.

My biggest fear being that go-2 may be a major break, like symfony-2 and angular-2 were (as examples).

Running old code and having it "just work" is something I really love with go. I hope go-2 new features won't come at the cost of breaking old code.

Are we too early for "Go-2 considered harmful" jokes?

There is always the possibility that a go fix tool makes a transition to version 2 super simple.

The maintainers have already publicly stated that this will be the case. They used python 2 to 3 as an example of what they're NOT going to do.

Awesome. Does anybody here know where this discussion happened, for further reference?

I believe the "official" start of the discussion was on the Go blog [1].

[1]: https://blog.golang.org/toward-go2

Indeed, thanks.

Here is the relevant part from it:

> Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part.

Indeed. I didn't think about that, but given how gophers are into code generation, this could happen.

Yes, contrast this with Swift which has become unwieldy in my opinion.

I enjoy Swift a lot. Haven’t really ran into anything that made me feel this way except for the compile times which are fucking terrible

Yeah, good luck getting generics.

Adding generics is being considered and might be happening. In the meantime you could write an Experience report[0]?

[0]https://github.com/golang/go/wiki/ExperienceReports

It's interesting that generics are so important now but they were almost dropped from .NET schedule as being "academic only": https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...

> ...they were almost dropped from .NET schedule as being "academic only"

For all the good that has come out of .NET, and the nice platform it is today, there are a lot of high level design decisions where the team decidedly landed on 'the wrong answer'. To their credit they've been moving towards 'the right answer' for a while now.

Auto-wrapped properties instead of exposed value fields. Smart initialization. Safe default values. Generics. Anonymous functions. Nulls. Higher order functions.

Still under way: pattern matching, DSL support, option type, type aliasing, etc.

Related, but I also find it highly fascinating on those topics how much of Visual Basic's design they ignored, derided, and have then had to re-implement after-the-fact. A lot of babies got thrown out with the COM+/VB6/MFC bathwater.

> A lot of babies got thrown out with the COM+/VB6/MFC bathwater.

Not sure what you mean here, COM has become the main way of doing Windows APIs since Vista, going full circle to the original design of COM Runtime with WinRT (now UWP).

I was referring to the APIs, components, and language experience that got recycled incompletely as they were ported into .Net and "abstracted away", moreso than how components are marshaled :)

COMs resilience in the face of competing models, as you've pointed out, and the fractured GUI landscape of the windows client platform are symptoms, IMO, of ceding a pretty mature platform for something almost, but not quite, as capable. It has taken .Net over a decade to relearn lessons won painfully for the VB5 and VB6 teams, and I believe they lost a lot of larger systems because of WinForms restrictions in the 2005-2009 window.

Curious, what in your opinion is 'the right answer' in regards to parametric polymorphism?

I think the ideal is something close to ML-style polymorphism a la OCaml/Haskell, or F# on .Net.

The generics in C#/Vb.Net are pretty nice too, but their absence in the language during the design of the original standard libraries is still felt (typically along IDictionary and ICollection interfaces).

It seems obvious in retrospect how useful they are, but I do remember lots of contemporaneous "debate" about how academic and complicating they would be that turned out to be. My personal opinion is that these debates were relics of the C++ contingent of the ecosystem, and less applicable to languages running on top of virtual machines.

C# was originally trying to copy Java, a language that took influence from C (weak types retrofitted) and Smalltalk (no static types at all). Industry has since learned a lot about the tremendous value that types bring. Other forms of static analysis are now gaining popularity too.

Lets not forget that was in 1999, 10 years before Go came into existence.

For the record I'm not trying to argue generics are not important, on the contrary having worked with them for years go seems to be too limiting in this matter for my practical use.

But I agree they can be tricky to get right (compare e.g. declaration-site vs use-site variance [0]) or "accidentaly Turing-complete" TypeScript [1].

[0]: https://schneide.wordpress.com/2015/05/11/declaration-site-a...

[1]: https://gist.github.com/hediet/63f4844acf5ac330804801084f87a...

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

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

Well, I hope go get generics fast then. Seriously, what is this community that rejects any possible enhancement to a language? Even C gets new features albeit slowly. A language that doesn't evolve is a dead one.

There is nothing complicated with generics, they are just incomplete types, that's all. Generics =/= C++ templates.

Ada has a great implementation of generic programming which forces the developer to complete generic types before using them. In fact Ada got a lot of things that go got wrong despite being way older, especially when it comes to concurrency and types.

Package based generics make them completely compile time and runtime safe, no type erasure. The'd be the equivalent of reflect.MakeFunc or reflect.MakeStruct at compile time, so without any performance penality or ugly reflection, which go has right now.

I feel what is with this demand that Go has to have generics when there are some excellent languages with Generics available.

I'm on the fence about generics...but to answer your question generally...it's not all 'enhancements', it's making a language less readable. Sure, I can choose never to use it. But now I have (more) trouble reading others code. Go's strength, to me, is readability.

People programming in Go today already have workarounds to provide the functionality of generics, but at the cost of type safety and speed.

It is very common (especially in libraries) to pass `interface{}` around and use reflection to do manual type checking and type casting.

With generics the code that uses `interface{}` today would actually be much more readable, because the intention of the author would be clear.

Go has generics, but only for the blessed few built-in functions and types the Go team decided we couldn't live without.

We just want that special casing gone so we could write, say, a generic set that works just as well as map

Why? Like, I might have weird taste, because I really liked generics and even Java-style checked exceptions :-) And to me, generics always sounded like the most practical way to do safe code-reuse across various types.

They add complexity which makes understanding and auditing code much harder. Look at OpenSSL and their overuse of macros, or heavily-templated C++ code.

No one is asking for C/C++ style macros, or even C++ templates. Go generics would be closer to Java or C# generics, which increase code clarity, reduce boilerplate and copy/paste code, and communicate intent.

I see. If it can be implemented as something that make code easier to read and not worse. Why not. But I’d need to see a clear example of that.

Fair. In my opinion generics are good alternative to macros or templates, because they are much more constrained.

I think it would be naive to believe that adding generics to Go would have no effect on the stdlib, third party packages, and ultimately how you write Go code.

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.

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.

What are you saying, you never read other people's code? That's actually my job.

In his defense, just because you don't write generics yourself doesn't mean you don't encounter them.

Good luck, even C11 has light generics nowadays.

He said C11, not C++(11).

I am speaking about C, not C++.

Golang arrays and maps are generic ...

Yes, but I do not have to read their implementation fortunately, and not so many things in Go use generics if I do want to read their implementation.

This post basically proves that Google hires idiots and even created a language for idiots. :))

You'll love Algol 68.

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

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.

I wouldn’t recommend that against external APIs in general, though there are use cases. Adding keys is usually the best way to make backwards compatible changes in an API, but you’d make those changes backwards incompatible in your own infra.

My experience is that strictness is preferable here; silently accepting bad keys in a JSON object will lead the caller to think it's working, when it's not.

If you then break the API's backwards compatibility by, say, removing a field, then your API will visibly break, which is correct, something you'd otherwise not detect.

The solution to maintaining backwards compatibility is a combination of explicit versioning, erroring like this, good documentation, and trying to support old features for as long as possible.

Definitely never liked Go's silent ignoring of JSON keys. The workarounds (e.g. overriding the unmarshal code to apply a check) have always been very invasive.

Edit: Maybe you meant in the client, since you wrote "against". If so, I would still argue that strictness is good, as you do want your client to break (or at least warn) if something changes.

> If you then break the API's backwards compatibility by, say, removing a field, then your API will visibly break

That's a different issue. Fields going missing is definitely something I want to cause big problems.

I do mean consumers (e.g. unmarshalling JSON responses from APIs), as the typical mechanism to support backwards compatibility is by adding keys. Otherwise you can't upgrade ever without entirely new API versions, and you force lockstep for deployments. Needing new data is a common thing - maybe you have user endpoint that's not returning <some_flag> that you added that you now want in some new service. Bumping APIs for every added field would get unwieldy fast and you'll have services scattered among many API 'versions'.

It's just like in protobuf. In protobuf (or most other service-to-service serialization libs), adding a new field is not backwards incompatible.

That's a good point. It's more useful for config files than APIs I reckon. That's why I've been hanging for it.

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

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

You can have whatever default value you like by initialising the struct before you pass it to json.Unmarshal. If the key isn't present, it won't be set:

    type Test struct {
        Foo string
        Bar string
    }

    func NewTest() *Test {
        return &Test{Foo: "a"}
    }

    func main() {
        t := NewTest()
        if err := json.Unmarshal([]byte(`{"Bar": "b"}`), t); err != nil {
            log.Fatal(err)
        }
        fmt.Printf("%#v\n", t)
    }

Output:

    &main.Test{Foo:"a", Bar:"b"}

One thing you may want to consider in the future, or, at least, whoever wrote that code, is that it's not that difficult to fork the standard library and make it do something different in your program. I forked the encoding/xml library once so I could add tag stack depth limits and size limits for tags and text nodes, so I could use it to write an XML validator (in which you must be careful that the user can not simply blow out your RAM by sending you too much text), and I forked encoding/json so that you could declare a map[string]interface{} field on an struct you are decoding into that will "catch" any unmatched keys in the JSON object and treat it the same as if you passed the map[string]interface{} in as the thing to decode into, instead of discarding them. (Encoding works too.) The first was on the order of two days and the second was on the order of four hours (untested in production, but the unit tests are fairly easy and comprehensive), though in both of those particular cases if you've not fiddled with the "reflect" package enough to understand it, you'll also need to pay that price. Other packages may require other knowledge, of course. But the time required is such that it may be less than the time spent on dirty, half-working hacks, which tends to grow from the "just five minutes" of the initial estimate to "five days and we're still paying for the hack five years later...".

Release notes link: https://beta.golang.org/doc/go1.10

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

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

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.

> 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

The go assembly language is a bit idiosyncratic and didn't include all instructions, which led to 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

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.

> 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?

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://github.com/golang/go/commit/ee55000f6c45d2f5c38d9167... https://github.com/golang/go/issues/15131

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

Neat! I've been waiting for this.