но goland пока недоделанный, имхо. платить я бы за него не стал

Sublime с баффами

и что там недоделано?

Актуальность слабая

в чем слабая? вроде бы все умеет делать, что от него требуется

Нет необходимости от него избавляться - ведь работало все как-то все эти годы, но дело в том что в принципе GOPATH был необходим из-за особенностей того как Go резолвил зависимости, у многих разработчиков свой подход к тому как хранить код проектов у себя на машине и GOPATH в этом плане был не очень удобен. Сейчас с появлением go.mod появилась возможность отвязаться от GOPATH

Как я уже сказал. меня GOPATH устраивает, Не вижу с ним проблемы с которой надо бороться. Но я так же хочу хлебать борщи в виде семантически версионированных зависимостей, поэтому go mod тоже нужен. Хотелось бы это как-то совместить, а не выпиливать работающие и привычные фичи

ну у меня есть лицуха на джетбрейнс, так що не жалко

но goland пока недоделанный, имхо. платить я бы за него не стал

Почему недоделанный?

и что там недоделано?

по сравнению с той же Idea для джава - небо и земля.

в чем слабая? вроде бы все умеет делать, что от него требуется

В 2017 был родной dep, сейчас он же и модули из коробки

по сравнению с той же Idea для джава - небо и земля.

конкретику пожалуйста. что для разработки на go не хватает в голэнд?

но goland пока недоделанный, имхо. платить я бы за него не стал

почему? сижу на нем и пока дискомфорта не ощущаю

конкретику пожалуйста. что для разработки на go не хватает в голэнд?

очевидно же - джавы

Как я уже сказал. меня GOPATH устраивает, Не вижу с ним проблемы с которой надо бороться. Но я так же хочу хлебать борщи в виде семантически версионированных зависимостей, поэтому go mod тоже нужен. Хотелось бы это как-то совместить, а не выпиливать работающие и привычные фичи

Попробовал модули? Не знаю зачем совмещать, но если что там есть вендоринг для легаси

очевидно же - джавы

аа)

по сравнению с той же Idea для джава - небо и земля.

Например? Для го нужна поддержка maven? Или чего не хватает?

Попробовал модули? Не знаю зачем совмещать, но если что там есть вендоринг для легаси

попробовал. Впечатения в принципе совпадают с твоими. Да, есть. Но они же планируют вроде выпилить vendor и GOPATH, вот что смущает

попробовал. Впечатения в принципе совпадают с твоими. Да, есть. Но они же планируют вроде выпилить vendor и GOPATH, вот что смущает

где писали про выпил vendor?

на хаборе в стате прочёл)

спс

Так так

Dep вскоре выпилят?

попробовал. Впечатения в принципе совпадают с твоими. Да, есть. Но они же планируют вроде выпилить vendor и GOPATH, вот что смущает

ну его выпилят, но когда? думаю годика полтора есть

сможешь нормально мигрировать везде

Dep вскоре выпилят?

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

@madgopher

Что такое?

триггернул тебя на vscode vs goland

триггернул тебя на vscode vs goland

Ай, скучно же) и так понятно, что vscode)

блин

вот в голенеде автокомплит ахуенный

но я привык уже к vscode... очень удобно сделана работа с гитом, и вообще всё красиво (

Только таски заебуют

Только таски заебуют

?

Не включено по умолчанию буил тест ран, саму приходится писать

Например? Для го нужна поддержка maven? Или чего не хватает?

ну много чего из рефакторинга, что умеет идея и не умеет (не умел goland). например сходу не было такой фичи как замена дублирующегося кода на вызов функции, перемещение файлов в другие пакеты, с заменой по всему проекту.

Не включено по умолчанию буил тест ран, саму приходится писать

для чего должно быть прописано? для всех точек входа проекта? не совсем понятно

Меня тоже устраивает. Что не так с GOPATH и почему нужно от него избавляться? Про это можно где-то почитать?

Тем, что это уродливая концепция — по умолчанию забивать на менеджмент зависимостей и по сути костыль, усложняющий работу с форками и которого надо всячески избегать с помощью dep и прочих тулзов? Я понимаю что у половины сообщества уже стокгольмский синдром к архитектурным косякам го, но блин, должны быть какие-то рамки

посмотрим во что выльется vgo, но как по мне это то, что надо было сделать несколько лет назад

коллега

vendor+dep - это и есть менеджер зависимостей. один из лучших.

vendor+dep - это и есть менеджер зависимостей. один из лучших.

речь про GOPATH

modules+vgo - это другой подход к той же проблеме, и он мне нравится существенно меньше

речь про GOPATH

а что gopath. когда он появился - не было вообще понятно, выстрелит ли язык. придумывать что-то сложнее было незачем.

modules+vgo - это другой подход к той же проблеме, и он мне нравится существенно меньше

я пока не могу понять, что мне нравится больше vendor+dep или modules+vgo, но GOPATH — это какой-то просто очевидный и запредельный трэш для современного языка

CLASSPATH что, уже отменили? или LDPATH? или -I?

CLASSPATH что, уже отменили? или LDPATH? или -I?

сравнивать со странным вместо сравнивать с хорошим?

это все вполне современные языки

это как называется? а у них негров линчуют?

CLASSPATH что, уже отменили? или LDPATH? или -I?

а они от этого становятся чем-то хорошим и правильным? Можно ещё сказать что вон — в C и CPP толком менеджмента зависимостей нет, так и нам не надо (как до появления glider/dep половина сообщества и делала, кстати)

и я понимаю, почему

и я даже поддерживаю идею "давайте подумаем об этом позже"

и я даже поддерживаю идею "давайте подумаем об этом позже"

В случае других языков — да, такой подход в целом работает В случае с superopinionated Go это приводит к тому, что для исправления косяков придётся ломать пол мира, причём не понятно с какими результатами Имхо, тут либо крестик снимите, либо трусы наденьте: либо у нас сверхстабильный язык, в котором надо продумать всё заранее, либо оставить возможность для маневрирования, но тогда не заикаться о стабильности

погоди

vendor и dep нам впилили ничего не сломав

👍

вот модули нам будут впиливать довольно жестко, да

https://habr.com/post/421411/ годнота на русском подъехала

Привет, подскажите, как с помощью dep скачать репозиторий, в корне которого нет файлов go? например github.com/prometheus/prometheus

у меня такая ошибка https://github.com/golang/dep/issues/1306

Привет, подскажите, как с помощью dep скачать репозиторий, в корне которого нет файлов go? например github.com/prometheus/prometheus

git clone потм в терминале заходишь впапку проекта и пишешь dep ensure

"через гит" = "нужно на коленке написать свой пакетный менеджер"

но похоже я к этому и приду в итоге

Привет, подскажите, как с помощью dep скачать репозиторий, в корне которого нет файлов go? например github.com/prometheus/prometheus

dep ensure -vendor-only

Привет, подскажите, как с помощью dep скачать репозиторий, в корне которого нет файлов go? например github.com/prometheus/prometheus

упомянуть его в импортах, и сделать dep ensure

dep ensure -vendor-only

дв аминуса перед словом вендор

упомянуть его в импортах, и сделать dep ensure

var _ = api.Client уже автоматически рука набивает

dep ensure -vendor-only

no Gopkg.lock exists from which to populate vendor/

упомянуть его в импортах, и сделать dep ensure

t.me/gogolang/131500

один из последних моих даунских вопросов, вот проект у меня в $GOPATH/src и там и пакеты

я импорт делаю как project_name/package_name ?

нет

Привет, подскажите, как с помощью dep скачать репозиторий, в корне которого нет файлов go? например github.com/prometheus/prometheus

а как у вас в импортах оказалось нечто, в чем нет go файлов?

а как у вас в импортах оказалось нечто, в чем нет go файлов?

мне нужно сделать вандоринг внешних зависимостей, которые не указаны в main.go

я импорт делаю как project_name/package_name ?

import ( "ДОМЕН/ПРОЕКТ/ПАКЕТ" )

ДОМЕН?

это как?

а как у вас в импортах оказалось нечто, в чем нет go файлов?

он пытается сделать dep -ensure -add

мне нужно сделать вандоринг внешних зависимостей, которые не указаны в main.go

что такое вендоринг внешних зависимостей без go файлов?

это как?

github.com/project/package

а

так мне не нужен домен)0)