Как стать автором
Обновить

Комментарии 681

1. Kotlin более проприетарный....


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

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


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

История то пока как раз хорошо развивается.

Вы возможно не в курсе, но теперь разработка языка финансируется из Rust Foundation, что то есть Rust теперь не "ничей", а "общий". Разница для некоторых может ускользать, но она существенная – сейчас в развитии Rust заинтересовано множество компаний и людей, а не только одна Mozilla.

Я ровно это и написал, с чем вы несогласны?

Котлин действительно полностью опенсорсный, rzwitserloot врёт. Почитайте ответ elihart17, например.

Бинарные блобы в драйверах для Линукса тоже можно дизассемблировать, но это не делает такие драйвера open source в исконном смысле этого слова. Open source — это то, что любой может форкнуть и переписать под себя. Хранение ключевого кода компилятора в обфусцированном виде этому явно не способствует.

Может, я чего-то не понимаю. Спецификация языка Котлин открыта. Компилятор тоже открыт. В чём закрытость Котлина? В том, что какой-то промежуточный формат для конкретной платформы не может быть представлен в виде чистого текста?

Про @Metadata можно прочитать в доке например https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-metadata/, а сами данные в протобафе и лежат в репозитории котлина https://github.com/JetBrains/kotlin/blob/master/core/metadata/src/metadata.proto. Для любого кому это интересно – не сложно найти это (я нашел прямо в интерфейсе гитхаба). Ну и конечно чтобы понимать это нужно понимать компилятор :) Интересно как много джава разработчиков умеет в сорцы javac)

Похоже, это никакой не "проприетарный код" в компиляторе, а просто способ для компилятора дописать дополнительную инфу в жестко заданном формате .class-файлов, который, естественно был заточен только под javac.


Компилятор Scala тоже пишет достаточно много метаинфы в .class-файлы. С этим можно огрести, если например использовать обфускаторы, работающие на уровне байткода. Но ничего криминального и проприетарного в метаинфе нет.

Именно, более того во многих случаях можно удалить @Metadata (андроид разработчики так делают с помощью proguard, им зачастую не нужен рефлекшен для чего @metadata и используется) чтобы сэкономить несколько kb

@Metadata используется именно для котлиновского рефлекшена. Было очень много головной боли, когда ProGuard ломал мне метаданные внутренних классов и приложение начинало падать в случайных местах при десериализации через Moshi.

Нативная поддержка null, которая греет душу любого котлиниста, легко заменяется в Java на обёртку из Optional.ofNullable

a) Вместо Optional всегда может прийти null
б) Optional никак не избавляет от проверок на null. Просто вместо if(it!=null)по всему коду будет if(optional.isPresent())

в) Опять же, таскать повсюду эту обёртку. Вместо `(arg: MyClass)` посвюду будут `(arg: Optional<MyClass>`. А джава и так не отличается лаконичностью.

г) Ну и самое главное. В котлине null safety проверяется на этапе компиляции, а не в рантайме, что, какбы, значительно интереснее

Пара корректировок:


вместо if(it!=null)по всему коду будет if(optional.isPresent())

Только по коду, который писали неумеющие в map, flatMap и иже с ними.


В котлине null safety проверяется на этапе компиляции, а не в рантайме

В джаве Optional это и есть способ обеспечения null safety на этапе компиляции. В рантайм это пролезает только в паталогических случаях, вроде Optional.get() или передачи null вместо Optional, но с такими случаями до какой-то степени можно бороться линтерами.

Только по коду, который писали неумеющие в map, flatMap и иже с ними.

В Котлин можно написать val notNullValue = calculateNullableValue() ?: return. Как вам тут поможет map и flatMap?

Мы обсуждали Optional в джаве, про котлин я ничего не говорил. Но если вы спрашиваете, как в аналогичном вашему кейсе в джаве обойтись без if(!optional.isPresent()) return, то очень просто:


void myFunc() {
  ...
  optional.ifPresent(x -> ...);
}

Конечно, если в целом окружающий код императивный, то лучше сделать if и return/break. Но если это какие-то преобразования на стримах, например, мой вариант будет более уместен.

Конечно, если в целом окружающий код императивный, то лучше сделать if и return/break.

Ну то есть вы понимаете, что вопрос не в умении или не умении map/flatMap, а в том, какая у нас вообще задача и какой код вокруг? Просто вы так написали, будто готовы уволить любого, кто isPresent() в коде напишет.


ifPresent — это уныло. Мы можем находиться во вложенном if/while/for, тогда это не поможет. Если же у нас несколько проверок на null подряд, то будет opt1.ifPresent(x -> opt2.ifPresent(y -> opt3.ifPresent( -> {...}))). Ну и, конечно, замена if(opt.isPresent()) на opt.ifPresent() не делает код лучше в 99% случаев. Он не становится более функциональным, менее зависимым от сайд-эффектов, при этом его становится сложнее отлаживать в пошаговом отладчике, удлиняются стектрейсы и т. д.


Я вообще делаю обычно так:


V v = computeOptional().orElse(null);
if (v != null) {
  ... используем v
}

Некоторые приходят в ужас, но это самое удобное, что можно делать с optional.

Просто вы так написали, будто готовы уволить любого, кто isPresent() в коде напишет.

Я отвечал на "Optional никак не избавляет от проверок на null", что по факту не так. Использовать или нет — это воспрос стиля, принятого на конкретном проекте.


opt1.ifPresent(x -> opt2.ifPresent(y -> opt3.ifPresent( -> {...})))

Ну такой кейс во всей своей жести и на if'ах будет выглядеть неочень, особенно если есть else-часть.


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

Ну да, ifPresent — это для сайд-эффектов как раз и сделано. И да, есть плюсы и минусы. Но все-таки он вполне избавляет от проверок на null, о чем собственно и был изначальный тезис.

На ифах будет плоская структура:


X x = calcX();
if (x == null) return;
Y y = calcY(x);
if (y == null) return;
Z z = calcZ(y);
if (z == null) return;
// пользуемся x, y, z на здоровье.

Ну если цель в том, чтобы минимизировать стектрейс то да, if вне конкуренции. Если цель — уменьшить вероятность NPE при помощи компилятора — я, уж простите, поеду с Optional.

Нужно и то и то. Кстати, по этому подходу пошел майкрософт, и вполне неплохо вышло по-моему. Есть даже слабое подобие завтипов:


img

Optional не решает проблему с null. Её лучше решают nullability-аннотации и в целом массовый отказ от null (non-null by default). Но, конечно, в Котлине это сделано красивее и удобнее.

Optional не решает проблему с null. Её лучше решают nullability-аннотации

Непонятно, почему аннотации лучше. С использованием nullable-аннотаций, на мой взгляд, есть несколько проблем. Процитирую свой старый коментарий:


  1. нельзя отличить неинициализированное по ошибке поле от необязательного без значения
  2. аннотации для локальных переменных выглядят сильно хуже, чем Optional
  3. для null нет никаких средств композиции, для Optional есть flatMap

Для локальных переменных аннотации не нужны, любая нормальная IDE и без них справится. А средство композиции есть. Называется if. Насчёт инициализации с Optional тоже бывает, что поле может иметь значение, может не иметь, но инициализировать его надо лениво. Как будем выкручиваться? Optional<Optional<X>>?

Насчёт инициализации с Optional тоже бывает, что поле может иметь значение, может не иметь, но инициализировать его надо лениво. Как будем выкручиваться? Optional<Optional<X>>?

А что не так? Ну, кроме того, что это должно быть Lazy<Optional<X>>

  1. Неициализированные поля, по-моему, в целом проблема дизайна, потому что всё подобное (поля) стоит делать final, инициализируя при создании объекта. Экзотику с не очень удачным DI, вроде оного в JFX, стоит рассматривать, скорее, как неудачное решение.

  2. Для локальных переменных они, как раз, не нужны, потому что там nullability однозначно выводится.

  3. Тут, увы, да, но в пределах API, скорее, nullа будут избегать (снова же, при удачном дизайне). Классический пример, пустая коллекция лучше nullовой.

Неициализированные поля, по-моему, в целом проблема дизайна, потому что всё подобное (поля) стоит делать final, инициализируя при создании объекта.

Инициализация полей не в конструкторе это реальность жизни.
В больших spring проектах очень сложно все так разрулить чтобы все было только через конструктор. Увы, надо с этим жить.

Ну почему же? Всё тот же Spring умеет в инициализацию через конструктор, либо, что ещё более приятно, static factory method. Единственное, что, по-моему, может мешать этому — циклические зависимости, но, это как раз чаще признак того, что что-то не так.

Умеет. В небольших все разруливается без проблем. Поэтому я и говорю про большие проекты c кучей легаси в них.

Не зря всякие @PostConstruct выдуманы. В Спринге еще есть такие же вещи. Которых в новом проекте не должно быть. А вот в старом иногда по другому не разрулить зависимости никак. Разработчики Спринга знают своих пользователей.
Неициализированные поля, по-моему, в целом проблема дизайна

В целом согласен, но иногда бывает нужно ленивую инициализацию. А если отойти от Optional и просто поговорить о final-полях в джава, то с этим до сих пор довольно много проблем. Тот же хибер, который совсем не экзотика, форсит делать изменяемые поля. Надеюсь, новые record'ы, который immutable by design, улучшат положение дел, но врядли это произойдет быстро.


Для локальных переменных они, как раз, не нужны, потому что там nullability однозначно выводится.

А кем выводится? Я вот за то, чтобы выводилось компилятором. Optional для этого и сделан как раз.


Тут, увы, да, но в пределах API, скорее, nullа будут избегать (снова же, при удачном дизайне).

Возьмем например REST API. Насколько я знаю, при маппинге необязательных полей из Java в JSON и обратно, у вас два варианта — либо nullable, либо Optional. Как можно избежать null, если не использовать Optional?

Так потому и в стайлгайдах и в рекомендациях разработчикам пишут (и даже Идея это подсвечивает), что не надо возвращать Optional или принимать его в параметрах. По возможности, конечно. Если ожидаете что вам где-то может вернуться null или быть передан в параметрах — оборачиваете вызов в Optional, работаете с ним. Уверены, что такого не случится — работайте как работалось. Порой выглядит лучше чем код!.. белок!.. истеричек!!!

В параметрах передавать как раз таки антипаттерн.

Возвращать как раз хорошо. Принимать неправильно, да.

г) Ну и самое главное. В котлине null safety проверяется на этапе компиляции, а не в рантайме, что, какбы, значительно интереснее

Если рядом нет Java-кода.
На андроиде он обычно есть (старый код проекта или системный код андроида)
Какая то мелкая ошибка и креш с xxx must not be null. (xxx — объявлен в Java-коде)
И никаких вообще предупреждений компилятора.
Недавно пришлось править баг на эту тему. Dto-объект объявлен на java. одно из полей инициализируется вручную а не десериализатором (по историческим причинам, альтернатива — целиком этот модуль переписать, что в планах). вот только все забыли что у приложения есть (и используется иногда на проде) еще один legacy режим работы. в legacy-режими инициализации поля нет ни десериализатором ни вручную и при попытке обратится получатся xxx must not be null.

Ну уж в этом случае никто не мешал вам поставить Nullable на это поле. Это бы проросло в котлин.
НЛО прилетело и опубликовало эту надпись здесь

COBOL вполне себе успешно используется в банковском софте) Но мне тоже кажется, что автор прав и Scala не блещет какими-то успехами в последнее время.

НЛО прилетело и опубликовало эту надпись здесь
Между использованием кобола (в виде поддержки старого софта на нем) и написанием на скале нового вообще говоря разница огромного размера. По крайней мере — потенциально.
НЛО прилетело и опубликовало эту надпись здесь

На hh:

COBOL - 0 вакансий

Scala - 260 вакансий

Kotlin - 994 вакансии

Java - 4060 вакансиий

Так что COBOL скорее мертв, чем жив. Scala нашла свою узкую нишу. Kotlin до Java ещё далеко...

Kotlin уже набирает обороты, так что, мне кажется, что разрыв будет становится все меньше

Согласен. Kotlin развивается и в каждой вакансии под Android уже спрашивают знание Kotlin.

С бекендом этот процесс идет медленнее.

Просто программистов COBOL не набирают по объявлению )

Да они и не откликаются на объявления. Google "Cobol cowboys")

Похоже это отдельная вселенная... Такая же как и отдельная вселенная 1С-ников, отдельная вселенная рубистов и т.д.

Когда работал в Сбере ни разу не слышал, что ищут программиста Cobol (искали C, C++, Scala, JS, Python и больше всего искали Java) - хотя там тонны легаси. Но постепенно легаси заменяются на современные технологии....

Обычно разрабы на таких языках, как Cobol пишут десятилетиями и держатся за своё место или их индивидуально хантят.

Вместо кобола в России — абап.

В России Кобола никогда не было, разумеется. Когда западные банки автоматизировали на Коболе, у нас на счётах считали.

Пользуясь случаем, хотел спросить. А отдельная IDE для Раста у вас планируется? Ну хотя бы в отдалённых планах может быть?

Не имею такой информации.

а зачем? можно тот же GoLand взять и в него поставить Rust

Скорее уж тогда CLion:


In CLion, you get even more: fully-fledged debugger, CPU profiler, and Valgrind memcheck.

Но, по сути, да, особого смысла в отдельной IDE сейчас нет.

Канеш мертва. А некроманты 3ую версию тут релизят
www.scala-lang.org/blog/2021/05/14/scala3-is-here.html

Ну и lightbend контора некрофилов тоже. Да и тинькофф туда же. Полностью согласен.
Да и сравнение с COBOL в точку прост. На рынке аж 1 вакансия в самом прогрессивном банке на рынке страны. да что там страны!
spb.hh.ru/vacancy/43083989?query=cobol

Ваш текст навёл меня на мысль, что надо бы все же собраться с духом и изучить Scala. Коль скоро Скала уходит в забвение, скоро разработчиков на ней не останется, и тогда фин. сектор будет предлагать горы золотых пиастров тому, кто возьмётся поддерживать их легаси код, написанный на Скалке.

Тогда уж лучше всё же кобол

Ну может у человека нет тяги к иностранным разговорным языкам (к примеру исходя из никнейма) и он планирует остаться в фин. секторе конкретной страны :)

К тому времени все уже на Rust перепишут )

НЛО прилетело и опубликовало эту надпись здесь

Помню изучал Scala, написал веб сервер, для чтения книг. Изучил довольно таки хорошо примерно за месяц. А далее появился go и переписал сайт на него и тоже хорошо изучил. В итоге остался на го и уже забыл синтаксис скала

Не представляю человека с улицы, который какое-нибудь зио и котоэффекты без подготовки освоит за полтора месяца. Особенно учитывая, что у всех работа/учеба, и 1.5 месяца это не фуллтайм изучение япа обычно.

Понятно, что шутка, но все же за раст как раз в плане мощности системы типов душа болит. Специализация, гаты, конст генерики — всё прячется за min_min_min гейтами и практически не едет. Это грустненько.


Тогда как в скале б0льшая часть этого давно есть.

Согласен, наверное это самое большое разочарование для программиста на Rust: язык сначала воодушевляет, а потом оказывается, что то — нельзя, это — нельзя… И возникает уныние.


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

НЛО прилетело и опубликовало эту надпись здесь

Я гвоорю только про то, что есть языки с трейдофом в сторону меньшего перфоманса, но б0льшей выразительности и удобства. А учитывая что прям перф раста много кому не нужен на самом деле...

НЛО прилетело и опубликовало эту надпись здесь

Вообще то пробовал писать на scala но совсем недолго, буквально пару дней и отложил на неопределенное время.

У меня есть идея, возможно нелепая, но тем не менее, мне всерьез кажется, что скала будет хороша на поприще 2д геймдева (которым я по-немногу балуюсь)

И я пробовал скалу именно на этом поприще. Сваял для пробы пера тетрис на связке scala + libgdx. Ну что могу сказать. У меня все время было ощущение, что мне хочется писать на скале именно как на джаве в ООП парадигме, и мне приходилось все время делать насилие над собой, чтобы придерживаться чистого ФП стиля. В итоге получилось обойтись почти без ооп, кроме тех мест, где надо было непосредственно с libgdx взаимодействовать, но вот само ощущение, что все время хотелось забить на ФП, и начать писать как на джаве, оно удивило. Ведь я пробовал писать рогалик в псевдографике в чистом ФП стиле на хаскеле и в принципе мне нравилось. По ООП совсем не скучал, наоборот было ощущение, что вот как клёво, никаких тебе объектов, которые вызывают методы друг друга хаотическим образом, как здорово, что нет этой путаницы, когда все зависит от всего.

Почему же на скале меня потянуло в ООП? Возможно такое случилось потому, что я очень плохо знаю скалу, и мне над каждым действием приходилось подолгу мучаться, чтобы понять как надо сделать. А писать в духе джавы, даже с самыми минимальными знаниями скалы было несложно - плодишь себе объекты с методами, которые вызывают друг друга и не паришься.

Я не думаю что она куда-то уходит: сидит в своей нише и сидит. Изучить её в любом случае доброе дело — система типов там куда лучше чем у мейнстрима.

Если Java не будет «спать», как в нулевые, и продолжит развиваться, то в перспективе Kotlin — безусловно эволюционный тупик. Избавиться от «проклятия вторичности» JetBrains сможет, если в какой-то момент отвяжется от базы JVM и разойдется с Java по настоящему. Видимо и проприетарность в какой-то момент придется отменить. Хотя JB и создала Kotlin во многом для того, чтобы продавать больше IDEA.

У меня есть гипотеза, что Котлин создан не чтобы продавать IDEA, а чтобы разрабатывать IDEA. У JetBrains, я думаю, одна из самых развесистых Java-кодбаз в мире. Мало кто решается повторять их подвиг, предпочитают Electron. И когда несколько лет подряд 8 часов в день 5 раз в неделю пишешь Foo<bar> foo = new Foo<bar>, то в какой-то момент мысль о том "вот бы была такая Джава, как Джава, только лучше, и можно было бы в одном проекте их использовать" начинает преследовать.

Что такое развесистая JAVA-кодобаза? Electron используют по причине удобного рендеринга, движок chromium настолько оптимизирован, что даже не все десктоп приложения так быстро могут рендериться, плюс легкий вход css + js. Все же по мне JAVA отстает в плане графики. И при наличии jetbrains ide все же в некоторых проектах предпочитают VS Code, она шустрая, быстро запускается и самое главное есть интеграция с некоторыми тулчайнами, с которыми нет у jetrains.
Но ведь VS Code это не IDE. Максимум умный блокнот с плагинами. Нет ничего удивительного, что она быстрее запускается.
IDEA точно такой же умный блокнот с плагинами. Деление IDE/не IDE давно потеряло всякий смысл.
Ну просто есть какая-то критическая масса умности и плагинов, когда умный блокнот становится IDE.
В vscode это обычно достигается установкой плагина поддержки того или иного языка, который привносит весь необходимый набор инструментов. А потом можно еще поставить вагон других, которых либо вообще нет в IDEA, либо за них просят денег, да еще немалых. Это одна из причин, почему я похоже никогда таки не перейду на Goland. Как IDE для Go он не умеет ничего сверх Vscode, а его набор плагинов банально недостаточен мне.

Сколько бы плагинов в vscode не ставил - он всегда хуже чем web/phpstorm из коробки, да и работать начинает медленней, например go to definition срабатывает через пару секунд.
о том, что между ними нет разницы пишут только фанаты редакторов, которые не освоили нормальную ide

о том, что между ними нет разницы пишут только фанаты редакторов, которые не освоили нормальную ide

Ну у меня есть idea, для джавы ее использую, т.е. вроде бы по вашей класификации IDE освоил. А вот для JS/TS использую vscode и считаю его более удобным чем webstorm.

Осилил, и около 7 лет работал на идее, несколько месяцев назад пересел на VSCode. Из недостатков для меня только работа с гитом, в остальном не вижу особой разницы. По производительности ощущается намного лучше, ничего не зависает во время автокомплитов, не шумит как самолет из-за постоянных индексаций + есть remote development, которого почему-то до сих пор в «самой продвинутой» IDE нет

Вот этого нет?

Только что попробовал. Не совсем, хотя до недавних пор даже этого не было.
В VSCode полноценный клиент, который взаимодействует с анализаторами, плагинами, файловой системой и т.д. на сервере через api, за счёт чего разница с локальной разработкой фактически не ощущается, а тут просто сделали что-то вроде VNC, из-за чего скролл и шрифты выглядят странно и чувствуются задержки при взаимодействии с UI

Ну основное отличие — интегрированность. Обычно один плагин в умном блокноте никак не взаимодействует с другим. В той же идее есть некий протокол взаимодействия, что ли. Например, когда ты можешь в java-коде вставить jpql-строку. И она не просто подстветится в соответствии с синтаксисом, но и будут работать автодополнения. А если настроены datasource, то оно ещё и с реальными таблицами в базе интегрируется.

В этом согласен отчасти, но некоторые плагины в VS Code все же интегрированы между собой очень плотно.

ПО закону мерфи именно те 2 плагина которые вам нужны интегрированны друг с другом не будут :)

Умный блокнот с плагинами это продукты Jetbrains. Уже ниже писал, что за свои деньги становишься каким-то бета тестером и не возможно нормально работать. Скажу больше, в плагинах VS Code поддержка некоторых тулчайнов, значительно лучше чем в продуктах Jetbrains. У Jetbrains конечно есть свои плюсы, но и есть кучу минусов…
Ага, в Райдере поддержка новых версий тулчейнов выходит с запозданием в месяц — два. В платном продукте. Или например в бесплатной Идее делать нельзя ни-че-го.

Это при том, что VS Community бесплатен.
Мафия вошла в чат… То есть сотрудники Jetbrains. Все минусуют…
Они кстати очень смешные, совсем не умеют признавать свои ошибки и баги в их продуктах, но искренно верят в свою исключительность и что их IDE одни из лучших. Когда им говоришь про серьезные проблемы и недоработки мешающие работать, даже огрызаются… Самое главное они недостаточно понимают специфику работы конечных пользователей их IDE, и какие задачи они решают, будь-то живут в своей вселенной Jetbrains… Вроде они что-то сделали хорошее, но все не то. Условно дали вам красивые кожаные ботинки, но не дали носков, а ботинки вроде есть, но натирают мозоль и протекают… В итоге вы носите старые кросовки…
То есть сотрудники Jetbrains. Все минусуют…

Везде заговор!


совсем не умеют признавать свои ошибки и баги в их продуктах

Я умею. Дофига багов, вообще глюкавище полное иногда релизим :( А кто не умеет? Можно более конкретный пример?


но искренно верят в свою исключительность и что их IDE одни из лучших

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


Самое главное они недостаточно понимают специфику работы конечных пользователей их IDE, и какие задачи они решают, будь-то живут в своей вселенной Jetbrains…

У наших IDE порядка 10 миллионов пользователей, большинство платных. Они все ошибаются? Пали жертвой агрессивного маркетинга? А может такое случиться, что как раз ваши потребности слишком специфичны и не укладываются в сценарии, которые нужны большинству (говоря русским языком, "пользователь хочет странного")?

У наших IDE порядка 10 миллионов пользователей, большинство платных. Они все ошибаются? Пали жертвой агрессивного маркетинга? А может такое случиться, что как раз ваши потребности слишком специфичны и не укладываются в сценарии, которые нужны большинству (говоря русским языком, «пользователь хочет странного»)?

Это случается потому, что для джавы Идея — лучше чем остальное (там совсем все плохо), а не потому, что Идея прямо идеальный инструмент.

Кто-то выше утверждал, что Идея идеальный инструмент? Была бы она идеальна, мы бы без работы остались :-)

Как бы без работы бы не остались бы, т.к. постоянно выходят новые версии фреймворков / бд.
Это случается потому, что для джавы Идея — лучше чем остальное (там совсем все плохо), а не потому, что Идея прямо идеальный инструмент.

Применимо для чего угодно. Ничего идеального не существует, а сама идеальность меняется со временем.

Посыл был в том, что много областей, где заставляют писать на Java

Я так же пользуюсь райдером вместо студии и Clion вместо VSCode для раста. А ещё датагрипом вместо прости господи pgAdmin. Ещё эпизодически есть dotPeek/dotMemory/… и некоторые другеи продукты.


В итоге оказывается, что одна ультимейт подписка покрывает все мои потребности в написании лоу-левел кода, круд-кода, прототип-кода на жс или питоне, и даже sql-кода. Не смог найти только плагин для Idris чтобы заработал, пришлось ставить вскод. Ну и текстовые файлики тяжко открывать, получается что-то в таком духе


img


Подводя итог: у нас в компании куплены и VS и Rider лицензии. Изначально все сидели на студии, потом райдеры купили. Так вот за пару лет не осталось ни одного разраба на студии, включая меня.


Всех подкупили, Не иначе.

Реально полное глюкавище распиаренное — пользоваться невозможно. Разве это софт? Вот пойду щас на notepad'e код попишу через экранную клавиатуру и через PowerShell позапускаю. Вот где стабильность, никаких тебе бесячих подсказок, никаких автоподстановок и глюкавых плагинов — только программистский хардкор!

Far Manager FTW: редактор и командная строка в одном флаконе!

говоря русским языком, "пользователь хочет странного"

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

Я хочу странного?

Скорее странно (мягко говоря) поведение JetBrains:

1) маскируются под чехов, на вопросы, заданные на русском языке, отвечают на плохом английском

...

N) Плачутся что их не внесли в реестр "отечественного" ПО

А вы много знаете продуктов мирового уровня, где есть поддержка и документация на русском? Мне на ум приходит MS Windows и некоторые сервисы Google. И то, и другое предназначено для широких народных масс.


Кстати, можно ссылку, где JetBrains плачется по поводу реестра? Ну потому что они очевидно не "отечественное" ПО.

А вы много знаете продуктов мирового уровня, где есть поддержка и документация на русском?

Adobe, например: Illustrator, Photoshop — такая поддержка была лет 10 назад (сейчас — не знаю).

Кстати, можно ссылку, где JetBrains плачется по поводу реестра?

Один из руководителей(?) жыдбрэйнсов сетовал на это в своём интервью, которое вроде даже проскакивало здесь на Хабре.
можно ссылку, где JetBrains плачется по поводу реестра?


31 декабря 2016 Меня разрывает, когда я не могу писать код — интервью с Максимом Шафировым, CEO JetBrains

— Вы будете что-то с Россией специально делать, или воспринимаете рынок таким, какой он есть?

— Он хороший, нам нравится. Зачем с ним что-то специальное делать? Я думаю, что продуктовые российские компании к нам так или иначе все приходят, мы их знаем, вы их знаете. Можно назвать имена, но это ничего не расскажет дополнительного. Есть такой специальный сектор, как государственные компании или просто государственные структуры, вот с ними можно было бы как-то специально работать, но у нас тут случился казус, и теперь им нельзя покупать наш софт!


— То есть для них вы не российская компания?

— Для них мы не российская компания, потому что интеллектуальная собственность принадлежит чешской компании. У нас так устроен бизнес, что чешская компания заказывает разработку российской, российская делает на заказ за денежку, интеллектуальная собственность остаётся на балансе у чешской. Когда вы покупаете что-то, вы покупаете это у чешской компании. А [для продаж госкомпаниям] нужно быть в специальном реестре. И если в этом реестре есть хоть что-нибудь, отдалённо напоминающее конкурента по названию или по рубрике, то вы не можете купить зарубежный продукт, вы должны купить российский.


— Так а ведь нет же никого!

— Фактически нет, а если почитать реестр — то есть.


— Есть IBM с Eclipse, есть Oracle с NetBeans — и они же все тоже иностранные.

— Ты перечисляешь реальные конкурентные альтернативы, а есть бумажные конкурентные альтернативы.


— Это довольно забавно. То есть это всё с импортозамещением связано, с такими вещами?

— Ну, нас это не особо печалит, потому что с точки зрения денег, там их и не было. Нас печалит, что пользователи, которые хотели бы что-то купить у нас, не могут этого сделать, пишут нам «давайте вы внесётесь в этот список, Касперский же внёсся каким-то образом». А мы не можем им помочь. Обидно.


#шизофрения
Так и не видно, чтобы кто-то плакался.
Я хочу поддержки, обучающих материалов и документации на русском языке.

Я хочу странного?

Если коротко, то — да. Я обычно хочу обратного — чтобы все на английском было. Доходит до смешного: например, постгря ошибку авторизации всегда отдает в серверной кодировки, не важно в какой вы там просили её ответить. В итоге рождаются такие смешные костылики: https://github.com/zemian/pgjdbc/commit/bd6de1b360c6a72b5513597813bef3773835e84e


А раньше когда я с MSSQL работал плотно и с виндовыми десктоп приложениями я регулярно пользовался вот этим сайтиком и проклинал создателей локализованных ошибок.


Так что да — странного.

Причём здесь «текст ошибки», который индус перевёл ПРОМТом?

Я говорю о том, что когда в JetBrains русские для русских пишут документацию на плохом английском — это #шизофрения

Как вы перешли от


1) маскируются под чехов, на вопросы, заданные на русском языке, отвечают на плохом английском

к


Я говорю о том, что когда в JetBrains русские для русских пишут документацию на плохом английском — это #шизофрения

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

Как вы перешли от

1) маскируются под чехов, на вопросы, заданные на русском языке, отвечают на плохом английском


к

Я говорю о том, что когда в JetBrains русские для русских пишут документацию на плохом английском — это #шизофрения


Это не я «перешёл», это перешли JetBrains

Я, решая вопрос о закупке ПО выбрал другое ПО (худшего качества, но производители которого не шизофренируют с «больше охват» за счёт отказа, себе в убыток, от собственной русскости).

Сначала я (потенциальный покупатель)
1) обратился в JetBrains на русском языке с вопросом «существуют ли официальные учебные курсы, документация и обучающие материалы на русском языке?»,
потом
2) получил ответ на ломанном английском что ничего такого нет,
затем
3) приобрёл (за деньги) другое ПО другого производителя
и ещё
4) повторил свой запрос (через несколько лет)
— 5) с тем же результатом.

А потом прочитал интервью их CEO(?) в котором он пожаловался, что "не может" торговать своим ПО в РФ.

#шизофрения

У меня в карме счётчик сотрудников жыдбрэйнс, набижавших на хабр.

Ещё раз, для «непонятливых»:

Шизофрения в данном случае — это отказ (по сути запрет самому себе) использовать свой родной язык и попытка «обьяснить» этот отказ «расширением охвата»,

а потом жалобы на то, что охват ВНЕЗАПНО сузился и оправдания в духе «не можем ничего поделать!» —
у нас тут случился казус...


habr.com/ru/company/funcorp/blog/558412/?reply_to=23063292#comment_23063136
русские для русских пишут документацию на плохом английском — это #шизофрения

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

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

А потом прочитал интервью их CEO(?) в котором он пожаловался, что «не может» торговать своим ПО в РФ.

Он же сказал, что точки зрения бизнеса рынок госкомпаний в РФ денег не приносит и ему жалко только с точки зрения патриотизма как личному лицу.

Сначала я (потенциальный покупатель)

Формула «покупатель всегда прав» никогда не работала, работала «если покупатель приносит денег больше, чем стоят его хотелки, тогда он прав».

В данном случае, создание и подерживание русской документации (вместе с английской) будет стоит значительно дороже, чем деньги, которые принесут русские покупатели для которых это критично, даже если учитывать косвенные доходы от лучшего имиджа в РФ.

#шизофрения

шизофрения это Вера, что большой бизнес будет действовать против своих же интересов только потому что так захотелось ВАМ.
В любом случае, придется писать документацию на английском, возможно нанимая англоязычного (не знающего русский) специалиста. Писать дополнительно документацию на русском — значит придется её же спровождать и делать все изменения в двух местах.
Это увеличит стоимость создания документации почти в 2 раза даже если её пишет изначально русскоязычный сотрудник.

вы описываете какой-то «гипотетический» случай. Или случай «общий» (причём вы его считаете общим, а я компания Adobe — нет :-)

А я — практический случай, имевший место быть,
причём случай прямо противоположный:

1) я обратился на русском языке в «чешскую» команию JetBrains по вопросу существования русских же материалов
2) мне человек с русским Ф.И.О. ответил на английском.

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

Полазив по форуму Джетбрэйнс я убедился тогда, что таких случаев (русский вопрос — ответ на плохом английском) несколько, т.е. рациональных причин тут нет, причины русофобии (саморазрушительной в том числе) всегда иррациональны.
2) мне человек с русским Ф.И.О. ответил на английском.

1) Вы не поверите, но человек с русским Ф.И.О. может не иметь русский как родной (коллеги с Украины, Казакстана и те чьи родители давно иммигрировали из СССР передают вам привет), например, Серге́й Миха́йлович Брин хоть русский вроде бы знает, но если бы его вывезли из СССР в более ранем возрасте легко мог бы его уже и не знать,

2) Если вы напишите вопрос на русском на английском StackOverflow, я вам тоже ответ на русском не напишу, потому что у каждого ресурса есть свои правила, в лучшем случае напишу комментарий где попрошу использовать русский ресурс или перевести вопрос на английский,

3) Кстати, вот у меня ни на одной клавиатуры (ни дома, ни на работе) нет русских букв, разумеется, лично я давно освоил слепую печать однако знаю много сотрудников (тестировщиков, HR, иногда даже программистов), которым приходится писать транслитом при общении на русском или долго искать где же находится та или иная русская буква,
Вы не поверите, но человек с русским Ф.И.О. может не иметь русский как родной (коллеги с Украины, Казакстана и те чьи родители давно иммигрировали из СССР передают вам привет),

человек с русским ФИО, сидящий на Васильевском острове в СПб?
вы утверждаете, что они шпионы что ли :-)

JetBrains. Офис по принципу «сделать людям комфортно» 16.07.2014 Марина Кван
Представьте, у них есть офисы и за пределами РФ.

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


Но страждующие увидят и в этом русофобию. Это как радикальные SJW, но в отношении своего этноса. Так и ищут чем бы ещё оскорбиться :) Полезный навык наверное.

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

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

Давно это было?

Если надо ЕЩЕ примеров на тему "не того" языка -:)
то можно придраться к тому что Kotlin in Action / Kotlin в действии изначально написана на английском хотя казалось см хотя бы тот факт что авторы вычитывали текст после переводчика на русский (что не скрывается — https://habr.com/ru/company/JetBrains/blog/339400/ )


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

Кстати вот не факт что перевод — лишний, мне (с родным русским) не раз уже встречалось что я не знаю как что-то сказать на русском, ну вот просто не знаю перевода термина, или что хуже — знаю что есть несколько переводов, и часть из них — явно кривые.

Кстати вот не факт что перевод — лишний, мне (с родным русским) не раз уже встречалось что я не знаю как что-то сказать на русском, ну вот просто не знаю перевода термина, или что хуже — знаю что есть несколько переводов, и часть из них — явно кривые.

А никак не надо переводить. Вот как перевести на русский слово атмосфера (греч.), галоши (франц.), зонтик (голланд.), бутерброд (нем.)? Да никак, просто берется слово вместе с понятием.


Можно изобретать колоземицы и мокроступы, но наверное не стоит.

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


ЧТО вы «не знаете как сказать по-русски»?!
есть ли документация, поддержка и обучающие материалы на русском языке?

со смыслом слов «есть» и «нет» затруднения?

или они вам кажутся неудачными кальками глагола 'to be' (are) и английского неоднозначного 'No'?
ЧТО вы «не знаете как сказать по-русски»?!
Комментарий был не в контексте Kotlin'а/Java'ы а вообще программирования.
при этом с точки зрения репутации лучше не иметь русской документации, чем иметь устаревший и кривой перевод с английского


с точки зрения здравого смысла я купил продукт дороже по цене и худшего качества у компании Adobe, которая ничего зазорного в русском языке не видела.
купил продукт дороже по цене и худшего качества у компании Adobe

Ну может потому и дороже и хуже, что компания Adobe потратила деньги на русскую/китайскую/монгольскую документацию? Вы же понимаете, что за все заплатит конечный покупатель?
и я заплатил — за то, что мне было нужно.
А джетбренс — вместо «выше охвата» потеряли деньги.
Уверен, их очень расстроили недозаработанные 100$ в год.
Уверен, их очень расстроили недозаработанные 100$ в год.


тогда не было модели «подписки», так что не в год

я заплатил что-то порядка 500 $ Адоуби единовременно, софт работает в пределах ветки, лицензия «навсегда»
шизофрения это Вера, что большой бизнес будет действовать против своих же интересов только потому что так захотелось ВАМ.

шизофрения — это аппелировать к «большому бизнесу», который создаёт и поддерживает документацию на русском и никаких репутационных рисков и «ниже охватов» из-за этого не имеет.

Как раз для большого бизнеса никаких «народов-изгоев» нет и не может быть — Google.ps тому пример

Какая связь между наличием русской документации и попаданием в госзакупки?

У меня не «госзакупка», мне просто нужно было какое-то «лицензионное» ПО (с бухгалтерсикими документами).

Я хотел отечественное, ДжетБрейнс сильно не хотели и играли в иносранцев
Причём здесь «текст ошибки», который индус перевёл ПРОМТом?

То есть майкрософт который со штатом лингвистов вполне неплохо перевел текст — это индусы с промптом виноваты? А не то, что современные системы поиска не могут найти англоязычные ответы как решить ошибку "повторяющееся значение ключа нарушает ограничение уникальности" при использовании библиотеки по работе с pdf.


Я говорю о том, что когда в JetBrains русские для русских пишут документацию на плохом английском — это #шизофрения

Они не для русских пишут — а для себя и в паблик в том числе. Да и у себя там не 100% арийцев рускоговорящих. У нас вот например в компании на 50 человек 45 русских. И ничего, общаемся все на английском, чтобы оставшиеся 10% компании не выпадали из процессов. Заодно тренируем язык.

майкрософт который со штатом лингвистов вполне неплохо перевел текст


Я достаточно часто встречал в интерфейсе Windows перлы типа «запись изображения на диск» (подразумевался ISO-образ), не считаю такой перевод хорошим.

Не понял как ваш пример связан с обсуждаемой мной темой.

По-вашему, русскоязычные [потенциальные] пользователи искали бы ответ на свой вопрос (наличие интересующего их русского языка) на английском?
Они что, шизофреники?
По-вашему, русскоязычные [потенциальные] пользователи искали бы ответ на свой вопрос (наличие интересующего их русского языка) на английском?

Я ищу исключительно на английском вопросы и документацию, да.


Во-первых потому что поиск более высокое качество имеет и больш выборка. В гугле вопрос на английском находится в первых нескольких строках выдачи, в яндексе на русском можно перелопатить первые 3 страницы и видеть только вопросы на мертвых форумах с битыми ссылками.
Во-вторых потому что тупо проблемы с терминологией, из-за чего ищется не то. Например Generics — у кого-то это генерики, у кого-то дженерики, у кого-то обобщения. У кого-то ещё как-то. Если я напишу запрос "ошибка обобщения Х" то я не найду ответ если кто-то написал "ошибка с генериками Х".


Про перевод вещей а-ля Stream/Thread/Flow я молчу — тупо "поток потока потока" — удачи найти что-нибудь. Использовали "потоки" и "нити" в поисковом запросе чтобы их разделять? Надейтесь, что и другие люди так же написали, а то гугол не найдет

Я ищу исключительно на английском вопросы и документацию, да


ну вот и потенциальная ЦА шизофренического поведения джэтбрейнз

— u vas est' dokumentatsiya na russkom yazyke?
— yes, off cause! Google for «russkaya dokumentatsiya dlya phpshtorm»!
Доля программистов, которые не сумели в английский (хотя бы на уровне гуглинга и чтения документации) — исчезающе мала, AFAIK. И часть из них — это 1С программисты :) Так зачем тогда ради них стараться?
Вы мне опять рассказываете про какую-то гипотетическую ситуацию. Я а вам — про реальный случай когда погромист с upper intermediate английским купил adobe dreamweaver за 500 долларов и не купил webstorm за 300 сколько он тогда стоил

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

Есть одно но, помимо взрослых есть дети (до 10-12 лет скажем) которым читать документацию на неродном языке сложно, увы, в итоге хотел ребёнка, после Scratch, MinecraftEdu, изучать kotlin (в связке с андроид) Но увы... Именно английский везде его оттолкнул (даже с учётом того что я готов был сидеть рядом и просто переводить всё что написано).

Играл в Dune, Warfcraft: Orc & Humans, первую циву… — никаких переводов не было, и ничего — всё понимал :) Было мне лет 5 на тот момент. До 5 лет играл в русифицированные квестики вроде кирандии.


Наоборот, лучше одноклассников шарил в языке класса до 8го

Вам не кажется что изучение программирования "методом тыка" когда нужно программу печатать буквами которых 20+ и играть в игру в которой всё визуально и надо использовать 10к кнопок с весьма информативными иконками это немного разное....

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

Я считаю, что детям не нужно читать документацию — она для них скучная. Какая-нибудь книжка "Питон для самых маленьких" будет переводная, и это не вопрос. А ребенок постарше (5-8 класс) пусть уже английский понемногу подучивает — все равно пригодится.


и играть в игру в которой всё визуально и надо использовать 10к кнопок с весьма информативными иконками это немного разное....

Ну я вот не уверен насколько тут информативные иконки например… Моя первая игра которую я начал играть в 2-3 года:
image


Как-то в итоге разобрался :)

Думаю записи геймплея нет, а так дети в годик могут играть в любую игру не понимая смысла, старший не умея читать и нормально говорить спокойно "читал" книжки про колобка перелистывая страницы и выражая вполне себе эмоции взрослых, которые ему эту книжку читали до этого, особенность только в том что его (как и вас в 2-3 года интересовали только меняющиеся картинки и вы понимали что тыкая что то на экране вы можете что-то поменять, но вот проблема к изучению программирования это не имеет никакого отношения, а вот когда возникает вопрос "почему тут у меня ошибка и программа не работает) тут уже надо читать (хотя бы сообщения и что написано на вкладках).

А ведь есть спец версия idea education edition к примеру, там для детей много чего бы подошло, если бы не только английский...

Ну выигрывать игру на самой простой сложности как-то получалось. Видимо, все же не совсем "перелистывание картинок". Есть вполне простой критерий — окно победы.


А ведь есть спец версия idea education edition к примеру, там для детей много чего бы подошло, если бы не только английский...

Для детей офк перевод нужен. Но для детей нужны книжки, а не документация. Скучный справочник ребенку совать бесполезно.

  1. Это перебор всех возможных вариантов, с закреплением (хотя насчёт того что ваша память от возраста 2-3г. соответствует реально происходившим событиям есть сомнения (и тут статьи со ссылками на исследования были, про память) ну может вы вундеркинд, я не по себе сужу а по своим детям...

  2. Что такое офк не понял, но про книжки вы наверное мыслите "от себя" увы но ребёнок хочет иметь возможность "творить" и иногда "подсматривать" а на идти по инструкции (этого в школе хватает) книжки этого не дают.

  3. Я всё же про возраст когда на русском мы уже читаем относительно быстро и не встаём от этого(в среднем это где-то от 8 до 10 лет), а вот на английском ещё никак, при этом ограничения сред типа Scratch уже сильно мешают. (Про отдельных детей которые бегло читают на 2х языках в 6 лет речь не идёт)

А где задавали вопросы на русском? Кажется, в ZenDesk отвечают по-русски на русские вопросы.

Эта история началась в 2010.
Я рад что JetBrains стали чуть адекватнее с тех пор.

маскируются под чехов

Странно. Мне вполне отвечают по-русски. Может ты правда на чеха попал? :)

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Яндекс, Mail.ru. Во первых это коррумпирует, так как вместо работы по профилю, фирма вовлекается во всякие схемы. Во вторых моральный аспект — платя подписку JeBrains опосредованно поддерживаешь нелигитимный режим


«нелигитимный режим» — это ГДЕ?!

В Чехии, где зарегистрировано юрлицо JetBrains?

Или в нидерландском аэропорту (где прописан yandex zoekmachine)?
Или в Британии и на Кипре (откуда родом MAIL-RU)?
«нелигитимный режим» — это ГДЕ?!

А как же ВШи?

Как раз напротив одного из офисов JetBrains расположены, и рядом композиция, изображающая пословицу «хуже дурака только дурак с инициативой»

image

Рука поднята, головы нет
Сраликов? Который русских вдов и сирот Донбасса обворовал?
Спасибо, НИНАДА
Каждый из продуктов сам по себе неплох — но если вам приходится писать на двух языках сразу (PHP/Python или Python/C++), вы скажете немало горьких слов.

VSCode использует Eclipse Language Srever (через Language Server Proticol). Получается, что и eclipse это тоже умный блокнот?

IDE - это не только LS

IDE это совсем НЕ LS. Например, у сишарпа IDE — Vistual studio, а LS — Roslyn

Развесистая - это пара миллионов строк и больше. Моя ставка - что ближе к миллионам пяти, считая более поздние не-IDE проекты. Поддерживать и развивать такие монолиты - настоящий трудовой подвиг)

А что мешает их делать не как монолиты а как модули/компоненты? Вроде бы как есть экспертиза.

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

Хорошо что для C# есть VS
IDEA у Jetbrains самая взрослая, и меньше багов мешающих работать, в остальных IDE встречаются довольно часто совсем критические баги. Некоторые запросы которые им писались в багрепорт 3-4 года назад до сих пор не выполнены, хотя технически там исправить некоторые можно довольно быстро.
Самая взрослая и самая легаси. Как-то писалось, что скины у них были настолько захардкожены, что темы просто гвоздями были прибиты.

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

3-4 года? Это мелочи. Есть тикеты, которые по 15 лет висят!


хотя технически там исправить некоторые можно довольно быстро.

Бывает так, что технически исправить просто, но не нужно.

Бывает так, что технически исправить просто, но не нужно.

Для непосвящённых звучит, честно говоря, в лучшем случае довольно странно. Можете как-то пояснить на примере?

Такие примеры появляются с завидной регулярностью (говорю про свою подсистему — язык Java). Вот буквально сегодняшнее. Пять лет назад пользователь попросил прокачать анализатор, чтобы он понимал, что метод интерфейса-аннотации никогда не возвращает null. Чтобы при сравнении с MyAnno.value() == null выдавалось Condition is always false. Изменение буквально пять строчек кода плюс тест. Очень просто. Мы сделали. Правда сам пользователь написал:


(technically, annotation.x() can be null, if someone implements FooBar annotation explicitly, but I guess nobody does it).

И вот на днях другой пользователь жалуется, что ему выдаётся ложное предупреждение, потому что "I guess nobody does it" реализуется в некотором фреймворке. А ложное предупреждение — это гораздо более неприятная ситуация, чем отсутствие правдивого предупреждения. Потому что пользователи верят предупреждениям и могут сломать себе код, удалив проверку, которую IDE пометила как ложная. Простой пример фичи, которую не надо было делать, несмотря на то что она простая.

Нет, не такие запросы. К примеру, что в clion нельзя указать toolchain файлы cmake, нельзя указать переменные среды с помощью bat или shell скриптов, во вторых параметры для CMAKE удобно писать в много строчном режиме, в одну строку писать конечно хорошо, но там вмещается всего 2 параметра, и остальные не видно, и не удобно перемещаться по параметрам, ваши разработчики видимо не пишут сборочные скрипты для серьезных проектов? Все это ломает работу с крупными проектами. Понятное дело с простенькими скриптами созданными cmake комфортно работать, но с чем-то крупным нет. Clion жрет память как не в себя, не может проанализировать даже не очень крупные C и C++ проекты, начинает дико тормозить и жрать память, чтобы сделать вид, что эту проблему решили в Clion, просто включили ограничения на размеры файлов и их просто пропускает. Ошибки qt, которые ломают анализатор, автодополнение, кривая поддержка st embedded — у меня даже проекты не открывает. Вроде функционал заявлен, а все глючно. Rider тоже глючный и сыпется на моих проектах. Поддержка wls кривая. Ваши продукты только около веб разработчиков покрывают, кто занимается серьезной разработкой даже не подумают переходить на ваши продукты, потому что капец как все сыро там. Говорю же вы смешные, и отмазки смешные вечно лепите. Как обычно ответ «сам дурак», у нас все круто, у нас миллионы пользователей.
в clion нельзя указать toolchain файлы cmake, нельзя указать переменные среды с помощью bat или shell скриптов

Clion жрет в память как не в себя, не может проанализировать даже не очень крупные C и C++ проекты, начинает дико тормозить и жрать память

Ошибки qt, которые ломают анализатор, автодополнение, кривая поддержка st embedded — у меня даже проекты не открывает

Это вы перечислили проблемы, которые по вашим словам "технически можно исправить довольно быстро"?

За 3-4 года вполне… А вот еще вы мне напомнили, в дебагере clion нет просмотра переменных в бинарном и 16ричном формате, т.е. он есть но в эсперементальном виде и только в 16ричном формате. Когда gdb и lldb умеют все это из коробки, и их использует clion.
Но 200 баксов же вы берете? Это же не VS Code, сделаем когда сделаем.
во вторых параметры для CMAKE удобно писать в много строчном режиме, в одну строку писать конечно хорошо, но там вмещается всего 2 параметра


Это тоже тяжко сделать?
Но 200 баксов же вы берете?

Да, берём. И нам совершенно не стыдно. А что, где-то есть продуктовая компания, которая за 200 баксов вам все желания исполняет? Подскажите такую.


Это тоже тяжко сделать?

Не моя подсистема, не могу знать.

Есть MS, которая дает мне бесплатный Visual Studio. Да, там не все есть, что нужно как в Pro, но все равно можно доставить CodeMaid и Visafora и более менее работать. Я не требую от бесплатного продукта особо много, но тем не менее, он почему-то поддерживает новые версии Blazor с их появлением, а не через 3 месяца.

В бесплатной версии Idea работать нельзя. Соответственно, я плачу деньги. И тут такой вопрос, если я плачу, то почему проблемы не фиксятся годами? Мало плачу? Ну давайте буду платить 999, как за VS Pro. Однако что-то мне подсказывает, что ничего не поменяется.

Вот как всегда в спорах в интернете. Я задал один вопрос, а мне отвечают на другой. Звучит примерно как "Тут благотворительная организация бесплатно бомжам вкусные котлетки раздаёт, а вы продаёте за пятьдесят рублей и не можете фарш качественный накрутить".


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

Супер, оказывается потенциальные пользователи продуктов Jetbrains бомжи, хорошее начало… Что и писал выше, сотрудники Jetbrains смешные и не умеют реагировать на конструктивную критику… В VS Code есть OSS сборка, там нет телеметрии и проприетарных компонентов.

Тут, если не выпадать из контекста, смысл получился как раз таки наоборот: те, кто пользуется бесплатной версией VS - бомжи. А пользователи Jetbrains  возмущаются что им мясо плохо накрутили. ))))

НЛО прилетело и опубликовало эту надпись здесь
Соврал, все таки завезли многострочный режим, только что проверил.
Вот, работа идет.

Тулчейн файлы можно указать через параметры CMake. В 2021.2 еще завезем поддержку новомодных CMake прессетов. Про параметры среды через скрипты — есть такая беда (мы вместе с платформой думаем пока, как это решить), но кто мешает в самом CMake это все указать?


Память — мы постоянно оптимизируем потребление памяти в CLion, но я замечу, что даже простенький Hello World после препроцессора не такой уж маленький на C++, так что не удивительно, что CLion после сборки информации о резолве кода во всех конфигурациях со всеми инклюдами и ветвями препроцессора отъедает много памяти. Так что оптимизировать там не всегда можно. Но что-то мы уменьшаем постоянно.


Про ошибки Qt — я бы послушала примеры и передала ребятам, они поправят. Честно сказать, уже давно не видела Qt проблем в анализаторе и автодополнении.

Слышал что появление rider это в том числе и результат того что студия просто начала не вывозить весь солюшн решарпера. Что там в IDEA тогда я вообще представить боюсь.
Вот в этом эпизоде подкаста devzen в интервью с гостем подробно разбирается, почему электрон не подходит для построения отзывчивой IDE: devzen.ru/episode-0331 Если очень коротко — потому что в своей новой ide JetBrains собирается увеличить отзывчивость на порядок, приблизив её к «чисто текстовым» редакторам типа vim. И при таких амбициозных планах им с электроном не по пути. Но интервью действительно интересное
Бред полнейший! Поэтому продукты Jetbrains тормозят? Видимо так проявляется более высокая отзывчивость? Собирается, это не значит сделает. Вот вы к примеру собрались из дома выйти, но не вышли и в итоге ни куда не пошли… Если в electron не тригерить часто сборку мусора и перерисовку стилей, то там вполне можно уложится в пару десятков ms. Основная проблема всех платформ это разработчики, в случае electron порог входа ниже и там менее грамотные разработчики, отсюда есть серьезные баги в некоторых плагинах и они медленно работают. Но у IDE тоже не все так хорошо, как вы тут расписали…

В какой-то момент, мне казалось, что языком "как Java, только лучше" мог бы стать Groovy.

alexanderniki а автор Groovy сказал:

По мнению Джеймса Стрэчена[en], создателя языка программирования Groovy, Scala может стать преемником языка Java[5].


Стрэчен покинул проект за год до релиза Groovy 1.0 в 2007 году, а в июле 2009 года Стрэчен написал в своём блоге, что возможно не создал бы Groovy, если бы в 2003 году прочитал книгу Мартина Одерского с соавторами о программировании на языке Scala (вышедшую в 2007 году)[3].
НЛО прилетело и опубликовало эту надпись здесь
В какой-то степени так оно и есть. Просто лучше — это не лучше для всех. Это лучше в определенных задачах. У него есть своя достаточно стабильная, хоть и не очень большая ниша. Я лично его применяю с тех пор как он появился, и до сих пор, и знаю других людей, кто делает тоже самое. И да, это даже не gradle и не jenkins.
Groovy хорош для написания своих DSL, плюс для него есть dsld и сразу получить autocomplete для этого DSL. Единственная проблема — на dsld найти нормальную документацию непросто, такое ощущение, что проект подзаброшен (или просто некому эту документацию делать).
Была задача подключить скриптовый язык близкий к java с пробросом ряда переменных в скрипт. Выбирал между groovy и kotlin, по kotlin нашел описание проблемы, что по сравнению с groovy использование в качестве скриптового языка работает медленно. А groovy зашел на ура, особенно понравилось в нём сборка xml.
Ну еще у груви есть чистый синтаксис, т.е. литералы для списков, мапов, и т.п., билдеры, то есть код получается лаконичный, даже и без DSL. Насчет заброшенности — ну его же реально забросили, хотя потом Apache его подобрали — но какое-то время реально было состояние, что не поймешь, будет когда-то релиз еще, или уже нет.
Когда var в Java появился? А когда зарелизился Kotlin?

Спору нет. Но об этом вот в статье тоже есть.

Скорее new Foo<Bar> ctrl+alt+v, остальное само допишется.

Нет проблемы это дописать. Проблема — потом это читать

Advanced code folding plugin для желающих есть.

У JetBrains, я думаю, одна из самых развесистых Java-кодбаз в мире.

Видимо, вы мало знакомы с развесистыми кодовыми базами. У нас довольно скромно по сравнению с некоторыми компаниями, которые активно используют Java.

Я действительно не знаком с кодбазами больше 1м LOC. Было бы интересно послушать мнение человека более осведомлённого.

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

Мне интересно, угадал ли я с оценкой в 5м LOC для всей кодбазы JetBrains, или 2м LOC общей кодбазы всех IDE?)

Нет, не угадали. Только кодовая база IDE превышает 10M LOC (без комментариев и пустых строк). И, повторяю, у нас ещё скромно.

Вам не кажется) В каком-то интервью говорили

Мне кажется, рывок развития Java в последнии годы во многом был связан как раз с успехом Kotlin. JetBrains заставили Oracle проснуться.
DenisB12 JAVA в топе популярных языков последние 20 лет. Очень много бизнес софта на нем написано. И все это было далеко до kotlin. Язык изначально был с хорошей выразительностью, и быстрой обучаемостью. Синтаксический сахар до контлина еще был в C#.
безусловно. Я не спорю, что Java в топе, и будет в топе еще многие годы. Но это не отменяет того факта, что Kotlin отваевывает кусок рынка Java, особенно в Android-разработке. Да и back-end последнее время всё чаще пишется на Kotlin.
Сомневаюсь, что то так с ходу даже не вспомню какой нибудь крупный и известный проект на kotlin, кроме их IDE. И как правильно выше написали, тому причина проприетарность. Не изучал лицензию, но думаю, там тоже не все гладко для разработчиков.

Apache 2 на компилятор, библиотеки и плагин. Который кстати доступен в Intellij IDEA Comunnity Edition. Как говорится, не изучал, но осуждаю. Тем временем 80% процентов Android уже на Kotlin, куча бекенда на Kotlin https://kotlinlang.org/lp/server-side/case-studies/ (в том числе банки American Express, N26, Tinkoff, etc)


По разным пузомеркам у котлин уже минимум 20% отъедено от джавы. Джава кстати уже не растет последние 3-4 года, а наоборот стагнирует.

По вашей ссылкам там некоторые ссылки, что не используют они, а просто есть биндинги на kotlin для их продуктов))) Как вы всех Android разработчиков или приложения посчитали?)

А я думал там все компании в мире отметились, оказывается нет. Можете добавить IAC тогда в которой я работаю и пишу критикал приложения и аналитику на Kotlin.


Сомневаюсь, что то так с ходу даже не вспомню какой нибудь крупный и известный проект на kotlin, кроме их IDE

Спросите джависта (который не пишет на питоне) про крупные и известные проекты на питоне, большинство не назовет ничего практически. Спросите питониста который в глаза джаву не видел, он скажет что весь мир крутиться на питоне. Такие аргументы (ну которые отталкиваются от ваших представлений об объективной действительно) смехотворны, да и вообще не аргументы.


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

Научитесь делать выводы основываясь на фактах что-ли :)


Как вы всех Android разработчиков или приложения посчитали?)

https://android-developers.googleblog.com/2021/05/whats-new-for-android-developers-at.html


Kotlin: the most used language by professional Android devs

Kotlin is now the most used primary language by professional Android developers according to our recent surveys; in fact, over 1.2M apps in the Play Store use Kotlin, including 80% of the top 1000 apps. And here at Google, we love it too: 70+ Google apps like Drive, Home, Maps and Play use Kotlin. And with a brand-new native solution to annotation processing for Kotlin built from the ground up, Kotlin Symbol Processing is available today, a powerful and yet simple API for parsing Kotlin code directly, showing speeds up to 2x faster with libraries like Room.

Ну вот, стоило мне порадоваться уровню дискуссии( Постарайтесь, пожалуйста, не переходить на личности, это не помогает вашей аргументации, а ровно наоборот.

Как вас батенька разнесло. А был лишь вопрос про то, как вы посчитали Android разработчиков. Вопрос вполне резонный, так как вы сами написали про 80%. Поэтому грамотных людей вполне заинтересует методология. И тут не мало людей, кто хорошо знаком со статистикой, им будет интересен ваш личный опыт, как собирались и анализировались статистические данные. А вместо ответа, начался переход на личности… Но все мимо, на JAVA программирую с середины 2000-х.

Забавно, что относительно Котлина вы приводите конкретные цифры, названия компаний и ссылки и тут же бросаетесь голословным утверждением о стагнации Java последние 3-4 года без всяких подтверждений. Java сейчас очень бодро развивается.

Java как язык конечно да. Увеличивается ли от этого значительно его популярность или это попытка удержать позиции? Массовый исход огромной индустрии Android разработки на Kotlin будем учитывать? :)


На последнем Kotlin 1.4 Online Event было представлено, что около 5.8млн разработчиков попробовали котлин (редактировали код в IDE), а также около 1.2млн активных пользователей Котлин [https://youtu.be/xJawa3C6pss?t=826]. По статистике самой JB в мире около 6.8млн разработчиков Java [https://blog.jetbrains.com/idea/2020/09/a-picture-of-java-in-2020/]


Это соотношение подтверждается различными рейтингами redmonk/pypl/etc
Или данными на Stackoverflow https://insights.stackoverflow.com/trends?tags=kotlin%2Cjava%2Cgroovy%2Cscala


Есть и другие анекдотические совпадения, так например число людей в сабредите Kotlin [https://www.reddit.com/r/Kotlin/ https://www.reddit.com/r/java/] около тех самых 20%


Откуда пришли эти разработчики? У меня нет четких статистических данных, но на митапах которые мы проводили, опросы показывали что в зале сидят бывшие джависты. Получается джава потеряла большой процент (около 20%) разработчиков за 5 лет, это ли не стагнация?

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

В Android ситуация с Java совсем печальна. Там все остановилось на Java 8. Собственно поэтому Kotlin и выстрелил именно в Android, так как там нет альтернативы.

Вы похоже еще не обновились на Android Studio 4.2

Там уже используется Java 11

Мы, собственно на котлине сидим, поэтому этот момент я не заметил. Но проблема еще и в том, что наше приложение поддерживает Android начиная с 6 (23 sdk), а это java 6. Там еще раньше и с котлином иногда проблемы вылазили, когда в рантайме не находилось нужного класса или метода на старых девайсах. Сейчас вроде такого не было давно, может компилятор подфиксили.

Да, наверно пофиксили. Я пишу под Android начиная с 5.0 - на старых девайсах проблем с использованием Java 8 не замечал.

А ART во всех версиях андроид что используют клиенты тоже до уровня Java 11 обновился с выходом Android Studio 4.2?

Конечно нет. Но уже можно писать код на Java 11 под Android, а то будет ли он вообще работать на старых устройствах или будет заменен на другой код - это другой вопрос.

Моя ошибка — надо было блогпост про релиз ASO 4.2 прочитать. После чтения гугловского блога более подробно — теперь яснее.
Конструкции языка — да, будут работать. Насколько понимаю — на любом андроиде.
Библиотечные API — вообщем все плохо. Как и раньше — работает (на любом андроиде) только то что указано в https://developer.android.com/studio/write/java8-support-table


Ну уже неплохо.

В Android как бы у Kotlin большое преимущество в том что то что вместо JVM(ART) у Android не обновляется почти в плане поддержки новых версий (а даже если бы и обновлялось — у андроида все далеко не хорошо с обновлением системы а значить — привет совместимость. ART хотя бы потенциально обновляем отдельно от самого Android начиная Android 10).
А Kotlin'у на версию JVM плевать вообщем то. Что в данной ситуации — огромное преимущество. Для Android разработки — Kotlin не с вышедшей полгода назад версией Java сравнивать надо а с Java 8 в лучщем случае.

НЛО прилетело и опубликовало эту надпись здесь
Именно!

Оригинальный автор неправильные выводы делает.
Показателен кусок про
В Java вплоть до 14-й версии это выглядело так:
Скрытый текст
if (x instanceof String) {
    String y = (String) x;
    System.out.println(y.toLowerCase());
}

В Kotlin сделали примерно так:
Скрытый текст
if (x instanceof String) {
  // теперь x имеет тип String!
    System.out.println(x.toLowerCase());
}

Но в Java версии 16+ стало так:
Скрытый текст
if (x instanceof String y) {
    System.out.println(y.toLowerCase());
}
Не дай Kotlin пинка, Java так и осталась бы без фич. А так хоть с «худшего языка» их взяла. Kotlin прокладывает путь для Java, и, очевидно, это сложно. Поэтому и вылезают проблемы, когда Java догоняет обратно
Переходить же с Java на Kotlin будет по-прежнему легко, т.к. уже Java адаптируется, а не Kotlin, идущий во фронтире. Значит новые версии Java всё более будут похожи на Kotlin
Не дай Kotlin пинка, Java так и осталась бы без фич.

Это да. Поговаривают даже, что дженерики в пятую джаву завозил лично Бреслав :)

В жабу внесли плохую фичу. В этом примере — 16+ вариант это синтаксический сахар для варианта 14+, с неявным созданием экземпляра класса, а в Котлине это неявное преобразование типа внутри.
Причём жаба как-то неинтуитивно модифицирует поведение самого оператора instanceof.

Какого экземпляра класса? Вы о чём? Никаких экземпляров не создавалось ни до, ни после.

"y" это что?

Локальная переменная.

String это уже базовый тип?

Удивительно, что люди рассуждают о дизайне языков программирования, не зная этих языков программирования даже в самом минимальном объёме. Я на третьей лекции по Java для начинающих уже рассказываю, что присваивание в Java копирует ссылку, но никогда не копирует сам объект, потому что это никому не нужно и копирование объекта в Java в общем случае неразрешимая задача. Причём JIT-компилятор может и копирование ссылки соптимизировать (и сделает это практически всегда в данном сценарии кода, потому что нет причин так не делать).

Вот я даже картинки из лекций нашёл, где показано, что при присваивании мы ссылаемся на тот же объект и можем его поменять:


Если они таки смогут нормально продвинуть мультиплатформу, то всё будет хорошо

А мне кажется java тоже уйдет на покой. Либо rust победит, либо им придется делать аналогично — т.е. будет +- та же java по синтаксису, но без GC. Т.к. rust сложнее для простых задач, должно появится что-то среднее между rust и java. Конечно это не так скоро будет, но у java уж слишком большой оверхед.

Java и Rust — это вообще два разных языка. Первый для больших (квази-)монолитных прикладных задач, второй — для системного программирования.

Вы ошибаетесь. Rust — универсальный ЯП, хоть и позиционируется прежде всего как системный. Поэтому так медленно и отвоевывает себе рынок. Реально Rust так же интересно использовать в прикладной разработке, как и в системном программировании, если не интереснее.

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

Сборка мусора превращает простые программы в неповоротливых монстров.
Вон, тот же Go это просто нативная Java. И проги на нём жрут оперативки ого-го! Да и мир приходится останавливать на время работы GC.
Вы тут прям собрали в одном сообщении буквально все страшилки начала нулевых…
Так я пользуюсь этими программами, и вижу сколько они занимают в памяти. Зачем мне врать?

У меня есть pet-project на Go, это IoT-сервер с большим REST и WS API, очередями, внутренними кэшами и т.д. Он занимает в памяти 50 мегабайт и работает на Raspberry Pi. Всё, как обычно, зависит от решаемых задач и умении инженера избегать лишних аллокаций.

А у меня pet-project на Расте, это DNS на базе блокчейна. Там DNS-резолвер с кэшем и т.п. Версия без GUI занимает в памяти 2Мб, а бинарник 1,6Мб. А с GUI на базе веб-вью занимает 20Мб и весит 3,5Мб.
Вон, тот же Go это просто нативная Java
Вы простите, но я не верю, что человек, трогавший оба этих языка хотя бы 15 минут каждый, может такое всерьёз сказать. И это даже не говоря об остальном.
Да дело не в трогании, а в использовании. Просто по наблюдениям получается так, что продукты на Go сейчас жрут довольно много памяти, больше чем Растовые, например.

Казалось бы, потребление памяти - далеко не единственный критерий сравнения языков программирования.

А продукты ещё и написать можно по-разному.

Ну вот в первом своём комменте я имел ввиду именно это. Ни синтаксис, ни поддержку архитектур, ничего больше.

Помню когда-то давно читал о (почти) рандомизированном исследовании, где программистов пригласили решить какие-то задачи на Си или Яве.


The conclusions showed that Java was 3 or 4 times slower than C or C++, but that the variance between programmers was larger than the variance between languages, suggesting that one might want to spend more time on training programmers rather than arguing over language choice. (Or, suggesting that you should hire the good programmers and avoid the bad ones.) The variance for Java was lower than for C or C++. (Cynics could say that Java forces you to write uniformly slow programs.)


выделено мной

Выжимать скорость надо в нескольких процентах от всегда кода. Самый яркое это разные БД. Там каждый процент ускорения дает миллионы долларов экономии на серверах.

А вот в обычном серверном софте зачем? Ну будет он потреблять вместо пяти десять ядер. И что? Даже по ценам Амазона это все копейки.

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

Где же, блин, язык с RAII и сборщиком мусора? Не хочу руками закрывать файлы.

Справедливости ради, закрываются они не совсем руками, а через всякие "try with resources".


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


Из этой же оперы: не понимаю как люди мирятся с невозможностью "передать по константной ссылке". В том плане, что по сигнатуре функции не видно будет ли она менять переданные объекты. В полностью иммутабельных языках это действительно не важно.

Из этой же оперы: не понимаю как люди мирятся с невозможностью "передать по константной ссылке". В том плане, что по сигнатуре функции не видно будет ли она менять переданные объекты. В полностью иммутабельных языках это действительно не важно.

Я лично решаю это тем что классы иммутабельные и для изменения чего-то нужно делать глубокую копию. Кажется что неэффективно, но засчет fearless sharing как раз можно хорошо жить.

Я не в теме: а все стандартные классы тоже иммутабельные? Если да и в библиотеках тоже придерживаются такого подхода, то вероятно проблемы и нет.

Есть стандартный неймспейс System.Colletions.Immutable где есть всё, что нужно.


Многие библиотеки которым позарез нужна иммутабельность (например, Roslyn) используют их по умолчанию

НЛО прилетело и опубликовало эту надпись здесь

Сразу оговорюсь, что в хаскеле я не особо разбираюсь, так что могу сказать глупость, но вижу, что кроме withFile есть и openFile. То есть, можно воспользоваться второй функцией и забыть вручную закрыть файл. Если апи использует RAII, то для этого потребуются специальные приседания.


И как быть если файл у нас вложен в другой объект? Какой-нибудь SomeManager внутри которого содержится ресурс (а может и не один). В деструкторе такого "менеджера" даже делать ничего не нужно. Правильно я понимаю, что в подходе с withХ придётся это всё протаскивать наружу?

НЛО прилетело и опубликовало эту надпись здесь
Так и в плюсах можно случайно вместо #include <fstream> сделать #include <чётосишное> и использовать старый-добрый fopen. Даже приседать не надо.

Я всё-таки больше раст в уме держал: там настолько легко сишные функции протащить не получится. Впрочем, у fstream интерфейс тоже достаточно отличается от сишного, чтобы это не прошто незамеченным.


Насчёт линейных типов и монад: изначально всё-таки речь шла про RAII против языков с GC. Формально, конечно, хаскель и прочие попадают во вторую категорию, но я верю, что там всё сделано достаточно хорошо и интересует как в C#/Java.


чего не было доступно во времена Haskell98, да и сейчас не факт что в хаскеле можно

Насколько я понимаю, все пользуются System.IO "без заморочек"?..


Да не особо. Там, конечно, появляется уровень абстракции в виде всяких управляющих ресурсами монад, но with вам тягать везде не нужно.

Если не лень, то я бы хотел взглянуть на пример. Только желательно с комментариями.

Насчёт линейных типов и монад: изначально всё-таки речь шла про RAII против языков с GC. Формально, конечно, хаскель и прочие попадают во вторую категорию, но я верю, что там всё сделано достаточно хорошо и интересует как в C#/Java.

так тот же бракет сделано в сишарп/джаве с using/try-with-resources. В этом плане тут паритет

НЛО прилетело и опубликовало эту надпись здесь
Ну withFile на openFile вам случайно заменить тоже не получится.

Да, случайная замена звучит нереально, но допустим я впервые с этим апи сталкиваюсь, увидел подходящую функцию и использовал не вчитываясь в документацию (где как раз и советуют withFile).


Ну ладно, я согласен, что такие проблемы звучат очень натянуто. С другой стороны, сишники вон тоже говорят, что как можно забыть проверить указатель на null?! RAII всё-таки делает апи чуть проще в использовании.

тем что оно лучше композируется и не требует лапши из коллбеков. Тот же bracket насколько я знаю хоть и решает проблему, но не идеально.


Впрочем, если обмазать API типами достаточно плотно (чего не было доступно во времена Haskell98, да и сейчас не факт что в хаскеле можно), то можно гарантировать статически, что любой openFile будет завершён с closeFile. Опять же, что-то там про линейные типы, про rank-2 polymoprhism, и так далее.

Раии по сути это и есть линейные типы и статическая гарантия что закрытие будет вызвано. По крайней мере если мы про раст.

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

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


Ну там вообще больше про экзепшоны, а с ними в хаскеле вообще отдельный разговор.

Ну раии решает в т.ч. проблему с ошибками во время инициализации/деинициализации.


Да я ж не спорю. Просто вон выше противопоставляется RAII и GC, а при должном обмазывании типчиками одно другому вообще не противоречит.

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

Ну что принципиально она упрощает? Я писал долгое время web-приложения на Java, теперь пишу на Rust. И разницы не замечаю (в вопросах удобства управления памятью). А вот то, что теперь не надо тюнить JVM, чтобы сделать выделение памяти и сборку мусора предсказуемой — очень даже чувствую.

Можно пример того, что вы написали на JAVA и переписали на раст, где вас сильно мучала сборка мусора?

Я Java-приложения на Rust не переписывал. Просто говорю по своему опыту, что возни с GC в крупных приложениях на Java больше, чем проблем с BC (наличие которого через полгода практики перестаешь замечать).

Вы пишете полную чушь. Так же товарищ выше писал про Rust. Глубоко сомневаюсь, что вы писали приличные приложения на Java и Rust. Вы сейчас тут распространяете непонятные мифы. Rust не решает проблемы GC и не заменит его! Читайте мой комментарий выше! Rust решает совсем другую проблему! Если вам нужен низкоуровневый доступ к памяти JAVA, то может использовать Unsafe, VarHandle, но вы видимо таких вещей даже не знаете.

Писал только неприличные приложения видимо.


Последний объем кодовой базы составляет порядкм 1mloc, не сверх много, но кмк релевантно. На расте многие вещи менее удобно делать чем на языках с гц, но не на порядок и думаю даже не в разы.

Да ладно? Вы в принце не понимаете даже зачем в Java GC. У многих есть ошибочное мнение, что GC это костыли. Ошибочное мнение. Вы неужели думаете, что C++ и С программисты настолько тупы, и так же создатели JVM, что не смогли до Rust придумать удаление сразу объектов как в C++ или C? Или сделать shared pointer? Такие вещи сделать совсем просто, это примитив, даже мне приходилось такое писать и оверхед там не более 1%. Rust это только оптимизировал на уровне компилятора. GC совсем не про это, GC решает проблему при работу с очень крупными данными, десятками гигабайт и больше, где нельзя просто взять и удалить объект, где создается и удаляется много объектов, что повлечет за собой фрагментацию памяти и скажется на производительности! На маленьком приложении вы в принципе это даже не заметите, а на крупном это серьезная проблема. Плюс алгоритмов сборки мусора существует несколько, и они решают именно определенные проблемы, что подходит одному не подойдет другому. Плюс в JAVA есть интеграция с алокатором ОС, там есть к примеру

-XX:+UseLargePages
-XX:+UseTransparentHugePages


Для работы совсем с большими страницами памяти и тоже решает проблему сборки мусора на больших данных.

Java это в первую очередь не десктоп, и не веб и микросервисы, это в первую очередь обработка больших данных для целей бизнеса! Все проблемы с GC от не понимания принципов его работы, и кривых алгоритмов и программистов, от которых не защищены все языки программирования…

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

Есть ли в Rust MapReduce?

Прям столько всего сразу что даже не знаю с чего начать:)


Да ладно? вы в принце не понимаете даже зачем в java gc.

Ну да, я пишу на жабе/шарпе 10 лет, но не понимаю зачем там гц. Не знаю что пространство ручек гц состоит из по крайней мере 15 тредофов. Не знаю про существование G1,Shenandoah,ZGC и какие у них характеристики… Ничего не знаю, просто фанбойствую по расту :)


Java это в первую очередь не десктоп, и не веб и микросервисы, это в первую очередь обработка больших данных для целей бизнеса!

Скажите, HFT биржи обрабатывают большие данные или нет? Просто любопытно.


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

может и не примут, но я бы поставил что примут. Надо подпилить некоторые вещи. Но при чем тут это не сильно понятно — у линуса проблема в том, что ядру паниковать плохо. А вот в юзерспейсе (где 100% жаба аппов выполняются) это наоборот хорошо — приложение просто падает, а не совершает УБ или молча портит чужую память.


Есть ли в Rust MapReduce?

Нет

HFT биржи? HFT это лишь стиль торговли, а не биржа, высокочастотная торговля, и да мне приходилось писать коннекторы для трейдинга. Впринципе можно писать на чем угодно, сборка мусора не помеха, у меня это было C++и С#. Если вы про Stock Sharp то он жестко кривой, изначально когда я писал своего работа использовал его как основу, но в итоге избавился и написал свое, которое не тригерит так сборку мусора и не копирует объекты раздувая память. Честно говоря мне не понятно за что там берут деньги, проект совсем кривой и тормозной, и по мне коммерческая ценность его 0. А еще у меня не самая плохая математическая база h0tc0d3.github.io/evtools
НЛО прилетело и опубликовало эту надпись здесь
Сразу видно профессионал. Точно совсем никак без GC? А можно уточнит для каких провайдеров данных вы писали коннекторы? Как организовывали риск менеджмент? Какой был у вас коэффициент шарпа по вашей стратегии и стандартное отклонение, максимальная просадка? Можно увидеть аналитику?) Можно было все на C++ писать. Вы меня не поняли писал не только коннекторы, но и платформу для алго. На C# банально проще визуализировать данные, работать с таблицами, графиками. C# биндинги есть даже в западных коммерческих платформах для алготрейдинга, не говоря про несколько российских. Вот они же лохи, чувак же на хабр сказал, что GC плохо и вообще никак нельзя вкорячить. Можно уточить, что вы там на сотни гигов грузите? Данные по объемам? В принципе при конвертации данных и компактном их хранения, по инструменту за последние несколько лет данные занимают не более пары сотен гигов. Для HFT впринципе столько данных не нужно, для HFT важна моментальная адаптация по времени. HFT это принципе не про стратегию на исторических данных, там другой принцип. Ага, чувак написал про хаскель, и сразу можно в боги программирования записывать…
НЛО прилетело и опубликовало эту надпись здесь
CSV медленно, тут вы жестко спалились. С бинарными данными всегда проще работать, плюс они выравнены, с текстом работать это самое медленное. Банально parseInt, parseDecimal у вас будет брать кучу времени, с бинарными данными все проще, плюс можно упаковывать данные практически бесплатно бинарными сдвигами, чтобы уменьшить место и увеличить скорость доступа. Все быстрые коннекторы поэтому передают данные только в бинарном формате, например протокол PLAZAII. Скажу больше, хранение больших данных в текстовом формате, это вообще гремучая смесь для сборщика мусора, и основная проблема очень большого количества программ почему они так жестко тормозят при работе.
НЛО прилетело и опубликовало эту надпись здесь
ЛОЛ. Так вы же говорили про крупные приложения под сотню гигабайтами данных… Да еще чето про HFT пытались писать впринципе не понимая специфику. А сейчас съезжаете… Для HFT даже лаг в несколько секунд много, HFT это быстрый алгоритм, который работает на не эффективности рынка, он просто эксплуатирует более медленных торговцев. Изучайте теорию игр и GTO. На больших данных там не на минуты время идет, а на часы и даже дни, мне приходилось конвертировать большое количество бинарных данных в текст и обратно. Вы никогда не думали почему базы данных все данные хранят в бинарном формате? Ничего сложного с бинарными данными работать, даже значительно проще чем с текстом)))
НЛО прилетело и опубликовало эту надпись здесь
Парсить сотни мегов и даже несколько гигогов логов в секунду вполне реально, но только если у вас нет сложной токенизации и сложной логики лексического анализатора. Даже на JS можно несколько мегабайт распарсить и построить AST за примерно 30мс. Проблема CSV совсем другая, это то, что файлы усыпаны большим количеством чисел, которые надо распарсить, вот это уже очень медленно! Вы мне затираете про rust и тонкие материи, а сами даже не работаете с бинарными данными. Такие смешные… Вы когда нибудь пробовали делать выгрузку и загрузку базы из postgresql в бинарном и текстом формате и замерить во сколько раз отличаются их скорости? Предлагаю вам поставить postgresql и это проверить прямо сейчас и выложить результаты тут. Сами же несете чушь и минусуете впридачу… Ох уж эти крутые программисты на хаскель… Вот так всегда кончились аргументы, и начали минусовать)))
НЛО прилетело и опубликовало эту надпись здесь
Знаете, что означает, что стрелчока вниз здесь не красная, а такая же серая, как и стрелочка вверх? Что я вам вообще никакие оценки не ставил.

Я программист — это фотошоп!