• 3 Posts
  • 21 Comments
Joined 1 year ago
cake
Cake day: August 6th, 2023

help-circle







  • The go community is strongly opinionated in unique ways. For example, using libraries is generally frowned upon. You either use something included in the language itself (standard library) or copy/paste the code you wrote in another project. There’s also advocacy for shorter variable names which generally seems counter to the normal “write descriptive variable name” mantra.

    All in all, I hope the ideas / opinions came from a good place and then some people took them as black & white rules. But they also come off as one or two people’s pet peeves who got to build a language around them.





  • I too want my query results in an object, but thankfully libraries like sqlx for golang can do this without the extra overhead of an ORM. You give them a select query and they spit out hydrated objects.

    As far as multiple DBs go, you can accomplish the same thing as long as you write ANSI standard SQL queries.

    I’ve used ORMs heavily in the past and might still for a quick project or for the “command” side of a CQRS app. But I’ve seen too much bad performance once people move away from CRUD operations to reports via an ORM.





  • Jetbrains IDEs do a lot of indexing and caching so that operations that normally take a bit are faster. Full text search, find usages, identifying interface usage in duck types, etc.

    But the killer feature for me is the refactoring tools. Changing a function signature, extracting an interface, moving code to new files or packages, etc. I pair with folks who use VS Code and its a bit tedious watching them use find and replace for renaming things.

    I’ve never been able to benefit from an IDE in a way that make up for how much slower and more bloated they are.

    That does sound legit if you have resource limitations. Thankfully I’ve always worked for corporations that hand out MacBook Pros like candy. Normal day for me is having two Jetbrains IDEs open with Chrome, Slack, Zoom, and a dozen containers. Still runs smooth.



  • Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)

    I think part of this is caused by the fact that a lot of people are bad at code reviews so they focus on things that a linter could have told you. Being able to read code isn’t necessarily the same skill as being able to write it – as evidenced by the knee jerk reaction to throw out any coffee we didn’t write ourselves.

    I still create code reviews when I’m working on a project alone because it gives me a different perspective on the changes I’ve made.