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

ну так да, они этим и берут

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

сколько гошников, а сколько скалистов

всё-таки простота использования для разработчиков - это мощная киллер фича

ноду эта фича не спасла

ноду эта фича не спасла

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

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

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

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

#define performance распределенщина тоже не понятно каким боком

биг дата /= математика (от слова совсем)

биг дата /= математика (от слова совсем)

чаще всего там в бигдате матан 3его класса )

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

откуда там перформанс?

и что такое распределенность

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

Throughput гохи будет меньше jvm

go get raspedeli mne vse plz

Throughput гохи будет меньше jvm

можно и про лэитенси забиться)

как новый gc релизнут, го только в Debian stable останется

zgc? шенаду?

Шенанду

Нужно только чтобы go добавили в GraalVM

Тогда JVM захватит мир

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

и в докере нормально работать станет)

>3 миллиарда устройств Разве, добро уже не победило?

>3 миллиарда устройств Разве, добро уже не победило?

и это число не меняется уже 10 лет

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

и это число не меняется уже 10 лет

Но ведь неравенство продолжает быть верным. Зачем?

Но ведь неравенство продолжает быть верным. Зачем?

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

А нубские вопросы в этом чатике задавать позволительно?)

конечно

я только этим и занимаюсь:))

тут)

ещё флужу

В java-классе есть 2 метода по следующими сигнатурами 1 - public static Stubber doReturn(Object toBeReturned) 2 - public static Stubber doReturn(Object toBeReturned, Object... toBeReturnedNext) из scala-класса пытаюсь выполнить следующий код Mockito .doReturn(products) - важное тут .when(requesterSpy) .receiveProductIds(urlCaptor.capture(), paramsCaptor.capture()) и получаю ошибку ambiguous reference to overloaded definition, both method doReturn in object Mockito of type (x$1: Any, x$2: Object*)org.mockito.stubbing.Stubber and method doReturn in object Mockito of type (x$1: Any)org.mockito.stubbing.Stubber match argument types (List[Int]) .doReturn(products) Можно как-то вызвать .doReturn метод чтобы зафорсить использование метода с 1ой сигнатурой?

scalamock лучше

https://stackoverflow.com/questions/41337468/mockito-ambiguous-reference-to-overloaded-definition

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

Хз, рассуждая про ГО, я скорее говорил про идеи дизайна, типа этих https://talks.golang.org/2013/distsys.slide

Вообще, что я видел про хай лоад, говорили что на определенном объеме нагрузки, уходят от GC и управляют помятью вручную, типа C++

Господа. Решил достигнуть просветления, обчитался всех этих "кодируйте ваши инварианты в типах" , пробую применить. Вот скажем типичная статья https://blog.codecentric.de/en/2016/02/phantom-types-scala/ там есть Hacker[State] и в зависимости от State у него разные методы появляются. Все красиво. Я вот над чем туплю: этого хакера надо где-то создать и куда то передать. Отдават/принимать будут общий тип Hacker[State] ведь так? Но тогда Мне ж потом до конкретного класса не добраться изза стирания типов. Где ошибка? Как использовать эти инварианты в типах на практике? Какие слова гуглить?

там же в примерах и создается и отдается

отдавать принимать будешь не общий а конкретный тип

типа Hacker[T<:Caffeinated]

типа Hacker[T<:Caffeinated]

Я бы рад, но как создать хакера тогда? Вот пришел запрос, там json , я смотрю в поля и создаю хакера. Но эта функция возвращает Hacker[State] (иначе никак или я чего то не вижу?) .

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

какой тип передашь такой и вернет

Если это узнаётся в рантайм, то идём мимо

Похоже на извечный вопрос "зачем мне все ваши зависимые типы, если по сути моя программа это String => Future[String]

Я бы рад, но как создать хакера тогда? Вот пришел запрос, там json , я смотрю в поля и создаю хакера. Но эта функция возвращает Hacker[State] (иначе никак или я чего то не вижу?) .

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

Я бы рад, но как создать хакера тогда? Вот пришел запрос, там json , я смотрю в поля и создаю хакера. Но эта функция возвращает Hacker[State] (иначе никак или я чего то не вижу?) .

Я попробую. Вначале у тебя извне ведь приходить не json, так? А что-то вроде Array[String] или Source[ByteString] или типа того Ты запускаешь некоторый процесс который превращает это во что-то вроде Either[JsonError, Json] можно также записать как JsonError Either Json. Оба результата - и Left(error) и RIght(json) валидны. Но тебя гораздо больше интересует второй. Ветка обработки, связанная с ним гораздо длинее и интереснее. Точно так же, имея Json ты можешь откопать в нём какое-то поле "caffeinated": true или "caffeindated" : false и и получить BoringCase Either Hacker[Caffeinated] Either Hacker[Decaffeinated] . Один раз проверив необходимое качество в Json, ты можешь запомнить на уровне типа, что твои данные этому качеству соответствуют. И все дальнейшие вычисления могут "сохранять" этот факт на уровне типов. Тебе не придётся каждый раз проверять значение какого-то поля caffeinated в рантайме. Т.е. весь длинный путь в каждой ветке от одного State до другого ты можешь пройти, сохраняя инварианты в типах.

никто не вкурсе собирались ли завезти -Xlint:strict-unsealed-patmat в обычную скалу из тайплевел?

Я попробую. Вначале у тебя извне ведь приходить не json, так? А что-то вроде Array[String] или Source[ByteString] или типа того Ты запускаешь некоторый процесс который превращает это во что-то вроде Either[JsonError, Json] можно также записать как JsonError Either Json. Оба результата - и Left(error) и RIght(json) валидны. Но тебя гораздо больше интересует второй. Ветка обработки, связанная с ним гораздо длинее и интереснее. Точно так же, имея Json ты можешь откопать в нём какое-то поле "caffeinated": true или "caffeindated" : false и и получить BoringCase Either Hacker[Caffeinated] Either Hacker[Decaffeinated] . Один раз проверив необходимое качество в Json, ты можешь запомнить на уровне типа, что твои данные этому качеству соответствуют. И все дальнейшие вычисления могут "сохранять" этот факт на уровне типов. Тебе не придётся каждый раз проверять значение какого-то поля caffeinated в рантайме. Т.е. весь длинный путь в каждой ветке от одного State до другого ты можешь пройти, сохраняя инварианты в типах.

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

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

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

Я попробую. Вначале у тебя извне ведь приходить не json, так? А что-то вроде Array[String] или Source[ByteString] или типа того Ты запускаешь некоторый процесс который превращает это во что-то вроде Either[JsonError, Json] можно также записать как JsonError Either Json. Оба результата - и Left(error) и RIght(json) валидны. Но тебя гораздо больше интересует второй. Ветка обработки, связанная с ним гораздо длинее и интереснее. Точно так же, имея Json ты можешь откопать в нём какое-то поле "caffeinated": true или "caffeindated" : false и и получить BoringCase Either Hacker[Caffeinated] Either Hacker[Decaffeinated] . Один раз проверив необходимое качество в Json, ты можешь запомнить на уровне типа, что твои данные этому качеству соответствуют. И все дальнейшие вычисления могут "сохранять" этот факт на уровне типов. Тебе не придётся каждый раз проверять значение какого-то поля caffeinated в рантайме. Т.е. весь длинный путь в каждой ветке от одного State до другого ты можешь пройти, сохраняя инварианты в типах.

Я могу вставить своё "но ведь" Hacker[Caffeinated] Either Hacker[Decaffeinated] по сути с фантомными типами тебе ничего не даст, как в этой точке программы можно понять, какой именно вариант у тебя сейчас?

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

Да, я про множество отдельных состояний и говорю: Hacker[CoffeeState, Citizenship, Marital, Sex]

Ну или Extends ... With ... With ... With...

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

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

Да, я про множество отдельных состояний и говорю: Hacker[CoffeeState, Citizenship, Marital, Sex]

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

Я могу вставить своё "но ведь" Hacker[Caffeinated] Either Hacker[Decaffeinated] по сути с фантомными типами тебе ничего не даст, как в этой точке программы можно понять, какой именно вариант у тебя сейчас?

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

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

Как? Поматчить ты тут ничего не можешь

@rossmohax чем тебе не угодили кейс классы? case class Hacker(coffeeState:CoffeeState, ..... ) ? я к тому - откуда у тебя такое маниакальное желание все на типы в скале перевести?

Нужно помещать в класс какой то evedence, который уже можно сматчить в рантайме

ERROR: S client not available

Как? Поматчить ты тут ничего не можешь

не можешь Left \ Right поматчить?

не можешь Left \ Right поматчить?

Ох, что то я тупой

@rossmohax чем тебе не угодили кейс классы? case class Hacker(coffeeState:CoffeeState, ..... ) ? я к тому - откуда у тебя такое маниакальное желание все на типы в скале перевести?

Как откуда, увидел игрушку, глаза загорелись

посоны хочу лифтануть функцию до функтора кошками (K, List[B]) => (K, List[B]) и чет не хочет лифтить скалаз лифтила прост парой импортов а тут не схватывает простой пример чтото типа (((_: Int) * 3) map {_ + 100}) (1) работает в том же скоупе где я хочу поднять пред функцию

посоны хочу лифтануть функцию до функтора кошками (K, List[B]) => (K, List[B]) и чет не хочет лифтить скалаз лифтила прост парой импортов а тут не схватывает простой пример чтото типа (((_: Int) * 3) map {_ + 100}) (1) работает в том же скоупе где я хочу поднять пред функцию

Что за функтор у тебя?

я хочу map использовать

оно чтото типа fa andThen f должно быть

У Function1?

да

import cats.instances.function._ ?

import cats.syntax.functor._

Как откуда, увидел игрушку, глаза загорелись

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

@rossmohax чем тебе не угодили кейс классы? case class Hacker(coffeeState:CoffeeState, ..... ) ? я к тому - откуда у тебя такое маниакальное желание все на типы в скале перевести?

Вон академики говорят, кодируйте состояния в типах, пусть компилятор проверит или заставит вас в рантайме проверить. Вот и пробую, но на практике в моем неумелом рантайме типов не остается :( пытаюсь понять, как это все на практике применить. Может TypeTag протаскивать?

import cats.syntax.functor._

проклятье яже проверял у меня не поднималось

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

спасибо Олег

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

тогда бы была ошибка красноречивая

Вон академики говорят, кодируйте состояния в типах, пусть компилятор проверит или заставит вас в рантайме проверить. Вот и пробую, но на практике в моем неумелом рантайме типов не остается :( пытаюсь понять, как это все на практике применить. Может TypeTag протаскивать?

так в рантайме и не должно оставаться

"заставит" значит что без проверок не скомпилится просто

тогда бы была ошибка красноречивая

w00t? верно все было он имплисит кейс класс типа не подставлял потому что много подходило

ну это есдинвтенное обяснение

"заставит" значит что без проверок не скомпилится просто

Это и имею ввиду: заставит вставить рантайм проверку. Я непротив, лишь бы по рукам бил в нужный момент. Писать программульку по фен шую как рекоммендует @rudogma вроде могу представить как, но вот как из рантайма перескочить в компайлтайм пока не могу увидеть , видимо надо взять паузу и обдумать :)

это надо шейплес курить, но вообще без завтипов оно всё будет муторно :)

что-то типа https://github.com/fthomas/refined наверное будет неплохим решением

ну или можно угореть по связкам со сторонними пруверами, типа там https://github.com/epfl-lara/leon https://github.com/epfl-lara/ScalaZ3/ https://github.com/larsrh/libisabelle

это надо шейплес курить, но вообще без завтипов оно всё будет муторно :)

Книжку по Shapeless купил, прочитал и даже кажется что-то понял :)

Это и имею ввиду: заставит вставить рантайм проверку. Я непротив, лишь бы по рукам бил в нужный момент. Писать программульку по фен шую как рекоммендует @rudogma вроде могу представить как, но вот как из рантайма перескочить в компайлтайм пока не могу увидеть , видимо надо взять паузу и обдумать :)

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

ну вообще сам шейплесс немного про другое, а именно про generic алгоритмы

там ключевой момент - witness-типы

которые недавно вмержили в виде http://docs.scala-lang.org/sips/42.type.html

всем привет! Я с очередным нубовским вопросом. я правильно понял, что yield всего-лишь формирует список при работе с циклами?