hashmap VS go

Glad to see this make it into the core.

I've been using this library for ages now...

https://github.com/cornelk/hashmap

Always entertains me to see developers write all the lock/unlock code when they could just use that.

Assuming it is issue 54 and its age, I am now unsure about the usability.

Pre-allocating would not fix https://github.com/cornelk/hashmap/issues/47 as the bug is in the linked list. This is not grow related but an issue with concurrent Add/Delete on the list.

Would be interesting to compare with https://github.com/cornelk/hashmap

Go

Have you looked for any evidence? There is plenty.

Sum types have been discussed since before the initial open source release of the language, at least according to some of the issue threads such as https://github.com/golang/go/issues/19412

If they're laughably simple, then please contribute a proposal for how to add them to the language. You'll find no one is really fighting against the concept of sum types.

I agree that there are no objective measure. I guess it's just different expectations.

I would not say it's obvious what the machine is doing in the Go example though. For example it wasn't clear to me that append() mostly doesn't copy the full vector, but does a copy of the slice pointer. I had to look it up from a blog post, because the source for append() is gnarly

https://github.com/golang/go/blob/go1.16.7/src/cmd/compile/i...

jaredpar on the C# team offered the very first comment on the Github issue for this proposal: https://github.com/golang/go/discussions/56010

I think it played a large part in helping get past the default-deny that any language change proposal should have. The other big one for me was the scan done over the open source code base and the balance of bugs fixed versus created.

Most commonly no impact. It can require an additional heap allocation per iteration if taking the address or capturing in a closure, but even in those cases escape analysis may be able to determine that the value can remain on the stack because it will not remain referenced longer than the current loop iteration. If that happens then this change has no impact.

I'm not sure how thorough Go's escape analysis is, but nearly all programs that capture the loop variable in a closure and are not buggy right now could be shown to have that closure not escape by a sufficient thorough escape analysis. On the other hand for existing buggy programs, then perf hit is the same as assigning a variable and capturing that (the normal fix for the bug).

Google saw no statistically significant change in their benchmarks or internal applications.

https://github.com/golang/go/wiki/LoopvarExperiment#will-the...

This will crash if `foo()` returns nil, because it's checking if `x == interface{}(nil)`, which is false. What you wanted to check was whether `x == *bar{nil}` or one of the other nil types that implements the interface; which must be done with `reflect.ValueOf(x).IsNil()`.

https://github.com/golang/go/issues/30865

I’m referring to this guideline:

> Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex.

https://github.com/golang/go/wiki/CodeReviewComments#variabl...

> Plugins are currently supported only on Linux, FreeBSD, and macOS, making them unsuitable for applications intended to be portable.

uh-huh

but, in all seriousness: I wonder why that is? I struggle to think of a technical reason that go would be unable to load and invoke a .dll even if one had to name it .so https://github.com/golang/go/blob/go1.21.1/src/plugin/plugin...

You just add the -static argument, if you want a fully static executable that can run on any linux distro: ‘g++ -o main main.cpp -static’

You can even go above and beyond with cosmopolitan libc v2, which makes c/c++ build-once run-anywhere: https://github.com/jart/cosmopolitan/releases/tag/2.0

There seems to be some work getting cosmopolitan libc support in Go, but it is not ready like it is for c/c++: https://github.com/golang/go/issues/51900