Re: Интересное мнение про перспективы .NET

fruit6 · Post by **fruit6** » 11 Feb 2014 17:22

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

crypto5 · Post by **crypto5** » 11 Feb 2014 17:23

reality wrote:
crypto5 wrote: Ну для меня есть сложности, монады сложно дебажить, сложнее отлавливать ошибки, они норовят выполнить запрос к БД когда транзакция закрылась, потому что какой то умник заюзал lazy колекцию, а по возвращаемому результату это никак не поймешь.
Это не монады вина а токо криворукого создания которые норовить выполнить IO черт знает как

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

crypto5 · Post by **crypto5** » 11 Feb 2014 17:27

reality wrote:
Komissar wrote:у скала-лазов overengineering rules.
По моему как раз таки overengineering у жавалазов, чтобы сделать в общем то простую композицию двух фьючуров нужно писать какие то свои таски и в пул их пихать. А в скале это просто работает. И так с очень многим. Удобные и просты конструкции пишутся в 10 раз короче.

У вас это работает потому что кто-то точно так же завернул ИО в монады или в что-то другое, в скале вроде нету родного ИО которое работает так как вы описали.

vladich · Post by **vladich** » 11 Feb 2014 17:36

crypto5 wrote:
rorp wrote:
crypto5 wrote:
Интеррапт wrote:Я даже ради интереса погуглил NIO и ForkJoinTask - глухо как в могиле, ничего даже близко подобного нет, а ведь казалось бы - это ведь должен быть прорыв в серверном перформансе.
Я думаю классические джава сервера и с блокированными тредами неплохо живут, все эти дела нужны очень маленькой части програм.
Сервера может и неплохо живут -- они железные. А вот писателям их не позавидуешь.
Не знаю, я вот кучу кода видел, который обрабатывает десятки тысяч QPS, и сотни миллионов транзакций в день, и вполне все бегает по старинке без изнишних сложностей.
Хотя не исключаю что в геймдеве, аналитике, и телекоме такое нужно.

Вот именно что. Десятки тысяч может быть и потянет, не без излишних сложностей, но реально. А как быть с чем-нибудь вроде легкого месседжинга, который должен миллион(ы) коннектов на сервер держать? Сервера на блокированных тредах хорошо живут если они тяжелые операции выполняют, на которые реально расходуется CPU. Если же эти треды большую часть времени спят и их много, то scalability такой системы просто на порядок а то и два хуже чем аналогичной на асинхронных сокетах.

crypto5 · Post by **crypto5** » 11 Feb 2014 17:37

reality, да, и в чем именно проблема из джавы заюзать ListenableFuture в таких случаях? https://code.google.com/p/guava-librari ... eExplained

crypto5 · Post by **crypto5** » 11 Feb 2014 17:37

vladich wrote:
crypto5 wrote:
rorp wrote:
crypto5 wrote:
Интеррапт wrote:Я даже ради интереса погуглил NIO и ForkJoinTask - глухо как в могиле, ничего даже близко подобного нет, а ведь казалось бы - это ведь должен быть прорыв в серверном перформансе.
Я думаю классические джава сервера и с блокированными тредами неплохо живут, все эти дела нужны очень маленькой части програм.
Сервера может и неплохо живут -- они железные. А вот писателям их не позавидуешь.
Не знаю, я вот кучу кода видел, который обрабатывает десятки тысяч QPS, и сотни миллионов транзакций в день, и вполне все бегает по старинке без изнишних сложностей.
Хотя не исключаю что в геймдеве, аналитике, и телекоме такое нужно.
Вот именно что. Десятки тысяч может быть и потянет, не без излишних сложностей, но реально. А как быть с чем-нибудь вроде легкого месседжинга, который должен миллион(ы) коннектов на сервер держать? Сервера на блокированных тредах хорошо живут если они тяжелые операции выполняют, на которые реально расходуется CPU. Если же эти треды большую часть времени спят и их много, то scalability такой системы просто на порядок а то и два хуже чем аналогичной на асинхронных сокетах.

Для чатов заюзаем ForkJoin pool

Post by **reality** » 11 Feb 2014 17:46

crypto5 wrote:reality, да, и в чем именно проблема из джавы заюзать ListenableFuture в таких случаях? https://code.google.com/p/guava-librari ... eExplained

Нет такой проблемы. Можно и заюзать. Я же не утверждаю что джаву ваще на помойку вынести вот прям сейчас и сразу. Я говорю что у меня есть опыт фул-тайма на Java и фул-тайма на Scala и скала мне нравится больше. Для меня она работает. Для компании где я тружусь она тоже работает отлично. Для Twitter, LinkedIn, Netflix она работает отлично.

Если нету времени учить скалу, просто лень, и так все хорошо, хочется провести время с семьей/детьми, просто отдохнуть в конце концов, все это звучит вполно разумно для того чтобы не учить скалу и спокойно продолжать писать на Java и не знать как оно еще бывает. Кривые монады которые затрудняют дебаг выглядят абсолтно неубедительно, потому что это не так. Переубеждать у меня цели нет. Лично для меня все приеимущества очевидны и поэтому я на скале.

vladich · Post by **vladich** » 11 Feb 2014 17:48

crypto5 wrote:
vladich wrote: Вот именно что. Десятки тысяч может быть и потянет, не без излишних сложностей, но реально. А как быть с чем-нибудь вроде легкого месседжинга, который должен миллион(ы) коннектов на сервер держать? Сервера на блокированных тредах хорошо живут если они тяжелые операции выполняют, на которые реально расходуется CPU. Если же эти треды большую часть времени спят и их много, то scalability такой системы просто на порядок а то и два хуже чем аналогичной на асинхронных сокетах.
Для чатов заюзаем ForkJoin pool

Ну я не только про чаты говорю. Если приложение целиком асинхронное, включая DB-библиотеку, не выполняет никаких CPU-bound вычислений само, то scalability у него будет практически как у чата. Таких приложений вагон с телегой. Поэтому всякие штуки типа Node.JS популярны, хотя JS для серверных приложений прямо скажем так себе язык. А в применимости ForkJoin pool для этого я сильно сомневаюсь, мне кажется он только оверхеда добавит. Потому что количество ни worker threads ни i/o threads он не снизит никак. в случае с асинхронным i/o там уменьшать уже нечего.

crypto5 · Post by **crypto5** » 11 Feb 2014 17:50

vladich wrote:
crypto5 wrote:
vladich wrote: Вот именно что. Десятки тысяч может быть и потянет, не без излишних сложностей, но реально. А как быть с чем-нибудь вроде легкого месседжинга, который должен миллион(ы) коннектов на сервер держать? Сервера на блокированных тредах хорошо живут если они тяжелые операции выполняют, на которые реально расходуется CPU. Если же эти треды большую часть времени спят и их много, то scalability такой системы просто на порядок а то и два хуже чем аналогичной на асинхронных сокетах.
Для чатов заюзаем ForkJoin pool
Ну я не только про чаты говорю. Если приложение целиком асинхронное, включая DB-библиотеку, не выполняет никаких CPU-bound вычислений само, то scalability у него будет практически как у чата. Таких приложений вагон с телегой. Поэтому всякие штуки типа Node.JS популярны, хотя JS для серверных приложений прямо скажем так себе язык. А в применимости ForkJoin pool для этого я сильно сомневаюсь, мне кажется он только оверхеда добавит. Потому что количество ни worker threads ни i/o threads он не снизит никак. в случае с асинхронным i/o там уменьшать уже нечего.

Ну ты топик перечитай если терпения хватит, как раз fork join pool все снизит, и туда отлично вписывается асинхронное IO!

crypto5 · Post by **crypto5** » 11 Feb 2014 17:56

reality wrote:
crypto5 wrote:reality, да, и в чем именно проблема из джавы заюзать ListenableFuture в таких случаях? https://code.google.com/p/guava-librari ... eExplained
Нет такой проблемы. Можно и заюзать. Я же не утверждаю что джаву ваще на помойку вынести вот прям сейчас и сразу. Я говорю что у меня есть опыт фул-тайма на Java и фул-тайма на Scala и скала мне нравится больше. Для меня она работает. Для компании где я тружусь она тоже работает отлично. Для Twitter, LinkedIn, Netflix она работает отлично.

Если нету времени учить скалу, просто лень, и так все хорошо, хочется провести время с семьей/детьми, просто отдохнуть в конце концов, все это звучит вполно разумно для того чтобы не учить скалу и спокойно продолжать писать на Java и не знать как оно еще бывает. Кривые монады которые затрудняют дебаг выглядят абсолтно неубедительно, потому что это не так. Переубеждать у меня цели нет. Лично для меня все приеимущества очевидны и поэтому я на скале.

Я потратил времени на изучение скалы, и вполне написал на ней кода, и по моему мнению джава8 скале будет уступать мало, что нивелируется стабильностью джава платформы, намного лучшей поддержкой ИДЕ и отсутствием косяков совместимости.
К тому же в скале тоже есть куча недоделок, например вот так в скале переопределяется default constructor: http://stackoverflow.com/questions/4045 ... parameters

vladich · Post by **vladich** » 11 Feb 2014 18:00

crypto5 wrote:
vladich wrote: Ну я не только про чаты говорю. Если приложение целиком асинхронное, включая DB-библиотеку, не выполняет никаких CPU-bound вычислений само, то scalability у него будет практически как у чата. Таких приложений вагон с телегой. Поэтому всякие штуки типа Node.JS популярны, хотя JS для серверных приложений прямо скажем так себе язык. А в применимости ForkJoin pool для этого я сильно сомневаюсь, мне кажется он только оверхеда добавит. Потому что количество ни worker threads ни i/o threads он не снизит никак. в случае с асинхронным i/o там уменьшать уже нечего.
Ну ты топик перечитай если терпения хватит, как раз fork join pool все снизит, и туда отлично вписывается асинхронное IO!

Он не все снизит, ты утверждал что он может снизить количество потоков если мы a+b выполняем параллельно. ok.
Но чат на ForkJoin pool это как-то очень неортодоксально, вот хоть убей не пойму что там можно распараллелить

crypto5 · Post by **crypto5** » 11 Feb 2014 18:04

vladich wrote:
crypto5 wrote:
vladich wrote: Ну я не только про чаты говорю. Если приложение целиком асинхронное, включая DB-библиотеку, не выполняет никаких CPU-bound вычислений само, то scalability у него будет практически как у чата. Таких приложений вагон с телегой. Поэтому всякие штуки типа Node.JS популярны, хотя JS для серверных приложений прямо скажем так себе язык. А в применимости ForkJoin pool для этого я сильно сомневаюсь, мне кажется он только оверхеда добавит. Потому что количество ни worker threads ни i/o threads он не снизит никак. в случае с асинхронным i/o там уменьшать уже нечего.
Ну ты топик перечитай если терпения хватит, как раз fork join pool все снизит, и туда отлично вписывается асинхронное IO!
Он не все снизит, ты утверждал что он может снизить количество потоков если мы a+b выполняем параллельно. ok.
Но чат на ForkJoin pool это как-то очень неортодоксально, вот хоть убей не пойму что там можно распараллелить

ForkJoin Pool будет работать как скедулер асинхронной обработки запросов, ну и я не совсем понимаю, какое именно решение ты предлагаешь?

vladich · Post by **vladich** » 11 Feb 2014 18:12

crypto5 wrote:
vladich wrote: Он не все снизит, ты утверждал что он может снизить количество потоков если мы a+b выполняем параллельно. ok.
Но чат на ForkJoin pool это как-то очень неортодоксально, вот хоть убей не пойму что там можно распараллелить
ForkJoin Pool будет работать как скедулер асинхронной обработки запросов, ну и я не совсем понимаю, какое именно решение ты предлагаешь?

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

crypto5 · Post by **crypto5** » 11 Feb 2014 18:16

vladich wrote:
crypto5 wrote:
vladich wrote: Он не все снизит, ты утверждал что он может снизить количество потоков если мы a+b выполняем параллельно. ok.
Но чат на ForkJoin pool это как-то очень неортодоксально, вот хоть убей не пойму что там можно распараллелить
ForkJoin Pool будет работать как скедулер асинхронной обработки запросов, ну и я не совсем понимаю, какое именно решение ты предлагаешь?
Я не совсем понял, ты про запросы к самому чату или запросы из приложения чата куда-то еще?
Если первый случай, то там нет ждущих друг друга запросов. Если про второй, то то же самое.
Ну, наверное можно придумать такой чат где это необходимо, чисто теоретически...

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

crypto5 · Post by **crypto5** » 11 Feb 2014 18:31

reality wrote:
crypto5 wrote:reality, да, и в чем именно проблема из джавы заюзать ListenableFuture в таких случаях? https://code.google.com/p/guava-librari ... eExplained
Для Twitter, LinkedIn, Netflix она работает отлично.

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

vladich · Post by **vladich** » 11 Feb 2014 18:39

crypto5 wrote:
vladich wrote: Я не совсем понял, ты про запросы к самому чату или запросы из приложения чата куда-то еще?
Если первый случай, то там нет ждущих друг друга запросов. Если про второй, то то же самое.
Ну, наверное можно придумать такой чат где это необходимо, чисто теоретически...
Про любые варианты, даже в простом варианте когда приходит сообщение тебе нужно выполнить обрабитчик в каком то потоке, вот этот поток и будет менеджится ForkJoinPool. Например в нетти вроде по срцам есть свой форкджойн пул, который делает то что я описал.

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

crypto5 · Post by **crypto5** » 11 Feb 2014 18:43

vladich wrote:
crypto5 wrote:
vladich wrote: Я не совсем понял, ты про запросы к самому чату или запросы из приложения чата куда-то еще?
Если первый случай, то там нет ждущих друг друга запросов. Если про второй, то то же самое.
Ну, наверное можно придумать такой чат где это необходимо, чисто теоретически...
Про любые варианты, даже в простом варианте когда приходит сообщение тебе нужно выполнить обрабитчик в каком то потоке, вот этот поток и будет менеджится ForkJoinPool. Например в нетти вроде по срцам есть свой форкджойн пул, который делает то что я описал.
Пул там безусловно какой-то должен быть, но причем тут форк джойн? Там нет тасков которые должны распараллеливаться и потом сливаться.

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

crypto5 · Post by **crypto5** » 11 Feb 2014 18:47

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

vladich · Post by **vladich** » 11 Feb 2014 18:48

crypto5 wrote:
vladich wrote: Пул там безусловно какой-то должен быть, но причем тут форк джойн? Там нет тасков которые должны распараллеливаться и потом сливаться.
Ну я не знаю что именно есть "там", для чата логично предположить что нужны какие то вычисления, хотя бы статистику асинхронно писать. Но если чат совсем простой ехо пинг-понг, то да, fork-join pool наверное не нужен.

Статистику можно писать асинхронно, но это неблокирующая операция. Мне непонятно какие могут быть блокирующие параллельные операции в чате

vladich · Post by **vladich** » 11 Feb 2014 18:50

vladich wrote:
crypto5 wrote:
vladich wrote: Пул там безусловно какой-то должен быть, но причем тут форк джойн? Там нет тасков которые должны распараллеливаться и потом сливаться.
Ну я не знаю что именно есть "там", для чата логично предположить что нужны какие то вычисления, хотя бы статистику асинхронно писать. Но если чат совсем простой ехо пинг-понг, то да, fork-join pool наверное не нужен.
Статистику можно писать асинхронно, но это неблокирующая операция. Мне непонятно какие могут быть блокирующие параллельные операции в чате

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

Post by **reality** » 11 Feb 2014 19:19

crypto5 wrote: Кстати, про твиттер я наслышан что у них много проектов на скале делают, а вот про линкедин и нетфликс у меня сложилось сильно противоположное впечатление, что они скалу пробовали в каких то небольших нишах, и опенсорс скажем нетфликса в основном на джаве.

У LinkedIn есть Kafka которая на скале и почти что стандарт для high-throughput distributed queue. Все новые веб морды у них крутятся на Play2+Scala о чем они докладывают на конференциях о том как борятся с плеем. Netflix тоже часть своей инфрасруктуры держит на скале и в качестве билд системы использует SBT, и пакует свои сервисы в AMI о чем они хотели рассказать на NEScala но не заапрувили. Если в Twitter скала близка к 100% насколько я знаю, то в ЛикедИн и Нетфликс очевидно грораздо меньше. Какие у них тенденции я не знаю, инсайдеров нету, но на концефенциях они выступают все больше и больше.

crypto5 · Post by **crypto5** » 11 Feb 2014 19:38

vladich wrote:
vladich wrote:
crypto5 wrote:
vladich wrote: Пул там безусловно какой-то должен быть, но причем тут форк джойн? Там нет тасков которые должны распараллеливаться и потом сливаться.
Ну я не знаю что именно есть "там", для чата логично предположить что нужны какие то вычисления, хотя бы статистику асинхронно писать. Но если чат совсем простой ехо пинг-понг, то да, fork-join pool наверное не нужен.
Статистику можно писать асинхронно, но это неблокирующая операция. Мне непонятно какие могут быть блокирующие параллельные операции в чате
И да, это второй случай, для него можно придумать что-то требующее параллельных ждущих друг друга операций.
Для первого, скедулинга worker threads, я вообще ничего такого придумать не могу.

договорились

crypto5 · Post by **crypto5** » 11 Feb 2014 19:48

reality wrote:
crypto5 wrote: Кстати, про твиттер я наслышан что у них много проектов на скале делают, а вот про линкедин и нетфликс у меня сложилось сильно противоположное впечатление, что они скалу пробовали в каких то небольших нишах, и опенсорс скажем нетфликса в основном на джаве.
У LinkedIn есть Kafka которая на скале и почти что стандарт для high-throughput distributed queue. Все новые веб морды у них крутятся на Play2+Scala о чем они докладывают на конференциях о том как борятся с плеем. Netflix тоже часть своей инфрасруктуры держит на скале и в качестве билд системы использует SBT, и пакует свои сервисы в AMI о чем они хотели рассказать на NEScala но не заапрувили. Если в Twitter скала близка к 100% насколько я знаю, то в ЛикедИн и Нетфликс очевидно грораздо меньше. Какие у них тенденции я не знаю, инсайдеров нету, но на концефенциях они выступают все больше и больше.

Да, сбт та еще жесть, отпугивающая наверное процентов 30 пробующих скалу. Я вот перебрался на gradle и там все отлично работает.

Post by **reality** » 11 Feb 2014 19:52

crypto5 wrote:Да, сбт та еще жесть, отпугивающая наверное процентов 30 пробующих скалу. Я вот перебрался на gradle и там все отлично работает.

Дело привычки. Gradle не пробовал, но мавен ведь тоже та еще жесть. Километры xml. Но ведь все привыкли же и стал стандартом.

Меня СБТ кстати полностью устраивает. Даже плагины к нему научился писать, пока учился понял как он работает

crypto5 · Post by **crypto5** » 11 Feb 2014 19:54

reality wrote:
crypto5 wrote:Да, сбт та еще жесть, отпугивающая наверное процентов 30 пробующих скалу. Я вот перебрался на gradle и там все отлично работает.
Дело привычки. Gradle не пробовал, но мавен ведь тоже та еще жесть. Километры xml. Но ведь все привыкли же и стал стандартом.

СБТ мне очень понравилась для простых проектов, но вот например прикрутить генерацию протобуферов, или thrift классов, или запаковать все в big fat jar, и начинается куча плясок с бубном..

Привет