Еще на тему
Анилингус и флатуленция
![
стад
|Ш(Ш
v\
Ш1](http://img2.joyreactor.cc/pics/thumbnail/post-5687771.jpg "
стад
|Ш(Ш
v\
Ш1")
Популярные geek
 | it-юморРейтинг: 98,359.9 |
 | программированиеРейтинг: 16,319.2 |
 | geek pornРейтинг: 2,854.0 |
 | матанРейтинг: 2,576.4 |
 | Приколы для математиковРейтинг: 1,792.7 |
Сейчас на сайте
Всего пользователей на сайте: 891
к настоящему времени вроде поулеглось
а вообще под каждую задачу - свои инструмент. если надо только джейсончики гонять или тонкую прослойку между фронтом и бэком сделать, то js подходящий. если собрался работать с графикой, видео потоками и прочей паралельщиной, то нехуй брать неподходящий инструмент
Ну и работает она в продакшен режиме охуенно быстро, только с записью файлов проблемы в плане скорости
асинхронность в жс обеспечивается "нитями", которые работают в одном(!) потоке
при этом async hell в нодопроектах живёт и здравствует
крч, полная ебанина. хвала рандому, что эта херня сдохла на бэкэнде
даже для разработки RESTa (джейсончиков, ага) есть инструменты более быстрее как в плане разработки, так и в плане производительности
нахуя там нужен рантайм для динамического языка в принципе?
Или это был сарказм?
Как только надо то, что будет работать десятилетиями с постоянной поддержкой и разрастанием, цена поддержки этой радости на динамическом языке, когда кода становится сотни мегабайт, начинает расти экспоненциально.
Я вот работал когда-то с проектом на джаве, для минимальной сборки которого была нужна репа с сорцами на 20гб, и поддержка этого была во много-много раз пиздецовее, чем любой проект с минкросервисами на динамических языках. А есть ведь еще и проекты похожего размера на доисторических технологиях типа кобола с корбой - расскажи им, пожалуйста, про сложности поддержки проектов с динамическими языками
пейсбук на Hack - типизированный компилируемый "PHP".
вконтактик на KittenPHP - типизированный компилируемый "PHP" без ООП.
и тут на сцену закатывается DropBox, который положил кучу денег на разработку Pyston (так и называется) в попытке ускорить Python, а в итоге всё равно переписал всё на Go - оказалось, что это быстрее и дешевле
за джаву не скажу, но на шарпе с опытом год+ можно хуячить не сильно медленнее бидониста
но изучается шарп, конечно, сильно труднее и медленнее
1) Покупаешь лицензию битрикса с кучей свистоперделок. 3/4 которых тебе нафиг не нужны - но включены в стоимость.
2) Тратишь кучу времени, чтобы написать интеграцию под требования заказчика. Это только в рекламе "все работает из коробки". На деле хрен там - форматы данных в 1С у всех разные, а переделывать номенклатуру под твой битрикс никто не станет.
3) Ведешь бесконечную переписку с 1С-ником заказчика, который опять что-то поменял у себя, и выгрузка сломалась нафиг.
В общем, очень глубокая интеграция, можно на порнхабе публиковать.
Т.е. это не расширение для 1С, а самостоятельный продукт.
Есть, например, готовый модуль для интеграции. Создатели битрикса его написали - и добавили 1С к названию, чтоб покупателей привлекать. Мол, ставьте наш продукт, и каталог будет выгружаться сам автоматически.
На деле, сам понимаешь, "из коробки" ничего не работает без танцев с бубном. Только если 1С тоже "из коробки", а такое на реальных проектах бывает редко.