Вот тоже вариант замены докера, как и snapd.

замена заменой ... но действий надо больше выполнить .

Чем зоопарк с чрутами =)

Удивлю наверно, правильно написанный bash script, и не какого зоопарка с chroot, и с другими типами контейнеров.

Удивлю наверно, правильно написанный bash script, и не какого зоопарка с chroot, и с другими типами контейнеров.

Теперь сравни баш скрипт и докерфайл по сложности

замена заменой ... но действий надо больше выполнить .

Зачем? Если ci cd настроен?

Зачем? Если ci cd настроен?

Да большая часть ci/cd завязана на докер

Теперь сравни баш скрипт и докерфайл по сложности

Может bash проще окажется, плюс он полностью тюринг. В докерфайле же всеравно команды bash используются.

И уровень "специалистов" проверяется сразу если они в микросервис с 1000 строк кода тащат лютое ООП.

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

Да большая часть ci/cd завязана на докер

Нет.

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

Беда в том что прокидывают лишние прослойки, хотя начинать строить по патерну это антипатерн. :)

понимаю неприязнь к излишне абстрактному коду, но с другой стороны говнокод в один файл, который под еще разгребать другим людям — куда большее зло

минимальные абстракции должны быть, сейчас по примеру с Evrone в основном пишем

https://www.youtube.com/watch?v=V6lQG6d5LgU

https://github.com/evrone/go-clean-template

Может bash проще окажется, плюс он полностью тюринг. В докерфайле же всеравно команды bash используются.

Какой же там такой тюнинг есть который не даст докер ? Я конечно понимаю что баш это круто . с тем же успехом можно в контейнеры и с питоном играться

понимаю неприязнь к излишне абстрактному коду, но с другой стороны говнокод в один файл, который под еще разгребать другим людям — куда большее зло

Не стоит путать структурирование и отсутствие ООП. Существуют и функциональные подходы, и разные способы декомпозиции и организации.

Какой же там такой тюнинг есть который не даст докер ? Я конечно понимаю что баш это круто . с тем же успехом можно в контейнеры и с питоном играться

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

я бы ставил на постепенное вытеснение php, nodejs, смерть ruby

Python nodejs почему упадут?

https://www.youtube.com/watch?v=V6lQG6d5LgU

Они сами полгода пытались понять где у них что. :) А потом еще кто-то будет полгода разбирать их хитровыверты с интерфейсами. :)

Какие хитровыверты? Интерфейсы на вход — вообще часть Uber styleguide

3 слоя абстракции — это много что ли?

Какие хитровыверты? Интерфейсы на вход — вообще часть Uber styleguide

:) Ага, специально на типизированом языке уйти от типа. Гугл какбы намекнул не создавая тип Class... :)

3 слоя абстракции — это много что ли?

Для микросервиса скорее всего да.

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

:) Ага, специально на типизированом языке уйти от типа. Гугл какбы намекнул не создавая тип Class... :)

холодное с мягким путаете, интефейсы (не пустые) — это не уход от типизации

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

А если писать на функциональном подходе, тоже когда все привыкнут будет профит. :)

А если писать на функциональном подходе, тоже когда все привыкнут будет профит. :)

Главное чтобы понимали зачем вам ФП. Вам он зачем?

Главное чтобы понимали зачем вам ФП. Вам он зачем?

За тем что и ООП, разные инструменты, патерны, подходы.

Главный принцип ФП — неизменяемость данных, нужен для безопасного concurrency

И только джависты почемуто уверенны что только их подход единственно верный.

для безопасного concurrency есть ряд инструментов, почему вам нужен именно ФП?

Главный принцип ФП — неизменяемость данных, нужен для безопасного concurrency

А концепция чистой функции и тп.?

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

А вот оно что, пишите свои контейнеры на питоне а лучше С , а у моя жизнь слишком коротка

А вот оно что, пишите свои контейнеры на питоне а лучше С , а у моя жизнь слишком коротка

Зачем, есть готовые решения под задачи. Контейнеризаций много.

А концепция чистой функции и тп.?

это уже побочное следствие требования к неизменямости входных данных

которое в свою очередь нужно для безопасности

Зачем, есть готовые решения под задачи. Контейнеризаций много.

дак вы баш предлагаете =) а там половина команд это обертки для вызовов пары функций ядра

дак вы баш предлагаете =) а там половина команд это обертки для вызовов пары функций ядра

Я нечего не предлагаю. По ситуации, иногда скрипт на баше быстрее и надежней компилит и обеспечивает доставку и запуск. Иногда Ansible например. Иногда Fabric на python. Не нужен везде докер...

для безопасного concurrency есть ряд инструментов, почему вам нужен именно ФП?

Иногда и рекурсия лучше цикла что рискует стать вечным, а стек закончится. :) И т.п.

И я вовсе не ругал Docker или Java или ООП, но они не единственное решение...

А где-то лучше asm, а где-то лучше то, а где-то лучше по грибы ходить, а не заниматься ерундой. Об этом разговор?

контейнеры, SOLID и прочие вещи придуманы понятно для чего и используются понятно для чего. Если есть желание обсуждать то как можно без них жить — ок

но кому надо используют, и понимают для чего и почему

А где-то лучше asm, а где-то лучше то, а где-то лучше по грибы ходить, а не заниматься ерундой. Об этом разговор?

С моей стороны о том, что Go достаточно гибкий язык чтоб не превращать его в Java, компилить его в нативный toolchain и доставлять исполняемым файлом а не докером и т.п.

контейнеры, SOLID и прочие вещи придуманы понятно для чего и используются понятно для чего. Если есть желание обсуждать то как можно без них жить — ок

Для архитектуры вроде изначально. Их понимание со временем сильно менялось и т.п. Я застал как в 2000х считалось правильно все от всего наследовать. Щас за такое побьют, типа зацепленость и т.п. В джаве сами ушли со спрингом от нормального rich domain model к simple domain model, и сами не заметили например. :)

МММ — мы можем многое. Обычно помимо Go на платформах еще несколько технологий + *баться с автоскейлом, observability и тд не очень хочется

но кому надо используют, и понимают для чего и почему

Используют да, а вот видится картина что большинсто не понимает зачем. :)

вот за что по рукам нужно бить — это MSA без надобности

все пошли на микросервисы, не объяснив а зачем собственно

все пошли на микросервисы, не объяснив а зачем собственно

Ага, размыли и изничтожили кеширование, получили сетевые задержки и т.п. И не понимают зачем. А потом у них "тормазит". :)

Решили что из теоремы CAP им потребовалась partition tolerance (зачем?), модель согласованности просто забывают (ну там по сетке типа что-то ходит), начинают тратить время разработчиков на инфраструктурные задачи и код ради кода, вместо бизнес-логики. Я такое наблюдал в рамках CV-driven development, когда чел в небольших компаниях начинает пилить MSA с прицелом на то, как будет интервьюверу рассказывать про опыт работы с "микросервисами"

люди разучились ценить здравую лень. я бы вместо того, чтобы пилить MSA, фильм хороший бы посмотрел или книгу почитал

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

вчера вы принимали интерфейс на вход, который у вас локально ходил в базу — теперь это клиент, который по сетке ходит куда-то там, кидает сообщение в шину — не суть

сам код от изменения имплементации не поменялся, меньше работы, профит

вчера вы принимали интерфейс на вход, который у вас локально ходил в базу — теперь это клиент, который по сетке ходит куда-то там, кидает сообщение в шину — не суть

а интерфейс на вход остался

я думал микросервисы это такой способ масштабироваться

вещь заразительная, мне когда на какое-то время нужно было вернуться к python по задачам — я и там нашел интерфейсы

from typing import Protocol — часть стадартной либы оказывается

я думал микросервисы это такой способ масштабироваться

масштабироваться чему? Есть масштабирование разработки, есть масштабирование компонентов вашей системы — с последним, если нет серьезных накладных расходов (которые будут например на Java), ничто не мешает масштабировать от нагрузки и монолит

просто если у вас обычно уже есть нагрузка — значит есть и процесс разработки с кучей людей

from typing import Protocol — часть стадартной либы оказывается

Не знал, гляну.

👣 Подробное руководство по тестированию в Go Вы начнете с простой функции тестирования и поработаете с другими инструментами и стратегиями, которые помогут вам освоить тестирование в Go. ✅ Статья @Golang_google

Всем привет! Как в го выполнить выражение пришедшее в строковом виде?

Например 5+6

Всем привет! Как в го выполнить выражение пришедшее в строковом виде?

eval() в гошке нет, нужно писать самому

Спасибо, я не нашел тоже, думал может плохо искал

Всем привет! Как в го выполнить выражение пришедшее в строковом виде?

Никак. Го - компилируемый язык.

Никак. Го - компилируемый язык.

А это противоречит принципам?

А это противоречит принципам?

Да.

Ясно, спасибо

Для вычисления арифметических выражений (и даже функций) посмотрите тему "обратная польская запись".

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

Мне дали задание сделать самый простой калькулятор, который на вход принимал бы выражение a (+-*/) b и выдавал бы ответ на следующей строке, проблема в том что нужно все выражение писать в одной строке

всем привет можно ли в go считать строку с пробелами без использования bufio? (scanln не работает)

Мне дали задание сделать самый простой калькулятор, который на вход принимал бы выражение a (+-*/) b и выдавал бы ответ на следующей строке, проблема в том что нужно все выражение писать в одной строке

Это совершенно не проблема. Проблема - если это проблема. Начните с разработки алгоритма.

У вас в задании всего лишь два числа, разделенных всего лишь одним знаком действия. И всё. У вас даже нет произвольного выражения.

Да.

а что, есть принципиальные препятствия для создания compiler as a service?

в дотнете это есть 3й или 4й версии C#

а что, есть принципиальные препятствия для создания compiler as a service?

Не положено. В дотнете есть, эмиссия кода.