Comments 119
Вот как с языка снял :)
ECMAScript (1997 год) — это прежде всего попытка составить спецификацию ранее появившегося JavaScript (1995 год), так что вопросы прежде всего к тем, кто потратил на дизайн языка всего десять дней
это язык со слабой типизацией и неявным приведением
Вот вы сами и ответили на свой вопрос
данные обычно приходят откуда-то из внешнего источника
Ничто не мешает один раз десериализовать/распарсить внешние данные в правильный тип и потом работать с точно известными типами. Во всех нормальных языках так делают.
если же проверять все типы в рантайме
Вообще-то в JavaScript как раз постоянно проверяются типы в рантайме… Есть оператор instanceof, есть функции вроде Array.isArray, а если вы подсунете куда-нибудь браузеру неправильный тип (например document.body.appendChild({})) он вам в ответ ругнётся о том, что тип переданного объекта не Node, например.
Кто в 2021 году складывает пустые массивы? По прежнему наркоманы?
> pyhton
>>> []+[]
[]
P.S. А почему именно пустые? Можно подумать, с непустыми массивами ситуация лучше.
[1,2,3] + [4,5,6]
"1,2,34,5,6"
[1,2,3] + [null,4,5,6]
'1,2,3,4,5,6'
Но тут главная проблема-то не в этом, а в том, что такие вещи маскируют баги.
интуитивно понятным
Сперва докажите, что такое бывает.
попросите его предсказать результат сложения 2 массивов
Гарантирую, он скажет, что так не делают.
Сперва докажите, что такое бывает.
Haskell же!
Сперва докажите, что такое бывает.
Что именно? Идеального языка пока нет, к сожалению. Языков с более логичной системой типой хватает.
Гарантирую, он скажет, что так не делают.
Так проблема и заключается в том, что язык позволяет такую конструкцию. И в определенных случаях это может привести к возникновению багов, которые будет трудно обнаружить.
Ну или возьмем другой пример:
parseInt(null, 25)
23
Строки в числа тоже никто не преобразует?)
Что именно?
Что у термина "интуитивно понятный" есть физический смысл.
И в определенных случаях это может привести к возникновению багов, которые будет трудно обнаружить.
Эти определённые ситуации отсекаются проверкой параметров. Да, в отличие от языков со статической типизацией, у нас нет для этого встроенного инструмента. Это неудобство.
Сперва докажите, что такое бывает.
PHP.
из Опыта в основном Си и Verilog
Или вы всерьез думаете, что если показать условному прохожему-не программисту с улицы программу на Go и программу на JS
Я такого не утверждал нигде. Для прохожего непрограммиста обе программы будут выглядеть китайской грамотой. А вот прохожий программист, скажем, на C++ (или Java или Python — неважно) скорее всего правильно поймет пример на Go, но пример с массивами на JS вызовет у него недоумение. Я бы, например, предположил 2 варианта: либо конкатенация, либо исключение, если операция сложения не определена для массивов. На деле же имеем третий вариант: код выполняется без ошибок, но возвращает бессмысленный результат.
— А что вас смущает?
— М… Всё.
— Это потому, что вы документацию на эту улитку не читали. Прочитайте.
— Я читал документацию. Вы правы, там ясно и чётко специфицирована одноногая улитка с однолопастным глазом на подбрюшном хвосте. Но…
— Что но? Вам лишь бы прикопаться?
— Да нет, конечно, так-то мне в целом всё равно… но давайте уточним. Вас вот совершенно не смущает одноногая улитка с однолопастным глазом на подбрюшном хвосте потому, что кто-то описал это чудо биоинженерной мысли в документации, а затем реализовал?
— Да, а что? Повторю: читайте документацию, не надо удивляться. RTFM, lamo.
— Ясно, спасибо. Удивляться я не буду.
Это к тому, что вы напрасно пытаетесь загнать оппонентов в комфортный вам шаблон «они просто не пробовали эту вкусную морковочку». Пробовали. А некоторые из моих знакомых и 10+ лет пробовали, потом ушли именно после более глубокого знакомства с другими языками.
Т.ч. нет, мир сложнее и, возможно, морковочку стоит оценивать более критично. Что, конечно, не отменяет простого: вам язык может нравиться настолько, что и фиг с остальным — позиция ничем не хуже других.
quiz из 30 вопросов, которым выносил голову любому. Собсно, сам на него уже через месяц полностью ответить не смог, настолько «интуитивные» механики языка, ага.
Это очень-очень странно. Человек либо знает язык, либо не знает. Либо вы составили его из 30 вопросов про то, что никогда ни для чего не применяется.
В процессе вёл внутри компании курсы по JS
Это мне совсем не понятно. Если человек не способен самостоятельно освоить JS по открытым источникам — значит с ним что-то сильно не так и JS-разработчиком ему не быть.
(то же скажу о любом другом языке)
Либо вы составили его из 30 вопросов про то, что никогда ни для чего не применяетсяВот сначала такое удивляло, а теперь смирился. Ну т.е. норм, что в языке заметное число конструкций и ситуаций, которые настолько не нужны / «своеобразны», что их не применяют? И язык при этом норм?
Это мне совсем не понятно. Если человек не способен самостоятельно освоить JS по открытым источникам — значит с ним что-то сильно не так и JS-разработчиком ему не быть.Это… замечательное мнение. :)
Это очень-очень странно. Человек либо знает язык, либо не знает.
В человека заложена неявная функция забывания тех вещей, которые не используются каждый день) Особенно, если они не интуитивны.
А вам правда нравится синтаксис спредов? Мне вот не очень.
Например undefined и null-я видел десятки багов связанных с этим на разных проектах.
Конечно же виновата в том, что в ней отсутствует null safety, который уже завезли в Kotlin, C# и много куда ещё
Так это же примерно половины той же проблемы. И да, жду когда завезут null-safety, как это сделано во многих популярных языках. Но проблема когда у вас есть null которыми оперируют половина внешних зависисостей или когда есть null и undefined-это в несколько раз больее глубокая проблема. И она как раз на уровне дизайна.
Основная претензия к языку это его не консистентность. Просто сравните без учета библиотек и прочего javaScript и тот же Lua. Он просто имеет травмы на уровне дизайна.
C неконсистентностью PHP сколько лет жили, пол интернета на нем написали.
У PHP между тем на уровне языка не настолько все плохо. Просто для пояснения
В php функция gettype от массива вернет array
В js функция typeof вернет object и что это массив можно узнать только через Array.isArray()
Я вот про такую неконсистентность. Если мы посмотрим что там в lua мы увидим что там схема похожа на js, но она там просто консистентна. Там есть примитивные типы, функции и таблицы. И все. И таких вот особенных типов нет.
Array — это не особенный тип, а частный случай объекта. Так же как в Lua вместо массивов используются таблицы.
Все бы ничего, если бы им пользовались как объектом. А им пользуются как массивом. И такого внутри JavaScript много и оно не очень логично.
В Lua тоже пользуются таблицей (с соответствующей метатаблицей) как массивом. И это очень логично. Тут полная аналогия.
В lua таблица расширяется до массива. И массив объявляется как таблица и при обращении к нему сообщается что это таблица. Расширение до объекта не более чем использование в качестве ключей вместо string number и все.
А как в JavaScript? Сам массив объявляется отдельной конструкцией языка, а не как объект. Т.е
test = [1,2,3,4]
test = {"test":12, 4 }В каком месте так же?
В JS массив — это объект, всё его поведение реализовано в его прототипе, как и у любого другого объекта. Его можно создать конструктором, как и любой другой объект. При обращении к нему сообщается, что это объект.
Сам массив объявляется отдельной конструкцией языка
Это синтаксический сахар. Для объекта, кстати, тоже.
Тут есть два вопроса. Какие из методов объекта массива используется напрямую? И второй зачем это было вообще делать, если практически во всех языках массив или таблица это отдельный примитивный тип?
В итоге мы имеем красивую на бумаге теорию и кривую реализацию. Чем криво? Ну просто практически никто не работает с массивом как с объектом в js.
Какие из методов объекта массива используется напрямую?
В объекте практически нет методов. Это к делу не относится.
У массива есть свойства и методы — как и положено объекту.
И второй зачем это было вообще делать, если практически во всех языках массив или таблица это отдельный примитивный тип?
Ага! Таблица в Lua — это аналог объекта в JS. Полная аналогия, которую Вы упорно не хотите видеть.
Кстати, в Java — вообще все данные — объекты.
Ну просто практически никто не работает с массивом как с объектом в js.
Да Вы что? А как с чем же с ним работают?
Что, свойства не читают и методы не вызывают?
У массива есть свойства и методы — как и положено объекту.
Проблема в том что при этом сначала надо обратиться к нему как к объекту. При этом синтаксический сахар делает так чтобы он не выглядел как объект.
Ага! Таблица в Lua — это аналог объекта в JS. Полная аналогия, которую Вы упорно не хотите видеть.
Эмм. Смотрите в lua таблица расширяется до объекта через мета таблицы и синтаксический сахар. А в js объект имплементирует массив через реализацию и синтаксический сахар. Как вообще разные вещи. Первый подход все же в динамически типизируемом языке лучше.
Кстати, в Java — вообще все данные — объекты.
Примитивные типа там все же есть, как и отдельное объявление массивов. К тому же там статическая типизация из-за этого проблемы объект или массив там фактически нет. Если у вас она там появилась, то вы явно злоупотребляете рефлексией.
Да Вы что? А как с чем же с ним работают?
Что, свойства не читают и методы не вызывают?
Обычно с ним работают через скобочную нотацию. И да из-за того что и массив и объект одно и тоже приходится городить отдельные проверки. Причем проверка делается именно для массива. Т.е. мне мало посмотреть объект ли это мне еще надо посмотреть массив ли это. Если считаете что не только для него то я бы хотел посмотреть на пример.
В итоге мы и получаем хотели как лучше, а получилось как всегда.
При этом синтаксический сахар делает так чтобы он не выглядел как объект.
Нет. Это Ваше личное искажение восприятия.
Смотрите в lua таблица расширяется до объекта через мета таблицы и синтаксический сахар.
А в js объект имплементирует массив через прототип и синтаксический сахар.
Прототип — аналог метатаблицы. Подходы идентичны.
Обычно с ним работают через скобочную нотацию.
Представьте себе, скобочная нотация в JS используется для любых объектов. Это просто другой способ обратиться к свойству по имени.
Причем проверка делается именно для массива.
А если я буду ждать на вход класс Cat, я бужу использовать проверку именно для класса Cat. Что в этом удивительного?
Нет. Это Ваше личное искажение восприятия.
Эх. Если бы только у меня. Это известная проблема и она возникает у всех. И возникает она от того что массив определяется не как объект, а именно с этим синтаксическим сахаром. И по аналогии с другими языками все ожидают что typeof будет давать им array.
Прототип — аналог метатаблицы. Подходы идентичны.
Языки похожи но не идентичны. Объявление методов мета-таблицы выполняется по другому.
Представьте себе, скобочная нотация в JS используется для любых объектов. Это просто другой способ обратиться к свойству по имени.
Я знаю. Просто разница между lua и js именно в том что lua дает более консистенный подход чем js. Тут дьявол именно в небольших деталях и ожиданиях программистов. В итоге особенностей в js приходится помнить больше чем в lua. От этого происходит частый выстрел в ногу.
Это известная проблема и она возникает у всех.
Почему у меня она никогда не возникала?
И по аналогии с другими языками все ожидают
Это главная ошибка человека, изучающего новый язык. Не ожидай того, чего тебе никто не обещал, и не будешь разочарован.
Объявление методов мета-таблицы выполняется по другому.
Чисто синтаксическая разница.
В итоге особенностей в js приходится помнить больше чем в lua.
Нет. Примерно то же на то же, просто у JS стандартная библиотека больше.
Почему у меня она никогда не возникала?
Ну потому что видимо читали полный референс. А про не ожидаемое поведение не я же один тут пишу.
Это главная ошибка человека, изучающего новый язык. Не ожидай того, чего тебе никто не обещал, и не будешь разочарован.
Чисто синтаксическая разница.
Именно она и дает проблему. Крякает как утка значит это утка. Js сильно похож на другие языки особенно в части создания массивов вот и результат. Синтаксис lua прямо указывает что массив таблица, просто за счет использования одинаковых фигурных скобок. Если бы это было так же в js или банально там бы он объявлялся через конструктор объектов проблем было бы меньше.
Нет. Примерно то же на то же, просто у JS стандартная библиотека больше.
Больше. Просто смотрите в lua
> test = {1,2,3}
> test2 = {4,3,5}
> test + test2
stdin:1: attempt to perform arithmetic on a table value (global 'test')И тут взрыв
в javascript
> test = [1,2,3]
[ 1, 2, 3 ]
> test2= [4,3,5]
[ 4, 3, 5 ]
> test + test2
'1,2,34,3,5'WAT?
Lua мне явно говорит слыш чувак я так не умею. А JavaScript делает какую-то дичь. В итоге даже случайная опечатка или не внимательность в коде может легко приводить к неопределенному поведению и сложно уловимым ошибкам. И про это приходится помнить. Плюс многие наоборот начинают таким пользоваться, что приводит опять же к странному коду.
Ну потому что видимо читали полный референс.
Не полный, а более-менее полный для начинающих. Я же не с полного референса учиться начинал.
И я интуитивно полагаю, что люди изучающие язык, изучают язык, а не "изучают как писать программы копипастом".
Все эти отсылки про "ожидаемое поведение" — выглядят как перекладывание с больной головы на здоровую. Язык изучать надо, а не "ожидать" от него чего-то.
в js или банально там бы он объявлялся через конструктор объектов проблем было бы меньше.
Да объявите, кто же вам мешает?
const arr = new Array(1, 2, 3);WAT?
В соседней ветке длинный предлинный диалог, сводящийся к тому, что здоровые люди так не делают.
Все эти отсылки про "ожидаемое поведение" — выглядят как перекладывание с больной голов на здоровую.
это выглядит как в том анекдоте.
Доктор я так делаю и мне больно. А вы так не делайте.
Хорошо бы, но люди ожидают вот и все. Делать защиту от дурака это весьма полезная тема и многие проблемы в js именно от того что авторы не подумали или не сделали.
В соседней ветке длинный предлинный диалог, сводящийся к тому, что здоровые люди так не делают.
Ну тут есть один момент, средняя квалификация по больнице у кодера js низкая. И так делают.
именно от того что авторы не подумали или не сделали.
Они на начальном этапе на самом деле много что подумали и специально не сделали. Из рассчёта на подход "не делайте так". Вы же знаете, почему в JS приватных свойств не было?
средняя квалификация по больнице у кодера js низкая.
Полагаю, проблема не в языке, а таки в самих кодерах. Не имейте дела с плохими кодерами — и будет вам счастье.
Не зря же пром стандартом становится тайпскрипт, внедряется WASM, а люди изобретают тонны решений для этих проблем разной степени успешности.
По поводу производительности — не поймите неправильно, V8 — чудо инженерной мысли, просто это концептуальное ограничение. Так то и на реализацию ООП через ссылки в java и C# говорят что она медленная.
Имхо, это все крайне споные моменты. Претензии к нишевому языку за то что он не такой как другие универсальные языки. Или давайте уж кинем претензию другим нишевым языкам. Lua, Python, PHP, Perl, Лисп. А можно еще и bash'у в догонку.
Не поймите неправильно — я разделяю ваши сожаления об отсутствии типизации, низкоуровневой работе (хотя в контексте ноды, эту проблему можно решить модулями) и прочем, но давайте не перегибать. Все равно что утверждать киянка плохой молоток и портится от гвоздей.
Так в этом-то и был изначальный посыл, что пытаются использовать нишевый язык везде где только можно, натягивая сову на глобус. А node.js оказался просто вундер расширителем совы, позволяющим растянуть ее до невиданных доселе размеров и форм каждому встречному. Но суть процесса от этого слабо поменялась и системные противоречия никуда не делись. Так что значительная часть глобусов до сих пор с огромным трудом встраивается в сов, и требует крайней осторожности, чтобы не нанести непоправимого ущерба ни тем, ни другим.
А по теме, самый лютый с моей точки зрения пример: переформатировал код, чтобы читался полегче, и все сломал. Простым переносом строки… Вот где, простите, ж*па.
Ну вы ещё слова в названии функции не camelCase пишите, а разделите пробелами для лучшего чтения, а потом удивляйтесь, что всё сломалось.
Постойте, но ведь разница между вашим предложением и переформатированием кода в том, что вы добавляете whitespace туда, где его раньше не было, а zhaparoff — менял количество различных символов whitespace там, где они и так уже были.
Он добавил перевод строки там, где его не было.
Перевод строки, согласно всем конвенциям, является whitespace, как и пробелы. А так как JavaScript относится к семейству языков, где whitespace не несёт синтаксической нагрузки, то автоматическое добавление ; в конец строк кода является очередным misfeature.
Для примера, я пока не встречал специально настроенного линтера, где бы разрешено было писать код так, чтобы эта фича интерпретатора имела возможность примениться. Там, где эта фича хоть иногда срабатывала, просто не было линтеров (на них забивали).
Я лишь пытаюсь сказать что сам язык не ужасен. :-)
Если серьёзно- js местами выдает странные вещи, но до уровня запутанности, переусложненности, странностей дизайна, отсутствия нормального ООП, дубовости компилятора (но тут просто js не компилируется) — вот этого всего набора характерного для С++, ему очень далеко. Понимаю, что кому как, а по мне именно js вполне себе неплох, но очень хотелось бы нормальное управление потоками и возможность работы со строгими типами побайтовыми (uint8, int16 и т.д.) чтобы было в нем.
Людям дела делать а не табуны сферических коней по вакууму гонять в мантии "жаба-чимпиёна"
"Ужасный" язык для ООП-нутого на всю голову а для нормального программиста в 21-ом веке уже давно понятно что типы не нужны!
Ни к каким страшнючим бедам и неудобствам отстутствие строгих типов не приводят, кто-то паука боится, а кто-то кушает.
JS стал популярным не из-за нода, популярность это когда много-много людей делают одинаковый выбор, дизайнеру JS позволял и позволяет кодить на третий день после знакомства, а не через пять лет сушения мозгов Эккелями и Шилдами и еще пяти лет змагания с табуном паттернов и все ради чего-то не шибко сложнее хэловорда схожей внешности.
Свои миллионы JS собирал вод дверями хором "джава чемпионов" куда путь простым смертным был заказан, а теперь поздняк метаться и типизация ваша никогда не будет принята народом и тайпскриптщина не поможет, сколько ни пыжься и не объявляй "победу тайпскрипта"
Типизация это кандалы а не удобства, или удобства тюрьмы, где "все понятно"
Повторяюсь: людям надо делать дела а не кадить вокруг языка, а чем пинать нод за популяризацию JS, лучше ответь себе на простой, казалось бы, вопрос: зачем понадобился котлин если джава жэ идеальный ЯП вселенной на все времена?
Проблема с index.js выглядит скорее надуманной, чем реальной, как и отсутствие расширений при подключении модулей.
Попробуйте написать свой сборщик и поймёте, что проблема совсем не надуманная. Например, тайпскрипту приходится перебирать чуть ли не десяток различных вариантов путей для каждого импорта. Всё это замедляет работу, и усложняет работу. И как следствие, привносит кучу багов и несовместимостей. Например, настройка tsconfig, чтобы всё правильно резолвилось — это целый квест. А один и тот же код в половине онлайн песочниц работает, а в другой половине — нет.
Добавьте резолв без расширений, алиасы, и разные алгоритмы резолва модулей.)
А еще попытаться на всем этом поддерживать монстра франкенштейна, оставленного в наследство предыдущими разрабами, где скрестили легаси библиотеки с какими-нибудь свежими фреймворками, и при этом для вязкости обмазали any чуть менее, чем на половину. Да, есть всякие *.d.ts, но это не сильно спасает ситуацию от протекающих абстракций и проблем с типизацией.
Мимо?
сожалел о том, что каждый его пост в блоке «привлекает сотни комментариев» и «теперь надо аккуратнее высказывать свое мнение», потому что сообщество часто понимало его слова слишком буквально.
Пожалуй да, а то получается неловкая ситуация судя по материалам статьи (глубже не копал).
Сначала несколько лет громко популяризировать свою собственную платформу, убеждая людей что её можно и нужно использовать, люди поверили ему.
Потом взять и фактически изящно кинуть всех, бросить своё детище и уйти на Go.
Потом также бодро соскочить на Rust.
Тем временем, те кто поверил ему и выбрал Node.js как свою основную платформу (энтерпрайз даже) вынуждены были выстроить своё сообщество, сами развивать систему и бороться с врождёнными болячками, который лучше всего как раз мог бы исправлять прародитель платформы.
Интересно, есть ли теперь новые желающие последовать за ним в новое потрясающее приключение с Deno?
С другой стороны, когда мне надо быстро поднять API для прототипирования чего-нибудь, то я, скорее всего, сделаю на express. Просто потому что там тяп-ляп, и готово. И при этом, если следовать гайдлайнам (то есть не выполнять вычислительно сложные задачи в основном потоке), оно будет держать нагрузку характерную для «незагруженного хайлоада», 1000 RPS проблемы не составят.
Для сравнения, легковесные процессы есть еще в Go и они же есть в виде короутин в Котлине. Но Go компилируемый, поэтому на горячую код заменить не выйдет. JVM частично поддерживает горячую замену кода (через jdb redefine), но это воспринимается как хак, и на продакшне использовать это многие боятся (и правильно делают, там будут возникать интересные спецэффекты). В nodejs можно организовать горячую замену кода через механизм сброса кэшей модулей, но я не знаю, какие ограничения у этого подхода, и пользуются ли им в продакшне. В Erlang же эта возможность — штатная. При этом в любом энтерпрайзе возможность горячей замены нужна просто с самого первого запуска системы в продакшне (те, кто говорят, что «не нужна», просто не знают, что «так можно»).
В Котлине короутина может проснуться не на том потоке, в котором засыпала, но о том, чтобы переместить ее на другую JVM или, тем более, на другую машину кластера — речи не идет, а Erlang, говорят, это умеет.
Ну и, по слухам, там формально подошли к параллелизму: исключили mutable shared state и организовали обмен информации между процессами на основе семантики сообщений.
Горячая замена делается микросервисами и контейнерами, наверное по этому эта фича не особенно востребована именно как часть языковой среды выполнения. С другой стороны для JVM есть фрейморки, например Akka, которые умеют горячий деплой. Про Котлин на докладах от разработчиков они иногда упоминают, что хотели бы сделать сериализуемые корутины, со всеми вытекающими возможностями.
Когда проект, количество кода и разработчиков растет, с чистым JS работать невозможно. Но быстрый старт — это да… главное потом выжить.
А вы знаете что уже сегодня есть поколение разработчиков не видавших никогда колбэк хела уровней так на 10 со всякими вотерфолами? А потом еще обернутыми в промисы =))
Иными словами, осваивать NodeJS не стоит? В обозримом будущем на нем перестанут делать стартапы, соответственно, Electron тоже заменится чем-то другим, так? Если я хочу уйти из скучного энтерпрайза на .net в модную хайповую разработку, с макбуком и смузи — стоит учить Go?
В обозримом будущем на нем перестанут делать стартапы
Не перестанут. Перечисленные проблемы не являются особо критичными. Deno не взлетел (это перевод доклада трехлетней давности).
Вы будете мечтать о компиляторе каждый раз когда будет прилетать эксепшен или блокер из-за самых тупых вещей. Когда весь проект написан на объектах, без нормальных моделей данных, вы будет открывать любую функцию, смотреть на параметры типа options, и гадать — а что там внутри?
Есть огромная разница между людьми которые пишут POC на JS и прыгают со стартапа в стартап и никогда не доходят до момента когда простенький POC вырос в гиганта и теперь кому-то с этим жить.
Спасибо. Ну это же наверное проблема всего JS (динамическая типизация)? Равно, как и Python/PHP.
В Python типизация динамическая, но строгая. Сложить что попало с чем попало не получится, пока один из типов не определит операцию сложения явно. А аннотации типов и сторонние утилиты вроде mypy позволяют накатить поверх питона что-то напоминающее статическую типизацию и отловить многие ошибки ещё до первого запуска кода
Но добавьте к этому еще то что весь хайп зарождался фронтендерами которые теперь могли писать бэкенд. Писали как умели. Добавьте к этом коллбэки и промисы и вообще асинхронную модель. Никаких тебе паттернов написания бэкенд сервисов. Синглтоны наше все. Тесты? О да. Давайте вначале нахреначим кода нетестируемого, а потом придумает JEST который магией поможет протестировать это все.
Если в в любом статическом языке вы 100 раз будете думать использовать ли рефлекшен, то услышать от JS разработчика «давай метапрограммирование здесь заюзеам, классная штука, я тут на конференции увидел» это нормально. Он даже не понимает какие последствия всего этого могут быть. Не хватает того что язык динамический и ты можешь себе выстрелить в голову через ногу, есть люди которые не боятся, как бы это сказать, возвести эту проблему в степень.
Да, согласен, поднять серверок за 2 минуты это круто. Запилить крад апи прямо в базу с монгуси, еще 5 минут. И если это изначально маленький проектик, то нет проблем. Но для больших проектов надо понимать, что за все придется платить.
И это я еще не говорю про то что многие не понимают разницу между CPU bound/IO bound. А если начинают понимать, начинают пизать решения типа форков, от которых меня тошнит.
Многие не доходили до проблема когда GC тупо съедает все CPU потому что такое количество инлайновых обьектов и стрингов создается что он не успевает очищать память…
Рефактор без компилятора, и даже с тестами — то еще удовольствие.
Мы вот нахавались, начали внедрять Type Script с надеждой что хоть часть проблем он уберет. С оставшимися научимся жить.
Проблема в том что многие пишут на JS скриптики или что-то простенькое, и не всегда доходят до проблем реальных приложений с нагрузкой и большой кодовой базой. Вот они будут хвалить JS.
Люди с опытом уже не так сильно будут радоваться тому что вебсервер поднять на експрессе с монго в 100 раз быстрее чем на жаве или дот нет, если знают что им нужно будет в будущем это поддерживать. Потому-что понимают во что это позже выльется. А если написать, и через 2-3 годика свалить, то норм. Уже не твои проблемы. Уже другому придется объяснять почему переименовать филд в проекте это месяц работы…
Но опять же, для POC или простых проектов, особенно IO Bound нода свою работу делает.
P.S.
А еще я всегда ржу что винда на пентиуме быстрее поднимается чем билд и приложение на ноде с +100500 зависимостями =)
Так может, не в языке дело, а в безруких разработчиках?
Почему у меня никогда не было 100500 зависимостей?
Resolving: total 3402
3402 пекеджей… Карл!!!
2.5G папочка node_modules… и это мы еще rush юзаем
Почему, достаточно понять по примеру вот этого пекеджа
github.com/i-voted-for-trump/is-even
Который стостоит, из…
'use strict';
var isOdd = require('is-odd');
module.exports = function isEven(i) {
return !isOdd(i);
};Который состоит из
'use strict';
const isNumber = require('is-number');
module.exports = function isOdd(value) {
const n = Math.abs(value);
if (!isNumber(n)) {
throw new TypeError('expected a number');
}
if (!Number.isInteger(n)) {
throw new Error('expected an integer');
}
if (!Number.isSafeInteger(n)) {
throw new Error('value exceeds maximum safe integer');
}
return (n % 2) === 1;
};
Который состоит из
'use strict';
module.exports = function(num) {
if (typeof num === 'number') {
return num - num === 0;
}
if (typeof num === 'string' && num.trim() !== '') {
return Number.isFinite ? Number.isFinite(+num) : isFinite(+num);
}
return false;
};Где-то мир свернул не туда…
Насчет безруких разработчиков. Тут проблема не в безруких. Проблема в разных. С разным бэкграундом, целями, возможностями, хотелками, опытом и т.д. И вот тут та свобода и «простота» которую дает JS выходит боком.
Можете мой монорепо забилдить. Там всего 170 зависимостей зависимостей. Всё хочу как-нибудь тайпскрипт и экспресс выпилить, да руки не доходят.
'use strict';
var isOdd = require('is-odd');
var not = require('not');
module.exports = not(isOdd);
:)
Хоспати бедный убогий мир js
Как создатель node.js сам разочаровался в нем