Здравствуйте, kaa.python, Вы писали:
KP>Зачем нужен CLR если есть JVM? Набор библиотек для JVM сам по себе очень богат, нет необходимости <anything else>
Однако, "набор библиотек" распространяется как правило в исходниках (давайте не будем ля-ля об всеобъемлющей полноте чего-то типа maven central), потому вместе с Clojure давайте держать до кучи еще и 100500 мегабайт JDK вместо JRE. О, а еще "набор библиотек" надо собирать 100500 системами сборки — в компанию к JDK зело просим еще 100500 мегов Maven/Gradle, чтобы эти библиотеки собрать. И вот, наконец, "набор библиотек" можно как-то присобачить к Clojure — только теперь зачем он нам, если мы только что с ним притащили целый java и groovy разве что без Idea ?
Между тем, .NET не оставляет пространства для маневра — базовая поставка идет вместе с компиляторами C#/VB/F# и вместе с системой сборки MSBuild/XBuild, да она тоже 100500 вроде как, но тем не менее all-in-one — ничего лишнего, кроме одного базового дистра для "набор библиотек" к своему любимому .net-язычку типа Jython тащить не надо
Выбор в пользу JVM неочевиден, ничего не говорит в его "избранность" кроме ультимативных "исторически так сложилось"
Здравствуйте, Wolverrum, Вы писали:
W>Выбор в пользу JVM неочевиден, ничего не говорит в его "избранность" кроме ультимативных "исторически так сложилось"
По большому счёту — да. Преимущество JVM — это её везесущесть. Вряд ли найдёшь другую управляемую платформу, которая бегает более-менее на всём.
CLR как платформа выглядит более технически совершенным, но
1. Его кросс-платформенность была заторможена на почти 20 лет
2. Оптимизации JIT были заторможены на почти 20 лет.
В итоге, сейчас CLR представляет собой достаточно интересную штуку, но все тапки уже разобраны.
Лично я подписался на доставку попкорна, т.к. крайне интересно посмотреть, что куда в итоге выстрелит. Дотнет показывает отличную динамику в последние пару-тройку лет, что может привлечь в него энтузиастов.
Но у жавы два десятка лет форы. Но за дотнетом стоит одна из самых богатых компаний в мире. В общем, я пока воздержусь делать ставки.
Если сам буду пилить какой-нибудь опенсорс, то, ясное дело на CLR .
В минуты бессонницы развлекаю себя идеями построения чисто-управляемой СУБД, которая бы бегала поверх memory-mapped files. Как делают все промышленные СУБД, кроме всякого java-отстоя, который massively parallel slowpoke.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, varenikAA, Вы писали:
AA>Когда читаешь рекламу Clojure, а впрочем и других языков, может сложиться ложное впечатление, AA>что они привносят много нового. Еще Clojure часто позиционируется как полноценный CL. AA>Да, можно допустить, что Clojure визуально более выразителен(особенно с подсветкой синтакса), но при этом многие крутые вещи из него исчезли.
CL – перегруженный функционалом монстр. В Clojure просто не вносили того, что плохо ложиться на JVM, либо излишне усложняет язык. И вышло, как мне кажется, просто шикарно.
AA>Но проходят годы, а язык так и существует в жвм(плюс интероп в JS). Как будто ЖВМ реально имеет какое-то преимущество.
Зачем нужен CLR если есть JVM? Набор библиотек для JVM сам по себе очень богат, нет необходимости в еще одной платформе, которая до кучи долгие годы была гвоздями прибита к одной ОС. Ну а нативная сборка... есть предположение что кому-то понадобится LISP компилируемый в нативный код (такой есть, кстати)? Итого: JVM хватает для вообще всего, у этой платформы же только один недостаток реальный – медленный старт.
Здравствуйте, Sinclair, Вы писали:
S>Если сам буду пилить какой-нибудь опенсорс, то, ясное дело на CLR . S>В минуты бессонницы развлекаю себя идеями построения чисто-управляемой СУБД, которая бы бегала поверх memory-mapped files.
AA>что они привносят много нового. Еще Clojure часто позиционируется как полноценный CL. AA>Однако, в Clojure много чего нет — сигналов, перезапусков,
Что это?
AA>обобщенного формата данных
Все используют edn и не парятся
AA>Но проходят годы, а язык так и существует в жвм(плюс интероп в JS). Как будто ЖВМ реально имеет какое-то преимущество.
Оно реально имеет преимущество: он есть чуть менее, чем везде. На JVM есть чуть менее, чем всё.
Здравствуйте, kaa.python, Вы писали:
НС>>>>Опыт всегда однобок. KP>>>Зависит сильно. НС>>Не зависит. KP>Откуда дровишки?
Из формальной логики. Опыт не будет однобок только если он покрывает 100% всего происходящего.
НС>>>>Вопрос в том почему Джо неуловим. Неспроста ведь? KP>>>Конечно неспроста. .NET мало полезная и не предсказуемая штука за пределами экосистемы Windows. НС>>Это тоже на основании личного опыта вывел? KP>Еще лучше, на основании статистики бэкендов для языков.
Какой статистики?
KP> Ради интереса глянь на языки полноценно работающие на .NET не от МС и подумай почему их вобщем-то нет
Причин может быть много. К примеру, из-за того что родная java очень долго была убога стараниями Гослинга, а сейчас все равно развивается черепашьими темпами из-за неповоротливости JCP или что там сейчас вместо него.
А вот конкурировать с шарпом, где сочетаются высокопрофессиональный design team и изрядное количество ресурсов — крайне сложно, язык должен быть чем то из ряда вон чтобы заинтересовать профессиональное коммьюнити.
НС>>А вот конкурировать с шарпом, где сочетаются высокопрофессиональный design team и изрядное количество ресурсов — крайне сложно
ARK>Прогиб засчитан. Шарп весьма прямолинейный язык, предназначенный для энтерпрайз-быдлокода, Java с синтаксическим сахаром по большому счету. Какая у него может быть "конкуренция" с той же Scala? Это вообще разные миры.
Именно. Потому что судя по всему, главный способ развития чего-либо на Скала проходит путь от «как офигенно и много чего» до «вот же убогое невменяемое переусложеннное говно» в срок от примерно полугода до двух лет. После чего люди бегут в любые другие проекты, как от огня.
ARK>Да и те же Groovy/Clojure/Ceylon — они тоже про другое.
Про что, интересно? Особенно невидимые даже в микроскоп груви (он вообще где-то кроме gradle применяется?) и ceylon.
ARK>Не в конкуренции дело, просто ЦЛР от Микрософта, известного своей страстью к постоянной смене технологий, в качестве надежной базы для создания языков никому нафиг не упал.
Когда читаешь рекламу Clojure, а впрочем и других языков, может сложиться ложное впечатление,
что они привносят много нового. Еще Clojure часто позиционируется как полноценный CL.
Однако, в Clojure много чего нет — сигналов, перезапусков,
обобщенного формата данных(родной формат CL в который можно сохранять программу и загружать в исполняемый образ без преобразований).
Теже хеш-мапы были в CL всегда, просто запись была несколько иной.
Да, можно допустить, что Clojure визуально более выразителен(особенно с подсветкой синтакса), но при этом многие крутые вещи из него исчезли.
Вообще, заметил, что многие языки хостятся на jvm, но на страницах проектов, часто публикуется и возможность(сейчас или позже) в натив, CLR и т.п.
Но проходят годы, а язык так и существует в жвм(плюс интероп в JS). Как будто ЖВМ реально имеет какое-то преимущество.
Здравствуйте, AlexRK, Вы писали:
ARK>Между .NET и .NET Core прошло 14 лет. Не так уж много по языковым меркам. Теперь все, старый фреймворк задепрекейчен, хе-хе, велком ту дивный новый мир Core. Еще лет на десяток, а там микрософт задепрекейтит и его в пользу еще более крутого .NET HardCore. ARK>JVM же уже существует 25 лет
Ты намеренно путаешь фреймворк и рантайм или действительно не понимаешь? В Java точно так же давным давно похоронили старые коллекции, AWT, старый I/O и т.д. В CLR происходит точно такой же процесс, просто решили ввести некий явный водораздел. При этом есть .NET Standard, обеспечивающий плавную миграцию со старых либ на новые.
Здравствуйте, Wolverrum, Вы писали:
W>Однако, "набор библиотек" распространяется как правило в исходниках (давайте не будем ля-ля об всеобъемлющей полноте чего-то типа maven central), потому вместе с Clojure давайте держать до кучи еще и 100500 мегабайт JDK вместо JRE. О, а еще "набор библиотек" надо собирать 100500 системами сборки — в компанию к JDK зело просим еще 100500 мегов Maven/Gradle, чтобы эти библиотеки собрать. И вот, наконец, "набор библиотек" можно как-то присобачить к Clojure — только теперь зачем он нам, если мы только что с ним притащили целый java и groovy разве что без Idea ?
Ну соберешь ты эти библиотеки один раз и всё. Это действительно видится какой-то большой проблемой? И да, есть вся Java, и приложение на Clojure зачастую имеет фрагменты на Java. Что вроде тоже нормально. Я серьезно не понимаю что тут не так, кроме "а у меня иначе обычно".
W>Между тем, .NET не оставляет пространства для маневра — базовая поставка идет вместе с компиляторами C#/VB/F# и вместе с системой сборки MSBuild/XBuild, да она тоже 100500 вроде как, но тем не менее all-in-one — ничего лишнего, кроме одного базового дистра для "набор библиотек" к своему любимому .net-язычку типа Jython тащить не надо
Между тем .NET очень долго время было не-кроссплатформенным решением и, насколько я вкурсе ситуации, сейчас .NET Core поддерживается далеко не всеми популярными сторонними библиотеками (может быть мои сведения устарели).
W>Выбор в пользу JVM неочевиден, ничего не говорит в его "избранность" кроме ультимативных "исторически так сложилось"
Если есть много кода на Java, то можно сильно упростить жизнь добавив Clojure. Брать для разработки сервисов с нуля JVM и/или .NET при наличии Go/Elixir не очень понятно зачем... но если реально нужно, то Clojure хотя бы очень простой и удобный язык, ничего похожего в экосистеме .NET нет по историческим причинам.
Здравствуйте, Sinclair, Вы писали:
W>>Выбор в пользу JVM неочевиден, ничего не говорит в его "избранность" кроме ультимативных "исторически так сложилось" S>По большому счёту — да. Преимущество JVM — это её везесущесть. Вряд ли найдёшь другую управляемую платформу, которая бегает более-менее на всём. S>CLR как платформа выглядит более технически совершенным, но
Если я правильно понял, создатель темы пишет о Common Lisp, а не о CLR.
Здравствуйте, varenikAA, Вы писали:
AA>Но проходят годы, а язык так и существует в жвм(плюс интероп в JS). Как будто ЖВМ реально имеет какое-то преимущество.
Не интероп, а компилятор из cljs в google closure js. Должно в теории хорошо бегать под Node.
Нахрена Clojure на JVM сделали свой сборщик с блекджеком, когда её преимущество- вызов java библиотек, и проще пользовать maven, я хз.
Люди очень разные бывают. Кому-то нравится использовать уже придуманные другими людьми языки, а кому-то нравится придумывать новые языки. Вторых заметно меньше, но вот автор кложуры один из них. Если бы все люди были одинаковые, то до чего же скучно было бы!
P.S. Ну, и CL — это Lisp-N, а вот кложура — Lisp1, что уже многое значит, что это далеко не одно и тоже
Здравствуйте, kaa.python, Вы писали:
KP>и, насколько я вкурсе ситуации, сейчас .NET Core поддерживается далеко не всеми популярными сторонними библиотеками (может быть мои сведения устарели).
Устарели. Сейчас скорее ты столкнешься с обратной ситуацией — какая то библиотека не поддерживает FW.
W>>Выбор в пользу JVM неочевиден, ничего не говорит в его "избранность" кроме ультимативных "исторически так сложилось"
KP>Если есть много кода на Java, то можно сильно упростить жизнь добавив Clojure.
А если много на дотнете?
KP> Брать для разработки сервисов с нуля JVM и/или .NET при наличии Go/Elixir не очень понятно зачем...
Экстремизм наше фсе?
KP> но если реально нужно, то Clojure хотя бы очень простой и удобный язык, ничего похожего в экосистеме .NET нет по историческим причинам.
Чем грузины лучше? Чем армяне.
Ну и есть же Clojure CLR, не?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это признание своей неправоты?
Скорее сочуствие к дотнетчикам.
НС>Опыт всегда однобок.
Зависит сильно.
НС>Вопрос в том почему Джо неуловим. Неспроста ведь?
Конечно неспроста. .NET мало полезная и не предсказуемая штука за пределами экосистемы Windows. Мало кому нужна в итоге, что бы в серьез заморачиваться поддержкой. Может лет через 10-15 что-то изменится, если в .NET Core не будет найден фатальный недостаток, в чем лично я сомневаюсь.
Здравствуйте, kaa.python, Вы писали:
НС>>Это признание своей неправоты? KP>Скорее сочуствие к дотнетчикам.
Бессодержательные ответы на сочувствие никак не похожи.
НС>>Опыт всегда однобок. KP>Зависит сильно.
Не зависит.
НС>>Вопрос в том почему Джо неуловим. Неспроста ведь? KP>Конечно неспроста. .NET мало полезная и не предсказуемая штука за пределами экосистемы Windows.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Опыт всегда однобок. KP>>Зависит сильно. НС>Не зависит.
Откуда дровишки?
НС>>>Вопрос в том почему Джо неуловим. Неспроста ведь? KP>>Конечно неспроста. .NET мало полезная и не предсказуемая штука за пределами экосистемы Windows.
НС>Это тоже на основании личного опыта вывел?
Еще лучше, на основании статистики бэкендов для языков. Ради интереса глянь на языки полноценно работающие на .NET не от МС и подумай почему их вобщем-то нет, а так же почему их гора на базе JVM и LLVM.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А вот конкурировать с шарпом, где сочетаются высокопрофессиональный design team и изрядное количество ресурсов — крайне сложно
Прогиб засчитан. Шарп весьма прямолинейный язык, предназначенный для энтерпрайз-быдлокода, Java с синтаксическим сахаром по большому счету. Какая у него может быть "конкуренция" с той же Scala? Это вообще разные миры. Да и те же Groovy/Clojure/Ceylon — они тоже про другое. Не в конкуренции дело, просто ЦЛР от Микрософта, известного своей страстью к постоянной смене технологий, в качестве надежной базы для создания языков никому нафиг не упал.
НС>язык должен быть чем то из ряда вон чтобы заинтересовать профессиональное коммьюнити.
Всегда интересно послушать человека, которого уполномочило говорить от своего лица профессиональное коммьюнити.
W>Однако, "набор библиотек" распространяется как правило в исходниках (давайте не будем ля-ля об всеобъемлющей полноте чего-то типа maven central),
Почему не будем? Будем. Не видел ни одной Явы библиотеки, котороая распространялась бы только в исходниках. У тебя есть примеры?
W>потому вместе с Clojure давайте держать до кучи еще и 100500 мегабайт JDK вместо JRE.
А .Нет фрэймворк не надо держать? ЖДК ещё кстати простым копированием распространяется, поэтому у неё никогда конфликтов не случается ни с чем.
W> О, а еще "набор библиотек" надо собирать 100500 системами сборки — в компанию к JDK зело просим еще 100500 мегов Maven/Gradle, чтобы эти библиотеки собрать.
Брехня же. Мавен несколько мегабайт.
W>Выбор в пользу JVM неочевиден, ничего не говорит в его "избранность" кроме ультимативных "исторически так сложилось"
Здравствуйте, AlexRK, Вы писали:
ARK>Прогиб засчитан.
Не понимаю о чем ты.
ARK>Шарп весьма прямолинейный язык, предназначенный для энтерпрайз-быдлокода, Java с синтаксическим сахаром по большому счету.
И такой в подавляющем большинстве случаев и нужен.
ARK> Это вообще разные миры. Да и те же Groovy/Clojure/Ceylon — они тоже про другое. Не в конкуренции дело, просто ЦЛР от Микрософта, известного своей страстью к постоянной смене технологий, в качестве надежной базы для создания языков никому нафиг не упал.
Факты, правда, говорят о том что CLR более чем стабилен, но что нам до фактов.
НС>>язык должен быть чем то из ряда вон чтобы заинтересовать профессиональное коммьюнити. ARK>Всегда интересно послушать человека, которого уполномочило говорить от своего лица профессиональное коммьюнити.
Разумеется все написанное это ИМХО. К чему такой экзальтированный тон? В интернете кто то не прав?
Здравствуйте, Mamut, Вы писали:
M>Именно. Потому что судя по всему, главный способ развития чего-либо на Скала проходит путь от «как офигенно и много чего» до «вот же убогое невменяемое переусложеннное говно» в срок от примерно полугода до двух лет. После чего люди бегут в любые другие проекты, как от огня.
Ну, тем не менее, Скала нашла популярность в определенных кругах. Да я и не про это, а про то, что скала и шарп не конкурируют, это разные ниши.
ARK>>Да и те же Groovy/Clojure/Ceylon — они тоже про другое. M>Про что, интересно? Особенно невидимые даже в микроскоп груви (он вообще где-то кроме gradle применяется?) и ceylon.
Не про кровавый энтерпрайз уж точно (а шарп только про него). Кложура — это лисп для любителей тонких извращений, цейлон — экспериментальный язык с продвинутой системой типов. Груви да, помесь бульдога с носорогом.
ARK>>Не в конкуренции дело, просто ЦЛР от Микрософта, известного своей страстью к постоянной смене технологий, в качестве надежной базы для создания языков никому нафиг не упал. M>CLR не менялся больше времени, чем некоторые платформы, на которых существуют большинство языков и рантаймов. Главное препятствие было нормальной кроссплатформенности. С .net core вопрос с кроссплатформенностью отменяется.
Здравствуйте, AlexRK, Вы писали:
НС>>Факты, правда, говорят о том что CLR более чем стабилен, но что нам до фактов. ARK>Он же уже все, того, разве нет? Core CLR теперь же.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Факты, правда, говорят о том что CLR более чем стабилен, но что нам до фактов. ARK>>Он же уже все, того, разве нет? Core CLR теперь же.
НС>И что? Он перестал быть CLR?
Если ~100% обратной совместимости, как в JVM, нет (а ее, насколько мне известно, нет) — то перестал.
Здравствуйте, AlexRK, Вы писали:
ARK>Если ~100% обратной совместимости, как в JVM, нет
Именно в CLR — есть. Базовые библиотеки отличаются, поэтому используют .NET Standard. Cобранная под .NET Standard сборка гарантированно работает и на FW и на Core.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>Если ~100% обратной совместимости, как в JVM, нет
НС>Именно в CLR — есть. Базовые библиотеки отличаются, поэтому используют .NET Standard. Cобранная под .NET Standard сборка гарантированно работает и на FW и на Core.
Но старые приложения были написаны, когда Standard не было.
Здравствуйте, AlexRK, Вы писали:
НС>>Именно в CLR — есть. Базовые библиотеки отличаются, поэтому используют .NET Standard. Cобранная под .NET Standard сборка гарантированно работает и на FW и на Core. ARK>Но старые приложения были написаны, когда Standard не было.
И? Это не делает Core CLR несовместимым со старым.
Здравствуйте, Sinclair, Вы писали:
S>Дотнет показывает отличную динамику в последние пару-тройку лет, что может привлечь в него энтузиастов.
Я бы еще добавил в копилку CLR очень быстро набирающую популярность Azure, которая хоть и не привязана никак к CLR, но именно CLR имеет самую быструю и полную поддержку/документацию/тулинг для Azure. У Azure сейчас фактически только один конкурент — AWS (все остальные уже безнадежно отстали от этой парочки), но хоть AWS и является на данный момент лидером, разница с Azure сокращается очень быстро и уже несущественна. То есть Azure может стать дополнительным локомотивом для CLR
ARK>Между .NET и .NET Core прошло 14 лет. Не так уж много по языковым меркам. Теперь все, старый фреймворк задепрекейчен, хе-хе, велком ту дивный новый мир Core. Еще лет на десяток, а там микрософт задепрекейтит и его в пользу еще более крутого .NET HardCore.
Microsoft больше не занимается .NET Core. Развитием dotnet занимается отдельная некоммерческая организация .Net Foundation, в состав которой входят помимо Microsoft еще Google, Amazon, Red Hat, Samsung и т.д.
ARK>Ну, тем не менее, Скала нашла популярность в определенных кругах. ARK>Кложура — это лисп для любителей тонких извращений, цейлон — экспериментальный язык с продвинутой системой типов. Груви да, помесь бульдога с носорогом.
Ну то есть на JVM гора непонятных и мало кому нужных языков, но это выдается за большой плюс по сравнению с CLR
ARK>Между .NET и .NET Core прошло 14 лет. Не так уж много по языковым меркам. Теперь все, старый фреймворк задепрекейчен, хе-хе, велком ту дивный новый мир Core. Еще лет на десяток, а там микрософт задепрекейтит и его в пользу еще более крутого .NET HardCore.
Что ты несешь. .Net Core — это не новый фреймворк, не с нуля новая технология и т.п.
Здравствуйте, mrTwister, Вы писали:
T>но хоть AWS и является на данный момент лидером, разница с Azure сокращается очень быстро и уже несущественна.
Разница все таки пока очень существенна и не уверен что она сокращается, потому что AWS тоже хорошо растет.
Сейчас просто сам рынок в целом растет быстро, и место есть для всех, не только для сладкой парочки но и для всяких Гулей с Яндексами. Но рано или поздно рост замедлится и начнется веселье.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>Между .NET и .NET Core прошло 14 лет. Не так уж много по языковым меркам. Теперь все, старый фреймворк задепрекейчен, хе-хе, велком ту дивный новый мир Core. Еще лет на десяток, а там микрософт задепрекейтит и его в пользу еще более крутого .NET HardCore. ARK>>JVM же уже существует 25 лет
НС>Ты намеренно путаешь фреймворк и рантайм или действительно не понимаешь? В Java точно так же давным давно похоронили старые коллекции, AWT, старый I/O и т.д. В CLR происходит точно такой же процесс, просто решили ввести некий явный водораздел. При этом есть .NET Standard, обеспечивающий плавную миграцию со старых либ на новые.
А что, в рантайме никаких изменений нет? Ну ок, тогда "голый CLR" стабилен.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Разница все таки пока очень существенна и не уверен что она сокращается, потому что AWS тоже хорошо растет.
AWS растет, но я читал, что Azure растет в два раза быстрее, чем AWS
Здравствуйте, mrTwister, Вы писали:
НС>>Разница все таки пока очень существенна и не уверен что она сокращается, потому что AWS тоже хорошо растет. T>AWS растет, но я читал, что Azure растет в два раза быстрее, чем AWS
Ты на график то посмотри. Ажур отъедает рынок у мелких игроков,а доля AWS стабильна. Что будет когда мелкие игроки закончатся?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, mrTwister, Вы писали:
НС>>>Разница все таки пока очень существенна и не уверен что она сокращается, потому что AWS тоже хорошо растет. T>>AWS растет, но я читал, что Azure растет в два раза быстрее, чем AWS
НС>Ты на график то посмотри. Ажур отъедает рынок у мелких игроков,а доля AWS стабильна. Что будет когда мелкие игроки закончатся?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ты на график то посмотри. Ажур отъедает рынок у мелких игроков,а доля AWS стабильна. Что будет когда мелкие игроки закончатся?
Даже если и так, то почему клиенты (бывшие или потенциальные) мелких облачных провайдеров переходят чаще на azure, а не на aws?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, romangr, Вы писали:
R>>Орен Эйни уже давно пилит RavenDB на C#, как раз чисто-управляеиая СУБД (правда NoSQL).
НС>Антон скорее всего имеет в виду РСУБД.
Да. Вот, кстати, сейчас, в рамках форфан развлечений, пытаюсь решить простую инженерную задачу: получить из MemoryMappedFile какой-нибудь Span<byte>.
По факту на январь 2020 всё, что мы имеем — https://github.com/dotnet/corefx/issues/26603#issuecomment-574627184:
Sorry to be late to this, but it is not very clear to me from the above what is currently the recommended way to turn a MemoryMappedFile into a ReadOnlySequence<byte> (or ReadOnlySpan<byte>)?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.