[HN Gopher] Go 1.19 Released
___________________________________________________________________
Go 1.19 Released
Author : petercooper
Score : 235 points
Date : 2022-08-02 17:13 UTC (5 hours ago)
(HTM) web link (go.dev)
(TXT) w3m dump (go.dev)
| database64128 wrote:
| The blog post is out: https://go.dev/blog/go1.19
| psanford wrote:
| Kind of annoying that the blog post links to pkg.go.dev but
| pkg.go.dev doesn't yet show 1.19 as the latest Go version so
| the links don't actually take you to the new documentation.
| benatkin wrote:
| It shows 1.19 for me.
| eatonphil wrote:
| > 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 wrote:
| Ken Thompson (2012) description of switch statements in Go:
| 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.
| karmakaze wrote:
| Finally.
|
| > Go's memory model now explicitly defines the behavior of the
| sync/atomic package.
| [deleted]
| morelisp wrote:
| > 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!
| hit8run wrote:
| I 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?
| chocolatkey wrote:
| > 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 wrote:
| I 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.
| varispeed wrote:
| I 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 wrote:
| If it's being exposed, possibly because of security updates?
| lmas wrote:
| Not to poop on your parade, but there's been a bunch of
| security updates you might want to get?
| programd wrote:
| I 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 wrote:
| Conversely, 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 wrote:
| On 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.)
| h1fra wrote:
| Nice! Most tooling is not even working with 1.18 ahah
| 62951413 wrote:
| At 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.
| EscargotCult wrote:
| I 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 wrote:
| For 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
| candiddevmike wrote:
| I think almost everyone is waiting to see those idiom too
| (myself included). If I'm going to rewrite stuff, I want to
| be able to justify it (less LOC may be be enough) and "do it
| right". Hopefully I get to see them in the sdlib soon!
| srpen6 wrote:
| ainar-g wrote:
| The 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
|
| [2]: https://pkg.go.dev/golang.org/x/exp/maps
|
| [3]: https://pkg.go.dev/golang.org/x/exp/slices
| teacpde wrote:
| > 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.
| staticassertion wrote:
| Interesting to see Go very slowly begin to get optimizations that
| other languages have had for 30 years. This seems like a good
| case study in rolling your own compiler toolchain from scratch.
| tomcam wrote:
| Nice username! Is it your opinion that the creators of go were
| not familiar with previous language implementations?
| eikenberry wrote:
| It was too bad they had to do it. Being able to use say LLVM's
| compiler tech would have had it's advantages. But they wanted a
| good developer UX which LLVM just doesn't provide.
| funny_falcon wrote:
| And disadvantages. LLVM is still hard to build precise GC
| with.
|
| Largest profit Go gains from custom toolset - they able to
| buld precise GC.
|
| Then they were able to build reliable preemptible scheduler,
| which would be hard as well if they use LLVM/GCC.
| geodel wrote:
| Yeah, everyone expected Go to never implement any optimization
| if it is not in v1.0.
| aliqot wrote:
| Generics were a mistake. @ me in the parking lot about it.
| morelisp wrote:
| I'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 wrote:
| > dependency of ours
|
| which one?
| morelisp wrote:
| Why 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.
| srpen6 wrote:
| why do you need to be so combative? I like to learn from
| others mistakes if I can. If you don't want anyone to
| learn anything from your issue, and force everyone to
| figure out everything for themself, thats your choice.
| nindalf wrote:
| They've made it clear - they don't want to denigrate a
| library they're using, likely for free. Imagine the
| author of that library seeing such a comment. I'm sure
| you'd find it educational, but it's a terrible experience
| for the author.
| staticassertion wrote:
| Not sure what your point is. Mine is that throwing out
| decades of compiler optimizations is a serious cost to pay.
| geodel wrote:
| Thats a kind of gaslighting isn't it. Seem to be saying no
| one dare to write new compiler ever because v1 of new
| compiler will be very likely worse than v10 of existing
| compiler technology.
|
| If they could have simply use LLVM they would be stuck with
| slow compilation that Rust folks are very fond of telling.
| And they would not be able to use segmented stack which was
| differentiating factor for language.
| steveklabnik wrote:
| I thought Go removed segmented stacks in 1.3. Is that
| incorrect?
| coder543 wrote:
| Go doesn't use segmented stacks anymore, but it does
| still have resizable stacks that start small and are
| technically able to grow to any size.
|
| IIRC, they were artificially capped at 1GB a few years
| ago since it was decided that stacks larger than that
| usually indicate an obvious bug, and if infinite
| recursion causes a goroutine stack to consume all memory
| on a machine, the OOM killer would make this harder to
| diagnose than a reproducible panic with a backtrace.
| staticassertion wrote:
| I didn't say it was the wrong call. My favorite part
| about new languages is being able to look at their
| choices over the course of decades.
| geodel wrote:
| Well it is implied, if one talk only about great cost but
| not benefits.
| staticassertion wrote:
| The post is about the optimization being implemented now.
| The cost is that it wasn't implemented before. I find
| that interesting.
| morelisp wrote:
| > Thats a kind of gaslighting isn't it.
|
| No, jesus christ, not every bad take is gaslighting.
| pjmlp wrote:
| Another one is adding yet another reason to keep writing
| code in C and C++.
| dang wrote:
| Could you please stop posting flamewar comments? You've done a
| ton of it in this thread alone--not cool.
|
| Programming language flamewars are particularly tedious and
| particularly easy to avoid, so please let's not do that here.
|
| https://news.ycombinator.com/newsguidelines.html
|
| We detached this subthread from
| https://news.ycombinator.com/item?id=32321813.
| bool3max wrote:
| How is that a flamewar comment? It's just an observation.
| [deleted]
| icholy wrote:
| Interesting how some people are unfamiliar with how technology
| s-curves work.
| staticassertion wrote:
| Time will tell. We have 11 years of Go to look at so I guess
| your argument is that we'll start seeing rapid adoption of
| optimizations? So 11 years to hit the upward curve of the S,
| if we see that.
| vmchale wrote:
| >This seems like a good case study in rolling your own compiler
| toolchain from scratch.
|
| They've flouted good sense before too - they only recently
| started passing function arguments in registers.
|
| Using jump tables to compile pattern matches has been done
| since the 90s at least.
| preseinger wrote:
| If O(3) people want to design a new language, how should they
| incorporate the "optimizations that other languages have had
| for 30 years" into that language that will satisfy the
| internet's peanut gallery?
|
| (alternatively)
|
| Go is the most successful language released in the last 20 to
| 30 years, so if this is meant as a critique I can't see how
| it's valid.
| coliveira wrote:
| > most successful language released in the last 20 to 30
| years
|
| You must be living in an alternate world...
| throwaway17_17 wrote:
| Can you explain why you think the claim is incorrect. I
| would think it at least plausible. A huge portion of the
| languages in common use are all over 20 years from
| introduction. So Go is certain to be in the top for
| language introduced after 2002. Or at least I would think.
| eikenberry wrote:
| If you had said 20 years you'd probably have been right.
| But going back 30 includes Python which is still WAY
| bigger than Go.
| throwaway17_17 wrote:
| Python was released Feb. 20, 1991. I checked that before
| I posted. And I am not the original poster and did limit
| my comment to 20 years. But, I did forget Java in the 30
| year category.
| coliveira wrote:
| Even if you had said only the last 15 years, that would
| still include languages like Clojure, Rust, Typescript,
| Swift, and Julia. But from 20 to 30 years you start to
| get into the league of: C# and Java, R, Lua, PHP, Ruby...
| In other words, there is no way you can prove your
| assertion.
| throwaway17_17 wrote:
| Just to note, I didn't make the original assertion about
| the success of Go. I was only asking why your dismissal
| of the claim was so emphatic. I just stated that I found
| the assertion plausible where languages from the last 20
| years were concerned and wondered why you were so certain
| Go could not be at the top.
| jrockway wrote:
| I think these debates boil down to people just talking
| past each other about things that don't matter. "Blue is
| the most widely used color in company logos in the last
| 30 years" "Yeah well I like red better" Yeah, that's
| fine.
| throwaway17_17 wrote:
| You're probably right, I was thinking about amount of
| code in actual production use and limiting to languages
| from after 2002, but some people clearly had different
| things in mind.
| shakow wrote:
| > how should they incorporate the "optimizations that other
| languages have had for 30 years"
|
| Leverage an already existing compiler backend, typically GCC
| or LLVM - just like Julia, Rust, or Swift.
|
| Or, similarly, target an existing, battle-tested VM - like
| e.g. Elixir, Kotlin, Clojure, or F#.
|
| > Go is the most successful language released in the last 20
| to 30 years
|
| Python? Ruby? Javascript? Java? C#? TypeScript? PHP? R?
| Visual Basic?
| eikenberry wrote:
| GCC and LLVM both have terrible UX with their ridiculous
| compilation times. Go wanted good developer UX so that
| ruled those out.
|
| None of those VMs would allow for the native compilation
| that was another design goal.
|
| They had specific design goals which nothing out there met.
| shakow wrote:
| > GCC and LLVM both have terrible UX with their
| ridiculous compilation times.
|
| And so will go if it implements the optimizations they
| implement. GCC and LLVM are not putting sleep(10)
| everywhere just for the sake of longer compilation times.
| staticassertion wrote:
| Using existing compiler toolchains, obviously. In 11 years I
| think it's interesting to see how that has panned out. Go is
| very popular for a relatively new languages, yes.
| eikenberry wrote:
| Yep... and it would have likely just fizzled out as all the
| existing toolchains have a terrible UX and that is one of
| Go's best points.
| pjmlp wrote:
| Meaning keeping C and C++ alive, if nothing else as the
| languages those compiler toolchains are written on.
| staticassertion wrote:
| Does anyone think that C and C++ are going to die?
|
| Anyway, I'm actually glad that Go went down this path
| exactly because it allows us to look at the decision and
| see the costs. I'm very curious to see if we _do_ hit
| that S curve, as another poster mentioned.
| pjmlp wrote:
| Not on our lifetime, but reducing the use cases that
| require their uses helps.
|
| This is also why I follow GraalVM since the days it used
| to be MaximeVM.
| staticassertion wrote:
| I personally have no issue with C++ being used for
| compilers, but to each their own.
| pjmlp wrote:
| Depends on how one stands in regards to secure code.
|
| I love C++, but secure like the ALGOL linage it will
| never be, no matter how many fixes we throw at it,
| because that C copy-paste compatibility layer is never
| going to be thrown away.
| staticassertion wrote:
| I'm quite fond of secure code but attackers don't really
| exploit memory unsafety in compilers as they're not often
| in a position to or, if they are, there are much simpler
| ways to execute code.
| pjmlp wrote:
| Except compilers aren't used in isolation, if one writes
| the compiler toolchain in C++, chances are other system
| critical components are also written in C++, if nothing
| else for the comfort of single language use.
|
| Security must be applied end to end, and not pontual.
| Shorel wrote:
| Ten years ago, that was the feeling. C++ was perceived as
| a dead end. Everything was going to be Java or C#.
|
| But it didn't die. And today there are more C++ jobs
| available than a decade ago.
|
| In contrast, today there are some new languages that can
| actually be good contenders for C++. My personal
| favourite is Dlang.
| pjmlp wrote:
| Kind of true, depends where you look at.
|
| Compilers, HPC, GPGPU, game engines, OS drivers, C++ is
| probaly the king of those domains.
|
| Distributed computing, GUI frameworks, mobile apps, CNCF,
| other contenders rule the day.
| msbarnett wrote:
| > If O(3) people want to design a new language, how should
| they incorporate the "optimizations that other languages have
| had for 30 years" into that language that will satisfy the
| internet's peanut gallery?
|
| Generally this is done by building the language on an
| existing compiler backend, and the ability to do this is in
| fact why the backend/frontend distinction in compilers was
| created to begin with.
|
| > Go is the most successful language released in the last 20
| to 30 years, so if this is meant as a critique I can't see
| how it's valid.
|
| False dichotomy. A language can both be popular and have left
| very obvious optimizations on the table for years.
| kjksf wrote:
| > Generally this is done by building the language on an
| existing compiler backend,
|
| Go was implemented on top of existing compiler backend. It
| just wasn't LLVM.
|
| Go was based on a C compiler suite from Plan 9. See
| https://9p.io/sys/doc/compiler.html and
| https://github.com/huangguiyang/plan9-cc
|
| Those compiler suite was very portable ("The compilers are
| relatively portable, requiring but a couple of weeks' work
| to produce a compiler for a different computer.") which is
| a strength Go inherited from get go.
|
| Also 2/3 of Go designers (Pike, Thompson) were intimately
| familiar with that code base by the virtue of having
| written it in the first place.
|
| (some) people just get twisted that Go didn't pick LLVM
| because it had better optimizations as if in engineering
| you just look at one positive and ignore all the negatives.
| For LLVM the list of negatives is huge: slow compilation,
| gigantic code base that would take ages to learn and
| contribute changes, architecture that would preclude some
| of the optimizations in Go (Go has a very smart and fast
| linker where using LLVM would forced them to just use the
| LLVM linker, segmented stacks not possible, GC not
| possible) etc.
|
| Just to put things in perspective: just implementing
| segmented stacks LLVM would probably require more man hours
| than the all the compiler work in Go 1. And would
| realistically require forking LLVM because why would Apple
| devs with bonuses tied to shipping what Apple needed care
| about some new language from 3 guys from Google.
| pjmlp wrote:
| This is one case I am fully behind Go's decision not to be yet
| another compiler toolchain that keeps C and C++ dependencies
| around.
|
| It is indeed a very good case study to prove Go's suitability
| as systems programming language.
|
| Naturally one might add that writing compilers, assemblers and
| linkers isn't systems programming.
| petercooper wrote:
| No official blog post yet, but the official Twitter account
| announced it:
| https://twitter.com/golang/status/1554515292390408192 and
| https://groups.google.com/g/golang-nuts/c/m3V8y4D02ao
| ibraheemdev wrote:
| The 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...
| staticassertion wrote:
| I was told that garbage collection knobs were an antifeature.
| geodel wrote:
| Well, 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]
| klabb3 wrote:
| Great. I love it when my test matrix size exceeds the
| number of quarks in the known universe.
| oconnor663 wrote:
| Generics were an antifeature too.
| ibraheemdev wrote:
| Is allocating a large array on startup to avoid gc cycles
| better?
| staticassertion wrote:
| Just trying to understand if this is what simple looks
| like.
| coder543 wrote:
| 2 knobs after a decade vs how many in Java? Yes, that is
| exactly what simple looks like.
|
| After years of real world experience, I can say that the
| Go garbage collector worked fantastically across a range
| of applications that I've been involved in. No tool is
| perfect for every job, of course, and having hundreds of
| knobs does not make Java perfect for every job either.
| eikenberry wrote:
| I'd say it makes Java's GC worse at nearly every job as
| that means the defaults probably aren't what you want but
| are probably what you are going to use.
| truffdog wrote:
| The Java problem is that you wind up in a blame game
| where one team blames the code and the other blames the
| GC settings and you wind up doing a lot of fruitless
| flailing. No knobs really cuts down on that nonsense.
| vips7L wrote:
| In situations where you actually are allocating on the
| heap, Java's default GC significantly out performs Go's.
| Just look at the binary tree bench marks.
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| coder543 wrote:
| Even that simplification is too much. Java uses a
| generational GC, so the fewer objects that survive the
| nursery, the less work it has to do.
|
| That benchmark _does not_ mean Java 's GC is faster when
| you're "actually allocating on the heap". It means Java's
| GC is faster when you're spewing garbage onto the heap as
| fast as possible.
|
| Since Go makes heavy use of stack allocation where
| possible, short-lived garbage usually doesn't end up on
| the heap, but this benchmark is designed to force that
| outcome. Go's garbage collector is optimized to minimize
| latency and STW, but this does come at the cost of
| decreased throughput. The opposite can be said of the
| majority of Java GC implementations, which trade latency
| and STW time for increased throughput.
| staticassertion wrote:
| cool just wanted to understand if this is still "simple",
| I can never tell
| dang wrote:
| Please stop.
| coder543 wrote:
| You clearly seem to be here to troll / just crap on Go
| while trying to appear fake-earnest, and that goes
| against HN guidelines. I believe this falls under
| "sneering".
|
| I've actually also used Rust plenty in professional
| contexts over the last five years. Once again: no tool is
| perfect for every job.
| staticassertion wrote:
| I didn't say anything about Rust, nor is Rust on my mind
| with regards to any of those comments. I mostly think of
| Java and C# when I think about Go.
|
| But I am being transparently snide, certainly.
| coder543 wrote:
| As I recall, C#'s GC famously has very few knobs as well.
| I don't think you can swap the GC implementation, either,
| which is a source of even more complexity in the world of
| Java.
| bit_flipper wrote:
| I had a look through some of your comments here and
| elsewhere and just wanted to give you some friendly
| feedback: This style of commenting is quite toxic. I
| think you'll feel happier if you let go of the tribalism
| and engage with others in good faith.
| MichaelMoser123 wrote:
| why is asking questions regarded as toxic? I genuinely
| want to know
| staticassertion wrote:
| I engage in good faith conversations all the time.
| dilap wrote:
| Obviously the fewer you need the better. Zero-knob GC not yet
| discovered.
| the-smug-one wrote:
| Isn't that what Java's ZGC stands for ;-)?
| yoidaj wrote:
| liveoneggs wrote:
| https://go.dev/LICENSE where are you looking?
| ainar-g wrote:
| I 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
|
| [2]: https://cla.developers.google.com/about/google-
| individual
| AnimalMuppet wrote:
| That 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 wrote:
| 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 wrote:
| That sounds pretty reasonable.
___________________________________________________________________
(page generated 2022-08-02 23:01 UTC)