А это случайно не заблуждение отождествлять асинхронизм в глобальном его понимании с конкурентностью? На некоторых платформах(типа jvm) асинхорнизм построен на многопоточности ибо по другому там никак, но это всего лишь частный случай. Если брать ко-рутины то они там совсем по другому построены, и конкурентность там не причем.
Нет я вас прекрасно понял, но у нас подходы разные. Я исхожу из того что один инструмент для одной определенной сферы. Зачем язык которые умеет запрашивать БД, делать кофе и его можно перевести без труда на перфокарты. Согласен с вами что когда у вас 35 разных языков это уже перебор, но когда один язык для клиентской части, один для бэкенда, один для скриптинга около DevOps-ых задач это уже не так уж и много. Не вижу смысла "притягивать за уши" бэкенд язык к вебу.
Как не крути у вас все равно будет как минимум 2 языка в команде, один системный другой для всего остального, если вы конечно не пишите на python.
Ну следует заметить что такая вещь в себе как TypeScript навряд ли покинет сцену скоро. В том то и дело что Clojurescript и другие порты scheme-like выглядят намного элегантней и более востребованным для node.js, чем та же scala. Зачем кому-то писать на scala под node.js, когда есть акка, play!, и прочие плюшки.
По мне так Scala.js выглядит довольно таки неуклюже по сравнению с элегантностью Elm и другими функциональными языками доступными для веба. Какова ее ниша? Я например не представляю как вот это можно использовать с React или Angular.
Я был не совсем уверен в переводе на русский язык как машина состояний. Проверил в википедии, называется абстрактный автомат. Ну после вашего комментария, мой уже не поправить.
Kotlin для Android хорош, я долго ждал выхода. До этого пробовал писать под Android на Scala и даже Groovy. В Scala убивало то что компиляция долгая и официальный джар нельзя использовать из-за размера, приходилось обходными путями. Ну а Groovy тоже мороки навалом. Порог вхождения в язык Kotlin почти нулевой, да и генерация из Java помогает очень. Впечатления только положительные, ждем версию 1.1.
Здесь вы ошибаетесь, проводя параллели со streams api. Не нужно представлять rxJava как библиотеку для java <v8. Между streams api и реактивными расширениями есть одна существенная разница, которая заключается в том что streams по сути построены на pull а observable построены на push. Результат таков что на streams можно "подписаться" только один раз а у observable может быть сколько угодно подписчиков.
По мне так главная мешанина с rxJava начинается с того что люди мешают многопоточный и асинхронные подходы. Просто в Java из за отсутствия машины состояний(state machine) асинхронизм построен поверх многопоточных библиотек.
В Kotlin 1.1, кстати, обещают ко-рутины построенные поверх машины состояний(state machine).
Минуточку, мне всегда казалось что данная ниша была за Си только благодаря ручному контролю за использованием памяти. Но ведь если в данной сфере переходить на функциональные языки то этот контроль будет потерян. Или тут все дело в хитрой транслитерации с <Мой-любимый-фя> на Си код? Поясните пожалуйста данный момент. Спасибо.
Как то невероятно слышать такое из уст банка. Сейчас сам работаю в одном частном инвест банке, во вторник послед день. Так вот тут никакими микросервисами и далеко не пахнет, да и девиз тут скорее -"мы до сих пор пилим мейнфреймы не смотря на ваши мейнстреймы". И по ходу, так почти во всех банках… Так что как-то не верится.
Вы забыли про мин 7 гб для инсталляции студии в самом легковесном ее варианте? А тормоза при редактировании ХАМЛ? Я лучше джаву поставлю и райдер чем студию.
Я так же не вижу проблем ставить одну более меньшую уязвимость на черную дыру всех уязвимостей.
А это случайно не заблуждение отождествлять асинхронизм в глобальном его понимании с конкурентностью? На некоторых платформах(типа jvm) асинхорнизм построен на многопоточности ибо по другому там никак, но это всего лишь частный случай. Если брать ко-рутины то они там совсем по другому построены, и конкурентность там не причем.
Я думал что минт после скандала с подменой дистрибутива вообще скатился в самый низ, а он вона на первом месте.
Нет я вас прекрасно понял, но у нас подходы разные. Я исхожу из того что один инструмент для одной определенной сферы. Зачем язык которые умеет запрашивать БД, делать кофе и его можно перевести без труда на перфокарты. Согласен с вами что когда у вас 35 разных языков это уже перебор, но когда один язык для клиентской части, один для бэкенда, один для скриптинга около DevOps-ых задач это уже не так уж и много. Не вижу смысла "притягивать за уши" бэкенд язык к вебу.
Как не крути у вас все равно будет как минимум 2 языка в команде, один системный другой для всего остального, если вы конечно не пишите на python.
Ну следует заметить что такая вещь в себе как TypeScript навряд ли покинет сцену скоро. В том то и дело что Clojurescript и другие порты scheme-like выглядят намного элегантней и более востребованным для node.js, чем та же scala. Зачем кому-то писать на scala под node.js, когда есть акка, play!, и прочие плюшки.
По мне так Scala.js выглядит довольно таки неуклюже по сравнению с элегантностью Elm и другими функциональными языками доступными для веба. Какова ее ниша? Я например не представляю как вот это можно использовать с React или Angular.
На TeamCity, им денег наверное жалко...
Я например был вдохновлен вот этим примером от команды Яндекса.
Я был не совсем уверен в переводе на русский язык как машина состояний. Проверил в википедии, называется абстрактный автомат. Ну после вашего комментария, мой уже не поправить.
Да Anko буквально сегодня для себя открыл, вечерком начну колупать на очередном проекте.
Kotlin для Android хорош, я долго ждал выхода. До этого пробовал писать под Android на Scala и даже Groovy. В Scala убивало то что компиляция долгая и официальный джар нельзя использовать из-за размера, приходилось обходными путями. Ну а Groovy тоже мороки навалом. Порог вхождения в язык Kotlin почти нулевой, да и генерация из Java помогает очень. Впечатления только положительные, ждем версию 1.1.
Здесь вы ошибаетесь, проводя параллели со streams api. Не нужно представлять rxJava как библиотеку для java <v8. Между streams api и реактивными расширениями есть одна существенная разница, которая заключается в том что streams по сути построены на pull а observable построены на push. Результат таков что на streams можно "подписаться" только один раз а у observable может быть сколько угодно подписчиков.
По мне так главная мешанина с rxJava начинается с того что люди мешают многопоточный и асинхронные подходы. Просто в Java из за отсутствия машины состояний(state machine) асинхронизм построен поверх многопоточных библиотек.
В Kotlin 1.1, кстати, обещают ко-рутины построенные поверх машины состояний(state machine).
Минуточку, мне всегда казалось что данная ниша была за Си только благодаря ручному контролю за использованием памяти. Но ведь если в данной сфере переходить на функциональные языки то этот контроль будет потерян. Или тут все дело в хитрой транслитерации с <Мой-любимый-фя> на Си код? Поясните пожалуйста данный момент. Спасибо.
Хотелось бы видеть так же что нибудь новенькое по F#, Scala или Clojure. Скажите у вас в планах что то из этого есть?
Выглядит неплохо, спасибо. Интересно что за инструмент на обложке, зубодергалка или ореходробилка.
Скажите а поддержки F# в планах нет?
Вроде стоить это все будет 1/12 от стоимости оракла, а сколько стоит последний черт его знает.
Вы забыли упомянуть что этот язык, вот уже не первый год, уверенно лидурует в топ-10 самых "пугающих" технологий, по версии Stackoverflow.
Как то невероятно слышать такое из уст банка. Сейчас сам работаю в одном частном инвест банке, во вторник послед день. Так вот тут никакими микросервисами и далеко не пахнет, да и девиз тут скорее -"мы до сих пор пилим мейнфреймы не смотря на ваши мейнстреймы". И по ходу, так почти во всех банках… Так что как-то не верится.
Вы забыли про мин 7 гб для инсталляции студии в самом легковесном ее варианте? А тормоза при редактировании ХАМЛ? Я лучше джаву поставлю и райдер чем студию.
Я так же не вижу проблем ставить одну более меньшую уязвимость на черную дыру всех уязвимостей.
Скажите а Xamarin проверять не планируете?