I worked with Perl for years, and I don’t recommend it for a beginner. There are just too many idiosyncrasies that belong specifically to the language that you’d be better off with Python for learning the basics.

I’m also not really sold on that book, which from the code samples looks really old. I’d recommend two books: Modern Perl and Perl Best Practices.

Edit: I’d also recommend working in Go but potentially the way i/o intersects with interfaces makes it a bit more challenging.

All sounds pretty sensible. I do think it might feel annoying waiting minutes to download a model for the sake of generating a line of alt text the first time, though. It would probably be quicker to write the alt text.

More or less. Either Excalidraw for your quick and dirty diagrams or I’ve used PlantUML + C4 Plug-in for your larger, more long lived diagrams with some success.

Diagrams. Loads and loads of diagrams. One for each use-case.

Then I’d have one diagram to draw out dependencies between each service at the broadest level. Although depending on how messy your architecture is it can be very difficult to read, in my experience.

I think if you read through this and take it at face value, there is a pretty clear picture of what happened: https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/

A lot of it has reinforced my understanding around distributed databases and transactions. In my day-to-day, I’ve not really had need to use this knowledge as pretty much all our data stores are hosted in cloud platforms and we’re operating on low datasets and traffic.

I’ve been reading Designing Data-Intensive Applications and it really is a great book, specifically for backend engineers.

As a bit of low-hanging fruit, you may be able to reduce the length of the diffs in an MR by marking generated files with -diff in a .gitattributes file. This is at least supported by GitLab (not sure about others): https://git-scm.com/docs/gitattributes#_marking_files_as_binary

To be honest, it doesn’t seem that bad. With clean architecture, you are going to end up with extra types and mappers. I would argue that what you have isn’t coupled, because a change in one place doesn’t have unexpected side effects elsewhere.

I haven’t used Goa or Gorm. Writing SQL by hand gets old quick so I get why you’d use Gorm - just less code to write in the end. I’ve used sqlc as it’s more a library than a framework, and it’s fine, but it can’t fulfill every use case. Goa looks too opinionated for me, on the face of it.

I’ve used wire. It takes some understanding but it’s definitely a lot to understand just to add a dependency. At work we’ve got our own template for doing dependency injection and although I was skeptical at first it strikes a really good balance between being understandable and abstracting away DI. If this is your pain point, I’d consider going back to basics and get rid of the framework.

If you decide to go with a framework like Laravel, Rails or Next.js and build everything around the framework, you will deliver quickly at first, but you won’t have type safety and it particular point it will stop scaling because these frameworks have no consideration for clean architecture. You won’t necessarily be better off.

The redesign is literally pointless and currently achieves nothing. I find that the user’s profile button having moved to the bottom-left so goddamned weird, as is the “Activity” button moving to the no-mans-land of middle of the sidebar.

If you wanted to do both front and backend development TypeScript + JS/Node would make the most sense, no? I say this as someone who works with and enjoys working with Go almost every day, but there’s only so much time to learn new stuff.

It’s a great base for general desktop use as well as server. Been using it on my PC for years now, and aside from a few 3rd party repositories it has everything I need. It just works and continues to work.