lcof

Same here too for personal/family vaults. Have been using the bitwarden cloud offering in professional context too.

vaultwarden, or bitwarden-rs as it used to be called, have been working flawlessly for years on my side, updates always work just as expected, and it supports a lot of organizational features too.

But I felt like it was better to trust bitwarden’s cloud for professional stuff, just for the reliability.

I feel mostly the same as the author. The Go ecosystem is so simple, logical and smooth that it is hard to reach out for something else. I do use other languages for one-off programs of course, be it bash, perl or javascript, depending on the task.

On bigger projects, the first pain point to appear for me is dependency management. It feels so antiquated in most other ecosystems, with loose compatibility contracts that add mental overhead. Go let’s you focus on the problem you are trying to solve, and you get so used to that luxury that using anything else quickly becomes painful.

Again, I might be wrong as I did not use this directly in a couple years, but saying “the limit is 50% share of 10 cores” is not equivalent to “the limit is 5 cores”. This is still “how much” versus “how many”, and cannot translate into each other without sacrificing flexibility

if you want to limit the number of Ps, then you use a cpuset, that sched_getaffinity will take into account. cgroups only allows you to limit cpu usage, but not lower the number of cpu cores the code can run on. This is “how many” versus “how much”, and GOMAXPROCS only relates to the “how many” part.

I may have misunderstood the rationale here, but I think the discussion about cgroup support is not about limiting the number of Ps

Who’s up for a micro-benchmark? Jk, will definitely consider it

No it’s an interesting comment. This is not really about load, but about control flow: if goroutine is just spinning wild without going through any function prologue, it won’t even be aware of the synchronous preemption request. Asynchronous preemption (signal-based) is mainly (I say “mainly” because I am not sure I can say “only”) for this kind of situation.

I don’t have the link ready, but twitch had this kind of issue with base64 decoding in some kind of servers. The GC would try to STW, but there would always be one or a few goroutines decoding base64 in a tight loop for the time STW was attempted, delaying it again and again.

Asynchronous preemption is a solution to this kind of issue. Load is not the issue here, as long as you go through the runtime often enough.

By “us”, I was referring to normal, everyday go devs (versus working on go itself).

I think starvation mode is a pragmatic way of solving the issue: overtaking happens when the fast path assumption is wrong - but absolute fairness is not a requirement. So it’s ok. The gains of the fast path is enough to justify having that starvation mode.

I would argue that if some piece of code ends up wasting lots of time on futex calls, it suggests that this code was not designed with the right use case in mind.

Interesting comment about wine’s allocator, did not know about this

This sounds like a great idea on the paper, I think it can bring value. But once you enable this in an organization, if it works well, it could be hard to remove it without resentment

I wonder if the overhead of using context values is noticeable in the context of logging. I guess you want to reconstruct the logger only when needed, kind of lazily

The relationship with data is that it protects (controls) access to it