nozd up

1. Да, это нормально. Сильно легче код писать таким образом. (а иногда и читать, тк меньше слов дублируется. Например совершенно никакой ценности не несёт User user = userRepository.GetUserById(...) или многослойный женерик)

2.

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

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

Ты же не задаёшься вопросом, какой тип возвращает какой-нибудь GetUser, ToString, TryParse, FirstOrDefault?

Если тебе сложно понять смысл кода без типов - значит кто-то плохие имена дал переменным.

Данный код достаточно сложно разобрать человеку, который не писал это всё с нуля, а был присоединён через 4-5 лет ведения проекта.

Очень смелое заявление, которое мало чем подкреплено.

Как по мне, добавление возможности писать var вместо обычного типа было ужасной ошибкой Microsoft. Сам var был добавлен в язык вместе с анонимными типами и предназначался специально для них.

1. var далеко не только для анонимных типов полезен, хотя с анонимными типами без var работать было бы очень сложно.

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

Ну и помни ещё, что ты же не в блокноте код пишешь - у тебя есть всякие inlay hints, которые могут рядом с именем переменной показать её тип, а наведя мышку на слово - ты узнаёшь о нём все (имя переменной, сигнатуру метода, документацию, итд)

Вполне норм. Просто тип определяется справа, а не слева.
Подсказки ide должны решить вопрос понимания человеком, что там за тип.

Кто то счетает это хорошей идеей, как возможность связать все сервисы

Тем временем центральная идея микросервисов в том, чтобы связанность максимально снизить.

Клик сюда


Далее сюда


Подключаете .proto файл. После этого делает Rebuild вашего solution'а. Потом даблклик по проекту, в этом .csproj файле ищите секцию ItemGroup в которой будут ваши Protobuf. К ним додаёте аттрибут ProtoRoot, который (Для удобной работы) должен быть таким же как и пусть в аттрибуте Include без указания названия файла .proto

UPD:
Так же стоит отметить, чтобы импортировать в .proto ваш другой .proto, они должны быть хотя бы на одном уровне. Другими словами, вы можете импортировать только файлы, который находятся по архитектуре на том же уровне или ниже, потому что в import запрещено использования символа точки и запятой. Это значит, что вы не сможете выйти на уровень выше

За редкими исключениями ИП/СЗ - это либо галеры, либо временные сотрудники на малозначимых должностях. Так что вы этим сильно ограничиваете для себя рынок труда и ухудшаете условия труда.

Почему C# не кроссплатформенный?

На этот вопрос нельзя ответить сразу по двум причинам:
1. C# - это язык, а язык не может быть кросс-платформенным, так как платформы в разрезе языка и нет.
2. .NET уже много лет как кросс-платформенный.
Начиная с уже мейнстримного .NET 8, заканчивая mono и всякой экзотикой типа nano framework

но при этом, это не так

Ничто нельзя запустить на "чём угодно"

но в неё вопрос кроссплатформенности решена абсолютно полностью

Если вопрос "абсолютно полностью" решён, то почему я не могу запускать программы, написанные на Java, на любом железе?

Добрый вечер! Столкнулся с такой проблемой: Мне очень нравятся семейство языков Си, у меня есть выбор учить C++ либо C#, хочу разрабатывать ПО для ПК. Подумал начать с C++ и говорят что сначала поучить чистый СИ, а после переходить на C++, так что же из этого правильно? Надо ли учить Си? Или может лучше начать с C#, а дальше уже выучу C++?

Тема сравнения С/C++/C# в публичном пространстве - опасная тема. Она обычно заканчивается
топиком в 1000 страниц и великой войной всех против всех. Я видел много таких войн.
Они ничем не заканчиваются. Специалисты остаются при своих мнениях. А зритель просто развлекается.

Сам по себе выбор языка ставят только новички. Професиионалу безразличен язык (почти). Его может больше интересует отрасль, стек технологий, стандарты и протоколы. С моей точки зрения сегодня
таким стандартом может быть выбор облака (AWS, Azure, GCP).

Чистый СИ учить смысла нет. Учи сразу С++. Но даже его создатель Бьорн Страуструп считает что С++ это
сложный язык и он настаивает чтобы новички не брались учить все фичи сразу. Исключение по языку
СИ может быть в том случае, если ты собрался быть инженером по разработке микро-контроллеров
и у тебя скорее всего будет только СИ как основной (на 80-90%) инструмент взаимодействия с таким железом. Выйти на мидловый или синьорный уровень в С++ очень тяжело. Тяжелее чем в других языках.
Поэтому будь готов терпеть. Вот когда виски станут седые - тогда и будешь господин-синьор.

C# - это очень сильно корпоративный стандарт от Microsoft. Никакой связи с С++ он не имеет. Он конечно
внешне похож но это сходство обманчиво. Да изучать его тоже можно. Он учится легко. Существуют книги
вроде ".... C# за 14 дней". Разработка бизнес-приложений на шарпах идет гораздо быстрее чем на С++
например. И завалить систему в синий экран в этом языке гораздо труднее. В нем реализованы методы
защиты памяти и нельзя грязно трюкачить с указателями как это любят в С или С++. Производительность
шарпов в численных методах будет слабее чем в С++ но обычно бизнес не ставит таких задач и чаще
надо будет писать веб-хендлеры или хендлеры MQ-систем. Кач уровней синьорити идет быстрее в шарпах.

Уберите из docker-compose
"ports:
- "5400:5432"
и порт не будет публиковаться наружу, будет доступен только на внутреннем ip адресе вашего контейнера docker.
Для подключения или используйте внутренние имена контейнеров, или создайте отдельную подсеть docker (подсеть по умолчанию не дает выдавать контейнерам статические ip адреса) и переведите оба контейнера на ее использование с выдачей статических ip адресов.