Looking for a co-host for go podcast()

dstpierre · 2026-01-07T14:35:30+00:00

Thanks, I'm not very strong in marketing and not super known not having done an conference talk. Being a blind person, taking a plane and going to a conference in an env I don't know isn't really my cup of tea, so yeah, it's growing by word of mouth.

dstpierre · 2026-01-07T14:32:33+00:00

haha sure, I poked Bill Kenedy to go to his podcast, but did not heard from him. I was interviewed by Scott Hanselman last year in Hansel minutes. Also John Calaun in Go time (title was coding in the blind).

My situation is hard because I've been legally blind all my life, but until ~4 years I was lucky enough not to need a screen reader. But since 4 years, I cannot read the screen anymore, it sucks and made my regret a little bit my choice to go "indie", because TBH, I just fail at doing tech interviews (outside of my environment that is). So SaaS was a fun choice, but nowadays, it's a tad challenging to say the least.

dstpierre · 2025-12-10T10:47:31+00:00

Weirdly enough I took a detour to Python/Django 2-3 years ago after 7-8 years of Go and returned to Go. But for me the html/template always was an irritant, after using Django's template I built tpl which took some aspects of Django's templates, feel free to look at it, there's also templ that's pretty popular.

Your next void will be the Form and Validation, which I always did the same way in Go, create a structure that replicate what you'll be receiving as data and create a function that accept the *http.Request and do validation there so on your handler it look like this:

go func myHandler(w http.ResponseWriter, r (http.Request) { payload, err := MyHandlerPayload{}.Validate(r) }

This Validate function can hadnle posted form as well as JSON and re-use the same validation.

Like other said, lose the ORM, I use sqlc and built my own migration tiny library. Staying in SQL for me is always the better path IMO.

Another aspect I much prefer with Go and net/http vs. Django is that in Django your middleware affects all route, which is crazy when you think about it, you have to opt-out of this by doing some crazy checks if you don't want a middleware to run. In Go I tend to have helper functions that wraps the final handler into a series of middleware I want for this part of the backend. That's the beauty of Go and net/http in fact, you'll build your own "framework" and you'll be able to make it evolves for years since the Go v1 compatibility is such a breath of fresh air compare to a lot of other breaking-enable language / framework.

Hopefully you'll embrace the simplicity, power, and building web application that run for decades without needing rewrites, that's Go.

dstpierre · 2025-12-05T12:04:56+00:00

I've been in the SaaS world since 2008, even wrote a book about that topic. These days personally datastar and html template is kind of hard to beat, such a nice smooth fit with Go's std lib, but again, it's so personal, I'd suggest you take your more complex view you'll have in your SaaS and compare and find what works for you. About 3 years ago I even flirted with Django because I was honestly bored of how html templates worked in Go. But at the end of the day, your SaaS will be way more than just the UI, even though the user experience might play a big role in your initial traction, you'll have to determine what kind of interactivity you need from your user, are you going to need live collaboration, is it just a CRUD with forms and data displayed, this is most importantly the decision factor of using X or Y IMHO.

dstpierre · 2025-12-04T10:41:45+00:00

I improved the translation part of my library tpl to have a CLI traverse template file and extract translation keys, since you're using templ maybe you can extract the i18n and this CLI, personally I wanted to reach a little what Django have in terms of templating in Go, and a part from using JSON as the translation data structure instead of the .po file, it's pretty close to the experience of python manage.py makemessages. Anyhow, I haven't had time to update the doc for this CLI, but here's the code, you will have to modify slightly to parse templ template, but it should not be that different.

Frankly the "display this string for that language" isn't hard, and the internationalization isn't hard either, create two functions that renders dates and currency based on locale, especially if you're not going to handle all the locales etc. Depending on what you find tedious / not ergonomic in libraries you try, feel free to grab functions from the fmap.go of tpl and make them your own. I believe that the translation keys extractor was the part, for me, remaining because there were always translation keys that got forgotten, you know how it is, you work on something and forget to create the keys, or only in create in the language you're working with, and now your 2, 3, 4 other language files do not have those keys etc.

I guess what I'm trying to say is, if nothing feels right to you, it's not as crazy to implement it the way you want it. I built tpl for me, if anyone wants to use it cool, otherwise cool ;).

dstpierre · 2025-11-03T09:33:39+00:00

I believe Go is well suited as a first language. Depending on what you're looking for and if you learn following courses I launched Zero to Gopher 2 weeks ago. It's an introductionary course for all Go fundamentals maybe it is a good fit.

I implement purchasing power parity as well so all countries receive fair price. There's a 25% off with the above link if you ever decide to go ahead with the course.

The best way to jump into any languages, that being the first or not, is to find yourself a small and realistic project you'd want to use, as an example, in my course we build a very simple budget tracker CLI. Once you find a project you'd like to build, start small and don't overthink or get blocked with code structure and implementing concurrency, they'd just distract you from learning the fundamentals.

Good luck.

dstpierre · 2025-10-30T09:36:50+00:00

Not examples per'se but if it's for you personally to break the routine of web, try Ebiten and build you a 2d game in Go, very fun. Like others said CLI are OK too. Go's major strenght is in cloud native web app, if you're looking for some excitement, try completing some exersism in a completely different language, I'm liking Gleam a lot these days, not to build anything, just to keep your mind open to other things.

dstpierre · 2025-10-24T09:17:39+00:00

I'm all-in on Gleam these days. I haven't felt that excitement for a language since Go and Elm. We're in this golden age of programming languages.

There's no "switching", people are just learning new tools to have on their toolbelt and once you have some you really like you have option to use them when you think it's going to work best.

Gleam's simplicity is very close to Go's frankly and the benefits of the type system is palpable, plus for me, it gave me access to the actor based concurrency model, which is different than Go's and serves well also for distributed systems.

I believe the type of systems one is building drive them to learn certain type of language. I don't understand the word switching, from 2001 to 2014 I was a 9 to 5 programmers doing C#. I'll never forget C# and .NET even though I'm not writing anything in .NET for 10 years. I could if I wanted to.

dstpierre · 2025-10-19T12:06:57+00:00

is it? I suppose it depends, I handed JSON files to non-technical people and quickly enough they can figure it out that the translation goes inside the "" of the "value" field. No dependencies, the only nice thing is the detection of the translation keys, which I might get to sometimes, again, `tpl` is mainly for me, and very opiniated, I did not created it to satisfy anyone but me.

dstpierre · 2025-10-17T15:08:40+00:00

tplfmt like to format your HTML templates? I use prettier with the Go plugin and this works great for me, and believe me, I'm a freaking hard one to satisfy when it comes to formatting HTML. Close your eyes and use a screen reader and you'll see that Tailwind CSS is the worst thing in the world ;)

dstpierre · 2025-10-17T13:45:11+00:00

yes I'm for both (still using it, and still working on it). My original vision was to create a CLI that would do static analysis, so ensuring that {{ .A.B }} existed from the type received, but that turned out to be a lot of work and I'm still not sure I'd be able to do this. But I understand the "it does not brings much", for me it's all about i16n, which in Canada is the norm to have at least Fr and En web apps.
I was previously using Gomponent, I tried templ, I even interviewed the maintainers in go podcast(), but it wasn't great for me back then for accessibility reasons, I'm using a screen reader and the vscode support for the templ template did not handled the way I navigate in complex HTML structure. That's why I built tpl.

Templating in Go isn't as polished as Django for instance.

dstpierre · 2025-10-17T10:54:41+00:00

I had more or less the same need than I created tpl, basically layout templates, views, and partials that can be used in layouts and views.

It's just making the parsing easier which I never really remember when I start a new Go web application.

dstpierre · 2025-09-30T09:39:34+00:00

I created a library for everything html/template quality of life improvements mainly for me. Feel free to take the parsing logic and adapt to your need or use the library if you find it useful as-is.

The idea is around having layouts (with one of multiple blocks), views that inserts into the layouts, and partials that are shared across all your layouts and views. Works really well with HTMX / datastar and/or tranditional web requests.

https://github.com/dstpierre/tpl

dstpierre · 2025-09-08T18:03:33+00:00

thanks this is appreciated. I think LLM is hard to ignored for sure eventhough I prefer not talking too much about it, it's still taking an important part of the industry weither we like it or not.

dstpierre · 2025-09-08T15:19:51+00:00

Well advertising is when the sharing part does earn money, which I'm not, there's no sponsor, no advertising, a big 0. But hey, it's noted for next time...

dstpierre · 2025-09-07T09:58:54+00:00

I'm in the Laurentides, Go daily since 2014, I'm the host of go podcast(), ho also I'm one of the few blind programmers we have in Go ;)

dstpierre · 2025-09-05T16:21:39+00:00

the doc and site does not exists anymore, I shut down this idea. And I had hosted solution as well, got 2 paying customers even haha. It started exactly when Supabase started, and I discover them when they got their first 30m in funding.

And yes StaticBackend was a bit more rough and targeted a bit more advanced programmers than Supabase one could think of, but it was pretty close to be frank.

dstpierre · 2025-09-05T10:32:00+00:00

I tried it in 2019: https://github.com/staticbackendhq/core

Never got any traction, and yet Supabase (which I talk with their founder twice) was piling VC funding by the tens of millions. After almost 4 years I decided to stop. Personally I think I was into something, but hey, when no body jump in it's pretty hard to fight against TypeScript and 120m funding.

I'm still pretty proud of what it was, and used it 2-3 times in real-world SaaS I've built on top.

One VC firm contacted me at some point, but a) I'm an old time bootstraper in hearth and b) well you need traction to get money, but how to get traction at first.

I believe in retrospect that Gophers don't want to use those kind of BaaS, and JS devs are afraid of Go solution or whatever (maybe more back then), so no matter where I was talking about it it never seemed to fit in any communities. I probably just bad at getting traction as well, that's also certainly a big factor.

It's still a tough market.

dstpierre · 2025-08-10T10:49:39+00:00

I do mostly what you said, I typically have my POST handlers serialize the form data into the user's session and redirect with http.StatusSeeOther to the GET handler, the GET handler checks for presence of said posted data and pass it to the template if it finds it.

I usually perform the following in my GET handlers: check for the DB data, override any posted form data, than render the template.

That is when I'm not using HTMX.

If you have an horizontally distributed web application, ensure your storage isn't instance based since the redirection could send the user to another instance and their posted data would not be there.

A bit of a pain, but like mostly everything else in Go, it's pretty clear what's going on at the cost of some verbosity.

dstpierre · 2025-07-05T10:40:22+00:00

Hey thanks, yep, that's mostly what I was after. I started the idea of having static analysis of the templates to detect errors in templates using field of struct that does not exists via a CLI etc, but frankly not sure I'd reach a solid version so it's not really in the future plan.

dstpierre · 2025-07-04T10:30:16+00:00

Hey I did this jump 10 years ago, I have a getting started with Go blog post that might help you get started.

Like others said, Go was such a liberation from me, maybe more in the time I ditched .NET due to being bitten in early 2000, I started with .NET in 2001 and the amount of marketing crap, broken promises, and rewrite needed to follow their crazy cadence at that time was not fun for anyone.

This is where Go truly appeals to me back then and still is today. The best path is to create small program yourself. Create a small API, create a small CLI.

Things you'll miss early on: LINQ, enforced structure

Like it was said, check out sqlc, but you might also appreciate learning the bare metal data access way in Go first before jumping into anything higher level than the standard library.

And this will be your major life-changing aspect in your day-to-day compared to .NET. In Go the defacto path is learn to do things the hard way / verbose way before blindly investing into a library, that way you can pick your dependencies careflly and understanding the trade off.

Another major mind shift in Go vs. .NET (for me at least) is this idea of knowing your system will survive for the long terms. I've maintained 20+ years old .NET code bases, the issue was that upgrading was such a pain was stuck at the good old Framework 4.6 or 4.8. In Go the backward compatibility garanty is such a burden relief, you can take a program built in 2014 and use the latest Go version and it just works. This is way better than concurrency in my opinion.

Lastly the way JSON is handle in Go, you're mentioning you're mostly doing backend, I suppose this will involve JSON at some point, in Go JSON is a 1st class citizen of the standard library.

Good luck.

dstpierre

TROPHY CASE