Re[16]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 11:26
Оценка:
Здравствуйте, Pzz, Вы писали:

S>>Как и следовало ожидать:

S>>1. Довольно странная тулза, которой пользуются два с половиной человека и ты.
S>>2. Проприетарный драйвер, у которого нет исходников и на обновление которого забили программисты этого драйвера.

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

Я его и не выдвигал, ты прав.

Pzz>Надо сказать, что опенсорсный CUPS пытается опознать мой принтер и на нем печатать. Только у него это не очень-то получается. Вернее, получается печатать белые листы. Что, конечно, очень полезно в плане экологии, экономии бумаги и повышения секретности в делопроизводстве, но не совсем совпадает с целями, с которыми я этот принтер купил.

Pzz>Помогает руками сочетать опенсорсный CUPS с неопенсорсным PDL-файлом, который можно, при некоторой сноровке, выдернуть из инсталлятора неопенсорсного драйвера. Что само по себе удивительно, потому, что мой принтер прекрасно поддерживает совершенно стандартные IPP, PDF и PostScript, и, казалось бы, CUPS'у больше ничего не должно быть нужно.
И что тебе помешало сразу печатать об "IPP, PDF и PostScript,"?
Ну и я не знаю что именно реализовывалось киоцерой в следующей цепочке

И да, там тоже есть свои компиляторы, исходники для которых могут быть закрыты.
Matrix has you...
Re[14]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 11:28
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>>>Ну при всем при том, большинство программистов вряд ли понимают, как устроен внутри float.

S>>Я про некомпетентность и лень как раз тут и пишу.

Pzz>Это не некомпетентность. Просто float — это очень хорошо инкапсулированный тип. Никому особо и не надо знать, как он внутри устроен, он прекрасно реализует заявленный интерфейс, независимо от своего внутреннего устройства.

Ты прав в контексте сабжа. Незнание устройства float скорее всего не помешает выпустить релиз. А вот неумение управлять зависимостями и отсутствие знаний для чего это нужно — скорее всего помешает выпуску релиза.
Matrix has you...
Re[15]: Язык Go - слабые стороны
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.02.22 11:31
Оценка:
Здравствуйте, Sheridan, Вы писали:

Pzz>>Ну, когда тебя попросят сделать интерфейс, ты скажешь, что это сложно, хлопотно и надо тестировать, и займет это неделю. И у тебя есть некоторая надежда, что менеджер тебе поверит и пойдет искать другого крайнего. А вот убедить менеджера, что на замену слова private на слово public у тебя уйдет неделя, ты вряд ли сможешь.

S>Твои слова подтверждают твою мысль что и там и там сменить доступ к интерфейсу можно, если есть доступ к исходникам. А делать ли это прямо сейчас зависит от подвешенности языка а не от ограничений языка/мотодологии.

Ну вообще-то говоря, этого совсем не следовало бы делать. Просто в таких местах происходит конфликт интересов между хорошим программированием и хорошим ведением бизнеса. И бизнес обычно побеждает.

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

S>Это справедливо и при работе с библиотекой и при работе с http api. Зачем это тут? Меня заболтать?

Потому, что вытащить внутренность в интерфейс заметно сложнее, чем открыть прямой доступ к памяти.

Pzz>>Поэтому одной только инкапсуляции недостаточно, чтобы сложность проекта не разрасталась. Надо еще, чтобы превращение приватного в публичное было действительно муторным и трудоемким мероприятием.

S>Это тоже не спасёт от дурака. Правильно делать так: не пускать туда дурака.

Я все больше и больше убеждаюсь, что дурак — роль социальная. Т.е., если набрать в проект одних умных, они все равно расслоятся не небольшое количество граждан, которые ведут себя и поступают, как умные, а остальные будут дураками. Если дураков потом поувольнять, оставшиеся умные опять расслоятся. И так до тех пор, пока вообще никого не останется.

Иными словами, дураки неистребимы.

S>Это както противоречит тому что докер появился после микросервисов и туда начали запихивать микросервисы для изоляции?


Я не историк, мне трудно сказать, кто появился раньше.

Но в принципе, "микросервисы" — это модное слово для давно известной идеи. Полагаю, микросервисы как идея, а не модное слово, появились примерно тогда, когда появились компьютеры, способные одновременно исполнять несколько программ.

Pzz>>Слушай, я в полном соответствии с теорией Фрейда эти травмирующие воспоминание немедленно вытесняю после того, как они перестают быть актуальными.

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

Но тем не менее, случается.
Re[16]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 11:41
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>>>Ну, когда тебя попросят сделать интерфейс, ты скажешь, что это сложно, хлопотно и надо тестировать, и займет это неделю. И у тебя есть некоторая надежда, что менеджер тебе поверит и пойдет искать другого крайнего. А вот убедить менеджера, что на замену слова private на слово public у тебя уйдет неделя, ты вряд ли сможешь.

S>>Твои слова подтверждают твою мысль что и там и там сменить доступ к интерфейсу можно, если есть доступ к исходникам. А делать ли это прямо сейчас зависит от подвешенности языка а не от ограничений языка/мотодологии.
Pzz>Ну вообще-то говоря, этого совсем не следовало бы делать. Просто в таких местах происходит конфликт интересов между хорошим программированием и хорошим ведением бизнеса. И бизнес обычно побеждает.
Да, ты прав. Этого не следует делать. Но если бизнес победит программирование то и ты и я это сделаем в обоих случаях


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

S>>Это справедливо и при работе с библиотекой и при работе с http api. Зачем это тут? Меня заболтать?
Pzz>Потому, что вытащить внутренность в интерфейс заметно сложнее, чем открыть прямой доступ к памяти.
и там и там это можно сделать. Скорость реализации зависит от компетентности программиста и там и там. И, опять же, и там и там это будет сделано если бизнес скажет "надо!".
Более того, во втором случае это вдобавок ещё будет сделать сложнее.


Pzz>>>Поэтому одной только инкапсуляции недостаточно, чтобы сложность проекта не разрасталась. Надо еще, чтобы превращение приватного в публичное было действительно муторным и трудоемким мероприятием.

S>>Это тоже не спасёт от дурака. Правильно делать так: не пускать туда дурака.
Pzz>Я все больше и больше убеждаюсь, что дурак — роль социальная. Т.е., если набрать в проект одних умных, они все равно расслоятся не небольшое количество граждан, которые ведут себя и поступают, как умные, а остальные будут дураками. Если дураков потом поувольнять, оставшиеся умные опять расслоятся. И так до тех пор, пока вообще никого не останется.
Ну, это уже про психологию а не про программирование и деплой.


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

Pzz>Но тем не менее, случается.
Вероятность вообще чего угодно никогда не равна нулю. Но это не означает что не нужно стремится вероятность негативных последствий стремить к нулю.
Matrix has you...
Отредактировано 16.02.2022 11:42 Sheridan . Предыдущая версия .
Re[17]: Язык Go - слабые стороны
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.02.22 11:42
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>И что тебе помешало сразу печатать об "IPP, PDF и PostScript,"?


То, что изначально их драйвер работал. А потом федора подвергла 2-й питон геноциду, и он перестал/

S>Ну и я не знаю что именно реализовывалось киоцерой в следующей цепочке


Я не такой уж знаток внутренностех CUPS'а, хотя иногда переписываюсь с его автором. Полагаю, что фильтр, но это не точно.

Судя по тому, что достаточно просто подсунуть PPD, этот фильтр не больно-то и нужен. Я полагаю, что и PPD не больно-то и нужен, но CUPS все равно какой-то опенсорсный подсовывает, скорее вредный, чем полезный.

S>Image: cups-postscript-chain.png

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

Я всегда думал, что PPD подсовываются ghostscript'у вместе с документом, который надлежит распечатать, и являются программой для ghostscript'а (или иного интерпретатора постскрипта).

Android и iPhone печатают на этом принтере без всяких драйверов и PPD. У них с ним делается бездрайверное IPP Everywhere, иначе называемое AirPrint.
Re[18]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 11:45
Оценка:
Здравствуйте, Pzz, Вы писали:


Pzz>Я не такой уж знаток внутренностех CUPS'а,

Я тоже не ахти какой знаток, да.
Речь тут вообще о том, что поломался проприетарный драйвер (фильтр? ppd? чтотоещо?), жизнь которого обособлена внутри киосеры и не может управляться снаружи темже редхатом. То есть это некий чёрный ящик, новую версию которого киосеровцы не потрудились соорудить.
Matrix has you...
Re[10]: Язык Go - слабые стороны
От: ononim  
Дата: 16.02.22 12:09
Оценка:
vsb>>Забавный факт. В жаве кажется до 8 версии substring работал именно так: был один общий массив символов и offset/length. Т.е. маленькая строка могла внутри держать массив на мегабайт, к примеру. Но потом поменяли на копирование.
Pzz>Это очень такое Сишное поведение. Т.е., человек, для которого привычен Си, другого бы и не ждал.
Проблема в том что это поведение неочевидно из синтаксиса, как я уже писал гдето тут, если бы append принимал указатель на слайс, подвергающийся модификации — все было бы очевиднее. А он принимает слайс и возвращает слайс, причем тот слайс который он принимает остается в непредсказуемом для программиста состоянии. По сути — классическое сишное UB, просто без SIGSEGV.
Как много веселых ребят, и все делают велосипед...
Отредактировано 16.02.2022 12:11 ononim . Предыдущая версия .
Re[7]: Язык Go - слабые стороны
От: Vetal_ca Канада http://vetal.ca
Дата: 16.02.22 12:34
Оценка: +5
Здравствуйте, Ikemefula, Вы писали:

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


Это не лечится. Уже были эти споры. Все уже тысячу раз доказано а у Шеридана все "Нужно сечь разработчиков плетями". Он остановился, закостенел.

На картах его мира нет белых пятен: его мир оконечен и определен, как полные карты средневековья. Все уже открыто, известно и внесено в "Библию Шеридана". Пустые белые пространства замещаются монстрами и плетями, поджидающими непослушных, молодых и дерзких.

Лучше подумать о том, что каждый из наз подвержен такой же ловушке. И надо ее избежать.
Re[8]: Язык Go - слабые стороны
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.02.22 12:51
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

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

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

Именно потому, что на машине может крутиться чтото еще, стоит использовать, как вариант, all-in-one.

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

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

Вероятно, это ты так видишь свою работу. Только при чем здесь другие программисты, если дело в тебе?

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


Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке?
Я выбрал апгрейд на OutOfMemory,т.к. выяснил, что это ошибка — бросается не то исключение. Это стоило примерно один месяц — перебрать версии, идентифицировать проблемы, подебажить, выбрать нужную, протестировать, понаписывать сто заплаток и вкомитать.

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

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

К твоему сведению, в ченджлогах пишут зафикшеные баги, а не новые неизвестные.

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

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

Это голословно.

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

S>Только вот высокие затраты ты придумал. В этом проблема.

Наоборот. Я знаю ситуацию с обоих сторон — и как потребитель фремворка, и как разработчик.
Обеспечить обратную совместимость адски тяжело, при этом бОльшая часть времени уходит именно на это.
Правило большого пальца при разработке либы/фремворка — любое измнение/фикс что нибудь да поломает и не существует способа гарантировано это обнаружить.

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


См выше про содержимое ченджлога.

S>А вот если обновлять ОС хотя бы раз в месяц — то и проблем не будет. Либо для их решения достаточно обычного приходящего админа.


Голословно. Любая версия либы может сломать обратную совместимость. Нет способа гарантировать отсутствие багов.
Когда проблема в общих/транзитивных зависимостях, не существует способа гарантировано безопасно перекатиться на новую версию. Отвалилась кучка тестов и все решилось небольшим багфиксом — это идеальный случай.
Проблема не в девелоперах, в новых, неизвестных проблемах которые содержатся в новых версиях. Писать без багов пока что только шериданы умеют, и то на словах.
Отредактировано 16.02.2022 12:59 Pauel . Предыдущая версия .
Re[9]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 12:59
Оценка: :))
Здравствуйте, Ikemefula, Вы писали:

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


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

S>>Может это программисты деплой не понимают? Может это программисты не понимают что на машине может крутиться не только их, безусловно божественный, проект?
I>Именно потому, что на машине может крутиться чтото еще, стоит использовать, как вариант, all-in-one.
Нет. Это должно происходить когда все остальные шаги (такие как обновления библиотек в своём проекте) предприняты и не помогла.


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

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


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

I>Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке?
Написать баг авторам либы и не переходить пока он не будет починен.


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

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


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

S>>Это когда петух приходит. А когда вовремя всё — то и затраты около нуля.
I>Это голословно.
Нет, так делают люди, у которых процесс поставлен нормально а не "и так сойдёт".


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

S>>Только вот высокие затраты ты придумал. В этом проблема.
I>Наоборот. Я знаю ситуацию с обоих сторон — и как потребитель фремворка, и как разработчик.
ВНЕЗАПНО, я тоже. И я знаю, что если обновления планировать и выполнять в запланированное время (хотя бы раз в квартал), то затраты сильно ниже, чем обновляться только тогда когда приходит петух со своим клювом.


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

I>См выше про содержимое ченджлога.
См выше про багтрекер и отложенное обновление.


S>>А вот если обновлять ОС хотя бы раз в месяц — то и проблем не будет. Либо для их решения достаточно обычного приходящего админа.

I>Голословно. Любая версия либы может сломать обратную совместимость. Нет способа гарантировать отсутствие багов.
Я понял, ты теперь прицепился к возможным багам и не отцепишся. Багтрекер, друже, бааагтрееекер.
Matrix has you...
Re[2]: Язык Go - слабые стороны
От: Шубин Евгений Россия http://erladvisor.blogspot.de/
Дата: 16.02.22 13:02
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Лично для меня у Go самая фатальная проблема это система обработки ошибок. Я считаю, что исключения в сто раз лучше, чем то, что сделали в Go.


Я тут пописываю на Эликсире, где есть обработка ошибок через исключения и даже весьма приятная как на уровне библиотек, так и в популярных фреймворках. Заметил, что коллеги предпочитают коды возврата исключениям, все кроме меня.
Re[8]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 13:03
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V_>Это не лечится. Уже были эти споры. Все уже тысячу раз доказано а у Шеридана все "Нужно сечь разработчиков плетями". Он остановился, закостенел.

В эту игру можно играть вдвоём. Это местные агитаторы "не надо обновляться" и "память не ресурс" закостенели в своих убеждениях. И постоянно вытаскивают козыри "бизнес" и "бабло".
И если я не обновляю чтототам, не разбираюсь с избыточным жором ресурсов то значит я уже пытался это сделать и знаю почему не получится в данный момент. Так же это означает что у меня запланировано в будущем ещо одна попытка.
Matrix has you...
Re[10]: Язык Go - слабые стороны
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.02.22 13:14
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

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

I>>Именно потому, что на машине может крутиться чтото еще, стоит использовать, как вариант, all-in-one.
S>Нет. Это должно происходить когда все остальные шаги (такие как обновления библиотек в своём проекте) предприняты и не помогла.

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

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

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

Как я вижу, у нас есть Шеридан, который не в курсе что на этапе разработки нет сведений из будущего
1. кто куда чего может задеплоить
2. какие новые неизвестные баги могут быть привнесеные в какую из десятков или сотен зависимостей?

I>>Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке?

S>Написать баг авторам либы и не переходить пока он не будет починен.

Бинго! И автор либы через месяц сообщает, что он пофиксит, но возможно после того, как выкатит две версии.
А потом заходишь ты в гитхаб либы, и видишь, что эта проблема булькает уже три последних года.

I>>К твоему сведению, в ченджлогах пишут зафикшеные баги, а не новые неизвестные.

S>Для них есть багтрекер. Выше только что написал.

Похоже, что ты не различаешь "новые известные" и "новые неизвестные". Первые — в баклоге. А вот остальные булькают то тут то там и возможно не скоро попадут в баклог.

I>>Это голословно.

S>Нет, так делают люди, у которых процесс поставлен нормально а не "и так сойдёт".

Шериданы что ли?

I>>Наоборот. Я знаю ситуацию с обоих сторон — и как потребитель фремворка, и как разработчик.

S>ВНЕЗАПНО, я тоже. И я знаю, что если обновления планировать и выполнять в запланированное время (хотя бы раз в квартал), то затраты сильно ниже, чем обновляться только тогда когда приходит петух со своим клювом.

Это какие то общие слова вида "хорошее лучше плохого".

I>>Голословно. Любая версия либы может сломать обратную совместимость. Нет способа гарантировать отсутствие багов.

S>Я понял, ты теперь прицепился к возможным багам и не отцепишся. Багтрекер, друже, бааагтрееекер.

Что бы баг попал в багтрекер, его ктото должен обнаружить, идентифицировать, подготовить описание, стабильную последовательность. До того этот баг будет просто булькать тут и там и подламывать разработку.
В каждом проекте либы/фремворка есть кучка вечно живых багов, которые никто не берется фиксать, потому что
1. фикс ломает обратую совместимость
2. есть проблемы более приоритетные
Тем, для кого такой баг стал критичным, можно только посочувствовать.
Re[9]: Язык Go - слабые стороны
От: Vetal_ca Канада http://vetal.ca
Дата: 16.02.22 13:27
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


S>В эту игру можно играть вдвоём. Это местные агитаторы "не надо обновляться" и "память не ресурс" закостенели в своих убеждениях. И постоянно вытаскивают козыри "бизнес" и "бабло".

S>И если я не обновляю чтототам, не разбираюсь с избыточным жором ресурсов то значит я уже пытался это сделать и знаю почему не получится в данный момент. Так же это означает что у меня запланировано в будущем ещо одна попытка.

Почему ты считаешь, что кому-то интересно в это играть?

Есть реальная жизнь с реальными требованиями и ограничениями. Иногда это работает, иногда нет.

В стартапе это не работает, пока будут вылизывать, конкуренты перехватят инициативу.
В банке, работает. И не из-за ограничений жора а из-за attack surface и PCI compliance. Там обсосут и проверят каждую версию до мельчайших деталей

Естественно, твой религиозный подход ни там ни там не пройдет.
Re[11]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 13:31
Оценка:
Здравствуйте, Ikemefula, Вы писали:

S>>Нет. Это должно происходить когда все остальные шаги (такие как обновления библиотек в своём проекте) предприняты и не помогла.

I> Алё — на этапе разработки ты и представить не можешь, что куда кому взбредет в голову задеплоить. Как ты собираешься проанализировать тысячу-другую возможных комбинаций?
Достаточно нескольких (2-5) популярных дистрибутивов поддерживать. Всё остальное — "мы не поддерживаем данный дистрибутив но готовы помочь за допплату"


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

S>>Нет, это я так вижу работу отвечающих мне тут программистов, которые кричат о том что можно делать говно так как юзер просто купит памяти/стораджа и поэтому можно тяпляп.
I>Как я вижу, у нас есть Шеридан, который не в курсе что на этапе разработки нет сведений из будущего
I>1. кто куда чего может задеплоить
В рекомендованные вами дистрибутивы. Почемуто считается нормальным указываать версию мака и виндов для которых приложение работает. Но с линупсом надо обязательно вообще всё!!11.
Не работает так.

I>2. какие новые неизвестные баги могут быть привнесеные в какую из десятков или сотен зависимостей?

Вот это и есть — "закостеневание". Это когда "нетнет, обновляться нинада, уже и так хорошо, а вдруг там монстры??7"


I>>>Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке?

S>>Написать баг авторам либы и не переходить пока он не будет починен.
I>Бинго! И автор либы через месяц сообщает, что он пофиксит, но возможно после того, как выкатит две версии.
Автор общается, отвечает — ждём. А пока работаем со старой версией.

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

Два варианта:
1. Сменить библиотеку.
2. Форкнуть и пофиксить.
Почему так? Потому что де-факто эта либа уже не поддерживается никем. И обязательно устареет. Не сегодня так через пару лет. И всёравно придётся вот эти вот два пункта.
Я за то, чтобы запланировать один из этих пунктов и в рабочем порядке решить.
Ты за то чтобы оставить всё как есть и ждать петуха с вооот таким клювом...


I>>>К твоему сведению, в ченджлогах пишут зафикшеные баги, а не новые неизвестные.

S>>Для них есть багтрекер. Выше только что написал.
I>Похоже, что ты не различаешь "новые известные" и "новые неизвестные". Первые — в баклоге. А вот остальные булькают то тут то там и возможно не скоро попадут в баклог.
Я про новые неизвестные и пишу. Нашол такой — в багтрекер его.


I>>>Это голословно.

S>>Нет, так делают люди, у которых процесс поставлен нормально а не "и так сойдёт".
I>Шериданы что ли?
Если тебе так нравится, то да.


I>>>Наоборот. Я знаю ситуацию с обоих сторон — и как потребитель фремворка, и как разработчик.

S>>ВНЕЗАПНО, я тоже. И я знаю, что если обновления планировать и выполнять в запланированное время (хотя бы раз в квартал), то затраты сильно ниже, чем обновляться только тогда когда приходит петух со своим клювом.
I>Это какие то общие слова вида "хорошее лучше плохого".
В противовес твоему "старое лучше свежего" звучат более логично, не находишь ли?


I>>>Голословно. Любая версия либы может сломать обратную совместимость. Нет способа гарантировать отсутствие багов.

S>>Я понял, ты теперь прицепился к возможным багам и не отцепишся. Багтрекер, друже, бааагтрееекер.
I>Что бы баг попал в багтрекер, его ктото должен обнаружить, идентифицировать, подготовить описание, стабильную последовательность. До того этот баг будет просто булькать тут и там и подламывать разработку.
Ты и твоя команда это будут делать. Ты и твоя команда. В рабочем порядке во время запланированного обновления используемых либ на этапе тестирования свежего перед принятием решения "обновляться можно уже сейчас или ещо подождать?".
Matrix has you...
Re[10]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 13:36
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

S>>В эту игру можно играть вдвоём. Это местные агитаторы "не надо обновляться" и "память не ресурс" закостенели в своих убеждениях. И постоянно вытаскивают козыри "бизнес" и "бабло".

S>>И если я не обновляю чтототам, не разбираюсь с избыточным жором ресурсов то значит я уже пытался это сделать и знаю почему не получится в данный момент. Так же это означает что у меня запланировано в будущем ещо одна попытка.
V_>Почему ты считаешь, что кому-то интересно в это играть?
Это не должно быть интересно или неинтересно. Это работа, которую надо выполнить. Только и всего. Мне вот неинтересно например подготавливать (обновлять в том числе) репозитории стороннего софта при релизе нашего продукта. Тупо скучно. Но делать надо. Поэтому вот прямо щас сижу и слежу за строчками на экране от работающего скрипта.


V_>В стартапе это не работает, пока будут вылизывать, конкуренты перехватят инициативу.

Потом стартап становится на ноги, эти проблемы всётаки всплывают и встают стеной и их приходится решать. Один раз, второй... А потом планировать обновления начинают когда два раза штаны уже сгорели.
Matrix has you...
Re[19]: Язык Go - слабые стороны
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.02.22 14:17
Оценка:
Здравствуйте, Sheridan, Вы писали:

Pzz>>Я не такой уж знаток внутренностех CUPS'а,

S>Я тоже не ахти какой знаток, да.

Что-то ты стареешь, брат. Раньше ты вообще все знал, и никогда ни с чем не соглашался.

S>Речь тут вообще о том, что поломался проприетарный драйвер (фильтр? ppd? чтотоещо?), жизнь которого обособлена внутри киосеры и не может управляться снаружи темже редхатом. То есть это некий чёрный ящик, новую версию которого киосеровцы не потрудились соорудить.


Поменяли системную инсталляцию Питона, и старые скрипты на Питоне загнулись.
Re[12]: Язык Go - слабые стороны
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.02.22 14:26
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Достаточно нескольких (2-5) популярных дистрибутивов поддерживать. Всё остальное — "мы не поддерживаем данный дистрибутив но готовы помочь за допплату"


Несколько популярных — это Debian, Ubuntu, Fedora, пару-тройку последних версий на x86 и ARM. И еще возножно на MIPS, если ты любишь китайцев. Достаточно много сочетаний.

Просто JFYI.
Re[11]: Язык Go - слабые стороны
От: Vetal_ca Канада http://vetal.ca
Дата: 16.02.22 14:28
Оценка:
Здравствуйте, Sheridan, Вы писали:

V_>>Почему ты считаешь, что кому-то интересно в это играть?

S>Это не должно быть интересно или неинтересно. Это работа, которую надо выполнить. Только и всего. Мне вот неинтересно например подготавливать (обновлять в том числе) репозитории стороннего софта при релизе нашего продукта. Тупо скучно. Но делать надо. Поэтому вот прямо щас сижу и слежу за строчками на экране от работающего скрипта.

Еще молиться надо, по определенным дням, некоторые считают. некоторые считают, что машину надо обойти 3 раза, подергав за ручки, убедиться что она закрыта. Некоторые 2-3 раза возвращаются, закрыв дверь в квартиру, чтобы проверить еще раз плиту или утюг.

Все надо обосновать. А если есть экономически или технические необоснованные ритуалы, то тут большая вероятность ОКР

V_>>В стартапе это не работает, пока будут вылизывать, конкуренты перехватят инициативу.

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

Или не приходится.

У тебя есть хоть приблизительный порядок цифр, сколько ты выиграл и сколько затратил своего и чужого времени? Я уверен, что нет, ибо это вразрез с твоими ритуалами.
Re[20]: Язык Go - слабые стороны
От: Sheridan Россия  
Дата: 16.02.22 14:32
Оценка:
Здравствуйте, Pzz, Вы писали:

S>>Речь тут вообще о том, что поломался проприетарный драйвер (фильтр? ppd? чтотоещо?), жизнь которого обособлена внутри киосеры и не может управляться снаружи темже редхатом. То есть это некий чёрный ящик, новую версию которого киосеровцы не потрудились соорудить.

Pzz>Поменяли системную инсталляцию Питона, и старые скрипты на Питоне загнулись.
Очевидно что не все.
Matrix has you...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.