3 ms·
Why exactly do you say Go is backwards to C++ with regards to concurrency and race conditions? Really curious. I worked on a sizeable C++ codebase, and it had
by akavel 8y ago
Why exactly do you say Go is backwards to C++ with regards to concurrency and race conditions? Really curious.
I worked on a sizeable C++ codebase, and it had a home-grown, buggy thread-pooling & task cancellation (similar to Go's context.Context) engine. Go's builtin goroutines were a breeze afterwards. Also, I debugged a race condition in this codebase. Once, and it took me a few weeks full steam digging, thinking and mental construction. I didn't even know I have one at the beginning, just had this nagging feeling. (Valgrind would take the app to a crawl, and it was speed-critical.) In Go, I can just run tests with -race flag, and it finds me truckload races at a blink, pointing to the exact place where they happened, with a stack trace sprinkled on top. I really find it hard to understand how you find Go experience backwards here. But I'm also open and listening, and very curious whether I could maybe learn something enlightening!
- pdeuchler 8y agoYour experience mimics my experience almost exactly (although it sounds like you've worked on much larger and more complex C++ projects than I have), however I've been lucky enough to work with some extremely talented C++ programmers that have been able to accomplish astounding things with good, clean, C++ code. The problem, of course, is that 99.9% of us are not extremely talented C++ programmers.
- akavel 8y agoOk; so if you confirm my experience, I don't understand how you can at the same time claim Go is "backwards to C++" w.r.t. concurrency & race conditions. Did you mistype "superior" as "backwards"? Btw, we also had extremely talented C++ programmers. Some of them sent ISO C++ proposals from time to time, and I think were even accepted.