На прошлой неделе вышел GoLand 2018.2. В этой статье мы расскажем о том, что появилось в новой версии.
Что нового вкратце:
- поддержка модулей Go (ранее известных как vgo);
- улучшенный Move-рефакторинг и новые автоматические исправления;
- пополнение в семействах Postfix Completion and Intention Actions;
- отладчик теперь поддерживает точки останова, не требующие полного прерывания программы, а также отложенную загрузку массивов, слайсов и словарей.
Кроме того, много улучшений пришли из платформы IntelliJ: от нововведений для систем контроля версий и поддержки Touch Bar для MacBook Pro до последних новинок из мира фронтенд-разработки.
Поддержка модулей Go (vgo)
В феврале команда Go анонсировала пробную версию нового инструмента для управления зависимостями, и мы сразу же решили начать работу над его поддержкой.
GoLand позволяет создавать проекты нового типа (Go Module) и предлагает синхронизировать зависимости в один клик прямо из редактора кода.
Подробнее про про поддержку модулей Go читайте здесь(статья на английском).
Move-рефакторинг
В предыдущем релизе в GoLand появился Move-рефакторинг, который умеет быстро перемещать любое объявление в другой файл в пределах одного пакета. В этой версии мы научили его перемещать символы между пакетами.
Чтобы видеть всю картину целиком, мы добавили новый интерфейс, который показывает элементы, зависимые от перемещаемого объекта. Экспортируйте и переносите эти зависимости вместе с ним.
Быстрые исправления кода
Появились новые автоматические исправления ошибок несоответствия типов: Convert to expected type и Implement missing methods.
Convert to expected type преобразует значение в ожидаемый тип в соответствии с требованиями языка:
Implement missing methods в один клик добавляет отсутствующие методы, если ожидаемым типом является интерфейс:
Генерация кода
Implement Methods теперь может не только добавлять методы из интерфейса к существующим типам, но и создавать новый тип с имплементациями методов интерфейса:
Редактирование кода
Новое действие Add dot import alias позволяет ссылаться на все экспортируемые имена без использования имени пакета. Обратное действие Remove dot import alias отменяет эти изменения.
Рефакторинг Introduce local variable теперь доступен через Alt+Enter. Быстрое действие записывает результат выполнения функций и методов в новую локальную переменную.
Postfix-шаблоны
Новый шаблон .sort добавляет метод сортировки к массивам и слайсам на основе типа элементов. Если элементы относятся к пользовательскому типу, будет применяться метод sort.Slice.
Для удобства использования мы объединили шаблоны .rre и .rrv в один новый — .rr, его можно вызывать как на выражениях, так и на именах переменных.
Стиль кода
Изучив рекомендации для Go-разработчиков по оформлению кода, мы добавили подсветку для комментариев, которые начинаются не с пробела, и научили IDE форматировать их, добавляя недостающий пробел. Спустя время выяснилось, что некоторые библиотеки (например easyjson), наоборот, требуют их отсутствия!
Для библиотек с подобным требованием мы добавили список исключений для опции Add leading space to comments. Он помогает избежать лишних пробелов, достаточно внести необходимые префиксы. Включается здесь: Settings/Preferences | Editor | Code Style | Go | Other.
Отладчик
В новой версии отладчик поддерживает точки останова, не требующие полного прерывания программы. Значения массивов, слайсов и словарей загружаются лениво, а структуры теперь можно разворачивать без ограничения по уровню вложенности.
File Watchers
Маленькое, но очень приятное улучшение появилось у File Watchers в этом релизе. Раньше нужно было настраивать File Watchers под каждый проект отдельно, теперь настройки можно переиспользовать между проектами.
Система контроля версий
Коротко о разрешении конфликтов слияния: легко ошибиться, проблему непросто найти и трудно исправить. Мы решили сделать этот процесс менее болезненным, поэтому система контроля версий теперь группирует файлы с конфликтами слияния для каждого списка изменений. Улучшенный диалог Files Merged with Conflicts показывает имена веток при выполнении Pull, Merge, или Rebase и группирует файлы по каталогам.
Появилось множество улучшений для окна Log, теперь можно:
- Открывать столько Log-окон — сколько вам необходимо;
- Удалять Git-тэг из коммита;
- Фильтровать коммиты по выбранным веткам;
- Изучать Diff Preview Panel не покидая Log-окна;
- Следить за состоянием репозитория с помощью нового действия Browse Repository at Revision.
Помимо изменений для окна Log, VCS стала лучше еще в нескольких направлениях.
Например, в новой версии можно коммитить и пушить изменения в один клик без диалога Push:
А еще управлять любым количеством аккаунтов GitHub, не переключаясь между ними:
Пользовательский интерфейс
Владельцы MacBook Pro, не проходите мимо: GoLand 2018.2 поддерживает Touch Bar. Все доступные инструменты для сенсорной панели можно настроить под свои задачи: Settings | Appearance & Behavior | Menus and Toolbars.
Еще одна новость для пользователей macOS: теперь заголовки окон можно сделать темными. Для этого необходимо включить опцию Use dark window headers в Settings | Appearance & Behavior | Appearance.
Иконки поменяли цвет, форму и стиль. Подробности вы можете найти в этом посте (на английском) от нашей команды по проектированию интерфейсов: они делятся тем, как принимали решения и что планируют сделать в будущем.
JavaScript/TypeScript
По традиции мы немного рассказываем про изменения в поддержке фронтэнд-технологий, вот несколько самых значимых:
- Поддержка TypeScript 2.9 и TypeScript 3.0;
- Много новых intention-действий: Implement interface, Create derived class, Implement members of an interface or abstract class, Generate cases for 'switch', и Iterate with 'for..of'.
- Теперь можно найти весь неиспользуемый код с новой функцией покрытия кода.
Подробнее прочитать про эти и другие улучшения можно на странице What’s New команды WebStorm.
Вот и все! Как всегда, мы будем рады услышать ваше мнение здесь в комментариях, в Twitter или баг-трекере :)
Скачать обновление можно на странице загрузки или через приложение Toolbox App.
На всякий случай напоминаю, что если вы уже используете IntelliJ IDEA Ultimate, то все возможности GoLand доступны прямо там, нужно просто установить этот плагин.
Спасибо за внимание!
Комментарии (71)
SirEdvin
02.08.2018 23:02+3Стиль кода
Тут мы выяснили, что комментариев как таковых в Go нет и не будет.
Окей, есть хоть вообще какие-то причины писать на языке без комментариев, нормальной обработки ошибок, дженериков, нормального менеджмента зависимостей и системы пакетов в 2018 году?
Edison
03.08.2018 00:06-1интересный вы человек. Практически в каждом посте про Go приходите вы и пишете одни и тоже притензии (ошибки, дженерики, менеджер зависимостей). И каждый раз разводите километровый срач. И вот опять. В чем смысле?
Ответ на ваш комментарий вы найдете в практически любом посте про Go, где вы писали.MaM
03.08.2018 10:33+2Дак человек знатно набрасывает же. Язык проповедует свой tools set и вроде бы как все языки стремяться к единообразию, но сами хейдлайнеры в лице гугл написали свой препрочессор для дженириков, к чему бы это? Комментариев нет, как использовать сторонние утилиты типа того же доксигена и генерировать доку тоже не ясно, никто не любит обрабатывать ошибки, поэтому давайте всех заставим это делать и шоб еще макросы понаписали. Мне тоже не совсем ясно какие преймущество дает гоу кроме как вкусовщины, хайпа больше, имхо
gnomeby
03.08.2018 10:45Сама суть языка, что вы получаете самостоятельный бинарник, который запихиваете в пятимегабайтный контейнер с alpine linux и дальше масштабируете до нужных значений.
А почему язык такой странный?
1. Потому что это portable C
2. Потому что старались сделать язык на котором единообразно будут писать сотрудники любой квалификации
и отсюда растут все его недостатки.
Единственно я не понял, что значит нет комментариев?SirEdvin
03.08.2018 12:51Единственно я не понял, что значит нет комментариев?
Комментарии, по определению, не должны никак влиять на код. Если же вы используете комментарии для того, что бы изменять код или его поведение — это уже нельзя назвать комментариями.
Следовательно, это можно назвать метаинформацией и при ее написании вам стоит помнить, как ее можно безопасно оформлять, а как — нет.
Edison
03.08.2018 13:00ооо, ждал этого ( я даже знаю, в каком посте на хабре вы это прочитали и теперь пишите об этом)
SirEdvin
03.08.2018 13:15Ну вот, а мне казалось, я сам это заметил.
И в чем это утверждение неправильное, в том что комментарии не должны влиять на код или в том, что в go они влияют на код?
gnomeby
03.08.2018 14:22Вы мне можете объяснить о каких комментариях идёт речь?
Edison
03.08.2018 14:29В Go есть такие вещи как директивы и CGO.
Например `//go:noescape` директива функции, она учитывается компилятором.
В тоже время `// go:noescape` — просто комментарий (пробел есть).
Тоже самое в CGO:
// #include <stdio.h> // #include <errno.h> import "C"
А вот просто комментарий:
// #include <stdio.h> // #include <errno.h> import "C"
Дальше ж, разработчики начали такое же использовать, например, для генерации кода. В статье упоминается easyjson — он генерит код для cериализация/десериализация json. Ну и там используются комменты (но без пробела), где держат метаинформацию для генератора.gnomeby
03.08.2018 14:48Это ужасно.
/me плачетEdison
03.08.2018 14:53скажем так, в любом языке вы можете такое сделать (как easyjson). Для компилятора все это будут комментарии.
Ну кроме вот тех случаев с CGO и директивами.SirEdvin
03.08.2018 14:56Но в любом языке за это бьют тряпками, а не вносят в более-менее стандарт. Или есть еще языки с похожими идеями?
khim
03.08.2018 17:53Object Pascal, C/C++, JavaScript — это из популярного и используемого
Если посмотреть на более экзотические языки — думаю можно ещё найтиSirEdvin
03.08.2018 17:54Хм… а можно примеры из С++ и JavaScript? Ну, исключая доки, в javascript у них такой же формат, как и в java и на код вроде не влияют, если я не ошибаюсь.
khim
03.08.2018 21:02В Angular даже названия переменных, которые вы используете в вашем коде влияют на результат. В C++ посмотрел, да, возможно вы правы — там OpenMP через #pragma сделан, а не через в комментарии, как в Fortran.
В Java через комментарии в старых версия работали, сейчас там появились аттрибуты (вроде в версии 1.5).
В любом случае псевдокомментации — вещь достаточно распространённая, только из-за них отказываться от языка глупо.
Edison
03.08.2018 10:551. быструю компиляцию и оптимизацию кода
2. статический бинарник
3. производительность (в зависимости с чем сравнивать, конечно)
4. concurrency
5. тулсет (go fmt/imports/guru/vet/rename, go/ast (что очень важно, что бы свои тулзы проще писать было), vgo)
6. стандартная библиотека (конечно же не все идеально), но все равно помогает решать очень много задач
7. простота кода (да да, я перешел на Go с java и код на Go читать намного проще)
8. ошибки — намного удобнее чем исключения (но может быть это уже вкусовщина)SirEdvin
03.08.2018 12:481. А что нет? Понятное дело, что то, что это делается из коробки дорогого стоит, но все-таки не очень похоже на киллер-фичу.
2. Который вы с большой вероятностью все равно положите в docker?
4. А что нет? Почти любой язык так может, даже python.
5. А что нет? Так же, я бы добавил, что тот же vgo не официальная часть тулсета, а «high experimental not ready for production» и его опять же легко могут выкинуть как dep.
6. А у кого нет нормальной стандартной библиотеки?
7. Субъективно, лично я считаю, что автоматический экспорт всех файлов в папке в общий namespace — это просто безумный ад для чтения кода.
8. Мне всегда было интересно, чем?Edison
03.08.2018 12:581. А что нет?
2. image будет небольшого размера, билдинг такого image будет самым быстрым
3. А что нет?
4. А что нет? Вы на какой пункт отвечали? vgo уже в go 1.1 (да, пока под флагом). Если бы вы чуть больше интересовались Go, вы бы знали про обсуждения dep в Go команде и какие к нему были претензии. Его хотели включить в Go тулсет, после редизайнинга (почитайте твиттер тред от Russ Cox, на хакерньюс еще был).
5. А что нет?
6. Субъективно
7. Я уже писал об этом (даже в посте, где вы бегали и кричали про ошибки в Go). Опять тоже обсуждение начинать не хочу, тем более с вами.
Edison
03.08.2018 13:15лучше бы уже новый написали, чем старый коммент изменять.
> 4. concurrency
> 4. А что нет? Почти любой язык так может, даже python.
даже python? серьезно? Умеет как Go?SirEdvin
03.08.2018 13:19лучше бы уже новый написали, чем старый коммент изменять.
Я по дурости включил Markdown и он переиначил мне нумерацию :( Простите
даже python? серьезно? Умеет как Go?
Практически, только вместо тредов у вас будут процессы. Или модель корутин в python чем-то принципиально хуже, чем схема с горутинами в go, исключая тот факт, что python не может в потоки?
Edison
03.08.2018 13:30Я даже не знаю с чего начать, тем более не использовал корутины в python. Давайте уточню:
1. Каналы есть в python? Это все таки часть concurrency в Go.
2. Так же удобно работать с корутинами? Создавать (одно ключевое слово `go`), управлять (`sync.WaitGroup`, `sync.Once`, etc, `context`, select и range для каналов).
3. Как работает планировщик корутин в python? Мне вот нравится идея с work-stealing планировщиком.SirEdvin
03.08.2018 13:40Небольшая поправка на все, что я напишу ниже — в силу того, что в python нет нормальных потоков, у вас есть различие между корутиной внутри одного процесса и корутинами между.
- Внутри процесса есть Queue, для общения между процессами есть Pipe. Но я бы предложил просто навернуть zeromq сверху для унификации.
- В целом, для синхронизации корутин есть большая куча доступных примитивов,
waitс гибкими возможностями настройки (отвалится после первого провала, после всех или просто подождать первый результат), gather, wait_for и так далее.selectнет, так как в python вообще нет case, обычно это эмулируется определенным образом. + Еще сторонние библиотеки для всяких timeout и прочей мути. В целом, вполне удобно, на мой взгляд. - Как-то так + возможность реализовать свой.
Edison
03.08.2018 13:42ну вот, вы сами показали, что все на костылях.
SirEdvin
03.08.2018 15:10Не будет ли вам сложно придумать довольно простой пример приложения, которому нужно такое взаимодействие между корутинами и я попробую его запустить на этой схеме, что бы проверить, в самом деле это все будут костыли или нет?
А то я не могу придумать какого-то быстро примера :)
Edison
03.08.2018 15:39оо, мне даже интересно как будет выглядеть на python, например, вот такое:
Создается 10 goroutine, которые читают с одного канала и обрабатывают сообщение. Есть рутина, которая пишет в канал (не важно как, например, читает с файла и пишет в канал). Обработка сообщений затратный процесс (потому один пишет и много читают). Самый обычный кейс.
При этом, после Ctrl+C завершается работа всех goroutine и после этого приложение останавливается.
(набросал быстро, к качеству можно не придраться)
package main import ( "context" "os" "os/signal" "sync" "syscall" ) func main() { queue := make(chan message) ctx, cancel := context.WithCancel(context.Background()) w := &worker{ queue: queue, } var wg sync.WaitGroup wg.Add(1) go func() { produce(ctx, queue) wg.Done() }() wg.Add(10) for i := 0; i < 10; i++ { go func() { w.work(ctx) wg.Done() }() } stop := make(chan os.Signal, 1) go func() { signal.Notify(stop, syscall.SIGTERM, syscall.SIGINT) defer signal.Stop(stop) }() <-stop cancel() wg.Wait() } type message struct{} func produce(ctx context.Context, queue chan message) { // допустим тут мы прочитали строку с файла и создали message msg := message{} select { case queue <- msg: case <-ctx.Done(): return } } type worker struct { queue chan message } func (w *worker) work(ctx context.Context) { for { select { case msg := <-w.queue: process(msg) case <-ctx.Done(): return } } } func process(msg message) { // omit }SirEdvin
03.08.2018 17:19+1У меня получилось как-то так.
В целом, немного ручного шедулинга у меня есть. По желанию можно переписать так, что бы
main_message_processerвместо того, что бы создавало просто три корутины запускало только одну, которая каждый раз при получении задачи запускала бы еще одну в фоне.Edison
03.08.2018 17:42-11. Общение через каналы (память) vs. IPC — костыли.
2. Легковесные goroutine vs. процессы — костыли.SirEdvin
03.08.2018 17:46Стоит заметить, что все происходит опять же из-за того, что в python я не могу одновременно выполнять задачи в нескольких тредах, потому что у нас есть GIL.
Но я бы сказал, что:
- Общение через каналы (общую память между тредами) vs. IPC — костыли (?).
Легковесные goroutineтреды vs. процессы — костыли.
Так как в go в пределах одного треда вы тоже не можете выполнять больше одной задачи одновременно. То есть, больше одной корутины можно (так же, как и в python), но именно работать будет все равно только одна. Разве нет?
Edison
03.08.2018 18:06Стоит заметить, что все происходит опять же из-за того, что в python я не могу одновременно выполнять задачи в нескольких тредах, потому что у нас есть GIL.
Ну вот именно, потому костыли. В Go все изначально по другому, потому python и рядом не стоит.
Так как в go в пределах одного треда вы тоже не можете выполнять больше одной задачи одновременно. То есть, больше одной корутины можно (так же, как и в python), но именно работать будет все равно только одна. Разве нет?
Вы же помните, мы говорим про concurrency?
В Go есть планировщик, который ранит горутины на тредах. В один момент времени на одном треде будет раниться одна горутина. Да. Точно так же, как на одном ядре будет выполняться один процесс в одновременно.
А теперь давайте посмотрим реальный мир — точно так же как и процесс, горутина может быть в состоянии blocked, running, waiting. Blocked — например горутина выполняет системный вызов, планировщик припарковывает эту горутину и освобождает тред, тред берет следующие горутину из очереди и выполняет ее. Как только горутина получила ответ, она попадает в очередь и как только будет свободный тред — продолжит свое выполнение. И это все в рамках одного процесса. Потому можно на одной машине запускать десятки тысяч горутин.
В данном случае треды не простаивают и полностью утилизированы, в отличии от любого другого языка с тредами (в java, например, когда тред будет выполнять блокирующий вызов — тред будет заблокирован).
В целом, почитайте про планировщик и в целом про райтайм в Go, что бы потом не писать тут глупости.
SirEdvin
03.08.2018 18:18В целом, почитайте про планировщик и в целом про райтайм в Go, что бы потом не писать тут глупости.
Ну, python может работать аналогично с go +
GOMAXPROCS=1, а дальше ему мешает фатальный недостаток. Простите. В целом, еще 2-3 года и скорее всего, python таки избавится от него и заживем, а пока да, немного страданий.
А возвращаясь к реальному миру, у вас так часто бывают задачи, в которых нужно вам необходимо утилизировать правильно ядра?
А еще обратно к реальному миру, мне кажется, вместо каналов вы чаще будете использовать какие-то другие MQ, например nats.
Edison
03.08.2018 19:19Ну, python может работать аналогично с go +GOMAXPROCS=1, а дальше ему мешает фатальный недостаток. Простите. В целом, еще 2-3 года и скорее всего, python таки избавится от него и заживем, а пока да, немного страданий.
Да вы товарищь троль.
А возвращаясь к реальному миру, у вас так часто бывают задачи, в которых нужно вам необходимо утилизировать правильно ядра?
Я же пример привел — в java тред будет заблокирован, в Go будет выполнять горутину. Тредов мало, горутин много.
А еще обратно к реальному миру, мне кажется, вместо каналов вы чаще будете использовать какие-то другие MQ, например nats.
Какая чушь.
А NATS, о господи, использует каналы. Видно, что вы никогда не программировали но Go и потому говорите такие глупости.Edison
03.08.2018 19:31-1> Какая чушь.
А NATS, о господи, использует каналы. Видно, что вы никогда не программировали но Go и потому говорите такие глупости.
Даже так — вы что никогда не писали многопоточный код, что бы сравнивать это с очередями?
bosom
03.08.2018 17:51-1Зачем вы реагируете на тролинг? Ну не нравятся кому-то go пусть пишут на том что нравится, это их проблемы, зачем в сообществе go говнокодеры? Пусть пишут на питоне на php и не в коем случае не трогают язык go!
Им не дано, и заставлять или что-то доказывать нет никакого смысла! Тем более спорить.
Отправляй тролям статью https://divan.github.io/posts/go_complain_howto/ именно для них она и написана. Пусть добавляют свои варианты и радуются.
А сообщество go будет избавлено от говнокодеров которые не понимая язык начинают писать так же как на php писали и в результате получать сами знаете что...
SirEdvin
03.08.2018 17:56-1Значит, после вашей фразы "У разработчиков GoLand нет понимания того что комментарии в коде Go это не только комментарии!" говнокодер я?) Ок да.
SirEdvin
03.08.2018 12:50Очевидно, потому что ответы, которые состоят из "сторонний инструмент" и "вам это не нужно" — это так себе ответы.
Ну и еще потому, что мне приходится пользоваться инструментами, написанными на go, которые по хорошему стоило бы написать на том же python, потому что требования по производительности у него нет, зато python позволяет концентрироваться на логике кода, вместо всякого boilerplate.
Я просто жду, что однажды мне скажут "vgo теперь включити в официальный toolchain и он стабильный, а еще добавили процедурные макросы и специальный синтаксис для метаинфомации и так далее". Но пока все нет и нет.
Edison
03.08.2018 12:59vgo уже включили в официальный toolchain
SirEdvin
03.08.2018 13:14Вы же про этот vgo?
Который "https://github.com/golang/vgo"?
И про который написано тут, что "For any production workloads, use dep, or migrate to it if you have not done so already."?
Edison
03.08.2018 13:17ну не все же сразу. Его уже включили в Go 1.11 под флагом — github.com/golang/go/issues/24301
gnomeby
03.08.2018 13:09* vgo требует поддержки IDE, с vim это работает плохо.
* Ничего не поделаешь, нам всём придётся пользоваться инструментами на go периодически. И как бы вы ни были правы в том, что Go плох, ситуация не сдвинется ни на грамм.
Или вам до сих пор никто не ответил потому что модно и потому что Google?Edison
03.08.2018 17:44для vgo с vim делаю так — проект в GOPATH и делаю
vgo mod -vendor.
Уверен что скоро будет поддержка vgo. Goland вон уже умеет.
OnYourLips
03.08.2018 12:40Причина отсутсвия исключений или дженериков достаточно простая: на этом языке могут писать качественное ПО люди, не являющиеся software engineer'ами.
SirEdvin
03.08.2018 12:45Вы использовали ПО, написанное на Go?
Краткий спойлер — такое утверждение как минимум сомнительно потому, что go в том числе не предпринимает попыток избавится от тех же runtime errors.vscrub
03.08.2018 16:27Как насчет git lfs?
SirEdvin
03.08.2018 16:29А что насчет docker в его ранних версиях?
Я не отрицаю, что на golang можно писать нормальный софт, это было бы глупо. Но утверждение о том, что «на golang даже не профессионалы могут писать качественный софт», которое на мой взгляд подразумевает, что на остальных то языках нельзя — требует хоть каких-то доказательств или исследований, потому что я предпосылок для этого не вижу.
getId
03.08.2018 04:59+1Спасибо за IDE.
Но почему светлая тема по умолчанию так обделена разнообразием подсветки?
Пример
Gizmich
03.08.2018 09:59темная тема помогает сохранить глаза при долгой работе, видимо считают что никто не пользуется светлой )
corr256
03.08.2018 11:46-1тёмная тема не глаза сохраняет, а исключительно батарейку на твоём говно-буке
gnomeby
03.08.2018 11:51Это справедливо только для OLED экранов.
igordata
03.08.2018 12:01Для сраного драйвера встроенных Intel видюх к сожалению тоже справедливо. Как же он меня бесит. Постоянно включается «динамическая» подсветка, и если картинка тёмная, то подсветка гасится.
Отключается где-то в драйвере, я толком до сих пор не понимаю где, т.к. переодически оно само слетает. И хотя все галки остаются, яркость начинает гулять.
Т.е. переключение между тёмным Sublime и светлым браузером — это несколько секунд гуляния подсветки.
А так как все галки остались на месте, то приходится снимать-сохранять-выставлять-сохранять все галки снова.
Хотя в остальном меня Intel видюхи вполне устраивают, даже выдают неплохой fps в майнкрафте в разрешение 4k. Прогресс не остановить! =)
igordata
03.08.2018 11:54Это не так. При долгой работе за компьютером мы забываем моргать, от этого глаза сохнут, как следствие возникает раздражение и светобоязнь — реакции на яркий свет, а потом даже и на неяркий свет.
В таком случае тёмная тема позволяет снизить негативные ощущения, но причину не убирает и проблему не решает. Если вы работаете с тёмной темой не из эстетических предпочтений, а из-за в глазах, затылке и т.п., то это звоночек, что дело хреново и надо начинать следить за собой, заставлять моргать часто, делать перерывы, меньше пить кофе (т.е. вообще не пить) и так далее.
Это непросто, но надо.
katezharova Автор
03.08.2018 16:30Поделитесь, пожалуйста, какое именно разнообразие в этом конкретном примере вы хотели бы увидеть?
KYuri
03.08.2018 16:04А мне бы хотелось узнать, как организован процесс CI в JetBrains.
Потому что уже второй раз (до этого — при обновлении на одну из промежуточных 2018.1, сейчас — при обновлении на 2018.2) при предложении обновиться меня предупреждают о том, что плагин для поддержки Less превратится в тыкву.
Насколько понимаю, его тупо не пересобрали под обновленную версию.katezharova Автор
03.08.2018 16:26Мы собираем плагин Less с каждый релизом и выкладываем на CDN. После установки IDE его достаточно просто обновить.
bosom
03.08.2018 17:40+1Перешел на GoLand в связи с эпичной смертью плагина GoClipse под эклипс. Покойся с миром!
Хочу рассказать что меня "покоробило" в GoLand, если вдруг не в тему и надо где-то задачи завести, дайте пожалуйста ссылки, я заведу задачи, так как это важные вещи.
У разработчиков GoLand нет понимания того что комментарии в коде Go это не только комментарии! Подход описанный в пункте "Add leading space to comments" выглядит как косяк заклеенный скотчем. Важно разделять "комментарии" хотя бы на три группы:
1.1. Управляющие директивы — Пример: // +build ignore
1.2. Комментарии/документация к экспортируемым переменным, константам, функциям
В настоящий момент они игнорируются и даже не отображаются в подсказках
1.3. Директивы управления работой сторонних библиотек, используемые в go generate, упомянуты в статье, в главе "Стиль кода" на примере библиотеки easyjson
При наличии достаточно подробного и расширенного по сравнению с GoClipse инструмента раскраски синтаксиса, был сильно удивлён тем что GoLand не делает различий между строкой и многострочной строкой.
""и``соответственно. Хотелось бы чтобы появилась возможность покрасить код с такими строками в разные цвета.
Нет возможности изменить цвет у файлов, скины меняются, все цвета изменяются, кроме цветов в именах файлов во вкладке "проект" и в табах открытых файлов. Почему?
Это же портит механизм смены скина. И из за того что имена файлов только либо красные, чёрные или голубые весь внешний вид портится. Хотелось бы иметь возможность и этим элементам задать цвета.
А в целом получился у вас редактор очень хороший, вы уже на пол шажка обогнали плагин GoClipse для эклипса. Так что так держать!
Надеюсь на достигнутом вы не остановитесь, будите прислушиваться к пожеланиям разработчиков и сделаете идеальный IDE!
Valery4
03.08.2018 18:47Возможно, это не решит все вопросы по цветовому оформлению, но всё же взгляните.
www.material-theme.com
P.S. В контесте подсветки Go я не проверял, но проект однозначно достойный. Многое из того, что там реализовано и отсутсвует из коробки — вызывает у меня недоумение.
katezharova Автор
03.08.2018 20:42- Все так и работает, комментарии разделяются на эти три типа: директивы IDE знает сама, вторая группа от третьей отделяется введенной настройкой.
- Заведите, пожалуйста, реквест в нашем баг-трекере.
- Объясните, пожалуйста, какой смысл вы вкладываете в слово «скин».
И да, на данный момент UI элементы (в том числе табики) нельзя кастомизировать. Но, можно как раз воспользоваться вышеупомянутым плагином: Preferences | Plugins | Material Theme UI.
beduin01
Боже, какой же у Go синтаксис уродский…
Сейчас реально истерия пройдет и фанбои сдуются. По факту имеем очень ущербный язык, разработчики которого поставили крест на всех наработках в области языков программирования. На фоне Go даже такие упоротые проекты как Nim смотрятся свежо и актуально.
Сейчас гоферы Go-вна понапишут и потом придется кучу времени потратить, чтобы это на нормальные языки переписать.
Даже Python на фоне Go смотрится как ракета.
Hixon10
Не знаю, это вы набрасываете на вентилятор, или правда так считаете. Но сделать просто куда сложнее, чем сделать сложно.
Я думаю, в Гугле люди знают, как реализовывать всякие LINQ-подобные API, имплиситы, дженерики, зависимые типы, higher kinded типы, и другое. И Гуглерам было ой, как не просто, спроектировать проестое API Go, на котором сможет любой general разработчик прочитать и написать код.
arilou_camper
Я думаю, что Гугл очень сильно страдает синдромом NIH.
igordata
Минусуют потому, что ты не привёл аргументов.
Мне нравится синтаксис Go. Но «нравится / не нравится» — это субъективщина. Мне например не нравится отсутствие скобочек в Python. Но я и не пишу на Python, так что тут всё сходится.
Но мне интересно, что конкретно по-твоему не так с синтаксисом Go. Расскажешь или это тайна?
beduin01
Достаточно на любой язык от C# до Python посмотреть, чтобы понять что с синтаксисом Go не так. С Go буквально всё не так. Сильных сторон кроме маркетинговых никаких. Зато куча обезьян думают, что разные абстракции злые взрослые сделали специально, чтобы дети в них разобраться не могли. В итоге вся эта проста в Go выливается в том, что программисты будут изобретать велосипеды где только можно.
Valery4
Вот за это и минусуют. Говно, но что не так не скажу — всё не так, просто сами посмотрите на другое. А те кто пишут на Го — обезьяны.
Я вот не хочу такое здесь читать, хоть на Го и не пишу. Поэтому внёс свою лепту, чтобы вы пореже могли писать.
beduin01
Все аргументы в пользу Go исключительно маркетинговые. Реальных аргументов я так и не услышал. Только бред какой-то про простой код, толстые бинарики и тд. Создается впечатление, что люди на Go только Hello World'ы пишут. Попробуйте что ли бизнес-логику на нем реализовать. Посмотрим каким колом этот «простой и понятный код» вам встанет.
Valery4
Вы не по адресу, я не пишу на Го и не агитирую. Мне неприятно агрессивно-пренебрежительное отношение к людям имеющее отличное мнение от вашего.