libddwaf VS go

Even in C there can be issues. the nokigiri ruby gem builds (or used to build) libxml and libxslt (which are pure C) and has to make effort remove a couple of GNUisms.

For C++ we were faced with some issues, so the process we ended up with is:

- build musl, install it in some location

- inject a few GCC libs and linux headers required for C runtime to have the above location be a proper sysroot for clang to use

- build LLVM libc++ and a few libs (e.g libunwind) as static libs against that sysroot using clang, and inject them into the sysroot

- build whatever C++ final product we want against the sysroot using clang, statically linking libc++ in

- for a dynamic lib, remove dynamic reference to some shared libs (can't recall if it's libc.so or ld.so). also, hide all symbols from libc++ and load with bind local so that when loaded the shared lib prefers its internal symbols (which would make it crash if it jumps to another libc++) and does not pollute the symbol namespace with its internal ones (which would make another lib crash if it jumps to the internal libc++)

- for an executable binary instead of a lib, dynamic reference would instead need to be altered so that it works for both

It all hinges on musl being a subset of glibc, which is not entirely true either (see the musl website for differences in behaviour, which may or may not matter depending on the piece of software)

https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e...

Go without concurrency is fully memory safe. However, once you start using goroutines there can be memory corruption and segfaults: https://github.com/golang/go/issues/37484. Note that these are not recoverable panics (such as "writing to a close channel"), but causes completely arbitrary behavior:

    runtime: pointer 0xc00379ac60 to unused region of span span.base()=0xc001794000 span.limit=0xc001795e00 span.state=1

As for first entry, this has been discussed many times without ever reaching any consensus, see - https://github.com/golang/go/issues/19412

To be fair to those projects, the type was introduced only three years ago:

https://github.com/golang/go/pull/49359/files

Before that, doing a string compare was basically the only way to detect that specific error. That was definitely an omission on the part of the original authors of the stdlib code; I don't it should be classified as "Hyrum's Law".

git clone https://github.com/golang/go OR git clone https://go.googlesource.com/go

I install go.

The difference between types.Implements and types.Satisfies is mainly a history reason, a tradeoff between keeping backward compatibility and theory perfection.

It is pity that Go didn't support the "comparable" interface from the beginning. If it has been supported since Go 1.0, then this tradeoff can be avoided.

There are more limitations in current Go custom generics, much of them could be removed when this proposal (https://github.com/golang/go/issues/70128) is done.

I recommend people to read Go Generics 101 (https://go101.org/generics/101.html, author here) for a thoroughly understanding the status quo of Go custom generics.

Tried to contribute to a Go project a few months ago and got bitten by https://github.com/golang/go/issues/67296 due to questionable doc quality. I was pretty disappointed to find that natural sort isn't builtin since Go was the Unicode language in my mind (Go runes, made by some Plan 9 thus UTF-8 creators).

Go has a lot of good points, but I immediately felt "dirty" when using it. Like that time when I tried to wrap a closure variable over itself ("my_closure = new closure calling my_closure") and needed to use a temporary variable because closure captures are always by reference: if you want to build abstractions, you got to think them better; as it stands, this is the worst of both worlds I know (C++ makes capture type explicit and customizable, Common Lisp was designed by wizards who knew what to do cf https://www.tfeb.org/fragments/2023/02/22/how-to-understand-...).