Re[10]: Опять дваццатьпять
От: smeeld  
Дата: 17.02.22 11:53
Оценка: +2
Здравствуйте, Sheridan, Вы писали:


S>Как по мне — контейнеры нужны в паре случаев всего:

S>1. Для разработки, чтобы не захламлять рабочую машину всевозможными кроликами, постгрями, мускулями итд
S>2. Когда нужно уметь разворачивать мощности при возрастании нагрузки и сворачивать обратно потом (aws тотже)

Есть ещё третий вариант, и именно он обеспечил массовость популярность контейнеров и докера в частности. Это когда сидит макака, ваяет у себя на локалхосте на последней убунту приложение, тащит для этого кучу всякого разношерстного и разноверсионного хлама из самых разных реп, самыми разными пакетными менеджерами, отличными от штатного (pip-ы, npm-ы). Поучается нагроможение и мессиво. Работать будет только у него на локалхосте. А нужно чтоб работало где-то на любом сервере, в закрытом или публичном облаке. Что делать? Завернуть всю эту кучу вместе с загаженным обазом ОС в контейнер, и этот контейнер можно уже запускать где угодно. А то, что вместе с жалкими 10KB творения макаки на каждый сервер тащится ещё 500MB образа ОС, то это макаку не волнует, а провайдеры только за-повышенное потребление ресурсов клиентами для них прибыль.
Контейнеры, их необходимость и популярность-это деградация именно культуры разработки ПО.
Re[11]: Опять дваццатьпять
От: Sheridan Россия  
Дата: 17.02.22 12:18
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>>2. Когда нужно уметь разворачивать мощности при возрастании нагрузки и сворачивать обратно потом (aws тотже)

НС>А где ты еще увидел Go, кроме "aws тотже"?
Всмысле где применяется гошечка? Да куча экспортеров статистики под prometheus/influxdb на ём, да и вообще почти весь этот стек мониторинга на ём.
Matrix has you...
Re[11]: Опять дваццатьпять
От: Sheridan Россия  
Дата: 17.02.22 12:20
Оценка:
Здравствуйте, smeeld, Вы писали:

S>Есть ещё третий вариант, и именно он обеспечил массовость популярность контейнеров и докера в частности. Это когда сидит макака, ваяет у себя на локалхосте на последней убунту приложение, тащит для этого кучу всякого разношерстного и разноверсионного хлама из самых разных реп, самыми разными пакетными менеджерами, отличными от штатного (pip-ы, npm-ы). Поучается нагроможение и мессиво. Работать будет только у него на локалхосте. А нужно чтоб работало где-то на любом сервере, в закрытом или публичном облаке. Что делать? Завернуть всю эту кучу вместе с загаженным обазом ОС в контейнер, и этот контейнер можно уже запускать где угодно. А то, что вместе с жалкими 10KB творения макаки на каждый сервер тащится ещё 500MB образа ОС, то это макаку не волнует, а провайдеры только за-повышенное потребление ресурсов клиентами для них прибыль.

Да, это и есть хк-хк-продакшн. "Нам пофиг как это работает, пусть хоть как нибудь взлетит а клиент памяти/дисков/серверов докупит"

S>Контейнеры, их необходимость и популярность-это деградация именно культуры разработки ПО.

Именно про это я и пишу. Против этого я тут и выступаю.
Matrix has you...
Re[10]: Опять дваццатьпять
От: Sheridan Россия  
Дата: 17.02.22 12:23
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

CC>>А не дороговато ли выйдет?

НС>Нет. Для того контейнеры и придумали, чтобы не было дороговато.
А ты считал стоимость сопровождения? Стоимость специалиста по кубам, нопример?
Matrix has you...
Re[7]: Язык Go - слабые стороны
От: Ночной Смотрящий Россия  
Дата: 17.02.22 12:35
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


Ему это все уже объясняли. На что был получен ответ, что бизнес должен идти в жопу со своими потребностями пока программисты обновляют все либы в проекте. Так что не про то ты рассказываешь. Надо рассказать что в жопу пойдет Шеридан (или вообще вся индустрия разработки, если его мечталки о поведении разработчиков сбудутся), и что большинство из присутствующих занимаются разработкой не ради мудя почесать, а чтобы денег заработать.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Язык Go - слабые стороны
От: Ночной Смотрящий Россия  
Дата: 17.02.22 12:35
Оценка: -2
Здравствуйте, Sheridan, Вы писали:

S>ЧСХ, я сразу написал что в гошечке нет ООП и потому надо закапывать. Но пытаются из-за этого закопать меня


Закапывать надо ООП, а не гошечку.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[12]: Опять дваццатьпять
От: Ночной Смотрящий Россия  
Дата: 17.02.22 12:37
Оценка:
Здравствуйте, Sheridan, Вы писали:

НС>>А где ты еще увидел Go, кроме "aws тотже"?

S>Всмысле где применяется гошечка?

Да

S> Да куча экспортеров статистики под prometheus/influxdb на ём, да и вообще почти весь этот стек мониторинга на ём.


Т.е. "aws тотже".
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: Опять дваццатьпять
От: Ночной Смотрящий Россия  
Дата: 17.02.22 12:37
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

CC>>>А не дороговато ли выйдет?

НС>>Нет. Для того контейнеры и придумали, чтобы не было дороговато.
S>А ты считал стоимость сопровождения?

Кого, контейнеров? И что подразумевается под их сопровождением?

S> Стоимость специалиста по кубам, нопример?


При чем тут куб? Куб решает намного больше задач, чем контейнеры.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: Язык Go - слабые стороны
От: Ночной Смотрящий Россия  
Дата: 17.02.22 13:12
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Никогда у меня не было проблем с исключениями.


Это потому что у тебя не С++, где исключения настолько опасная штука, что в некоторых проектах их тупо запрещают. Ну а потом эти проблемы С++ плюсовики переносят на исключения, не язык же виноват, право.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: Язык Go - слабые стороны
От: Ночной Смотрящий Россия  
Дата: 17.02.22 13:12
Оценка: -2
Здравствуйте, Sheridan, Вы писали:

S>>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?

S>Нет ООП. Выбрасывайте.

ООП? Согласен.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Язык Go - слабые стороны
От: Mr.Delphist  
Дата: 17.02.22 13:36
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Но динамические библиотеки, написанные на других языках, с сишными соглашениями о вызовах, из Go без проблем можно использовать.


Эка невидаль — даже FoxPro это умел. Вопрос: где сейчас Фокс, и где сишечка?
Re[14]: Язык Go - слабые стороны
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.02.22 14:15
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

I>>Вот именно по этому all-in-one предпочтительнее. Кроме того, ты забыл, что вместе с твои софтом будей и другой, у которого могут быть совсем другие предпочтения по версиям.

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

В любом случае конфигурация финишного деплоймента на момент разработки неизвестна. И в конце спокйно может оказаться мешанина вида "софтина-плагины-еще-софтина-еще-плагины" имее взаимоисключающие требования.

I>>Неинтересно. Чет заказчик на такое не жаждет соглашаться. Что предложишь, оскорбить его, обмануть, кинуть?

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

Заказчик платит не за софт в дистрибутиве, а за решение конкретной его проблемы. all-in-one это хороший вариант исключить проблемы с шаред/транзитивными зависимостями.

S>У меня значит получалось выяснить что и почему не работает (и это включало в себя например сборку подправленного постгреса с дополнительным дебаг-логом). А у настоящих тру-программистов-профессионалов лапки.


Снова тебе программисты мешают.

I>>Похоже, ты уже начал кое что понимать.

S>Я изначально к этому вёл, но у тебя закостенение "шеридан-долбоклюй-непрофессионал" и это мешает тебе воспринимать то что я пишу.

Здесь ровно наоборот- ты по пять раз на сообщении утверждашь, что с прграммистами чтото не то.

I>> Смешно. У тебя похоже экономическая составляющая вообще в рассуждениях не присутствует. С чего ты взял, что влегкую фиксанешь произвольную либу?

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

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

S>Ну то есть никто на протяжениии нескольких лет не чинит баги означает что либа полностью и адекватно поддерживается автором?

S>Г — лоГика.

Да, бывают такие баги, которые трудно воспроизводятся, или их фикс ломает обратную совместимость. БОлее того — приоритеты в разработке никто не отменял. А в опен-сорсе тебе никто ничего не должен.

I>>У тебя багтрекер это синоним "магия". Ну есть баг в том трекере, только например описан он совсем не так, как тебя проявляется. Что дальше?

S>Опиши так как у тебя проявляется. Надеюсь ты сам понимаешь, что это поможет автору баг исправить.

Это только с детскими багами так, когда сразу ясно где он, и как его воспроизвести. А слишком часто баг в одном месте, а причина — в противоположном, и появляется не сразу, а время от времени, через пару дней и последствия
Соответственно, такие вещи тестами просто так не возьмешь.

S>А как ещо назвать разрабов, которые говорят "если на баг никто не отвечает, то ты неправ что либа не поддерживается автором а наоборот."?


А это норма в опен-сорсе — игнорить баги. Заходишь зарепортать в популярный репозиторий, а там булькают вещи еще с нулевых.

I>>Выглядит как юношеский максимализм. Я и моя команда и без тебя все это делаем.

S>Если вы и так это всё делаете, то какого Иакова вы мне тут мозги полоскаете? Так и напиши "да, мы этим занимаемся, но по мере возможностей". И вопросов не будет. Срач ради срача?

Так я не сужу по себе.


I>>Зато факт в том, что большинство долгоиграющих проектов такой роскоши позволить себе не могут. Причины самые разные. И только ты один обвиняешь разрабов в некометентности. Тут похоже весь мир живет не по твоим правилам

S>Причин две: лень и некомпетентность. Я бы добавил третью: недальновидность. Но программисту бизнес-бабки-платит-я-кодю этого не понять.

Снова программисты виноваты. У тебя похоже риск и инцидент это одно и то же.
Re[5]: Язык Go - слабые стороны
От: Cyberax Марс  
Дата: 17.02.22 14:21
Оценка:
Здравствуйте, Sheridan, Вы писали:

H>>Каких непостижимых фич? Итераторы блин непостижимые? Перегрузка оператора сравнения это непостижимо? Без перегрузки оператора сравнения зачастую нельзя использовать тип для индексирования map.

S>ЧСХ, я сразу написал что в гошечке нет ООП и потому надо закапывать. Но пытаются из-за этого закопать меня
???

В Go есть ООП, причём достаточно крутой за счёт структурной типизации.
Sapienti sat!
Re[6]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 17.02.22 14:36
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Закапывать надо ООП, а не гошечку.

Причины? Серьёзно.
Matrix has you...
Re[13]: Опять дваццатьпять
От: Sheridan Россия  
Дата: 17.02.22 14:37
Оценка: :)
Здравствуйте, Ночной Смотрящий, Вы писали:

S>> Да куча экспортеров статистики под prometheus/influxdb на ём, да и вообще почти весь этот стек мониторинга на ём.


НС>Т.е. "aws тотже".

Не распарсил что ты имеешь в виду.
Matrix has you...
Re[12]: Опять дваццатьпять
От: Sheridan Россия  
Дата: 17.02.22 14:38
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

CC>>>>А не дороговато ли выйдет?

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

Кто будет инфраструктуру настраивать?
Matrix has you...
Re[6]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 17.02.22 14:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В Go есть ООП, причём достаточно крутой за счёт структурной типизации.

Унаследуйся от класса и переопредели метод сравнения.
Matrix has you...
Re[8]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 17.02.22 14:40
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>Ему это все уже объясняли. На что был получен ответ, что бизнес должен идти в жопу со своими потребностями пока программисты обновляют все либы в проекте. Так что не про то ты рассказываешь.
Если бизнес скажет тебе вставить затычку в пятую точку — так и сделаешь?
Бизнес нанимает профессионала чтобы решать задачи бизнеса но потом не слушает профессионала и требует вырастить руки на жопе. Это так работает?
Matrix has you...
Re[15]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 17.02.22 14:54
Оценка: :)))
Здравствуйте, Ikemefula, Вы писали:

I>>>Вот именно по этому all-in-one предпочтительнее. Кроме того, ты забыл, что вместе с твои софтом будей и другой, у которого могут быть совсем другие предпочтения по версиям.

S>>Решение подсказать? Нужно свой софт писать так, чтобы использовал те версии либ, которые есть в дистрибутиве. А если нет такой либы вообще, то в свой репозиторий складывать в виде зависимости к пакету с твоим софтом. А заказчику давать линк на свою репу, которую надо подключить ему к дистрибутиву чтобы потом стандартными средствами установить ваш софт.
I>В любом случае конфигурация финишного деплоймента на момент разработки неизвестна. И в конце спокйно может оказаться мешанина вида "софтина-плагины-еще-софтина-еще-плагины" имее взаимоисключающие требования.
Всмысле неизвестна? Как софт должен установиться и как работать уже должно быть известно ещо до первой строки кода, на проектировании. Окружение по мере разработки да, может поменяться. Наприер, используемая БД или средства мониторинга. Но чем ближе к финишу, тем всё более точно известно и окружение.
При этом деплой пишется сразу, параллельно разработке. И этим кодом деплоя выкатывается продукт на stage сервера.


I>>>Неинтересно. Чет заказчик на такое не жаждет соглашаться. Что предложишь, оскорбить его, обмануть, кинуть?

S>>Если заказчик платит деньги чтобы ваш софт появился в его дистрибутиве то вам нужно опакетить ваш софт для того дистрибутива.
I>Заказчик платит не за софт в дистрибутиве, а за решение конкретной его проблемы. all-in-one это хороший вариант исключить проблемы с шаред/транзитивными зависимостями.
Определитесь уже. То заказчик не может на свои сервера поставить для вашего продукта нужную ОС (из списка популярных и заведомо стабильных), то ему побоку на ОС и ему надо решить некую проблему. Взаимоисключающие пункты.


S>>У меня значит получалось выяснить что и почему не работает (и это включало в себя например сборку подправленного постгреса с дополнительным дебаг-логом). А у настоящих тру-программистов-профессионалов лапки.

I>Снова тебе программисты мешают.
Я чтото не так сказал? Программисты умеют находить корни проблем и исправлять их? Если да, то к чему этот разговор? Срач ради срача?


I>>>Похоже, ты уже начал кое что понимать.

S>>Я изначально к этому вёл, но у тебя закостенение "шеридан-долбоклюй-непрофессионал" и это мешает тебе воспринимать то что я пишу.
I>Здесь ровно наоборот- ты по пять раз на сообщении утверждашь, что с прграммистами чтото не то.
Конечно чтото не то. Вас послушать так программист умеет только код в студии набирать. Чуть чтото не так и сразу у него лапки.


I>>> Смешно. У тебя похоже экономическая составляющая вообще в рассуждениях не присутствует. С чего ты взял, что влегкую фиксанешь произвольную либу?

S>>А я говорил что это будет легко? Я сказал что если либа не поддерживается больше, то выполнить один из этих двух пунктов тупо придётся. Ты будешь с этим спорить? Ты правда программист?
I>Совсем необязательно, что придется. Это всего лишь риск. Сработает ли он, и во что обойдутся последствия это отдельный разговор. И слишком часто заказчик принимает решение, что ему выгоднее всего игнорировать такие риски.
Ты по верхам прыгаешь. Спустись на землю. Этот риск при своевременном обновлении либ воообще не возникнут.


S>>Ну то есть никто на протяжениии нескольких лет не чинит баги означает что либа полностью и адекватно поддерживается автором?

S>>Г — лоГика.
I>Да, бывают такие баги, которые трудно воспроизводятся, или их фикс ломает обратную совместимость. БОлее того — приоритеты в разработке никто не отменял. А в опен-сорсе тебе никто ничего не должен.
Это ты к чему? Да, такие баги бывают. Но как это относится к тому что автор забил на свой проект и несколько лет его вообще не сопровождает?


I>>>У тебя багтрекер это синоним "магия". Ну есть баг в том трекере, только например описан он совсем не так, как тебя проявляется. Что дальше?

S>>Опиши так как у тебя проявляется. Надеюсь ты сам понимаешь, что это поможет автору баг исправить.
I>Это только с детскими багами так, когда сразу ясно где он, и как его воспроизвести. А слишком часто баг в одном месте, а причина — в противоположном, и появляется не сразу, а время от времени, через пару дней и последствия
То у тебя тот же баг в другом месте. То у тебя баг вообще неуловимый. Сколько у тебя обуви то?


S>>А как ещо назвать разрабов, которые говорят "если на баг никто не отвечает, то ты неправ что либа не поддерживается автором а наоборот."?

I>А это норма в опен-сорсе — игнорить баги. Заходишь зарепортать в популярный репозиторий, а там булькают вещи еще с нулевых.
Если брать к себе в проект либу которую когдато вася пуповкин написал для себя то так и будет. И часто у вас ошибки выбора используемых либ? Как часто вы хватаете первое попавшееся а потом "ойвей, а либа то мёртвая!"?.


I>>>Выглядит как юношеский максимализм. Я и моя команда и без тебя все это делаем.

S>>Если вы и так это всё делаете, то какого Иакова вы мне тут мозги полоскаете? Так и напиши "да, мы этим занимаемся, но по мере возможностей". И вопросов не будет. Срач ради срача?
I>Так я не сужу по себе.
Вот только не надо говорить мне что если весь мир называет белое чорным то и я обязан это делать.


I>>>Зато факт в том, что большинство долгоиграющих проектов такой роскоши позволить себе не могут. Причины самые разные. И только ты один обвиняешь разрабов в некометентности. Тут похоже весь мир живет не по твоим правилам

S>>Причин две: лень и некомпетентность. Я бы добавил третью: недальновидность. Но программисту бизнес-бабки-платит-я-кодю этого не понять.
I>Снова программисты виноваты.
Не все, а только те, которые тупы.

I>У тебя похоже риск и инцидент это одно и то же.

Нет. Но тебе же важно набросить на вентилятор.
Matrix has you...
Re[9]: Опять дваццатьпять
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.22 14:55
Оценка: +2
Здравствуйте, CreatorCray, Вы писали:

НС>>Да. Про контейнеры слышал?

CC>Предлагаешь каждую софтину запихивать в контейнер?
CC>А не дороговато ли выйдет?
Да ну откуда? Контейнеры же из слоёв; как я понял — слои повторно используются.
Поэтому если у тебя на железке 30 контейнеров с аппликухами построены на одном и том же дистрибутиве, и в 20 используется питон, а в 10 — go, то физически на диске будет лежать 1 питон и 1 го.
Если кому-то потребовался питон 2.7, а не 3.1, то появится 1 экземпляр питона 2.7, при этом он никак не помешает тем 20 аппликухам, которым нужен питон 3.1.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.