Mistakes C/C++ Devs make writing Go | Hacker News Reader

Mistakes C/C++ Devs make writing Go

about.sourcegraph.com

202 pointsbeyang60 comments

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?

(Please, don't start a religious war on programming languages. We are all grown ups)

Somewhat. But I would rather characterize Go as a modernized middle ground between C and Java.

Both C++ and python are rather fully featured languages, while the design of Go seems to aim for more simplicity and quality of implementation which affords a great developer UX. In this sense, Go is a step back from the complexity of both C++ and python.

Go for me feels more like an updated and slightly higher-level C for application or webserver programming than any sort of alternative for C++.

I don't understand why anyone would characterize C and go. C and Java makes much more sense. It's basically Java with a clean an minimal API. That does not make it C.

In my eyes, Java and Go have very little in common beyond that they are both garbage collected languages. Go has been created by experienced C programmers and the heritage shows. Java is completely object-oriented, based on byte-code which gets JITed by a VM. All complex types have to be objects and are always handled by references - you cannot make an array of objects, you can only have an array of references.

Go is statically compiled into a statically linked executable. Go has structs as complex types. They are handled by value, unless you specifically use pointers. Structs can contain other structs as values, without requiring the indirection and the overhead of references. The same applies for arrays. You can have methods on any type, including structs, but you can also just have functions.

I’m a novice programmer but guessing Golang is concerned with keeping things as bytes; arguably _the_ distinguishing characteristic of C.

So it has a scanner like Java or C#, but you’d get laughed at iterating bytes not objects in Java.

I’d also note Golang’s API is built for enterprises so it’s familiar by design.

I’d enjoy to hear other perspectives.

I have not studied Go. I am learning Rust. I am not current with C++, but once was fluent. My take on Rust (as a Pythonista) is that while C++ is tedious and error-prone, Rust is merely tedious. Which IS progress. But... if you want to up-level, then I think the goal you seek depends on the state of the Rust crate ecosystem to get you out of the trenches.

>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?

Yes

I think your assessment is fairly accurate, although my recommendation would depend on having slightly more information. If you're looking for C++-like language but designed from scratch to be more modern (singular toolchain across platforms, better package management, compile-time guarantees about things like data races), then Rust would be a good choice for you. In my opinion, it's roughly as complex as C++ but fixes a number of the common pain points that resulted from C++ being designed to be mostly compatible with C. On the other hand, if you'd prefer something with less complexity with C++ (simpler memory model, smaller number of language features, eschewing of "magic"), then Go is probably a better choice.

Ultimately, I think the right choice comes down to identifying what exactly your dissatisfaction with C++ is.

Disclaimer: I'm a huge fan of Rust and not much of a fan of Go, but I do have experience writing each of them, and I tried to focus on the positives of each language as they might appeal to the parent commenter

Rust. Go and C++ have completely different aims, Rust is of the same ilk as C++

Yes, you’re right. The Go team was originally targeting use in C++-like applications, but was surprised to see Go catching on more among Python programmers than C++ programmers.

I would also suggest trying Python itself (why not go all the way?). Personally I write quick hacks in Python and real code in C++, and find Go to be an interesting middle ground. Python will do more to stretch your idea of programming. Maybe someday Go will get numpy and tensorflow.

I'm not sure if this is what you meant, but there are actually supported Tensorflow bindings for Go. They're quite usable (at least for me when I used them for inference), relatively idiomatic, and well documented. See https://godoc.org/github.com/tensorflow/tensorflow/tensorflo...

Also I’m not sure exactly what Numpy is but Go probably has an analog as it already has a suite of scientific computing libraries (check out gonum as a starting point).

Given their stance against generics, enumerations, operators, exceptions, ... it was only natural that we wouldn't spend that much time looking at Go.

Also C++ did not stand still and even the compile times are slowly becoming a thing of the past, with incremental compiler and linking, and modules support.

Maybe if Go 2.0 gets done right, it gets another look from us.

Afaik Go does not have operator overloading and, hence, will never be popular for numerics, just like java never was (or will be). Python has this flexibility and allows for great numerics libs for this reason.

You are correct, Go does not have operator overloading. While that can be cute, I wonder how important that would be for numerics, as only a subset of the computations break down to + - * /. Also, for decades Fortran was the go to language for numerics, and still is. It also did not offer operator overloading.

Fortran has had it since the 90s, but importantly,it has elementwise operations built right into the language. Python does not, but operator overloading allows for a good array library to be implemented (numpy).

Many computations contain other functions, but the four arithmetic operations are very familiar and look godawful as add(multiply(5, 2), 7) instead of 5*2+7. All of linear algebra is aritmetics, as a prime example

In my eyes, Go is rather a safe version of C. So you should be able to pick it up quickly.

As I'm learning Go, I'd like to know why this comment is downvoted. I'd personally never compare Go to C++ as they're completely different animals to me.

If no garbage collector isn't your requirement, you could try D.

Yeah that's about right. Go wont fit the bill if you can't trust the garbage collector (often true for scientific computing), or if you're not running your code on a full OS (like if you were writing an OS / embedded code).

Since Go is easier to learn, it probably couldn't hurt to learn it, then turn to Rust if it's not powerful enough for your use case.

Why wouldn't you be able to trust the garbage collector? Especially with scientific computing, by which you probably mean numerics, your program shouldn't produce much garbage in the first place.

Sure it will, scientific computing is rife with potentially very large intermediate matrices/tensors of data that need to be deallocated. In C++ I can explicitly free that memory, and in higher level frameworks, like tensorflow, dependency properties of the computational graph as used to figure out the earliest point in time a tensor can be deallocated.

I'd say rust is like C++ without the C legacy. Or maybe even a more modern C.

It isn't quite as complex as C++, but has more meat to it than C.

If you like C++, try rust, if you like C, try go.

> As a C++ dev who wants to write "slightly less low-level code"

If you really know C++, then you know it's easy to write safe C++ code with the latest standards so I'm not sure what's your problem here. Go and Rust brings very little to the table for an experienced C++ developer IMHO. Stick to the latest C++ features and you'll write "slightly less low-level code", although it's debatable how level C++ is to begin with.

As the initial concept of Go was made while the creators waited for their rather large C++ application to compile, I guess there are at least some things Go has to offer. One thing are the fast compile times. Not only is the Go compiler rather fast, as Go packages are compiled and stored as binaries, you usually do not have to rebuild them, only the code you are working on. Of course, there is the garbage collector, which can be of great help.

If you really know c++, then you know it is not easy to write safe code. It is easier than it used to be, for sure, but not yet easy.

See Go vs. Brand X for a take on what Go offers.

My understanding is that go is primarily targeted at spinning up webservices quickly, at the expense of most other purposes, so probably rust. (Or another contender for c++ replacement like d, nim, or zig.)

Go is great for all kinds of [web] server/systems and network programming -- if you're ok with the GC (i.e. it's a replacement for most things you'd do with Java and possibly some C/C++ stuff). Then Go is a great choice (BTW the Go standard library is fantastic and the eco system is amazing! you want to do USB, see gousb, d-bus? look at go.dbus etc).

If you are building an OS, game engine, database server or doing embedded programming where the gc is a problem, or if you need a memory/type safe program (at the expense of a bit of productivity), then use Rust.

So in other words 'use go for everything, unless gc is a problem, then use rust'? That seems like a bit close-minded, as if to say 'all the other languages and all they offer...is useless'.

re: "# channels < # goroutines"

  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
  }

> When one routine writes to the channel, the program exits and the other goroutine is lost, building up memory use as a results

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.

https://golang.org/ref/spec#Channel_types

https://golang.org/ref/spec#Send_statements

> How do we fix this? We simply increase the number of channels to 2

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.

> 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.

I was very disappointed with this explanation as well. The documentation is less than direct on this point, and suggests goroutines "execute independently", so my only conclusion is that the author doesn't understand channels very well, and was perhaps led to not understand them well.

    01  func doSomethingTwice() error {
    02      // Issue occurs below
    03      errc := make(chan error)
    04
    05      go func() {
    06          defer fmt.Println("done wth a")
    07          errc <- doSomething("a")
    08      }()
    09      go func() {
    10          defer fmt.Println("done with b")
    11          errc <- doSomething("b")
    12      }()
    13      err := <-errc
    14      return err
    15  }

If the programmer understands the control flow is something like: 03, 06, 07, 10, 13, 14 then they're not going to be confused, and they're certainly not going to "fix it" by increasing the buffer, they'll fix it by reading from the channel twice, and guarding against this by closing the channel. The real question is how to explain to the programmer what the semantics of channels is:

A goroutine blocks on read or write of an unbuffered channel (what we're seeing here).

The garbage collector is for simulating an infinite memory machine only. It is not for "cleaning up" after you.

The issue comes up when go programmers learn about runtime.GOMAXPROCS much too early, so they learn goroutines as threads, and they guess that the thread will be cleaned up when "garbage collected" because that's how Python works (or some other "garbage collected" language they might be familiar with). They're further confused because golang values have a "finalizer" so they might just assume that the thread finalizer (somehow) kills the thread, or the channel finalizer (somehow) closes the channel.

Perhaps if they noticed that writing to a closed channel causes a run-time panic, they might think these semantics are unlikely.

The point about buffering is to be able to write twice without blocking. Yes, you get 03, 06, 07, 10, 11, 13, 14 but how important was that really? If you did it just because you don't want to "leak memory", then you still don't know what's going on.

Increasing the channel size to 2 is the correct fix.

You don't want to read twice because then you would block waiting for both messages.

When the channel size is two the two inner writing goroutines can succeed on their write to the channel even if nothing reads from it.

The channel has three references, the outer receiver, and the two inner senders. The receiver finishes as soon as its able to receive the first message.

So what happens is one of the messages is sent and received, the other is sent and just sits in the channel. Then the channel has no more references and is garbage collected, so there's no memory leak.

Also goroutines are scheduled onto threads. So these orphaned goroutines that can't complete eat up memory (their call stack + the channel which can't be completed) as well as put pressure on the scheduler. (though the scheduler is efficient and can handle millions of goroutines) That's why it makes sense to refer to this as a memory leak.

> Increasing the channel size to 2 is the correct fix.

Or is the correct fix to use errgroup[1]?

  func doSomethingTwice() error {
  	var g errgroup.Group
  	g.Go(func() error {
  		defer fmt.Println("done wth a")
  		return doSomething("a")
  	})
  	g.Go(func() error {
  		defer fmt.Println("done with b")
  		return doSomething("b")
  	})
  	return g.Wait()
  }

[1] https://godoc.org/golang.org/x/sync/errgroup

> Increasing the channel size to 2 is the correct fix.

Sometimes. Sometimes it is not. For a trivial example, a unix-style wait would be done by reading twice. A job queue would be another.

It is not, for the reasons specified in the article, which falsely states that the buffer length and the number of goroutines has some relationship (# channels < # goroutines).

The channel size needs to match or exceed the number of producing goroutines. Anything less and the some of the goroutines will block attempting to send to a channel with no receiver.

The example in the article is a common issue that comes up in go programs, and the suggested fix is what is usually recommended.

The other way to solve it would be to read the first error and then up another goroutine to read the remaining error, but that seems more complicated to me.

> The channel [buffer] size needs to match or exceed the number of producing goroutines

This is not true, for the reasons I outlined.

> The example in the article is a common issue that comes up in go programs, and the suggested fix is what is usually recommended.

That may be, but it doesn't change the fact that go programmers that take this advice are creating a kind of cargo-cult around channels and goroutines that will hold them back.

> The other way to solve it would be to read the first error and then up another goroutine to read the remaining error, but that seems more complicated to me.

If all you ever do with channels and goroutines is simulate threads, you're missing out. Erlang programmers might more-easily appreciate this given that they have to go through an incredible contortion to get this feature that go provides for free.

Far better to just read twice from the channel, too. It's generally a smell to leave stuff on a channel. And that's a good example why -- you're losing track of a goroutine with no way to wait for completion or interrupt it.

i see what you mean. it'd be pretty strange to wait and see if you got an error from the first goroutine to complete. i'd imagine usually you'd want to wait for the first non-error result to arrive, say, or for all results. maybe there's a scenario where this kind of thing is useful, but it's probably not common

The two most common scenarios in my 3 years of experience are fan-in and first-error (executing stuff for their side effects only). It’s easy to mess up the latter, but golang.org/x/sync/errgroup is usually what you want.

I don't like this example and solution, because while it doesn't leaks (the channel goes out of scope, and the goroutine ends) it still is 1. error prone you now have to have a buffered channel, 2. sort of wasteful, setting the buffer to 1 instead of 2, also wouldn't leak and 3. not clear.

If you don't care about the results of the goroutine (here you explicitly don't care about the return value of at least one of the routines), a WaitGroup is much better.

    import "sync"
    func doSomethingTwice() error {
      // Issue occurs below
      var wg sync.WaitGroup()
      wg.Add(1)
      go func() {
          defer fmt.Println("done wth a")
          wg.Done()
      }()
      wg.Add(1)
      go func() {
          defer fmt.Println("done with b")
          wg.Done()
      }()
      wg.Wait()
      return nil
    }

The more advanced concept than this, which isn't in the stdlib is errgroup (https://godoc.org/golang.org/x/sync/errgroup#Group.Wait), where instead the accompayning `Wait()` function can also return an error.

In general I consider a code smell if you aren't reading every value off the channel.

A better solution would be a struct as return value of channel which contains both value and error as fields.

So just casually one would handle the case:

if ret.err != nil{

       //Handle error.


}

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.

A reflection of lots of "C++" code I see in the enterprise, what I call "C compiled with C++ compiler", because usually it doesn't even make use of C with Classes kind of features.

Also why the C++ community has started to focus on teaching C++ the right way.

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

Good tips, unfortunately, the explanations are not very clear and it's written in poor English, this gets very distracting.

Which part are you looking at? It all reads quite clearly to this native English speaker.

It reads fine to me

Regarding the defer statements in loops. It is better to just not ever do that.

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.

The issue outlined in the article is not defer in a loop, it's defer in an infinite loop.

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.

the article is pretty cool, especially when the author actually has a family name Check. :)

[1] https://github.com/fortytw2/leaktest

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).

Sounds more like design mistakes of Go.

1.There is no such language as C/C++.

2. There are no developers of C/C++.

3. C and C++ are distinct languages.

4. Anybody advertising for a C/C++ developer is insufficiently aware of software requirements to provide meaningful employment.

5. C++ programmers and C programmers have different responses to unfamiliar languages.

6. Some C programmers would like to be thought of as skilled "C/C++" programmers. There are none. Thus, they are not.

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++.

8. C++ programmers and C programmers make different kinds of mistakes.

9. Anyone titling an article about "C/C++ programmers" make is making a fundamental category error, and has self-identified as lacking insight.

10. Anyone titling an article about mistakes "C/C++ programmers make" refers to an empty set of programmers.

11. People new to Go make mistakes. (One such mistake might be using Go at all; that is not decided.)

12. There will be some intersection between mistakes made by any two groups of programmers.

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.

I guess you're being downvoted for tone, but I agree with you.

I program professionally in C++. Waltzing into a non-C++ C code base requires a strong mental shift. I work with embedded programmers new to our team who have a strong history of C programming, and for them, C++ is a very steep hill to climb to become proficient.

They are two languages with interoperability and semantic similarities that share a compiler infrastructure and a runtime and memory model.

But modern C++ programming differs in drastic ways from C such that I don't think you can call them a unified language and brush over it with 'C/C++ programmers'

C/C++ Users Journal

https://en.wikipedia.org/wiki/C/C%2B%2B_Users_Journal

Yes the languages are different, I would like to have C nuked instead of having to use it from time to time, but I agree with using C/C++ instead of writing C and C++ all the time.

It is a matter of English style only.

https://www.grammarly.com/blog/slash/

You are being pedantic, C/C++ is a shorthand that is quite common in the industry to refer to both languages, instead of typing C and C++ all the time.

Remember "The C/C++ User's Journal"? The magazine of reference for C and C++ developers?

Google, Apple, HP, IBM, Microsoft, ARM, clang, gcc and many others have C/C++ scattered all around in their documentation, do you want to mail their documentation departments?

Wrong. I'm a C/C++ developer.

I too develop software using this mythical language known as C.

I haven’t seen any unicorns yet but I do seem to have found a quantity of gold. But no rainbow.

Reply on news.ycombinator.com