Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>>Бизнес нанимает профессионала чтобы решать задачи бизнеса но потом не слушает профессионала НС>>>С чего ты взял что ты профессионал? Сам так решил? То что ты тут пишешь — уровень любителя. S>>Я тут при чом?
НС>При том что рекомендации плевать на задачи бизнеса и постоянно обновлять либы идут исключительно от тебя. Профессионал такого бизнесу навязывать не будет.
При чом тут "навязывать"? Это как раз та самая работа, за которую бизнес платит деньги. Бизнес хочет стабильный, развивающийся продукт. И нанимает для этого профессионала.
НС>Я тебе больше скажу, бизнес часто такое и не навязывает. Бизнес просто просит реализовать набор фич. А решение по тому когда мы либы обновляем, а когда занимаемся другими задачами принимают разработчики. И инициатива тормознуть обновление почти всегда исходит от них. Бизнес скорее наоборот, прибежит с найденной уязвимостью и попросит что то обновить.
А что мешает в ответ на моё "планируйте обновления" (переведу на бизнес-язык: "сообщите бизнесу, что в случае долгого не-обновления может случиться 'ой' и придется потратить сотни нефти на исправление") написать "мы както так приблизительно и работаем"
Зачем вы мне пишете тогда фразы типа "обновлять ненужно"? Срач ради срача?
Здравствуйте, Sheridan, Вы писали:
НС>>Это не задача, а решение, одно из. Задача называется динамическая диспетчеризация, и у нее есть много вариантов решения, не только полиморфизм классов в ОО стиле. S>А тут речь именно про ООП.
Нет, тут речь про конкретное решение при помощи наследования из ООП.
S>Он не сказал "ООП нет, но задача решится об динамическую типизацию".
Ты по прежнему не в состоянии прочесть что тебе пишут.
Здравствуйте, Sheridan, Вы писали:
НС>>При том что рекомендации плевать на задачи бизнеса и постоянно обновлять либы идут исключительно от тебя. Профессионал такого бизнесу навязывать не будет. S>При чом тут "навязывать"? Это как раз та самая работа, за которую бизнес платит деньги.
Бизнес не платит деньги за обязательное и постоянное обновление либ.
S> Бизнес хочет стабильный, развивающийся продукт.
Осталось доказать что постоянное обновление всех либ — обязательное условие для стабильного, развиваюющегося продукта.
S>А что мешает в ответ на моё "планируйте обновления"
А сейчас ты занялся подменой. Ты заявлял не про планирование обновлений (с этим никто бы и не спорил), а про:
Используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.
S>Зачем вы мне пишете тогда фразы типа "обновлять ненужно"?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>>>>>Нет. Для того контейнеры и придумали, чтобы не было дороговато. S>>>>>>А ты считал стоимость сопровождения? НС>>>>>Кого, контейнеров? И что подразумевается под их сопровождением? S>>>>>> Стоимость специалиста по кубам, нопример? НС>>>>>При чем тут куб? Куб решает намного больше задач, чем контейнеры. S>>>>Кто будет инфраструктуру настраивать? НС>>>Ты не ответил на вопрос.
НС>Потому что твой вопрос в стиле "ты уже перестал пить коньяк по утрам". Я задал тебе уточняющий вопрос. Тут ты понял что спорол фигню и начал всячески уходить от темы. Так будет ответ или засчитываем слив?
Я тебя спросил считал ли ты стоимость сопровождения. Ты включил непонятно кого и начал изображать непонимание. Я сделал вид что ты вопрос не понял и спросил его по другому, проще. Ты начал уходить от темы. И в итоге обвинил меня что от темы ушол я.
Удобно, чо.
Здравствуйте, Sheridan, Вы писали:
S>Да-да-да, контейнеры разворачиваются чуть ли не по щелчку пальцев. Но чтобы это произошло ктото должен это описать, настроить, подготовить инфраструктуру
Есть возможность развернуть кластерное решение без "ктото должен это описать, настроить, подготовить инфраструктуру"?
S>С тем же успехом можно не в контейнеры а в ansible/chif, да хоть тупо в скрипты.
Можно, но контейнереы проще, универсальнее и быстрее.
S>Ой, ВНЕЗАПНО виртуальная машина.
Почему внезапно? ВМ это базовый кирпич облаков, понятно что к ней все сведется. Впрочем, есть варианты и без ВМ, см. ACI/Fargate.
S> Причом следующим же пунктом после "vm нинужны!"
Где ты увидел такой пункт?
S>
НС>>More consistent operation
НС>>DevOps teams know applications in containers will run the same, regardless of where they are deployed.
S>Ой, а без контейнеров как будто приложения работают по другому.
Они больше зависят от окружения, как следствие больше проблем при деплойменте в конкретное окружение.
S>Напомню только что ровно так же можно и без контейнеров при помощи того-же ansible.
Нельзя. Контейнер понимается намного быстрее, чем отрабатывают твои скрипты. Я уж не говорю о том, что собрать контейнер намного проще и требует меньше знаний.
Здравствуйте, Sheridan, Вы писали:
S>Я тебя спросил считал ли ты стоимость сопровождения.
Я писал про контейнеры, ты спросил про кубер. Почему я должен включать стоимость сопровождения кубера в оценку бенефитов от контейнеров? Так при чем тут кубер?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Неадекватность современным задачам, плохо работающие идеи. S>>эммм... Можешь более подробно пжлст?
НС>Могу
Первый же пункт, про наследование которое не имеет отражений в реальном мире. Серьёзно? Что с эволюцией делать будем?
Ну и вообще там всё такое.. "А может быть, а может и не быть". В челом написано умно но ничего существенного.
Ну отсутствуют какието формализованные правила — ну так их и нигде нет.
OO is Xenophobic — вообще фантастический аргумент
В общем, автор очень хочет очернить ООП, явно видно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Это не задача, а решение, одно из. Задача называется динамическая диспетчеризация, и у нее есть много вариантов решения, не только полиморфизм классов в ОО стиле. S>>А тут речь именно про ООП. НС>Нет, тут речь про конкретное решение при помощи наследования из ООП.
Цитирую: "В Go есть ООП, причём достаточно крутой за счёт структурной типизации."
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sheridan, Вы писали:
НС>>>При том что рекомендации плевать на задачи бизнеса и постоянно обновлять либы идут исключительно от тебя. Профессионал такого бизнесу навязывать не будет. S>>При чом тут "навязывать"? Это как раз та самая работа, за которую бизнес платит деньги. НС>Бизнес не платит деньги за обязательное и постоянное обновление либ.
Это такая же часть работы, как и нажатие на кнопки. Так что платит. Но эта работа не выполняется (иначе бы срача не было). И то что бизнес просто не в курсе того, что часть работы не выполняется вы почемуто интерпретируете как "бизнесу это не надо".
S>> Бизнес хочет стабильный, развивающийся продукт. НС>Осталось доказать что постоянное обновление всех либ — обязательное условие для стабильного, развиваюющегося продукта.
Потому что если не обновлять то со временем продукт тупо перестанет работать на свежих ОС.
S>>А что мешает в ответ на моё "планируйте обновления" НС>А сейчас ты занялся подменой. Ты заявлял не про планирование обновлений (с этим никто бы и не спорил), а про: НС>
НС>Используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.
Не "при их релизе сразу", а "сразу во всех проектах". Казнить нельзя помиловать получилось, да.
S>>Зачем вы мне пишете тогда фразы типа "обновлять ненужно"? НС>Приведи где я такое написал. Не стыдно врать то?
Я написал "вы". Тебе бы я написал "ты".
Хотя бы вон там
Здравствуйте, Sheridan, Вы писали:
S>Ну как бы, на секундочку, это минус. Негоже в рамках одного проекта держать зоопарк подпроектов на разных языках.
О, давай, расскажи как надо, очень интересно.
Вот есть у нас модуль обучения, написан на Питоне (модуль это не dll, это набор скриптов, общающихся с внешним миром через консоль и файлы и запускающий при этом десяток разных приложений), и команда, умеющая в машинное обучение и Питон. Рядом другая команда, умеющая в CV и C++, и модуль CV на C++. И третья команда, умеющая в облачный бэк и их Платформа, написанная на дотнете или жабе. И еще пяток сторонних сервисов, написанных на Go, С++, Питоне, жаве.
Теперь это все нам нужно собрать в работающий продукт, причем в разумные сроки. Твои действия?
Здравствуйте, Sheridan, Вы писали:
S>Image: emulation_workflow2.png S>Ой, ВНЕЗАПНО виртуальная машина. Причом следующим же пунктом после "vm нинужны!"
Не совсем. qemu-aarch64/qemu-amd64 (или FIX-Emu, с которым я сейчас экспериментирую) не виртуализует всю машину, а только конкретный процесс (или группу процессов). Оно просто транслирует системные вызовы между архитектурами, и сам прикладной код.
При этом благодаря механизму binfmt_misc в Линуксе можно запустить нативный bash на x64, из него запустить midnight commander для aarch64, а затем из него запустить приложение для архитектуры risc-v.
Здравствуйте, Sheridan, Вы писали:
S>>>А тут речь именно про ООП. НС>>Нет, тут речь про конкретное решение при помощи наследования из ООП. S>Цитирую: "В Go есть ООП, причём достаточно крутой за счёт структурной типизации."
Есть. Нет "наследования классов" и мастурбирования на "контроль доступа".
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Да-да-да, контейнеры разворачиваются чуть ли не по щелчку пальцев. Но чтобы это произошло ктото должен это описать, настроить, подготовить инфраструктуру НС>Есть возможность развернуть кластерное решение без "ктото должен это описать, настроить, подготовить инфраструктуру"?
Нет.
S>>С тем же успехом можно не в контейнеры а в ansible/chif, да хоть тупо в скрипты. НС>Можно, но контейнереы проще, универсальнее и быстрее.
Все три — спорно. Если кратко — зависит от опыта того кто это делает.
S>>Ой, ВНЕЗАПНО виртуальная машина. НС>Почему внезапно? ВМ это базовый кирпич облаков, понятно что к ней все сведется. Впрочем, есть варианты и без ВМ, см. ACI/Fargate. S>> Причом следующим же пунктом после "vm нинужны!" НС>Где ты увидел такой пункт?
Прямо перед обсуждаемым.
S>>
НС>>>More consistent operation
НС>>>DevOps teams know applications in containers will run the same, regardless of where they are deployed.
S>>Ой, а без контейнеров как будто приложения работают по другому. НС>Они больше зависят от окружения, как следствие больше проблем при деплойменте в конкретное окружение.
Ну так хоть какието минимальные требования к окружению то должны быть, не?
Или вы эти требования делегируете докеру?
Заказчику всё равно, он их выполнит либо для докера либо для вас. Не аргумент, крч.
S>>Напомню только что ровно так же можно и без контейнеров при помощи того-же ansible. НС>Нельзя. Контейнер понимается намного быстрее, чем отрабатывают твои скрипты. Я уж не говорю о том, что собрать контейнер намного проще и требует меньше знаний.
Тоже спорно и тоже зависит от опыта исполнителя.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Я тебя спросил считал ли ты стоимость сопровождения. НС>Я писал про контейнеры, ты спросил про кубер. Почему я должен включать стоимость сопровождения кубера в оценку бенефитов от контейнеров? Так при чем тут кубер?
А что, куб внезапно перестал быть модным и все обратно в докер-композ вернулись?
Ну допустим что так, сделай s/куб/докеркомпоз/ — смысл вопроса останется тем-же.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот есть у нас модуль обучения, написан на Питоне (модуль это не dll, это набор скриптов, общающихся с внешним миром через консоль и файлы и запускающий при этом десяток разных приложений), и команда, умеющая в машинное обучение и Питон. Рядом другая команда, умеющая в CV и C++, и модуль CV на C++. И третья команда, умеющая в облачный бэк и их Платформа, написанная на дотнете или жабе. И еще пяток сторонних сервисов, написанных на Go, С++, Питоне, жаве. НС>Теперь это все нам нужно собрать в работающий продукт, причем в разумные сроки. Твои действия?
У вас выбора нет, у вас уже есть куча мала и её хоть както надо запустить.
Я же про ситуации когда выбор (ещё) есть.
Здравствуйте, Cyberax, Вы писали:
S>>Цитирую: "В Go есть ООП, причём достаточно крутой за счёт структурной типизации." C>Есть. Нет "наследования классов" и мастурбирования на "контроль доступа".
Ну, такой себе ООП. Самую мякотку и выкинули.
S>func (fee *Fee) Bar() { S> log.Println("Fee::Bar called, id:", fee.id); S> fee.Foo.Bar(); S>} S>Это точно наследование с переопределением? Я ничего не перепутал? -_-
То что ты выделил — это в терминах С++ — вызов метода базового класса из переопределенного метода в дочернем. Просто чтобы показать возможности.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, bitboi, Вы писали:
B>но вот библиотеки — говно, не потому что они плохо или некачественно сделаны, а потому что они какие-то слишком самобытные
ЩИТО?
Из однозначно плохих библиотек в стандартной упаковке — только SQL и log.
B>почему для того чтобы соединиться с хостом мне нужно вызывать метод Dial?
Потому, что "connect" слишком перегружен. Надо было имя придумать.
B>где мои monotonic clocks? почему вместо этого time.Now() возвращает объект, который содержит две метки времени и пытается быть умным при вычислении интервалов?
Эрм... time.Now() всегда содержит монотонное время. Как раз очень остроумное решение. Такая вот последовательно гарантированно работает даже при изменении системного времени:
start := time.Now()
time.Sleep(10*time.Second)
end := time.Now()
elapsed := end.Sub(start) // Всегда правильно
B>какого лешего все операции с файлами принимают String вместо специального типа Path, String это юникодная строка, а путь в файловой системе не обязан ею быть
Это не так. string в Go может содержать произвольный набор байт.
Исключение есть только одно — на Windows строка преобразуется в UCS-2 перед вызовом CreateFileW. Проблема в том, что в Windows файлы могут содержать произвольный набор UCS-2 символов, в том числе и последовательности, которые не транслируются в utf-8 (см.: https://simonsapin.github.io/wtf-8/ ). Так что на Windows у Go могут быть проблемы в случае с файловыми системами, созданными в старых версиях Windows.
B>таких странностей там очень много, это такие вещи, которые бы просто не приняли на ревью, если бы их попытались пропихнуть в тот же boost
В Бусте ровно та же проблема, кстати. Я проверял и отправлял баг.
Здравствуйте, Sheridan, Вы писали:
S>>>Цитирую: "В Go есть ООП, причём достаточно крутой за счёт структурной типизации." C>>Есть. Нет "наследования классов" и мастурбирования на "контроль доступа". S>Ну, такой себе ООП. Самую мякотку и выкинули.
Наследование классов — оказалось противопоказано и в классических ООП, так как создаёт слишком сильную связность. А детальный контроль доступа просто не нужен, достаточно разделения между публичным интерфейсом и приватным для пакета.