4 ms·

Go is one of those languages where "good layout" feels more elusive to me than in other languages. I think you accidentally highlight one of the reasons why.

Go is one of those languages where "good layout" feels more elusive to me than in other languages. I think you accidentally highlight one of the reasons why. core.WeatherServices Which makes sense because you're using a lot of things from core but since I have to carry the package name around everywhere I use it, outside of that module, it becomes a bit of a strain. weather.Service Would clearly be a better name in the "go style," but the single level package structure always makes me feel like my types are dangling out in space outside of any decent hierarchy. I love Go as a language but I dislike how often it makes me think of exceptionally tiny things like this. Please don't read this as a criticism of your project just a general criticism of how thin the Go "namespace" ideology actually is.

deleted 1y ago
[deleted]
9rx 1y ago
> Would clearly be a better name It appears that it wanted to be services.WeatherService, which if reduced to service.Weather isn't looking so bad, but core ended up being introduced because the unnecessary interface already overloaded the namespace. The code doesn't accidentally highlight - it is crying out. > always makes me feel like my types are dangling out in space That's the idea, though, isn't it? Each package is its own distinct thing, intended to be useful and usable across many projects. There shouldn't be any kind of deep interconnectedness in most cases – and where there needs to be, you will typically place the related packages in a subfolder to communicate that relationship. I can't think offhand of any package manager that maintains anything other than a flat list of dependencies, and that's essentially what you are building here too. I do think you have a point that many other ecosystems have a mindset where you are only building a single application with no attempt to find reusability beyond the immediate codebase. In large part because those languages/ecosystems require a bunch of extra, often complex, steps to make packages exportable. It can be a bit of mental shift to consider an application as a set of discrete, reusable parts if you come from those places.
angra_mainyu 1y ago
The usual heuristic is if you're repeating a noun in several variables, move those to a separate package with that noun. Example: WeatherConfig, WeatherService, WeatherPollInterval => weather.*

deleted 1y ago

[deleted]

9rx 1y ago

> Would clearly be a better name It appears that it wanted to be services.WeatherService, which if reduced to service.Weather isn't looking so bad, but core ended up being introduced because the unnecessary interface already overloaded the namespace. The code doesn't accidentally highlight - it is crying out. > always makes me feel like my types are dangling out in space That's the idea, though, isn't it? Each package is its own distinct thing, intended to be useful and usable across many projects. There shouldn't be any kind of deep interconnectedness in most cases – and where there needs to be, you will typically place the related packages in a subfolder to communicate that relationship. I can't think offhand of any package manager that maintains anything other than a flat list of dependencies, and that's essentially what you are building here too. I do think you have a point that many other ecosystems have a mindset where you are only building a single application with no attempt to find reusability beyond the immediate codebase. In large part because those languages/ecosystems require a bunch of extra, often complex, steps to make packages exportable. It can be a bit of mental shift to consider an application as a set of discrete, reusable parts if you come from those places.

angra_mainyu 1y ago

The usual heuristic is if you're repeating a noun in several variables, move those to a separate package with that noun. Example: WeatherConfig, WeatherService, WeatherPollInterval => weather.*