Для своей работы IDE использует Resharper, который запускается в отдельном процессе, и служит в качестве бэкенда для редактора кода. IDE поддерживает .NET Framework, Mono и DNX/CoreCLR, и работает на платформах Windows, Mac OS X и Linux. Сообщается, что выход данного продукта связан в том числе и с движением Microsoft в сторону Open Source, а также, с растущей популярностью альтернативных платформ в мире .NET.
Предполагаемая дата релиза — осень 2016 года, но пользователи получат возможность протестировать продукт раньше, воспользовавшись Early Access Program.
Комментарии (139)
musuk
13.01.2016 19:50+18Думаю, что суть в том, что в VS нелья отключить встроенный анализатор кода. Потому в 32-битной VS сейчас тупят и Resharper и Roslyn. Видимо JetBrains не договорились с MS, вот и решили строить свой лунапарк. Собственно, давно пора, а то я уже не знаю какой компьютер нужно купить, чтобы не видеть
Razaz
13.01.2016 22:39+1Два сетапа:
I5 Second Gen, SSD, 16GB мозгов.
I7 Second Gen, SSD, 16GB мозгов.
Проект на обычном hdd. Кеш решарпера на SSD и студия там же.
Такое обычно при работе с git Только, когда между брэнчами переключаюсь и то редко.
Обычно запущено около 3 студий.
Хотя в 15 конечно потормознутее стало :( Плюс она темы портит.
Athari
13.01.2016 22:57+3Подозреваю, что немного не так. Из-за тупления решарпера и рослина в студии пришлось выносить решарпер в отдельный процесс. А если выносить решарпер в отдельный процесс, что бы за компанию не прикрепить его практически на халяву к собственной идее? На винде конкурировать со студией идея не может: всякие UWP и прочий зоопарк проектов идея поддерживать не будет, впрочем при зоопарке немелкомягких технологий и очень ограниченном использовании мелкомягких какая-то небольшая конкуренция может быть. Это всё имеет смысл для линукса, где кроме монодевелопа и игрушек типа атома ничего нет, но на линуксе и студии, собственно, нет. Так что ссоры с МС и даже поводов для неё я не вижу. Джетбрейнс пытается занять пустую нишу, по сути.
mird
14.01.2016 23:44+3Вы бы почитали что авторы пишут. Отдельный процесс решарпера там потому что IDE на Java. Они не захотели портировать решарпер на Java. Поэтому отдельный процесс и обмен с помощью бинарного протокола.
Athari
15.01.2016 00:38Вы бы почитали, что авторы в других статьях пишут. ;) У них дотнетовый решарпер в VS 2015 умирает под нагрузкой до такой степени, что они сами им пользоваться не могут. Невозможность использования решарпера на больших проектах в VS 2015 — согласитесь, гораздо более серьёзная проблема для джетбрейнс, чем возможность писать консольные приложения на шарпе под линуксом в крутой IDE. :) И все эти «оптимальные бинарные протоколы» тоже произрастают из проблем с ресурсами в VS.
nerzhul
15.01.2016 01:42+2Вы уверены, что в VS 2015 умирает Решарпер? Умирает студия изза недостатка свободной памяти, которую очень хорошо выжирает «новый модный» Roslyn. Изза этого начинает работать Blocking GC, который тормозит UI поток студии. Решарпер тоже поедает память, хотя и не сильно много, но по крайней мере в нем нет кода подобного while (freemem < 300 * 1024 * 1024) { GC.Collect(); Thread.Sleep(100); }, а в студии есть.
Rider (работающий на решарпере), открывает солюшен ~300 проектов примерно в 2 раза быстрее, чем это делает студия. И во время открытия можно без проблем тайпить в документе в отличие от студии.
Для интереса, найдите солюшен в 300-400 проектов, откройте его в VS2015 и попробуйте найти наследников какого-либо часто наследуемого класса (с колвом наследников от 50), после этого студию с ее «инновационным» рослином придется убить
a553
15.01.2016 02:02-2Извините, но вы не правы.
nerzhul
15.01.2016 18:57+4Извините, но я разрабатываю решарпер около 3 лет и профилировал студию вместе с ним не одну сотню раз и знаю, о чем говорю. И сейчас я разрабатываю Райдер и тоже знаю, о чем говорю, сравнивая скорость работы студии и решарпера на одинаковых проектах. Решарпер далеко не идеален, но в студии гораздо более серьезные факапы, которые никто не собирается фиксить и на которые мы никак не можем повлиять, даже имея прямой контакт с разработчиками студии, слишком много бюрократии у MS. Я всего лишь пытаюсь возразить, что тормоза в студии с включенным решарпером далеко не всегда по вине самого решарпера, а по вине нехватки памяти в 32битном процессе. Если вам хорошо на Рослине, удалите решарпер и живите на рослине, однако на 300 проектах, рослин помирает и без решарпера. А если пользователь привык к решарперу, то выкат VS2015 вставляет ему большие палки в колеса изза невозможности отключить рослин и жить только с решарпером.
a553
15.01.2016 20:49-5А я больше лет пользуюсь решарпером, и знаю, где тормозит решарпер, а где студия. И с вашей компанией я это обсуждал много раз, но отчаялся и теперь перехожу с решарпера на более эффективные инструменты.
nerzhul
16.01.2016 01:47А можно подробнее про вашу проблему, которую вы много обсуждали с нашей компанией. Действительно интересно.
a553
16.01.2016 01:50nerzhul
16.01.2016 03:03+2Отвечу отдельно по всем:
1) RSRP-448070 «Find Usages» speed depends on how common the name of searched item is
Да, это действительно так, множество файлов поиска зависит от того, какой идентификатор ищется. Т.е. если идентификатор Type встречается в 1000 файлах, то действительно поиск пройдет по всем этим файлам (конечно, если эти файлы достижимы по проектным зависимостям).
Я сейчас специально провел эксперимент, сделал поиск идентификатора Language, который встречается десятки тысяч раз в нашем проекте, с помощью решарпера и с помощью студийного поиска (который видимо уже на рослине):
а) Рослин — 1мин 3секунды, потребление памяти возросло на 800мб, блокирует на все время поиска окно студии
б) Решарпер — 28 секунд, потребление памяти возросло на 150мб, ищет асинхронно, можете делать параллельно, что угодно
Что же вам удобнее?
2)RSRP-447915 Opening «Add New Item» on a folder spins 1 CPU core 100%
Вам показали стектрейс, в котором явно видно, что факап студии. Да он возникает изза нехватки памяти, но это один из тех кусков кода, где в цикле вызывается GC.Collect(). (и такой кусок не один в студийном коде)
Как нам с этим бороться? да, мы пытаемся экономить память, но судя по всему, только мы этим и занимаемся
Кстати сам натыкался на этот факап много раз
3) RSRP-446534 «Find code dependent on module» freezes main VS window
Вероятно наш продолб, отрицать не буду. Просто редко использую эту фичу, сам не натыкался
4)RSRP-447853 Opening R# IntelliSense is a CPU-bound operation that does not scale with project size
Не отрицаю, что проблема есть, но сам не смог воспроизвести. Комплишен поднимается всегда. R# 10.0.2
5)RSRP-447916 Pasting anything into ascx/aspx files hangs VS for 20 seconds
Вроде бы вы вместе разобрались, что это баг не решарпера, и вопроизводится без решарпера вообще.
Т.е. из тех 5 перформанс проблем, что вы зарепортили, действительно наших — две, и по обеим из них вроде бы вы даже получили ответы.a553
16.01.2016 03:56Опять двадцать пять.
Что же вам удобнее?
В кейсе написано, что у меня R# медленнее раз в 100-1000. Про асинхронность тоже не совсем правда — CodeLens полностью асинхронный, а поиск решарпера заметно больше тормозит студию, потому что использует в 4 раза больше потоков, и периодически самоотменяется («Find Usages has been canceled» или что-такое). Может быть под поиском рослином вы что-то другое имеете ввиду, о чём я не знаю?
Вам показали стектрейс, в котором явно видно, что факап студии. Да он возникает изза нехватки памяти, но это один из тех кусков кода, где в цикле вызывается GC.Collect(). (и такой кусок не один в студийном коде)
Потребление памяти 1 ГБ и растёт, а не уменьшается. Без решарпера не повторяется.
но сам не смог воспроизвести
Там есть видео.
Все 4 открытых кейса мне кажутся именно проблемами решарпера, а не студии.
Вот вы говорите, что вам памяти не хватает. Вместе с или около выхода Rider же будет релиз out-of-process R#? Давайте поспорим, что не станет out-of-process R# и/или Rider быстрее, даже если ему дать, скажем, 10 ГБ памяти? Если оно будет хотя бы сравнимо по скорости с VS 2015 (или какая там будет на тот момент), то я куплю/продлю персональную лицензию и всерьёз рассмотрю возможность поддержки R# и/или Rider в компании. (Дополнительное требование для Rider — чтобы это была настоящая замена VS без очевидных шоустопперов, с поддержкой MSBuild, с возможностью удалённого дебага, интеграцией с git, поддержкой веб-языков хотя бы без on-save компиляторов и большинством фич R#)
Потому что ну вот не верю я, что все ваши проблемы связаны с нехваткой памяти. Как-то же CodeLens умудряется влезать в 275 мегабайтов памяти (пусть и в отдельном процессе) и при этом мгновенно искать референсы по всему солюшену.nerzhul
16.01.2016 06:31В кейсе написано, что у меня R# медленнее раз в 100-1000. Про асинхронность тоже не совсем правда — CodeLens полностью асинхронный, а поиск решарпера заметно больше тормозит студию, потому что использует в 4 раза больше потоков, и периодически самоотменяется («Find Usages has been canceled» или что-такое). Может быть под поиском рослином вы что-то другое имеете ввиду, о чём я не знаю?
Я подождал 3.5 минуты для того, чтобы codelens показал мне кол-во ссылок на проперти Language. Это на машине core i7, 32gb ram. Впечатляющая производительность. Особенно если мне нужно найти референсы 5-10 раз подряд на разные символы. А в предыдущем комменте я говорил про экшн студии Find all references.
Потребление памяти 1 ГБ и растёт, а не уменьшается. Без решарпера не повторяется.
Так что из этого? Тормоза то, которые вы видите, порождаются от GC.Collect()
Потому что ну вот не верю я, что все ваши проблемы связаны с нехваткой памяти. Как-то же CodeLens умудряется влезать в 275 мегабайтов памяти (пусть и в отдельном процессе) и при этом мгновенно искать референсы по всему солюшену.
см. выше
Если оно будет хотя бы сравнимо по скорости с VS 2015 (или какая там будет на тот момент), то я куплю/продлю персональную лицензию и всерьёз рассмотрю возможность поддержки R# и/или Rider в компании
оно быстрее студии уже на данный моментnerzhul
16.01.2016 06:40Я ни разу вас не уговариваю уйти со студии. Если вам хорошо разрабатывать в студии, то это отлично. Просто не стоит в каждом фризе студии винить решарпер, есть куча причин по которым оно может тормозить, но, я заметил, пошла такая мода, в случае любого подвисания студии все стрелки переводить на «тормозной убогий решарпер»
a553
16.01.2016 06:42Я ни разу вас не уговариваю уйти со студии. Если вам хорошо разрабатывать в студии, то это отлично. Просто не стоит в каждом фризе студии винить решарпер, есть куча причин по которым оно может тормозить, но, я заметил, пошла такая мода, в случае любого подвисания студии все стрелки переводить на «тормозной убогий решарпер»
А какой реакции вы ожидаете, когда без решарпера всё летает?
оно быстрее студии уже на данный момент
ОК, ждём
Athari
15.01.2016 03:04+2По-моему, это просто называется «вместе не уместились», и искать крайнего — бесполезное занятие.
Ну а сравнивать оптимизации решарпера и рослина, учитывая, сколько каждому из них лет — это неспортивно.musuk
15.01.2016 14:46Microsoft на захотели сделать галку для отключения рослина. Так что крайний тут очевиден.
creker
15.01.2016 14:54+3А с чего им это делать вдруг?
gorohoroh
15.01.2016 16:10Ну я даже не знаю. Может быть, потому, что по разным оценкам от 10% до 20% пользователей студии используют решарпер?
creker
15.01.2016 21:18И теперь наверняка начнет падать, потому что рослин много чего умеет сам. Крайний в любом случае решарпер. Продукт свой МС вольна делать так, как захочет. Хочется улучить анализ кода своими силами — их право, пользователи только в выигрыше. Ведь основная часть аудитории таки решарпером не пользуется.
Athari
15.01.2016 16:46Я так понимаю, на этот рослин в студии много чего завязано, и будет завязано ещё больше. Разные расширения от него зависят. Предлагаете мелкомягким реализовывать фичи в двух версиях: через рослин и через решарпер? Вы фантазёр.
nerzhul
16.01.2016 01:50Предлагается предоставлять опцию отключить рослин и все фичи, зависящие от него. Редактировать документ можно и без рослина. Подчеркну — это только для тех, кому роднее фичи решарпера. Однако, такой опции никто не предоставил.
Athari
16.01.2016 01:57+1Не знаю, как конкретно сейчас реализовано, но могу предположить, что дизайнеры форм для WPF и WinForms, окошко с иерархией классов, всякие выпадающие списки с членами и ещё 100500 вещей могут зависеть от рослина. Не зависят сейчас — будут зависеть в будущем.
А теперь берём и отрубаем рослин. Отрубать все зависящие фичи? Вы уверены, что вы на это согласитесь?
creker
16.01.2016 17:24И вряд ли предоставит. Студия это не конструктор для сообщества. Это самодостаточный продукт. Рослин всяко внедрен в систему настолько, что отключить просто так его не получится. А делать это ради решарпера… Пусть решарпер вот и крутится, он плагин. Не может — его проблема. Делайте свою IDE. Мне понятна сторона разработчика плагина, что ему все мешает, но это абсурд.
mird
15.01.2016 18:31Угу. поэтому, видимо, вынесение решарпера в отдельный процесс решит проблему с кончающейся памятью? Я, если что, тоже работаю с решарпером на большом проекте (около 100 проектов в солюшне). И основная проблема там в недостатке памяти.
kekekeks
15.01.2016 21:25Оно по крайней мере не будет упираться в 32-битное адресное пространство, в котором живёт студия.
EpeTuK
15.01.2016 07:17ну если еще плагинчик для Vala (с поддержкой GTK) под линуксовую версию напишут, то цены джетбрейнсу действительно не будет
denismaster
13.01.2016 20:07+11Раньше Visual Studio была самой лучше IDE для C#, сейчас в игру вступают JetBrains с их опытом… Это будет интересно)
rauch
13.01.2016 23:14-29с опытом из более правильного мира Java, вы хотели сказать
Valery4
14.01.2016 10:20+9Наверное это будет неожиданно. Но у JetBrains есть опыт разработки IDE для Python, Ruby, PHP, JS и С++. И многие из них являются, практически, стандартами индустрии.
rauch
14.01.2016 10:35-40И все они появились на фоне опыта Intellij IDEA
Вы готовы аргументированно спорить, а не верещать?
//и да, «более правильного» было для остроты сказано… как бобмануло-то у вендовозниковGorniv
14.01.2016 10:51+4честно говоря не совсем понятно как связан мир Java и IDE? Visual Studio отличный инструмент, НО он работает только на винде и конкуренция это здорово!
//про бомбануло и вендовозников — комментировать вообще бессмысленно
Diaver
13.01.2016 20:07+3Интересно что ответят представили JetBtrains о целевой аудитории.
Все-таки студия это огромный комбайн который может очень много чего, а не только редактор кода.
Nigrimmist
13.01.2016 20:16Ну так и Москва не за день строилась. Главное, что есть шаг. А ещё главнее, что это шаги от JetBrains, потому что кто-кто, а они умеют пилить продукты.
kekekeks
13.01.2016 20:25+1Там проблема не в функционале самой студии, а в функционале тучи дополнений под неё разного рода.
Nigrimmist
13.01.2016 20:25Подтянутся в течении пары лет, если мс не изменит темп врыва в опенсурс, не?
kekekeks
13.01.2016 20:27+3Кто подтянется? Авторы дополнений? Писать дополнения под платную IDE от JB при бесплатной-то студии?
Nigrimmist
13.01.2016 20:29Ну сегодня платная, завтра условно-бесплатная. Студия-то тоже изначально платный продукт был (или мы express считаем бесплатной и достаточной?)
Diaver
13.01.2016 20:50+4Бесплатная версия Visual Studio сейчас называется Community. Она бесплатна для индивидуальных разработчиков и не сильно отличается от Professional версии, за исключением поддержки TFS.
sborisov
14.01.2016 13:10Да. Community, но она равна Professional по функционалу.
www.visualstudio.com/ru-ru/products/compare-visual-studio-2015-products-vs.aspx
Viacheslav01
14.01.2016 13:46+1Комунити близка, но не равна по функционалу к Проф версии.
sborisov
14.01.2016 13:47По ссылке ходили?
Там нет только TFS — остальное есть.Viacheslav01
14.01.2016 18:59+1А зачем мне по ссылке ходить? Я сам встречался с различиями, дома комунити на работе проф, различия есть из того, что могу вспомнить сходу это кодлинзы.
Antelle
13.01.2016 20:40+2Хм, вообще под IDE JetBrains очень много дополнений.
> При бесплатной студии
которая не запускается ни под чем кроме винды
Caravus
13.01.2016 22:51-14… да и не под каждой виндой-то (вин 10 х64)…
withkittens
13.01.2016 22:58+3Caravus
13.01.2016 23:35-14Слышали когда-нибудь поговорку: «на заборе тоже написано, а там дрова лежат»? :)
ZimM
14.01.2016 01:23Что не так со студией под вин 10 х64? Установлены студии 2012, 2013, 2015, все работает как должно работать.
Caravus
14.01.2016 01:34-16Карма -3 подсказывает мне что мой фидбек никому не нужен, забейте.
ad1Dima
14.01.2016 08:45+10А логика подсказывает, что о большинства студия на заявленных системах работает. И Если бы вы начали не с наезда, а с проблемы с которой столкнулись лично вы, то, вероятно, вам бы помогли. Но выбор ваш…
ApeCoder
14.01.2016 11:06Плюнь на карму, что не так-то?
Кстати, www.infoq.com/news/2016/01/VS-64-bitCaravus
14.01.2016 11:09Как это плюнуть, с неудовольствием наблюдаю -5.
По сути — не устанавливается. Пробовал и на апгрейженой с вин7 и на чистой вин 10 про и на чистой вин 10 хоум (как она там)… Не может скачать файлы какие-то, а если скачивает — не ставит. В обоих случаях — установщик просто висит не подавая признаков жизни.
rbobot
14.01.2016 11:12У меня такая же проблема была. Решилось запуском с ключом тихой установки.
Грешу почему-то на видеодрайвер новый для амд.Caravus
14.01.2016 11:17Я пробовал на разных компах (ноут и комп) и при этом натрёх разных видеокартах (нвидия, амд, интел), в разных местах (разный интернет), также — как уже писал — на разных виндах. Думаю что проблема всё таки не на моей стороне…
VEG
14.01.2016 13:06Пруф, что VS2015 работает на Windows 7. У меня она установлена на двух машинах — всё поставилось без нареканий. Может быть, вы ставите на необновлённую систему? На Windows 7 как минимум должен стоять Service Pack 1.
Caravus
14.01.2016 13:25Речь идёт о вин 10 х64
Viacheslav01
14.01.2016 13:52+1Три установки, на три разнородных PC везде 10x64 Pro, встало без сучка и задоринки.
mezastel
14.01.2016 00:38+2Я приведу пример WPF редактора. Он вам точно нужен? Точно? Когда он вообще последний раз правильно формочку отрисовывал? Воот. Но если серьезно, да, будут дизайнеры и технологические стеки которые с начала не будут поддержаны т.к. это тяжело и нужны большие усилия.
creker
14.01.2016 01:06+3Все время, что им пользовался, вроде правильно отрисовывал, по крайней мере в 12-13 студиях. Мне точно нужен, но мне и студии хватает. Потребности в сторонней IDE для этого нет и вряд ли будет. Тем более для WPF, который до сих пор только Windows. В любом случае на Windows потеснить студию вряд ли получится ни в ближайшем, ни далеком будущем. А вот на linux/mac в свете движения .Net туда будет очень здорово видеть что-то полноценное.
denismaster
14.01.2016 01:20-9WPF технологически устарел, но вот что-то новое, тот же Perspex, видеть из коробки в Rider было бы очень круто.
creker
14.01.2016 01:47+4WPF технологически устарел
Странное умозаключение. Посмотрел примеры Perspex и его paml — практически копия xaml. Ну да ладно, WPF в любом случае никуда не денется с позиции основного инструмента UI приложений на Windows. По крайней мере, пока MS стоят за ним и поставляют в комплекте. Они как раз вновь подтвердили, что WPF — это тот самый и единственный выбор на Windows платформе.denismaster
14.01.2016 07:38-4Однако, в отличие от того же paml, razor, xaml-синтаксис остается вообще неизменяемым и достаточно неудобным для нашего времени. А использование Direct3D 9?) UWP вроде бы использует другие системы отрисовки, поновее, но WPF именно технологически устарел. Не морально, подчеркну.
ad1Dima
14.01.2016 08:47+1UWP вроде бы использует другие системы отрисовки,
С точки зрения программиста — тот же XAML, тот же Direct X. Внутри они, конечно, отличаются. И по биндингам и по темплейтам. Но все это не кардинальные изменения.
kekekeks
14.01.2016 10:06+2тот же Perspex, видеть из коробки в Rider было бы очень круто.
Perspex-овский дизайнер, мы, вероятно, будем таки выносить в полностью автономный процесс вместе с текстовым редактором paml. Это как позволит редактировать .paml с предпросмотром и автодополнением без какой-либо IDE, так и существенно облегчит его встраивание в разные IDE (MonoDevelop, SharpDevelop, Rider, ну и та хреновина, которую сейчас на самом Perspex-е делают).
Говорить же о технологическом превосходстве перспекса над WPF пока достаточно рано и немного смешно — у нас даже VirtualizingPanel ещё нет.
Diaver
14.01.2016 01:26+2Если вопрос ко мне, то да, WPF редактором пользовался, довольно много, глобальных проблем не возникало. На мой взгляд, для desktop разработчика штука нужная.
withkittens
13.01.2016 20:40+1И снова Java, на которой на некоторые шрифты без слёз и не взглянуть?
splav_asv
13.01.2016 22:02+3Они именно поэтому таскают с собой свою патченую java.
withkittens
13.01.2016 22:50+3Сами посудите:
Заголовок спойлера
splav_asv
13.01.2016 23:48Для monospace шрифтов вроде бы нет понятия «кернинг», а другими в редакторе кода и не пользуюсь. Рендеринг глифов справа вроде бы вполне нормальный.
withkittens
14.01.2016 01:04+4Это пропорциональный Input.
Если воспользоваться хаком с FontForge, то шрифт будет выглядеть так:
Заголовок спойлера
Bringoff
14.01.2016 08:43+1Такое ощущение, что вы типограф, а не разработчик :) Я на первой картинке вообще разницы почти не вижу.
splav_asv
14.01.2016 12:49+2Хак удаляет хинтинг, к кернинг по идее не затрагивается. Видимо сглаживание тоже влияет косвенно на кернинг. Но, повторюсь, для monospace понятия кернинг нет, ширина позиций фиксированная.
P.S. на Linux, всё по умолчанию шрифт выглядит так:
https://habrastorage.org/files/5ef/a5f/f2c/5efa5ff2cfff4159b18619e76c4f86a6.png
java — jre8-openjdk
Elufimov
14.01.2016 07:25+4
IDEA 15, правда под маком. Но тут со шрифтами всё просто отлично.
youROCK
14.01.2016 11:22Даже с патченной java от jetbrains, сглаживание шрифтов на маке достаточно сильно отличается от нативного. Но все равно намного лучше, чем сглаживание в Java 8 от Oracle (в коробочной Java 1.6 сглаживание хорошее, но иде моргает и тормозит немного)
konsoletyper
14.01.2016 12:46+9Кстати, вот пришло время оффтопа. Этой проблеме лет 10, если не больше. Про неё все знают, все плюются. По сети гуляют патчи, так что, кому не страшно повторить квест со сборкой OpenJDK, таки собирают его пропатченный и радуются шрифтам. Там и проблема-то в том, что настройки хинтинга жёстко прибиты гвоздями и не читаются из системных конфигов. Так почему разработчики OpenJDK до сих пор не исправят проблему (дело пары десятков строк кода) или хотя бы не примут патч в основную кодовую базу? ИМХО, стыд.
areht
13.01.2016 22:03+2Я помню JB не так давно утверждали, что конкурировать со студией им не резон, им такой комбайн не потянуть.
Видимо, просто обкатывают out-of-process ReSharperPowerz
14.01.2016 10:53После того, как МС пообещали нормальную кроссплатформенность для дотнета и начали делать VS Code, стало очевидно, что JetBrains долго тупить не будут.
Atreides07
13.01.2016 22:29+6Каждый раз запуская Xamarin Studio я очень жалел что нет альтернативы от JetBrains или хотя бы плагина к Xamarin Studio c фишками Resharper-а. Сейчас очень много кода пишу на этой платформе и порой пишу на маке. Очень надеюсь что когда нибудь будет полноценная поддержка Xamarin. За такой продукт заплатил бы с удовольствием, несмотря на наличие бесплатного Xamarin Studio.
x2bool
13.01.2016 23:14+9Xamarin CEO:
Congratulations to JetBrains on the launch of @JetBrainsRider! We're looking forward to supporting it at Xamarin.
— Nat Friedman (@natfriedman) 13 января 2016
Shablonarium
14.01.2016 00:49-22Эх, ну какая кросс-платформенность без ондроеда, а я уж было поверил заголовку…
SonicGD
14.01.2016 08:38+12А вы IDE на телефоне запускаете?
Valery4
14.01.2016 10:26А что на Nokia 3210 портировали Android? А то на огромно цветном экране 4", как-то, некошерно IDE запускать.
Shablonarium
14.01.2016 17:13-3Asus Transformer для вас тоже телефон?
ad1Dima
15.01.2016 06:26+3Если на нем android, то да. Ну и как-то не вижу я, что б он комфортно потянул современную IDE ещё и на Java.
Gorniv
14.01.2016 09:49Это супер новость, два дня назад я узнал что ASP 5 добавили в Xamarin, а теперь такой подарок от JetBrains!!!
Надеюсь будет возможность попасть в закрытый бета тест, и можно будет не включать Parallels…
gurinderu
14.01.2016 10:21+2Не в обиду JetBrains, но вы ребята сильно распыляетесь. Понятное дело, что разные люди занимаются проектами, но Clion развивается ну очень медленно.
anastasiak2512
14.01.2016 10:40+2Это вообще две никак не связанные команды. И вряд ли развитие Project Rider как-то повлияет на CLion, ну разве что в положительном плане, так как, очевидно, будут какие-то фиксы в платформе.
А что лично Вам не хватает в CLion?gurinderu
14.01.2016 14:27+2с11, makefiles и кучу других вещей.
Я уже на трекере голосовал, но по-моему на эти голоса особо то и не смотрят.anastasiak2512
14.01.2016 14:35+1Смотрим, еще как. Но как раз таки именно поэтому пока другие задачи в приоритете (Python, attach to process, variadic templates).
Makefile — тут вообще своя история, мы ее пытались в посте отразить. Если кратко, чтобы добавить еще одну систему сборки/проектную модель, нам надо закончить с важными проблемами по CMake, иначе эти проблемы просто «переползут» в общий интерфейс, через который будет работать и CMake, и Makefiles. Именно это сейчас и пытаемся сделать. Потом начнем смотреть в сторону уже конкретно Makefiles.
youROCK
14.01.2016 11:26+1Возможно, вы удивитесь, я когда столкнулся с проблемой того, что CLion работает очень медленно на больших файлах, пошел искать другую IDE для C/C++ и остановился на… NetBeans! Она каким-то образом умудряется вполне сносно работать при любом размере файла, что было очень важно для того проекта, над которым я работал. Также NetBeans не прибивает проект гвоздями к cmake, что тоже в моем случае был плюс.
anastasiak2512
14.01.2016 12:41Что Вы подразумеваете под быстро работать? Изначальный парсинг проекта? Думаю да, NetBeans может делать его быстрее. Ему и не надо столько информации о проекте, сколько собирает CLion. Тайпинг? За последнее время в CLion решили много проблем на эту тему, стоит попробовать последние билды и зарепортить нам проблемы, если они все еще есть.
youROCK
14.01.2016 13:06Нет, скорость индексации лично меня не волновала — проект был небольшой, но состоял из пары файлов, один из них был 5000 строк. Скорость ввода текста была неудовлетворительной — большую часть времени IDE вводила текст где-нибудь через секунду после нажатия. «Живой рефакторинг» тоже работал супер-медленно, когда я хотел переименовать макрос, который встречается 100 раз в одном файле — я ждал около минуты, пока IDE «отпустит». Я пробовал версии 1.0 и 1.1beta, на обоих версиях Java (1.6 и 1.8), разницы не заметил. Это было месяца 3-4 назад, возможно что-то и изменилось с тех пор, конечно. Я думаю, с CLion проблема в том, что иде пытается «честно» работать с макросами и дефайнами, и на больших файлах это приводит к очень медленной работе. Не уверен, что при выбранном подходе вообще вам удастся получить хорошую производительность, к сожалению.
anastasiak2512
14.01.2016 14:18В целом можно попробовать а) увеличить память, ну или хотя бы для начала включить индикатор памяти в настройках и проверить, сколько ее используется б) снять логи и CPU snapshot с меделенным тайпингом (инструкцию можно найти здесь) и засабмитить нам в саппорт. Тормозящий тайпинг — это проблема, с который мы активно боремся. Сейчас вроде таких явных «историй» не особо знаем, так что если вдруг попробуете опять и встретите, присылайте данные — будем разбираться.
youROCK
14.01.2016 18:59Попробовал EAP, определенно выглядит получше, чем раньше, спасибо! Впрочем, переименование константы, которая встречается в файле много раз, всё ещё заставляет IDE задуматься очень конкретно.
anastasiak2512
14.01.2016 19:05А можете закинуть лог + snapshot в трекер? Вдруг мы там что-то интересное найдем)
sborisov
14.01.2016 13:18По моему скромному мнению, в Linux CLion лучшая IDE, (именно IDE), но для быстрой работы — конечно очень нужен SSD.
Правда CMake и правда странная вещь, сколько он нервов попортил, что кажется быстрее и проще было написать разные Makefiles под разные ОСи и забыть про них, чем решать проблемы почему cmake не видит директорий или не линкует библиотеки (в Windows, в Linux таких проблем почти нет), но это уже не проблема CLion.
vba
14.01.2016 14:58+2Надеюсь как с IDEA будет и коммюнити и интерпрайз версии. Так же даешь поддержку F# и долой vb.net!
danslapman
14.01.2016 16:01+1Я, например, вообще надеялся, что уж если Jetbrains сделают .NET IDE, то наконец-то будут нормальные рефакторинги для F#, а тут «no plans for F# right now»
return_true
20.01.2016 02:22Есть старый проект FSharper. Активность в нём показывает, как сильно миру нужна поддержка F#.
evilbloodydemon
20.01.2016 09:15+1активность в нём показывает всего лишь, как сильно jetbrains нужна поддержка F#. а вот насколько она нужна миру показывает VisualFSharpPowerTools
return_true
20.01.2016 12:46Ок, переформулирую. Отсутствие активности в FSharper показывает, что не так уж и нужна поддержка в ReSharper. Сообщество справляется своими силами и без решарпера.
solver
Что теперь будет с Consulo?
kekekeks
А ей кто-то кроме автора пользовался?
ArXen42
Я пользуюсь. Под linux для unity3d (да и для C# в принципе) ничего более удобного не нашел.
TheShock
Я пользуюсь. И скажу вам, что она довольно хороша.
VISTALL
Ничего не поменяется. Про Rider я очень давно знал