Comments 18
Даже не сразу понял, что это метафора :D
За то, один раз описав — можно было назвать это «принеси тапки», и в следующий раз уже сразу писать кратко и понятно.Это широко использовалось и до Синтезатора Интеллектуального, еще в эпоху Автоматического Синтезатора Морфем.
А СИ не столь сильно повлиял на языки, как, например, тот же Фортран (просто Си на сегодня более известный и популярный)
И Питон был далеко не первым скриптовым (хотя один из самых известных на сегодня), а JS был сделан изначально не для простоты обучения (но получил популярность во многом благодаря этому)
Ну а нужда в программистах на JS породила спрос на обучение на JS.
Однако чем позже тем больше всякого стали делать «на JS» и «под node/npm». Да что там говорить — сам node.js был явно сделан не по причине отсутствия альтернатив для разработки под backend, а именно дабы получить тех самых «full-stack разработчиков» и очередной раз удешевить разработку софта для корпораций (зачем нам два девелопера с половинной загрузкой, когда можно взять одного на полную?)
Да и сами разработчики, осознавшие спрос на себя и постоянно прыгающие с фирмы на фирму и поднимающие себе ЗП, и обвешивающиеся позывными «Senior/Principal» через 2-3 года после начала работы программистом, создают для бизнеса потребность в поиске или обучении новых и новых кадров
Короче, причин много, единую выделить сложновато
главное чтобы технология WebAssembly не «свернула не туда», тогда может будет хоть какой-то просвет в этом постоянно наростающем хаосе
Как всегда — это мое личное мнение и взгляды на вещи
Вы бы хоть историю ноды почитали, что ли. Не вижу ничего плохого а личном мнении, но не когда оно основано на фантазиях.
Из того что я знаю и помню о Node.JS, то его создателю не нравились часто используемые подходы к программированию серверных решений ограничивающих пропускную способность. А т.к. V8 к тому моменту стал весьма шустрым, то давнюю мечту (еще времен NetScape) писать на одном языке на фронте и на беке вышло воплотить в реальность
Уточните где не прав, пожалуйста
Вы не правы в предпосылке о том, что у кого-то была мечта писать на беке и на фронте на одном языке, и именно из-за этого всё и пошло.
Не было такой мечты у Райана. И у больших компаний тоже такой мечты нет — потому что там всё равно бэкендеры отдельно от фронтендеров. О фуллстеках мечтают только маленькие компании, но им без разницы, один язык требовать или четыре. И они разработку не двигают, а скорее паразитируют на ней.
Так же вы не правы в том что были альтернативы JS на фронте. JS тогда был не сахар, но "альтернативы" были полнейшей помойкой — в равной мере и флеш и сильверлайт и джава апплеты. JS победил в этой войне ровно по той причине, что альтернативы были гораздо хуже. Действительно, только webAssembly похоже на потенциальную альтернативу. Спустя очень много лет.
Можно ли было тоже самое реализовать на С++ и даже быстрее сделать? Можно
Можно ли было сделать очередной PyPy, который бы решал вопросы производительности самого Python — думаю можно. Но зачем, когда есть язык на котором уже многие пишут и под него есть движок на котором можно все уже сделать производительным?
Опять же, доказательств не имею, но мне кажется многие большие компании поддержали эту разработку именно по причине того что новых девелоперов получить можно больше и дешевле (новый язык учить не нужно).
Насчет «мечт о full-stack» — отчасти соглашусь. Лишь отчасти, но это уже другая история
А вот насчет «альтернатив JS на фронте» — вот тут не согласен. Да, у альтернатив было полно «но», как я и писал. Однако они активно развивались и расширялись до определенного времени. Тот же Flash поставлялся «из коробки» браузером Chrome, который долгое время держит лидирующие позиции на desktop рынке. И весьма большое число сайтов либо полноценно (сайты многих крупных автомобильных компаний), либо местячково (даже тот же gmail) использовали эту технологию на своих сайтах до поры до времени.
JS их победил, по большей части, потому что развивался открыто и многими компаниями, а не внутри одной корпорации (привет, Adobe!)
Но выбор языка, думаю (хотя доказательств и не имею), был сделан именно ввиду распространенности в web и простоты JS в изучении
Ну вот я и говорю — перед тем, как говорить, имеет смысл минимально изучить вопрос. Райан хотел попробовать сделать чисто асинхронный серверный движок. И ровно потому что JS отлично подходил под эту парадигму — он использовал его. Сейчас есть альтернативы в виде Rust и Go. Да и остальные подтянули асинхронную парадигму. Десять лет назад таких вариантов просто не было.
Да, можно было написать очередной интерпритатор питона или ещё один ReactPHP — но зачем? Райан хотел попробовать новую парадигму — и она взлетела.
А вы натягиваете сову на глобус ради свои убеждений. Не надо так. Мир немного сложнее, чем "все хотят тонну дешёвых фуллстек говнокодеров индусов на JS".
Java, C#, C++ и куча других вариантов — что мешает сделать асинхронно?
Если уж на то пошло, то JS для асинхронщины вообще не особо хороший вариант. Сам JS код выполняется однопоточно, только I/O многопоточный
А если дело в «так проще для разработчиков» — тогда был Python с его стандартной реализацией CPython, который наиболее близко походил на JS, т.к. хоть код и выполнялся конкурентно, но не было параллельности а стало быть и проблем с параллельным использованием объектов, dead-lock-ов и прочих потенциальных блокировок
Так что, как мне кажется, главной причиной использования JS а не Java/C#/C++ и т.д. было именно создание движка под который проще писать особенно новичкам, чтобы не мучиться со всякими mutex-ами и потенциальными dead-lock-ами
К слову — делать язык/систему для уменьшения потенциальных ошибок от новичков — это еще не плохой подход. Тот же Go был сделан именно с этой мыслью. Только там это сделано путем уменьшения кол-ва возможностей в языке и применении практик приводящих в более явному и прозрачному коду (порой в ущерб краткости). Только вот в JS подход к решению этих проблем иной
В C# async/await появился только в 2012 студии. До этого там на каждый чих было принято создавать потоки. Про написание асинхронного кода в джаве лучше молчать. На плюсах веб сервисы практически никто не пишет. Про питон ничего не скажу — в питоне не разбираюсь, и предпочитаю не делать выводы по вещам, о которых не знаю. Но вы можете придерживаться другой точки зрения, если от этого чувствуете себя лучше других — кто ж помешает.
>Про написание асинхронного кода в джаве лучше молчать
А чего ж молчать то? В чем такая проблема асинхронного кода в Java? там утилит для его написания даже больше чем нужно
>На плюсах веб сервисы практически никто не пишет
Тоже не правда. То что там разработчиков толковых найти сложнее — это факт. Но есть те же TreeFrog, CppCMS и прочие
А если же ваш web-server требует websockets и высокую производительность — так там и вовсе С++ весьма недурной выбор
Тут вопрос в том в какие сферы и на потребности каких фирмы смотреть
В C# async/await появился только в 2012 студии. До этого там на каждый чих было принято создавать потоки.
В C# с незапамятных времен были асинхронные подходы. Равно как и в Java.
Семантика async/await сильно отличается от того, как это работает в JS. В C# для выполнения continuation может выделяться поток из тредпула, который не обязан совпадать с тем, в котором выполнялся пролог. Так это работает в ASP.NET, например. А может выполняться в том же потоке. Это зависит от такой штуки, как SynchronizationContext.
«50 оттенков коричневого» или «Как мы до этого докатились»