вопрос про котлин. почему val Class<MyClass> c = javaClass не влезает в метод fun m(c: Class<Any>) {} ? зато влезает метод с дженериками fun <T> m(c: Class<T>) {}

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

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

какие?

пали

хвостовая рекурсия и экстендж методы

оптимизация хвостовой рекурсии в смысле? как в кложе и скале?

это плюс, согласен

а второе это что?

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

аа

ну имплиситы короче

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

(по сравнению со скалой)

но я все-таки сравнивать со скалой не хочу

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

ну на этом и хватит

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

кстати, раз уж про скалу вспомнили, может посоветуете какой-нибудь опенсорс на scalaz почитать? шоб каноничненько и до костей пробирало ?

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

сырцы scalaz )

http://eed3si9n.com/learning-scalaz

но я бы посоветовал cats смотреть, они поприятее

http://eed3si9n.com/learning-scalaz

не, мне не академическое что-то, а реальный бы проект

в скалазе разве кроме ? | что-то еще используется? :)

а, ну с этим сложнее) akka-http, но он тяжелый для понимания

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

с одно стороны да, а с другой можно реально композицией заниматься. На джаве пришлось бы городить что-то вроде: method1( arg1, method2( arg2, arg3, method3( ... ) ) ) а на котлине можно arg1.method1 {..} .method2(arg2, arg3) { ... }

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

кстати, раз уж про скалу вспомнили, может посоветуете какой-нибудь опенсорс на scalaz почитать? шоб каноничненько и до костей пробирало ?

не могу не заметить, что активно этот весь ФП стафф использует процентов 5 скалистов (не надо думать, что мы все такие) остальные пишут проще

Это да

Но хочется как страшилки на ночь почитать, знаете ли

Но хочется как страшилки на ночь почитать, знаете ли

https://github.com/tel/scala-comms/ вот ещё, поменьше, но все ещё злобное

че то все про скалу. че такая крутая вещь. стоит бросать яву и изучать?

если хочется функциональщины, то скала

отличный вброс!

Для общего развития в любом случае полезно будет.

а на выходе тот же ява?

а так в 90% проектов джавы хватает

тот же байткод

интересно. надо поизучать

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

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

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

Кложур

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

в основном берут как раз для этого

но таких проектов намного меньше

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

Идрис для общего развития мне кажется лучше скалы

Хаскелль для общего развития мне кажется лучше Идриса

а работал кто с kryonet?

видимо нет. перейду тогда на netty

видимо нет. перейду тогда на netty

отличный выбор )

мы используем крио для сериализации, но в связке с JGroups

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

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

а что непонятного?

ERROR: S client not available

самое простое https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

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

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

а что такое адовая многопоточность?

проблема не в выборе метода шифрования. а встраивание в kryonet

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

решая общую задачу

звучит как обычная многопоточность

ага

обычная многопоточность это ад

тогда ладно

а что такое адовая многопоточность?

если взять что в среднем в мире умирает 160к человек в день, из них 80% попадают в ад, то это примерно 1,5 запроса в секунду

фп тем и хорош, что нету переменных и прочего изменяемого говнеца

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

как на фп сделать производительный чат-рум ?

в смысле на полном мутабилити

MutableRef<ImmutableList<Msg>> не предлагать

выносить стейт в редис или куда-то еще тоже

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

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

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

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

так что разработчики языка (компилятора) заранее позаботятся о том, чтобы были оптимизации по памяти.

Name [jdbc/somebase] is not bound in this Context. Unable to find [jdbc]. Как это побороть? Гугл бессилен. Конфиги перепроверил все, драйвер mysql.jar в папку lib томката закинул

а базу то создал????

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

как на фп сделать производительный чат-рум ?

фп != отсутсвию мутабельности оно скорее про её контроль