nozd up

Вот вам перевод (часть первая, а всего там шесть частей) фундаменнтальной статьи по async/await одного из разрабочиков .NET в Microsoft (а именно - Stephen Toub).
Читайте и просвещайтесь.

PS Автор вопроса никак не желает считать текст выше ответом на свой вопрос - а зря. Потому что по-другому на форуме на него не ответишь - слишком много букв писать надо. Но сегодня - выходной, так что - попробую.
И самое главное, что вам следует осознать - что код асинхронного метода, который вы написали, и код машины состояний, в которой он преобразуется (и далее - транслируется в IL и компилируется в команды процессора) - это два разных кода, пусть и эквивалентных.
Если очень вкратце:

• компилятор преобразует код асинхронного метода до неузнаваемости, в ту самую "машину состояний": класс, в котором есть метод, ее реализующий, и есть поля для данных, как нужных для работы самой машины состояний (в частности - для хранения состояния), так и для хранения локальных переменных исходного метода (да-да, в стеке они не хранятся);
  
• каждый кусок исходного метода - начальный, между двумя await и завершающий - преобразуется в отдельный кусок метода машины состояний, выполняемый, когда выполнение машины состояний возобновляется в определенном состоянии; этот код производит действия, определенные в этом куске метода, и либо меняет состояние на новое значение и переходит к ожиданию (там, где в исходном асинхронном методе написан оператор await), либо завершает выполнение метода машины состояний;
  
• для выполнения перехода к ожиданию используется объект awaiter'а, получаемый методом GetAwaiter() операнда операции await;
  
• перед переходом к ожиданию проверяется возможно продолжение без ожидания, если это возможно (метод IsCompleted() awaiter'а возвращает true), то ожидания не происходит, а возобновляется выполнение машины состояний уже для нового состояния;
  
• запуск ожидания происходит во внешнем относительно асинхронного метода коде - в объекте awaiter'а;
  
• и при завершении метода машины состояний, и при запуске ожидания метод машины состояний возвращает управление в код, который вызвал в этот раз метод машины состояний (для одного вызова асинхронного метода вызовов метода машины состояний может быть много, см. дальше);
  
• первый возврат из метода машины состояний происходит в вызывающий метод, он возвращает объект задачи, позволяющий отследить в вызывающем методе завершение работы машины состояний ( и тут есть нюанс, связанный с возвращением ValueTask, а не Task);
  
• при окончательном (а не при запусе ожидания) выходе из метода машины состояний этот возвращенный объект задачи завершается;
  
• после завершения ожидания метод машины состояний вновь вызывается: в типичном случае - в свободном потоке из пула потоков, но возможны варианты (какие - курить тему Synchronization Context); и он продолжает свое выполнение для нового состояния
  

Это - максимально урезанное описание работы асинхронного метода.
Если вы смогли из этого описания понять ответ на ваш первый вопрос - хорошо. Если нет - читайте статьи(ссылка выше), или книги (лично я рекомендую главу про асинхронные меотоды из книги Рихтера "CLR via C#").
Касательно второго вопроса. Задачи, выполнение которых ожидает асинхронный метод, будут выполняться совершенно параллельно, каждая - в своем потоке из пула, возможно - на разных ядрах/процессорах). А асинхронный метод в это время не будет выполняться совсем: поток в котором он выполнялся, будет дальше выполнять код после его вызова в вызвавшем его методе (или код, возвращий поток в пул, если это был вызов машины состояний после ожидания). А после завершения обеих этих задач выполнение метода машины состояний, в который был преобразован асинхроннный метод, будет возобновлено и задача, которую возвратил асинхронный метод, будет завершена.

"Думал" - это такая же часть реализации, как и "писал", так что выделять отдельно её нет никакого смысла.

Другое дело, что если задача большая и непонятная, то её декомпозируют на "исследование", "проектирование", "мониторинг после деплоя" и т.п. И каждый такой этап - это, по сути, отдельная (атомарная) задача.

У нас при этом принято каждый день отмечать потраченное время в задачу и оставлять комментарий, если это время ушло на что-то необычное ("не работал сервер", "пошёл не по тому пути" и т.п.). Системно за этим никто не следит, но иногда такие комментарии помогают на ретроспективах/постмортемах или клиенту доказать, что перерасход по задаче был не по нашей вине (а потому что требования в процессе они меняли три раза и не могли два месяца выделить ресурсы) и его придётся оплатить.

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, на любом железе?