Мне кажется куда душа ляжет. Про Python я то же не очень согласен, так как в отличии от ruby/php это не web-only язык (в сравнении конечно). К слову Go уже становится не модно, а Rust немного вырастает как и Elexir.
PS ну и всё же async statefull код (ака websockets) удобнее писать на Python3/Elexi/NodeJS, в PHP/Ruby с этим куда хуже.
Спасибо за обзор, было очень интересно (часто писал/пишу на Python/Tornado/Pylons). Как обстоят дела с асинхронностью в Erlang?
Есть ли возможность писать явно асинхронный код ака asynс из Python 3.5?
К сожалению часто микромодуль противоречит вот этому:
— эта строка просматривается бòльшим числом глаз чем она просматривалась бы в одном проекте
— эта строка имеет меньшую вероятность внести ошибку в проект нежели написанная с нуля, особенно неискушённым разработчиком
такие вещи начинают использовать не задумываясь. Кроме того у JS есть серьёзные проблемы со сборкой и получением JS нужных размеров и нарезанных нужным образом… (1 Mb JS файл часто не вариант качать, как и 50-60 мелких файлов)
Я короче в JS для Frontend отказался от любых сборочных систем, текущая ситуация меня не устраивает.
Советую тогда глянуть другие языки где с этим нету проблем (конечно там будут свои проблемы). PHP7 конечно знатный рывок но в сторону старой ниши. т.е. с PHP7 язык большим конкурентом Python/Ruby/Go/Rust/C++ и т.д. не стал.
ЗЫ statefull модель полезна для WebSockets. В том же Python+Tornado я в одном коде могу писать statefull вебсокет хендлеры и stateless http хендлеры, мне не нужны разные языки/фреймворки для этого. Использовать для хранения информации всякие Redis между состояниями конечно можно, но это медленно и далеко не всегда удобно.
Эх… ну я вроде стараюсь всем их требованиям удволетворять. Я просто не понимаю почему они не банят тогда Facebook/Instagram/Twitter где порево найти как нефиг делать?
О! Ну с моим анимешным приложением было то же самое. Они крайне ревниво к этому относятся. Со второй попытки вроде нормально. Правда я думаю, что после 100 000 скачек они начинают осторожнее относится. :)
Ну нельзя так просто взять и проиграть аудио файл. Забыли самый злобный и неприятный для MS вопрос: форматы аудио.
А именно то, что MS отказывается поддерживать свободные видео и аудио стандарты (как и картинки аля WebP).
Хотя вроде пошли подвижки с Opus но видимо из-за Ogg контейнера они тормозят (для RTS поддержка уже есть).
Количество решений как то не тянет на слово "хак". Может просто не очень удачное решение?
Ну и насколько я это себе понимаю, http2 больше помогает серверу чем клиенту.
А основной стандарт — един. Опциональные фишки в нём — это признания того, что что-то было в него включено по ошибке (VLA-массивы в C11, export шаблонов в C++11).
С этим я соглашусь, хотя VLA после C99 мне не хватает в C++.
О чём, собственно, авторы обсуждаемой статьи и говорят: если ваша фича кому-то может помочь, а кому-то — не нужна совершенно значит ей в стандарте C++17 делать нечего.
Вот с этим я категорически не согласен.
Правда мне кажется мы просто на это совершенно с разных точек зрения смотрим. Я смотрю как пользователь языка и мне кажется совершенно нормально когда ты в проекте используешь 20-30% возможностей (правило Парето).
т.е. для меня это естественно, что вот в этом проекте я использую эту фичу, а вон в том мне она нафиг не нужна. К примеру есть много кода где даже не пахнет unique_ptr и аналогами.
Правильно я понимаю, что вы разработчик компилятора или stdc++ и у вас есть серьёзные опасения, что без костылей и проблем эту фичу не реализовать? Если так, то это совсем иная история, и тут спорить не хочу.
Однако замечу, что скорее всего есть проблема сопряжения подходов, но тогда всегда можно написать (даже в стандарте) к примеру: внутри await функции не может быть порождение thread и т.д. Хотя может быть это и костыляво.
И всё же, вы часто работали с асинхронынми кодом? У вас был тот самый callback-hell? Просто те кто через это прошли и потом освоили технологии аналогичные asyncio понимают их необходимость и то, что это просто must have.
Синтаксически и логически мне текущее предложение нравится НО не нравится то, что не описана реализация, а то что предложил MS за гранью добра.
PS ну и всё же async statefull код (ака websockets) удобнее писать на Python3/Elexi/NodeJS, в PHP/Ruby с этим куда хуже.
Есть ли возможность писать явно асинхронный код ака asynс из Python 3.5?
такие вещи начинают использовать не задумываясь. Кроме того у JS есть серьёзные проблемы со сборкой и получением JS нужных размеров и нарезанных нужным образом… (1 Mb JS файл часто не вариант качать, как и 50-60 мелких файлов)
Я короче в JS для Frontend отказался от любых сборочных систем, текущая ситуация меня не устраивает.
ЗЫ а так elite-games наше всё! Свобода среди звёзд.
ЗЫ statefull модель полезна для WebSockets. В том же Python+Tornado я в одном коде могу писать statefull вебсокет хендлеры и stateless http хендлеры, мне не нужны разные языки/фреймворки для этого. Использовать для хранения информации всякие Redis между состояниями конечно можно, но это медленно и далеко не всегда удобно.
Всё наоборот, LESS, SASS, Stylus появились из-за того, что CSS слишком примитивный (сейчас по лучше).
А именно то, что MS отказывается поддерживать свободные видео и аудио стандарты (как и картинки аля WebP).
Хотя вроде пошли подвижки с Opus но видимо из-за Ogg контейнера они тормозят (для RTS поддержка уже есть).
Ну и насколько я это себе понимаю, http2 больше помогает серверу чем клиенту.
С этим я соглашусь, хотя VLA после C99 мне не хватает в C++.
Вот с этим я категорически не согласен.
Правда мне кажется мы просто на это совершенно с разных точек зрения смотрим. Я смотрю как пользователь языка и мне кажется совершенно нормально когда ты в проекте используешь 20-30% возможностей (правило Парето).
т.е. для меня это естественно, что вот в этом проекте я использую эту фичу, а вон в том мне она нафиг не нужна. К примеру есть много кода где даже не пахнет unique_ptr и аналогами.
Правильно я понимаю, что вы разработчик компилятора или stdc++ и у вас есть серьёзные опасения, что без костылей и проблем эту фичу не реализовать? Если так, то это совсем иная история, и тут спорить не хочу.
Однако замечу, что скорее всего есть проблема сопряжения подходов, но тогда всегда можно написать (даже в стандарте) к примеру: внутри await функции не может быть порождение thread и т.д. Хотя может быть это и костыляво.
И всё же, вы часто работали с асинхронынми кодом? У вас был тот самый callback-hell? Просто те кто через это прошли и потом освоили технологии аналогичные asyncio понимают их необходимость и то, что это просто must have.
Синтаксически и логически мне текущее предложение нравится НО не нравится то, что не описана реализация, а то что предложил MS за гранью добра.
Скажите что ваша платформа не поддерживает эту фичу. Я не понимаю вас, поясните.