[HN Gopher] Go 1.16 Release Notes
___________________________________________________________________
Go 1.16 Release Notes
Author : ra7
Score : 173 points
Date : 2021-02-16 20:01 UTC (2 hours ago)
(HTM) web link (golang.org)
(TXT) w3m dump (golang.org)
| pella wrote:
| summary: Go 1.16 is released https://blog.golang.org/go1.16
| nemo1618 wrote:
| At 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. :(
| woodruffw wrote:
| This 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.
| martisch wrote:
| The reasoning is here:
| 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.
| nappy-doo wrote:
| It 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.
| pansa2 wrote:
| Is 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.
| dastx wrote:
| Would love to know too. I've recently thought of something that
| would be great for go wasm.
| petercooper wrote:
| Two examples although both in the 'fun' category:
|
| - https://healeycodes.com/boids-flocking-simulation/
|
| - https://dstoiko.github.io/posts/go-pong-wasm/
| kodablah wrote:
| While 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.
| smasher164 wrote:
| Excited 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 wrote:
| I'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.)
| candiddevmike wrote:
| So 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 wrote:
| I 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 wrote:
| This is by far the best tool for the job that I've found:
| https://github.com/cortesi/modd
| leg100 wrote:
| In tandem with 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.
| jbub wrote:
| I second that
| SamWhited wrote:
| This should be pretty straight forward without special support.
| Do the embedding and create a function that returns the fs.FS
| with your files in it. Put that in a file with a build tag or
| something, // +build !dev and then put the same function that
| returns an fs.FS that points at the filesystem in another file
| and add the build tag // +build dev or something along those
| lines. Now you can do go build -tags dev to get the filesystem
| versions, or build normally to get the "release" version where
| it's embedded.
| silasb wrote:
| I've been using https://github.com/cosmtrek/air
| papaf wrote:
| _I 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
|
| [2] https://github.com/codegangsta/gin
| bartekrutkowski wrote:
| Shameless self plug, but I've had that itch and decided to
| scratch it with a tool[0] that would be universal and not
| limited to Go - albeit written in it ;)
|
| [0] https://github.com/bartekrutkowski/watchr
| barosl wrote:
| > 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
|
| [2] https://github.com/golang/go/issues/27719
| mholt wrote:
| "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 wrote:
| What storm? Generics?
| mseepgood wrote:
| Yes, the proposal was accepted this week:
| https://golang.org/doc/faq#generics
| _wldu wrote:
| But is that really bad for Go? I'm not sure it is. Go1 will
| always be useful just as it is.
| mseepgood wrote:
| > But is that really bad for Go?
|
| No, I don't think so.
| throwaway894345 wrote:
| One 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.
| cpuguy83 wrote:
| I don't think the op intended "storm" to be negative
| here. Just to say that there are loads of changes coming
| soon.
| mholt wrote:
| Yeah. 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.
| benhoyt wrote:
| I'm looking forward to them, and definitely agree it's a
| great feat of software engineering ... though I'm not sure
| about "testament to the open source process". Go is open
| source, but most of the core developers are Google
| employees, and definitely the folks that worked on generics
| (Ian and Robert, mainly) are full time at Google.
|
| I don't actually think that's a bad thing: I love it that
| Google pays people to work on Go full time, and don't mind
| the language being spear-headed by a tight team with a
| vision (who happen to work at a commercial entity). I'm
| impressed with their direction, and ability to say no.
| _wldu wrote:
| Thanks. I could take them or leave them. I've used generics
| a lot in C++, but as long as I can continue writing Go1
| programs as I have been for the last 10 years, I'll be
| happy.
| btreecat wrote:
| >Go is still my favorite language when it's the right tool for
| the job.
|
| Forgive my ignorance, when would you recommend go? As in what
| problem domains have you seen it excel at?
|
| I have thought about trying it in the past and even tinkered
| with a project for a bit but didn't quite find it useful enough
| to be worth the tooling cost (at the time). Would like an
| excuse to check it out again.
| WinstonSmith84 wrote:
| I like different languages and Rust most particularly, but
| when it's about getting things done, in a reliable way and
| within a short timeframe, I couldn't find yet a better trade
| off than Go.
| fileeditview wrote:
| My guess is web servers for one, since he is the author of
| the Caddy web server (written in Go).
|
| Btw thanks for that.. I recently moved to a new VPS and
| migrated from nginx to Caddy.. I love it.
| mholt wrote:
| Awesome, glad to hear it! :)
| u678u wrote:
| I like it because it creates a small binary executable that
| is easy to deploy. Other stuff like Java or Python have big
| VMs or interpreters that are error prone and take up room.
| Also if you want a small container a go binary is small.
| hellcow wrote:
| Not GP, but I choose Go for webservices as well as devops
| tooling. I use it whenever possible. I've been very happy
| with the decision to use Go over the past 4 years at my
| company.
| mholt wrote:
| It's easy to learn and and great for getting something useful
| deployed pretty quickly. In both undergrad and grad school, I
| often chose Go and my projects -- using the same algorithms
| as classmates -- were finished sooner, ran faster, had less
| bugs, and used less resources.
|
| Go is pretty good for almost anything server-side. I wrote a
| web server in Go that a lot of businesses use in production.
| It's a very practical "get things done" language and is
| generally associated with developer satisfaction/happiness.
| Almost anywhere you use C/C++, I would try to use Go.
|
| It's progbably easier to enumerate what Go is not good at:
| native GUIs, C interop, some kinds of data science (though I
| used it as much as Python in college), and some kinds of very
| low-level programming (though it can be good for embedded
| systems, if you can stomach large binaries).
| MuffinFlavored wrote:
| > It's easy to learn and and great for getting something
| useful deployed pretty quickly
|
| I'd argue node.js is even easier to learn and even better
| for getting something useful deployed faster.
| rad_gruchalski wrote:
| The advantage of nodejs over go for web apps is the live
| reload / recompile tool chain. golang has some really
| nice apis for back end servers, single binary, no runtime
| deployment is really great. But golang lacks in that live
| reload feedback loop.
|
| I do a lot of golang but whenever I want to do something
| web browser facing, I cave in for nodejs. Especially in
| the exploratory phase when building front / back end
| together.
| nine_k wrote:
| If you want a single-binary utility, node has a
| disadvantage.
| FpUser wrote:
| My understanding is that one can deploy go application
| simply by copying. Can't get much simpler than that.
| KarlKode wrote:
| Do you know any good GUI library in go (as you mention
| _native_ GUIs as a weakness. Besides that what were you 're
| problems with the C interop? In addition to the lack of up
| to date documentation for more complicated examples, I had
| huge problems using the C interop layer with more
| complicated C++ libraries (mostly because the C interop has
| its problems with C++).
| sly010 wrote:
| C++ doesn't have a stable ABI, so C++ interop is usually
| done by wrapping a C++ library with a C interface first.
| This is true for most compiled languages afaik.
|
| GUI libraries often rely on specific language features so
| they are hard to wrap in other languages. That's why good
| GUI libraries don't exist in ANY language other than the
| ones they were written in.
| systemvoltage wrote:
| How can you do OOP with Go? I know it does some composition
| over inheritance but there 3 other aspects of OOP that I
| really like.
| throwaway894345 wrote:
| Go is very opinionated and if you try to shoehorn it into
| some existing paradigm, you will probably not enjoy the
| experience. If you follow the happy-path, you'll have a
| much better time and for me at least, I decided that the
| things I liked about OOP were actually more elegantly
| addressed with Go. Notably decomposing inheritance into
| polymorphism (interfaces and callbacks), composition, and
| automatic delegation ("struct embedding")).
| grey-area wrote:
| You don't. Elaborate abstraction is often a mistake.
|
| Which aspects do you like? Personally I have grown to
| dislike the pointless abstraction and obfuscation
| introduced by huge inheritance hierarchies, so Go is a
| breath if fresh air in that regard in just doing away
| with it all. I haven't missed classes at all.
| sheenobu wrote:
| Go can do encapsulation and polymorphism. Go doesn't do
| inheritance, of course. Channels can also help simulate
| message passing and actor-style code. What's missing?
|
| IMO, If you compare Go to an OOP language that runs in a
| VM there are some things that will fall short but the
| industry has worked around it. It's not cool to have a
| beefy Smalltalk or Java VM, with the dynamic runtimes
| that let you auto-export objects as remote endpoints...
| you have small binaries exporting HTTP or RPC services
| running in containers and interfacing with service
| discovery and fabric systems. The "object orientation" is
| now at an abstraction sitting above the running binary.
| douglasisshiny wrote:
| >It's not cool to have a beefy Smalltalk or Java VM, with
| the dynamic runtimes that let you auto-export objects as
| remote endpoints... you have small binaries exporting
| HTTP or RPC services running in containers and
| interfacing with service discovery and fabric systems.
| The "object orientation" is now at an abstraction sitting
| above the running binary.
|
| I'm not sure why an application running in the JVM in a
| container is any different. Can you elaborate?
| codegeek wrote:
| I love Go for its native capabilities to do things with
| servers etc like ssh, networking. I wrote some Go code for a
| small project to connect to external servers using SSH and it
| was a lot of fun and a breeze.
| pansa2 wrote:
| I've considered Go for writing command-line apps - mostly for
| conversion between domain-specific formats and standard ones
| (e.g. proprietary image format => png).
|
| I think when considered in isolation, Go would be perfect for
| this. However, I haven't used it because my existing code in
| this area is in C++ and I'm not sure how well the two
| languages interoperate.
| _ph_ wrote:
| Go interoperates pretty well with C - so you would have to
| create a thin C layer on top of your C++ code. This is one
| problem I constantly have with C++, it is pretty much its
| own world.
|
| I have wrapped a large C++ library for Go it was a pretty
| straight forward process. I created a file with C callable
| functions that get passed pointers to the C++ objects and
| invoke the corresponding methods on that object. On the Go
| side pointer gets wrapped in a struct type for each C++
| class and in the methods on that type I call the C
| functions. Works great.
| pansa2 wrote:
| > _I have wrapped a large C++ library for Go_
|
| How well does it work the other way round - calling Go
| from C/C++? IIRC when I first looked into doing that, it
| wasn't really possible - only threads that were started
| by Go could run Go code. Does that restriction still
| apply?
| jerf wrote:
| It's quite good at network code.
|
| Arguably, that's more because of the way you can pretty much
| completely rely on io.Reader and io.Writer being used
| pervasively throughout the ecosystem (3rd party libraries and
| all) rather than any specific "Go" special sauce, but, it is
| what it is.
| lanstin wrote:
| The special sauce is you get work in from the network,
| split it into small pieces for a bunch of worker go
| routines and then make some of that work do down stream
| calls in easy to write CS 101 style network code; the go
| routines/channels exert back pressure exactly as you
| specify and the scheduler spreads the work across all the
| cores without you having to lock anything. And they have
| libraries for a bunch of modern things. Pretty good
| libraries too, written by people that care about error
| checking.
| bombela wrote:
| How do you apply back pressure? As far as I can tell Go
| will spawn a goroutine per request (well that's how the
| standard http lib and grpc seems to do it).
|
| I would like to compute a load factor and refuse new
| requests. Or do some basic rate limiting. But the
| coroutine is spawned before I have a say...
| iampims wrote:
| the package `netutil` has a LimitListener function which
| wraps the given listener and accepts at most N
| simultaneous connections.
| bborud wrote:
| I am unreasonably happy for the standard library support for
| embedding files. I'm not kidding. This makes my life so much
| easier. :-)
| dvirsky wrote:
| +1 this is so nice. I actually think this is a bit too much
| magic:
|
| > import _ "embed"
|
| > //go:embed hello.txt
|
| > var s string
|
| > print(s)
|
| But the embed.FS example looks much nicer, I'm glad we can
| have both.
| christophilus wrote:
| Agreed. I'm kind of regretting using Node for my current
| project. Every time I look at package-lock.json, I die a
| little. I really like the way Go projects tend to have very few
| dependencies.
| ed25519FUUU wrote:
| > _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.
| kodah wrote:
| This 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.
| lima wrote:
| > 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 wrote:
| You 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.
| benhoyt wrote:
| I don't exactly know how production-ready it is, but there's
| https://pkg.go.dev/modernc.org/sqlite, which is an automated
| transliteration of SQLite's C code to Go, so that it can be
| used with CGo.
| [deleted]
| mseepgood wrote:
| > Can this be used to imbed a dynamically growing SQLiteDB?
|
| It's read-only.
| the_mitsuhiko wrote:
| Self 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.
| bsaul wrote:
| 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.
|
| 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 wrote:
| > 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 implement complex data pipelines with
| different struct types.
|
| https://github.com/golang/go/wiki/SliceTricks
|
| Everybody is happy.
___________________________________________________________________
(page generated 2021-02-16 23:00 UTC)