Как в GO правильно структурировать проект (сайт)

А как сделать что-то вроде заголовочных .h-файлов в C/C++ ?

хотелось бы понять, как в GO правильно структурировать проект

Ну создай себе файл headers.go и запихни туда все константы и типажи. И потом импортируй оттуда, туда куда нужно.

хочет чтобы этот "vars" был имортирован непосредственно в файл

чё вообще нет способа один раз только указать и юзать по всему проекту??

А ты как хотел?

Если у тебя будет одно пространство имен. То есть один пакет. Пакет можно разбить на любое число файлов. Но только в пределах одного каталога.

они что про MVC никогда не слышали?

Go это не сайтики. Go это микросервисы.

мне вот именно сайтики подавай

нужен всё ещё

Over 95% of the "debate" I see on the matter completely fails right here. The "original" definition of MVC as given in the Design Pattern book observably fails to correspond to what most people actually implement when they claim they're using an MVC design. (For one thing, the original MVC has no network communication in it, and whether people like it or not, network communication is such a fundamental change that it must be a major design consideration. Anyone who says otherwise is just deluded as to how difficult it is.) So, err... what exactly is MVC?

Nobody knows. But they're pretty sure it's good. Sometimes they're so sure it's good that they very completely know that MVC is the only good design, and if it isn't MVC, it isn't good. But... errr... what is MVC again? You can get a dozen conflicting answers to that. Which means there literally isn't an answer.

The solution, in my considered-for-several-years-now opinion, is to just ignore "MVC" entirely. You can't design your code in accordance with "something. I'm not sure what exactly, but something. Models. It definitely has models. Although their exact responsibility and nature I'm not too clear on either. But definitely models. And definitely put the words 'view' and 'controller' in your code, too." Just because you have a name doesn't mean you have a thing that corresponds to that name.

What you need is to separate your concerns, and to Don't Repeat Yourself. The rest will fall out naturally.

I will also say that actually creating directories that are called "model", "view", and "controller" will drive you absolutely batty in Go, because of the way packages drive visibility. In conventional OO languages it would not be too surprising to see some "friend" relations between the bits and pieces. In Go, you'll be forced to have things public that really shouldn't be public. It's not how Go code "wants" to be split up. Go code "wants" to be split up by concern, so, for instance, all the "user" stuff goes in one package. If you insist on MVC, the user's model and core view and controller should probably go in one "user" package.

Although, honestly, you're just not going to see much benefit from that vs. simply separating responsibilities manually. MVC was made for a problem that the vast majority of web apps simply do not have. MVC was made for when you need a lot of mixing and matching between multiple views at a time, so you have to abstract at that level. Think a 3D CAD program with multiple views on the same model, all of which can interact with it in realtime. Your web app does not look like that, so spending design budget on a design pattern for a problem you don't have is just cargo cult programming... and not even very good cargo cult programming. Meanwhile, you do have problems that the CAD programs don't, like the aforementioned fundamental inclusion of network communication, which is what you ought to be spending your design budget on.

In conclusion... no, MVC isn't a good pattern for Go web apps, because it's a terrible pattern for web apps in general.

Если у тебя будет одно пространство имен. То есть один пакет. Пакет можно разбить на любое число файлов. Но только в пределах одного каталога.
Каталог == пакет

а подкаталоги? смогут они видеть переменные из НАДкаталога и наоборот?

в C/C++ ты один раз прописал в main и юзаешь по всему проекту