map-of-shame
⚠️ EXPERIMENTAL - DO NOT USE IN REAL SYSTEMS ⚠️
map-of-shame provides direct access to Go’s internal map implementation through unsafe pointers.
Some code needs to perform operations on maps whose type is not known at compile time. Normally, this is done using reflection, which enforces various safety guarantees and prevents consumers from violating expectations of the runtime. However, this requires causes a large performance overhead - mainly by forcing most operations to allocate memory. The only alternative to this is to break the encapsulation of the runtime and expose internal functions and reimplement private types.
This library provides a thin wrapper around these exposed operations, so that consumers can merely focus on writing unsafe code.
You shoul…
map-of-shame
⚠️ EXPERIMENTAL - DO NOT USE IN REAL SYSTEMS ⚠️
map-of-shame provides direct access to Go’s internal map implementation through unsafe pointers.
Some code needs to perform operations on maps whose type is not known at compile time. Normally, this is done using reflection, which enforces various safety guarantees and prevents consumers from violating expectations of the runtime. However, this requires causes a large performance overhead - mainly by forcing most operations to allocate memory. The only alternative to this is to break the encapsulation of the runtime and expose internal functions and reimplement private types.
This library provides a thin wrapper around these exposed operations, so that consumers can merely focus on writing unsafe code.
You should not use this library. It serves a niche purpose that you do not have. If you do have it, you should write the subset of it that you need yourself. If you think you’ll do a worse job than me, I can’t stop you.
Why is this shameful?
If you read code for the Go runtime, especially code related to maps, you will find comments referencing libraries as members of the “hall of shame”. These libraries exposed internal functions of the runtime for this purpose, so that they could write efficient code. The Go maintainers, not wanting these libraries to break, have had to quietly mark these methods as an unofficial backdoor API and maintain them in perpetuity. The whole situation is messy, and I find it easy to sympathize with people on both sides.
However, if many people repeatedly write the same code to break into the runtime and expose functionality because it’s the best way to write efficient code, it seems obvious to me that there should be an officially-supported way to do this. This library exists mainly as a rough-draft proposal for an API extension for the unsafe package.