"А так то скала с ним мало общего имеет." — где-то 90% "идей" котлина взято из скалы

Ну вот потму и говорю что он скале не конкурент

Это каких кроме дата класса ?

Вал вар, обжект

Патерн матчинга нет, имплиситов нет.

патмат недо есть, и недо имплиситы есть

точнее, имплисит расширение, но это ближе к шарпу

Нет там пм, и не спешат, по словам жетбрейнс людей. Мол, не нужно это.

в 1.1 делают таплы типа val (a, b) = foo

не нужно, ага

Это не особо-то пм :-) такого сахарка везде полно

это называется деструктуризация, и это отдельная фича

Это ж как ее.. деструктуриз

Да :-)

и в чем разница от патмата?

кроме того, что последний умеет больше?

в том, что ты так поматчить не сможешь

эээ

ещё как могу

Вот если б Матч п { Кейз (33,б) .. Кейз (а, 22) ... }

вон тот кусок кода выше — именно патмат именно в скале

скажем, без деструктуризации не будет паттерн матчинга

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

Ыы, о нет

А без инстансоф да кастинга вообще огонь jmp по адресу да пошел

А без инстансоф да кастинга вообще огонь jmp по адресу да пошел

к чему это было сказано?

паттерн матчинг и деструктуризация - это сахарок и в котлине его также не трудно будет добавить

Наверн не в кассу, не правильно понял твое про производительность :-)

едем дальше по фичам — строковая интерполяция (опять-таки слабее оригинала), тайп алиасы

фишка в том, что вот все эти "слабее оригинала" иногда будут преимуществом

Наверн не в кассу, не правильно понял твое про производительность :-)

ну, тут все так надрачивают на патмат (как собственно и все скалисты), но мало кто задумывается что он на перфоманс может влиять

Значит наверное таки в касс2

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

*кассу

ну, тут все так надрачивают на патмат (как собственно и все скалисты), но мало кто задумывается что он на перфоманс может влиять

да не так уж сильно, смотря какой патмат в хорошем случае он сводится к switch/case, в плохом — к пачке isInstanceOf

да не так уж сильно, смотря какой патмат в хорошем случае он сводится к switch/case, в плохом — к пачке isInstanceOf

это ты не прав)

да не так уж сильно, смотря какой патмат в хорошем случае он сводится к switch/case, в плохом — к пачке isInstanceOf

(миллионам пачек инстансоф, кастингу и проверкам)

инстансоф - это довольно хороший случай в патмате)

ещё про анбоксинг можно наверное в таких случаях вспомнить

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

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

я бы сказал, 99%

я бы сказал, 99%

ну если он ещё и предсказуемый байткод выдаёт с предсказуемым поведением в большинстве случаев, то вообще почти 100

Читабельность и понятность сильно важнее производительности в 95% случаев. Какая разница сколько ты на матчинге потеряешь 5 или 50нс все равно потом на I/O на 70мс заблочишься.

Читабельность и понятность сильно важнее производительности в 95% случаев. Какая разница сколько ты на матчинге потеряешь 5 или 50нс все равно потом на I/O на 70мс заблочишься.

вот с этого я щас прямо скажем крякнул

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

типа при case Foo(Bar(s: String),_ , Baz(i: Int)) ?

типа при case Foo(Bar(s: String),_ , Baz(i: Int)) ?

во, норм пример, printassembly сделай, и сравни с серией instanceof)))

вот на работе и гляну)

типа при case Foo(Bar(s: String),_ , Baz(i: Int)) ?

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

во, норм пример, printassembly сделай, и сравни с серией instanceof)))

Как в той бородатой шутке, ты пока это писал потратил больше времени чем средний проект сэкономит в рантайме за счет этих микрооптимизаций :-)

мало того, что микровызовы плодятся как грибы, так еще и неизвестно что внутри зачастую выполняется - если unapply не стандартный

Как в той бородатой шутке, ты пока это писал потратил больше времени чем средний проект сэкономит в рантайме за счет этих микрооптимизаций :-)

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

Как в той бородатой шутке, ты пока это писал потратил больше времени чем средний проект сэкономит в рантайме за счет этих микрооптимизаций :-)

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

Есть, и в этих задачках есть 5% горячих мест

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

http://pastebin.com/mW8mGRQc

Да, но еще сильнее ударит по тебе попытка въехать в код коллеги уоптимизированый в хлам когда новы требования вкатят :-)

два unapply, две проверки типов, один equals, остальное фигня

вот jmh точно поленюсь сейчас доставать

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

Потому я и говорю 95% случаев. Низкоуровневые библиотеки? Да и то тлько после профилирования. Бизнес - ну его нафиг.

Ребят, где список докладов сегодняшних можно посмотреть?

Киньтемь ссылкой пожалуйста

@notxcain будешь выступать?

Я распечатку принтассембли твоих .freek сделаю, чтоб потралить.

Nope, так и не успел подготовиться

два unapply, две проверки типов, один equals, остальное фигня

а где там два unapply? помоему там все к сравнениям свелось, без вызова unapplн

Тогда не сделаю :-(

два unapply, две проверки типов, один equals, остальное фигня

если заменить Bar(any: Any) и проверять Bar(s: String), то появляется isInstanceOf

но такие простые случаи они все равно линейно разворачиваются

без вызова unaply

по большей части паттерн матчинг как раз и раскладывается в обычный бойлер плейт

да, нету unapply

поэтому можно не заморачиваться в большинстве случаев

не то написал /=

ну вот там большая часть команд вроде как быстрые

поэтому можно не заморачиваться в большинстве случаев

Вот! +1

без вызова unaply

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

сделай свой unapply подходящий и тогда он у тебя вызовется)

аа, да, для кейс классов там все оптимизировано

вот ещё кейс: http://pastebin.com/tEuDy9um вроде как эквивалентные действия, почему для первого куда более страшный байткод?

вот ещё кейс: http://pastebin.com/tEuDy9um вроде как эквивалентные действия, почему для первого куда более страшный байткод?

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

*они умные ровно на столько

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

Эти оптимитизации джит поправит

Транслятор толькл банальщину оптимизирует

Проогони раз 1000 и посмотри что джит сделает с этого куска

В javac оптимизации повыпиливали еще в 1.3

В javac оптимизации повыпиливали еще в 1.3

вобще не режет ничего? просто сахарок раскладывает?

Ага, только очевидные констант инлайн

И десахар. Отсальное джит и то тольк если статистика покажет что это хотспот

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

В рантайме у вмашины гораздо больше информации что нужно оптимизировать, что нет. Некоторые куски вообще выпиливаются. И да, лучше починить оптимизатор в жвм чем подпереть костыль :-) пример https://plumbr.eu/blog/performance-blog/self-healing-jvm

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

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

Либо это такая экзотика, автоген на 1000 кейзов

Что тоже сомнительное решение :-)

ну, тут все так надрачивают на патмат (как собственно и все скалисты), но мало кто задумывается что он на перфоманс может влиять

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

Список докладов на сегодняшнем Московсом митапе: 1) Дмитрий Мешков, IOHK Research, Scorex Project Developer, Разработка приложений с использованием криптографии 2) Дмитрий Зуев, SberTech, ex-Pimpay, Введение в программирование на уровне типов 3) Евгений Остапенко, Введение в CRDT