Is Golang the "Python for those who know C"?

Dev Zone Code
1

After reading @SgtAwesomesauce and @Dynamic_Gravity comments in

and looking at their repo, I decided to look further into golang and was really impressed with the language.

What jumped out at me was that it’s a pass-by-value language that allows the programmer to use pointers and references, as well as create executable binaries. At the same time, it looks like it has a ton of syntactic sugar to make writing golang very efficient.

Basically, it seems like “python for those who know how to program in C/C++.” In other words, there’s a lot of shorthand but follows the paradigms and concepts that C/C++ would use.

This was exciting for me, because I truly like the above listed concepts and I’ve had to “settle” using interpreted languages, where everything is a reference to something in heap memory. It seems like this language is different and has a lot of functionality that I wished all the other new languages had and might be a good fit for me to adopt.

However, it always seems things that seems super awesome also have cruft or painful parts. These are the parts I’m interested in.

Could anyone who uses golang and is familiar with C/C++ please share the pain points they’ve run into with the language?

cotton

1 Like
2

Not exactly. There’s a lot more to it.

I think a better analogy would be “Python for those who want the performance of C”

Something to understand:

There are no classes, only types.

Go is more akin to a procedural language, but it is not purely procedural either.

Go is very focused on ease of concurrency, as noted by the language feature goroutines.

If you approach Go thinking “I can program in an object-oriented method” you are going to be endlessly frustrated and find yourself giving up.

While go is technically a strongly typed language, it’s not entirely so. For example, you can make a method that takes an interface as an argument, that you can then pass any type to. There’s a lot of fun little language features.

Oh, another thing you should look into is channels and buffered channels.

In the next feature I’m writing for the API, I’ll very likely be using goroutines and buffered channels, so if you’re curious how they work, in practice, watch that space.

4 Likes
3

Sounds like it works like C more than C++ in that respect. Which is totally cool with me.

Thanks for the response.

1 Like
4

golang has a garbage collector and therefore won’t have nearly the same performance as C.

5

I call BS on performance wars on the account of garbage collector, you can totally use sync pools and they’re as unsafe and as performant as malloc. And you can still totally hand craft code in your tight loops to match the workloads your CPU is efficient in. And if you’re worried about memory allocation/deallocation overhead, you can always just ask the compiler to annotate your code with details of what gets inlined and what escape analysis has determined will have to go on heap and what can stay on stack.

Even with c/c++ once your binaries stop being toy code and cross 20-30MB of executable size, any idea of memory determinism outside of your core libraries is out of the window anyway.

One thing i was missing in Go was const. When your code starts manipulating/transforming deeply nested datastructures. It’s helpful for the people working with the code to be able to tell whether or not something is changing. It means you can debug code more easily.

In addition to cpu/heap profiling, if things are not scaling and you’re suspecting a bottleneck in your code, you can get an incredible amount of detail by tracing your code… which can show you what your threads/goroutines are blocking on. — regular pprof is usually good enough to tell you if you’re being stupid by allocating and deallocating memory all the time.

Modules are an awesome late addition. They fix a long standing issue of “how do you organize/map your libraries into repos” and keep working on both your code and libraries in parallel.

1 Like
6

This is the kind of thing all the Java kids say. But at the end of the day, go isn’t as fast as C (source), and saying that it is, is misleading.

7

15ish percent performance difference between an extremely high level language and an extremely low level language. Go is 9700ish percent faster compared to Python. A difference of approximately 15 percent is nothing in comparison.

This minor performance difference is the sort of thing a zealot would bring up.

Additonally, Go is used for things that C is not.

Would you write a HTTP API in C?

When writing a program for the real world, you have to take into consideration development efforts as well. It’s not just execution speed but the effort required to maintain the software.

6 Likes
8

7x performance is not “minor”, it’s the reason why people who care about performance still use C and not Go.

This, ladies and gentlemen, is why modern software is so astronomically slow these days.

1 Like
9

cherry picking binary trees

ok

1 Like
10

Often it seems that C is chosen for speed, but effort is still minimized at the expense of security. Not enough talent, patience and budget for everything to be written well in C. OpenBSD devs can’t write everything.

3 Likes
11

I’ve used Go for my master thesis and really enjoyed working with it. (I started working with it about 7y ago.) Their concurrency handling is spot-on and I do like the concept of pointers w/o pointer arithmetic to avoid weird things happening. :smiley:

However, what I’m currently not entirely sure is if Go is able to run on several distinct threads at once? I think I can remember that this was an issue the first few iterations, but I also think that this may have been fixed early on.

Regarding the C vs. Go performance discussion: Albeit from being more common, there is still a reason to use C if performance is of the utmost importance. Such occurrences are rare though, e.g. game engines. That being said, the C developer needs to have very high skills to write code that outperforms other languages.

3 Likes
12
13

Not an issue.

… a developer needs to have skills to write code that outperforms other developers code…

Have you tried pprof-ing the 7x slower benchmark? (e.g. why does it even use goroutines?)

14

One of the things Go prides itself in is the ease of concurrency and multithreading.

1 Like
15

No not entirely, in Java you don’t have to take of that many things to write code that performs well enough. In C and C++, matters are different.

Go prides itself in the concurrency mechanism it employs. There is a difference between concurrency and parallelism. That being said, @risk also mentioned that this is not an issue anymore and I suspected Google to fix this issue rather sooner than later.

16

image
image810×632 31.2 KB

didn’t know .net liked using this much memory

image
image734×432 20.1 KB

image
image735×199 10.7 KB

still less than java tho

17

Great, another good thread derailed by C aspys.

@cotton, want me to clean this up, or is any of it useful to you?

3 Likes
18

Do we like the fact that you can dereference a pointer using only the . operator in Go?

Isn’t a bit dangerous to automatically derefernce pointers like this? This can make it confusing if your dealing with a pointer to something. With C you have the -> operator, which if you’re reading the code makes it clear your dealing with a pointer to something.

19

The most significant thing about go is the package unsafe because it gives you introspection about the data. One of the biggest hurdle I faced was giving up control to another entity when I was used to have it myself. It gets tricky with the array and slices. GO is drastically different from c when it comes to memory management, dependency management, etc.

20

No, not at all. The compiler knows what it is dealing with anyway, it makes no difference to it. As a developer you don’t really care either, you just want to get at that member etc. It’s weird looking from a C standpoint, I guess. There’s a great perk there though: If you at some point switch from a pointer to struct, or vice versa - 0 changes of the operators will be required.

It makes total sense, Go is less explicit than C by design, so it’s pretty natural IMO. Heck, we at least get to choose pointers or values front and center, not like C# where you choose that by picking either a struct or a class to work with and everything else is invisible (value type vs reference type). It’s an interesting middle ground indeed.

On the general topic and question: Well, it’s probably how you look at it, there’s definitely a lot of C style in there, that I enjoy a lot, but I don’t even think Go competes with C in a many cases (there are some areas where it just can’t compete). That’s coming from someone whose daily job is to code in Go in Linux system level.

Go took over the more higher level stuff from C - like some daemons and system services - that’s where C projects often are just too cumbersome to develop at speed (in addition to any performant web services, Go is great at those). I would not compare it to Python for C developers, because C developers often use Python for scripting stuff, they wouldn’t use Go - it’s too cumbersome for that :slight_smile:

I personally always loved C, but there was that problem with it, that it’s not practical for most companies, so they rarely use it. I could find a few Go jobs in my area before I found anything with C at all (not even one). It’s simply a more practical language (batteries included with your purchase), not for quick an dirty stuff just because it’s faster to write. You can design pretty nice software with it, and other people can understand it more quickly. I’ve had no problems onboarding a junior dev and an intern to my code. If it was C, it would be another story. Managers like it, developers love it.

Because it does not compete I’m therefore looking at Zig rather closely, it looks fully capable of competing with C properly - in all areas - embedded, OS, etc low level stuff.

1 Like