
Go 1.9 Beta 1 release notes - bradfitz
https://tip.golang.org/doc/go1.9
======
lgierth
I hadn't looked at the planned changes for go1.9 until now and I have to say
I'm really happy :)

\- net.Resolver.Dial allows doing all DNS resolution myself, right in the same
process (via a localhost port). And nice it can do both UDP and TCP.

\- SyscallConn providing access to the underlying file descriptor is super
useful too.

\- monotonic time is very useful in network protocols.

\- concurrent.Map is nice too.

~~~
arrty88
Java has had concurrentMap forever

~~~
dguaraglia
So did Python. What's your point?

------
drej
Chuffed about math.bits. You can always implement these yourself, these are
short (albeit a bit cryptic) snippets, but having these in the standard
library means that they will be regularly updated for various architectures
and CPUs.

Good stuff.

~~~
f2f
> You can always implement these yourself

Check the discussion, as usual things aren't as simple as they seem:
[https://github.com/golang/go/issues/18616](https://github.com/golang/go/issues/18616)

------
Shamiq
Will need to double check some machines to make sure these two don't bite me:

On Unix systems the environment variables SSL_CERT_FILE and SSL_CERT_DIR can
now be used to override the system default locations for the SSL certificate
file and SSL certificate files directory, respectively.

The os/exec package now prevents child processes from being created with any
duplicate environment variables. If Cmd.Env contains duplicate environment
keys, only the last value in the slice for each duplicate key is used.

~~~
bradfitz
I would be super interested if the os/exec change bites you. I've never seen
any definition of how programs should handle duplicate environment variables,
and there doesn't seem to be consistency in the wild either.

We went with the bash behavior (latest one wins), which also means all the
code previously using:

cmd.Env = append(os.Environ(), "KEY=newvalue")

... now actually works reliably. Previously, if KEY=oldvalue was already
defined, what you got depended on your luck with the child program. Either
old, new, or random.

File a bug if you see a regression.

~~~
Shamiq
Yea, I'm thinking about cases similar to HTTP parameter pollution, and what
the program expectations are. You'd be right to argue environment variables
should not be user controlled. :)

~~~
bradfitz
Note that only the os/exec package has this new cleanup logic.

If you really want to do something nasty and intentionally confuse your child
processes, the lower-level os.StartProcess and syscall packages are there for
you. :)

------
hardwaresofton
Type aliasing!

    
    
      type T1 = T2
    

I'm currently writing a pretty large project in Haskell and am thoroughly
enjoying it -- as everyone and their mother says, the type system is superb,
and even simple aliases like:

    
    
      type UserID = Int
    

Make it so much easier to read and understand functions.

~~~
justinsaccount
I'm not sure if type aliasing is for that use case. I think you're more
thinking about things like

    
    
      type Celsius int
    

that in theory prevent you from passing a bare int and mixing up
Celsius/Fahrenheit.

In go this almost works. If you define

    
    
      type Celsius int
    
      func isBoiling(t Celsius) bool {
          return t >= 100
      }
    

then You need to call it by doing something like

    
    
      t := Celsius(100)
      isBoiling(t)
    

and just

    
    
      t := 212
      isBoiling(t)
    

will not compile with

    
    
      cannot use t (type int) as type Celsius in argument to isBoiling
    
    

But unfortunately you can get away with

    
    
      isBoiling(212)
    
    

However, If you just used a type alias then you'd be able to do either.

~~~
thomas11
Right. You could always define a _new_ type with an existing _underlying_
type, like Celsius with the underlying type int in your example. See the spec
here: [https://golang.org/ref/spec#Types](https://golang.org/ref/spec#Types)

This would define a new, non-interchangeable type, even though it's just an
int behind the scenes. The new type alias on the other hand define a new name
for an existing type; you still have just one type. In the user ID example
above that's not what you want, it would allow using an int where a UserID is
required.

~~~
frou_dh
As I understand it, there have been a couple of compiler-blessed aliases for a
long time (byte -> uint8 and rune -> int32), making this a similar thing but
now at user level.

------
curun1r
> ...the environment variables SSL_CERT_FILE and SSL_CERT_DIR can now be used
> to override...

I presume that those environment variables override the defaults at runtime,
but it would be good to call that out explicitly since we are talking about a
compiler release and there are compilers that can evaluate environment
variables at compile time to allow for more flexible constant runtime values.

------
benhoyt
It would be really nice if each change in the release notes linked to the
GitHub issue and/or PR, so curious folks can see how each fix or improvement
is implemented. For example, see the notes like "Contributed by Victor Stinner
in bpo-26146" in the Python What's New documents:
[https://docs.python.org/3/whatsnew/3.6.html](https://docs.python.org/3/whatsnew/3.6.html)

~~~
benhoyt
Interestingly, the CL (changelist?) numbers are in the HTML as comments, so if
you do View Source you can see them. And then you can go to (for example)
[https://golang.org/cl/42028](https://golang.org/cl/42028) to see the
associated code changes. Not sure why these aren't user-visible links.

------
usuallybaffled
Is there anything being discussed about Go 2.x?

I haven't seen anything about it, which I absolutely love (based on fear of a
Python 3 situation).

~~~
bradfitz
We on the Go team team also muse about a Go 2.x occasionally (no concrete
plans), but the number one rule would be not pulling a Python 3 or Perl 6 and
fracturing the community in two.

If/when it happens, it won't be scary.

~~~
pjmlp
Maybe you guys could do like Java did and eventually drop the 1.x from the
naming, leaving just the x, or do you see any issue with the perception of
backwards compatibility?

------
justinclift
Cool, DWARF improvements are definitely welcome. Even if these ones are just
for Windows. ;)

Go's debugging story, for things using cgo, has been a bit of a rude shock (to
me). As of yesterday's toolchain updates (Gogland, Delve), single stepping on
Linux is now working reliably (eg not randomly hanging).

It still needs to be improved so instructions execute in the order they're
written (eg more disabling of compiler optimisations when debugging), but
that's less important than fixing the "ugh, it's just hung again!" bug was.

Hopefully OSX debugging gets to a similar (working ok) state soon too. :)

------
helper
When should one use sync.Map vs a plain old map with a RWMutex?

~~~
tejasmanohar
When one does not care about type safety ;)

Only sorta kidding... Personally, I think sync.Map is a dangerous addition to
the standard library, and hope that the Go team does not encourage using the
empty interface{}'s like this. I can only imagine how bad it'll feel when
someone reads an int64 as an int.

~~~
pjmlp
Until they introduce some kind of type safe genericity language level support,
_interface{}_ and _go generate_ are the only options available for generic
data structures.

Personally I would already be happy with what CLU allowed for in 1975, no need
for anything more expressive.

~~~
kasey_junk
There is a third option which is to add specific data structures to the
existing list of generic data structures with out making user defined
generics.

~~~
pjmlp
Which leads to the question when would they stop adding special case
structures?

~~~
kasey_junk
(shrug) they clearly are ok with _some_ generics. In my mind if they argued
that they'd rather support more widely used data structures at the language
level instead of user defined generics thats a logically consistent position.

In fact, if I could get a) a type safe concurrent map b) a promise/future
construct and c) a fast concurrent queue for single writer multi-reader, I'd
probably be ok with the set of generic data structures provided in the
language.

If they fixed their variance rules along the way as well, I'd probably lose
any actual arguments against the type system when it comes to the systems I
build.

The question is of course, are those the only ones that fall into that
category? Who knows but those are the ones I run into the most pain for.

------
YZF
Seems like the monotonic time changes mean that some calls (e.g. time.Now())
are making two syscalls where they used to only make one? And storing two
different clock values? Could make code that makes a lot of timing calls more
expensive/slow...

~~~
bradfitz
The size of the time.Time data structure is unchanged on 64-bit. There was
space to pack it in.

As for time, on Linux it got 70 ns slower. Tolerable. (It went from 70 ns to
140 ns on my GCE VM)

On Windows, it actually got faster on 64-bit with the addition of:

[https://github.com/golang/go/commit/e4371fb179ad69cbd057f243...](https://github.com/golang/go/commit/e4371fb179ad69cbd057f2430120843948e09f2f)

And on macOS, where nobody runs servers, it's basically unchanged speed-wise.

~~~
YZF
Cool. I've just been instrumenting some fairly hot Go code with time.Now/Since
all over the place trying to pinpoint some lost milliseconds ... I was
planning to keep the instrumentation in there for monitoring... Sounds like it
shouldn't be a problem.

------
avshyz
still no generics :(

------
deckarep
What does sync.Mutex is now more fair really mean?

~~~
zik
It probably means that it used to favour activating one waiter over others,
but now is less likely to do so.

