Sergey
если бы гнались за скоростью кода, а не развитием продукта?
Vladimir
Нет, если бы просто делали тоже самое, но на более быстром языке
Sergey
не
ну если бы на стабильной версии раста начали писать, тогда да
Sergey
но на ноде большой проект писать невозможно
Vladimir
> @sovamist
но на ноде большой проект писать невозможно
Бред
Vladimir
Нода мало чем отличается в этом смысле от всего остального
Sergey
Нода мало чем отличается в этом смысле от всего остального
ну да, кроме того что ее апи построено на ивентлупе
Vladimir
И что?
Sergey
да ничего :)
Nikolay
Чем это мешает писать большие проекты то?
Sergey
обработка сложных бизнес-кейсов превращается в ад)
Vladimir
Каких кейсов?
Nikolay
Заметь, большой проект != большой монолитный кусок говна :)
Sergey
только кастомного кода тонна лежит
Nikolay
обработка сложных бизнес-кейсов превращается в ад)
Это не проблема платформы, а проблема выбранной архитектуры.
Sergey
а так ничего
Vladimir
Между прочим в тот же питончик специально впилили эвент луп, видимо дурачье
Sergey
Между прочим в тот же питончик специально впилили эвент луп, видимо дурачье
питончик то поадекватнее реализован наверное)
Vladimir
Эвент луп есть эвент луп
Sergey
Это не проблема платформы, а проблема выбранной архитектуры.
покажите мне архитектуру удачно подходящую для написания проекта размеров gitlab на ноде?
Nikolay
Микросервисы :)
Дима
>питон
>адекватно
Дима
Давайте не будем делить на ноль
Vladimir
В скале тоже на асинхронщине сидят
Vladimir
В джаве многие на netty сидят
Vladimir
А там даже функций нет
Sergey
эм
Sergey
возвращаемся
Sergey
к тому что нужны либы
Sergey
и их знание
Nikolay
Конечно, нужны. Не велосипедить же их самому.
Ale
для бизнес-кейсов? Либы?
Sergey
а господин выше предлагал велосипедить))
Дима
Да ты же просто javascript, имитация скалы. Разве может nodejs написать сервис, сделать шедевр?
Vladimir
Либы нужны для работы с сервисами, для работы сетью, и т д
Ale
короче для инфраструктуры
Ale
и они подменяемы
Ale
DIP все дела
Sergey
для бизнес-кейсов? Либы?
если писать на vanilla js все бизнес кейсы, то эти строчки можно выкинуть
всё нужно абстрагировать) это вам не раст
Дима
Короче для всего
Ale
если писать на vanilla js все бизнес кейсы, то эти строчки можно выкинуть
всё нужно абстрагировать) это вам не раст
ну правильно, все надо абстрагировать от либ и конкретных реализаций
Ale
и потом можно подменять
Nikolay
Чатику не хватает десяти мемберов до круглого числа :)
Уже 13. Люди бегут, давайте завязывать :D
Ale
конечно дробить тоже надо правильно
Vladimir
Бизне логику нужно абстрагировать от инфраструктуры - это да
Sergey
ну правильно, все надо абстрагировать от либ и конкретных реализаций
итак
какие варианты построения абстракций в js? )))
Дима
Не
Ale
ага, ну поехали
Nikolay
Вот не могу взять в толк, почему ООП всегда противопоставляют ФП :)
Sergey
когда я был маленьким, мне били по рукам, когда я активно смешивал разные стили и подходы
Ale
те, кто критикует ооп, обычно подразумевает процедурщину с использованием классов, как неймспейсов
Ale
а не ооп
Nikolay
Есть императивный подход, а есть декларативный. И никто не мешает их смешивать в разных пропорциях.
Sergey
те, кто критикует ооп, обычно подразумевает процедурщину с использованием классов, как неймспейсов
напомнить что с наследованием в js?
а с ООП впринципе
Anonymous
покажите мне архитектуру удачно подходящую для написания проекта размеров gitlab на ноде?
Бэкенд — нода + БД (пожалуй, всё равно, какая) + редис с подписочками на сокет-соединение с клиентом и в обратную сторону-тоже. Клиент на реакте (впрочем, тоже всё равное, на чём) + Redux с подпиской на вебсокеты. Суть в том, что у нас получится общий медиатор для клиента и для сервера. Гитлаб получится прям как живой. Всё будет жевелиться и свистопердеть, в реальном времени обновляться у всех и сразу.
Ale
только в инфраструктуре, когда это необходимость
Ale
очень даже чистый
Ale
я не знаю
Vladimir
Наследование не нужно для паттернов