I don't get the point of Golang - That's why I need help

I would also like to hear a perspective from other experts there, even though I understand the obvious benefit to using GO, that its a compiled language rather than interpreted at runtime, which makes it faster

I think you are asking the wrong question.

You said you need fresh air, then maybe the question is why do you need fresh air?

I always try new languages, listen to talks that go over my head. But i consider that a part of my developer life. Always wanting to learn how to do better, and failing a lot along the way.

I would suggest you focus on something you see in another language you want to understand. And once you understand it, try to do it in your language of choice. All languages are evolving and a thing that wasn't possible a year ago, can be possible now.

I use now Go for most of my projects. When I started, I was wondering why I shouldn't just use Python. After a while, something just clicked, and now I love it.

Nothing needs to be done in Go, so if you'd rather, you can something else.

What can you do with Go but not Node?

1. Build executables. Go is a compiled language, so it's very fast.
2. Statically typed (although I think Node supports TS now?).
3. VERY useful error messages. It basically only lets you run your code if it has no errors.
4. Simplicity. Although this can also be a downside, because you have to do a ton yourself.
5. The packaging system. go.mod is complex, but once you get the hang of it, it's an absolute pleasure.
6. Go saves your dependencies. Instead of having 40 node_modules directories, you have one ~/go directory that holds all of your dependencies, and you can use them across different projects.
7. Concurrency.

Side note: The creator of Node switched to Go. Then Rust. Then made Deno.

Hope it helps :)

I haven't used Node.js for much more than playing around. But I do now have some more serious Golang projects behind me and so I can give you my reasons for liking it. I'm a Lisper at heart so Go is not my dream language, but it sufficiently embodies the Unix philosophy of simplicity and readability that I can't not like it. Here are some points I find noteworthy:

• The type system is robust and expressive. It's not as watertight as Haskell's but gives one the feeling of well-defined data structures at the center of one's programming effort (see Alan Perlis' epigram no. 9: cs.yale.edu/homes/perlis-alan/quot...)
• It's a bit C-like in terms of syntactic simplicity, yet feels much more high-level (probably due to a rich set of libraries and standard means of their distribution).
• Channels! Go has typed channels and goroutines at its core, which is a clever programming paradigm for concurrency. It's more or less equivalent to Tony Hoare's CSP (cs.cmu.edu/~crary/819-f09/Hoare78.pdf)
• It's fast. Both execution and compilation. Combined with goroutines' lightweight implementation, you can easily have thousands (maybe millions) of goroutines in parallel.
• It feels like a no-nonsense systems programming language for the present. It's not trying to be too clever, rather deliver a pragmatic mixture of theory and practice. If I were to recommend a single resource to get a little excited, Id' suggest you check out this presentation by Rob Pike, one of Go's designer: go.dev/talks/2012/concurrency.slide#1

I find go a breeze to write and the added performance and goroutines is great. The code structure is much more easy to reason about. Pass by value or pointer, your choice. Especially when seeking performance, one or the other could better as per stack vs. heap allocation. Gives you control to some degree of how you manage the life cycle of your variables.

I also love how they've implemented interfaces: you can only define methods, everything else is up to you how you need to implement it, no need for further strictness. Testing comes out of the box and it works great, no need for 3rd party tools.

Tooling is great, fmt, and everything comes with a strict set of rules that makes it easier to avoid some pitfals. Also, go finally has go.mod, without which go was a bit messy for me module wise, but not the case anymore.

Also, true type safety! Not just a fancy "linter" that does not actually provide safety.

Any project I start now I go with go out of the box. Only might use echo as a basic framework for web servers, as I feel it saves you a bit of time.

I feel I write code faster, with less hassle, and have everything out of the box right there. Compiles fast too.

multi threaded server that runs requests in parallel with minimal resources without an interpreter. You can't have it on python due to GIL, you can't have it on node due to C++ single event loop

if all you do is CRUD, it doesn't matter for you but when it comes to deployment you will be dealing with process managers/spawners or web server gateway interfaces/workers to be able to glue-jail your interpreter. In some cases, you can get away with [ python main.py] or [node index.js] entrypoint docker container but it is not ideal for prod

In go/rust/zig, you just ship native binary in a scratch container and it just works because it is native static single bin kinda like C but with less cumbersome tooling

lastly, I think working without type hinting doesn't scale in team projects, it is easily the Achilles heel of duck typed languages

From the point of view of an application developer you can do pretty much the same things with Node as you can with Go.

So, the change is not worth if Node fit perfectly your application scope.

Even if you use Node successful, you might face some issues while hitting certain limits.

For example, if you write an application that is doing a lot of I/O processing, or you use a huge amount of RAM memory, just to highlight some cases that pop up in my mind.

With Go, you will have a much efficient language, that can help you work on multiple threads, using all the power of modern multi-core CPUs.
Your code in Node can't do that, you need a library in C++ or Rust, that handle the computation for you, or write your code to have different Workers, but this is not as efficient as the Go solution.

With Go you can build executable for many architecture, you just need to provide the target and it will cross-compile.

With Node, you may don't have the issue, if you don't have binary dependencies, but if you end with one of those, you have to set up a build chain that include this target architecture, I mean, you need a VM or a Container Image of this platform to build your application and deploy it.

The list can be longher, but you may get it, there are reason you may choose Go for your task, because with Node you can't be so effective.
In any case, I suggest you to learn Go a bit, even you don't end up using it with your production apps.
Why, because it will help you to refresh your mind with an outside the box approach.
It's good to pich a different language, just for learning purpose, time by time.

After having used TypeScript for like forever, writing Go feels like a huge step back in language ergonomics. Some of it because I'm more experienced in TS, some because TS really does have a lot more going for it with things like map().filter().reduce() etc. Let's not talk about error handling. That being said, it's good to be curious and Go does have it's place, which is why I still use it for certain tasks like where I want a single static cross-platform binary.

I think there is no "point" for Go. Several languages are used for building complex backend applications. For me node.js is like a bridge to the other side. If someone is used to frameworks, JS and TS its a small hopp to node.js without struggling with new languages like Go, Rust, Kotlin, ...
Go's concurrency and the channels to communicate and synchronize them are similar to the event driven non-blocking model from node.js. Go concurrency might be on heavy cpu-intensive operations slightly better...
So my answer to Your question is : Nothing

Go is not an exciting language in terms of syntactic sugars. Its very (deliberately) boring in that respect.

Go is like the ultimate grug-brain language. It appeals to me at least because the language makes it harder for someone to make a clever and incomprehensible solution to an algorithm. In Go one is strongly inclined (both in terms of the language and the community around it) to do it in a plain way.

The hopeful upshot is that I will actually be able to understand what the hell I and my coworkers were thinking 6 months down the line.

Listen to Rob himself on the subject: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=14m35s