25 ms·
Go 1.16 Release Notes
- smasher164 6y agoExcited for io/fs. The design work that went into it is hopefully going to lead to the level of interop that we see with io.Reader and io.Writer. It's nice to see the float parsing speedups too. I do wish the Unicode package wasn't tied to the Go release cycle. Unicode 13 was released in March of last year.
- benhoyt 6y agoI'm curious -- what have you needed from Unicode 13 that wasn't in the previous version of Go? (Presumably new codepoints still work fine, as long as you're just passing characters through, and not relying on the categorization functions in the unicode package.)
- smasher164 6y agoI do care about categorization though. Here’s an identifier parsing library of mine (https://github.com/smasher164/xid https://github.com/smasher164/xid) where I can’t test that codepoints are in some category without knowing the version. If unicode was an external library, it would be my responsibility to update this identifier parsing library.
- benhoyt 6y agoNice! I suspect you're in a minority of developers who need this level of control, though. I don't think I've ever used "unicode" directory, though I reach for "unicode/utf8" often enough.
- mholt 6y ago"There are no changes to the language." It's the calm before the storm. But I love that. :) 10 years in, Go is still my favorite language when it's the right tool for the job. So actually, this is an exciting release IMO. Highlights: - darwin/arm64 support (M1 chips) - Go module quality-of-life improvements - Built-in support for embedding files - File system interface! (io/fs) - Linker optimizations! - io/ioutil -> io - Lots of juicy crypto/* package improvements. Filippo and team are crushing it!
- _wldu 6y agoWhat storm? Generics?
- mseepgood 6y agoYes, the proposal was accepted this week: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
- _wldu 6y agoBut is that really bad for Go? I'm not sure it is. Go1 will always be useful just as it is.
- mseepgood 6y ago> But is that really bad for Go? No, I don't think so.
- cpuguy83 6y agoI don't think the op intended "storm" to be negative here. Just to say that there are loads of changes coming soon.
- throwaway894345 6y agoOne of the features of Go is that everyone writes code the same way, which means anyone can easily read anyone else's code; there's only one paradigm; idioms and conventions are strong across the community. This property exists precisely because Go isn't very expressive, but the generics proposal will make Go more expressive and in all likelihood the ecosystem will become more diverse accordingly. Whether this is a positive or negative depends on how much you value expressiveness versus standardization.
- mholt 6y agoYeah. To clarify, I'm not suggesting it's either good or bad -- just that it's a big deal. To some, it's controversial. I personally think Go's proposed implementation of parametric polymorphism a great feat of modern software engineering, and a testament to the open source process. Anyway, they'll probably land in Go 1.18.
- ed25519FUUU 6y ago> The go command now supports including static files and file trees as part of the final executable, using the new //go:embed directive Can this be used to imbed a dynamically growing SQLiteDB? If so that would be a killer feature. Unfortunately SQLite with Go still requires the remote host to have a c compiler (must use CGO), which makes even a static binary much less portable.
- mseepgood 6y ago> Can this be used to imbed a dynamically growing SQLiteDB? It's read-only.
- the_mitsuhiko 6y agoSelf modifying executables are both a bad idea and generally flagged by virus scanners. So embedding the db in the executable I would say is a pretty big no no.
- kodah 6y agoThis seems, at least on the facade, like a bad idea. Binaries being immutable is one of the more concrete things we know about a system. It's why hashing a binary is effective in the first place. I read this feature as beneficial for folks who do not need to scale frontends and want to embed resources in the binary to that end. This was already possible before but it looks like they just gave us an official channel for doing so.
- deleted 6y ago[deleted]
- lima 6y ago> Unfortunately SQLite with Go still requires the remote host to have a c compiler (must use CGO) No, you just need the shared object.
- didip 6y agoYou should probably embed table schema DDL only. If you need to export the SQLite, it is better to write a separate goroutine that exports the SQLite file into a remote storage like S3.
- woodruffw 6y agoThis stood out to me: > As announced in the Go 1.15 release notes, Go 1.16 drops support for x87 mode compilation (GO386=387). Support for non-SSE2 processors is now available using soft float mode (GO386=softfloat). Users running on non-SSE2 processors should replace GO386=387 with GO386=softfloat. This change makes perfect sense to me (you'd have to be running a 20+ year old CPU to still need x87 float support, and plenty of distros have already dropped it), but I'm curious as to whether it was partially motivated by Go's decision to implement their own optimizing compiler and surrounding ecosystem. Modeling x87 is a real pain, one without obvious benefits when outside of a mature surrounding framework (like LLVM or GCC). Can someone with knowledge of Go's compiler internals opine on this? It'd be interesting to hear which bits are sources of historical pain/relative ease.
- nappy-doo 6y agoIt was dropped because it had bugs, no-one ever really supported it, it was impossible to find hardware to run it continuously. There are many reasons it was dropped.
- martisch 6y agoThe reasoning is here: https://github.com/golang/go/issues/40255 https://github.com/golang/go/issues/40255 Copy of part of it: 1) While 387 support isn’t a huge maintenance burden, it does take time away from performance and feature work and represents a fair amount of latent complexity. 2) 387 support has been a regular source of bugs (#36400, #27516, #22429, #17357, #13923, #12970, #4798, just to name a few). 3) 387 bugs often go undetected for a long time because we don’t have builders that support only 387 (so unsupported instructions can slip in unnoticed). 4) Raising the minimum requirement to SSE2 would allow us to also assume many other useful architectural features, such as proper memory fences and 128 bit registers, which would simplify the compiler and runtime and allow for much more efficient implementations of core functions like memmove on 386. 5) We’re exploring switching to a register-based calling convention in Go 1.16, which promises significant performance improvements, but retaining 387 support will definitely complicate this and slow our progress. The 5) didnt make it into go1.16 but will be focused on again for go1.17.
- candiddevmike 6y agoSo happy to see file embedding move to the stdlib. Having _everything_ in a single binary makes distribution so much easier. As an aside, I would love to see Go have first class support for watch/hot reload while developing...! (e.g. go run --watch main.go)
- Meekro 6y agoI have a small project that uses Go's built-in webserver libs to display a status page. I've been storing the HTML/CSS for that in Go strings, which breaks color formatting in my editor and generally feels ugly. This embedding approach looks awesome, I can't wait to give it a try!
- coder543 6y agoThis is by far the best tool for the job that I've found: https://github.com/cortesi/modd https://github.com/cortesi/modd
- jbub 6y agoI second that
- leg100 6y agoIn tandem with https://github.com/cortesi/devd https://github.com/cortesi/devd I've found it a good setup for web development. Modd watches file changes and rebuilds, while Devd enables livereload, letting me make changes in my text editor and then see the rendered changes in the browser, side-by-side, in near real-time. This is for go web development but I'm pretty sure these two tools are language-agnostic.
- papaf 6y agoI would love to see Go have first class support for watch/hot reload while developing Its not first class, but I have been happy using reflex [1] for non-http and gin [2] for http. Combined with Go's fast compile they work as well as a hot reload. [1] https://github.com/cespare/reflex https://github.com/cespare/reflex [2] https://github.com/codegangsta/gin https://github.com/codegangsta/gin
- pella 6y agosummary: Go 1.16 is released https://blog.golang.org/go1.16 https://blog.golang.org/go1.16
- pansa2 6y agoIs anyone using Go’s support for compiling to WebAssembly? I know it was added experimentally a few versions ago - is it still being worked on? Is it production-ready? There’s no mention of it in these release notes.
- petercooper 6y agoTwo examples although both in the 'fun' category: - https://healeycodes.com/boids-flocking-simulation/ https://healeycodes.com/boids-flocking-simulation/ - https://dstoiko.github.io/posts/go-pong-wasm/ https://dstoiko.github.io/posts/go-pong-wasm/
- dastx 6y agoWould love to know too. I've recently thought of something that would be great for go wasm.
- kodablah 6y agoWhile I believe it is probably production ready, due to how Go is implemented with implicit coroutines/yielding, generated WASM from Go is larger and has many more instructions than a lower-level languages that map more directly to machine code. For most, this tradeoff is likely negligible.
- deleted 6y ago[deleted]
- dmitshur 6y agoIt’s still supported and developed, but it’s not an area where most activity is currently focused. It is very stable, even more so when it was first added, since bugs are being fixed and regression tests are added. You can see what issues are open and closed at https://github.com/golang/go/issues?q=is%3Aissue+label%3AArch-Wasm https://github.com/golang/go/issues?q=is%3Aissue+label%3AArc.... The Wasm specification is also progressing over time, sometimes unblocking some opportunities in the Go implementation. I’ve been using Go in the frontend in many (most?) of my personal projects since the early days of GopherJS, and by now I’ve compiling most of that frontend code to Wasm. I’m very happy with the experience and results, and my top wishlist item would be improvements to the binary size for faster first-time loads. If you haven’t already seen it, https://golang.org/wiki/WebAssembly https://golang.org/wiki/WebAssembly has lots of good info.
- bsaul 6y agoI'm back to programming in swift after half a year of doing go only, and i'm more and more sceptical on the benefits of adding generic programming to the language. I didn't take the time to really read the spec for go generics, but i really hope the gray beards didn't compromise on letting developers shoot themselves in the foot with overly complex design. Nowaday i would recommend every developer to go through a 3-month coding session with go, solving real problem, to really appreciate how much one can do with just basic tools and an elegant design (with a few diving session in the stdlib codebase, which is just a pure gem). This is by far the most important aspect of the language.
- throw_m239339 6y ago> I'm back to programming in swift after half a year of doing go only, and i'm more and more sceptical on the benefits of adding generic programming to the language. That's fine, you won't have to use them, or even use code that depends on generics. And I won't have to remember a dozens of silly slice tricks each time I have to implement complex data pipelines with different struct types. https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks Everybody is happy.
- badsectoracula 6y agoIf "you won't have to use it" is something people accepted then wouldn't everyone stick with kitchensink languages like C++ instead of coming up with new "clean" ones like Python, Java, C#, etc? :-P
- throw_m239339 6y ago> If "you won't have to use it" is something people accepted then wouldn't everyone stick with kitchensink languages like C++ instead of coming up with new "clean" ones like Python, Java, C#, etc? :-P No because C++ still requires some amount of manual memory management, unlike the rest of languages you listed.
- swagonomixxx 6y ago
- nemo1618 6y agoAt long last, I can issue a `retract` statement for the version I pushed over a year ago. :) ...except that only Go 1.16 can parse those statements, so I need to wait for everyone else to upgrade first. :(
- barosl 6y ago> Build commands like go build and go test no longer modify go.mod and go.sum by default. > go install now accepts arguments with version suffixes > The go mod vendor and go mod tidy subcommands now accept the -e flag, which instructs them to proceed despite errors in resolving missing packages. Do these mean I can finally reliably build the dependencies beforehand, to better utilize Docker layer cache, using this hack?[1][2] [1] https://github.com/montanaflynn/golang-docker-cache https://github.com/montanaflynn/golang-docker-cache [2] https://github.com/golang/go/issues/27719 https://github.com/golang/go/issues/27719
- minieggs 6y agoThe go:embed directive and embed.FS interface are great, as expected. If you're developing an AGPL or similarily licensed application it's incredibly easy to distribute source code with the application. //go:embed main.go go.mod go.sum LICENSE README makefile static/* var sourceCode embed.FS // ... func main() { // ... http.Handle("/source/", http.StripPrefix("/source/", http.FileServer(http.FS(sourceCode)))) // ... }
- mseepgood 6y agoAlso quines become incredibly easy: package main import ( _ "embed" "fmt" ) //go:embed quine.go var src string func main() { fmt.Print(src) }
- deleted 6y ago[deleted]
- xpressvideoz 6y ago"The go get -insecure flag is deprecated and will be removed in a future version. [...] To permit the use of insecure schemes, use the GOINSECURE environment variable instead." I'm not a fan of using pervasive environment variables. It feels like cluttering my own, well, environment. I very much prefer using explicit command-line options, or even configuration files. Does anybody share the same opinion?
- xyzzy_plugh 6y agoHuh? They're removing a flag, and recommending use of a environment variable. The environment variable can easily cover all cases in which fetching dependencies can occur, whereas the flag would have to be glued on to a bunch of `go mod` subcommands. There's no need to export this to your environment, you can just use it as a one-shot, similar to the flag: GOINSECURE=foo.com,*.bar.com go get ./...
- xpressvideoz 6y agoYeah, that's exactly what I'm opposed to. I know the in-line environment variable syntax, and I actually use it, but somehow I feel uneasy whenever I need to do that. Possibly related to my own aesthetic preference, I don't know. I just like "bolted-on" flags more.
- yobert 6y agoSince GOOS and GOARCH are not going anywhere, I'm guessing they're just trying to unify a little more to one scheme.
- andrew_mason1 6y agoVery excited to see how many codebases that do anything along the lines of `fs := flag.NewFlagSet(...)` have to update to also import `io/fs`
- svnpenn 6y agoI'm pretty disappointed by the io/fs documentation. Not a single example, and the overview doesn't explain in what situations you'd even want to use the package.
- kyrra 6y agoOfficial docs may not be there yet, but lots of people have written guides, like: https://benjamincongdon.me/blog/2021/01/21/A-Tour-of-Go-116s-iofs-package/ https://benjamincongdon.me/blog/2021/01/21/A-Tour-of-Go-116s...
- Shadonototro 6y agoVery nice release, i work with both D and GO, and it's been a pleasure, server stuff? i pick GO, everything else? D and sometimes Rust, just to spice things a little bit and be up to date with current trends, it's always a good thing to be curious and try new things