Количество успешного ПО написанного на этих языках с вами не согласится. Сейчас уже буквально всё ПО на жс пишется. А го это по-видимому что-то из разряда раби, там такой же хайп был.
Нода это просто жс. Если есть много веб программистов, то почему бы им не писать любые приложения? Имхо конечно npm помойка, а качество кода зачастую оставляет желать лучшего.
Уже давно хайп прошёл. От ноды сам создатель открещивается. Потом он топил за Go, а теперь уже пишет на Rust убийцу ноды. Но там по сути, та же нода, но с дополнительными костылями, которые исправляют фатальный недостаток. В общем, всё как обычно в мире js, опять тоже самое переизобретают раз в год.
И какого же ООП тебе в JS не хватает? Учитывая тот сахар, который добавили в es6, при этом сохранив старый механизм с прототипированием, на котором можно наворачивать даже множественное наследование при помощи тех же миксинов.
Кстати да. На ноде можно запилить себе нормальное ооп, в отличии от явы. Есть getter'ы, setter'ы и можно не дрочить везде вот это вот myclass.getId и там, где в яве нужны костыли типа lombook в js всё делается в 10 строчек средствами языка.
Да, давно завезли и уже даже, вроде, стабильные и не за флагами.
Так же допилили их апишку для нативных аддонов для работы в этих воркерах, раньше с этим были проблемы.
Можно пользоваться, если бы взаимодействие между воркерами не было таким стремным — все объекты так или иначе должны быть сериализированы в одном потоке и десериализированы в другом. Я с этим особо не работал, но звучит не очень быстро.
Можно пользоваться, если бы взаимодействие между воркерами не было таким стремным — все объекты так или иначе должны быть сериализированы в одном потоке и десериализированы в другом.
Так это специально сделали, чтобы трудно было сделать дедлок.
Я с этим особо не работал, но звучит не очень быстро.
Там по сути должен быть такой же async как со всем остальным. Тоже думал их потыкать, но у меня нет ничего такого, для чего они могли бы понадобиться.
Нет, я не про одновременное использование несколькими воркерами данных.
В любом случае, базовым механизмом взаимодействия между воркерами является отправка/получение сообщений. Поэтому дедлоки все рано не могут случиться. Но при отправке сообщением сложной структуры она сериализуется в некий простой буфер и уже этот буфер атомарно передается от одного воркера в другой. Но хотелось бы избежать именно этой сериализации. Т.е. чтобы сложная структура при передаче пропала в одном воркере и появилась в другом (просто передачей чего-то вроде указателя, воркеры все равно мапятся на треды). А в первом все ссылки на нее стали невалидными.
Но, видимо, v8 так устроен, что это невозможно. Одна из причин его высокой скорости — он однопоточен, а значит не надо тратить ресурсы на синхронизацию.
Кстати, по поводу дедлоков. Прередача сообщений — это основной, рекомендуемы способ взаимодействия между воркерами. Но есть еще и через расшаренный буферы (SharedArrayBuffer). Это кусок сырой памяти, к которой реально есть доступ у нескольких воркеров одновременно. И чтобы как-то синхронизировать к ним доступ есть элементы синхронизации, которые реально могут создать дедлоки. Так что теперь и разработчики на js могут страдать от взаимных блокировок. Раньше они были обделены этой возможностью
Там такая же ситуация была, спаситель всех оказался хуже и медленней всех конкурентов и куча сахара не спасла. Так и тут, рантайм с гц и прочее не позволяют работать с ним сколько-нибудь серьёзно. Как много успешных проектов гугла вы знаете? Вроде у него всё, к чему бы он ни прикасался, превращается в какахи. Попутно он конечно задавливает конкурентов деньгами и нечестной конкуренцией, так что вполне возможно это часть далеко идущих планов для очередного слитого проекта, деньги инвесторов то отрабатывать надо.
Это не нормальный, а узкоспециализированный, мало кому нужно писать ос или дрова. Нормальный - это клиент к vk, soundcloud, инстаграмму, например. Такой софт, наиболее популярный, судя по гугл плею / апп стору, почти всегда пишется на electron совсем не зря, и далеко не дураками...
иди букварь читай, школьник. причем тут ООП и потребление памяти? таблицы виртуальных методов не занимают 4 гб. 4гб жрут программы, написанные ламерами вроде тебя.
Почти ничем кроме версии языка. Но недавно наткнулся на проект хипстеров, пользующих Array#flat в webpack-конфиге и он, естественно, не работал на LTS. babel? слишком простое решение.