3 ms·
I was writing the same few lines for every project, so why not make it its own package? For my projects I can just include the dependency, as I wrote it and do
by jamesponddotco 1y ago
I was writing the same few lines for every project, so why not make it its own package?
For my projects I can just include the dependency, as I wrote it and don’t mind using it. Other people can copy it instead, since the proverb goes “a little copying is better than a little dependency”.
- skydhash 1y agoEditor macros/snippets?
- jamesponddotco 1y agoDidn’t think of that ¯\_(ツ)_/¯
- TheDong 1y agoUse rust or typescript or something where it's socially acceptable to make small packages. That'll also let you avoid writing the `if err != nil { return fmt.Errorf("context string something: %w", err) }` boilerplate again and again too (since you can just write '.context("context")?' each time). If you're using Go, you're not supposed to build abstractions, small packages, or any sorta clever or good code. And be really careful using generics. If you want to write abstractions, you're supposed to use a different language. Those are the rules.