go VS zig

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.

> And there's also the aliasing issue

Plans to address this were shared just last week: https://github.com/ziglang/zig/issues/5973#issuecomment-2380...

You crave the simplicity of C, but miss modern features and a nice build system? You got Zig

I raise you https://github.com/ziglang/zig/issues/20875

It is not entirely clear what any of this means, and in any case, it keeps changing all the time.

Arguably, one should call `flush()` on the file first. Resource allocation must always succeed; otherwise a lot of invariants break. This is why Zig's close method[0] ignores errors (with the exception of `EBADF`).

[0]: https://github.com/ziglang/zig/blob/fb0028a0d7b43a2a5dd05f07...

Zig is moving away from LLVM (https://github.com/ziglang/zig/issues/16270) and Rust has added Cranelift as a debug backend (https://lwn.net/Articles/964735/).

Not sure about Jai.

It won't require build.zig, you'll just have to run `zig translate-c` on the C file. Andrew's comment here[1] says that @cImport is basically @import + the compiler implicitly running `translate-c` for you. There was some discussion of removing the `translate-c` subcommand as well (which _would_ force you to use build.zig), but I don't think it's been decided to do that.

[1] https://github.com/ziglang/zig/issues/20630#issuecomment-225...

We would need more branch hints? https://github.com/ziglang/zig/issues/5177

Cold, warm, warmer, hot? Sometimes you would set all branches to be cold except one

It's the major area of focus right now. You can track the issues with this tag/link if you'd like:

https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...