Можно package object добавить, но в multi project это нужно в каждый подпроект

Predef очень часто - зло, его многие сейчас флагами выключают. Например Travis brown недавно вычистил использование Predef из circe, полностью

так что я был не прав)

один any2stringadd только чего стоит

Флагом выключить - это понятно

Да и без разимпортирования все работает. https://gist.github.com/fomkin/71d763b2ff8d7eaf16850e732f686a2d

Да и без разимпортирования все работает. https://gist.github.com/fomkin/71d763b2ff8d7eaf16850e732f686a2d

?

по ссылке выше: import Predef.{any2stringadd => _, _}

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

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

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

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

насчет предефа -- не проще ли всего написать свой предеф, и импортить лишь его?

Слышал что в хаскеле это распространенная практика.

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

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

"это все равно не ботлнек, так не все равно ли тебе, юзер моей либы, будет оно делаться 0.1 или 0.2 сек?" мой ответ -- нет, не все равно выбор библиотеки -- сложная нелинейная функция с кучей параметров, и, пусть коэф при "насколько быстро работают некритичные вещи" небольшой, он есть

а ты уверен, что ты правильно оценил 0.1 и 0.2 секунды и что, даже если ты правильно оценил именно на своем юзкейсе время - то верно ли ты определил, что именно Option.get является причиной такой разницы? а может быть ты пропустил, что твою архитектурку можно слегка переписать и получить выигрыш в несколько десятков секунд (в этом случае вобще непонятно, как можно бочку на option.get катить, коли критичные места не оптимизированы ни на йоту)? а может это все не имеет значения, потому что ты пишешь скрипт на один раз? никто же не отрицает, что оверхед Option.get имеется. Но надо трезво смотреть на вещи и не сваливаться в крайности)

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

например, джавовские стримы имеют mapToInt, здесь оптимизации со знанием того, что у нас именно инт

(примерно о таком я говорю)

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

чего, увы, почти не наблюдается, а в фпшной половине скалы так вообще нет

http://stackoverflow.com/questions/28744990/why-is-scala-hashmap-slow оп

Без Одерски в чатике не разобраться

моё впечатление я уже сказал – jit оптимизирует многие операции, и с ФП ему делать предположение проще. Я не припомню, что бы наблюдал в рантайме много аллокаций Option'ов

вот похожая дискуссия http://www.scala-lang.org/old/node/4243.html

моё впечатление я уже сказал – jit оптимизирует многие операции, и с ФП ему делать предположение проще. Я не припомню, что бы наблюдал в рантайме много аллокаций Option'ов

не уверен jit писался под джаву, а там задела под фп нет

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

http://blog.vorona.ca/scala-option-performance-cost.html

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

http://www.lihaoyi.com/post/MicrooptimizingyourScalacode.html

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

во, тут классно расписано

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

я про подход авторов либ

Feel free to PR :)

вот как чувак взял и запилил https://github.com/lihaoyi/scalatags/pull/126

такие стикеры любой кидать может, а вот в холивар вступить вижу зассал)

я про подход авторов либ

ну подход согласен, если весь функционал есть, то кажется, что надо жать и жать перфоманс

но с другой стороны - большинство библиотек опенсорных не оплачивается, это фан

так почему ты считаешь, что автор должен сидеть и вылизывать её?)

"в идеальном мире"

тип того

ну и опенсорс, почти весь, пишется за деньги

*почти весь стОящий

нуууу…

с натяжкой

с натяжкой?

такие стикеры любой кидать может, а вот в холивар вступить вижу зассал)

А чо, на Azgul запустить все

Весь стоящий опенсорс пишется за деньги

найс стике

за ссылки на телеграмные бот апи спасибо. я так понимаю, в этом чате есть как минимум два автора API, верно? @ivovk @levkhomich а почему кстати решили писать свою реализацию, если уже были готовые?

А этот как? https://github.com/mukel/telegrambot4s

это из него я пример с имплицитами сбрасывал

ну и future там нигде не обрабатываются. и кодогенерации нет. и вообще. нужен единый стандарт

dsl там тоже нет нормального

короче пулл реквестами это не чинилось

за ссылки на телеграмные бот апи спасибо. я так понимаю, в этом чате есть как минимум два автора API, верно? @ivovk @levkhomich а почему кстати решили писать свою реализацию, если уже были готовые?

Когда я писал, bot API только зарелизились

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

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

А потом на каждой яваконфе квизы, как думаете что быстрее в этом случае? А вот и не угадали :-)

товарищи. оцените идею? почти все библиотеки общего назначения на scala являются open-source ными и лежат на гитхабе. но бывает что заглядываешь в исходный код, и понимаешь что тебе довольно сложно этот код читать, потому что скажем это 90% typelevel магия, или Free, и прочие интуитивно понятные монады. Что если сделать badge(типа как CI или gitter badge) для scala проектов, который будет давать примерную информацию о сложности проекта, и о том стиле, в котором он написан. Я думаю что частично это можно сделать средствами анализа кода, частично переложить на людей. Например автор/мейнтейнер либы может дать свою оценку(неправильную конечно), или например туда же голосовалку сделать для пользователей гитхаба. Со стилем проекта наверное проще - "mostly typelevel stack", "lightbend stack", "twitter stack". При этом подозреваю что объективности оценки сложности добиться сложно. Тут какая цель - хочется дать тому кто впервые заходит на страницу проекта общее впечатление о его сложности. Что скажете, нужно ли такое?

а какую проблему оно бы решило?

финагловые сорцы местами та еще задачка)

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

Даже в одном finagle местами есть вдумчивый аккуратный код ядра, а местами - безумный хаотичный поток сознания юных выпускников scala school.

Как быть в таком случае?

Как быть в таком случае?

пока что не знаю

пингвины знают толк в финагле)

)))

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

тут согласен

вернее не совсем

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

ну я вот просто в гугл вбиваю в поиск: - scala language - Результатов: примерно 8 770 000 (0,27 сек.) - rust language - Результатов: примерно 15 000 000 (0,24 сек.)

поиск scala медленнее?

ну я не знаю, возможно это показатель, а возможно это такой же показатель, как количество npm пакетов

поиск scala медленнее?

Наверняка из-за медленной хешмапы

товарищи. оцените идею? почти все библиотеки общего назначения на scala являются open-source ными и лежат на гитхабе. но бывает что заглядываешь в исходный код, и понимаешь что тебе довольно сложно этот код читать, потому что скажем это 90% typelevel магия, или Free, и прочие интуитивно понятные монады. Что если сделать badge(типа как CI или gitter badge) для scala проектов, который будет давать примерную информацию о сложности проекта, и о том стиле, в котором он написан. Я думаю что частично это можно сделать средствами анализа кода, частично переложить на людей. Например автор/мейнтейнер либы может дать свою оценку(неправильную конечно), или например туда же голосовалку сделать для пользователей гитхаба. Со стилем проекта наверное проще - "mostly typelevel stack", "lightbend stack", "twitter stack". При этом подозреваю что объективности оценки сложности добиться сложно. Тут какая цель - хочется дать тому кто впервые заходит на страницу проекта общее впечатление о его сложности. Что скажете, нужно ли такое?

Бесполезно, быстрее в код лезть

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

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

предложенный бейдж - слишком субъективная метрика

можно еще бейдж "мера интепрайзности"

на сколько проект ентерпрайзен

набор бейджей для холиварчиков)

holiwarity

на сколько проект ентерпрайзен

нужно бы повторить проект https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition на скале с cats + dogs + shapeless: FizzBuzzTypelevelEdition. наконец-то можно будет применить фри монадки в реальной жизни

предложенный бейдж - слишком субъективная метрика

Сложность - субъективная, тут большей частью согласен. Стиль - менее субъективная

Народ, а есть здесь использующие Play + REST?

да

А как решили вопрос с аутентификацией?

Т.е. проверка что этот юзверь именно этот и он может делать то что он делает?

по-разному можно. Задача сводится к передаче уникального идентификатора пользователя. Можно передавать заголовком, параметром, кукой

зависит от того, кто будет клиентами апи, как им будет удобней