go VS v

In 2022, ByteDance proposed an issue recommending that Golang adopt SwissTable for its map implementation. In 2023, Dolt published a blog post titled SwissMap: A Smaller, Faster Golang Hash Table, detailing their design of a swisstable, which garnered widespread attention. The Go core team is reevaluating the swisstable design and has added some related code in the runtime. With some free time during the holidays, let's delve deeper into the principles, compare it to the runtime map, and understand why it might become the standard for map implementation.

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

I didn't know about that. I agree it qualifies as a "weird issue".

Exactly. This is also highly problematic if you try to perform atomic operations against bare 64 bit integers on those systems, because the atomic instructions do require them to be 8 byte aligned. In C11 and later it’s not an issue, because _Atomic(int64_t)’s alignment may be stricter than int64_t.

This was also an issue in Go, because it tries to use the same alignment rules as C to make cgo work. There they also solved it by adding dedicated atomic types.

https://github.com/golang/go/discussions/47141

gRPC is not more than an abstraction over the conventional RPC, using protobuf as the serializer and making requests over http/2. There are some performance considerations when using http/2, and in some cases, using http/1 can be faster! I recommend you to read this benchmark and this open issue on golang/go about the http/2. However, when dealing with requests with a large/complex body, gRPC turns out to be a great solution due to having the protobuf as the serializer, which is much faster than serializing JSON as an example. Elton Minetto wrote a great blog post explaining better those alternatives and benchmarking them. Another great benefit of using protobuf is solving the contract inconsistency between the client and the server since they both use the same .proto files.

Really appreciate the article and the pointer to Go's SSA backend, which appears to implement common optimization passes like SCCP succinctly with good comments[0]. It's always nice to see harder concepts implemented with simplicity and readability in mind.

[0] https://github.com/golang/go/blob/master/src/cmd/compile/int...

Recently, I discovered that the Go standard library includes a built-in implementation of varint, found in encoding/binary/varint.go. This implementation is similar to the varint used in protobuf. Using the Golang standard library's varint source code, we will systematically learn and review the concept of varint. If you're familiar with protobuf, you probably already know that all integer types (except fixed types like fixed32 and fixed64) are encoded using varint.

We agreed to make the threadsafeness more explicit in the documentation of the 'unique' package: https://github.com/golang/go/issues/69637

Now Go is NOT CFS aware golang/go#33803 therefore GOMAXPROCS will default to using all 8 cores of the Task.

Their site is clearly showing the language is in beta. The V documentation also states that autofree is WIP, and to use the GC instead. This isn't a corporate created language, but looks to be a true volunteer open source effort from people around the world.

Their community, in comparison to others, even has their discussions open and open threads for criticism[1]. These

[1]https://github.com/vlang/v/discussions/7610

V also has this https://github.com/vlang/v/blob/master/doc/docs.md#embed_fil...

Goroutines was the selling point for me until they decided to introduce telemetry in their toolchain; that was what forced me to stop using Golang as a whole.

About GC, I would say: if you implement C++'s RAII mechanism to replace garbage collection, then I believe this project will have a bright future.

My final question is the following: how `pcz` compares to V language, from a syntax's perspective [1]?

[1] https://github.com/vlang/v