(They closed the issue on the golang link.)
I'm not a golang user. One language too many for me. It sounds like a library issue. My suggestion would be to use the openness of open source. Generate a patchset that extends the interface properly. Don't try to "improve" what you don't like - communities like stability and backward compatibility. Explain the added semantics in documentation. Then, maintain your fork. I don't know how the golang community works with versioning of libraries, but Python, Rust, Haskell, and NodeJS all have ways to let projects use variants of libraries. Then, submit that patchset upstream to the golang community. Advocate for upstreaming it, and develop a community that uses the patched library. Eventually, you may be able to stop maintaining your variant toolset. Or you will develop an alternat library user base that disagrees with upstream's decisions. (Analogy, Android's Linux Kernel vs. Linus Torvalds's. Google Android rejects to some extent Linus's crew's unwillingness to accept what Android needs as improvements.) This is "modern open source community" practice for getting things done. Pragmatic innovations in shared codebases sometimes have to wait for the original egos to die off. _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
