18 ms·
Go 1.21 Release Candidate
- 29_29 3y agoThis is a big release. Lots of new packages. The language is changing
- benhoyt 3y agoIt is a big release, and the number of new stdlib packages (4) is relatively high for a Go release. That said, apart from the addition of some minor builtins (min, max, clear), the language isn't changing. That happened back in 1.18 with the introduction of generics.
- Patrickmi 3y agoGo releases feels it’s has changed massively when reading the release notes but when coding it’s just like every other day
- Karupan 3y agoRelease candidate
- philosopher1234 3y agoSeems like a really substantial release to me. The new built in functions min, max, and clear are a bit surprising, even having followed the discussions around them. The perf improvements seem pretty great, I’m sure those will get much love here. Personally, I’m most excited about log/slog and the experimental fix to loop variable shadowing. I’ve never worked in a language with a sane logging ecosystem, so I think slog will be a bit personally revolutionary. And the loop fix will allow me to delete a whole region of my brain. Pretty nice.
- anyoneamous 3y agoAs a non-developer who has only gone as far as "hello world" in Go, I'm baffled by the idea that the log/slog thing is new - that seems like an absolutely basic language feature. TBH I'd say the same about min/max, but could forgive those being absent since Go isn't known for being numerically-focused...
- tick_tock_tick 3y ago> that seems like an absolutely basic language feature Most languages have no logging "system" built in at all. Honestly it's really quite rare.
- deleted 3y ago[deleted]
- ilyt 3y ago> As a non-developer who has only gone as far as "hello world" in Go, I'm baffled by the idea that the log/slog thing is new - that seems like an absolutely basic language feature. Then you'd be even more surprised when you learn that the vast majority of languages do not have standard logging library in core. Most have one or few common libraries that community developed instead, but they are not in stdlib, and if stdlib has one it's usually very simple one (Go had standard logger interface that was too simple for example)
- anyoneamous 3y agoI have evidently been spoiled by Python and it's abundance of batteries.
- justinsaccount 3y agoPython does not include a structure d logging package as part of the stdlib as far as I know. What package are you thinking does what slog does?
- anyoneamous 3y agoJust the standard "logging" - might not meet the definition of "structured logging", but at a glance it seems about as featureful as what is being added to Go right now.
- 3y ago
- ilyt 3y ago> The new built in functions min, max, and clear are a bit surprising, even having followed the discussions around them. Was that discussion pre-generics? Most of functions and libraries introduced in Go 1.21 is stuff people already put in community libraries (lodash being probably most popular, despise utterly nonsensical name not relating to anything it does) so it is just potentially cutting extra dependencies for many projects.
- philosopher1234 3y agoNo, it was a recent discussion, here: https://github.com/golang/go/issues/59488 https://github.com/golang/go/issues/59488
- tomjakubowski 3y agoYou mean samber/lo? What is nonsensical about the name?
- saghm 3y agoAm I reading it correctly that `clear` does different things for maps and slices? Why doesn't it remove all the items from the slice like it does with the map, or set the values in the map to the zero value like it does for slices? That seems like an easy thing to get tripped up on
- arp242 3y agoYou can't "remove all items from the slice"; you can only change the length to 0: "slice[:0]".
- saghm 3y agoThat _is_ removing all the items from it; my point is that if you pass a map with `n` entries to clear, you end up with a map with 0 entries. If you do the same with a slice with `n` elements, I'd imagine most people would expect to end up with a slice with 0 elements, but instead you have a slice with `n` copies of the zero value.
- arp242 3y agoBut it's not "removing items", at least not for all meanings of the word "removing". You can see this with something like: s := []string{"hello", "world", "foo", "bar"} fmt.Println(s) // [hello world foo bar] s = s[:0] fmt.Println(s) // [] s = append(s, "XXX") s = s[:2] fmt.Println(s) // [XXX world] Which will print back "XXX world" because it's using the same array, and nothing was ever "deleted": only the slice's length was updated. This is why "delete(slice, n)" doesn't work and it only operates on maps. I suppose clear(slice) could allocate a new array, but that's not the same behaviour as clear(map) either, and doesn't really represent the common understanding of "clearing a slice". The only behaviour I can think of that vaguely matches what "clearing a slice" means is what it does now.
- saghm 3y agoOkay, yeah, that definitely isn't what I expected. It's pretty wild to me that `s = s[:2]` will ever work fine if `len(s) == 1`; I would have assumed that it would always be the same regardless of how the slice was created. Playing around with it, it seems like this means that if you pass a subslice to a function, that function can get access to things from the entire slice, including the portions that weren't in the slice passed in[1]! I think I understand now why `clear` can't work on slices the way I think it should, but only because slices themselves don't work the way I feel even stronger that they should. [1]: https://play.golang.com/p/fYrGUbCePuD https://play.golang.com/p/fYrGUbCePuD
- earthboundkid 3y agoAn extremely generic release.
- candiddevmike 3y ago> New slices package for common operations on slices of any element type. This includes sorting functions that are generally faster and more ergonomic than the sort package. > New maps package for common operations on maps of any key or element type. > New cmp package with new utilities for comparing ordered values. Pun intended? =D
- deleted 3y ago[deleted]
- evacchi 3y agoGOOS=wasip1 is pretty cool IMO (disclaimer: I work on wazero.io)
- kernal 3y agohiyo
- Hakkin 3y agoHuh, I'm glad to see generic Min/Max functions, but the fact that they're built-ins is a little odd to me. I would have expected them to put a generic math library into the stdlib instead. The fact the stdlib math package only works with float64s has always struck me as a poorly thought out decision.
- klodolph 3y agoMaking them builtins allows them to work as you’d expect with cases like, func clamp(x float64) float64 { return max(0, min(1, x)) } With ordinary functions, the arguments are assigned types too soon, and you get integer types for 0 and 1 in the above code. In C++ you might make the types explicit: template<typename T> T clamp(T x) { return std::max<T>(0, std::min<T>(1, x)); } That’s not meant to be exactly the way you’d write these functions, but just a little bit of sample code to show how the typing is different.
- Hakkin 3y agoThat doesn't seem to be true, unless I'm misunderstanding something. https://go.dev/play/p/ymM0tD3aGYg?v=gotip https://go.dev/play/p/ymM0tD3aGYg?v=gotip Obviously these sample functions don't take into account all the intricacies of float min/max functions.
- klodolph 3y agoYou can const x = min(a, b) assuming a and b are const.
- onionisafruit 3y agoI can't think of a use case for that. If all the inputs are consts, then you know the values and can just assign it to be the less of a or b. Am I missing something here?
- nordsieck 3y ago
- ubavic 3y agoI enjoy Go so much. It is almost perfect language for getting things done, but I still can't understand some design choices. Does someone knows why Go uses env variables (like GOOS and GOARCH) instead command line arguments?
- superb_dev 3y agoIt could make it easier for build systems to be multi platform. You don’t have to keep track of custom args and add them to every call, you can just set the environment once.
- abalaji 3y agoI assume so that it can be sticky across invocations and is easy enough to debug using `go env`
- Cthulhu_ 3y agoI guess so you can configure them on e.g. a build server instead of tweak your build command, but then, neither is particularly portable.
- francislavoie 3y agoEnv vars make it easier to automate in CI. The actual script to build for each os/arch is the same but only the vars change. It's convenient. You can always prefix the command with the env vars on the same line if you want a one-liner.
- Patrickmi 3y agoAs a PL focused on building networking services across different arch and platforms if it was any different that’ll be the first thing to hate in go
- Cybergenik 3y agoWrote a blog explicitly asking for some of these changes last year: https://www.lremes.com/posts/golang/ https://www.lremes.com/posts/golang/ Nice to see their going in a good direction.
- colesantiago 3y ago[flagged]
- Cthulhu_ 3y agoWhat big thing are you expecting? Go is more of a stable language, a reliable and boring language for building software now that in ten years you can still maintain. Go isn't peaking, Go isn't an exciting or cool or hype language, it's just... there. And that's just fine. Too many languages just started borrowing features from others, saying "yes" to every suggestion, until they got out of control and all over the place. Go says "no" more often than not. Which isn't always a good thing, mind; generics took a long time because they wanted to understand the problem and not add more like what happened to Java. The builtin min/max features up until this release only supported float64. Lots of small annoyances like that.
- nu11ptr 3y agoIt is interesting to see them add things like the "clear" function for maps and slices after suggesting to simply loop and delete each key one at a time for so long. Is this a result of the generics work that makes implementation easier vs. the extra work of making a new "magic" function (like "make", etc.)?
- Waterluvian 3y agoIt might also be that they’ve worked their way down the priority list and are getting to these features that are largely just to tidy up code.
- stefan_ 3y agoClearing a container is usually a much simpler and faster operation than looping through all and removing them individually. That's not a question of tidying something up.
- onionisafruit 3y agoThere were compiler optimizations for clearing by iterating. I haven’t looked at the code, but I suspect this won’t be much more efficient than iterating was with the optimizations.
- yencabulator 3y agoI expect both will result in the same code; the only difference is that the clear built-in can handle maps with NaN keys.
- maximilianburke 3y agoThat `clear` on a slice sets all values to their type's zero value is going to be extremely confusing especially coming from other languages (Rust, C#, C++, Java, ...) where the same-named function is used on list-ish types to set their length to zero. Doubly-so when `clear` on a map actually seems to follow the convention of removing all contained elements.
- showdeddd 3y agoI wonder if the new stdlib logger is featured enough to get rid of logrus/zerolog.
- JyB 3y agoI'm wondering the same. Anyone already played for some time with the pkg?
- richieartoul 3y agoI've been using it for a few weeks now. Overall pretty happy with it. Has good default API, and can be basically arbitrarily extended as needed. We even have a custom handler implementation that allows us to assert on specific logs being emitted in our stress/fuzz testing.
- xh-dude 3y agoThere’s been an emphasis in slog on Handler composition over directly implementing a ton of features. Personally I love it - there are things I’ve needed, that slog can do, that few other loggers make easy/possible. Zerolog will still be relevant for raw performance (slog is close to zap on perf - doesn’t win benchmarks, doesn’t look out of place either), fewer really need it but some really do.
- monocasa 3y agoNice, my push for actually using the sha256 instructions on amd64 finally got released. 3x-4x increase in hash speed on most x86 which is really nice for content addressable storage use cases like handling container images.
- candiddevmike 3y agoGot a link to the PR? Curious to see how this is implemented.
- jeffbee 3y agoIt looks like https://go-review.googlesource.com/c/go/+/408795 https://go-review.googlesource.com/c/go/+/408795
- xyst 3y agoSeems like these changes only benefit you if you have an Intel processor. If you have an AMD or Arm processor, you won’t see any difference. Also, interesting to see assembly again after many years. Haven’t touched that since college during a compilers and assembly course. Edit: never mind, amd has implemented these “sha-ni” instructions since “Zen” [1] [1] https://en.wikipedia.org/wiki/Intel_SHA_extensions https://en.wikipedia.org/wiki/Intel_SHA_extensions
- monocasa 3y agoAnd adding that they already had support for ARM sha256 instructions https://github.com/golang/go/blob/master/src/crypto/sha256/sha256block_arm64.s https://github.com/golang/go/blob/master/src/crypto/sha256/s...
- jeffbee 3y agoHuh, that is interesting how they do that. They are enabling SHA instruction support based on CPUID and without respect to the value of GOAMD64. I did not realize Go was doing that.
- bbkane 3y agoI love the new stdlib additions- I've been pulling in these dependencies since generics arrived and it'll be nice to have them built-in.
- H1Supreme 3y agoThe new built in functions for slice manipulation are a welcome addition!
- panzi 3y agoWait is this now heap allocating a value in every iteration of every loop? I hope that allocation is optimized out in every case where there isn't a closure over the loop variable?
- collinvandyck76 3y agoI didn't see this optimization when I read the overview. I also hope that the compiler is smart enough to avoid this.
- dr2chase 3y agoThe way to view it is "unless there is syntactic sharing, it is a for loop, same as before". The compiler uses a syntactic test (with little knowledge of control flow or value use) to exclude loops from the change. This excludes most loops. After the change, escape analysis figures out if the changed iteration variable actually needs heap allocation; in an internal sample of code that was actually buggy (i.e., biased, guaranteed to have at least one loop like this) for 5/6 of the loops escape analysis decided that heap allocation wasn't needed. The reason this optimization isn't part of the language change proposal is that escape analysis is "behind the curtain"; ignoring performance, a program should behave the same with or without it, and it is removing heap allocations all over the place already. Escape analysis is also extremely difficult to explain exactly, so you would not want it in the spec, and "make escape analysis better" (that is, change it) is one of the prominent items in the bag of things to do for Go.
- vbezhenar 3y agoOf course it'll be optimized. It's just semantics that's changed. Compiler will make sure to copy variable value to new address.
- quacker 3y agoThey discuss this here: https://github.com/golang/go/wiki/LoopvarExperiment#will-the-change-make-programs-slower-by-causing-more-allocations https://github.com/golang/go/wiki/LoopvarExperiment#will-the... In fact, you can enable warnings/logs that indicate whether code that is affected by the loopvar experiment results in a stack-allocated or heap-allocated loop variable: https://github.com/golang/go/wiki/LoopvarExperiment#can-i-see-a-list-of-places-in-my-code-affected-by-the-change https://github.com/golang/go/wiki/LoopvarExperiment#can-i-se... I imagine that the current workarounds for this issue also end up with heap-allocated variables in many cases.
- cube2222 3y agoI'm a bit surprised that the slog package was added to the stdlib, but it does seem to use the API that I think is the most ergonomic across libraries I saw in Go (specifically, varargs for key values, and the ability to create subloggers using .With), so I guess it's nice most of the community will standardize around it. If all goes well, you won't have different libraries using different loggers anymore, in some not too distant future, which should improve easy composability.
- fourseventy 3y agoI literally just updated all of my golang logging to use zerolog so i could get severity levels in my logs. Bad timing on my part! I guess ill re-do it all with slog, i prefer stdlib packages to third party packages.
- philosopher1234 3y agoideally an slog handler is built for zerolog, so that you can use slog BE and keep the zerolog FE
- d1str0 3y agoTomorrow we will see a blog post titled “Why I always use 3rd part dependencies instead of stdlibs”
- chrsig 3y agoI have mixed feelings about it. if nothing else, the name..."slog" isn't exactly the word i want repeating to myself as I'm working.
- tomjakubowski 3y agoA little honesty is a good thing
- endorphine 3y agoYou can alias it when importing it then.
- throwaway5959 3y agoWhy is map copy "dst, src" vs "src, dst"?
- klodolph 3y agoCopy operations in Go are normally destination first, source second. This includes builtins like copy() and library functions like io.Copy(). Making it "src, dest" would make this one case the opposite of all the others. Note that the order mimics variable assignment. You copy an integer with: var src, dest int dest = src // dest first, src second I appreciate the consistency.
- Xeoncross 3y agoThanks, "mimics variable assignment" is a good way to remember it
- deleted 3y ago[deleted]
- kinghajj 3y agoIt's not that uncommon. https://en.cppreference.com/w/cpp/string/byte/memcpy https://en.cppreference.com/w/cpp/string/byte/memcpy https://en.cppreference.com/w/cpp/string/byte/strncpy https://en.cppreference.com/w/cpp/string/byte/strncpy https://en.wikipedia.org/wiki/X86_assembly_language#Syntax https://en.wikipedia.org/wiki/X86_assembly_language#Syntax
- esprehn 3y agoTo match the semantics of dst = copy(src). Multiple languages model operations like this in assignment order.
- WhereIsTheTruth 3y ago> New built-in functions: min, max and clear. What a mistake.. reserved keywords are words I can no longer use for myself... Zig does it better by requiring a prefix @ for most their builtin needs
- philosopher1234 3y agoThey're not reserved keywords. Existing/package defined min/max functions would take precedence. They have the same semantics as `append`
- WhereIsTheTruth 3y agoYou refactored your code, you think you wrote your ``min`` function, but no, it'll call the builtin one, without warning you.. I don't like this design..
- bananapub 3y agoif you have so few tests and so little code review that this matters then I am not sure what to suggest
- vito 3y agoThe compiler will tell you if the types aren't compatible, and this is only for primitive comparable types. What `min()` implementation could you have that even does something different?
- KRAKRISMOTT 3y agoA heap?
- Chiron1991 3y agoNot too familiar with go toolchains, but I bet there's a linter that will warn you about shadowing builtins.
- nasretdinov 3y agoI am honestly surprised nobody mentioned the intention of Go team to make multipath TCP the default in later releases
- kkirsche 3y agoCan you elaborate on why this is surprising for those who don’t fully understand the differences?
- nasretdinov 3y agoI don't think Multipath TCP has been tested in enough environments to become the default yet. It's compatible with TCP, yes, but it's mostly useful for e.g. mobile devices that have multiple links like Wi-Fi and 4G, and it lets users to maintain TCP connection to a certain service even when moving across networks. Go seems to be server-oriented first, and there are some potential downsides to multipath TCP in a datacenter environment (e.g. potentially higher CPU usage, etc).
- arp242 3y ago"In a future Go release we may enable Multipath TCP by default on systems that support it." This could be five years from now. Or maybe never.
- Patrickmi 3y agoFrom what I heard the reason for not defaulting, its not yet acceptable across different platforms esp windows and most who’ll need this are data centers 5 years its too long, since linux kernel has accepted mptcp
- silisili 3y agoThese new packages, like slices and maps, were a long time coming. So glad it's finally here. I cannot even begin to tell you how many different itemInSlice functions I've written over the years.
- throwawaygo 3y agotbh whenever I write one of these it makes me wonder if I can accomplish the same logic in a better way.
- tptacek 3y agoWe've had `slices` and `maps` in the `exp` tree for awhile; I think they're pretty widely used already.
- openasocket 3y agoGlad to see the crypto performance improvements, I noticed a major regression in the performance of some auth code with 1.20
- pizzafeelsright 3y agoWas there a push to get it released today?
- racingmars 3y agoNo, release candidate 2 was released today; Go 1.21 is not yet released.
- pizzafeelsright 3y agoBased upon the date as .21 on the 21st.
- throwawaygo 3y agoSo I guess with new builtin functions we will be breaking backwards compatibility?
- racingmars 3y agoIf you already have your own functions or variables named max, min, or clear in-scope, they will shadow the new built-in functions and your code will continue to use your own version of the functions. No breakage to existing identifiers that match the new function names. (This is the same behavior as the append built-in function today, for example. These things in Go are _not_ reserved keywords, they are simply global functions that can be overridden at other scopes.)
- metaltyphoon 3y agoLets be honest, its a terrible choice
- racingmars 3y agoIn what way? Overall as a language, identifier shadowing is a feature of the language in nested scopes. Are you saying built-in identifiers (that aren't language keywords) should be treated specially and work differently than user-declared identifiers?
- metaltyphoon 3y agoIt's terrible, IMO, because every package that has generic words is now a variable name I can't use. A simple example which i find unreasonable: package main import ( "fmt" "path/filepath" ) func main() { filepath := filepath.Dir("./") //filepath.Dir('./") -> This is now a string. Can't use filepath package anymore fmt.Println(filepath) } Now I have to make up variable names because `filepath` will shadow the package. How it this sensible in any shape? Zip just does this better by having @ in front of builtins.
- w10-1 3y agoOverall, a release more for engineering than language. Even the new API's are mainly optimizations, and optimizations are netting ~10% (pretty good for an mature toolset). The WASI preview shows Google is committing engineering resources to WASM, which could grow the community a touch.
- jbrandhorst 3y agoFWIW the WASI support is 99% a community contribution, so unfortunately it's not much of an indicator of Google's commitment.
- throwawaygo 3y agoCan we get arenas yet?
- aktau 3y agoArenas are available as an experiment. See (e.g.) https://www.reddit.com/r/golang/comments/ztaxhu/docs_for_the_go_120_experimental_feature_arenas/ https://www.reddit.com/r/golang/comments/ztaxhu/docs_for_the....
- synergy20 3y agoreally hope Go has something like MERN for node.js or Django for Python, so I can use it for ready-to-go backend framework. There are gin and echo etc, just not as widely adopted as MERN or Django. in some of my use cases, I need make sure source code is fully protected, neither Node nor Django can do that well, Go will be perfect as it is compiled, however there is nothing like MERN or Django in Go(yet). Another option will be Java, but I do not know Java.
- djsavvy 3y agoThe new experimental fix for loop variable capture [0] is huge; this is the biggest footgun with the language in my experience. I hope the experimental fix makes it into the next version of Go by default. [0] https://github.com/golang/go/wiki/LoopvarExperiment https://github.com/golang/go/wiki/LoopvarExperiment
- epmatsw 3y agoWow, that’s a blast from the past. Those code examples look exactly like the var to let changes in ES2015…
- galkk 3y ago[flagged]
- preseinger 3y ago[flagged]
- galkk 3y ago[flagged]
- jsd1982 3y agoA good first step for better WASM support, however it's currently incompatible with tinygo's WASM target. For example, I'm working on a custom WASM host (non-browser) and have a tinygo WASM package with import bindings like this: //go:wasm-module rex //export wait_for_event func wait_for_event(timeout_usec uint32, o_event *uint32) bool Both these comment directives are tinygo-specific of course, and now Go has added its own third and different directive of course. When I add Go's desired `//go:wasmimport rex wait_for_event` directive, it complains about the types `*uint32` and `bool` being unsupported. Tinygo supports these types just fine and does what is expected (converting the types to uint32). On the surface, I understand why Go complains about it, but it's such a trivial conversion to have the compiler convert them to `uint32` values without requiring the developer to use unsafe pointer conversion and other tricks. Hopefully I can find a way to keep both tinyo and Go 1.21rc2 happy with the same codebase going forward and be able to switch between them to evaluate their different strengths and weaknesses.
- jbrandhorst 3y agoThe type conversion will improve in new releases. FYI recent TinyGo releases supports go:wasmimport too. The desire is definitely to allow users to use either or at least easily migrate. Thank you for trying it out!
- tastysandwich 3y agoReally glad to see some of these new packages (sort, map, etc) making use of generics. Should reduce the need for a lot of helper functions. Also really excited to see loop capture variables finally getting sorted out. It is a constant pain point with new devs, and I have no good answer when they ask "but WHY is it like this?" More information about loop capture here for those interested https://github.com/golang/go/discussions/56010 https://github.com/golang/go/discussions/56010
- yencabulator 3y ago> "but WHY is it like this?" Because, historically, it's been like that all over, it's not just Go. For example, Python has the same loop variable reuse. Probably comes from a time when compilers were a lot simpler, and all local variables were allocated stack space for the whole duration of the function call.
- suessflorian 3y agoNice - but hang on a second, I thought you cannot shadow language keywords in Go. So projects bumping to 1.21 in the future should be aware that you will run into compile time errors all of a sudden… doesn’t that actually break the compatibility promise? max := something() https://go.dev/doc/go1compat https://go.dev/doc/go1compat
- tedunangst 3y agoBuiltins aren't keywords.
- medellin 3y agoA function is not a keyword.
- oefrha 3y agoYou can shadow any builtin function. package main func main() { arr := make([]int, 0, 10) make := 1 arr = append(arr, make) len := func(arr []int) int { return -1 } println(len(arr)) // Output: -1 } https://go.dev/play/p/pG3Qi8G4dS5 https://go.dev/play/p/pG3Qi8G4dS5
- SergeAx 3y agoPlease add "RC1" to post title. Currently it's misleading than a stable release is here.
- idbfs 3y agoWorth noting that the release announcement was written by Eli Bendersky, of https://eli.thegreenplace.net/ https://eli.thegreenplace.net/ fame. It's a fantastic technical blog with literally decades of content.
- slantedview 3y agoThis is great, but why do I get the sense that Golang's development is so slow? Ex: Java: We added structured concurrency and virtual threads! Golang: We added a min function! Most of the standard lib still doesn't properly support generics, and at this pace, it will be another 5 years at least before it does.
- Mawr 3y agoBecause great care was taken for the 1.0 release to be a complete design. Most language changes since then have just been fixes. That's why Go 1.0 code is basically the same as Go 1.21 code.
- physicles 3y agoTouché. When I noticed how happy I was that they added a min function, Stockholm syndrome came to mind. Tbh I don’t see most of the standard lib benefitting from generics. For example, json.Unmarshal wouldn’t be dramatically better with generics — in practice, I rarely see runtime errors where I passed the wrong kind of thing to that function. I personally love the slow pace of go development. I love that I don’t need to refactor my code every year to take advantage of whatever new hotness they just added. The downside is that stuff that’s annoying now will be annoying forever (like those times when you want a more expressive type system), but I’m willing to live with that.
- physicles 3y agoThis is at least the biggest release since 1.18 with generics, possibly bigger. I’m excited because the changes demonstrate a transition from the traditional go philosophy of almost fanatical minimalism, to a more utilitarian approach. Loop variable capture is a foot-gun that in the last six years has cost me about 10-20 hours of my life. So happy to see that go. (Next on my list of foot-guns would be the default infinite network timeouts — in other words, your code works perfectly for 1-N months and then suddenly breaks in production. I always set timeouts now; there’s basically no downside) Interesting to see them changing course on some fundamental decisions made very early on. The slices *Func() functions use cmp() int instead of less() bool, which is a huge win in my book. Less was the Elegant yet bizarre choice — it often needs to be called twice, and isn’t as composable as cmp. The slog package is much closer to the ecosystem consensus for logging. It’s very close to Uber’s zap, which we’re using now. The original log package was so minimal as to be basically useless. I wonder why they’re adding this now. I’ve already written most of what’s in the slices and maps packages, but it’ll be nice to have blessed versions of those that have gone through much more API design rigor. I’ll be able to delete several hundred lines across our codebase. What’s next? An http server that doesn’t force you to write huge amounts of boilerplate? Syntactic sugar for if err != nil? A blessed version of testify/assert? Maybe not, but I’m happy about these new additions.
- meling 3y agoYou might be interested in this discussion https://github.com/golang/go/discussions/6022 https://github.com/golang/go/discussions/6022 about http serve mux.
- physicles 3y agoYou seem to have linked to an issue about error messages in text/template; did you intend to link to something else?
- meblum 3y agoProbably meant to link this. https://github.com/golang/go/discussions/60227 https://github.com/golang/go/discussions/60227 It’s an interesting discussion about making changes to the default router.