Pzz>В Go если от слайса сделать субслайс, получишь "указатель" на ту же память, где был оригинальный слайс. И если модифицировать субслайс, оригинальный слайс тоже изменится, и наоборот. А вот если потом к оригинальному слайсу сделать append, то может он переедет в другую память, а может и нет, как повезет. И тогда модификация одного может будет изменять другой, а может и нет. Pzz>Или, например, если мы от мегабайтного слайса отсубслайсим 5 байт, а про остальное "забудем", в памяти все равно будет занят мегабайт, потому что отсубслайсенные 5 байт все равно указывают на мегабайтный буфер, и GC его не приберет. Наивная идея организовать очередь, дописывая в конец слайса и откусывая от начала породит конструкцию, которая в конце концов сожрет всю память. Ну и т.д.
Ты так рассказываешь, как будто это чтото хорошее.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Anton Batenev, Вы писали:
AB>А зачем? Для ниши go монобинарь удобнее (в деплое и поддержке).
Насрать вообщето деплою и поддержке.
Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.
Здравствуйте, Sheridan, Вы писали:
S> AB>А зачем? Для ниши go монобинарь удобнее (в деплое и поддержке). S> Насрать вообщето деплою и поддержке.
Для ниши go — нет. Но мне сложно будет тебе объяснить почему, т.к. у тебя отсутствует релевантный опыт.
S> Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.
Для обсуждаемого языка и типичных условий работы go-приложений в подавляющем большинстве случаев монобинари — это и есть "нормальные".
Здравствуйте, ononim, Вы писали:
Pzz>>Или, например, если мы от мегабайтного слайса отсубслайсим 5 байт, а про остальное "забудем", в памяти все равно будет занят мегабайт, потому что отсубслайсенные 5 байт все равно указывают на мегабайтный буфер, и GC его не приберет. Наивная идея организовать очередь, дописывая в конец слайса и откусывая от начала породит конструкцию, которая в конце концов сожрет всю память. Ну и т.д.
O>Ты так рассказываешь, как будто это чтото хорошее.
Я так рассказываю, как будто это то, что есть. А хорошее оно или плохое, пусть каждый решает в меру своих потребностей.
Здравствуйте, Sheridan, Вы писали:
S>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.
Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут.
Здравствуйте, Anton Batenev, Вы писали:
S>> AB>А зачем? Для ниши go монобинарь удобнее (в деплое и поддержке). S>> Насрать вообщето деплою и поддержке. AB>Для ниши go — нет. Но мне сложно будет тебе объяснить почему, т.к. у тебя отсутствует релевантный опыт.
У меня всё отсутствует, да. Даже компустера нет, с калькулятора пишу, ага.
Писал я на этом вашем го. Деплою то что на го написано. Один из моих экспортеров prometheus community себе забрало. На go.
Но у меня опыта нет, иначе быть не может.
S>> Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением. AB>Для обсуждаемого языка и типичных условий работы go-приложений в подавляющем большинстве случаев монобинари — это и есть "нормальные".
Ну, такое редко бывает чтобы среда както накладывала ограничения на язык на котором написаны приложения. В современном мире даже для ардуин местами на питоне пишут. Но это не значит что так делать правильно и нужно.
Монобинари это такое себе, от безысходности. Когда не хватает опыта/знаний/желания уметь в зависимости. Когда в команде раздрай и разные участки проекта требуют разных версий одной и той же библиотеки. Отсюда и докеры с кубами выросли и гошечка.
S>>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением. CC>Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут.
Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов. Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.
Здравствуйте, Sheridan, Вы писали:
S>Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов. Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.
Ещё раз, при деплое куда лучше всё что надо иметь в себе, и ни от кого не зависеть.
Все внешние зависимости приводят к вариациям dll/libc-hell
Здравствуйте, Sheridan, Вы писали:
S>Монобинари это такое себе, от безысходности. Когда не хватает опыта/знаний/желания уметь в зависимости.
Ага, ага. Это примерно как люди изобрели туалетную бумагу и всякие там биде потому что не хватает опыта/знаний/желания уметь пальцем жопу вытирать.
S> Когда в команде раздрай и разные участки проекта требуют разных версий одной и той же библиотеки.
Ну а кроме твоего проекта на машине у кастомера вообще больше ничего не присутствует, да? Никаких других проектов, или твоего же только предыдущей версии.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Или, например, если мы от мегабайтного слайса отсубслайсим 5 байт, а про остальное "забудем", в памяти все равно будет занят мегабайт, потому что отсубслайсенные 5 байт все равно указывают на мегабайтный буфер, и GC его не приберет. Наивная идея организовать очередь, дописывая в конец слайса и откусывая от начала породит конструкцию, которая в конце концов сожрет всю память. Ну и т.д.
O>>Ты так рассказываешь, как будто это чтото хорошее.
Pzz>Я так рассказываю, как будто это то, что есть. А хорошее оно или плохое, пусть каждый решает в меру своих потребностей.
Забавный факт. В жаве кажется до 8 версии substring работал именно так: был один общий массив символов и offset/length. Т.е. маленькая строка могла внутри держать массив на мегабайт, к примеру. Но потом поменяли на копирование.
Но в целом я думаю, что поведение go лучше. Программист сам должен понимать, когда данные надо копировать, а по умолчанию оно должно работать максимально быстро. Скажем сейчас в Java невозможно повторить то поведение (без написания своего класса String).
Здравствуйте, Sheridan, Вы писали:
S>>>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением. CC>>Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут. S>Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов.
Снова у Шеридана программисты некомпетентные. Может это ты разработку не понимаешь?
Надо вспомнить, что стоимость труда разработчиков выросла до небес, а стоимость стораджа упала ниже плинтуса, при этом сложность софта растет непрерывно.
> Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.
Актуализация либ это процесс крайне трудозатратный. Настолько трудозатратный, что большинство проектов просто отказываются и делают это только когда секюрити баг найден или что навроде. В самых популярных либах такое конечно протекает легко. Штука в том,что далеко не все сводится к тем самым хорошим и правильным либам, коих в общей массе единицы.
Больше всего проблем доставляют шаред и транзитивные зависимости. Например — обновил ты либу, упали тесты А. Фиксанул. Обновил другую — упали тесты Б. Фиксанул — снова упали А. Фиксанул — упали тесты Б. Обычно здесь надо засаживаться за глубокую отладку что не всегда возможно, писать тикеты и ждать фиксов, искать версии, которые хоть как то совместимы, или гуглить до посинения, пока кто нибудь не подскажет тебе комбинацию.
Такое, во первых, требует высокой квалификации, во вторых, огромных трудозатрат, и часто абсолютно непредсказуемо по продолжительности.
И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.
За деньги, которые этот разработчик потратит на миграцию, можно проплатить хостинг-деплоймент-клауд на год. Отсюда ясно, что постоянно заниматься миграциями никто в своём уме не будет.
Поэтому обычно используются другие подходы, например — zero dependency, или all-in-one, или доккер, или lambda, или итд.
Здравствуйте, CreatorCray, Вы писали:
CC>Ещё раз, при деплое куда лучше всё что надо иметь в себе, и ни от кого не зависеть.
Ещё раз: абсолютно насрать. Что надо — то и задеплоится. Надо один ьинарник — будет один бинарник. Надо 100500 либ впридачу — будет 100500 либ впридачу. Не программистское дело — лезть в деплой. Просто скажите что надо — то и будет.
CC>Все внешние зависимости приводят к вариациям dll/libc-hell
Это от некомпетентности того кто допустил этот самый hell.
Здравствуйте, CreatorCray, Вы писали:
S>>Монобинари это такое себе, от безысходности. Когда не хватает опыта/знаний/желания уметь в зависимости. CC>Ага, ага. Это примерно как люди изобрели туалетную бумагу и всякие там биде потому что не хватает опыта/знаний/желания уметь пальцем жопу вытирать.
Нет.
Слишком легко, не стараешься. Нет упоминания гитлера, геноцида и человекоедения. Ну чтобы нагнетать так нагнетать.
S>> Когда в команде раздрай и разные участки проекта требуют разных версий одной и той же библиотеки. CC>Ну а кроме твоего проекта на машине у кастомера вообще больше ничего не присутствует, да? Никаких других проектов, или твоего же только предыдущей версии.
Нууу вообщето чаще всего да. А то и один проект целый кластер машин занимает со всяким окружением типа БД/мониторинга.
И даже в этом случае надо планировать и выполнять апгрейд используемых либ под выбранные версии продакшн-дистрибутивов.
Здравствуйте, Ikemefula, Вы писали:
S>>>>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением. CC>>>Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут. S>>Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов.
I>Снова у Шеридана программисты некомпетентные. Может это ты разработку не понимаешь?
Может это программисты деплой не понимают? Может это программисты не понимают что на машине может крутиться не только их, безусловно божественный, проект?
I>Надо вспомнить, что стоимость труда разработчиков выросла до небес, а стоимость стораджа упала ниже плинтуса, при этом сложность софта растет непрерывно.
И поэтому надо писать говно на говне и делать модным говно. Я тебя услышал.
>> Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать. I>Актуализация либ это процесс крайне трудозатратный. Настолько трудозатратный, что большинство проектов просто отказываются и делают это только когда секюрити баг найден или что навроде. В самых популярных либах такое конечно протекает легко. Штука в том,что далеко не все сводится к тем самым хорошим и правильным либам, коих в общей массе единицы.
Когда проепустили пару десятков версий а потом пришол петух с вооот таким клювом и таки клюнул — то да. Очень трудозатратный процесс. Потому что надо в кратчайшие сроки сделать работу, которую надо было делать на протяжении нескольких лет.
I>Например — обновил ты либу, упали тесты А. Фиксанул. Обновил другую — упали тесты Б. Фиксанул — снова упали А. Фиксанул — упали тесты Б. Обычно здесь надо засаживаться за глубокую отладку, что бы выяснить, почему либы несовместимы, писать тикеты, искать версии, которые хоть как то совместимы, или гуглить до посинения, пока кто нибудь не подскажет тебе комбинацию.
Стандартный рабочий процесс. Если не оттягивать и не ждать петуха.
I>Такое, во первых, требует высокой квалификации, во вторых, огромных трудозатрат.
Про трудозатраты я уже сказал. Про квалификацию: что, серьёзно настолько всё плохо что программисты разучились читать ченгджлоги и пользоваться поиском? Серьёзно?
I>И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.
Это когда петух приходит. А когда вовремя всё — то и затраты около нуля.
I>За деньги, которые этот разработчик потратит на миграцию, можно проплатить хостинг-деплоймент-клауд на год. Отсюда ясно, что постоянно заниматься миграциями никто в своём уме не будет.
Ты придумал высокие затраты и теперь пишешь про то что можно сделать вместо них. И выглядит всё логично и правильно.
Только вот высокие затраты ты придумал. В этом проблема.
I>Поэтому обычно используются другие подходы, например — zero dependency, или all-in-one, или доккер, или lambda, или итд.
Это от некомпетентности/лени. Потому что лень обновить либу, лень посмотреть/почитать чего нового появилось в мире.
Приведу пример:
Берём линупс. Буквально любой. А на больших промежутках времени (десятилетия) то и любую вообще ОС.
Устанавливаем ОС и не обновляем несколько лет. А потом обновляем. ВНЕЗАПНО возникает такая гора проблем, что для их решения реально нужны действительно дорогие специалисты и время.
А вот если обновлять ОС хотя бы раз в месяц — то и проблем не будет. Либо для их решения достаточно обычного приходящего админа.
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, CreatorCray, Вы писали:
CC>>Ещё раз, при деплое куда лучше всё что надо иметь в себе, и ни от кого не зависеть.
NB>или как альтернатива разворачивать свой докер образ
Это тоже способ уйти от необходимости обновлять у себя используемое.
Смотри:
Сначала были монолиты. Чтобы решить проблему используемых при разработке либ (не всем дано вовремя обновляться, да и лень) — придумали микросервисы.
Спустя какоето время поняли что микросервисы решили только проблему разработки и переместили проблему зависимостей на deploy-time. Поэтому придумали изоляцию (докер)
А теперь и докер перестал устраивать. Поэтому с одной стороны появляются языки, где секут плетями за "не такой" код и либы вкомпиливаются в бинарник (сабж). А с другой стороны пилят кубернетес чтобы хоть както управлять контейнерами и их версиями.
А казалось бы — обновляйтесь вовремя и никаких проблем.
Здравствуйте, Sheridan, Вы писали:
CC>>>Ещё раз, при деплое куда лучше всё что надо иметь в себе, и ни от кого не зависеть. NB>>или как альтернатива разворачивать свой докер образ
S>Это тоже способ уйти от необходимости обновлять у себя используемое.
макс, давай ты не будешь фантазировать о том, почему ушли от монолитов.
S>А казалось бы — обновляйтесь вовремя и никаких проблем.
не просто обновляйся, но и заставь всех клиентов обновляться. причем на ту версию, что поставилась в твоей системе.
в реальной жизни это почему-то не работает
