What to Learn? Cpp vs. Go

[lazy_afternoons]

I have less than 10 yrs of exp and primarily focused on web, JS(node, react) and kotlin.

Now I want to try my hand in building low level stuff like parsers, small KV stores and some network programming.

Go seems to be more approachable for my goals but I have the FOMO of not learning to manage memory. I want to be able to work on performance critical stuff later.

I used some Cpp in college and I went through some tutorials (learn go with tests) in GO. I like them both.

Which language do you think I should go deeper in.

[teeray]

If your goal is to build parsers, KV stores, and play with network programming, Go is going to be the most productive for those goals. It will get out of your way, and the “correct” was will be fairly straightforward. C++ is a language with decades of history, and a whole mess of “dialects” out there, and these will all distract you from building things.

Once you’ve cut your teeth with a few projects, I’d recommend Rust first, then C++. I built good habits fighting with the borrow checker that improved the C++ I wrote out of the gate.

[kstenerud]

Go is an OK language, but that's all it is: OK. It doesn't excel at anything or teach you any new paradigms, really. It was designed to be friendly for junior programmers so that they don't need much training to become productive.

C++ is a bit of a mess due to its long, personality warping, traumatic history. There are many awkward parts to it due to fundamental designs that have since been discovered to be bad (although we only know that through hindsight). So you have things bolted on like smart pointers, which give you reference counted memory management (and that really is the recommended way now, because the old way of purely manual memory management was a disaster).

Rust is an attempt to give the power of C++ without the mess. It's also a lot harder to grok from the start because they front-load you with a lot of required knowledge before you're able to do even the simplest of things.

If you have the ambition, I'd suggest diving into rust. The concepts you learn in there will cross over into many other languages, and you'll have a very strong foundation in ownership, transitional dependencies, and temporality in general (which you can get away with not knowing in most languages, but really should be aware of if you want to avoid some nasty bugs creeping in).

[GianFabien]

You might also want to consider Zig: https://ziglang.org/

It supports cross-compilation to a wide range of targets and supports C & C++ as well.

[Rochus]

> low level stuff like parsers, small KV stores and some network programming

That's not actually "low level"; you can pretty well do all of this using JS or TS. Go is very well suited for these kind of topics, and you can master it within a year. I don't see a necessity or clear advantage to learn C++ for these kinds of topics (mastering C++ takes 3 to 5 years).

> I have the FOMO of not learning to manage memory

There is no reason for this. It would be different if you would like to develop resource constrained embedded systems (those with less than a MB of RAM).

[lazy_afternoons]

what about systems like game engines and softwares like figma. People still use cpp there. Do you see go or go-like languages taking more in this space ?

[Rochus]

Well, if you intend to contribute to a game engine written in C++, it is of course of advantage if you can program in C++. But there are also game engines written in Go and other garbage collected languages (see e.g. https://www.dragonflydb.io/game-dev/engines/golang). There are also games written in Go. By the end of the day it's mostly a question of preference. As of Figma, as far as I understand it runs as Wasm; so essentially it can be written in any language which can compile to Wasm (which includes Go).

[gregjor]

Here's an idea: learn both. Maybe learn C first, then you will know 75% of C++ and 90% of Go. All Algol-family languages, or C-family if you prefer to start with a language still widely-used, have more in common than not.