Ну что же, поставил я данный продукт, поигрался и готов поделиться впечатлениями. Во-первых сразу же скажу, что у меня были связаны с ним большие ожидания, т.к. в области полноценных C++ IDE выбор очень небольшой (собственно только 3 продукта и могут бороться за первое место) и у каждого варианта есть свои недостатки. А судя по уровню IDEA можно было надеяться на прорыв именно в самой проблемой области (анализатор кода и всё из него следующее). Так вот если кратко, то CLion в общем то оправдал надежды в этой области, но совершенно неожиданно показал дикие (настолько, что для нас этот продукт сейчас не пригоден к использованию) провалы в других областях, вроде как тривиальных.

А теперь по порядку. И начать я хочу с набора вроде как неважных мелочей, чтобы потом не отвлекаться на них при обсуждение принципиальных вещей. И так мелкие огрехи:

1. Сразу бросилось в глаза, что CLion не сообщает Windows о том, что он умеет сам нормально работать с нестандартным DPI. В итоге винда его масштабирует как картинку — получаем размытость, что очевидно неприемлемо для IDE. Очень странно видеть такое у вроде как солидного продукта, в то время как даже мелкие бесплатные утилитки работают корректно. Более того, если для 32-ух битного приложения Windows позволяет указать опцию "не масштабировать" в свойствах exe файла в Проводнике, то для 64-ёх битного кода эта возможность заблокирована (кстати, кто-нибудь знает обоснование этого странного поступка MS?) и надо идти добавлять специальную строку в специальное место реестра (про которое далеко не все знают). Ну т.е. я проблему преодолел своими силами, но в целом дико видеть такое в солидном продукте.
2. Захотелось открыть файл и сразу поразился диалогу для этого. Он не просто совсем не стандартный, но похоже что и ещё не умеет видеть сеть (или я не увидел где это включается?).
3. Про неудобные полосы прокрутки (в которые ещё фиг попадёшь мышкой) тут уже вроде писали. Впрочем иконки на тулбаре тоже крайне мелкие, но тут хотя бы только размера, а не форма.
4. А где локализация? ) Понятно что для программистов это вопрос совершенно не принципиальный. Но с учётом того, что даже мелкие бесплатные редакторы (типа Notepad++) имеют локазализацию (причём работающую по умолчанию), а во всех сравнимых конкурентах (Netbeans, Eclipse, Visual Studio) это уже давно работает, то несколько удивляет. Тем более, что уж для русской версии переводчиков точно не пришлось бы нанимать. )))

Кстати, замечу, что все вышеуказанные проблемы явно не связаны со спецификой C++. Интересно, а в других продуктах компании наблюдаются эти же проблемы или нет? Т.е. это предрелизные проблемы или вообще характерное для них? Я сам не в курсе, т.к. для нас у них раньше не было подходящих продуктов.

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

Однако подобный редактор — это ничто без анализатора кода (самой проблемой частью для C++). Здесь у нас к сожалению нет какого-то гениального прорыва (типа парсинга 100% компилируемого кода, что кстати вполне возможно с помощью того-же clang'а, но пока слишком медленно), но и провала нет. По охвату кода ситуация наверное как у лидеров, но при этом ещё и быстродействие чуть лучше. В целом получается как минимум на уровне, если не лучший результат. В принципе тоже безусловный позитив, хотя тут ожидания были несколько большими. Ну и надо отметить, что памяти оно отжирает больше того же Netbeans'a (Eclipse'а и VS+VA сейчас под рукой нет, чтобы сравнить), но думаю что для компьютера разработчика это правильный размен.

Ну а дальше я перешёл к изучению системы проектов и тут уже пошёл ужас — её просто не оказалось в IDE вообще. Ну точнее она вся перенесена в сторонний инструмент (чужую систему сборки cmake). Как я понимаю, авторы решили поддержать правильную точку зрения (которой некоторые IDE не соответствуют), что нормальный проект должен уметь собираться без всяких IDE (т.е. не должен быть завязан на настройки проекта из IDE). Я эту точку зрения полностью поддерживаю, но она совершенно не означает то, что сделали в CLion. Для этого достаточно всего лишь обеспечить удобную поддержку запуска произвольных сторонних систем сборки и всё! Отказываться от настроек проекта внутри IDE для этого не требуется. Т.е. авторы CLion вроде как пошли по правильному пути, но зашли по нему куда-то слишком далеко. В принципе такое решение может быть успешным, но только при одном принципиальном условие: если до первого релиза CLion будет поддерживать все известные системы сборки (например мы сейчас используем waf). Надеюсь автор данной архитектуры чётко понимает это? Ну и я что-то сомневаюсь что такое удастся, причём не столько из-за их количества (основных всего штук 15, хотя это тоже не мелкое число), сколько из-за сложности "парсинга" конфигов в некоторых случаях и большого различия в принципах. В целом мне данное решение видится провалом. Можно было сделать гораздо проще — сборку отдать профессиональным инструментам (реализовав удобный их запуск), а настройки проекта оставить только для нужных IDE опций (типа include каталогов для анализатора кода и т.п.). Кстати, я бы ещё может с трудом понял подобное, если бы в папке проекта кроме CMakeLists.txt не появлялось вообще ничего. Однако там появляется целая новая папка с кучей мусора (и почему-то именем ".idea", а не ".clion). Почему нельзя было разместить в ней нужные анализатору кода настройки, а не заниматься сексом с CMakeLists.txt для меня загадка.

Но ещё больше чудес открылось, когда я перешёл к сборке... И тут дело совсем не в её архитектуре. Ну да, cmake, не лучшая система сборки, но и далеко не худшая. Ну да, зашита намертво и поддерживается только она одна. Но это вроде как только пока и обещают изменить к релизу. Всё дело в том, как тут cmake используется! Оно зачем-то создаёт папки (да, не одну, а сразу 5: default, Release, Debug, RelWithDebInfo, MinSizeRel — зачем???) для построения cmake'ом не в каталоге проекта, а где-то в домашнем каталоге пользователя (типа ~\.clion10\system\cmake\generated\7c448f19\7c448f19\)! Мне вот интересно, а "гений", придумавший это решение, вообще понимает, что:
— это может приводить к потери быстродействия (диски с проектами и домашним каталогом могут быть не просто с разной скоростью, а вообще расположены в разных точках планеты)
— это может являться существенной дырой в безопасности (к примеру у нас важные проекты живут на криптодисках, а домашние каталоги пользователей со всяким повседневным хламом естественно без всякой защиты)
— банально неудобно доставить оттуда exe в итоге.
Причём главное что я не понимаю смысла этого гениального решения — какой вообще может быть аргумент в пользу подобного извращения? Да, а в какой-нибудь IDE такое вообще встречалось? Я вот что-то не припомню.

Кстати, я попробовал прикрутить нормальное построение (другим инструментом и в каталоге проекта) через External Tools. Кривизна конечно, но для предрелиза сойдёт. Вроде как всё нормально заработало. Но тут выяснилось, что без корректного CMakeLists.txt не работает анализатор кода (а без него уже смысла в IDE нет). Ну хорошо, поставил корректный файл, но убрал шаг build (из run/debug) и не нажимал его руками. И что вы думаете? Оно всё равно тут же сгенерировало все эти 5 папок с полным содержимым (да, кстати, забыл добавить, что там ещё зачем-то лежат сгенерированные проекты для codeblock — а они то зачем???) в домашнем каталоге... Даже не знаю что сказать на это всё.

Ну и напоследок об остальных компонентах, которые не произвели какого-то яркого (позитивного или негативного) впечатления.

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

Если подвести итог с оценками, то по моим ощущениям это выглядело бы так:
— Интерфейс: 3-4.
— Редактор: 5.
— Анализатор кода: 4-5 (выше 4 только за счёт скорости).
— Проекты: 3.
— Сборка: 1.
— Отладчик: 4.
— Интеграции: 4-5 (4 сейчас, а 5 думаю быстро станет после релиза).

Для сравнения покажу такую же свою оценку Netbeans'a (на мой взгляд самого оптимального инструмента сейчас, хотя Eclipse не далеко от него):
— Интерфейс: 4-5.
— Редактор: 4.
— Анализатор кода: 4.
— Проекты: 4.
— Сборка: 4.
— Отладчик: 4.
— Интеграции: 5.

К сожалению для нас из всего этого следует, что переход на новую более удобную IDE похоже не состоится...

P.S. Тут вроде как на форуме присутствовали люди из JB. Надеюсь они передадут это отзыв по назначению. Я всё же его писал не ради самой критики, а с тайной надеждой на чудо в будущем... )))