I tend to do manual bootstrapping with local execution as well but when using Forgejo/Gitea and corresponding actions you could also init the repo, start building your pipeline and use act to run it (locally at first if course) and as soon as you have your infrastructure in place you could continue to use the same pipeline there?

Still not ideal/perfect but if you don’t want to depend on some SaaS then this at least already runs the automation as it will be later?

I can imagine how…exhausting these discussions were 😅

Apart from the more synthetic examples and the obvious things like iterating custom containers - I understand your argument that this is not a every day use case but there are certainly some use cases - there are things like:

• iterating a bufio.Scanner
• iterating SQL results
• streaming chunked HTTP results

That can benefit from the range-over-func approach.

Furthermore there’s another “class” of tasks that are quite a good fit: generators 😍 Think of an infinite slice of random numbers or Fibonacci numbers or prime numbers…all of this can be expressed as a function you can iterate and “just stop” as soon as you have enough.

Probably this gives you an idea what else the whole experiment is good for 😉

Edit: there’s for instance a Python library letting you generate the holidays of a state for the next 1000 years based on some algorithm without having the data pre-calculated/stored anywhere but you can iterate/filter/… whatever you want

I think this https://github.com/golang/go/discussions/56413 is the discussion.

Also an interesting read from Russ Cox: https://research.swtch.com/coro

I’d like to add that in my perception you’re a little bit overreacting. I can’t say that I got the same impression that you apparently got from the first comment. To me it sounds as if it’s primarily about missing some depth and could use some more advanced examples - especially when compared to the post Russ Cox wrote 😅 no offense!

Haven’t copied it yet to an editor so just a few things:

• naming convention in Go is camelCase not snake_case
• prefer to accept io.Reader over opening files in every function. Improves testability but also is best practice
• return errors whenever possible instead of just logging them or do something about if you can (like creating a file if it doesn’t exist yet if it makes sense) - don’t use panic if you don’t have to! Panics are only a last resort if there’s no way to handle the error gracefully, think: compile a regex as a global variable that you need and that’s static, the expression won’t change magically so there’s no way the program can continue without a valid expression
• move logic to some package (== sub-directory with a package name != main) and have at least one function with a PascalCase name to call from you main package. Functions starting with a capital letter are public whereas functions starting with a lowercase letter are private - not by convention but enforced by the compiler!

For a more thorough review I’ve to get to a computer but probably someone else has some more tips for you :)

Also check out the docs for testing https://pkg.go.dev/testing should hopefully get you started

There’s also an experiment from the core dev team now: https://go.dev/blog/gonew that comes with 2 very basic templates that might be worth a look