Можно. Только рядовой пользователь не будет мучиться. Андроиды блокируют установку приложений без выключения настройки и не все юзеры вообще знают что такое апк и что бывают файлы других форматов помимо пдф / картинок. А о убытках рекламы и убытков от отсутствия гугл сервисов и говорить не приходится, к сожалению...
Ну вот у меня какой то софт которому 10 лет есть. Или даже 15. Который не обновлялся и сам разработчик забыл о своём же детище. К я пользуюсь потому что не хочу искать альтернативы или привык. Или игрушка какая нибудь например. Или что угодно что не обновляется и может зависеть от ресурсов.
Что тогда? Сейчас все оживут и начнут портировать софт? Нет конечно) или начнут оптимизировать игрушки теже? Нет. Останется вариант с эмуляцией. Что может значительно повлиять на перфоманс или привести к багам если софт слишком специфично написан. (банально какая нибудь статистика у которой проверка лицензии встроена в самописный драйвер винды)
Даже сейчас с обилием арм и мобильных телефонов на андроиде (читаем линукс), лишь некоторый относительно малый - средний процент почти рядовых программ работает на андроиде под арм. У другого софта арм версии вообще нету. Хотя кроме исправления какого нибудь prefix и env и добавления платформы компиляции в настройках компилятора более ничего может и не потребоваться от разработчика. Вместо этого этим занимается комьюнити а не разработчики.
Не знаю о каком утопическом будущем вы говорите но оно может сработать только если вам реально надо открыть 1-2 вкладки в браузере. Для всего остального начинаются проблемы.
Х86/64 хорошие и мощные архитектуры. Несчастный арм их не заменит. А тем более риск какой нибудь. Только если у домохозяек. Это все одна большая погоня за зайцем. А в конце ничего кроме зайца и не останется. Как и от разработчиков программ которым этот арм как собаке пятая нога.
Инициатива хорошая. Кроссплатформенность. Независимость от архитектур. Мобильность. Но только на бумаге. На практике... Выйдет кот в мешке.
На самом деле вещь очень интересная. При желании и силах можно много интересного сделать. Особенно учитывая что это самостоятельная реализация протокола которая работает на многих серверах и версиях и при желании можно подружить с многими модами, хоть и не идеально.
Про что? Про IPC обозванным потоками! :) На уровне абстракции вы правы - воркеры можно рассматривать как потоки. Однако на деле, под капотом работает почти отдельный самостоятельный инстанс движка, который разделяет родителя\потомка, перенаправляет банально stdin\out итд итп. По итогу мы имеем оверхед просто от существования "потока" в виде инстанса, потребляемой памяти и прочей радости в виде больших потерь на том самом IPC, чего на нативных слоях даже в помине нету кроме условных одного - другого десятка байт на хэндл и прочей метаинфы.
Не поймите меня не правильно. Я сам люблю ноду. Однако как уже выше верно сказано - нода не про многопоточность. Нода в принципе не про многопоточность. И никогда не будет. Как и не будет про тяжелую нагрузку.
А в чем сложность написания нативного модуля? Сейчас (да и думаю уже давно) есть решения которые позволяют это делать одной двумя кнопками. Либо если не нативный модуль то можно делегировать тяжелую задачу на какой нибудь бинарь.
Строго говоря это и не многопоточность, это банальное масштабирование. Многопоточность как термин воркеров, здесь мало уместен.
Да иногда можно выиграть. Но с другой стороны, если нужен настоящий выигрыш - легче написать модуль нативный который по настоящему многопоточно что то гоняет а не извращаться подобным образом. Впрочем, зависит от задач.
По вашему 512 мегабайт памяти для приложения которое делает несколько хттп запросов к телеграмму и столько же, даже меньше, в базу данных - это нормально?
Разумеется, что фактическое потребление будет составлять в несколько раз меньше. Однако если держать в уме функцию приложения, которое должно среди строк искать несколько конкретных заранее известных из списка строк и давать в ответ заранее известные строки - вам не кажется, что даже 'в несколько раз меньше' - это все ещё очень много? И вам не кажется что при таких цифрах возможно стоит использовать либо другой язык и стек либо реализовать вещи вручную что бы не было такого огромного потребления?
Так вот именно что куча вариантов. Так вот именно что есть огромное количество возможностей. Полностью согласен с вами. Было бы лишь желание. Чего к сожалению все меньше у программистов и с каждым годом все больше абстракций над слоном и нежеланием разбираться с другими технологиями где можно потратить условно на час больше но получить тоже самое и даже и лучше за счёт меньшего слонохеда. Или получить опыт например.
Ваш вопрос слишком материалистический и делегирующий. Базы данных и pdf с почтой это далеко не то, зачем половина языков была создана. Не беря совсем частные случаи, конечно.
При желании можно сделать многое на многом. Работу в базой данных на Haskell, работу с pdf на Ruby и отправку емейла с Julia. При желании зачастую ничто не мешает скрестить одно с другим под видом третьего. Или например какой нибудь Cobol на котором работает некая часть экономической инфраструктуры в Америке. А возможно и не только там...
Вопрос удобства как исходной точки истины - не самый ведущий к результату. В начале нулевых или даже 80 не было такого обилия литературы и "удобства" среди языков как сейчас. Да и части языков в принципе не было. К тому моменту существующие языки были распространены в меру своих возможностей и на них писали. Несмотря на отсутствие удобств, на написанном руками ассемблере летали на луну. Несмотря на отсутствие удобств, есть ядра Linux и Windows NT/... которые все работают по всему миру на легаси коде написанных на не самых удобных языках при этом стабильно (разные сегментфолты или бсоды не берём в расчёт).
Языки которые предоставляют базовый функционал общего назначения - подойдут для почти всего. Делегировать на язык как на панацею который решает твои проблемы - ошибочно. Решать их должен программист. Но нынешний программист решать не хочет а хочет удобные ORM а за отсутствием таковых идёт писать статьи или делиться мнением почему язык ххх - в топку.
Вопрос бизнеса - это вопрос бизнеса. Вопрос удобства - вопрос личного навыка и личного желания.
Можно. Только рядовой пользователь не будет мучиться. Андроиды блокируют установку приложений без выключения настройки и не все юзеры вообще знают что такое апк и что бывают файлы других форматов помимо пдф / картинок. А о убытках рекламы и убытков от отсутствия гугл сервисов и говорить не приходится, к сожалению...
С каждой такой новостью окончательно разочаровываюсь в Маске.
Сидел бы ракеты запускал и модельку телсы тренировал.. Нет.
Да?
Ну вот у меня какой то софт которому 10 лет есть. Или даже 15. Который не обновлялся и сам разработчик забыл о своём же детище. К я пользуюсь потому что не хочу искать альтернативы или привык. Или игрушка какая нибудь например. Или что угодно что не обновляется и может зависеть от ресурсов.
Что тогда? Сейчас все оживут и начнут портировать софт? Нет конечно) или начнут оптимизировать игрушки теже? Нет. Останется вариант с эмуляцией. Что может значительно повлиять на перфоманс или привести к багам если софт слишком специфично написан. (банально какая нибудь статистика у которой проверка лицензии встроена в самописный драйвер винды)
Даже сейчас с обилием арм и мобильных телефонов на андроиде (читаем линукс), лишь некоторый относительно малый - средний процент почти рядовых программ работает на андроиде под арм. У другого софта арм версии вообще нету. Хотя кроме исправления какого нибудь prefix и env и добавления платформы компиляции в настройках компилятора более ничего может и не потребоваться от разработчика. Вместо этого этим занимается комьюнити а не разработчики.
Не знаю о каком утопическом будущем вы говорите но оно может сработать только если вам реально надо открыть 1-2 вкладки в браузере. Для всего остального начинаются проблемы.
Х86/64 хорошие и мощные архитектуры. Несчастный арм их не заменит. А тем более риск какой нибудь. Только если у домохозяек. Это все одна большая погоня за зайцем. А в конце ничего кроме зайца и не останется. Как и от разработчиков программ которым этот арм как собаке пятая нога.
Инициатива хорошая. Кроссплатформенность. Независимость от архитектур. Мобильность. Но только на бумаге. На практике... Выйдет кот в мешке.
На самом деле вещь очень интересная. При желании и силах можно много интересного сделать. Особенно учитывая что это самостоятельная реализация протокола которая работает на многих серверах и версиях и при желании можно подружить с многими модами, хоть и не идеально.
Если будешь писать продолжение - повышай градус.
Про что? Про IPC обозванным потоками! :)
На уровне абстракции вы правы - воркеры можно рассматривать как потоки. Однако на деле, под капотом работает почти отдельный самостоятельный инстанс движка, который разделяет родителя\потомка, перенаправляет банально stdin\out итд итп. По итогу мы имеем оверхед просто от существования "потока" в виде инстанса, потребляемой памяти и прочей радости в виде больших потерь на том самом IPC, чего на нативных слоях даже в помине нету кроме условных одного - другого десятка байт на хэндл и прочей метаинфы.
Не поймите меня не правильно. Я сам люблю ноду. Однако как уже выше верно сказано - нода не про многопоточность. Нода в принципе не про многопоточность. И никогда не будет. Как и не будет про тяжелую нагрузку.
А в чем сложность написания нативного модуля? Сейчас (да и думаю уже давно) есть решения которые позволяют это делать одной двумя кнопками. Либо если не нативный модуль то можно делегировать тяжелую задачу на какой нибудь бинарь.
Строго говоря это и не многопоточность, это банальное масштабирование. Многопоточность как термин воркеров, здесь мало уместен.
Да иногда можно выиграть. Но с другой стороны, если нужен настоящий выигрыш - легче написать модуль нативный который по настоящему многопоточно что то гоняет а не извращаться подобным образом. Впрочем, зависит от задач.
По вашему 512 мегабайт памяти для приложения которое делает несколько хттп запросов к телеграмму и столько же, даже меньше, в базу данных - это нормально?
Разумеется, что фактическое потребление будет составлять в несколько раз меньше. Однако если держать в уме функцию приложения, которое должно среди строк искать несколько конкретных заранее известных из списка строк и давать в ответ заранее известные строки - вам не кажется, что даже 'в несколько раз меньше' - это все ещё очень много? И вам не кажется что при таких цифрах возможно стоит использовать либо другой язык и стек либо реализовать вещи вручную что бы не было такого огромного потребления?
Нет. Но это камень в сторону использующих технологию и крайне лишнего оверхеда из за пары хттп запросов и одного запроса в базу данных. Крайне.
Я извиняюсь но смотря на " Для комфортной работы бота хватает 512 мб памяти" хочется плакать. К автору статьи вопросов нет но...
Так вот именно что куча вариантов. Так вот именно что есть огромное количество возможностей. Полностью согласен с вами. Было бы лишь желание. Чего к сожалению все меньше у программистов и с каждым годом все больше абстракций над слоном и нежеланием разбираться с другими технологиями где можно потратить условно на час больше но получить тоже самое и даже и лучше за счёт меньшего слонохеда. Или получить опыт например.
Боюсь спросить что будет лет через 20.
Ваш вопрос слишком материалистический и делегирующий. Базы данных и pdf с почтой это далеко не то, зачем половина языков была создана. Не беря совсем частные случаи, конечно.
При желании можно сделать многое на многом. Работу в базой данных на Haskell, работу с pdf на Ruby и отправку емейла с Julia. При желании зачастую ничто не мешает скрестить одно с другим под видом третьего. Или например какой нибудь Cobol на котором работает некая часть экономической инфраструктуры в Америке. А возможно и не только там...
Вопрос удобства как исходной точки истины - не самый ведущий к результату. В начале нулевых или даже 80 не было такого обилия литературы и "удобства" среди языков как сейчас. Да и части языков в принципе не было. К тому моменту существующие языки были распространены в меру своих возможностей и на них писали. Несмотря на отсутствие удобств, на написанном руками ассемблере летали на луну. Несмотря на отсутствие удобств, есть ядра Linux и Windows NT/... которые все работают по всему миру на легаси коде написанных на не самых удобных языках при этом стабильно (разные сегментфолты или бсоды не берём в расчёт).
Языки которые предоставляют базовый функционал общего назначения - подойдут для почти всего. Делегировать на язык как на панацею который решает твои проблемы - ошибочно. Решать их должен программист. Но нынешний программист решать не хочет а хочет удобные ORM а за отсутствием таковых идёт писать статьи или делиться мнением почему язык ххх - в топку.
Вопрос бизнеса - это вопрос бизнеса. Вопрос удобства - вопрос личного навыка и личного желания.