В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

JUG NN

197 membersпожаловаться на группу
2018 August 28

С

Сергей in JUG NN
Denis Anfertev
Блин, если нужны только коллекции, то можно, конечно, юзать vavr. Но мы же начали говорить о подходах, которые прививает этот vavr
Он прививает просто более функциональный стиль кмк. Ну и учитывая что тут под боком есть скала, то и его эта имплементация этого стиля похоже на скаловую
источник
18:50пожаловаться#1

RK

Roman Khlebnov in JUG NN
Сергей
А менеджеру чем обосновать переход на скала? Тип коллекции пизже?)
Ну, если ты в край задолбался писать портянки дженериков для структур
источник
18:51пожаловаться#2

RK

Roman Khlebnov in JUG NN
Например
источник
18:51пожаловаться#3

VK

Vlad K in JUG NN
господа, а что делают ваши проекты в плане предметной области, что требует иммутабельность, монады и прочее?
источник
18:51пожаловаться#4

DA

Denis Anfertev in JUG NN
Sergey Kapralov
А я вот так и не допер че такого специфичного он прививает. Обычный флюент апи
Ну вот я глянул в документацию - Try, Lazy, Either, Validation, Pattern Matching - совсем не только fluent api. Это более функциональный подход.
источник
18:51пожаловаться#5

SK

Sergey Kapralov in JUG NN
Denis Anfertev
Ну вот я глянул в документацию - Try, Lazy, Either, Validation, Pattern Matching - совсем не только fluent api. Это более функциональный подход.
Так функциональный != скаловый. На скале мир ФП не сошелся.
источник
18:52пожаловаться#6

DA

Denis Anfertev in JUG NN
Хах, ну дак vavr же копирование со scala
источник
18:52пожаловаться#7

DA

Denis Anfertev in JUG NN
Поэтому мы и говорим о scala, а еще потому что JVM и хороший интероп с java
источник
18:53пожаловаться#8

RK

Roman Khlebnov in JUG NN
Vlad K
господа, а что делают ваши проекты в плане предметной области, что требует иммутабельность, монады и прочее?
Например, монада Try очень даже удобная штука, если задуматься. Пишешь пайплайн функций, если посередине что-то зафейлилось, то все пройдёт более-менее гладко с красиво завернутым исключением в конце
источник
18:53пожаловаться#9

SK

Sergey Kapralov in JUG NN
Denis Anfertev
Хах, ну дак vavr же копирование со scala
И что? А лямбды - копирование с лямбд. А Project Reactor - копирование с RxJava (наверное).
источник
18:54пожаловаться#10

SK

Sergey Kapralov in JUG NN
Все всё чето копируют
источник
18:54пожаловаться#11

DA

Denis Anfertev in JUG NN
Sergey Kapralov
И что? А лямбды - копирование с лямбд. А Project Reactor - копирование с RxJava (наверное).
Почему ты отвечаешь только на последнее сообщение без учета контекста обсуждения?
источник
18:54пожаловаться#12

SK

Sergey Kapralov in JUG NN
А на месте менеджера я был бы тоже против гетерогенности вроде "а давайте мы замеcим разных Java-based языков в одном проекте ради каких то там коллекций"
источник
18:55пожаловаться#13

VK

Vlad K in JUG NN
Roman Khlebnov
Например, монада Try очень даже удобная штука, если задуматься. Пишешь пайплайн функций, если посередине что-то зафейлилось, то все пройдёт более-менее гладко с красиво завернутым исключением в конце
да монаду Try я активно юзаю(правда, на руби проекте), но предметка в том проекте - rest-like API. И в целом, что монада, что исключение - без разницы, нужно просто упасть и откатить транзакцию. С исключение попроще даже будет
источник
18:55пожаловаться#14

С

Сергей in JUG NN
дык что плохого то в том, что вавр свои имплементации функцианальных штук брал из скалы? Ну написали бы они их подругому, какая разница?
источник
18:55пожаловаться#15

DA

Denis Anfertev in JUG NN
Sergey Kapralov
А на месте менеджера я был бы тоже против гетерогенности вроде "а давайте мы замеcим разных Java-based языков в одном проекте ради каких то там коллекций"
Блин, а вот у меня в комапании менеджер скажет - а вы знаете, вот у нас большой опыт в c++, давайте вообще это перепишем на c++, но это не значит, что менеджер прав? 🙂
источник
18:56пожаловаться#16

С

Сергей in JUG NN
наоборот, для тех кто знаком со скалой это лучше. Или кто потом будет знаком увидит те же вещи
источник
18:56пожаловаться#17

DA

Denis Anfertev in JUG NN
Сергей
дык что плохого то в том, что вавр свои имплементации функцианальных штук брал из скалы? Ну написали бы они их подругому, какая разница?
Ничего плохого нет. Я вообще не знаю, откуда тут проблема. Я просто заметил тот факт ,что это скопировано со scala и как человек, который писал на scala, считаю, что лучше сразу начать писать на scala, чем использовать vavr. Но если ваш проект это не позволяет - тогда не нужно заморачиваться scala 🙂
источник
18:57пожаловаться#18

SK

Sergey Kapralov in JUG NN
Denis Anfertev
Блин, а вот у меня в комапании менеджер скажет - а вы знаете, вот у нас большой опыт в c++, давайте вообще это перепишем на c++, но это не значит, что менеджер прав? 🙂
Прав или не прав - зависит от контекста. Скорее всего профита от переписывания будет несравнимо меньше чем запары, поэтому не прав, да. Но я просто не могу себе представить ситуацию, где внедрение скалы ради одних вшивых коллекций было бы обоснованно.
источник
18:58пожаловаться#19

DA

Denis Anfertev in JUG NN
Sergey Kapralov
Прав или не прав - зависит от контекста. Скорее всего профита от переписывания будет несравнимо меньше чем запары, поэтому не прав, да. Но я просто не могу себе представить ситуацию, где внедрение скалы ради одних вшивых коллекций было бы обоснованно.
Ох, ну дак я такого и не писал, что нужно внедрять scala ради коллекций
источник
18:58пожаловаться#20