Go 1.12 Released
blog.golang.org
blog.golang.org
I'd be happy to answer any questions about it, or about the rest of the Go cryptography libraries!
Is 0-RTT on the roadmap for Go 1.13?
[Updated to add] TLS 1.3 is opt-in because despite years of improvements, it can still hit compatibility issues with broken or legacy peers. (Search for "TLS 1.3" on the Go issue tracker if you are curious.)
0-RTT is blocked on figuring out good, safe APIs for it. I feel like I am 80% of the way there for servers (just have to figure out how to make it opt-in per http.Handler instead of opt-out), while for clients I have no idea how to fit resending in io.Writer.
Hrmm, I can think of a few ways (assuming I'm understanding the problem). One is a ZeroRTTHandler iface w/ a single ServeHTTPZeroRTT function and if Server.Handler impls that iface in addition to Handler, then that function is called instead. Another way is just to have a ZeroRTTAllowed property in the Server struct of type "func(Request) bool" w/ nil as an assumption of false. If it has to be on the handler instead of on the server, do something similar to the context package and have a "func WithZeroRTT(h Handler, allowed func(Request) bool) Handler" that returns the new handler w/ the internal check. Just spitballing, I may not understand the problem (can't escape asterisks here, but Request is meant to be a ptr).
> for clients I have no idea how to fit resending in io.Writer
This is tougher (assuming I understand the problem). Maybe a TLS config or http.Request option that the entire byte slice of first write can be resent as a whole. The other option being a tls.Conn.ZeroRTTFirstWrite method that the http req's Write can use if a setting is present before falling back to regular write, I dunno.
If you have a domain name pointed at your machine:
$ caddy -host example.com
Or if you just want to try things out:
$ caddy "tls self_signed"But! Hearing about what people would like to do and then putting together an API if it makes sense is my job! So please do open an issue saying what you'd like to do but can't.
For example, I mean to extract Client Hello parsing and a capturing middleware net.Conn, as a lot of passive things can be implemented that way.
> I mean to extract Client Hello parsing
Something like that could have helped when I was toying w/ DTLS, though [1] did a great job on their impl.
0 - https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01#se... 1 - https://github.com/pions/dtls
My understanding is that the renaming was mostly politics between Microsoft, Netscape, and the IETF in the 90s. See more details here: http://tim.dierks.org/2014/05/security-standards-and-name-ch...
This affects several popular database libraries.
Hooray! I'm surprised it took as long as it did, since IIRC this was something that broke constantly…
It appears to be ~3-4 ms faster when counting repositories like redis which is rather nice for me as a free speed boost. Probably related to the changes to GC listed here https://golang.org/doc/go1.12#runtime
I understand there's still a cost compared to non-GCed languages, but I think it's mostly RAM usage (perhaps affecting CPU cache effectiveness and thus efficiency) rather than tail latency.
In particular the GC & thread scheduler are great. The fact that they are accessible and digestible by the average go dev is so impressive a testament to their authors and their focus.
This is mitigated quite a bit by how much gets stack allocated but I imagine there are workloads that this hampers a lot, in particular large in memory data sets.
That’s not to disagree with your point the GC improvements are great for my workloads but only to point out there is a cost to them.
On the other hand, heap compaction is itself very expensive, as you are stopping the world while moving data around in the heap.
With Go allocation being so stack-oriented, not using compaction could very well be the best choice.
Again, not disagree-ing with the choices the golang team are making on GC, they work great for my workloads but they aren't without trade off for other kinds of workflows.
The number of "knobs" in Go's GC is the same as that of G1: max pause time and max memory usage. (HotSpot has more intuitive names for its configuration settings compared to Go's confusing names.) More importantly, Go's GC sacrifices a very large amount of throughput in pursuit of low latency at all costs. This is not a very good tradeoff for most applications.
See: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
Nice! Out of curiosity: what is the total running time? Or in other words: what is the average performance improvement in percentages?
Go team: please reduce the binary size of wasm files!
OTOH, there is a new project called TinyGo (https://tinygo.org) which generates LLVM byte code from Go. This allows a subset of the Go spec, sans any GC or runtime, and generates binaries comparable to Rust/Emscripten.
Nowadays we ask for your name, email address, and optional GitHub username.
[1] https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-compa...
Early in Go's development, they intentionally randomized the iteration offset to make sure developers didn't become dependent on a behaviour they didn't want to be tied to.
You see this in Erlang also, where iteration order is deterministic (though not based on insertion order), but documentation makes sure to say iteration is arbitrary.
So, the answer to your question is that most people don't want their dictionaries implementation to be tied down due to this feature.
Except it worked so well in Python and PyPy that in Python 3.7 it was blessed into an official part of the language spec.
FWIW https://docs.python.org/3/whatsnew/3.7.html
> the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.
https://mail.python.org/pipermail/python-dev/2017-December/1...
There's a big difference between "iteration order is deterministic" and "iteration order is <very specific high-level behaviour>" even if the latter is a side-effect of an implementation details. In particular, iteration order being either insertion order or sorted are useful and sought-after properties, while other implementation-dependent deterministic orderings are mostly implicit dependencies and sources of bugs (not unlike e.g. the scheduling sequence of goroutines in Go).
fmt should only print, not manipulate the data it is asked to print.
I believe that the spec says that maps iterate over keys effectively at random and so that should be the result of any operation that iterates over keys.
`fmt` has always made things look prettier, that's part of what formatting is about.
You could equally argue that `fmt` should not round floats or pad numbers with zeros or spaces.
Really I have never seen print change the order of the data it is given (that's manipulating, indeed) for the sake of what seems to be laziness.
If there is a real need for sorted iteration then it should be external to print, possibly a new API of maps.
Eh? That's exactly the functionality they are announcing...
For printing purposes that means that it doesn't matter which order you print something out in. ANY order is equally correct. So you might as well choose the one that makes the most sense to human eyes, which is to print them out ordered alphabetically on the keys.
Just because the printing function is choosing alphabetical order to print things out in, it's not "manipulating" anything. Literally nothing about the map changes.
Clearly, I am not the one missing the point...
The order maps iterate is not the point. The point is that e.g. a 'print' function should print, not sort and change the order.
> just because the printing function is choosing alphabetical order to print things out in, it's not "manipulating" anything
Again, the printing function does not 'choose', it manipulates the date returned by sorting them.
My point is that, to follow good design principle, this sorted iteration should be a public API of maps.
The point is that a print should print in the order it is getting data.
Given that the order of keys in a map is not guaranteed, I also wouldn't consider rendering them in a fixed order as "manipulation". The order of the keys is undefined, unimportant, program-wise. So presenting them in a certain order implies meaning (presumably there is one, whether it be creation order, LRU, or physical-memory layout). But if you know the keys are sorted before being printed, then you can continue to assume you don't know the actual order, or to put it another way, you can continue to suspend your disbelief about whether the keys are truly "unordered" in the system.
But to get back to practical concerns, I'm genuinely curious what harm you see from presenting the unordered keys in a predictable order that allows humans to get more use from the particular formatting?
What not add a new format verb instead?
If you rely on such docker image then upgrade only after it is released.
The ability to test / CI that your library works properly?
The gap between developer tools and infrastructure support for them should be as small as possible this days. It's 2019.
This is why I have https://NewReleases.io configured to track both Go GitHub releases as well as golang image tags on Docker Hub.
We already have a reply to that in your case with the availability of the docker image.
In general, people do not rush into upgrading to a new release of any software because it's risky.
> There are already a lot of work and testing done on projects that depend on 1.12 features
The only reason I can think of is that you have a requirement to support TLS 1.3.
And there is no 'delay', as, surely, you plan based on the availability of everything you need (or build your own container image).
For example, compiling your program with a different version of Go can be done just by changing the tag on your compile command, and doesn't require that you have any development tools or compilers installed on your machine (except docker).
Also, when building a container with a Go binary, it's a great base to build from. You can use Docker Multistage Builds[1] to build your binary in the Go container, then copy it out into a minimal container all in the same Dockerfile.
[1]: https://docs.docker.com/develop/develop-images/multistage-bu...
https://golang.org/doc/contribute.html
> A contribution to Go is made through a Google account [...]. Google accounts can either be Gmail e-mail accounts, G Suite organization accounts, or accounts associated with an external e-mail address. [...]
Does anybody else feel the same way?
Disclaimer: Used to work in Google's Open Source office, which administers the CLA.
(I consciously avoided getting a Gmail account for years until I bought an Android phone which requires such an account, so I understand where you're coming from but this issue seems meh to me.)
Gmail accounts are not required for Android phones. To utilize the Google services on an Android phone, which 99% of people will choose to do, a Google account is required.
A Google account can be but doesn't have to be a Gmail account. You can use any email address to create your Google account.