Eli Bendersky

Yes, I think you're generally right. I'm a big fan of this blog post: https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/

> The numbers reported here paint an interesting picture on the state of Linux multi-threaded performance in 2018. I would say that the limits still exist - running a million threads is probably not going to make sense; however, the limits have definitely shifted since the past, and a lot of folklore from the early 2000s doesn't apply today. On a beefy multi-core machine with lots of RAM we can easily run 10,000 threads in a single process today, in production. As I've mentioned above, it's highly recommended to watch Google's talk on fibers; through careful tuning of the kernel (and setting smaller default stacks) Google is able to run an order of magnitude more threads in parallel.

YAML is kind of like C++:

> You like C++ because you're only using 20% of it. And that's fine, everyone only uses 20% of C++, the problem is that everyone uses a different 20% :)

https://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back

The YAML footguns are too numerous to reproduce here, so here are some sources:

https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-in-yaml-over-multiple-lines/21699210#21699210

https://www.arp242.net/yaml-config.html

https://noyaml.com/

YAML isn't terrible if you only ever have to read what you wrote. Now consider that there are 63 different ways to write multi-line strings in YAML -- how many of those have you committed to memory? Yeah... now throw 10-100 developers into the mix, each with their own favorite alternative syntaxes -- good luck making sense of your YAML.

Caveat: I've barely used Go personally.

Just speculating on what GP specifically meant, but Go lacks the ability to pack structs, and probably lacks the equivalent of tricks like computed gotos [0] to increase bytecode interpreter speeds. In general, Go seems to (intentionally) lack a lot of low-level control of code generation, preferring a "there's one way to do things, and it either works, or it's a bug we'll fix" approach.

Which is probably for the best in "most" software, but interpreters typically use weird hacks to squeeze more performance out of the rock. Wren is a good example [1] of some of these optimizations, and has splendid comments/documentation.

[0] https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables

[1] https://github.com/wren-lang/wren/blob/main/src/vm/wren_vm.c

Because native multithreading is expensive when it comes to (a) memory consumption per thread of execution and (b) context switching. Also, if your program spends a lot of time just waiting on outside resources (most notably slow/blocking IO), coroutine concurrency is bother faster and more lightweight. If your program is CPU bound, then coroutines/async have little-to-no value over native multithreading.

That being said, yeah, most async workflows are obtuse and difficult to follow and they force all consumers of your interface to also use the async primitives if they want the benefits. Go seems to be one of the few languages that does async/coroutines right.

See: https://eli.thegreenplace.net/2018/go-hits-the-concurrency-nail-right-on-the-head/

If you are interested in debuggers, there was a post series by Sy Brand a few years back:

https://blog.tartanllama.xyz/writing-a-linux-debugger-setup/

Eli Bendersky also wrote about debuggers (I think his post is a great place to start):

https://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1

I was fascinated with debuggers a while back exactly because they were so mysterious to me. I then wrote a ptrace debugger myself [1]. It features pretty simple implementations of the most common stuff you would expect in a debugger. Though I made the grave mistake of formatting all the code in GNU style.

[1]: https://github.com/thass0/spray/tree/main/src

I like Eli Bendersky's blog a lot. He talks about a variety of topics and he satisfies my occasional Go interest since I don't work in it regularly: https://eli.thegreenplace.net/

Mr Money Mustache has been my favorite blog for probably about eight or nine years now. Some people have negative opinions about the financial independence space or they say he's too hardcore for them, but I love a lot of his posts and they've led me to make happier decisions in my life. He's always got a different way of looking at things and sometimes I acknowledge that those aren't for me, and sometimes I adopt them. https://www.mrmoneymustache.com