I cannot speak for others but I can tell you why I keep my `main()` small:
1. I prefer to put as much logic into reusable packages as I can, and
`main()` is not reusable outside the current app.
2. CLI packages like Viper are configured to be invoked with just one or a
few small commands in `main()`, and then there is an idiomatic standard for
putting the code for commands in a `/cmd` directory, so that's were most of
the code is typically found that is still part of the app but that is not
in reusable packages.
Is there a reason this approach is problematic for you? Just curious.
If you prefer to put more in `main()` then AFAIK there are no real issues
with it other than lacking package reusability, so if it works for you,
knock yourself out. #jmtcw
-Mike
On Wednesday, February 14, 2024 at 6:12:49 AM UTC-5 Jerry Londergaard wrote:
> I see quite a few modules out there where they seem to be putting in as
> little into the main package as possible. Literally they will sometimes be
> a few lines:
> ```
> import foobar
> func main() {
> os.Exit(foobar.Run())
> }
> ```
> Yet then go on to do all the things I would've thought are the domain of a
> main package, in the foobar package, like arg parsing, pulling in config
> items from env vars, setting up deps etc, and then running the actual thing.
>
> Why not just put that code into the actual main package? Sure, maybe not
> all into the main *function* itself, but in the main package at least.
>
> I understand that you don't want to be putting any real business logic
> into that main package, but I'm just talking about entry point type
> specific stuff. People might say they want to keep main 'light', but
> sometimes it feels like it's a competition to have the fewest lines as
> possible in the main package.
>
> kube-proxy[1] is an example of this. Maybe this starts to make more sense
> when the amount of code you would be putting into main become a lot,
> kube-proxy may qualify for this, but I see other cases where I don't
> understand the reasoning.
>
> Certainly not all are like that[2], but in some circles that I travel it
> seems to be a common way of thinking.
>
> Am I missing something ?
>
> 1.
> https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-proxy/proxy.go
> 2. https://github.com/ethereum/go-ethereum/blob/master/cmd/geth/main.go
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/aa139a11-2359-48db-a9f9-0902ff96da77n%40googlegroups.com.
