Re[7]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 09:07
Оценка: :)))
Здравствуйте, Ikemefula, Вы писали:

S>>>>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.

CC>>>Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут.
S>>Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов.

I>Снова у Шеридана программисты некомпетентные. Может это ты разработку не понимаешь?

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

I>Надо вспомнить, что стоимость труда разработчиков выросла до небес, а стоимость стораджа упала ниже плинтуса, при этом сложность софта растет непрерывно.

И поэтому надо писать говно на говне и делать модным говно. Я тебя услышал.

>> Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.

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


I>Например — обновил ты либу, упали тесты А. Фиксанул. Обновил другую — упали тесты Б. Фиксанул — снова упали А. Фиксанул — упали тесты Б. Обычно здесь надо засаживаться за глубокую отладку, что бы выяснить, почему либы несовместимы, писать тикеты, искать версии, которые хоть как то совместимы, или гуглить до посинения, пока кто нибудь не подскажет тебе комбинацию.

Стандартный рабочий процесс. Если не оттягивать и не ждать петуха.

I>Такое, во первых, требует высокой квалификации, во вторых, огромных трудозатрат.

Про трудозатраты я уже сказал. Про квалификацию: что, серьёзно настолько всё плохо что программисты разучились читать ченгджлоги и пользоваться поиском? Серьёзно?

I>И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.

Это когда петух приходит. А когда вовремя всё — то и затраты около нуля.

I>За деньги, которые этот разработчик потратит на миграцию, можно проплатить хостинг-деплоймент-клауд на год. Отсюда ясно, что постоянно заниматься миграциями никто в своём уме не будет.

Ты придумал высокие затраты и теперь пишешь про то что можно сделать вместо них. И выглядит всё логично и правильно.
Только вот высокие затраты ты придумал. В этом проблема.

I>Поэтому обычно используются другие подходы, например — zero dependency, или all-in-one, или доккер, или lambda, или итд.

Это от некомпетентности/лени. Потому что лень обновить либу, лень посмотреть/почитать чего нового появилось в мире.

Приведу пример:
Берём линупс. Буквально любой. А на больших промежутках времени (десятилетия) то и любую вообще ОС.
Устанавливаем ОС и не обновляем несколько лет. А потом обновляем. ВНЕЗАПНО возникает такая гора проблем, что для их решения реально нужны действительно дорогие специалисты и время.
А вот если обновлять ОС хотя бы раз в месяц — то и проблем не будет. Либо для их решения достаточно обычного приходящего админа.
Matrix has you...
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.