Hello gophers,
We plan to issue Go 1.21.1 and Go 1.20.8 during US business hours on Wednesday,
September 6.
These minor releases include PRIVATE security fixes to the standard library and
the toolchain, covering the following CVEs:
- CVE-2023-39318
- CVE-2023-39319
-
*What are we looking for?*
- *English *proficiency;
- 5+ years of experience (overall);
- Excellent programming skills in *Golang + Microservices*;
- Experience with Docker and Kubernetes;
- Familiar with AWS DynamoDB;
*What do we offer?*
⭐ We’re Great Place to Work Certified;
I observed that function invocation is the performance bottleneck in this
function:
https://github.com/dhconnelly/rtreego/blob/v1.1.0/rtree.go#L631
In assembly, this translates into
```
CALL github.com/dhconnelly/rtreego.(*Rtree).searchIntersect(SB)
```
Is there room for improvement with
During a particular build, the following build tags are satisfied:
- ...
- "unix", if GOOS is a Unix or Unix-like system.
- ...
It then says:
If a file's name, after stripping the extension and a possible _test
suffix, matches any of the following patterns:
*_GOOS *_GOARCH
Ah! Got it. Thanks.
Would it perhaps be good to mention this in the docs,
here: https://pkg.go.dev/cmd/go#hdr-Build_constraints ?
The bullet points refer to "unix" (which is true) and then a naïve reader,
like me, would think the later paragraphs about GOOS also apply.
Peter
On Thursday, 31
https://github.com/golang/go/issues/51572
On Thursday, 31 August 2023 at 08:57:15 UTC+1 Peter Galbavy wrote:
> I have used comment level build constraints for a while but I moved to
> using _linux.go and _windows.go over time as it makes it clearer for
> external viewing.
>
> A user reported
I have used comment level build constraints for a while but I moved to
using _linux.go and _windows.go over time as it makes it clearer for
external viewing.
A user reported they tried to build on MacOS and of course this didn't
work. I renamed the _linux.go files to _unix.go suffixes but then
