unsafePtr

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

public IActionResult Post(Model model)
{
    ThrowIfModelIsInvalid(model);

    return View();
}

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

У них все новые компоненты стараются писать на Rust. Статического анализатора для него ещё нету(имею ввиду PVS).

Думаете Intel и другие разработчики процессоров сразу же пересядут на Rust? Учитывая что программирование касаемо hardware довольно небезопасно, то сплошь и рядом придётся писать блоки unsafe кода.

Если память не изменяет то первым языком с поддержкой async/await был F#. Там толпа энтузиастов. Ну а компилятор преобразует это в CLR, и там это выглядит в виде машины состояния с двумя состояниями, и переход между ними выполняется с помощью goto оператора. Ну а в CLR самые узкие места написаны на C/C++.

Странно упомянуть async/await и не упомянуть родоначальника этого паттерна, а именно платформу .net

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

Нет, и как по мне чрезмерно переусложненно. Наверное имеет смысл в приложениях со сложными запросами. К примеру интернет-магазин со множеством фильтров

Затянул с ответом, отпуск.
В gRPC мы передаём все данные в бинарном формате, так гораздо эффективнее, для чего собственно proto формат и был создан. В javascript-e из браузера работать с ним от слова почти невозможно, собственно выходит нужно передавать в каком нибудь другом формате. Ну а дальше натыкаемся на ограниченность формата json и самого http протокола, и невозможность напрямую предоставить некоторые типы данных. Для этого даже был создан документ у них в репозитории.
Так что пока gRPC для меня выглядит как идеальное решение для межсервисной коммуникации. Ту а для веба видать пока что лучше swagger-a альтернативы нету.

Если честно, я бы просто хотел генерировать модельки описанные в IDL. Если задуматься, имея готовые модели, можно не заморачиваться со спецификой protobuf протокола, и возвращать обычный json из уже готовой модели(так как для json-a у них свои ). Ну а сервисы, можно будет самому написать, без gRPC. Ведь кому-то нужен REST, а имея на руках готовые модели мы точно знаем какой объект нам придёт, за разработчиком остаётся только определить входные точки(endpoint). Кстати, не пробовали ли вы thrift? Ну я нарыл на днях решение от майкрсофта, где есть дженерики. Они, между прочим, тоже решили следовать gRPC.

Одно но, он веб как бы не поддерживает. Есть костыли от сторонних разработчиков которые пытаются приспособить его к вебу, но если сам гугл не сделал такой поддержки, значит оно ему и не нужно. gRPC скорее больше нужен как межсервисная коммуникация. Кстати по опыту CLI protobuf-a просто ужасен.

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

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

Всё равно осадочек остался от того что протащили windows-only API. Лучше совсем без них, и для windows-a предоставлять их в виде отдельных nuget пакетов. В принципе это ещё не поздно исправить, но никто этим заниматься не будет. Сейчас у них цель, проапгредить и заоптимизировать сетевой стек.

ARG89 указал кого надог звать, ну я оставлю замечательную презентацию с прошлого dotnext отkekekeks

Всем советую, у кого есть готовая библиотека или какие-нибудь компоненты написать файл дефиниции типов(d.ts). Это позволит другим людям использовать вашу библиотеку в тайпскрипте, ну а если вы пользуетесь VisualStudio Code, так вы в придачу получаете intelisense, да же из javascript кода.

Статья банально уже просто не актуальна. У windstor есть проблемы с миграцией на .net standard. Было бы интересно увидеть пример с asp.net core.

Ну я бред конечно написал, имел ввиду разные файлы.

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

Для сравнения возьмите дженерики из c#, нету там всяких танцев с бубном.

Могу вспомнить как минимум resource файл в VisualStudio. Можно статично через диалоговое коно указать путь к файлу. IDE ещё на прекомпиляции проверит что такой файл существует и сгенерирует статичный класс. Очень удобно например вынести все sql файлы в такой ресурс, а потом в месте использования заявки написать что то вроде:

var result = await db.Query(SQLResources.GetProducts);

Попробуйте сменить сериализатор. Например. Хорошо так уменьшить потребеление памяти и быстродействие.

Замечания:
1. Зачем вам класс Thread? Используйте Task. И почитайте про асинхронность. Судя по вашему методу мейн, если при открытии конзоли вы не нажмете клавишу, то мы понапрасну будем есть очень много ресурсов.
2. Не знаю в какие дебри вы залезли с http, но его использовать будет гораздо проще(потому что это текстовый протокол, а не бинарный коим являеться tcp). Особенно если вы планируете веб приложение, вам надо делать ставку на http.
3. Было бы не плохо выложить ссылку на репозиторий с кодом. В таком соятоянии, я вообще не вижу кода на расте, а по c# вам надо прочитать style guide. Именование методов с подчеркиванием разве что в WinForms я и видел, которые уже устарели.

Что интересно, по факту есть всего несколько имплементаций под OWIN интерфейс а именно Kestrel и Katana(IIS). Может кто знает проекты или попытки написать свой сервер под OWIN?

Монго никогда не использовал. Но по коду, разве тут есть смысл указывать .ConfigureAwait(false)? Я это к тому что в ASP.NET Core это поведение по умолчанию. Источник

Разве что для тестирования в изолированном окружении.

Boxed должен иметь ограничение — where T: struct. Иначе можем в него запихнуть ссылочный тип.

70 тысяч звездочек на гитхабе

И всего лишь 2 issue. Вот так действительно пример хорошо сделанной библиотеки.

Почему бы не использовать стандартные Claims? Можно создать claim c типом permission, а значением будет Read, Write, Delete операции.

const будет конечно лучше, но это не спасет от изменения самого объекта. Лишь запретит изменнии ссылки на текущую перменную.

После такой статьи от души радуешся что ты c# програмист.

Было бы интересно увидеть обзор качестве звука на Spotify. Как никак самый популярный сервис для прослушивания музыки.

Я полез в репо автора, но к сожалению никакой статьи там не нашел. Никогда не видел в глаза Perl, просто интересно о чём статья.

Медицинская страховка в Болгарии обязательна. Даже если вы не работаете извольте раз в месяц перечислять определенную сумму по страховой. Она хоть и не большая, честно говоря не знаю даже сколько, так как мне её оплачивает работодатель. Если вы студент, то её вам оплачивает универ, подозреваю что со школами тоже самое.

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

Недавно была статья на хабре про сравнение async/await с корутинами го. Я не специалист, но заинтерисовало что такое корутины, и как они работают в Go. Если кто хорошо разбирается, возможно сможет улучшить статью, добавив в комментарии улучшунный код на го. Хочется понять с точки зрения асинхронности, когда лучше использовать корутины(то есть когда они будут быстрее). Сам лично набрел на пост в стековерфлоу, что хорошо спроектированное приложение, использующее потоки всегда будет быстрее файберов(именно они используется в основе корутин, если я правильно понял). Асинхронный код в c# писать легко, однако, если нужна будет скорость, можно запутатся во множестве деталей. Ну и поздравляю приверженцев Go с выходом новой версии.

Не факт, возможно кто то из счастливчиков нашел коллизию.

А что если попробовать Task заменить на ValueTask?

А куда выгодно податься одиночке? В какую страну?

First, FirstOrDefault, Single, SingleOrDefault очень хорошо улучшают читаемость кода. Согласен что надо искать компромисс между читаемостью и производительнотю, и шарпам это очень хорошо удаётся. Кстати говоря, если метод не обязательно должен быть исполнен мы можем воспользоваться элвис оператором ?.

По моему тема ушла в перекос о том как спастись/избавится/не использовать исключения. Я хотел показать лишь, что вместо использования object аргумента лучше всегда использовать generic, так как это спасает от упаковки.
Что касается самих исключений, то я придерживаюсь мнения, что исключения надо использовать только по необходимости, и где это возможно избегать. Это и в стандартной библиотеке встречается, например класс ReadOnlyCollection. Если вы его откроете и посмотрите на строку его объявления то увидите, что он наследует IList, у IList есть метод Add, однако ReadOnlyCollection, использует трюк который называется Explicit Interface Implementation. Получается вы защищены от вызова метода на инстанции класса, однако не защищены от вызова этого метода на интерфейсе.

IList<int> collection = new ReadOnlyCollection<int>(new int[] { 1, 2, 3 });
collection.Add(10); // throws exception