vaastav

"You may have heard a little click at the end of that. That is not a bug in the browser, it is physics being unforgiving."

lolwut

How is this different from/similar to Barrelfish?

Is it tho? It's only understandable to me if I also read the subtitles. Otherwise it just sounds as random noise.

Its in the last paragraph of the article...Very easy to miss given the code uses goroutines and channels.

The runtime switch was buried in the last paragraph of the article. All of the code was using goroutines and channels....

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.

Sure but that's what the implementation of the coro in this post uses under the hood. Not sure how this is any better wrt overheads.

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.

So basically a normal phone from the mid-00s

Always remember to clean up the .tex files before submitting to arxiv

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?

And observing their technology might switch it from working to non-working

What about false positives? How did you account for that?