Какой язык стоит выбрать для написания микросервисов - Компьютерные священные войны

Здравствуйте, Sharov, Вы писали:

S>>Ой, все такие всегда правильные... "Ой, оказалось что бакенд посложнеее... Ну не меняяять же языык.. Ноду жэ ужэ выбрали!" и в итоге тормоза, жор ресурсов, контейнеры для масштабирования и вот это вот всё.
S>Контейнеры не про ресурсы, а для изоляции, воспроизводимости и простоты деплоя. А там уже и масштабирование.
Контейнеры это в первую очередь когда две команды не осилили взаимодействие между собой и поприкрутили к своим проектам разные версии библиотеки. Не обновлять же! есть же изоляция!

Я не устану повторять. Все эти докеры оправданы ровно в двух случаях.
1. При разработке. Удобно когда пилишь несколько проектов и окружение каждого в своих контейнерах и не хламят хост.
2. При необходимости масштабирования на лету.

Здравствуйте, Privalov, Вы писали:

НС>>Ты не поверишь. Он даже как то сюда выкладывал свой результат. И при этом не стесняется писать о своем высоком профессионализме и криворукости остальных.
P>Ну почему? Я не видел, что он выкладывал. Но учитывая наши с ним дискуссии в прошлом...
Ну на, посмотри.

Здравствуйте, Privalov, Вы писали:

P>Ну почему? Я не видел, что он выкладывал. Но учитывая наши с ним дискуссии в прошлом...

Держу под рукой всегда. Вот.

Здравствуйте, Sheridan, Вы писали:

P>>Я веб не писал. Мы вебу данные поставляли. Наш сервер на java держал 300 чего-то там в секунду при требовании 150.
S>На плючах бы держал на порядок больше минимум.

Ты эту мантру повторяешь около полутора десятков лет. Но ни разу не объяснил: каким образом? Я ж писал: оно упирается во внешние источники данных. Не в процессор, не впамять. Во внешние источники. Скорость сети выше, чем есть, не будет. Соответственно, Иногда будут тормоза с БД. Но вовсе не потому, что софтина не успевает их принять, а совсем наоборот.

P>>А как ты освобождаешь память, выделенную по голому указателю, если прилетает исключение?

S>Очень просто: дебажу и выпускаю в прод без расстрела памяти.

А с освободжением при исключении-то что? В плюсах сборщика мусорв нету. Как только ты за пределы вышел, указатель исчезнет, а память, выделенная по адресу, останется. А умными указателями ты принципиально непользуешься, насколько я помню.

S>А ты один экземпляр в один поток запускаешь?

Чего?

P>>Дак а кудаж без бабла-то? Если не напишешь, да чтобы ТЗ соответствовало, да в сроки заданные, да еще много чего, то бабла не будет.
S>Это головная боль продажников и прочих манагеров а не программистов.

Точно! Берешь, Рисуешь окошки на VB6, расставляешь on error resume next и несешь показывать заказчику. С этим любой продажник справится. Впрочем, в JS даже это не нужно. Я пробовал простенькие наброски делать для себя — выдает ересь, но не падает.

S>Не могу понять как при знании времени жизни объекта можно забыть его удалить или не создать...

Ничего, дойдешь еще. У меня такой случай был всего один раз. И какое отношение время жизни объекта имеет к его созданию/удалению?

Здравствуйте, Farsight, Вы писали:

F>Держу под рукой всегда. Вот.

8 лет прошло с тех пор, и ничего не изменилось.

Здравствуйте, Sheridan, Вы писали:

I>>Потому что у тебя основной кейс с налёту фиксануть и укатить в закат.
S>Ну то есть такое возможно и без траты года на изучение? Или нет?

Это не разработка. Когда говорят разработка, то это перемалывание длительных задач, деливери решений проблем именно бизнеса.

А вот фиксануть с налёту это не разработка, а малая часть её, L2 или L3 суппорт или что навроде.

I>>Не следил. Факт в том, что тебя никто не спрашивает. Считай, вся индустрия обошлась без советов Шеридана

S>А вперёд мало кто смотрит. Решают сиюминутные задачи. Надо сервис? А вон же фронтендер есть пусть на ноде пилит. Ой, сервис ВНЕЗАПНО вырос и тормозит...

Жалобы на тормоза были и будут во все времена, хоть на С++, хоть на Ноде, хоть на чем угодно.

I>>Косяки, просадки, ресурсы стоят много дешевле рабочего времени команды разработки. Дешевле купить, чем нанимать тех, кто сэкономит на клауде вдвое. Она ЗП такого специалиста потянет на два клауда.
S>А продукт пусть будет говном. Ой, я ж так с самого начала и говорил.

Никакой связи. Хороший продукт это минимум три вещи, в порядке убывания важности — требования, контроль качества, квалификация команды.

I>>С алгоритмическими задачами проблем нет. Проблемы есть с технологическими, т.е. такими, где нужно знание нюансов технологий. Результаты можно наблюдать по тому, как бакенды проявляют себя на фронтенде и наоборот.
S>Будет проблема — будет и решение.

Решение уже найдено — бакендов на фронт не пускать. Дешевле дать ноду фронтендам, и ограничить их архитектурно, например, module federation + edge service.

I>>Такой опыт не сделает тебя более квалифицированым дотнетчиком, специалистом по финтеху, геймдеву итд. И уж точно не появится понимание, почему нода применяется на своём классе задач.
S>Да кто ж про "свой класс" спорит? Хотя я с лёту не могу даже придумать такого чего нельзя на ширпотребском питоне реализовать...
S>Проблема в том, что эту ненужную шестеренку часто пихают туда где она нафиг не нужна.

Все технологии проходят этап, когда их пихали куда угодно. Даже веб приложения долго пытались пилить на С++. Слив был настолько громкий, что ржут до сих пор.
И с дотнетом был тоже самое, и с джавой, и с питоном.

Сейчас период в индустрии такой, цифровизация бизнеса. Фактически, бизнесы разных калибров заказывают для себя конское количество софта.
бОльшей частью этот софт фактически несложный CRUD с небольшими вариациями. И вот для него крайне критичен хороший фронтенд. А раз так, то нода справится очень хорошо.

Здравствуйте, Sheridan, Вы писали:

I>>Был, это ты как типичный ковбой-девелопер с гиком и свистом налетел, фиксанул один баг, и укатил в закат.
S>И так два года.

Хоть сто. Ты вещаешь как часовой мастер из сервиса — с его точки зрения 100% часов того или иного бренда или бракованые, или сломаные, или некачественные.

Хороших примеров ты не видел, но утверждаешь, что их нету. Это специфика твоей работы — ковбойские интервенции. Там где все хорошо, тебя туда не зовут.

I>>А нас тут интереует более-менее длительная разработка.
S>Ну, безусловно, у тебя длинее. ))

Мы здесь про написание бакенда и выбор технологии. Правильно понимаю, ты перед своими ковбойскими интервенциями выбираешь стек, архитектуру?

S>>>Конечно же есть примеры использования ноды. Кто бы сомневался. Только вот правильно ли её там использовать?
I>>У тебя релевантных аргументов против ноды как то нашлось. Вот, смотри сюда http://rsdn.org/forum/flame.comp/8291664.1
S>Нашлось или не нашлось?

Не нашлось, что очевидно. Что там у тебя? "Уууу, тормоза, уууу, говнокод". Что конкретное есть? А то я тормоза и говнокод чаще всего видел/вижу в джаве и С++.

S>Вот я и говорю — когда начинается бабло то сразу ищут где подешевле. И команду нанять подешевле и обслужить подешевле. А в итоге тормоза, и ад в коде. Через год проект невозможно поддерживать.

Качество кода имеет в среднем довольно слабое влияние на прибыль бизнеса. Такая вот жизнь. Слишком часто бывает так, что дешевле раз на говнокодить, а потом год суппортить, чем наоборот. Нынче слишком важен time to market.

Здравствуйте, Sheridan, Вы писали:

S>Я не устану повторять. Все эти докеры оправданы ровно в двух случаях.
S>1. При разработке. Удобно когда пилишь несколько проектов и окружение каждого в своих контейнерах и не хламят хост.

А в продакшне значит хост можно хламить, да?

Здравствуйте, Farsight, Вы писали:

P>>Ну почему? Я не видел, что он выкладывал. Но учитывая наши с ним дискуссии в прошлом...

F>Держу под рукой всегда. Вот.

Шериданство во всей красе. Html не в базе генерирует, и то хорошо.

Здравствуйте, Ikemefula, Вы писали:

I>Шериданство во всей красе. Html не в базе генерирует, и то хорошо.
Это же не весь код. Может, это только верхушка айсберга.

Здравствуйте, Sheridan, Вы писали:

S>Контейнеры это в первую очередь когда две команды не осилили взаимодействие между собой и поприкрутили к своим проектам разные версии библиотеки. Не обновлять же! есть же изоляция!
Зачем им осиливать взаимодействие? Есть же изоляция. Может команды от разных поставщиков вообще.

S>Я не устану повторять. Все эти докеры оправданы ровно в двух случаях.
S>1. При разработке. Удобно когда пилишь несколько проектов и окружение каждого в своих контейнерах и не хламят хост.
S>2. При необходимости масштабирования на лету.
Зачем повторять? Это же никого не интересует.

Здравствуйте, Farsight, Вы писали:

I>>Шериданство во всей красе. Html не в базе генерирует, и то хорошо.
F>Это же не весь код. Может, это только верхушка айсберга.

Ужос. Теперь для несложных приседаний с фронтендом вида подвинь кнопку надо искать матерого С++ разработчика

Здравствуйте, Privalov, Вы писали:

P>>>Я веб не писал. Мы вебу данные поставляли. Наш сервер на java держал 300 чего-то там в секунду при требовании 150.
S>>На плючах бы держал на порядок больше минимум.
P>Ты эту мантру повторяешь около полутора десятков лет. Но ни разу не объяснил: каким образом? Я ж писал: оно упирается во внешние источники данных. Не в процессор, не впамять. Во внешние источники. Скорость сети выше, чем есть, не будет. Соответственно, Иногда будут тормоза с БД. Но вовсе не потому, что софтина не успевает их принять, а совсем наоборот.
Про потоки слышал? Пока один одни данные ждёт — ко второму ещо клиент приходит.

P>>>А как ты освобождаешь память, выделенную по голому указателю, если прилетает исключение?

S>>Очень просто: дебажу и выпускаю в прод без расстрела памяти.
P>А с освободжением при исключении-то что? В плюсах сборщика мусорв нету. Как только ты за пределы вышел, указатель исчезнет, а память, выделенная по адресу, останется. А умными указателями ты принципиально непользуешься, насколько я помню.
Исключения — нештатное, форсмажор. Чтото пошло совершенно не так.

S>>А ты один экземпляр в один поток запускаешь?
P>Чего?
А чего ты тогда?

P>>>Дак а кудаж без бабла-то? Если не напишешь, да чтобы ТЗ соответствовало, да в сроки заданные, да еще много чего, то бабла не будет.
S>>Это головная боль продажников и прочих манагеров а не программистов.
P>Точно! Берешь, Рисуешь окошки на VB6, расставляешь on error resume next и несешь показывать заказчику. С этим любой продажник справится. Впрочем, в JS даже это не нужно. Я пробовал простенькие наброски делать для себя — выдает ересь, но не падает.
Перегибаешь.

S>>Не могу понять как при знании времени жизни объекта можно забыть его удалить или не создать...
P>Ничего, дойдешь еще. У меня такой случай был всего один раз.
И у меня был. Неделю искал. ЧСХ, с умным указателем связано было. Что именно — не помню — лет пять прошло.

P>И какое отношение время жизни объекта имеет к его созданию/удалению?
Создал — объект пожил — удалил.

Здравствуйте, Ikemefula, Вы писали:

I>>>Потому что у тебя основной кейс с налёту фиксануть и укатить в закат.
S>>Ну то есть такое возможно и без траты года на изучение? Или нет?
I>Это не разработка. Когда говорят разработка, то это перемалывание длительных задач, деливери решений проблем именно бизнеса.
Без декомпозирования, одно ТЗ в одно лицо одним таском?

I>>>Не следил. Факт в том, что тебя никто не спрашивает. Считай, вся индустрия обошлась без советов Шеридана

S>>А вперёд мало кто смотрит. Решают сиюминутные задачи. Надо сервис? А вон же фронтендер есть пусть на ноде пилит. Ой, сервис ВНЕЗАПНО вырос и тормозит...
I>Жалобы на тормоза были и будут во все времена, хоть на С++, хоть на Ноде, хоть на чем угодно.
Соглашусь но скажу только чем низкоуровнее язык тем меньше будет жалоб.

I>>>Косяки, просадки, ресурсы стоят много дешевле рабочего времени команды разработки. Дешевле купить, чем нанимать тех, кто сэкономит на клауде вдвое. Она ЗП такого специалиста потянет на два клауда.
S>>А продукт пусть будет говном. Ой, я ж так с самого начала и говорил.
I>Никакой связи. Хороший продукт это минимум три вещи, в порядке убывания важности — требования, контроль качества, квалификация команды.
Ну тогда и ноды не будет.

I>>>С алгоритмическими задачами проблем нет. Проблемы есть с технологическими, т.е. такими, где нужно знание нюансов технологий. Результаты можно наблюдать по тому, как бакенды проявляют себя на фронтенде и наоборот.
S>>Будет проблема — будет и решение.
I>Решение уже найдено — бакендов на фронт не пускать. Дешевле дать ноду фронтендам, и ограничить их архитектурно, например, module federation + edge service.
Опять бабло.

S>>Проблема в том, что эту ненужную шестеренку часто пихают туда где она нафиг не нужна.
I>Все технологии проходят этап, когда их пихали куда угодно. Даже веб приложения долго пытались пилить на С++. Слив был настолько громкий, что ржут до сих пор.
I>И с дотнетом был тоже самое, и с джавой, и с питоном.
И все ржут до сих пор? На чом же тогда писать если куда ни плюнь — все ржут до сих пор?

I>Сейчас период в индустрии такой, цифровизация бизнеса. Фактически, бизнесы разных калибров заказывают для себя конское количество софта.
I>бОльшей частью этот софт фактически несложный CRUD с небольшими вариациями. И вот для него крайне критичен хороший фронтенд. А раз так, то нода справится очень хорошо.
А питон ещо лучше. А плюсы ещо лучше.

Здравствуйте, Ikemefula, Вы писали:

I>>>Был, это ты как типичный ковбой-девелопер с гиком и свистом налетел, фиксанул один баг, и укатил в закат.
S>>И так два года.
I>Хоть сто. Ты вещаешь как часовой мастер из сервиса — с его точки зрения 100% часов того или иного бренда или бракованые, или сломаные, или некачественные.
I>Хороших примеров ты не видел, но утверждаешь, что их нету. Это специфика твоей работы — ковбойские интервенции. Там где все хорошо, тебя туда не зовут.
Но опыта у меня нет, ага.

I>>>А нас тут интереует более-менее длительная разработка.
S>>Ну, безусловно, у тебя длинее. ))
I>Мы здесь про написание бакенда и выбор технологии. Правильно понимаю, ты перед своими ковбойскими интервенциями выбираешь стек, архитектуру?
Не совсем понимаю посыл...
Да, я буду выбирать язык и окружение перед стартов нового проекта а не брать чтото модное, "на этом все пишут" или по советам с форума.

S>>>>Конечно же есть примеры использования ноды. Кто бы сомневался. Только вот правильно ли её там использовать?
I>>>У тебя релевантных аргументов против ноды как то нашлось. Вот, смотри сюда http://rsdn.org/forum/flame.comp/8291664.1
S>>Нашлось или не нашлось?
I>Не нашлось, что очевидно. Что там у тебя? "Уууу, тормоза, уууу, говнокод". Что конкретное есть? А то я тормоза и говнокод чаще всего видел/вижу в джаве и С++.
А я в жаве и ноде. Реже в питоне.

S>>Вот я и говорю — когда начинается бабло то сразу ищут где подешевле. И команду нанять подешевле и обслужить подешевле. А в итоге тормоза, и ад в коде. Через год проект невозможно поддерживать.
I>Качество кода имеет в среднем довольно слабое влияние на прибыль бизнеса. Такая вот жизнь. Слишком часто бывает так, что дешевле раз на говнокодить, а потом год суппортить, чем наоборот. Нынче слишком важен time to market.
Поэтому в основном говно на руках и имеем.

Здравствуйте, Ikemefula, Вы писали:

S>>Я не устану повторять. Все эти докеры оправданы ровно в двух случаях.
S>>1. При разработке. Удобно когда пилишь несколько проектов и окружение каждого в своих контейнерах и не хламят хост.
I>А в продакшне значит хост можно хламить, да?

А в продакшене `apt install lib1 lib2 lib3 myproject`, следом настройка и запуск.

Здравствуйте, Farsight, Вы писали:

S>>Контейнеры это в первую очередь когда две команды не осилили взаимодействие между собой и поприкрутили к своим проектам разные версии библиотеки. Не обновлять же! есть же изоляция!
F>Зачем им осиливать взаимодействие? Есть же изоляция. Может команды от разных поставщиков вообще.
Про ситуацию где разрабы вынуждены брать в руки говно никто не говорит. Посочувствую, но и только ибо выбора у них нет.

S>>Я не устану повторять. Все эти докеры оправданы ровно в двух случаях.
S>>1. При разработке. Удобно когда пилишь несколько проектов и окружение каждого в своих контейнерах и не хламят хост.
S>>2. При необходимости масштабирования на лету.
F>Зачем повторять? Это же никого не интересует.

Да потому что вы не слышите.

	От:	Ночной Смотрящий
	Дата:	07.06.22 13:15
	Оценка:

	От:	Sheridan
	Дата:	07.06.22 13:25
	Оценка:

	От:	Sheridan
	Дата:	07.06.22 13:26
	Оценка:

	От:	Sheridan
	Дата:	07.06.22 13:29
	Оценка:

	От:	Sheridan
	Дата:	07.06.22 13:31
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	07.06.22 14:03
Оценка: