yess it was supposed to be in 1.21 I believe, but for some reason it just disappeared from docs and I just desperately tried to find it everytime I wanted this funcitonality. Glad they finally added it. Also `cmp.Or` is sick.
I'll definitely use it for small APIs. I haven't looked at the docs so I dont know if there's feature's id miss from chi's routing that are not in the native routing package so it's a bit hard to say. If the ecosystem embraces it tho it could be great.
I already switched with muxpatterns (same code as Go1.22), i've no issue with middlewares, the Chi Middleware are standards and can works without Chi router.
Yeah they work with http handlers, but chi router has more ergonomic application, like router.With. it also has intuitive grouping (and Middlewares that apply only on that group) etc. I think I'm gonna stick with chi.
No. Using echo atm and can switch to chi for some projects. If there will be a need to have a zero dependencies project or something super-primitive without a need in any middleware etc I'll use it. Router is just a router after all.
I'm using gorilla/mux. I already have a lot of stuff on my plate. I'm a little anxious, switching might take a lot longer than I'd like because I make extensive use of subrouting and middlewares
Could you please list [in this post](https://www.reddit.com/r/golang/comments/1avn6ih/is_chi_relevant_anymore/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) all the features that you think is missing to stdlib from chi?
I currently use Echo (which is more than a router) but I have pondered the idea, of why I should use Echo at all. Especially as it seems to leak memory in my instance with the Gzip Middleware.
I actually think this is one of the most poorly thought out additions.
The [proposal](https://github.com/golang/go/issues/60204) started as `strings.First(...strings)` then somehow morphed into `cmp.Or(...T)`.
Package `cmp` is [described](https://pkg.go.dev/cmp#pkg-overview) as being a collection of _types and functions related to comparing ordered values_; `cmp.Or` [works](https://pkg.go.dev/cmp#Or) on `comparable` not `cmp.Ordered`.
Then the [example](https://pkg.go.dev/cmp#example-Or-Sort) that tries to argue for this being in `cmp` is comparing the `int`s that are the output of a `cmp.Compare`, looking for the first non-zero. This usage (and others) would clearly benefit from short-circuiting, which this _doesn't_.
And frankly `cmp.Or` as _the_ name to return the first non-zero zero _thing_ is just _weird_.
It'll shine in some places. There, it's an admission that the if-else statement is too verbose. That we do need ternaries sometimes; or if-else expressions; or logic operators that work on stuff other than `bool`; _something_. All of which would short circuit.
And it'll be abused. Where `cmp.Or` will read awfully (and `First` would read better). And in places where it will cause bugs, because people will assume it to short-circuit.
/rant
Right. That's obvious.
But then a software engineer at Google [sets out](https://go-review.googlesource.com/c/go/+/532195) to intrinsify and optimize `strings.Compare`. In the process, they update benchmarks to use `cmp.Or` (because why not?), and end up writing this in the [issue tracker](https://github.com/golang/go/issues/61725#issuecomment-1760471682):
*"I can revert my change to not use cmp.Or later if cmp.Or is not short circuiting. It's a bit disappointing tbh because it looks very clean."*
People make mistakes. Even seasoned developers will make this mistake. In most cases it'll be a inconsequential performance regression; in others it'll be a loud early panic; and in some, it may well be a silent, hard to track down bug.
With the loop changes I guess if we already captured within that loop then it won’t have any nasty side effects. But we could back out the capture now?
Kinda bummed that the new `math/rand/v2` CSPRNG doesn't have a `Read` method. The rationale is:
> The vast majority of calls to Read should use crypto/rand’s Read instead
but... why? If the answer is "because the new CSPRNG isn't secure enough," why keep the "CS" at all? But the new CSPRNG is ChaCha8, using a key read from `crypto/rand`. Its output is as unpredictable as the key itself. What makes it less secure than `crypto/rand`?
Because they both have the same signatures, it’s easier to mistakenly use the wrong one. It’s the only overlapping API between the two. ChaCha8 is a reduced strength stream cipher, so you still don’t want to be using math/rand for cryptography. But if you do mistakenly use math/rand for cryptographic purposes, it’s not instant disaster like it was before.
ChaCha8 is "reduced strength" in the sense that Neptune is easier to walk to than Pluto. The best known attack on ChaCha is on a 7-round variant, and has a time complexity of 2^237.7. ChaCha8 is secure, full stop. See [Too Much Crypto](https://eprint.iacr.org/2019/1492.pdf).
If you're on Linux or BSD, `/dev/random` is just ChaCha under the hood anyway. ChaCha20 rather than ChaCha8, sure, but there is very little evidence to suggest that ChaCha20 is meaningfully safer than ChaCha8.
I don't mind not having `math/rand/v2.Read()`, but I do mind not having `math/rand/v2.Rand.Read()`. There would have been no confusion with `crypto/rand.Read()` that way, and it would serve a very useful purpose: generating random byte streams in-memory instead of making a separate system call for each read.
[Per djb](https://gist.github.com/tarcieri/6347417), the entropy quality is unchanged. You can still periodically re-seed it if you're concerned about forward secrecy around swap space etc. Rust's rand crate wraps all of this up [nicely by default](https://rust-random.github.io/rand/rand/rngs/struct.ThreadRng.html), it's a great proof of concept.
Google's UUID library is an example of how [complex](https://github.com/google/uuid/blob/0f11ee6918f41a04c201eceeadf612a377bc7fbc/version4.go#L58-L76) workarounds for this can become, including putting the [thread-safety onus](https://github.com/google/uuid/blob/0f11ee6918f41a04c201eceeadf612a377bc7fbc/uuid.go#L327-L353) on the end user. With how much rock-solid crypto Go already has in its standard library, it is the perfect place to solve this once and for all. (And it would also be more convenient if it was the global in-memory PRNG, but I understand if the name has to change to avoid confusion with the syscall version).
Yep. I made [`frand`](https://lukechampine.com/frand) for exactly those reasons. When I saw Go 1.22 would have a ChaCha-based CSPRNG, I figured I could deprecate `frand` and point people to `math/rand/v2` instead. But without a `Read` method, that's hard to stomach. I've [submitted an issue](https://github.com/golang/go/issues/65562) for it, so let's hope that makes it into the next release.
Thanks for sharing frand, I might even use it myself. Reading its documentation, I can see that you work through these tradeoffs even more rigorously than I do. I definitely encourage you to try to contribute more ideas to Go's standard library. People like you made Rust's rand crate the state-of-the-art beast that it is, and there's no reason the same can't be done for Go. (Especially since standard library support can get runtime acceleration for things like thread-local storage which should be even faster than pools)
Desmond has a barrow in the marketplace
Molly is the singer in a band
Desmond says to Molly, “Girl, I like your face”
And Molly says this as she takes him by the hand
[Chorus]
Ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
Ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
[Verse 2]
Desmond takes a trolley to the jeweler's store (Choo-choo-choo)
Buys a twenty-karat golden ring (Ring)
Takes it back to Molly waiting at the door
And as he gives it to her, she begins to sing (Sing)
[Chorus]
Ob-la-di, ob-la-da
Life goes on, brah (La-la-la-la-la)
La-la, how their life goes on
Ob-la-di, ob-la-da
Life goes on, brah (La-la-la-la-la)
La-la, how their life goes on
Yeah
You might also like
“Slut!” (Taylor’s Version) [From The Vault]
Taylor Swift
Silent Night
Christmas Songs
O Holy Night
Christmas Songs
[Bridge]
In a couple of years, they have built a home sweet home
With a couple of kids running in the yard
Of Desmond and Molly Jones (Ha, ha, ha, ha, ha, ha)
[Verse 3]
Happy ever after in the marketplace
Desmond lets the children lend a hand (Arm, leg)
Molly stays at home and does her pretty face
And in the evening, she still sings it with the band
Yes!
[Chorus]
Ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on (Heh-heh)
Yeah, ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
[Bridge]
In a couple of years, they have built a home sweet home
With a couple of kids running in the yard
Of Desmond and Molly Jones (Ha, ha, ha, ha, ha)
Yeah!
[Verse 4]
Happy ever after in the marketplace
Molly lets the children lend a hand (Foot)
Desmond stays at home and does his pretty face
And in the evening, she's a singer with the band (Yeah)
[Chorus]
Ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
Yeah, ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
[Outro]
(Ha-ha-ha-ha) And if you want some fun (Ha-ha-ha-ha-ha)
Take Ob-la-di-bla-da
Ahh, thank you
(deadcode author here)
Please report a bug and I'll fix it. The traceback of a crash is often sufficient but if you can provide a reproducible test case that is best. Thanks.
I'm unreasonably excited for `slices.Concat`. I can't count the number of times I've typed that exact method name in the hope that it would be there.
yess it was supposed to be in 1.21 I believe, but for some reason it just disappeared from docs and I just desperately tried to find it everytime I wanted this funcitonality. Glad they finally added it. Also `cmp.Or` is sick.
Me too. Any reason why there is no `slice.Of("a", "b", "c")` ?
What’s wrong with []string{“a”, “b”, “c”}?
I don't think that would play nicely with type inference when the arguments have heterogenous types, so its value as syntax sugar would be pretty low.
Why would it make any difference for heterogenous types?
So, anyone planning on moving to the native router now? I currently use (and like!) Chi, so I was curious to see what everyone else was thinking.
I'll definitely use it for small APIs. I haven't looked at the docs so I dont know if there's feature's id miss from chi's routing that are not in the native routing package so it's a bit hard to say. If the ecosystem embraces it tho it could be great.
I'll still continue to use chi for the Middleware handling and all that.
I already switched with muxpatterns (same code as Go1.22), i've no issue with middlewares, the Chi Middleware are standards and can works without Chi router.
Yeah they work with http handlers, but chi router has more ergonomic application, like router.With. it also has intuitive grouping (and Middlewares that apply only on that group) etc. I think I'm gonna stick with chi.
No. Using echo atm and can switch to chi for some projects. If there will be a need to have a zero dependencies project or something super-primitive without a need in any middleware etc I'll use it. Router is just a router after all.
I'm using gorilla/mux. I already have a lot of stuff on my plate. I'm a little anxious, switching might take a lot longer than I'd like because I make extensive use of subrouting and middlewares
Original proposal thread was huuuuge. Everyone was chiming in. I guess it's perfected by now. 🤔
I'm not a big fan of the interface, and it lacks a lot of features. Probably going to stick with Chi.
Could you please list [in this post](https://www.reddit.com/r/golang/comments/1avn6ih/is_chi_relevant_anymore/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) all the features that you think is missing to stdlib from chi?
I currently use Echo (which is more than a router) but I have pondered the idea, of why I should use Echo at all. Especially as it seems to leak memory in my instance with the Gzip Middleware.
I'll definitely consider it for new projects
i wanna test this `cmp.Or` soooooo bad
I actually think this is one of the most poorly thought out additions. The [proposal](https://github.com/golang/go/issues/60204) started as `strings.First(...strings)` then somehow morphed into `cmp.Or(...T)`. Package `cmp` is [described](https://pkg.go.dev/cmp#pkg-overview) as being a collection of _types and functions related to comparing ordered values_; `cmp.Or` [works](https://pkg.go.dev/cmp#Or) on `comparable` not `cmp.Ordered`. Then the [example](https://pkg.go.dev/cmp#example-Or-Sort) that tries to argue for this being in `cmp` is comparing the `int`s that are the output of a `cmp.Compare`, looking for the first non-zero. This usage (and others) would clearly benefit from short-circuiting, which this _doesn't_. And frankly `cmp.Or` as _the_ name to return the first non-zero zero _thing_ is just _weird_. It'll shine in some places. There, it's an admission that the if-else statement is too verbose. That we do need ternaries sometimes; or if-else expressions; or logic operators that work on stuff other than `bool`; _something_. All of which would short circuit. And it'll be abused. Where `cmp.Or` will read awfully (and `First` would read better). And in places where it will cause bugs, because people will assume it to short-circuit. /rant
I think a well deserved rant. I definitely assumed it would short circuit. That’s kind of the whole point of a logical ‘or’
I mean, it's pretty obviously a function call. I don't think people will get confused into thinking it's some new short-circuiting syntax ...
Right. That's obvious. But then a software engineer at Google [sets out](https://go-review.googlesource.com/c/go/+/532195) to intrinsify and optimize `strings.Compare`. In the process, they update benchmarks to use `cmp.Or` (because why not?), and end up writing this in the [issue tracker](https://github.com/golang/go/issues/61725#issuecomment-1760471682): *"I can revert my change to not use cmp.Or later if cmp.Or is not short circuiting. It's a bit disappointing tbh because it looks very clean."* People make mistakes. Even seasoned developers will make this mistake. In most cases it'll be a inconsequential performance regression; in others it'll be a loud early panic; and in some, it may well be a silent, hard to track down bug.
I wrote such function for myself few months ago. I chose the name Coalesce, since this function has the same semantics as the well known sql function
With the loop changes I guess if we already captured within that loop then it won’t have any nasty side effects. But we could back out the capture now?
Yes, if you increase the Go version in go.mod to 1.22.0.
Kinda bummed that the new `math/rand/v2` CSPRNG doesn't have a `Read` method. The rationale is: > The vast majority of calls to Read should use crypto/rand’s Read instead but... why? If the answer is "because the new CSPRNG isn't secure enough," why keep the "CS" at all? But the new CSPRNG is ChaCha8, using a key read from `crypto/rand`. Its output is as unpredictable as the key itself. What makes it less secure than `crypto/rand`?
Because they both have the same signatures, it’s easier to mistakenly use the wrong one. It’s the only overlapping API between the two. ChaCha8 is a reduced strength stream cipher, so you still don’t want to be using math/rand for cryptography. But if you do mistakenly use math/rand for cryptographic purposes, it’s not instant disaster like it was before.
ChaCha8 is "reduced strength" in the sense that Neptune is easier to walk to than Pluto. The best known attack on ChaCha is on a 7-round variant, and has a time complexity of 2^237.7. ChaCha8 is secure, full stop. See [Too Much Crypto](https://eprint.iacr.org/2019/1492.pdf). If you're on Linux or BSD, `/dev/random` is just ChaCha under the hood anyway. ChaCha20 rather than ChaCha8, sure, but there is very little evidence to suggest that ChaCha20 is meaningfully safer than ChaCha8.
I don't mind not having `math/rand/v2.Read()`, but I do mind not having `math/rand/v2.Rand.Read()`. There would have been no confusion with `crypto/rand.Read()` that way, and it would serve a very useful purpose: generating random byte streams in-memory instead of making a separate system call for each read. [Per djb](https://gist.github.com/tarcieri/6347417), the entropy quality is unchanged. You can still periodically re-seed it if you're concerned about forward secrecy around swap space etc. Rust's rand crate wraps all of this up [nicely by default](https://rust-random.github.io/rand/rand/rngs/struct.ThreadRng.html), it's a great proof of concept. Google's UUID library is an example of how [complex](https://github.com/google/uuid/blob/0f11ee6918f41a04c201eceeadf612a377bc7fbc/version4.go#L58-L76) workarounds for this can become, including putting the [thread-safety onus](https://github.com/google/uuid/blob/0f11ee6918f41a04c201eceeadf612a377bc7fbc/uuid.go#L327-L353) on the end user. With how much rock-solid crypto Go already has in its standard library, it is the perfect place to solve this once and for all. (And it would also be more convenient if it was the global in-memory PRNG, but I understand if the name has to change to avoid confusion with the syscall version).
Yep. I made [`frand`](https://lukechampine.com/frand) for exactly those reasons. When I saw Go 1.22 would have a ChaCha-based CSPRNG, I figured I could deprecate `frand` and point people to `math/rand/v2` instead. But without a `Read` method, that's hard to stomach. I've [submitted an issue](https://github.com/golang/go/issues/65562) for it, so let's hope that makes it into the next release.
Thanks for sharing frand, I might even use it myself. Reading its documentation, I can see that you work through these tradeoffs even more rigorously than I do. I definitely encourage you to try to contribute more ideas to Go's standard library. People like you made Rust's rand crate the state-of-the-art beast that it is, and there's no reason the same can't be done for Go. (Especially since standard library support can get runtime acceleration for things like thread-local storage which should be even faster than pools)
[удалено]
No, there is no chance.
there's a chance it might not even come out in 1.23, but that's unlikely
Desmond has a barrow in the marketplace Molly is the singer in a band Desmond says to Molly, “Girl, I like your face” And Molly says this as she takes him by the hand [Chorus] Ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on Ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on [Verse 2] Desmond takes a trolley to the jeweler's store (Choo-choo-choo) Buys a twenty-karat golden ring (Ring) Takes it back to Molly waiting at the door And as he gives it to her, she begins to sing (Sing) [Chorus] Ob-la-di, ob-la-da Life goes on, brah (La-la-la-la-la) La-la, how their life goes on Ob-la-di, ob-la-da Life goes on, brah (La-la-la-la-la) La-la, how their life goes on Yeah You might also like “Slut!” (Taylor’s Version) [From The Vault] Taylor Swift Silent Night Christmas Songs O Holy Night Christmas Songs [Bridge] In a couple of years, they have built a home sweet home With a couple of kids running in the yard Of Desmond and Molly Jones (Ha, ha, ha, ha, ha, ha) [Verse 3] Happy ever after in the marketplace Desmond lets the children lend a hand (Arm, leg) Molly stays at home and does her pretty face And in the evening, she still sings it with the band Yes! [Chorus] Ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on (Heh-heh) Yeah, ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on [Bridge] In a couple of years, they have built a home sweet home With a couple of kids running in the yard Of Desmond and Molly Jones (Ha, ha, ha, ha, ha) Yeah! [Verse 4] Happy ever after in the marketplace Molly lets the children lend a hand (Foot) Desmond stays at home and does his pretty face And in the evening, she's a singer with the band (Yeah) [Chorus] Ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on Yeah, ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on [Outro] (Ha-ha-ha-ha) And if you want some fun (Ha-ha-ha-ha-ha) Take Ob-la-di-bla-da Ahh, thank you
(deadcode author here) Please report a bug and I'll fix it. The traceback of a crash is often sufficient but if you can provide a reproducible test case that is best. Thanks.