Тут скорее дело привычки, по сути и XAML и HTML — диалекты XML для разметки. Только на HTML Вы сразу знаете как какую-то задачу выполнить, а на XAML — надо сначала в документацию заглянуть.
IDEA на Java, она тоже жрёт дохрена, когда я её года 3-4 назад (в варианте Redmine) пробовал на своих проектах, она вообще тупо висла и даже тюнинг настроек JVM не особо помогал. Но это хотя бы IDE, а Atom по задумке должен быть легковесным редактором, если я ничего не путаю. Поэтому и потребление памяти у него должно быть на порядок меньше.
Я лично не могу сказать, может ли он обогнать IDEA по расходу ОЗУ. Но это как-то странно выбирать из двух прожорливых самого прожорливого. Я помню ещё времена Delphi 7 и Visual Studio 2005 и как-то ж блин всё отлично работало на компе с 768 Mb ОЗУ, прям летало )))
А вообще, накакокодить можно на любом языке, было бы желание.
Безусловно, но бэкенд уже по-моему у всех под постоянным мониторингом, даже на staging, поэтому там это редко доходит до production. Ну а если доходит, то сразу алерты приходят. На фронте же отслеживать производительность — пока редкость.
Если говорить про разработку классических desktop-приложений, то для них подразумевается QA-отдел, который в том числе проверяет, чтобы ничего не тормозило на всех target-платформах(версиях ОС и т.д.).
Т.е. можно снять часть ответственности с программистов на JS, сказав, что проблема в незрелости JS-платформы, но с другой стороны кто если не они, должен осознать необходимость использовать инструменты и способы контроля, которые в других областях уже используются по умолчанию.
Другими словами, надо уже осознать, что JS из языка для простеньких скриптиков превратился в язык для написания фронтенд-приложений и относится к разработке на нём так же серьёзно, как к разработке на языках, используемых для server-side и desktop.
само приложение отъедает ее только если есть какие-либо ресурсозатратные процессы, либо руки из жопы растут
ну так, бессмысленная и беспощадная растрата ресурсов — это не такая уж редкость в 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, который ещё и память на абсолютно ненужную последовательность тратить будет.
Я лично не могу сказать, может ли он обогнать IDEA по расходу ОЗУ. Но это как-то странно выбирать из двух прожорливых самого прожорливого. Я помню ещё времена Delphi 7 и Visual Studio 2005 и как-то ж блин всё отлично работало на компе с 768 Mb ОЗУ, прям летало )))
Но в целом да, поскромнее атома.
Если говорить про разработку классических desktop-приложений, то для них подразумевается QA-отдел, который в том числе проверяет, чтобы ничего не тормозило на всех target-платформах(версиях ОС и т.д.).
Т.е. можно снять часть ответственности с программистов на JS, сказав, что проблема в незрелости JS-платформы, но с другой стороны кто если не они, должен осознать необходимость использовать инструменты и способы контроля, которые в других областях уже используются по умолчанию.
Другими словами, надо уже осознать, что JS из языка для простеньких скриптиков превратился в язык для написания фронтенд-приложений и относится к разработке на нём так же серьёзно, как к разработке на языках, используемых для server-side и desktop.
Так что не мог совсем не упомянуть, всё-таки поразительно много людей программируют на 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, который ещё и память на абсолютно ненужную последовательность тратить будет.