3 ms·

An issue with doing that kind of programming in C++ is ownership. Basically if you have goroutines/threads and channels, then GC is helpful. So the Go languag

by chubot 6y ago

An issue with doing that kind of programming in C++ is ownership. Basically if you have goroutines/threads and channels, then GC is helpful. So the Go language is really giving you 2 things together that C++ doesn't have that makes concurrent programming easier. But arguably they could have just given you threads and channels and GC, and not goroutines. That is, leaving out M:N threading. (I thought gccgo did that a long time ago or still does?) You can use threads and channels (which are just thread-safe queues) in C++, and follow a convention where you NULL out pointers after passing them across a channel. So basically you have single ownership. That is all a manual process, which is OK sometimes, but when you add in threads and the possibility of nondeterministic bugs, then maybe it's easier to see why that style of programming is not super popular. Though I have done it for small programs and it works well.

monocasa 6y ago
I'm not sure a GC really helps that much. Yes, there's a few memory unsafety bugs from ownership issues fixed, but you still need to forcibly forget about any references you had to the data being passed along the channel so you don't access it concurrently (which is the case where go's memory safety guarantees start breaking down too, concurrent access to mutable pointers).
- chubot 6y ago
  Yeah that's a fair point. Well then you don't need much to implement a thread-safe queue in C++, and that's a big step toward Go-style concurrency. If you want to be really minimal you could just use pipe() with each end in a different thread but the same process, even passing pointers over it. Probably the bigger deal is the consistent networking libraries, and the consistent mechanisms for timeouts and cancellation that Go offers. I think that's difficult in most C++ programs using threads. (I'd be interested to know what C++ programs do that well) On a project several years back, that's what pushed me toward async -- doing timeouts in a principled way. Though to be fair to Go, I would say that memory corruption bugs can be highly non-local (from symptom to code fix), and race conditions less so. Bugs that have both properties are really painful and I think Go mostly helps you avoid the former.
dilyevsky 6y ago
Go code can still have ownership issues around channel lifetime (panic on sendin to closed channel, etc)

by chubot 6y ago

monocasa 6y ago

I'm not sure a GC really helps that much. Yes, there's a few memory unsafety bugs from ownership issues fixed, but you still need to forcibly forget about any references you had to the data being passed along the channel so you don't access it concurrently (which is the case where go's memory safety guarantees start breaking down too, concurrent access to mutable pointers).

chubot 6y ago
Yeah that's a fair point. Well then you don't need much to implement a thread-safe queue in C++, and that's a big step toward Go-style concurrency. If you want to be really minimal you could just use pipe() with each end in a different thread but the same process, even passing pointers over it. Probably the bigger deal is the consistent networking libraries, and the consistent mechanisms for timeouts and cancellation that Go offers. I think that's difficult in most C++ programs using threads. (I'd be interested to know what C++ programs do that well) On a project several years back, that's what pushed me toward async -- doing timeouts in a principled way. Though to be fair to Go, I would say that memory corruption bugs can be highly non-local (from symptom to code fix), and race conditions less so. Bugs that have both properties are really painful and I think Go mostly helps you avoid the former.

dilyevsky 6y ago

Go code can still have ownership issues around channel lifetime (panic on sendin to closed channel, etc)