29 ms·
Go 1.19 Released
- petercooper 4y agoNo official blog post yet, but the official Twitter account announced it: https://twitter.com/golang/status/1554515292390408192 https://twitter.com/golang/status/1554515292390408192 and https://groups.google.com/g/golang-nuts/c/m3V8y4D02ao https://groups.google.com/g/golang-nuts/c/m3V8y4D02ao
- database64128 4y agoThe blog post is out: https://go.dev/blog/go1.19 https://go.dev/blog/go1.19
- eatonphil 4y ago> The compiler now uses a jump table to implement large integer and string switch statements. Performance improvements for the switch statement vary but can be on the order of 20% faster. (GOARCH=amd64 and GOARCH=arm64 only) Nice improvement to switch statements!
- thomasahle 4y agoKen Thompson (2012) description of switch statements in Go: https://groups.google.com/g/golang-nuts/c/IURR4Z2SY7M/m/R7ORD_yDix4J https://groups.google.com/g/golang-nuts/c/IURR4Z2SY7M/m/R7OR... > optimization of switches would be different for different architectures. every x86, amd, intel, and then all the non x86s. they all have very different execution times and cache times and pipeline times. there is no single answer. there is usually a huge pipeline cost for a computed jump. > when you are considering native-client restrictions, jump tables become impossible. > also note that go switches are different than c switches. non-constant cases have to be tested individually no matter what. > having said that, a large (where large depends on architecture) dense switch would be faster than what is implemented now. BUT there are two parameters needed to implement it. how large and how dense. no matter what is used for large and dense, there will be a micro-benchmark on some machine, under some alignment, with some branch cache that will look wrong. > what is implemented is as follows. > 1. in order, all non-constant cases are compiled and tested as if-elses. > 2. groups of larger than 3 constant cases are binary divided and conquered. > 3. 3 or fewer cases are compared linearly. > i honestly dont think there is a much better algorithm across all machines.
- yoidaj 4y ago
- liveoneggs 4y agohttps://go.dev/LICENSE https://go.dev/LICENSE where are you looking?
- ainar-g 4y agoI think, they refer to the fact that you have to sign a CLA in order to contribute[1]. And the CLA[2] includes a “Grant of Patent License” clause. [1]: https://go.dev/doc/contribute#contributor https://go.dev/doc/contribute#contributor [2]: https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual
- AnimalMuppet 4y agoThat also sounds pretty reasonable. You don't get to patent something, contribute code that uses the patent to go, and then sue people using go for violating the patent.
- teraflop 4y agohttps://github.com/golang/go/blob/master/PATENTS https://github.com/golang/go/blob/master/PATENTS Seems to be significantly more equitable than the React license that people were originally concerned about. That one terminated your rights to use React if you sued Facebook for patent infringement for any reason. This one only terminates your rights to use Go if you assert that Go itself infringes on your patents.
- nindalf 4y agoThat sounds pretty reasonable.
- 62951413 4y agoAt first glance I don't see anything done about migrating the standard library to use generics. Is there any roadmap? I remember a cascade of related improvements when Java introduced generics.
- ainar-g 4y agoThe new generic atomic.Pointer[T] has been added[1]. More general improvements for slices and maps are being prototyped in the x/exp repos[2][3] to get it right and not get stuck with a sucky implementation in the stdlib. [1]: https://pkg.go.dev/sync/atomic@master#Pointer https://pkg.go.dev/sync/atomic@master#Pointer [2]: https://pkg.go.dev/golang.org/x/exp/maps https://pkg.go.dev/golang.org/x/exp/maps [3]: https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/slices
- srpen6 4y agoThat doesn't ever have to be done. Generics are a language level feature, so it must be done at the language/compiler level, otherwise people are forced to implement it using "go generate" or other metaprogramming. The standard library doesn't ever have to change in that regard. If people want a generic version of some function, they can just write it themself. Its possible/likely that more generic functions will be added to standard library, but its not a foregone conclusion that it needs to happen, or even should happen.
- EscargotCult 4y agoI think they've mentioned that they expect that their generics spec will evolve, plus they're waiting to see what idioms emerge before refactoring the standard library.
- vlunkr 4y agoFor now there are some experimental things in the exp module. See the maps and slices packages there. But yes, my understanding is also that they kind of waiting to see how generics work out. They've promised to make no breaking changes to Go v1, so adding any functions to the standard library is not to be taken lightly. https://pkg.go.dev/golang.org/x/exp#section-readme https://pkg.go.dev/golang.org/x/exp#section-readme
- ibraheemdev 4y agoThe new `runtime.SetMemoryLimit` is actually a pretty big deal and solves a lot of long standing issues regarding the garbage collector not being very configurable, I believe including the one described by the viral "Go memory ballast" article [0]. [0]: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...
- staticassertion 4y agoI was told that garbage collection knobs were an antifeature.
- geodel 4y agoWell, you are in luck. Java provides more than five hundred flags to configure runtime behavior. So there is no limit on things you can achieve with that.
- deleted 4y ago[deleted]
- klabb3 4y agoGreat. I love it when my test matrix size exceeds the number of quarks in the known universe.
- deleted 4y ago[deleted]
- kaba0 4y agoIt hasn’t been true at all for modern GCs. G1GC basically has only one knob that you may change: the target pause time. This changes between better throughput vs lower latency (which two problems are mostly opposite ends of the same axis). And your sarcasm aside, Java has the state-of-the-art GCs by a long shot.
- ibraheemdev 4y ago
- staticassertion 4y ago
- geodel 4y agoYeah, everyone expected Go to never implement any optimization if it is not in v1.0.
- aliqot 4y agoGenerics were a mistake. @ me in the parking lot about it.
- dw-im-here 4y agoShould it be a parking lot for blue audis? Or a parking lot for red toyotas? or a parking lot for [Object object]? string? {}?
- morelisp 4y agoI'm hoping atomic.Pointer's performance gain offsets the dependency of ours that rushed to switch to some generic slice function library and basically doubled memory allocations on a near-critical path.
- srpen6 4y ago> dependency of ours which one?
- morelisp 4y agoWhy does it matter? We didn't pay for it, so I'm not going to drag anyone personally for something that's a cultural issue. If you're worried because you might use it, you'll see it in your benchmarks just like we did. If you don't have benchmarks, it's the least of your performance concerns.
- 4y ago
- chocolatkey 4y ago> On Windows only, the mime package now ignores a registry entry recording that the extension .js should have MIME type text/plain. As someone whose primary dev machine runs Windows, this is a very convenient improvement to a pitfall I ran into. I probably won't stop manually adding the JS mimetype for a while though.
- Gibbon1 4y agoI got no dog in this hunt but I've come to really despise tools that grab random stuff from the registry or the environment. There are a myriad of ways that bites developers that just want stuff to work.
- LukeShu 4y agoI mean mapping of file extension to filetype is fine as an OS feature. On Unix that's /etc/mime.types (or /usr/share/misc/mime.types, depending on the system), on Windows that's the registry. What I despise is are tools that vomit random stuff in to your config, whether that's the registry or ~/.config/.
- programd 4y agoI suspect the PATH handling change in go/exec is going to bite many people. You can't just keep exec.LookPath("prog") you now have to explicitly say exec.LookPath("./prog") to find prog in the current directory. The os/exec docs have more info on how to error handle this correctly.
- morelisp 4y agoConversely, as someone who has written a lot of code using LookPath I was shocked (like, actually gasped) to learn in these release notes that it ever did the old behavior, and now need to go check several projects for security issues. Edit: checking the actual os/exec docs instead of the release notes, it’s actually not as bad as it sounds. What the change actually seems to be is that relative paths are now ignored even if they are in $PATH.
- LukeShu 4y agoOn Unix, it only did the old behavior if you explicitly had "." in your PATH (same as all other programs doing path lookup). The original (1979) default PATH included ".", but it's been considered a bad practice since the mid 1980s, and no modern Unixes include it in the default PATH. So for most Unix users, this is a no-op change. But this is a change on Windows, where bad practices stick around because backward compatibility. (Lots of things would break if cmd.exe changed; but fortunately they fixed this in PowerShell.)
- pjmlp 4y agoI am quite sure that until the early 2000's it was configured by default in many UNIX deployments, and I did use many flavours of it, starting with Xenix in 1992.
- LukeShu 4y agoFor sure; by the late 2000s I was still seeing it, but it was fairly uncommon by then. When I said "considered a bad practice since the mid 1980s" I was specifically meaning since Grampp & Morris 1984[1]. It definitely continued to be common for decades after that. I remember lots docs that told you to run "configure" where now they'd tell you to run "./configure", but the docs tended to lag behind the actual change to the default PATH. [1]: https://people.engr.ncsu.edu/gjin2/Classes/246/Spring2019/Security.pdf https://people.engr.ncsu.edu/gjin2/Classes/246/Spring2019/Se...
- karmakaze 4y agoFinally. > Go’s memory model now explicitly defines the behavior of the sync/atomic package.
- varispeed 4y agoI love Go. Just checked my Go server pushing terabytes of data per month has over 4 years of uptime now. Run and forget... Every time new version of Go is released I am thinking about updating it, but then why if it works...
- metaltyphoon 4y agoIf it's being exposed, possibly because of security updates?
- varispeed 4y agoFair point! The server is on a private network and it is exposed via nginx reverse proxy that is regularly updated.
- lmas 4y agoNot to poop on your parade, but there's been a bunch of security updates you might want to get?
- h1fra 4y agoNice! Most tooling is not even working with 1.18 ahah
- morelisp 4y ago> The pure Go resolver will now use EDNS(0) to include a suggested maximum reply packet length, permitting reply packets to contain up to 1232 bytes Cowards!
- deleted 4y ago[deleted]
- teacpde 4y ago> Doc comments now support links, lists, and clearer heading syntax. This change helps users write clearer, more navigable doc comments, especially in packages with large APIs. As part of this change gofmt now reformats doc comments to apply a standard formatting to uses of these features. A lot of exciting new features, but really happy to see this one.
- hit8run 4y agoI like go and I can program it very well. But for full stack web dev Rails is still my go to choice. Less headaches. I don’t need to setup everything by myself (sql layer, middlewares, background jobs, validation patterns, i18n, authentication, authorization, security concerns, caching, mailing, migrations and a million other things). There’s just nothing comparable from a developers productivity perspective to what Rails offers. Would I write a command line tool in Go? For sure. How do others think about Go for web dev?
- Andys 4y agoAfter using Rails for 15 years, I'm looking for a future on Go. The niche where Rails is great is larger apps that don't need anything custom or deviating from the built-in Rails Way. Simpler apps or services are simple in Go. Apps with heavy customization are also great with Go, and there's now plenty of libraries to help you outsource heavy lifting.
- Sin2x 4y agoHugo is huge.
- lanecwagner 4y agoI feel super productive in Go. The strong typing and static compilation just make everything simple and easy
- flippinburgers 4y agoNot comparing a language with a framework would be a reasonable starting place.
- hit8run 4y agoUseless comment. What framework you use?
- Zamicol 4y agoWe're especially excited for this release because we discovered a decade old inconsistency with Go's notation of ASCII/UTF-8 that's now fixed in Go 1.19. A demonstration of the issue: https://go.dev/play/p/R9dm6uYZSas?v=goprev https://go.dev/play/p/R9dm6uYZSas?v=goprev which fails in 1.18 but passes in 1.19. A little background of the issue: 1. Go uses UTF-8 encoding. UTF-8 is a superset 7 bit, 128 code point ASCII. (Two UTF-8 creators, Rob Pike and Ken Thompson, are also two of Go's creators.) 2. All UTF-8 points over byte 128 must be encoded as two bytes. All code points 128 and below are encoded as a single byte. 3. Single byte code points between 129 and 256 are valid in Go, but not as UTF-8. 4. Go uses different notations to make the distinction between 129+ code points that are two bytes and 1-256 code points that are a single byte, notably the code points in the 129-256 range. Go represents single byte code points with the \x notation, "\xXX", and multi-byte code points with the \u notation, \uXXXX. All ASCII and single byte 129-256 codes should always be represented with "\x" notation. The core of the issue is that Go was printing code point 128, \x7F, as \u007f. As previously said, the "\u" notation is reserved for valid UTF-8 points past the ASCII range, which are always encoded as a minimum of two bytes. \x7F is a valid single byte code point in the ASCII range and should not be printed in the "\u" notation. We discussed this issue on an old thread, and Rob filed a Github issue https://github.com/golang/go/issues/52062 https://github.com/golang/go/issues/52062, and it was fixed within hours. So the following line in the release note is us! >Quote and related functions now quote the rune U+007F as \x7f, not \u007f, for consistency with other ASCII values. How did we find this? We're fans of arbitrary base conversion (https://convert.zamicol.com https://convert.zamicol.com) and we discovered this issue while checking our work in our Go libraries. If encoded as two bytes, base conversion would be less useful. Thanks Go team!
- morelisp 4y ago> Go was printing code point 128, \x7F That's code point 127, which has always been quite a special case as the only non-printable ASCII codepoint larger than the smallest printable codepoint. > All ASCII and single byte [128]-256 codes should always be represented with "\x" notation... the "\u" notation is reserved for valid UTF-8 points past the ASCII range... all valid UTF-8 "\u" notation characters must be a minimum of two bytes. Says who? I mean I guess some consistency (though, with what?) is nice, but you should be plenty prepared for the other format too. `strconv.Quote` is only meant to be equivalent to Go's source string literal representation and that allows both, and JSON only allows \u, and Python's source literals also allow both, and and and.... > UTF-8 points... single byte code points... multi-byte code points This is... at best, unnecessarily and fundamentally confusing language.