Theme of the night: helping out other #golang projects wherever I can. That's 21 pull requests for today πŸŽ‰

I'll probably keep going for another hour or two. Got a #golang project waiting for a review? Don't hesitate and say hello 😊


@fribbledom while you're feeling generous, I'll ask you about my one experience writing in .
I write PHP and Javascript for a living. My first golang script felt more like Javascript (in that everything went into a single file) than it felt like PHP (where everything is nicely structured into class files). Is this normal for golang, or can I chop stuff up?
Repo here: - I'm sure there's lots of mistakes you could help me fix, but I'm mostly interested in structure.

Β· Β· Web Β· 2 Β· 0 Β· 1

@fribbledom I feel like the "Frontmatter" struct (at the bottom of main.go) should be separated into its own maintainable file/structure. Am I missing the point? In JS I often have stuff like

function Foo {
} = function {

And feels like that and it feels dirty, but that might just be my limited experience. I much prefer splitting everything out into class files and using PHP's autoloading to just use them when I need them. Do I need to think differently?


Yeah, in that case I'd just move FrontMatter and its data structures into a separate file, say "frontmatter.go". You don't need to change any imports, it'll still be accessible by everything else in the same package (read: directory).

@fribbledom OK, so just having it in the same directory is enough? Can I use subdirs?


A sub-dir is a separate package. You can import it, but you can't have circular dependencies, and you can only access public members of that package.

@fribbledom Cheers. That's all good to know. So the idea I guess would be to keep the packages small and self contained and each doing one thing and maybe even separate them out into full packages individually maintained?


Absolutely! ... and once you grasp how it all ties together with Go's interfaces, you'll really start appreciating the beauty of it.

@fribbledom That seems like some extra overhead upfront if you're making something complex. Would require some thought and care to group stuff into reusable and not reusable, but I can see how it could be a good way to do it.


Just a heads up: sent a pull request your way over on GitHub πŸ˜‰


You can use '-tabs=false' with gofmt, but let's just say it's not the recommend way πŸ˜‰


You usually divide your code by functionality / types into various files within a directory.

That entire directory forms a package, which then can get included as a whole by other packages ("import ...")

It's not uncommon that a single library or app consists of a bunch of packages, so you can divide it up further.

Sign in to participate in the conversation

Welcome to thundertoot! A Mastodon Instance for 'straya