Comments 5
Спасибо, чтиво занятное и интересное.
Вопрос о практической ценности оставим за кадром, не думаю, что о ней сейчас может идти речь.
Структуру Go-maven проекта, я постарался приблизить к стандартной принятой для Go структуре папок (т.е./srcи/binв корне проекта)
В принятой (негласно, само собой) в Go структуре в корне проекта нет директорий /src или /bin. Зато они есть в $GOROOT и $GOPATH.
== слабая продуманность организации структуры Go проектов и потребность в постоянной настройке параметров среды
Хотелось бы понять о чём здесь сказано. В чём заключается в частности бОльшая продуманность организации java проектов. И о какой постоянной настройке параметров среды идёт речь, если ранее для компиляции требовалось поставить одну переменную окружения, а сейчас ноль.
Так же весьма любопытно, какие именно практические задачи вы порешали данным нововведением. Каков профит от написания вот этих вот всех жутковатых xml файлов для гоферов, у которых 99.999% проектов билдятся директивой go build? Для этого интересно было бы взглянуть на набор консольных инструкций для компиляции/сборки до и после применения описанной утилиты. Сильно сомневаюсь, что первый на много больше или значимо сложнее второго, учитывая, что у вас кроскомпиляция, и следовательно нет необходимости возится с С/С++ тулчейном.
Хотелось бы понять о чём здесь сказано. В чём заключается в частности бОльшая продуманность организации java проектов. И о какой постоянной настройке параметров среды идёт речь, если ранее для компиляции требовалось поставить одну переменную окружения, а сейчас ноль.
Так же весьма любопытно, какие именно практические задачи вы порешали данным нововведением. Каков профит от написания вот этих вот всех жутковатых xml файлов для гоферов, у которых 99.999% проектов билдятся директивой go build? Для этого интересно было бы взглянуть на набор консольных инструкций для компиляции/сборки до и после применения описанной утилиты. Сильно сомневаюсь, что первый на много больше или значимо сложнее второго, учитывая, что у вас кроскомпиляция, и следовательно нет необходимости возится с С/С++ тулчейном.
современные Java проекты стали очень структурированными и в них уже практически не встретить микс из ресурсов с исходниками и тестами, поэтому было даже как то странно столкнуться с таким подходом из 90-х в языке из 2010-х. Современный серьезный Java проект это когда четко разбиты исходники, ресурсы, тестовые исходники, ресурсы тестов и этого мне не хватает в Go, вот плагин в какой то мере закрыл эту потребность. Напомню, что плагин разрабатывался, когда Go не предлагал решения с 0 переменных, но требовал настроить кучу переменных окружения.
Лично я при помощи Go решаю маленькие задачи, просто я люблю когда у меня есть «швейцарский нож» и поэтому я накрутил плагин что бы иметь возможность разрабатывать энтерпрайз-проект если мне потребуется, но в целом я сейчас обслуживаю интересы пользователей проекта, которые работают с более сложным и постят вопросы и баги. Тому кто не привык работать с xml файлами, понятно что они кажутся монструозными, хотя make файлы не менее монструозны имхо и это уже вопрос привычки. Главное что есть возможность работать с go тем кто привык к xml и можно 99.99% билдить с помощью go build, как когда то так же можно было компилить просто вызовом javac, но проекты взрослеют.
Лично я при помощи Go решаю маленькие задачи, просто я люблю когда у меня есть «швейцарский нож» и поэтому я накрутил плагин что бы иметь возможность разрабатывать энтерпрайз-проект если мне потребуется, но в целом я сейчас обслуживаю интересы пользователей проекта, которые работают с более сложным и постят вопросы и баги. Тому кто не привык работать с xml файлами, понятно что они кажутся монструозными, хотя make файлы не менее монструозны имхо и это уже вопрос привычки. Главное что есть возможность работать с go тем кто привык к xml и можно 99.99% билдить с помощью go build, как когда то так же можно было компилить просто вызовом javac, но проекты взрослеют.
Если посмотреть историю go pre-1.0, и затем 1.0, можно посмотреть, как единственная команда go build пришла на смену пачке Makefile, которые требовались до этого.
Так ведь и задачи разные — Java ориентирована на монолиты, Go на микросервисы, для которых Java с её фреймворками зачастую оверинженеринг, отсюда и разница в примерной усреднённой структуре проекта. Из этого вовсе не следует, что в java проекты более продуманы структурно, чем в Go. Может быть для гиганских монолитных приложений держать тесты и ресурсы в одном проекте/репозитории не правильно, для типичных гошных круд это вполне норм как по мне. Есть рекомендация, которой в основном все придерживаются. До сих пор конструктивных возражений против неё не встречал.
== Go не предлагал решения с 0 переменных, но требовал настроить кучу переменных окружения.
Я примерно с 13 года помню Go, ничего кроме GOPATH никогда не устанавливал.
== Go не предлагал решения с 0 переменных, но требовал настроить кучу переменных окружения.
Я примерно с 13 года помню Go, ничего кроме GOPATH никогда не устанавливал.
Sign up to leave a comment.
Maven-путь построения Go проектов