Grows unbounded. I wasn't recommending that one should set GOGC=off. Just making a remark that one could should they choose to do so.
EDIT: Sorry, I misunderstood part of your question. The memory grows unbounded unless you call runtime.GC() which triggers garbage collection. But this is a blocking call and essentially block your whole program.
Not sure if this really is required. Most cases in Go are served well by GoRoutines and for yield/resume semantics, 2 blocking channel are enough. This seems to add complexity for the sake of it and not sure it actually adds any new power to Go that already didn't exist.
You can export Jaeger traces via OTel as well. I am assuming the question here is why is there a different SDK rather than just re-using the standardized OTel APIs + libs for tracing and then providing a simple exporter for Traceo.
As a potential user, I am quite unsure as to why I would use this over something like TexStudio or even VSCode enabled with some LaTeX plugins. Could you tell me/us some pro/cons of this?
UBC has a 2 year BCS (Bachelor in CS) programme for people who already have a prior Bachelor's degree. It's not online but pretty much equivalent to a normal CS degree.
GoVector is a vector clock logging library written in Go. The vector clock algorithm (https://en.wikipedia.org/wiki/Vector_clock) is used to order events in distributed systems in the absence of a centralized clock. GoVector implements the vector clock algorithm and provides feature-rich logging and encoding infrastructure.
GoVector is one of the libraries provided as part of the Distributed Clocks project (https://distributedclocks.github.io/) which also provides vector clock logging libraries written in C++, C, and Java.