В конце 22го был уже .NET 6. Который LTS. И я на нём строил сервер для приложения на основе gRPC/protobuf. Под линуксом, да. И работал он прекрасно, полностью выжимая канал. Без перерасходов памяти, без сильной нагрузки на cpu. Без дедлоков. Хотя я не пробовал никогда лезть в задиспоженый стрим. Это как-то странно.
По мотивам той системы я уже писал статью на хабре.
Так что не знаю. Похоже, у нас разные дотнеты, разные линуксы и разные gRPC.
Я не знаю, почему у вас не едет дотнет под линукс. Я давно и плотно работаю с gRPC и у меня всё прекрасно едет. Что дотнет, что линукс, что gRPC - технологии, отлаженные годами. И это мейнстрим. И я сильно сомневаюсь, что в их связке есть какие-то проблемы. И я сильно сомневаюсь, что Го намного быстрее. Скорее всего вы умалчиваете какой-то интересный факт, а может и не заметили что-то.
Хотя именно в .Net такую критику - что "вы не умеете его готовить" - по данной проблеме, встречаю постоянно)
Я вам то же самое скажу. Вы не умеете его готовить. Прекрасно работает под большими нагрузками. В том числе и под линуксом.
Вам бы неплохо было бы определиться с требованиями к системе. gRPC работает через протобуф, протобуф - через https. Последний работает через TCP. Угадайте, включен ли у него алгоритм Нагла? Спойлер - он включен у всех по умолчанию. Соответственно, у вас будут задержки, лишние буфферы, лишний расход цпу. Если вас задержки не устраивают, то у вас путь один - к TCP. Это не значит, что нельзя "обогащать пакеты". Можно и ещё как. Простую информацию можно встраивать прямо в пакет (ну кто запретит пару байт с флагами вписать?), сложную и несинхронную оставить на gRPC.
То есть вы взяли gRPC/protobuf, только чтобы кидаться бинарными пакетами по 320 байт? Странное решение.
Тут бы подошёл обычный советский TCP. Отключаем Nagle (NoDelay = true) и вперёд кидаться друг друга пакетами практически безлимитно.
Протобуф - он какбы не для этого. Это суровый сериализатор сложных структур. И он отлично и быстро работает. Но вам он зачем? Если нет структуры - не нужен и сериализатор.
бизнес-логика - это то, чем люди будут заниматься даже при отсутствии какой-либо вычислительной техники вообще;
Без вычислительной техники - возможно. Без схемы данных - неа.
Бизнес-логика просто ничего не сможет сделать без модели. У всех звёзд одни и те же параметны, но разные. Процент пишется одними и теми же цифрами по одному и тому же правилу, от такой же цифры слева от процента. И получится абсолютно прямоугольная таблица, только нарисованная ручкой.
Спасибо. Я для написания прошлой статьи делал систему, где всё наоборот. Была модель, а из неё делались entity классы и proto-файлы. Вот репозиторий. Туда я тоже джойнов не завёз, хотя в оригинальной системе они были.
Ну как зачем? Модель создана для того, чтобы зеркалиться в базу. Это её назначение. Если мы этого не делаем, то у нас DB-first и модель нам не нужна.
Чистая архитектура рекомендует писать бизнес-логику так, как удобно для бизнес-домена, а база висит где-то там, за интерфейсом.
Так model-first и не вступает в противоречие с DDD. Они вообще на разных уровнях. Model-first решает проблему поддержки консистентности структуры базы и кода. В вашем случае можно было бы использовать, ну назовём это "3d model first". Когда предметная область задаёт структуру данных, то есть модель, а из модель подтягивает структуру БД до истинной и генерит код.
Но, на мой взгляд, это как-то очень скучно и сухо.
Я предпочёл бы скучно, сухо и предсказуемо незабываемому и захватывающему дух приключению по поискам непонятной ошибки. Может старый стал. Теперь люблю, когда скучно.
<PublishAot>true</PublishAot> включает NativeAOT при публикации; <NativeLib>Shared</NativeLib> заставляет выпускать именно разделяемую библиотеку для C ABI; <SelfContained>true</SelfContained> собирает всё нужное внутрь, без внешнего .NET Runtime;
SelfContained не нужен в сборке Native AOT. Он просто ничего не делает там. При Native AOT всё и так собирается в один бинарь, никакого рантайма не требуется.
Я считаю, что не надо быть фаундером, чтобы разбираться в токсичности фаундеров. Хотя я тоже, в своём роде фаундер, аргументы в стиле "сперва добейся" вызывают некое отторжение.
Представим мысленный эксперимент. Мы уносим одну из запутанных частиц на край Вселенной, ждём тысячелетие, а затем проводим измерения. Результат не зависит ни от пройденного пути, ни от времени. Что перенеслось сквозь космос и эпохи? НЕ набор параметров, воздействующих на измерительный прибор, а сама идея того, что должно быть зафиксировано строго противоположное значение.
Здесь есть нюанс. Чтобы получить результат, нам нужно подождать, пока информация придёт с другого конца вселенной. А это никак не может быть быстрее скорости света.
Вот и как доказать, что на том конце суперпозиция рассыпалась? Может информация идёт к нам тоже в суперпозиции. И с тем спутанным атомом ничего не произошло. Его измерили прибором, прибор перешёл в состояние суперпозиции, затем лаборант перешёл в суперпозицию, затем отправил суперпозиционный сигнал.
И ничего от вашей частицы не переносилось никогда в другой конец вселенной, вы просто сами, вместе со своим прибором измерения перешли в состояние суперпозиции. И вас теперь двое, измеривших разный спин. И каждый из вас получит свой кусок сигнала с другого конца вселенной.
Вот да. В моей тулзе есть два разных грида с разным кодом. Но внешне они выглядят совершенно одинаково. И я не "сушу" их до одной кодовой базы, потому что они "чуть-чуть" разные.
Первому нужно ворочать миллионы строк не моргнув глазом. Второму нужно уметь биндиться к коллекции и уметь в разнотипные редакторы.
Если их пытаться наследовать друг от друга, то их фичи начнут перемножать сложность, это снизит надёжность каждого.
Это значит, что его структура и именования настолько ясны, что комментарии, объясняющие, что он делает, становятся излишними.
Каждое наименование класса, имя каждой переменной и каждого метода - это комментарии. С теми же недостатками: могут врать, устаревать или просто рассказывать не то, что надо.
Иногда таких комментариев хватает и нет необходимости писать `//`.
В конце 22го был уже .NET 6. Который LTS. И я на нём строил сервер для приложения на основе gRPC/protobuf. Под линуксом, да. И работал он прекрасно, полностью выжимая канал. Без перерасходов памяти, без сильной нагрузки на cpu. Без дедлоков. Хотя я не пробовал никогда лезть в задиспоженый стрим. Это как-то странно.
По мотивам той системы я уже писал статью на хабре.
Так что не знаю. Похоже, у нас разные дотнеты, разные линуксы и разные gRPC.
Я не знаю, почему у вас не едет дотнет под линукс. Я давно и плотно работаю с gRPC и у меня всё прекрасно едет. Что дотнет, что линукс, что gRPC - технологии, отлаженные годами. И это мейнстрим. И я сильно сомневаюсь, что в их связке есть какие-то проблемы. И я сильно сомневаюсь, что Го намного быстрее. Скорее всего вы умалчиваете какой-то интересный факт, а может и не заметили что-то.
Я вам то же самое скажу. Вы не умеете его готовить. Прекрасно работает под большими нагрузками. В том числе и под линуксом.
Вам бы неплохо было бы определиться с требованиями к системе. gRPC работает через протобуф, протобуф - через https. Последний работает через TCP. Угадайте, включен ли у него алгоритм Нагла? Спойлер - он включен у всех по умолчанию. Соответственно, у вас будут задержки, лишние буфферы, лишний расход цпу. Если вас задержки не устраивают, то у вас путь один - к TCP. Это не значит, что нельзя "обогащать пакеты". Можно и ещё как. Простую информацию можно встраивать прямо в пакет (ну кто запретит пару байт с флагами вписать?), сложную и несинхронную оставить на gRPC.
То есть вы взяли gRPC/protobuf, только чтобы кидаться бинарными пакетами по 320 байт? Странное решение.
Тут бы подошёл обычный советский TCP. Отключаем Nagle (NoDelay = true) и вперёд кидаться друг друга пакетами практически безлимитно.
Протобуф - он какбы не для этого. Это суровый сериализатор сложных структур. И он отлично и быстро работает. Но вам он зачем? Если нет структуры - не нужен и сериализатор.
А нафенгхуа в GPU RISC-V? Там же совсем другая архитектура, которая SIMD с рождения.
С этим тоже не ясно. 24 бита на пиксель - этим кого-то можно удивить? Или тут про то, что видеовыход умеет выдавать такой формат сигнала?
Именно. В итоге тоже ничего не выделяется, только нет дополнительной когнитивной нагрузки.
Только нужен очень специфический программист, который умеет работать именно с вашим No-Code.
По этим соображениям я сделал абсолютно серый интерфейс. Цветом выделяются только немногие детали, вроде курсора, ok/cancel, да и то неброско.
Скрытый текст
Без вычислительной техники - возможно. Без схемы данных - неа.
Бизнес-логика просто ничего не сможет сделать без модели. У всех звёзд одни и те же параметны, но разные. Процент пишется одними и теми же цифрами по одному и тому же правилу, от такой же цифры слева от процента. И получится абсолютно прямоугольная таблица, только нарисованная ручкой.
Спасибо. Я для написания прошлой статьи делал систему, где всё наоборот. Была модель, а из неё делались entity классы и proto-файлы. Вот репозиторий. Туда я тоже джойнов не завёз, хотя в оригинальной системе они были.
Ну как зачем? Модель создана для того, чтобы зеркалиться в базу. Это её назначение. Если мы этого не делаем, то у нас DB-first и модель нам не нужна.
Так model-first и не вступает в противоречие с DDD. Они вообще на разных уровнях. Model-first решает проблему поддержки консистентности структуры базы и кода. В вашем случае можно было бы использовать, ну назовём это "3d model first". Когда предметная область задаёт структуру данных, то есть модель, а из модель подтягивает структуру БД до истинной и генерит код.
Я всё ждал, когда появится креационизм. Ну этот самый, где про Господа нашего Б-га.
Потому что такой отменный антинаучный бред обычно предваряет религиозные догматы.
Я предпочёл бы скучно, сухо и предсказуемо незабываемому и захватывающему дух приключению по поискам непонятной ошибки. Может старый стал. Теперь люблю, когда скучно.
Я помню этот опрос. Я хотел его честно пройти, но в первом вопросе не было пункта "у меня нет веб-камеры" и я закрыл его.
SelfContained не нужен в сборке Native AOT. Он просто ничего не делает там. При Native AOT всё и так собирается в один бинарь, никакого рантайма не требуется.
Я считаю, что не надо быть фаундером, чтобы разбираться в токсичности фаундеров. Хотя я тоже, в своём роде фаундер, аргументы в стиле "сперва добейся" вызывают некое отторжение.
Я не понял, что такое "поле потенций", "секции поля различий" и "согласованная конфигурация смыслов". А это точно общепринятые термины?
Здесь есть нюанс. Чтобы получить результат, нам нужно подождать, пока информация придёт с другого конца вселенной. А это никак не может быть быстрее скорости света.
Вот и как доказать, что на том конце суперпозиция рассыпалась? Может информация идёт к нам тоже в суперпозиции. И с тем спутанным атомом ничего не произошло. Его измерили прибором, прибор перешёл в состояние суперпозиции, затем лаборант перешёл в суперпозицию, затем отправил суперпозиционный сигнал.
И ничего от вашей частицы не переносилось никогда в другой конец вселенной, вы просто сами, вместе со своим прибором измерения перешли в состояние суперпозиции. И вас теперь двое, измеривших разный спин. И каждый из вас получит свой кусок сигнала с другого конца вселенной.
Вот да. В моей тулзе есть два разных грида с разным кодом. Но внешне они выглядят совершенно одинаково. И я не "сушу" их до одной кодовой базы, потому что они "чуть-чуть" разные.
Первому нужно ворочать миллионы строк не моргнув глазом. Второму нужно уметь биндиться к коллекции и уметь в разнотипные редакторы.
Если их пытаться наследовать друг от друга, то их фичи начнут перемножать сложность, это снизит надёжность каждого.
Каждое наименование класса, имя каждой переменной и каждого метода - это комментарии. С теми же недостатками: могут врать, устаревать или просто рассказывать не то, что надо.
Иногда таких комментариев хватает и нет необходимости писать `//`.