If you'd like to join the dev of StaticBackend a Firebase alternative I'm building in Go you're welcome, there's a discord if you'd want to chat. https://github.com/staticbackendhq/core

If you'd like to checkout my course called Build SaaS apps in Go or want to support this show, that's the best way.

If you're on Twitter make sure to follow me: https://twitter.com/dominicstpierre

sqlx: https://github.com/jmoiron/sqlx
sqlboiler: https://github.com/volatiletech/sqlboiler

If you're looking to learn how to build web API with Go, checkout my course on building SaaS in Go.

I've been maintaining 20 years old systems for a long time now. I've been working with legacy applications in .NET. To me Go has some great advantages built-in by design that should help in 10-15 years from now when the applications that are created today will be on maintenance mode.

What are you thinking about Generics? What about 3rd party libraries that will pop from everywhere once Go 1.18 launched?

Personally, I'll appreciate what the std lib offers and will wait before writing generics code, making sure I really need it.

I'm currently working on a free and open-source self-hosted Firebase alternative - if such things sound interesting, please join the Discord group and contribution are very welcome (it's written in Go of course).

This is my course on Building SaaS apps in Go.

If you'd like to check the code, the PR is still active.

StaticBackend repo: https://github.com/staticbackendhq/core

My course on Building SaaS in go

Share episode topic idea with me on Twitter @dominicstpierre

We go over what are pointers and when to use or not use them. For instance, this is probably not a good use for pointers.

func main() {
  var i int = 10
  abc(&i)
}

func abc(i *int) {
  *i = 15
}

In my opinion any dereferencing is probably bad. Better way:

func main() {
  var i int = 10
  i = abc(i)
}

func abc(i int) int {
  return 15
}

I also try to give some basics info regarding the stack and heap and why pointers might not be seen as an optimization.

I have a course on building SaaS in Go.

Follow me on Twitter.

Don't stress too much about having the "proper" project structure to the point where you might over-engineer or be paralyzed by the thought of doing something wrong.

It's just hard, and even 5+ years of Go experience will not ensure you're creating the optimal packages and structure. It's an art mixed with preferences that become a little easier with time but remain challenging.

I wrote a getting started with Go guide that cover a little about project structure and how to get started with Go.

If you're in writing web applications and maybe even SaaS, I have a course on creating API-first SaaS with Go.

• Wrapping error: fmt.Errorf("error trying to do X: %w", err)
• Package errors: https://pkg.go.dev/errors

Example of not using the happy path at 1st indentation:

An   example of happy path in idiomatic Go:

if !somethingElse() {
  // handle something else false
}
// Happy path

My course on building SaaS apps in Go.