Hacker News new | ask | show | jobs
by _008_jb_ 1766 days ago
When I started using Go I was more than sceptical. I had to mirgrate a CLI tool written in Kotlin (still my favorite language) because the memory consumption was to high.

After a while I actually understood why Go is such a successful language / ecosystem:

Go's priority is to make projects easier. It is doing so by all it's smaller and larger features respectivly skipped features. But one soon understands the big picture of the Go team. Go is designed by very experienced devs who knew what is important and what not.

In my Go projects, I don't have to worry about:

- Memory safety

- Tooling

- Performance

- Structure (once I understood the package desgin philosophie)

- Difficult syntax

- Concurrency

- Libraries, as we can do most with the standard lib

- Maturenes and stability

Instead I focus on the things that count:

- Solve the problem at hand

- Create correct, stable and maintable software

And as this was not enough, the Go team comes around the corner with an 5 % average performace gift.

Awesome.

1 comments

Not a GO dev, has the debugging experience improved?
Dunno, 20 years in the business and I still debug with print statements.

It's enough in 95% of cases and it works every time in every environment. In the time it takes me to get a debugger running and attached to a process, I've print-debugged it and fixed it already =)

> In the time it takes me to get a debugger running and attached to a process,

In any modern editor or IDE, getting a debugger running and attached to a process usually amounts to opening a folder, adding a breakpoint and pressing F5

Same here. I very rarely reach for a debugger. Especially with Go where you can recompile the binary very quickly.

I tend to reach for a debugger when doing post mortem debugging or when I work with C where that's usually the easiest way to get a stack trace when a program crashes.

That said, time travel / reverse debuggers can be quite useful indeed: see http://choly.ca/post/debugging-go-with-rr/

VsCode or IntelliJ with delv works beautifully for most common tasks. But don’t compare to JVM/Java. It does get trickier if you have many concurrent/goroutines but that is not unique to Go.