Верно ли то что в go нет конкретной структуры проекта?

Question

[loljapanes]

Подскажите пожалуйста, действительно ли в go нет конкретной структуры проекта? То есть можно писать хоть все в main.go , хоть создавать папки как тебе хочется итд? Знаю про golang standard project-layout, но замечаю что у каждого по разному кто-то использует standard project-layout, кто-то нет и делает как сам захочет

Comments

[Степан И]

Конкретной структуры вроде ни в одном языке нет.

[loljapanes]

Micro Null, возможно, но вот именно в go практически у всех структура разная и не совсем понятно что куда писать

[Василий Банников]

loljapanes, хз, у нас в .NET тоже у всех структура разная.
В целом сколько проектов - столько и разных подходов, ибо не может быть одного универсального подхода, который для всех будет одинаково хорош.

[Степан И]

loljapanes, в большинстве языков есть фреймворки, которые определяют структуру проекта. В Go фреймворками не принято пользоваться, из-за чего многие теряются.
Придерживайтесь project-layout.
Если пишете какой-то пакет, то можно вообще обойтись двумя файлами - сам пакет и тесты.

[loljapanes]

Micro Null,

В Go фреймворками не принято пользоваться

то есть gin,'ом mux'ом итд лучше не пользоваться и писать все на чистом go?

[Степан И]

loljapanes, mux и gin это библиотеки. gin хоть и определяет себя как фреймворк, но если вы работали с фреймворками в Java или PHP, то понимаете почему это не так)

[Степан И]

loljapanes, стройте приложение из библиотек как конструктор, придерживаясь project-layout. И все у вас будет в порядке.
В Go библиотеки (на сколько я понимаю) не могут тебе диктовать структуру проекта.

[Roman K]

loljapanes, gin — это микрофреймворк в терминах других языков. Фрейморков уровня Django, которые пытаются вобрать в себя всё на свете, на го нет. mux — это вообще роутер, даже не микрофреймворк

[loljapanes]

Micro Null, спасибо! Можете пожалуйста подсказать хотя бы один фреймворк в go (чтоб чуть понять как устроен Фреймворк в go, чтобы не путаться)

Answer 1

[DevMan]

конкретной структуры проекта нет вообще ни в каком языке.
конкретная структура может быть только при наличии соглашений, например, в конкретном фреймворке или собственном представлении o прекрасном.
да и ту можно (иногда и нужно) менять.

Answer 2

[d'Ivan]

Кто как хочет, тот так и делает. Однородность структуры в некотором роде упрощает понимание что где находится.
Скажем, взять структуру проекта на фреймворке Ruby on Rails: любой новый разработчик, знакомый с RoR будет знать что где искать. Конфигурация в одном месте, модели в другом, миграции БД в третьем и т.д.

Comments

[GavriKos]

на фреймворке

на то он и фреймворк. А go - не фреймворк

[d'Ivan]

GavriKos, ну так я о том же. Есть фреймворк - есть соглашение.

Answer 3

[mayton2019]

Скорее всего это связано с отсуствием сборщика. Именно он диктует определенную структуру например сорцов и тестов. Конфигов и таргет каталогов.

Comments

[DevMan]

кагбе многим сборщикам спокойно говорится где что брать и куда что класть.

[mayton2019]

DevMan, ну если разработчик подсел на иглу maven или gradle то у него будте 99% одинаковая структура фолдеров. Я готов спорить на это. Просто наблюдая проекты в github. У разраба конечно будет опция - менять назначение фолдеров. Но он этого делать не будет. Вот отсюда и возникает типичная структура проекта.

[DevMan]

mayton2019, сборщики типа maven/gradle могут предлагать "стандартную" структуру: convention over configuration. то есть "соглашения".
но, они именно предлагают, а не навязывают.
следовать или менять, каждый решает уже сам.