Brilliant talk, quite a unique one in that category. I started to nurture TDD back in 2010, applied in a project in 2016, and afterwards somehow lost track. Started it again in 2022, I just love it now.
Go uses a concurrent garbage collector (GC), which means that it operates concurrently with the execution of Go programs and doesn't stop the world during its execution. This concurrent GC has been present in Go since version 1.5, released in 2015.
This is false. The Golang GC doesn’t stop the world during the entire mark and sweep, but it does briefly stop the world when the GC transitions between mark and sweep phases. It’s concurrent in the sense that application work can continue during the mark phase.
It's just the matter of how much of the program behaviour the compiler is able to acknowledge. At compile time, the value a variable holds "escapes" to (allocated on) the heap, if the compiler is confident and almost-omniscient of the program's semantics and control flow in the vicinity of variable declaration and usage (like Go, unlike Python). Else if compiler only has partial information, it will allocate an empty memory slot for the variable ahead-of-time and runtime behaviour will unveil that it needs to be "moved" to the heap.
I think the point he made at 14:00 could be somewhat misleading as he's emphasizing "moved to the heap right at compile time". The escaped variables still have to be dynamically allocated in heap, so it's complied to call runtime.newobject which calls mallocgc, therefore there's no cost benefit at runtime. Also, I believe this speaker isn't experienced in C programming, not that I'm faulting it, judging by the fact he initially didn't understand why the read function of io.Reader uses a byte slice as its argument instead of an int. That's exactly how read in C works where the caller sends a buf pointer (along with the buf size or less) and gets the number of bytes filled in as the return value, just like all the other functions do unless the argument is a small struct that fits in the registers or a primitive type. From what's known, Golang is a brainchild smart men from Bell Lab who hated C++, so it quite closely follows Unix/C programming style.
It can be concluded that: system api should not be responsible for resources management (most of times it refers to memory), but only for logical evaluation.
One quote about TDD that I love went something along the lines of "I've never heard of someone who really tried TDD and thought Nah, this is a waste of time. I'm going back to my old ways." Learning it is like learning how to walk. You'll probably never crawl anywhere again😅
Happens to gamedevs all the time, because our requirements are fuzzy emotional judgements about what "fun" means, which means we can only meaningfully test implementations without going farther up the abstraction levels than most mainstream test advocates would want us to do. This results in TDD advocates telling us we're doing it wrong, so we throw our hands up and go "TDD is impossible for gamedev" and stop doing it. It takes experience and effort to overcome these hurdles and figure out *what* to test in a video game and many gamedevs do not get that far or if they do, don't get enough value from it to continue.
to be honest, I think TDD just wasting time, but this talk makes me start to like TDD. The benefit of "documenting of my todo list after lunch" seems a great benefit.
That face of TDD evangelists when writing tests will be substituted by the much more efficient and more exhaustive automatic generation process through formal methods. Can't wait.
These people are not able to write a simple line of code to test. Do you think that they can write a formal process to test that everything is okay. My experience with formal language was pretty good, but most of people are not able to follow a formal method.
