Delve Debugger VS Error Prone

At a recent job, we had slightly different containers for local dev; our backend containers (for a Go app) had Air [1] installed for live reloading, plus Delve [2] running inside the container for VS Code's debugger to connect to. We also had a frontend container for local dev, which didn't get deployed as a container, just as static files. [1] https://github.com/cosmtrek/air. - Source: Hacker News / 5 months ago

So in my case I use https://github.com/leoluz/nvim-dap-go (which itself calls out to the CLI tool https://github.com/go-delve/delve). Source: about 1 year ago

I usually set up a scratch-pad module on my machines for quickly throwing some code together to play with. For debugging/checking attributes etc. there's delve, which is usually built in to various editor's respective Go plugin. Source: over 1 year ago

I use a debugger every day. Delve[0] Go's debugger made me love the process of debugging my code – either attaching the debugger to an existing running process or the feedback loop of debugging the test code until make it passes the test case. Back in the days when I didn't use one, it was a miserable developer experience. Thanks to Go and his great decision of having unit testing built into their standard now... - Source: Hacker News / over 1 year ago

The required setup to debug a Go app running inside a Docker container is non-trivial. In this post I will walk through the configuration to achieve this using VSCode and the Delve debugger. - Source: dev.to / over 1 year ago

A special kind of validation is enforcing that record fields are not null. (Un)fortunately, records do not have any special behavior regarding nullability. You can use tools like NullAway or Error Prone to prevent null in your code in general, or you can add checks to your records:. - Source: dev.to / over 1 year ago

I am all in favour to more third side libraries adding functionalities, like Lombok, Manifold and error prone. As well as smaller projects like this shameless plug and what appears in this list. Source: over 1 year ago

While at it you could also point them to static code analyzers such as error_prone, spotbugs and pmd (use all 3 at once - they complement each other in detecting different issues). Source: over 2 years ago

Linters can check for this sort of thing, for example Error Prone[0] has a lint[1] for this. Totally agree this is better to be in the language proper so we don't need this extra tooling. [0]: https://errorprone.info [1]: https://errorprone.info/bugpattern/ParameterName. - Source: Hacker News / over 2 years ago