LINUX.ORG.RU

Gogland — новая среда разработки от JetBrains

 , , , ,


2

5

Компания JetBrains, известный производитель инструментов для разработки ПО, сегодня объявила о начале работы над новой интегрированной средой разработки Gogland, которая — как нетрудно догадаться — будет ориентированна в первую очередь на язык программирования Go.

Подробностей касательно функциональности нового продукта пока мало, но так как Gogland создаётся на платформе IntelliJ, можно ожидать качественного автодополнения кода, удобной навигации по проекту и подсветки ошибок «на лету».

Сейчас Gogland находится в раннем доступе; для получения сборки нужно оформить заявку.

>>> Анонс в блоге JetBrains

>>> Получить раннюю сборку Gogland

★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от Barracuda72

Всегда волновал вопрос: почему нельзя сделать одну IDE + плагины для языков, платформа-то одна?

Более того. Всегда мучаюсь выбором ставить:

Идея и отдельно пишарм или накатить плагин на идею

Еклипс джава и отдельно еклипс с++ и отдельно еклипс андроид или накатить в одну эклипс + плагины

Нетбинс джава и отдельно нетбинс с++ или один нетбинс с плагинами

И в каждом случае на сайте предлагают этот выбор. Что скачать-то, если мне нужен еклипс джава, с++, андроид. А на сайте только по отдельности?

anonymous ()
Ответ на: комментарий от env

и так понятно, нужно развивать память

Это, к слову, вообще проблема языка. Функции в языке должны иметь понятные и предсказуемые названия, тогда комплит становится не очень-то нужен. Вот в пхп предсказать названия функций практически нереально, там могут соседствовать функции 2upper, to_lower и convertToString, потому что макаки. А в окамле есть очень строгие правила именования, и практически все им следуют, потому легко предсказать, как называется функция.

Freyr69 ★★★ ()
Ответ на: комментарий от env

Зачем «нормальному» программисту что-то автоматизировать?

Я бы сказал, что IDE скорее препятствует автоматизации, чем помогает ей. Средства автоматизации в IDE, как правило, ставят безальтернативный выбор: либо ты ими пользуешься, как есть, ничего не трогая, либо ты полностью предоставлен сам себе и IDE превращается в редактор с подсветкой и набором кнопочек «запустить внешнее приложение». Промежуточный вариант в виде отваливающегося непонятно чего непонятно где непонятно почему при попытке настроить то, что тебе нужно так, как тебе нужно, встречается реже и тоже особой радости не добавляет.

Barracuda72 ()
Последнее исправление: Barracuda72 (всего исправлений: 1)
Ответ на: комментарий от env

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

anonymous ()
Ответ на: комментарий от mironov_ivan

Не, оно бесплатное и пилится не джетбрейновцами. Вот когда они его форкнут, «перепишут» и сделают платным...

java_util_Random ()
Ответ на: комментарий от Oxdeadbeef

irony-mode

Мужи-ик! Спасибо, что подсказал.

Hertz ★★★★★ ()
Ответ на: комментарий от paran0id

Нужно больше IDE

IDE не нужны, когда есть редактор TEA c блекджеладами и унитазами!

anonymous ()
Ответ на: комментарий от DeVliegendeHollander

В последние лет 25-30 — да.

А ты не слишком перегнул с цифирью?

- QBasic — 1991 (25 лет)
- Borland C++ — 1991 (25 лет)
- Turbo C — 1987 (29 лет)
- Turbo Pascal — 1983 (33 года)
- ZX Basic — 1982 (34 года)

:)

KRoN73 ★★★★★ ()
Ответ на: комментарий от intelfx

Предположим, вы правы - тормозит.

Но что, обладающее схожей функциональностью, под linux не тормозит?

anonymous ()

Название жесть, при всем уважении к jetbrains

Был бы я фанатом golang то такой продукт назвал бы GodLang а не Gogland

crono ()
Ответ на: комментарий от DeVliegendeHollander

Если поделить на 2, получится срок существования «IDE for everything and nothing in particular».

tailgunner ★★★★★ ()
Ответ на: комментарий от intelfx

По моим кратким наблюдениям, статический анализ кода в KDevelop показывает меньше ложных ошибок только потому, что и не пытается делать анализ многих элементов синтаксиса, которые CLion анализирует неправильно (что неудивительно в C++). Впрочем, если он хотя бы говорит variable assigned, but never read и read of uninitialized variable, то возьму свои слова обратно.

Нет, мои жалобы на тормоза не связаны с количеством RAM. Тормозит оно всегда.

Значит, код на С++ бывает очень разный. Если речь о других IDE, то интересно услышать, что же они делают медленно, и сколько это - медленно.

О темах - Впечатляет. Честно. При этом желаю успехов в поддержании этих супер-тем оформления спустя 5 компьютеров и 8 операционных систем, я давно забил и приучил себя работать на дефолтах.

yrs ()
Ответ на: комментарий от yrs

По моим кратким наблюдениям, статический анализ кода в KDevelop показывает меньше ложных ошибок только потому, что и не пытается делать анализ многих элементов синтаксиса, которые CLion анализирует неправильно (что неудивительно в C++).

Эти наблюдения во многом верны по состоянию на год назад. Сейчас KDevelop использует clang для анализа кода, поэтому он говорит всё, что умеет обнаруживать clang.

Впрочем, если он хотя бы говорит variable assigned, but never read и read of uninitialized variable, то возьму свои слова обратно.

...в том числе и это.

Значит, код на С++ бывает очень разный. Если речь о других IDE, то интересно услышать, что же они делают медленно, и сколько это - медленно.

Я говорю больше не о скорости анализа кода, а об общих впечатлениях. В частности, сюда входит визуальная отзывчивость UI и прочие подобные вещи.

А самому анализу кода необязательно быть сверхбыстрым, если IDE умеет «применять» результаты старого анализа к новому тексту, пока последний ещё анализируется.

При этом желаю успехов в поддержании этих супер-тем оформления спустя 5 компьютеров и 8 операционных систем

Ну, я надеюсь, что GNU/Linux не загнётся и мне не придётся менять операционную систему. А компьютеров может смениться (и уже сменилось) сколько угодно.

я давно забил и приучил себя работать на дефолтах

В каком-то смысле я даже завидую. Слишком сильно привык к своему «уютному сетапу».

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Zenom

Смутно помню как минимум то, что текст и контролы масштабировались 1) недостаточно (т. е. были слишком мелкими) и 2) неравномерно (т. е. много где текст выезжал за границы контролов, или наоборот). Ещё были какие-то проблемы с самим редактором и текстом в нём. Остальное уже забыл, т. к. смотрел ровно один раз ~год назад.

Если это с тех пор починили — хорошо.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от env

Для определенных языков просто нельзя нормально сделать комплит, он все равно будет неидеален - например для динамически типизируемых ЯП. Там и живется нормально на каком-то vim, который конкретно текст редактирует очень хорошо

vertexua ★★☆☆☆ ()
Ответ на: комментарий от env

Ну ты сильно загнул. Например, мои задачи, к сожалению, Clion не вывозит от слова совсем. QtC вывозит.

На одном проекте архинеобходимы удобные средства удалённой отладки контроллера с загрузкой кода по JTAG + возможность набить несколько билд конфигураций для CMake. Clion удалённую отладку умеет с недавних пор.... но это какая-то залепа, сделанная на от...сь. Да и для Baremetal непригодна от слова совсем. Кроме того, билд конфигурацию он умеет ровно одну на проект, смена - полный релоад проекта.

Другой проект отличается огромным числом файлов в дереве, что-то около 280 тыс. Да многие их них не относятся к исходникам или используются для отстройки смежного кода. На открытие этого безобразия Clion (на Windows), при условии расположения этого добра на SSD, тратит около 15 минут времени. Да, релоад проекта при смене билд-конфигурации требует столько же. А вот QtC под Linux в виртуальной машине с обычного HDD диска уходит около минуты (плагин для Cmake кастомный с загрузкой всего дерева). При этом хост машины идентичные. Только на машине с QtC 8 гигов памяти (виртуалке отдано 3), а на машине с Clion - 16. Потребление памяти не мерял на CLion, но у QtC что-то около 500Мб после часа работы (QtC + clangbackend).

По качеству редактирования, рефакторинга, генерации кода и навигации... Тут как бы Clion хорош, если бы нормально всегда парсил. На некоторых конструкциях он просто начинает недоумевать, причём в минимальном примере - проблем нет. QtC тоже не ангел, но у него есть мониторилка парсера, иногда можно понять, что не так и вменяемо репорт отписать или хлопнуть по лбу и исправить в настройках Kit/Toolchain. Так что в сухом остатке, то на то и выходит. Хотя QtC постепенно вылизывает свой clangbackend и уже рефакторинги некоторые через него тоже могут работать.

Поддержка CMake: QtC временами уже лучше Clion. Например в части редактирования опций и поддержки Server mode (cmake >= 3.7). А в части добавления файлов к таргетам - хуже, точнее никак (по понятным причинам никто не хочет писать парсер CMake, Тобиас очень надеется на появление средств редактирования в Server mode, я не так оптимитичен). При этом, было замечено, что Clion тоже генерирует CodeBlocks проект. Вот для чего - понятия не имею. QtC для построения списка таргетов и настройки кодовой модели именно его использует. Может Clion тоже? :)

Ещё нюанс - поддержка нескольких компиляторов. Среда от JB тут мало отличается от просто текстовых редакторов. Да, компилятор можно задать через тулчейн файл CMake. И среда даже может всосать его и настройки... Если он совместимый с Gcc. QtC умеет компилятор и от M$ брать.

Проекты. Для Clion, для не CMake-проектов нужно необходим враппер. QtC позволяет использовать любую билд систему при помощи Generic Project Manager. Но тут есть свои нюансы, влияющие на качество парсинга и разбора символов. Но: а) не всегда это критично, б) самое оно для «быстро открыть и поработать». Для длительной работы с кодом тоже желателен враппер/генератор в qmake/qbs/cmake: хотя бы разложить исходники по таргетам и не путать часть для контроллера и часть для десктопа.

В общем, за Java не скажу, а вот для C++ среда от JB очень сырая. Хотя посматриваю за её развитием. Но в данный момент времени, не уверен, что она стоит своих денег. Для меня QtC тоже не совсем бесплатен: я чуточку в него контрибучу. Исправляя мешающие мне косяки. Т.е. плачу своим временем.

h4tr3d ★★★★★ ()

Лучше бы CLion плагин сделали для Community Edition, а то тот который есть слишком тупой (только подсветка, даже не выравнивает по Ctrl+Alt+L)

anonymous_sama ★★★★★ ()
Ответ на: комментарий от SergikXP

Ты просто ничего не делаешь... Начни на нём писать.

:)

код проекта так же загружается в голову как часто-то используемые файлы в кеш файловой системы. На новом проекте IDE очень сильно помогает, но через некоторое время уже начинаешь писать быстрее автокомплита. Ну и рефакторинги. Иногда использую первый попавшийся под руку редактор (vim, nano, mcedit, xed/gedit/pluma) и правлю код в нём.

h4tr3d ★★★★★ ()
Ответ на: комментарий от env

Расскажи, придурок, что сегодня в моде, а у нас сегодня будут бить по морде! ©

Как раз чем приличнее компьютер, тем неприличнее нагружать его вычислительные мощности всяким жетбрейнсовским барахлом. А платить за это барахло - вообще верх ламеризма.

Собственно, такое тупое ламерьё типа env и распинается на протяжении всего треда, совершенно игнорируя принцип, который был сформулирован ещё сами знаете кем в 2005 году:

There’s only really one metric to me for future software development, which is — do you write less code to get the same thing done?

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

Вопреки высказанным за последние 3 страницы предположениям о том, что я понятия не имею о современной энтерпрайз-разработке, я с этой парашей сталкиваюсь каждый рабочий день. Собственными глазами вижу нарушения вышеуказанного принципа, когда для совершенно элементарных вещей жабомакаки пытаются впендюрить больше кода и наворотить больше слоёв на ровном месте. Естественно, так называемые IDE им в этом только помогают, но от того, что часть кода автогенерируется, самого кода меньше не становится. Сама по себе жаба, в которой каждый чих надо в класс оборачивать, вообще является эталонным примером создания проблем на ровном месте и затем героического их преодоления, частным случаем которого как раз и является необходимость использования IDE-костылей, чтобы или написать что-то побыстрее, или разобраться в чужой писанине.

Так не должно быть. Такая херота (C, C++, C#, Java, PHP) не имеет права называться «высокоуровневой». Она должна или перекочевать в разряд нео-ассемблеров (как это сейчас происходит с ES5), или вообще отправиться на свалку истории. Программисты не должны непосредственно писать на этом дерьмище. Реально высокоуровневым языкам IDE не нужны.

anonymous ()
Ответ на: комментарий от JAkutenshi

Тебе, ламеру, новую планку памяти поставили? Кодь быстрее, солнце ещё высоко. Больше бойлерплейтов, больше обёрток, больше писанины в билдфайлах, больше вербозности для рандомных индусов! Давай, за дядю, за ЫНТЫРПРА-А-А-А-АЙЗ!!!1111

anonymous ()
Ответ на: комментарий от DeVliegendeHollander

в случае intellij это, скорее, одна IDE с кучей плагинов, которые они продают уже установленными. Но, в целом, это практически unix-way - для каждой задачи свой инструмент:)

wingear ★★★★ ()

жыдоМозги опять обосрались. Пришел к ним хипстор и рассказал что го - это круто

TooPar ()
Ответ на: комментарий от anonymous

Ставлю полвеба за то, что ты еще и левачок. На самом деле мне больше всего отвратительно даже не твое лебезенье по отношению к JS (уверен, ты из штанишек выпрыгивал, видя как «не ламеры» делают эмулятор терминала на электроне), а откровенную чушь, которую ты несешь, кроме как психиатрии тут не на что списывать: C++ и Java, языки с разительнейшими подходами ты сваливаешь в одно, предлагая назвать «неоассемблером»; топишь за текстовые редакторы, не отдавая себе отчет в том, что с кучей плагинов, которые доведут до примерного уровня IDE, они будут лагать так же; твоя блажь про «автокомплит» не нужен, все от ламеров лукавого, и только про будут рефакторить ручками, рискуя в банальном переименовании переменной сделать 100500 ошибок, не говоря о той куче автоматизации по настройке и развертке приложений, которые делают IDE вместо тебя, экономя тонну времени. Но это же все для ламеров. Нет, не пойми не правильно: знать, как это происходит изнутри - надо. Один-два раза сделать. А когда надо работать и писать код, идет в ход автоматизация процессов, ибо время-деньги. Тру чуваки даже гагс оф фо не читают, ибо сами смогут все шаблоны сходу придумать и написать идеально, да? И учиться не надо - все можно нагуглить же (через w3m, я угадал?). И что еще смешнее, как ты всем пытаешься доказать какой ты гуру, что и крутые Си проекты пишешь, и в энтерпрайзе работаешь. Чудеса да и только.

JAkutenshi ()
Ответ на: комментарий от JAkutenshi

ты еще и левачок

ты так говоришь, как будто это что то плохое

TooPar ()
Ответ на: комментарий от JAkutenshi

Ставлю полвеба за то, что ты еще и левачок.

Гони полвеба, я ультраправый.

твое лебезенье по отношению к JS

Лебезенье? Это всего лишь инструмент (причём в своих старых версиях далеко не самый подходящий, но кросскомпиляторы нам в помощь), какое нафиг лебезенье?

C++ и Java, языки с разительнейшими подходами ты сваливаешь в одно, предлагая назвать «неоассемблером»

С точки зрения нужды в так называемых IDE они друг от друга ничем не отличаются. Подход может быть каким угодно, но более высокоуровневым язык это не делает.

что с кучей плагинов, которые доведут до примерного уровня IDE

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

и только про будут рефакторить ручками, рискуя в банальном переименовании переменной сделать 100500 ошибок

Переменные надо называть так, чтобы они назывались читабельно, трактовались однозначно и их можно было переименовать одной заменой на документ или блок.

не говоря о той куче автоматизации по настройке и развертке приложений, которые делают IDE вместо тебя, экономя тонну времени.

У меня этим Ansible и/или докерфайлы занимаются, зачем какое-то IDE приплетать к абсолютно не относящимся к написанию кода задачам?

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

Ещё раз, дурилко картонное, при чём здесь костыли к реальной автоматизации?

И учиться не надо - все можно нагуглить же (через w3m, я угадал?).

Ты меня с кем-то путаешь, мне последнего фокса с VimFx достаточно.

И что еще смешнее, как ты всем пытаешься доказать какой ты гуру, что и крутые Си проекты пишешь

Нет, точно путаешь. Си я не касаюсь уже лет так 8-10.

anonymous ()
Ответ на: комментарий от h4tr3d

При этом, было замечено, что Clion тоже генерирует CodeBlocks проект. Вот для чего - понятия не имею.

Разве? Раньше такого точно не было. Когда появилось?

Тут как бы Clion хорош, если бы нормально всегда парсил.

А ты не в курсе, будут ли они на Clang переходить? То, что сейчас юзается в CLion для парсинга С++, это Java-овский ANTRL, мегатормозной и вечно отстающий.

А так да, солидарен с тобой, после молниеносного Qt Creator, 20-минутный парсинг 300К C++-проекта на i7-3930K/32GB RAM/SSD выглядит просто издевательски со стороны CLion.

EXL ★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от yrs

ВНЕЗАПНО адекваты в треде. Два чая этому господину.

У самого IDEA отлично себя показывает на OS X/Retina, на 4k мониторе воткнутом в эту OS X/Retina, на Surface Pro 4 (3k монитор), на том же Surface Pro 4 воткнутом во все тот же 4к монитор и на dell xps 15 под бубунтой воткнутой во все тот же 4k монитор (а еще у 5 соседей на таких же 4к мониторах с dell xpx 15). Что ж мы все делаем не так?

DiKeert ()
Ответ на: комментарий от EXL

сейчас юзается в CLion для парсинга С++, это Java-овский ANTRL, мегатормозной и вечно отстающий

Откуда такая информация про ANTLR? У них же вроде давно свой фреймворк для парсинга всего подряд в свое внутреннее представление, на котором все фичи вроде compeltion/refactoring сделаны.

kamre ★★★ ()
Ответ на: комментарий от intel

VsBydloCode. По ссылке - типичная жертва IDE и унылого языка из прошлого.

anonymous ()
Ответ на: комментарий от tailgunner

И это тоже. Но суть даже не в нём, а в том, что то, что эта простыня делает, можно сделать гораздо более читаемым (даже без подсветки синтаксиса) кодом:

setup-acc: does [
  system/user/email: herzavalish@example.com
  system/schemes/esmtp/host: "smtp.example.com"
  system/schemes/esmtp/port-id: 25
  system/schemes/esmtp/user: "herzavalish@example.com"
  system/schemes/esmtp/pass: "lohopassword"
]

true-mail: func [subj addr-from send-to cc-to bcc-to msg /local header][
  header: make system/standard/email [
    from: addr-from
    to: replace/all form send-to " " ", "
    cc: replace/all form cc-to " " ", "
    subject: subj
  ]
  send/header join join send-to cc-to bcc-to msg header
]

setup-acc
true-mail "C++ suxx"
	 herzavalish@example.com
         [lorsux@mailnesia.com] ; TO list
         [lor-user-1@mailnesia.com bomzh@gmail.com] ; CC list
         [hidden-addressee@mailnesia.com] ; BCC list
	 "This is the true high-level language"

И для запуска этого кода достаточно одного-единственного бинарника интерпретатора, который в 64-битном варианте под Linux весит меньше 450 КБ и не имеет в зависимостях ничего, кроме eglibc:

$ du -b rebol 
448024	rebol
$ ldd ./rebol 
	linux-vdso.so.1 =>  (0x00007ffd425bc000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0b3b52b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0b3b164000)
	/lib64/ld-linux-x86-64.so.2 (0x0000559b8244d000)
$ ./rebol
REBOL/Core 2.7.8.4.10 (23-Jan-2016)

Согласитесь, IDEрасты, есть над чем задуматься.

anonymous ()
Ответ на: комментарий от anonymous

Согласитесь, IDEрасты, есть над чем задуматься.

Совершенно не о чем. Был бы ты прогером - понял бы.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Был я прогером. В том-то и дело. И сейчас непосредственно с оными взаимодействую и вижу тот трэш, угар и содомию, который у них творится.

А чем, собственно, смущает этот код? Тем, что ребол не опенсорц? Есть такой недостаток, да (хотя клозед-сорц там толко самое-самое ядро, исходники остального, в том числе и реализации ESMTP, можно посмотреть соответствующими вызовами). Ну так дождёмся допила Red - будет нам опенсорц с кросс-компиляцией, нативным гуем, юникодом, реактивщиной, блэкджэком и макросами. Но, несмотря на всё это, он по-прежнему не будет требовать стопицот мег рамы для рантайма и жабоидного монстра для разбора кода. Так что думайте сами, решайте сами, эффективно программировать или просиживать штаны, колупаясь в идеевских менюшках.

anonymous ()
Ответ на: комментарий от anonymous

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

pztrn ★★★★ ()
Ответ на: комментарий от anonymous

Был я прогером

Наверное, это было давно, и ты уже забыл, что такое «библиотека».

А чем, собственно, смущает этот код?

Ничем. Только он не катит в качестве доказательства ненужности IDE. Ну, есть у какого-эзотерического языка библиотечная реализация имейл-клиента - и что с того? Ровно ничего.

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

IDE не мешает эффективному программированию.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Наверное, это было давно, и ты уже забыл, что такое «библиотека».

Любая библиотека, кроме стандартной - просто вынос сложности в другой модуль, а не устранение этой самой сложности.

Ничем. Только он не катит в качестве доказательства ненужности IDE. Ну, есть у какого-эзотерического языка библиотечная реализация имейл-клиента - и что с того? Ровно ничего.
эзотерического

Вот это предъява. Вот это троллинг 90 лвл. Да будет тебе известно, что синтаксис языка, который ты только что, даже не попытавшись разобраться в вопросе, назвал эзотерическим, как раз и является залогом того, что там и без IDE, автокомплитов, подсветки и прочих костылей всё понятно на любом объёме кода. Естественно, для этого надо пару манов прочесть, но это для любого языка так.

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

anonymous ()
Ответ на: комментарий от tailgunner

Ах да, совсем забыл

IDE не мешает эффективному программированию.

IDE создаются для языков, на которых эффективно программировать невозможно в принципе. Было бы возможно - не нужно было бы столько подпорок.

anonymous ()
Ответ на: комментарий от anonymous

синтаксис языка, который ты только что, даже не попытавшись разобраться в вопросе, назвал эзотерическим, как раз и является залогом того, что там и без IDE, автокомплитов, подсветки и прочих костылей всё понятно на любом объёме кода

всё понятно на любом объёме кода

Ну окей. Удачи в покорении мира.

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

Что к чему? Я про редакторы, ты непонятно что толкаешь.

intel ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.