нужны подробности )

is_exists = true - присваивает ранее объявленной переменной is_exists := true - инициализирует новую. итого первая не используется

is_exists = true - присваивает ранее объявленной переменной is_exists := true - инициализирует новую. итого первая не используется

спасибо, уже понял )

но var is_exists = true - тоже создает новую

"К примеру, недавно я изучал проблему дженериков (generics), и пока что я не вижу в голове чёткой картины подробного и детального примера проблемы, для решения которой пользователям Go нужны дженерики. Как результат, я не могу чётко ответить на вопрос о возможном дизайне дженериков" Всё очень плохо, в общем

как посмотреть

как посмотреть

Я просто серьёзно не понимаю, что мешает им сделать дженерики так же, как это реализовано в C? Я не очень глубоко копал этот язык, конечно, но там всё достаточно стройно и понятно реализовано. Разве нет?

в каком С реализованы генерики?

в каком С реализованы генерики?

Видимо, что-то путаю

в C# есть, и весь современный C++ на темплейтах

а в C - нет

ну и в Java современной тоже есть

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

в C# есть, и весь современный C++ на темплейтах

Точно, я темплейты имел в виду

ну - это близкие, хоть и не тождественные понятия

так вот

про C# не знаю - я с ним дела не имел

С++ - это дно дна, возможности, глядя на чужой код, понять, что он делает нет никакой

С++ - это дно дна, возможности, глядя на чужой код, понять, что он делает нет никакой

это ты зря так

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

это ты зря так

последний мой подход к С++ связан с rtbkit. это настоящий С++ и насоящее дно дна

Не работал с этим( Я сейчас в kde пишу кое-какие штуки на плюсах, вполне всё нормально.

а

не, в гуях царство c++ до сих пор, где не царство ObjC

и куда JS не добрался

но бизнес-логика на крестах - это дно дна, точно говорю

но бизнес-логика на крестах - это дно дна, точно говорю

есть, мм, разные точки зрения на этот вопрос.

на любой вопрос есть разные точки зрения. но моя - такая

меня просто "точно говорю" покоробило.

почему?

мы много знаем продуктов с бизнес-логикой на плюсах?

(впрочем - нескоько знаем, да)

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

чет баз на c++ я не припомню

Монга, rethink, leveldb на вскидку

чет баз на c++ я не припомню

Clickhouse

Rocksdb

Соответственно и myrocks

leveldb на самом деле

На самом деле много в каких конторах есть много бизнеслогики на плюсах

Яндекс, гугл, фб где точно много

Дропбокс туда же

сунулся в код leveldb. там с++, но без темплейтов

каменный век :)

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

там где я видел C++ в активной разработке, всегда были жесткие гайдлайны, которые фактически заставляли людей пользоваться определенным подмножеством CPP.

и какой-нибудь местный патриарх сильно пушил остальных разработчиков следовать гайдлайну.

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

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

и какой-нибудь местный патриарх сильно пушил остальных разработчиков следовать гайдлайну.

иначе никак, да

но читабельно оно все одно не было

иначе оно превращается в неподдерживаемый код

но читабельно оно все одно не было

Дело привычки

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

Я из такого видел некоторые части буста и всё. Разный код смотрим видимо

да лааадно. я в жизни не писал на CPP, но не единожды вкапывался в код проекта чтобы понять как точно функционирует что-нибудь.

написать нечитаемый код на любом языке можно. на C++ несомненно легко.

написать нечитаемый код на любом языке можно. на C++ несомненно легко.

На перле легче

Я из такого видел некоторые части буста и всё. Разный код смотрим видимо

rtbkit. я до сих пор травмирован, а прошло два года

rtbkit. я до сих пор травмирован, а прошло два года

могу посоветовать хорошего гештальт-психотерапевта :) правда она в Москве.

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

но омерзение до сих пор со мной

но омерзение до сих пор со мной

Иногда полезно высказаться, чтобы травма прошла

Специалисту

тоже не считаю С++ чем то зубодробильным , по моему множественные связи рутин между собою (НАПИСАННЫЕ НЕ ТОБОЙ) гораздо труднее понять, чем C++ код ..... даже если использую thread , вызов будет сопровожден длинными подготовительными мероприятиями

тоже не считаю С++ чем то зубодробильным , по моему множественные связи рутин между собою (НАПИСАННЫЕ НЕ ТОБОЙ) гораздо труднее понять, чем C++ код ..... даже если использую thread , вызов будет сопровожден длинными подготовительными мероприятиями

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

а что за множественные связи рутин?

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

вот кстати. только плюсовики описывают протоколы в терминах наследования

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

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

Посмотри исходники какого нибудь питона, ты еще и не такого насмотришься

вот кстати. только плюсовики описывают протоколы в терминах наследования

Сильное заявление

а что за множественные связи рутин?

ну ... это если имеются оные .. если их нет то и связывать нечего

а ни у кого больше просто нет такого развитого наследования.

Посмотри исходники какого нибудь питона, ты еще и не такого насмотришься

Видел один проект

а ни у кого больше просто нет такого развитого наследования.

глядя на net.http я бы не стал говорить что все просто суммарно (56 файлов)

а?!

википедия пишет, чт еще множественное наследование есть в питоне. я-то питона не знаю

Ребят, хочу задать глупый вопрос. А как в микросервисной архитектуре гарантируется, что при изменении сервиса А не поломается взаимодействие с сервисом Б?

тестированием

автоматическим, в смысле

А на уровне языка как-то проверяют?

Типа завести внешний пакет с интерфейсами например

Или прям вот только автотесты?

я завожу внешний по отношению к обоим сервисам пакет

я код этот я генерю из swagger.yml

но это ничего не гарантирует - измениться может не интерфейс, а поведение

тестирование внутреннее ,может делаться средствами самого микросервиса, внешний контроль как уже описали выше

насколько я знаю когда сервисов много пишут монитор который занимается контролем WhoIShere только на предмет что сервис не упал "наглухо" каждый наделяет его своим "содержанием и умениями"

другое дело если разработчик сервисов не один человек.... и даже не одна комманда, тогда только СЕТЕВОЙ снифинг (но это чисто только мое мнение, может у кого то и есть решения по мониторингу сервисов без внедрения в код)

а почему без внедрения-то?

логи пишем, метрики собираем

а почему без внедрения-то?

ну а вдруг человек спрашивает о микросервисах к коду которых нет доступа

только исполнимый файл

и сказали " не дай бог упадет наш микросервис"

человек должен ответить "спасибо, досвиданья"

человек должен ответить "спасибо, досвиданья"

?

вообще конечно интереесно когда разработка большого продукта ведется несколькими командами особенно 1 микросервис и переход на 2 микросервиса

ну - регламенты, кодревью, автотесты и wtf-wtf-wtf

ну - регламенты, кодревью, автотесты и wtf-wtf-wtf

да там ..... бедные тимлиды "тонут" в болтовне

когда это 3-й микросервис .... то уже все регламенты разработаны

у меня мало опыта коллективной разработки ... поэтому мне это интересно ?

а других наверно "задолбало"