Here's a newbie's bit off topic question: As a C++ dev who wants to write "slightly less low-level code", should I go for RUST or GO? My intuition says Rust is more like a safer version of C++ while Go is more half way to Python/Julia. Do you agree with this sloppy assessment?<p>(Please, don't start a religious war on programming languages. We are all grown ups)
re: "# channels < # goroutines"<p><pre><code> func doSomethingTwice() error {
// Issue occurs below
errc := make(chan error)
go func() {
defer fmt.Println("done wth a")
errc <- doSomething("a")
}()
go func() {
defer fmt.Println("done with b")
errc <- doSomething("b")
}()
err := <-errc
return err
}
</code></pre>
> When one routine writes to the channel, the program exits and the other goroutine is lost, building up memory use as a results<p>I'm not very familiar with go, but my guess would be that since the two goroutines send to an unbuffered channel that is read at most once, the "slower" of the two goroutines will sit there blocking attempting to send to a channel that will never be read. So this would "leak" a goroutine that would consume resources while the process was still running, but it doesn't have anything to do with the program exiting.<p><a href="https://golang.org/ref/spec#Channel_types" rel="nofollow">https://golang.org/ref/spec#Channel_types</a><p><a href="https://golang.org/ref/spec#Send_statements" rel="nofollow">https://golang.org/ref/spec#Send_statements</a><p>> How do we fix this? We simply increase the number of channels to 2<p>The fix is okay but the language is a bit hazy, there's still only one channel, but now it's a buffered channel with capacity to hold up to 2 messages, so the two goroutines don't need to block waiting for a receiver to be ready to synchronously receive the message they are sending.
This has no c++ content. only C.
the mistakes highlighted are just not representative of a team of C devs. the resource leak is specially a bad example because there better examples where go safety is a real benefit.
Can’t leave comment in blog, but the first two listings are broken - it looks like there is no empty line after ``` in listing line, and before the same in listing two. So enumeration isn’t rendered correctly
Regarding the defer statements in loops. It is better to just not ever do that.<p>Instead, move the defer outside of any loops, and have the defer check the state of the variable to decide action. For example, in the case of an open file, the loop should close the file and nil out the reference. In the defer, if the reference is not nil, it closes the file.
for goroutine leaks, I have been using the leaktest package made by fortytw2 [1] in all my tests, pretty useful for my day-to-day dev work.<p>the article is pretty cool, especially when the author actually has a family name Check. :)<p>[1] <a href="https://github.com/fortytw2/leaktest" rel="nofollow">https://github.com/fortytw2/leaktest</a>
I wouldn't want to use a language that I cannot predict how memory allocation would work. I'd like to have every inch of performance in my disposal for the tasks I am interested in (video games, simulations, data mining).
1.There is no such language as C/C++.<p>2. There are no developers of C/C++.<p>3. C and C++ are distinct languages.<p>4. Anybody advertising for a C/C++ developer is insufficiently aware of software requirements to provide meaningful employment.<p>5. C++ programmers and C programmers have different responses to unfamiliar languages.<p>6. Some C programmers would like to be thought of as skilled "C/C++" programmers. There are none. Thus, they are not.<p>7. Many C++ programmers are capable of altering C code. They, also, are not "C/C++" programmers. When altering C code, they are programming in C, not C++.<p>8. C++ programmers and C programmers make different kinds of mistakes.<p>9. Anyone titling an article about "C/C++ programmers" make is making a fundamental category error, and has self-identified as lacking insight.<p>10. Anyone titling an article about mistakes "C/C++ programmers make" refers to an empty set of programmers.<p>11. People new to Go make mistakes. (One such mistake might be using Go at all; that is not decided.)<p>12. There will be some intersection between mistakes made by any two groups of programmers.<p>13. The intersection between mistakes made by Java programmers and Javascript programmers does not define a "Java/Javascript" language, nor a set of "Java/Javascript programmers", despite any similarity of names or surface syntax between the two.