само приложение отъедает ее только если есть какие-либо ресурсозатратные процессы, либо руки из жопы растут
ну так, бессмысленная и беспощадная растрата ресурсов — это не такая уж редкость в JS-мире… или вам не попадались сайты, которые из-за какой-нибудь тупой анимации отжирали на 100% целое ядро процессора, или простейшие странички, которые из-за какого-то текущего скрипта фоном отжирали память?
Так что не мог совсем не упомянуть, всё-таки поразительно много людей программируют на JS не задумываясь ни про ОЗУ, ни про CPU. Хотя само собой, это относится не ко всем JS-программистам. Так что, если Вы пользуетесь упомянутым отладчиком CPU/памяти или хоть как-то задумываетесь над ресурсоёмкостью написанного кода, то извините за обобщение ;-)
Поддерживаю, 16 Gb уже и без виртуалки еле-еле хватает.
Что браузеры, что js-программисты уже совсем краёв не видят.
Если памяти много, то это не значит, что каждая вкладка должна 200-300 Mb отжирать…
Chicago Boss выглядит слегка заброшенным. Вроде начали делать версию 0.9 и при этом за 3 предыдущие месяца всего 3 коммита.
А так, для веба ещё N2O есть.
По-моему, Elixir как раз устраняет большую часть перечисленных вами минусов.
Я тоже в прошлом году проводил сравнение Go и Elixir для узких мест. В итоге победил Elixir.
Наиболее удивительным для меня фактом было то, что экосистема Elixir оказалась более зрелой, чем у Go. Несмотря на то, что Go на несколько лет старше, в его экосистеме до сих пор преобладает хаос и анархия. И при выборе библиотек остаётся только удивляться насколько распространен среди гоферов NIH-синдром.
stride — это способ генерации последовательности/массива, поэтому использовать его для замены счётчика итераций значит использовать его не по назначению. Я не уверен в отсутствии оптимизаций на этот случай на уровне компилятора, но, честно говоря, присутствие таких оптимизаций было бы нелогичным. Классический цикл for отсутствует во многих функциональных языках, но в любом из них генерация списка чисел для обхода считается моветоном.
А потом другим программистам наслаждаться поддержкой кода таких творцов.
Вы всерьёз считаете, что конструкции типа for i in 1000000.stride(to:1, by: -1)
читаемы и удобнее в поддержке, чем примитивный for-цикл?
Или что операторы инкремента/декремента могут стрелять по ногам?
Понятно, что авторы языка решают что оставлять, но аргументы на тему, что конеретно эти изменения хоть как-то способны улучшить качество кода, выглядят очень странно.
Ладно бы все, как один, написали: фиг с ним с for, будем хвостовую рекурсию использовать… но нет, все про этот жуткий вариант со stride, который ещё и память на абсолютно ненужную последовательность тратить будет.
Я вспоминаю 2007-й год. Из всего фронт-энда у нас был только PrototypeJS.
Справедливости ради, уже был выбор как минимум из PrototypeJS, MooTools, jQuery и YUI.
Хотя мне ещё тогда казалось, что это перебор. А сейчас этот буриданов выбор расплодился в геометрической прогрессии.
То, что в кортеж нельзя добавить новые элементы, не делает его структурой времени компиляции, а лишь неизменяемой структурой данных. Есть много языков, в которых ни один экземпляр любого типа нельзя изменить во время выполнения. Но это не повод называть тот же list структурой времени компиляции.
Допустим, у нас есть кортеж {x, y}, если его конкретное значение может быть всегда вычислено на этапе компиляции, то да, это структура времени компиляции. Но если какой-то внешний фактор, например пользовательский ввод, может повлиять на значение x или y, то это уже совсем не структура времени компиляции.
Так что не мог совсем не упомянуть, всё-таки поразительно много людей программируют на JS не задумываясь ни про ОЗУ, ни про CPU. Хотя само собой, это относится не ко всем JS-программистам. Так что, если Вы пользуетесь упомянутым отладчиком CPU/памяти или хоть как-то задумываетесь над ресурсоёмкостью написанного кода, то извините за обобщение ;-)
И это без открытых проектов.
Что браузеры, что js-программисты уже совсем краёв не видят.
Если памяти много, то это не значит, что каждая вкладка должна 200-300 Mb отжирать…
На Хабре тоже этой темы касались: https://habrahabr.ru/post/245135/
А так, для веба ещё N2O есть.
Я тоже в прошлом году проводил сравнение Go и Elixir для узких мест. В итоге победил Elixir.
Наиболее удивительным для меня фактом было то, что экосистема Elixir оказалась более зрелой, чем у Go. Несмотря на то, что Go на несколько лет старше, в его экосистеме до сих пор преобладает хаос и анархия. И при выборе библиотек остаётся только удивляться насколько распространен среди гоферов NIH-синдром.
А вот почему забыли про Elixir и Nim непонятно...
Вы всерьёз считаете, что конструкции типа
for i in 1000000.stride(to:1, by: -1)читаемы и удобнее в поддержке, чем примитивный for-цикл?
Или что операторы инкремента/декремента могут стрелять по ногам?
Понятно, что авторы языка решают что оставлять, но аргументы на тему, что конеретно эти изменения хоть как-то способны улучшить качество кода, выглядят очень странно.
Ладно бы все, как один, написали: фиг с ним с for, будем хвостовую рекурсию использовать… но нет, все про этот жуткий вариант со stride, который ещё и память на абсолютно ненужную последовательность тратить будет.
Хотя мне ещё тогда казалось, что это перебор. А сейчас этот буриданов выбор расплодился в геометрической прогрессии.
Допустим, у нас есть кортеж {x, y}, если его конкретное значение может быть всегда вычислено на этапе компиляции, то да, это структура времени компиляции. Но если какой-то внешний фактор, например пользовательский ввод, может повлиять на значение x или y, то это уже совсем не структура времени компиляции.