Comments 54
Плюсую. Такой же путь. Чтобы понять - надо пройти. Уже 5 лет в Golang. И в отличие от предыдущих стеков - до сих пор не воткнулся в задачу, где надо тянуть другие технологии. А в том же PHP не единожды приходилось в узких местах использовать что-то другое.
Попробуйте чего-нибудь связанное с математикой и тренировкой сетей сделать, и сразу что-нибудь еще потребуется. Go неплох для перекладывания json, все остальное не про Go
Десктопное ПО и мобилы не может
Н-да. Нехило напихали и мне и ТС. Ну вы хоть граничные условия учитывайте. Сферические кони - они всегда круче всех.
Конечно речь была про web-мир. А если придраться - и у 1с есть своя ниша.
Go хороший язык для небольших сервисов и реализация параллелизма наверно лучшее из всего (особенно после того, как ты написал сто миллионов async/await в С# или typescript), но недостаток инструментария все равно часто напрягает.
А в чём недостаток?
недостаток инструментария? В го?
Тот самый го который можно скомпилировать под что угодно, без головняка и эльфийского делать вставки из других языков или и вовсе подключать целые либы?
Тот самый Го в котором НОРМАЛЬНО построенная система либ (модулей) ?
Мы точно говорим про тот самый Го в котором тесты и бенчмарки перестали быть своим отдельным миром?
Json в excel попробуйте конветнуть )
Нет общей либы конвертации, приходится писать болейплейт, да ещё и поддерживать его
В других языках ставишь либу, вызываешь функцию
Модули в го могут называться одинаково и после этого начинаются танцы с бубном
ну так это особенности статической типизации. можно все как map[string]any распарсить "в лоб" и с ним работать если прям горит, но по уму таки работать с четкими структурами данных
а за модули вообще смешно - ты можешь сам при инициализации указать какое удобно имя или вообще "прилинковать" напрямую. Даже если у тебя будет 10 одинаковых имен модулей, работать с ними ты будешь так как назовешь без каких либо жестких привязок или конфликта имен
Модули в го могут называться одинаково и после этого начинаются танцы с бубном
Ответить cmyser
Это не то чтобы прям так уж критично, есть же алиасы.
В чем проблема с конвертацией? Подключаем пакет encoding/json, подключаем пакет для работы с экселем, перекладываем данные тем способом, который требуется. Все как в любом другом языке.
особенно после того, как ты написал сто миллионов async/await в С# или typescript
особенно классно узнавать, что какая-то функция работает асинхронно без единого намёка на это
А что не так с async/await?
Go отличный язык для своей ниши, но есть нюансы. Если допустить что любой ЯП синтаксис+runtime+toolchain+stdlib имеет константную сложность, то у Go вся сложность перенесена в toolchain, в результате этого получаеться очень простой язык, но очень сложная обвязка вокруг него. Вот как пример https://golangci-lint.run/docs/linters/, 112 литеров это мягко говоря перебор. В Rust например ситуация кардинально противоположная, вся сложность перенесена в компилятор.
И как только дело касается soft real time или hard real time, то Go просто не подходит.
Линтеров больше, вот ещё: https://revive.run/r
Я и сам добавил парочку:
https://github.com/unused-interface-methods/unused-interface-methods
https://github.com/error-log-or-return/error-log-or-return
Мне нравится, что бьют по рукам линейкой, только когда попрошу.
Если человек не осилил Rust, то почему бы и не побаловаться с гошечкой, не осуждаем
Вакансий на Rust сейчас существенно меньше. Всем нужен Golang.
раст не нужен, не зачем его осиливать.
А кто тогда напихал минусов? Из лагерей PHP & NodeJS, вероятно. Шучу.
Я за любой кипиш, кроме голодовки. Пробовал и Rust, но у него же другое применение. А для профессии вебмастера - Go лучший, по моим ощущениям.
Коллеги, пожалуйста, поделитесь мудростью: работая под Win в IDE (условно, Goland) как проще всего делать готовый исполняемый файл не только под Win, но и сразу под Linux? Т.е. сразу две сборки под разные системы?
А зачем делать готовый исполняемый файл в IDE? Как будто для таких целей должен быть пайплайн настроен в каком-нибудь гитлабе.
Приватный, бесплатный план на github. С action так не получится. Вот и мудрю, как решить этот вопрос наиболее простым и не геморным способом. Может быть через контейнер докер как то сделать генерацию под Linux
все получится, просто в настройках репы надо разрешить что бы actions имел права
https://github.com/voluminor/scripts-for-integration вот держите если надо с примерами, не так давно вычесал в очередной раз гитхаб. По ссылке в целом автоматизация, вам же надо чисто actions с тем как его можно "готовить"
Может быть через контейнер докер как то сделать генерацию под Linux
Или в wsl собирать
сделать build с нужными параметрами если "в лоб". По красоте обернуть в контейнеры что бы собирало в той же ОС что бы не было сюрпризов
вообще из личной практики такое у меня собирается на стороне Ci/Cd в гитхабе с тестами, генераторами и тд. То есть по матрице паплайн на разные ОС и уже четко под ними пробегают тесты и если ок собираются (потому как могут быть мелкие подводные)
Если не используете CGO в проекте, то выставить две переменные окружения, отвечающие за архитектуру и ОС и запустить сборку
GOOS=linux GOARCH=amd64 go build -o myprogram_linuxЕсли CGO используется, то собирайте в локальном докер-контейнере, сделайте в мейкфайле, например, таргет для этого (или в любой другой системе запуска скриптов, которая вам удобна).
Почему автору поставили минусы? Возможно, «я пиарюсь» было бы более подходящим тегом статьи.
Думаю, автору стоило бы рассказать о «300 секретах»: как он их создавал с помощью LLM. Мне и другим читателям было бы интересно об этом узнать.
Бегло глянул проект https://github.com/comerc/budva43. На мой взгляд и субъективный, впечатление, что нет понятной принятой в Go структуры проектов, как, например, https://github.com/golang-standards/project-layout, и на первый взгляд выглядит как беспорядочные папки и с проблемными неймингами. И типичные проблемы с repo, с функционалом который не должен быть по определению в патерне Repository.
Я поставил минус потому что статья не имеет никакой информационной цености, просто заметка "мой жизненный путь" в три абзаца. Хабр всетаки это не жж и не твиттер.
Думаю, автору стоило бы рассказать о «300 секретах»: как он их создавал с помощью LLM. Мне и другим читателям было бы интересно об этом узнать.
За других не уверен, судя по негативной реакции на мои откровения...
В процессе загорается лампочка в голове, выписываешь вопрос. Правильно заданный вопрос - половина ответа. Клавдия всё знает. Потом интервальные повторения, что-то откладывается постепенно.
Наверно началось всё с подготовки к алгоритмической сессии в Нёбиус. Получил список алгоритмов, составил конспект. Зубрил целый месяц - не помогло.
Потом ещё была книжка "100 секретов Go", пока её штудировал, выписывал какие-то неочевидные для себя моменты. (Когда считаешь, что всё знаешь - а вот и нет).
А ещё опросники к собесам конспектировал.
на первый взгляд выглядит как беспорядочные папки и с проблемными неймингами. И типичные проблемы с repo, с функционалом который не должен быть по определению в патерне Repository.
Просто не укладывается в привычные шаблоны. Почему нейминги проблемные? И какие вопросы к функционалу в repo? Было бы интересно послушать фидбэк.
Ну не знаю, делал несколько подходов уже. Прям заставляю себя перейти. Но это урезаное, вернее альтернативное, понимание ООП, классов и прочего стопорит на этапе проектирования кода. Понимаю, что проще начать с go, чем переходить, но автор же прям восхищается легкостью перехода от php/typescript…
Я подумал сначала что статья написана нейросетью слово "хайлоад" встречается в каждом предложении. Автор вопрос, а что такое хайлоад?
Нормально, ребята, вы напихали энтузиасту — -44
я изучаю golang, пока идёт тяжеловато, но что-то в нем есть 🙂
Почему Go?