CherryTea
даже питон компилится в js, тоже мне фича
CherryTea
*трансплайтится
CherryTea
ага, и на дарт тоже гугл поставили, только где он этот дарт
Andrey
Гугл как азартный игрок в казино, много ставит и все на черное
Tema
Странно как могли на него поставить, если сейчас Гуглец судится с Oracle за использование Java/JVM внутри Android'а
Vladimir
Котлин вместо джавы
Tema
Нужно сделать rest бэкэнд для мобильного приложения. Пиковая нагрузка будет около 500 одновременных обращений. Могу выбирать из двух Node или Go. Ни того ни другого не знаю. Что посоветуете в плане скорости разработки?
Нода тут преобладает по нескольким причинам. Первая из них это простота разработки (т.к. JS, не надо учить новый синтаксис Go), а вторая это то что Node.js разрабов больше (во всяком случае в СНГ именно так относительно Go)
Дима
Странно как могли на него поставить, если сейчас Гуглец судится с Oracle за использование Java/JVM внутри Android'а
Этот суд тянется с тех пор, когда использование JVM в технологии ещё не считалось недостатком
CherryTea
Nurik
Кстати, они сперва поставили на swift, когда его сделали опенсорсным. Даже заявление вроде делали, что мол, Kotlin это хорошо, но вот swift более производительный.
Vladimir
чет ты попутал слегка
파쇼크
Так, что угодно компилится в webassembly нынче, а котлин молодой, с небольшим комьюнити (а таких сейчас много), так что фиг знает
파쇼크
Но вот то, что можно писать на андроиде с меньшим сопротивлением это оч кул
A
гы. JS уже ничего не заменит)
Может быть можно было бы спросить - станет ли Kotlin вторым typescript-ом..
Но, мне кажется, не станет.
Nurik
Нода тут преобладает по нескольким причинам. Первая из них это простота разработки (т.к. JS, не надо учить новый синтаксис Go), а вторая это то что Node.js разрабов больше (во всяком случае в СНГ именно так относительно Go)
Про синтаксис очень сомнительный плюс. Насчет количества, - количество не есть качество. В Go обычно приходят уже скилованные разрабы (мне так кажется, возможно что показалось, но всё же.), в ноде много тех, кто раньше умел только во фронтенд разработку.
A
А вот как Java 2.0 Kotlin выглядит более чем достойно.
파쇼크
> В Go обычно приходят уже скилованные разрабы
Там просто сложнее накосячить)
Tema
Про синтаксис очень сомнительный плюс. Насчет количества, - количество не есть качество. В Go обычно приходят уже скилованные разрабы (мне так кажется, возможно что показалось, но всё же.), в ноде много тех, кто раньше умел только во фронтенд разработку.
Не могу не согласится и про скилованность и про то что приходят в ноду с фронта, ибо JS. На самом деле я просто имел ввиду что коммюнити побольше у ноды и полегче найти неплохого разраба на ноде, чем если бы искать неплохого на Go.
A
Про синтаксис очень сомнительный плюс. Насчет количества, - количество не есть качество. В Go обычно приходят уже скилованные разрабы (мне так кажется, возможно что показалось, но всё же.), в ноде много тех, кто раньше умел только во фронтенд разработку.
спорный аргумент. Думаю в Haskell и Agda приходят еще более скилловые разрабы. Проблема в том, что в половине случаев важен не скилл, а умение тупо работать вперед)
파쇼크
Так а чо там за ад с воркерами
파쇼크
ада с коллбеками уже нет, у нас есть сочни промисы, и все уже забыли про пирамиды (нет)
A
Подниму второй инстанс и поставлю их за балансировщик?!
Дима
Ты пишешь какой-то чудовищный код
Дима
А иммутабельность и типизация хаскеля вообще фикция и не существует
Дима
отличный аргумент конечно
파쇼크
Ну это вопрос наличия подходящего инструмента
파쇼크
Мда, и что? Никакого ада больше
Yaroslav 🇺🇦
гугль просто тролит все разрабов. Давайте взбудоражим комьюнити.. а давайте. За что там брейнсы топят? за котлин.. объявим потдержку. И гул такой - "тревога, тревога!", "а как же го?", "почему не v8 прям вшито"
A
Ладно, я согласен pm2 start -i 2 это за пределами человеческих возможностей
Дима
Показывает его уровень освоения технологии)
파쇼크
Может он гошник прост
Дима
Похлопаем
파쇼크
А ну вот
Scarx
всем го пацаны!
Nurik
ада с коллбеками уже нет, у нас есть сочни промисы, и все уже забыли про пирамиды (нет)
Я хз, но вот насчет async await и голых промисов. Часто слышу, когда разрабы себе в ущерб выбирают просто промисы, потому что async/await —медленнее. Т.е. быстродействие ставится превыше удобства, как будто это геймдев где нужно делать грязные хаки для повышения фпс.
Scarx
вот еще phoenix посмотрел - там вообще оч круто все
Scarx
не как у людей
Scarx
и звучит гордо
Vadim
Я хз, но вот насчет async await и голых промисов. Часто слышу, когда разрабы себе в ущерб выбирают просто промисы, потому что async/await —медленнее. Т.е. быстродействие ставится превыше удобства, как будто это геймдев где нужно делать грязные хаки для повышения фпс.
Когда у тебя 300 rps, то быстродействие и вправду важнее
Vladimir
Когда у тебя 300 rps, запусти побольше процессов
Vadim
Ну представим, у тебя ограничение по бюджету в облаке или железо не бесконечное
A
И на 300rps реально нода узкое место? Я думал надо базу первым делом глянуть. Вдруг ей что-то надо
Дима
Если эти триста приходятся на один инстанс, то кажется у вас проблемы и отнюдь не в языке
Vadim
300 rps нода не узкое
Vadim
Я образно, если отказ от async/await дает на 50-100rps больше на один instance, то оптимизация выгоднее, чем удобство.
Всегда есть pros/cons, железо, деньги или оптимизации, если они того стоят.
Дима
Я хз, но вот насчет async await и голых промисов. Часто слышу, когда разрабы себе в ущерб выбирают просто промисы, потому что async/await —медленнее. Т.е. быстродействие ставится превыше удобства, как будто это геймдев где нужно делать грязные хаки для повышения фпс.
Наложив некоторые ограничения на код, можно async await спокойно транспилировать в промисы
Vadim
Сахар не влияет на скорость разработки
Nurik
Я образно, если отказ от async/await дает на 50-100rps больше на один instance, то оптимизация выгоднее, чем удобство.
Всегда есть pros/cons, железо, деньги или оптимизации, если они того стоят.
Вот, я как раз поэтому и говорю. ЧТо в nodejs любая фича связана в первую очередь со скоростью, а уже потом с удобством.
A
Сахар не влияет на скорость разработки
Не правда. Меньше кода - меньше зависимостей - меньше багов - короче цикл тестироваия
Vladimir
А еще неправда что async await медленнее
Анатолий
Конечно тут всё ещё зависит от инструмента
Анатолий
от иде
Vadim
Объективно es6 не внес ничего, чтобы повысило скорость разработки, скорее удобство.
파쇼크
Поделитесь тестом?
파쇼크
Договорились
Vladimir
Пруфы в студию
Дима
Объективно es6 не внес ничего, чтобы повысило скорость разработки, скорее удобство.
Из этой фразы делается вывод, что бывают ситуации, когда чем неудобнее писать - тем быстрее получается работать
Дима
ну и юзай блуберд, в чем проблема
Дима
async await -> promise -> bluebird
Дима
Технически спокойно реализуемо
Дима
Хз в чём у вас тут проблема вообще)
Vladimir
Ты ссылку дай, где async await с проимсами сравнивается
Vladimir
Ну тогда нечего чушь нести, не подкрепляя ничем
Vladimir
Проблема тестов в том что их очень просто сделать неправильно
Vladimir
Для это нужно бенчмарки показывать другим людям
Vladimir
Если задача - получить тест, результаты которого что то значат
A
Проигрыш в чем? Память, latency, throughput?
A
А в абсолютных цифрах? Хотя бы порядок какой
A
Ну и самый главный вопрос - в асинхронной функции что именно было?
A
Да, интересно было бы глянуть код под разными версиями ноды
Anonymous
Alexander Bu
Кто-нибудь сталкивался с ошибкой "options.uri is a required" у request при использовании Promise.all ?
Alexander
Не мутирует ник.
иммутабельным он был бы, если бы создавал себе новые аккаунты с новыми никнеймами и закидывал бы их в чат со старых
arts
Кто-нибудь сталкивался с ошибкой "options.uri is a required" у request при использовании Promise.all ?
Ошибка явно в чём-то другом