company_banner

Что нового в GoLand 2018.2

    Привет, Хабр!

    На прошлой неделе вышел 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 доступны прямо там, нужно просто установить этот плагин.

    Спасибо за внимание!

    JetBrains

    376,00

    Делаем эффективные инструменты для разработчиков

    Поделиться публикацией

    Похожие публикации

    Комментарии 72
      –7
      Боже, какой же у Go синтаксис уродский…
      Сейчас реально истерия пройдет и фанбои сдуются. По факту имеем очень ущербный язык, разработчики которого поставили крест на всех наработках в области языков программирования. На фоне Go даже такие упоротые проекты как Nim смотрятся свежо и актуально.

      Сейчас гоферы Go-вна понапишут и потом придется кучу времени потратить, чтобы это на нормальные языки переписать.

      Даже Python на фоне Go смотрится как ракета.
        0
        Не знаю, это вы набрасываете на вентилятор, или правда так считаете. Но сделать просто куда сложнее, чем сделать сложно.

        Я думаю, в Гугле люди знают, как реализовывать всякие LINQ-подобные API, имплиситы, дженерики, зависимые типы, higher kinded типы, и другое. И Гуглерам было ой, как не просто, спроектировать проестое API Go, на котором сможет любой general разработчик прочитать и написать код.
          +3
          Я думаю, что Гугл очень сильно страдает синдромом NIH.
          +3
          Минусуют потому, что ты не привёл аргументов.
          Мне нравится синтаксис Go. Но «нравится / не нравится» — это субъективщина. Мне например не нравится отсутствие скобочек в Python. Но я и не пишу на Python, так что тут всё сходится.

          Но мне интересно, что конкретно по-твоему не так с синтаксисом Go. Расскажешь или это тайна?
            0
            Достаточно на любой язык от C# до Python посмотреть, чтобы понять что с синтаксисом Go не так. С Go буквально всё не так. Сильных сторон кроме маркетинговых никаких. Зато куча обезьян думают, что разные абстракции злые взрослые сделали специально, чтобы дети в них разобраться не могли. В итоге вся эта проста в Go выливается в том, что программисты будут изобретать велосипеды где только можно.
              0
              Вот за это и минусуют. Говно, но что не так не скажу — всё не так, просто сами посмотрите на другое. А те кто пишут на Го — обезьяны.

              Я вот не хочу такое здесь читать, хоть на Го и не пишу. Поэтому внёс свою лепту, чтобы вы пореже могли писать.
                +2
                Все аргументы в пользу Go исключительно маркетинговые. Реальных аргументов я так и не услышал. Только бред какой-то про простой код, толстые бинарики и тд. Создается впечатление, что люди на Go только Hello World'ы пишут. Попробуйте что ли бизнес-логику на нем реализовать. Посмотрим каким колом этот «простой и понятный код» вам встанет.
                  0
                  Вы не по адресу, я не пишу на Го и не агитирую. Мне неприятно агрессивно-пренебрежительное отношение к людям имеющее отличное мнение от вашего.
          –1
          Стиль кода

          Тут мы выяснили, что комментариев как таковых в Go нет и не будет.


          Окей, есть хоть вообще какие-то причины писать на языке без комментариев, нормальной обработки ошибок, дженериков, нормального менеджмента зависимостей и системы пакетов в 2018 году?

            +5
            интересный вы человек. Практически в каждом посте про Go приходите вы и пишете одни и тоже притензии (ошибки, дженерики, менеджер зависимостей). И каждый раз разводите километровый срач. И вот опять. В чем смысле?
            Ответ на ваш комментарий вы найдете в практически любом посте про Go, где вы писали.
              +2
              Дак человек знатно набрасывает же. Язык проповедует свой tools set и вроде бы как все языки стремяться к единообразию, но сами хейдлайнеры в лице гугл написали свой препрочессор для дженириков, к чему бы это? Комментариев нет, как использовать сторонние утилиты типа того же доксигена и генерировать доку тоже не ясно, никто не любит обрабатывать ошибки, поэтому давайте всех заставим это делать и шоб еще макросы понаписали. Мне тоже не совсем ясно какие преймущество дает гоу кроме как вкусовщины, хайпа больше, имхо
                +1
                Сама суть языка, что вы получаете самостоятельный бинарник, который запихиваете в пятимегабайтный контейнер с alpine linux и дальше масштабируете до нужных значений.
                А почему язык такой странный?
                1. Потому что это portable C
                2. Потому что старались сделать язык на котором единообразно будут писать сотрудники любой квалификации
                и отсюда растут все его недостатки.

                Единственно я не понял, что значит нет комментариев?
                  0
                  Единственно я не понял, что значит нет комментариев?

                  Комментарии, по определению, не должны никак влиять на код. Если же вы используете комментарии для того, что бы изменять код или его поведение — это уже нельзя назвать комментариями.


                  Следовательно, это можно назвать метаинформацией и при ее написании вам стоит помнить, как ее можно безопасно оформлять, а как — нет.

                    0
                    ооо, ждал этого ( я даже знаю, в каком посте на хабре вы это прочитали и теперь пишите об этом)
                      0

                      Ну вот, а мне казалось, я сам это заметил.
                      И в чем это утверждение неправильное, в том что комментарии не должны влиять на код или в том, что в go они влияют на код?

                        0
                        Вы мне можете объяснить о каких комментариях идёт речь?
                          0
                          В 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. Ну и там используются комменты (но без пробела), где держат метаинформацию для генератора.
                            0
                            Это ужасно.
                            /me плачет
                              0
                              скажем так, в любом языке вы можете такое сделать (как easyjson). Для компилятора все это будут комментарии.
                              Ну кроме вот тех случаев с CGO и директивами.
                                +1
                                Но в любом языке за это бьют тряпками, а не вносят в более-менее стандарт. Или есть еще языки с похожими идеями?
                                  –1
                                  Object Pascal, C/C++, JavaScript — это из популярного и используемого

                                  Если посмотреть на более экзотические языки — думаю можно ещё найти
                                    +1

                                    Хм… а можно примеры из С++ и JavaScript? Ну, исключая доки, в javascript у них такой же формат, как и в java и на код вроде не влияют, если я не ошибаюсь.

                                      –1
                                      В Angular даже названия переменных, которые вы используете в вашем коде влияют на результат. В C++ посмотрел, да, возможно вы правы — там OpenMP через #pragma сделан, а не через в комментарии, как в Fortran.

                                      В Java через комментарии в старых версия работали, сейчас там появились аттрибуты (вроде в версии 1.5).

                                      В любом случае псевдокомментации — вещь достаточно распространённая, только из-за них отказываться от языка глупо.
                    +2
                    1. быструю компиляцию и оптимизацию кода
                    2. статический бинарник
                    3. производительность (в зависимости с чем сравнивать, конечно)
                    4. concurrency
                    5. тулсет (go fmt/imports/guru/vet/rename, go/ast (что очень важно, что бы свои тулзы проще писать было), vgo)
                    6. стандартная библиотека (конечно же не все идеально), но все равно помогает решать очень много задач
                    7. простота кода (да да, я перешел на Go с java и код на Go читать намного проще)
                    8. ошибки — намного удобнее чем исключения (но может быть это уже вкусовщина)
                      +1
                      1. А что нет? Понятное дело, что то, что это делается из коробки дорогого стоит, но все-таки не очень похоже на киллер-фичу.
                      2. Который вы с большой вероятностью все равно положите в docker?
                      4. А что нет? Почти любой язык так может, даже python.
                      5. А что нет? Так же, я бы добавил, что тот же vgo не официальная часть тулсета, а «high experimental not ready for production» и его опять же легко могут выкинуть как dep.
                      6. А у кого нет нормальной стандартной библиотеки?
                      7. Субъективно, лично я считаю, что автоматический экспорт всех файлов в папке в общий namespace — это просто безумный ад для чтения кода.
                      8. Мне всегда было интересно, чем?
                        –1
                        1. А что нет?
                        2. image будет небольшого размера, билдинг такого image будет самым быстрым
                        3. А что нет?
                        4. А что нет? Вы на какой пункт отвечали? vgo уже в go 1.1 (да, пока под флагом). Если бы вы чуть больше интересовались Go, вы бы знали про обсуждения dep в Go команде и какие к нему были претензии. Его хотели включить в Go тулсет, после редизайнинга (почитайте твиттер тред от Russ Cox, на хакерньюс еще был).
                        5. А что нет?
                        6. Субъективно
                        7. Я уже писал об этом (даже в посте, где вы бегали и кричали про ошибки в Go). Опять тоже обсуждение начинать не хочу, тем более с вами.
                          –1
                          лучше бы уже новый написали, чем старый коммент изменять.
                          > 4. concurrency
                          > 4. А что нет? Почти любой язык так может, даже python.

                          даже python? серьезно? Умеет как Go?
                            +1
                            лучше бы уже новый написали, чем старый коммент изменять.

                            Я по дурости включил Markdown и он переиначил мне нумерацию :( Простите


                            даже python? серьезно? Умеет как Go?

                            Практически, только вместо тредов у вас будут процессы. Или модель корутин в python чем-то принципиально хуже, чем схема с горутинами в go, исключая тот факт, что python не может в потоки?

                              –1
                              Я даже не знаю с чего начать, тем более не использовал корутины в python. Давайте уточню:
                              1. Каналы есть в python? Это все таки часть concurrency в Go.
                              2. Так же удобно работать с корутинами? Создавать (одно ключевое слово `go`), управлять (`sync.WaitGroup`, `sync.Once`, etc, `context`, select и range для каналов).
                              3. Как работает планировщик корутин в python? Мне вот нравится идея с work-stealing планировщиком.
                                +2

                                Небольшая поправка на все, что я напишу ниже — в силу того, что в python нет нормальных потоков, у вас есть различие между корутиной внутри одного процесса и корутинами между.


                                1. Внутри процесса есть Queue, для общения между процессами есть Pipe. Но я бы предложил просто навернуть zeromq сверху для унификации.
                                2. В целом, для синхронизации корутин есть большая куча доступных примитивов, wait с гибкими возможностями настройки (отвалится после первого провала, после всех или просто подождать первый результат), gather, wait_for и так далее. select нет, так как в python вообще нет case, обычно это эмулируется определенным образом. + Еще сторонние библиотеки для всяких timeout и прочей мути. В целом, вполне удобно, на мой взгляд.
                                3. Как-то так + возможность реализовать свой.
                                  0
                                  ну вот, вы сами показали, что все на костылях.
                                    0

                                    Не будет ли вам сложно придумать довольно простой пример приложения, которому нужно такое взаимодействие между корутинами и я попробую его запустить на этой схеме, что бы проверить, в самом деле это все будут костыли или нет?


                                    А то я не могу придумать какого-то быстро примера :)

                                      0
                                      оо, мне даже интересно как будет выглядеть на 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
                                      }
                                      
                                        +1

                                        У меня получилось как-то так.


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

                                          –1
                                          1. Общение через каналы (память) vs. IPC — костыли.
                                          2. Легковесные goroutine vs. процессы — костыли.
                                            0

                                            Стоит заметить, что все происходит опять же из-за того, что в python я не могу одновременно выполнять задачи в нескольких тредах, потому что у нас есть GIL.


                                            Но я бы сказал, что:


                                            1. Общение через каналы (общую память между тредами) vs. IPC — костыли (?).
                                            2. Легковесные goroutine треды vs. процессы — костыли.

                                            Так как в go в пределах одного треда вы тоже не можете выполнять больше одной задачи одновременно. То есть, больше одной корутины можно (так же, как и в python), но именно работать будет все равно только одна. Разве нет?

                                              0
                                              Стоит заметить, что все происходит опять же из-за того, что в python я не могу одновременно выполнять задачи в нескольких тредах, потому что у нас есть GIL.

                                              Ну вот именно, потому костыли. В Go все изначально по другому, потому python и рядом не стоит.


                                              Так как в go в пределах одного треда вы тоже не можете выполнять больше одной задачи одновременно. То есть, больше одной корутины можно (так же, как и в python), но именно работать будет все равно только одна. Разве нет?

                                              Вы же помните, мы говорим про concurrency?
                                              В Go есть планировщик, который ранит горутины на тредах. В один момент времени на одном треде будет раниться одна горутина. Да. Точно так же, как на одном ядре будет выполняться один процесс в одновременно.


                                              А теперь давайте посмотрим реальный мир — точно так же как и процесс, горутина может быть в состоянии blocked, running, waiting. Blocked — например горутина выполняет системный вызов, планировщик припарковывает эту горутину и освобождает тред, тред берет следующие горутину из очереди и выполняет ее. Как только горутина получила ответ, она попадает в очередь и как только будет свободный тред — продолжит свое выполнение. И это все в рамках одного процесса. Потому можно на одной машине запускать десятки тысяч горутин.
                                              В данном случае треды не простаивают и полностью утилизированы, в отличии от любого другого языка с тредами (в java, например, когда тред будет выполнять блокирующий вызов — тред будет заблокирован).


                                              В целом, почитайте про планировщик и в целом про райтайм в Go, что бы потом не писать тут глупости.

                                                0
                                                В целом, почитайте про планировщик и в целом про райтайм в Go, что бы потом не писать тут глупости.

                                                Ну, python может работать аналогично с go +GOMAXPROCS=1, а дальше ему мешает фатальный недостаток. Простите. В целом, еще 2-3 года и скорее всего, python таки избавится от него и заживем, а пока да, немного страданий.


                                                А возвращаясь к реальному миру, у вас так часто бывают задачи, в которых нужно вам необходимо утилизировать правильно ядра?


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

                                                  0
                                                  Ну, python может работать аналогично с go +GOMAXPROCS=1, а дальше ему мешает фатальный недостаток. Простите. В целом, еще 2-3 года и скорее всего, python таки избавится от него и заживем, а пока да, немного страданий.

                                                  Да вы товарищь троль.


                                                  А возвращаясь к реальному миру, у вас так часто бывают задачи, в которых нужно вам необходимо утилизировать правильно ядра?

                                                  Я же пример привел — в java тред будет заблокирован, в Go будет выполнять горутину. Тредов мало, горутин много.


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

                                                  Какая чушь.
                                                  А NATS, о господи, использует каналы. Видно, что вы никогда не программировали но Go и потому говорите такие глупости.

                                                    –1
                                                    > Какая чушь.
                                                    А NATS, о господи, использует каналы. Видно, что вы никогда не программировали но Go и потому говорите такие глупости.

                                                    Даже так — вы что никогда не писали многопоточный код, что бы сравнивать это с очередями?
                                          –1

                                          Зачем вы реагируете на тролинг? Ну не нравятся кому-то go пусть пишут на том что нравится, это их проблемы, зачем в сообществе go говнокодеры? Пусть пишут на питоне на php и не в коем случае не трогают язык go!
                                          Им не дано, и заставлять или что-то доказывать нет никакого смысла! Тем более спорить.


                                          Отправляй тролям статью https://divan.github.io/posts/go_complain_howto/ именно для них она и написана. Пусть добавляют свои варианты и радуются.


                                          А сообщество go будет избавлено от говнокодеров которые не понимая язык начинают писать так же как на php писали и в результате получать сами знаете что...

                                            0

                                            Значит, после вашей фразы "У разработчиков GoLand нет понимания того что комментарии в коде Go это не только комментарии!" говнокодер я?) Ок да.

                        0

                        Очевидно, потому что ответы, которые состоят из "сторонний инструмент" и "вам это не нужно" — это так себе ответы.


                        Ну и еще потому, что мне приходится пользоваться инструментами, написанными на go, которые по хорошему стоило бы написать на том же python, потому что требования по производительности у него нет, зато python позволяет концентрироваться на логике кода, вместо всякого boilerplate.


                        Я просто жду, что однажды мне скажут "vgo теперь включити в официальный toolchain и он стабильный, а еще добавили процедурные макросы и специальный синтаксис для метаинфомации и так далее". Но пока все нет и нет.

                          0
                          vgo уже включили в официальный toolchain
                            +1

                            Вы же про этот vgo?
                            Который "https://github.com/golang/vgo"?


                            И про который написано тут, что "For any production workloads, use dep, or migrate to it if you have not done so already."?

                              0
                              ну не все же сразу. Его уже включили в Go 1.11 под флагом — github.com/golang/go/issues/24301
                                0

                                Уже круто, да. Спасибо.

                            0
                            * vgo требует поддержки IDE, с vim это работает плохо.
                            * Ничего не поделаешь, нам всём придётся пользоваться инструментами на go периодически. И как бы вы ни были правы в том, что Go плох, ситуация не сдвинется ни на грамм.
                            Или вам до сих пор никто не ответил потому что модно и потому что Google?
                              0

                              для vgo с vim делаю так — проект в GOPATH и делаю vgo mod -vendor.
                              Уверен что скоро будет поддержка vgo. Goland вон уже умеет.

                                0
                                Оооо, вы спасли несколько жизней.
                          +2
                            –1
                            Причина отсутсвия исключений или дженериков достаточно простая: на этом языке могут писать качественное ПО люди, не являющиеся software engineer'ами.
                              +2
                              Вы использовали ПО, написанное на Go?
                              Краткий спойлер — такое утверждение как минимум сомнительно потому, что go в том числе не предпринимает попыток избавится от тех же runtime errors.
                                0
                                Как насчет git lfs?
                                  0
                                  А что насчет docker в его ранних версиях?

                                  Я не отрицаю, что на golang можно писать нормальный софт, это было бы глупо. Но утверждение о том, что «на golang даже не профессионалы могут писать качественный софт», которое на мой взгляд подразумевает, что на остальных то языках нельзя — требует хоть каких-то доказательств или исследований, потому что я предпосылок для этого не вижу.
                                    0
                                    чем меньше возможностей ошибиться — тем качетвеннее код (с точки зрения «прострели себе ногу»)
                                      0
                                      А как go способствует тому, что у вас меньше возможности ошибиться?
                                        –2
                                        чем проще — тем меньше возможностей ошибиться
                                          +2
                                          Проста языка компенсируется сложностью тулчейна, который стоят вокруг.
                                          Опять же, вот python простой, что с ним не так в этом плане?
                            +3
                            Спасибо за IDE.
                            Но почему светлая тема по умолчанию так обделена разнообразием подсветки?
                            Пример
                            image

                              0
                              темная тема помогает сохранить глаза при долгой работе, видимо считают что никто не пользуется светлой )
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Это справедливо только для OLED экранов.
                                    +1
                                    Для сраного драйвера встроенных Intel видюх к сожалению тоже справедливо. Как же он меня бесит. Постоянно включается «динамическая» подсветка, и если картинка тёмная, то подсветка гасится.

                                    Отключается где-то в драйвере, я толком до сих пор не понимаю где, т.к. переодически оно само слетает. И хотя все галки остаются, яркость начинает гулять.
                                    Т.е. переключение между тёмным Sublime и светлым браузером — это несколько секунд гуляния подсветки.

                                    А так как все галки остались на месте, то приходится снимать-сохранять-выставлять-сохранять все галки снова.

                                    Хотя в остальном меня Intel видюхи вполне устраивают, даже выдают неплохой fps в майнкрафте в разрешение 4k. Прогресс не остановить! =)
                                  +2
                                  Это не так. При долгой работе за компьютером мы забываем моргать, от этого глаза сохнут, как следствие возникает раздражение и светобоязнь — реакции на яркий свет, а потом даже и на неяркий свет.

                                  В таком случае тёмная тема позволяет снизить негативные ощущения, но причину не убирает и проблему не решает. Если вы работаете с тёмной темой не из эстетических предпочтений, а из-за в глазах, затылке и т.п., то это звоночек, что дело хреново и надо начинать следить за собой, заставлять моргать часто, делать перерывы, меньше пить кофе (т.е. вообще не пить) и так далее.

                                  Это непросто, но надо.
                                  0
                                  Поделитесь, пожалуйста, какое именно разнообразие в этом конкретном примере вы хотели бы увидеть?
                                    +2
                                    Хотел бы светлый аналог Colorful Darcula в списке стандартных тем.
                                    Пример
                                    image
                                  0
                                  А мне бы хотелось узнать, как организован процесс CI в JetBrains.
                                  Потому что уже второй раз (до этого — при обновлении на одну из промежуточных 2018.1, сейчас — при обновлении на 2018.2) при предложении обновиться меня предупреждают о том, что плагин для поддержки Less превратится в тыкву.
                                  Насколько понимаю, его тупо не пересобрали под обновленную версию.
                                    0
                                    Мы собираем плагин Less с каждый релизом и выкладываем на CDN. После установки IDE его достаточно просто обновить.
                                    +1

                                    Перешел на GoLand в связи с эпичной смертью плагина GoClipse под эклипс. Покойся с миром!


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


                                    1. У разработчиков GoLand нет понимания того что комментарии в коде Go это не только комментарии! Подход описанный в пункте "Add leading space to comments" выглядит как косяк заклеенный скотчем. Важно разделять "комментарии" хотя бы на три группы:
                                      1.1. Управляющие директивы — Пример: // +build ignore
                                      1.2. Комментарии/документация к экспортируемым переменным, константам, функциям
                                      В настоящий момент они игнорируются и даже не отображаются в подсказках
                                      1.3. Директивы управления работой сторонних библиотек, используемые в go generate, упомянуты в статье, в главе "Стиль кода" на примере библиотеки easyjson


                                    2. При наличии достаточно подробного и расширенного по сравнению с GoClipse инструмента раскраски синтаксиса, был сильно удивлён тем что GoLand не делает различий между строкой и многострочной строкой. "" и `` соответственно. Хотелось бы чтобы появилась возможность покрасить код с такими строками в разные цвета.


                                    3. Нет возможности изменить цвет у файлов, скины меняются, все цвета изменяются, кроме цветов в именах файлов во вкладке "проект" и в табах открытых файлов. Почему?
                                      Это же портит механизм смены скина. И из за того что имена файлов только либо красные, чёрные или голубые весь внешний вид портится. Хотелось бы иметь возможность и этим элементам задать цвета.



                                    А в целом получился у вас редактор очень хороший, вы уже на пол шажка обогнали плагин GoClipse для эклипса. Так что так держать!


                                    Надеюсь на достигнутом вы не остановитесь, будите прислушиваться к пожеланиям разработчиков и сделаете идеальный IDE!

                                      0
                                      Возможно, это не решит все вопросы по цветовому оформлению, но всё же взгляните.
                                      www.material-theme.com
                                      P.S. В контесте подсветки Go я не проверял, но проект однозначно достойный. Многое из того, что там реализовано и отсутсвует из коробки — вызывает у меня недоумение.
                                        0
                                        1. Все так и работает, комментарии разделяются на эти три типа: директивы IDE знает сама, вторая группа от третьей отделяется введенной настройкой.
                                        2. Заведите, пожалуйста, реквест в нашем баг-трекере.
                                        3. Объясните, пожалуйста, какой смысл вы вкладываете в слово «скин».
                                          И да, на данный момент UI элементы (в том числе табики) нельзя кастомизировать. Но, можно как раз воспользоваться вышеупомянутым плагином: Preferences | Plugins | Material Theme UI.

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

                                      Самое читаемое