3 ms·

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 wa

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.

systemvoltage 5y ago
Not a GO dev, has the debugging experience improved?
- theshrike79 5y ago
  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 =)
  - ithkuil 5y ago
    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/ http://choly.ca/post/debugging-go-with-rr/
  - maccard 5y ago
    > 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
- harikb 5y ago
  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.

systemvoltage 5y ago

Not a GO dev, has the debugging experience improved?

theshrike79 5y ago
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 =)
- ithkuil 5y ago
  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/ http://choly.ca/post/debugging-go-with-rr/
- maccard 5y ago
  > 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
harikb 5y ago
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.