В мире .NET все прекрасно — платформа движется в правильном направлении, новые технологии обкатываются и встают на ноги. В последнее время много разговоров про .NET/ASP.NET Core, и кажется, что все забыли про Roslyn, который предоставляет широкие документированные возможности по работе с кодом как во время рантайма, так и в процессе разработки.
Чтобы исправить это, мы взяли интервью у Filip W, Microsoft MVP, контрибьютора Roslyn и просто одного из наиболее популярных в мире ASP.NET блоггеров. Почему Filip считает, что изменения в новом С# могут пройти незамеченными, зачем писать собственные анализаторы кода, а также почему скриптинг на C# лучше, чем любом скриптовом языке?
JUG.ru Group: Филип, давайте начнем с разогрева. ASP.NET Core сейчас сильно меняется. Как вы относитесь к происходящим переменам как разработчик, работающего с платформой?
Filip W: Конечно, первопроходцы испытали множество проблем: переносы сроков, ад с версионированием, смены названий, проблемы с инструментарием, непоследовательная система работы с проектами и много чего еще, вплоть до изменений самого концепта .NET Standard. Можно ли бы сделать лучше? Определенно да, впрочем ретроспективно все всегда выглядит просто и понятно.
Если же говорить в целом, совершенно точно изменения происходят к лучшему. Просто подумайте, несколько лет назад ASP.NET работал только под Windows и только под IIS. К тому же он основывался на System.Web.dll, который к каждому HTTP-запросу добавлял нелепый оверхед (29Kb в среднем). Сегодня же, ASP.NET Core, если верить бенчмаркам, входит в тройку-пятерку лучших по производительности веб-фреймворков на Linux. С этой точки зрения платформа бесспорно прошла невероятную трансформацию.
JUG.ru Group: То есть ты уже писал .NET приложения под Linux? Расскажи, как обстоят дела со стабильностью таких решений? Готова ли платформа к продакшену?
Filip W: Да, многие мои новые проекты сейчас крутятся в Docker на Debian-based системах. Я столкнулся с некоторыми проблемами с платформозависимым кодом, таким как криптография, или со странными дедлоками, возникающими тут и там, но в целом все меня устраивает. Ну и конечно, преимущества возможности управления всей платформой через Docker Swarm впечатляют.
На самом деле, мы у себя стараемся разрабатывать кроссплатформенный .NET код независимо от того, на какой ОС проект будет развертываться. Как результат, у большинства наших проектов есть билд-агенты для Windows, macOS и Linux. Таким образом, я могу разрабатывать что-то на своем Mac и иметь возможность развернуть это хоть в Docker, хоть в Azure Web App с гарантией того, что все будет корректно работать.
JUG.ru Group: Что насчет C#? В версии 7.0 у нас будут кортежи, pattern matching и много других фич. Будут ли эти нововведения полезны для тебя, как для разработчика?
Filip W: Вообще, как и в случае с C# 6.0, изменения незначительны, так что вполне вероятно, что многие разработчики в своей повседневной работе не заметят перехода на новую версию. Лично для меня точно полезными окажутся кортежи, поскольку в текущем виде они реализованы из рук вон плохо. Надеюсь, это поможет резко сократить количество вспомогательных классов, с которым мы сталкиваемся сейчас, когда для десериализации или чтения одного-двух полей из БД разработчик вынужден создавать новый класс.
Меня немного расстраивает, что синтаксис паттерн-матчинга не будет основан на expression-ах. Вместо этого будет акцент на is и switch, впрочем, я понимаю рациональность того, что нововведения приходят шаг за шагом. К тому же, более экспрессивные элементы помогают писать лаконичный код, а C#, как мы знаем, может быть очень «многословным», так что подобные изменения тоже к лучшему.
JUG.ru Group: На прошлом DotNext ты рассказывал о скриптинге под C#. Как по-твоему, доклад «зашел»? Востребован ли такой сценарий использования C# среди .NET-разработчиков?
Filip W: О, я получил невероятный отклик аудитории! Мне кажется, скриптинг – одна из наиболее классных сторон Roslyn, поскольку она открывает доступ к множеству интересных юзкейсов, недоступных ранее в экосистеме .NET. Конечно, раньше можно было пользоваться Powershell, однако возможность писать скрипты на C# – совсем другое, учитывая насколько он близок .NET-разработчикам. Сейчас можно наблюдать резкий рост использования скриптов на C# в коммерческих проектах: на них реализованы Azure Functions, расширения для игр и многое другое. Прибавить к этому языковые сервисы и поддержку intellisense/дебаггинга для C#, которые можно получить в каком-нибудь легком редакторе, типа VS Code, и вы получаете очень приятный процесс разработки. Забавно, что C#, будучи нескриптовым языком, получил настолько мощное окружение, что вряд ли какой-либо из скриптовых языков может поспорить с ним в плане продуктивности.
В Москве в дискуссионной зоне мы почти два часа обсуждали сложности и способы применения C# скриптов: для безопасности, управления памятью, расширения приложений (системы плагинов, основанные на скриптах) и даже удаленный REPL для управления исполняемыми процессами. Это было круто!
JUG.ru Group: Кроме скриптинга, ты занимаешься еще и статическим анализом кода. Расскажи, кому может понадобиться разработка собственного анализатора, учитывая, что на рынке есть VS и Resharper?
Filip W: Собственный анализатор обычно нужен тимлидам, которые занимаются code review и вообще отвечают за качество кода в команде. Здесь важно понимать, что в процессе разработки мы сталкивается с какими-то своими проблемами и шероховатостями, актуальными только в контексте нашего проекта. И Решарпер, и VS являются универсальными инструментами, рассчитанными на широкую аудиторию, но что делать, если вам надо обеспечить применение какого-либо конкретного паттерна или соответствие кода вашим корпоративным гайдлайнам? Например, установить правила именования классов/переменных, убедиться в том, что ваш внутренний API используется только так, как это задумывалось, что код документируется в соответствии с вашими стандартами, или что HTTP endpoints разрабатываются в соответствии с установленным стандартом. Иногда встречаются и странные вещи, – я как-то работал в проекте, где на уровне компилятора запрещалось использование табов и #region-директив.
Впрочем, даже если забыть о написании собственного анализатора, важно понимать, как они работают «под капотом». Как и в других областях программирования, даже если у вас руки не дойдут до написания своего анализатора, очень полезно понимать те принципы, которые лежать в их основе, а также как работает API компилятора, обеспечивая работу анализатора кода.
JUG.ru Group: Говоря о компиляторе, какие Roslyn Compiler API облегчили вашу жизнь по сравнению с предыдущим?
Filip W: Это вопрос с подвохом? По факту, старый компилятор не позволял делать ничего, кроме как скармливать ему код, а на выходе получать DLL/EXE файлы. Так что для меня наиболее важным в Roslyn стало то, что это настоящий Сompiler-as-a-Service, где каждый шаг пайплайна имеет внешний API, который можно использовать по-своему. Также удивительно то, что до Roslyn не было официальной C# AST библиотеки (можно было найти только сторонние варианты).
JUG.ru Group: Кстати, а что с обратной совместимостью? Какова вероятность, что мой самописный анализатор развалится при следующем релизе Roslyn?
Filip W: Ну, то, что команда Roslyn уделяет огромное внимание обратной совместимости, я знаю наверняка! Если копаться в коде компилятора, можно найти невероятные примеры этому. Например, если поискть в исходном коде компилятора, можно обнаружить строки «DELIBERATE SPEC VIOLATION». Что это? Выясняется, что код старого компилятора CSC, из-за багов или каких-то недопониманий, в некоторых местах нарушает спецификации C#. В то же время, команда Roslyn не планировала делать никаких изменений, способных что-то поломать, и таким образом мы получили новый компилятор, в некоторых местах которого разработчики сознательно нарушали спеку C# и документировали это как deliberate spec violation :) Ссылка.
Я понимаю, что обратная совместимость компилятора и его API это разные темы, однако мой пример хорошо показывает менталитет команды. Я и сам контрибьютил кое-что в Roslyn и могу сказать, что один из наиболее утомительных аспектов code review – это то количество внимания, которое уделяется разбору каждого «публичного» API – именно потому, что оно будет поддерживаться в Roslyn в течение длительного времени. Так что, если честно, я не переживал бы насчет обратной совместимости.
JUG.ru Group: Как ты вообще пришел к тому, что начал исследовать Roslyn API? Какие именно проблемы ты хотел решить изначально?
Filip W: Изначально я попал в сообщество Roslyn из-за работы со скриптами, мы делали проект Scriptics, один из тех проектов, которые помогли нам сформировать всю эту историю со скриптами на C# 10 лет спустя. Тогда я попал в проект OmniSharp, который добавляет intellisense и языковые сервисы C# в редакторы типа emacs, vim или Atom. Хотя конечно крупнейший и наиболее узнаваемый «потребитель» OmniSharp в .NET сообществе это Visual Studio Code. Там я и начал разработку инструментов для анализа кода, рефакторинга и многих других языковых фич уровня IDE.
JUG.ru Group: Скажи, что будет со статическим анализом кода в ближайшем будущем? Чего стоит ждать ближайшие 1-3-5 лет?
Filip W: Думаю, что мы увидим много «живых» диагностик. Josh Varty, один из моих друзей, построил крутейший аддон к Visual Studio под названием (сюрпиз!) Alive, который выполняет блоки вашего исходного кода и моментально сообщает вам, как будет работать ваш метода или ваш цикл, а также предупреждает об ошибках, которые могут произойти в рантайме. Это все находится за гранью статического или семантического анализа кода, все построено на базе Roslyn.
Так что в общем, на мой взгляд, мы столкнемся со все более продвинутыми аналитиками, такими как поиск ссылок на null через символьные вычисления. На данный момент сообщество пока еще просто разбирается с теми возможностями, которые дает Roslyn. Кроме того, я надеюсь увидеть более плотную интеграцию анализаторов Roslyn в сторонних инструментах, таких как OmniSharp или Resharper. Подобные анализаторы уже существуют для Visual Studio Code, но их работа пока далека от идеальной.
JUG.ru Group: Спасибо, Филип, до встречи на DotNext!
Filip выступит с докладом «Building code analysis tools with the .NET Compiler Platform (Roslyn)» на грядущей конференции в Петербурге, на одной сцене с Jon Skeet, Sasha Goldshtein и другими MVP. Подробности о спикерах и докладах доступны на сайте DotNext 2017 Piter
P.S. Напоминаем, что до конца февраля действует ранняя регистрация и пока можно зарегистрироваться, сэкономив пару тысяч.
Чтобы исправить это, мы взяли интервью у Filip W, Microsoft MVP, контрибьютора Roslyn и просто одного из наиболее популярных в мире ASP.NET блоггеров. Почему Filip считает, что изменения в новом С# могут пройти незамеченными, зачем писать собственные анализаторы кода, а также почему скриптинг на C# лучше, чем любом скриптовом языке?JUG.ru Group: Филип, давайте начнем с разогрева. ASP.NET Core сейчас сильно меняется. Как вы относитесь к происходящим переменам как разработчик, работающего с платформой?
Filip W: Конечно, первопроходцы испытали множество проблем: переносы сроков, ад с версионированием, смены названий, проблемы с инструментарием, непоследовательная система работы с проектами и много чего еще, вплоть до изменений самого концепта .NET Standard. Можно ли бы сделать лучше? Определенно да, впрочем ретроспективно все всегда выглядит просто и понятно.
Если же говорить в целом, совершенно точно изменения происходят к лучшему. Просто подумайте, несколько лет назад ASP.NET работал только под Windows и только под IIS. К тому же он основывался на System.Web.dll, который к каждому HTTP-запросу добавлял нелепый оверхед (29Kb в среднем). Сегодня же, ASP.NET Core, если верить бенчмаркам, входит в тройку-пятерку лучших по производительности веб-фреймворков на Linux. С этой точки зрения платформа бесспорно прошла невероятную трансформацию.
JUG.ru Group: То есть ты уже писал .NET приложения под Linux? Расскажи, как обстоят дела со стабильностью таких решений? Готова ли платформа к продакшену?
Filip W: Да, многие мои новые проекты сейчас крутятся в Docker на Debian-based системах. Я столкнулся с некоторыми проблемами с платформозависимым кодом, таким как криптография, или со странными дедлоками, возникающими тут и там, но в целом все меня устраивает. Ну и конечно, преимущества возможности управления всей платформой через Docker Swarm впечатляют.
На самом деле, мы у себя стараемся разрабатывать кроссплатформенный .NET код независимо от того, на какой ОС проект будет развертываться. Как результат, у большинства наших проектов есть билд-агенты для Windows, macOS и Linux. Таким образом, я могу разрабатывать что-то на своем Mac и иметь возможность развернуть это хоть в Docker, хоть в Azure Web App с гарантией того, что все будет корректно работать.
JUG.ru Group: Что насчет C#? В версии 7.0 у нас будут кортежи, pattern matching и много других фич. Будут ли эти нововведения полезны для тебя, как для разработчика?
Filip W: Вообще, как и в случае с C# 6.0, изменения незначительны, так что вполне вероятно, что многие разработчики в своей повседневной работе не заметят перехода на новую версию. Лично для меня точно полезными окажутся кортежи, поскольку в текущем виде они реализованы из рук вон плохо. Надеюсь, это поможет резко сократить количество вспомогательных классов, с которым мы сталкиваемся сейчас, когда для десериализации или чтения одного-двух полей из БД разработчик вынужден создавать новый класс.
Меня немного расстраивает, что синтаксис паттерн-матчинга не будет основан на expression-ах. Вместо этого будет акцент на is и switch, впрочем, я понимаю рациональность того, что нововведения приходят шаг за шагом. К тому же, более экспрессивные элементы помогают писать лаконичный код, а C#, как мы знаем, может быть очень «многословным», так что подобные изменения тоже к лучшему.
C# vs Powershell — 1:0
JUG.ru Group: На прошлом DotNext ты рассказывал о скриптинге под C#. Как по-твоему, доклад «зашел»? Востребован ли такой сценарий использования C# среди .NET-разработчиков?
Filip W: О, я получил невероятный отклик аудитории! Мне кажется, скриптинг – одна из наиболее классных сторон Roslyn, поскольку она открывает доступ к множеству интересных юзкейсов, недоступных ранее в экосистеме .NET. Конечно, раньше можно было пользоваться Powershell, однако возможность писать скрипты на C# – совсем другое, учитывая насколько он близок .NET-разработчикам. Сейчас можно наблюдать резкий рост использования скриптов на C# в коммерческих проектах: на них реализованы Azure Functions, расширения для игр и многое другое. Прибавить к этому языковые сервисы и поддержку intellisense/дебаггинга для C#, которые можно получить в каком-нибудь легком редакторе, типа VS Code, и вы получаете очень приятный процесс разработки. Забавно, что C#, будучи нескриптовым языком, получил настолько мощное окружение, что вряд ли какой-либо из скриптовых языков может поспорить с ним в плане продуктивности.
В Москве в дискуссионной зоне мы почти два часа обсуждали сложности и способы применения C# скриптов: для безопасности, управления памятью, расширения приложений (системы плагинов, основанные на скриптах) и даже удаленный REPL для управления исполняемыми процессами. Это было круто!
Разработка собственных инспекций кода под Roslyn
JUG.ru Group: Кроме скриптинга, ты занимаешься еще и статическим анализом кода. Расскажи, кому может понадобиться разработка собственного анализатора, учитывая, что на рынке есть VS и Resharper?
Filip W: Собственный анализатор обычно нужен тимлидам, которые занимаются code review и вообще отвечают за качество кода в команде. Здесь важно понимать, что в процессе разработки мы сталкивается с какими-то своими проблемами и шероховатостями, актуальными только в контексте нашего проекта. И Решарпер, и VS являются универсальными инструментами, рассчитанными на широкую аудиторию, но что делать, если вам надо обеспечить применение какого-либо конкретного паттерна или соответствие кода вашим корпоративным гайдлайнам? Например, установить правила именования классов/переменных, убедиться в том, что ваш внутренний API используется только так, как это задумывалось, что код документируется в соответствии с вашими стандартами, или что HTTP endpoints разрабатываются в соответствии с установленным стандартом. Иногда встречаются и странные вещи, – я как-то работал в проекте, где на уровне компилятора запрещалось использование табов и #region-директив.
Впрочем, даже если забыть о написании собственного анализатора, важно понимать, как они работают «под капотом». Как и в других областях программирования, даже если у вас руки не дойдут до написания своего анализатора, очень полезно понимать те принципы, которые лежать в их основе, а также как работает API компилятора, обеспечивая работу анализатора кода.
JUG.ru Group: Говоря о компиляторе, какие Roslyn Compiler API облегчили вашу жизнь по сравнению с предыдущим?
Filip W: Это вопрос с подвохом? По факту, старый компилятор не позволял делать ничего, кроме как скармливать ему код, а на выходе получать DLL/EXE файлы. Так что для меня наиболее важным в Roslyn стало то, что это настоящий Сompiler-as-a-Service, где каждый шаг пайплайна имеет внешний API, который можно использовать по-своему. Также удивительно то, что до Roslyn не было официальной C# AST библиотеки (можно было найти только сторонние варианты).
JUG.ru Group: Кстати, а что с обратной совместимостью? Какова вероятность, что мой самописный анализатор развалится при следующем релизе Roslyn?
Filip W: Ну, то, что команда Roslyn уделяет огромное внимание обратной совместимости, я знаю наверняка! Если копаться в коде компилятора, можно найти невероятные примеры этому. Например, если поискть в исходном коде компилятора, можно обнаружить строки «DELIBERATE SPEC VIOLATION». Что это? Выясняется, что код старого компилятора CSC, из-за багов или каких-то недопониманий, в некоторых местах нарушает спецификации C#. В то же время, команда Roslyn не планировала делать никаких изменений, способных что-то поломать, и таким образом мы получили новый компилятор, в некоторых местах которого разработчики сознательно нарушали спеку C# и документировали это как deliberate spec violation :) Ссылка.
Я понимаю, что обратная совместимость компилятора и его API это разные темы, однако мой пример хорошо показывает менталитет команды. Я и сам контрибьютил кое-что в Roslyn и могу сказать, что один из наиболее утомительных аспектов code review – это то количество внимания, которое уделяется разбору каждого «публичного» API – именно потому, что оно будет поддерживаться в Roslyn в течение длительного времени. Так что, если честно, я не переживал бы насчет обратной совместимости.
JUG.ru Group: Как ты вообще пришел к тому, что начал исследовать Roslyn API? Какие именно проблемы ты хотел решить изначально?
Filip W: Изначально я попал в сообщество Roslyn из-за работы со скриптами, мы делали проект Scriptics, один из тех проектов, которые помогли нам сформировать всю эту историю со скриптами на C# 10 лет спустя. Тогда я попал в проект OmniSharp, который добавляет intellisense и языковые сервисы C# в редакторы типа emacs, vim или Atom. Хотя конечно крупнейший и наиболее узнаваемый «потребитель» OmniSharp в .NET сообществе это Visual Studio Code. Там я и начал разработку инструментов для анализа кода, рефакторинга и многих других языковых фич уровня IDE.
JUG.ru Group: Скажи, что будет со статическим анализом кода в ближайшем будущем? Чего стоит ждать ближайшие 1-3-5 лет?
Filip W: Думаю, что мы увидим много «живых» диагностик. Josh Varty, один из моих друзей, построил крутейший аддон к Visual Studio под названием (сюрпиз!) Alive, который выполняет блоки вашего исходного кода и моментально сообщает вам, как будет работать ваш метода или ваш цикл, а также предупреждает об ошибках, которые могут произойти в рантайме. Это все находится за гранью статического или семантического анализа кода, все построено на базе Roslyn.
Так что в общем, на мой взгляд, мы столкнемся со все более продвинутыми аналитиками, такими как поиск ссылок на null через символьные вычисления. На данный момент сообщество пока еще просто разбирается с теми возможностями, которые дает Roslyn. Кроме того, я надеюсь увидеть более плотную интеграцию анализаторов Roslyn в сторонних инструментах, таких как OmniSharp или Resharper. Подобные анализаторы уже существуют для Visual Studio Code, но их работа пока далека от идеальной.
JUG.ru Group: Спасибо, Филип, до встречи на DotNext!
Filip выступит с докладом «Building code analysis tools with the .NET Compiler Platform (Roslyn)» на грядущей конференции в Петербурге, на одной сцене с Jon Skeet, Sasha Goldshtein и другими MVP. Подробности о спикерах и докладах доступны на сайте DotNext 2017 Piter
P.S. Напоминаем, что до конца февраля действует ранняя регистрация и пока можно зарегистрироваться, сэкономив пару тысяч.
Поделиться с друзьями
Комментарии (70)
mezastel
21.02.2017 10:43А куда делся плагин Alive? Компанию вроде купил МС, а плагин тихо выпилили с VS Gallery.
foto_shooter
21.02.2017 18:32+3Не так давно писал статью по использованию 'Roslyn', может кто пропустил, и кому-то будет интересно/полезно :)
Ссылка на статью
Tantrido
Nagg
Так и mono и .net core развиваются и берут друг у друга лучшее ;-)
Tantrido
Через ж… конечно делали: Java изначально кроссплатформенная и таких проблем не имела, а моно кучу лет допиливают и всё никак до вменяемого состояния не дойдёт. Может хоть с net core ситуация изменится.
Nagg
А т.е. я могу ее запустить даже на iOS?
Моно — это опенсорс, за которым не стояли гиганты вроде Microsoft, Oracle или Sun. Он развивался силами Xamarin с прицелом на мобильные платформы.
Tantrido
Это не претензия к моно — они молодцы, а проблема МС.
guai
с джейлбрэйком да
Nagg
ок, т.е. нельзя. Так и запишем.
guai
у вас вроде претензии к яве были, так вот ее на арме можно запускать. То, что одна конкретная фирма в своём оборудовании зарезало всё: яву-шмяву, рута, файловую систему, нормальные браузеры, кач и аплоад файлов, и т.д — ну так это разве проблемы явы?
Nagg
Если ява не запускается на платформе, которая приносит больше всего денег разработчикам — это именно проблема явы. Теоретическую кроссплатформенность оставим для производителей чайников.
guai
С чего это она теоретическая? Она вполне себе практическая, если б чудаки из эпла не старались зарубить всё, кроме своего платного xcode — вполне бы всё работало. но это уже их корпоративная политика.
даже с их постоянными частично успешными попытками зарубить джэйл, ява на ios есть.
или может оракл должен сам джейлбрэйки писать для айфонов, чтоб туда можно было пропихать яву?
или может вы мне свои критерии практической кроссплатформенности назовёте? с примерами, желательно
Nagg
Чудаки не чудаки, а раз на платформе крутятся основные деньги — надо под нее подстраиваться, пилить AOT/LLVM, интегрироваться хаками в xcode, интеропаться со существующими 3rd party на Obj C/Swift. Если всего этого нет — это проблема не эпла. Xamarin'у вот никто не помешал реализовать всё вышеперечисленное на этой платформе без всяких джейлбрейков. А на java какие-то попытки кроссплатформа/конверт кода появляются временами, но все какие-то жуткие hello-world недоделки.
guai
ну видимо, не настолько надо.
эти чудаки будут палки в колеса вставлять, а разрабы явы должны против ветра идти, чего ради?
поделия эпла в нишу явы тож никогда не попадут. видимо, такой паритет всех устраивает
kekekeks
Это не палки в колёса, это защита от персонажей, желающих на тяп-ляп сделать приложение, которое потом будет тормозить и жрать батарейку. И от желающих догружать код из интернета в обход ревью апстора. Отсюда и принудительный AOT без кодогенерации в рантайме.
guai
а ну да, нужно ж много батарейки под нативные демоны, которые ничего полезного не делают, не вырубаются, и жрут ее :)
areht
> Чудаки не чудаки, а раз на платформе крутятся основные деньги
А вы всерьёз можете привести ссылку, что (корпоративные) системы на Java приносят меньше денег, чем мобильные игрушки? )
ggrnd0
10 место в рейтинге отдачи статики!
jugru вообще совести не имеют.
Еще пару недель назад публиковали пост о 10 месте, которое всего лишь за статику — то есть мягко говоря этот рейтинг никому не инересен…
А уже сегодня пишут 3-5 место...
Razaz
Ну с EF пока толку мало тестировать как и ADO голый ибо сыроваты драйвера. JSON то же вопрос — так как сериализаторы на любой вкус есть. Плюс это все на Linux тестировалось. На Win серверах там повыше цифры — https://github.com/aspnet/benchmarks.
ggrnd0
jugru откровенно лгут о цифрах…
Не имеет особого значения, почему цифры такие, что там на винде и прочее…
Их заявления не соответствуют реальности. И с каждым разом из заявления все больше расходятся с реальностью....
ggrnd0
А если еще взглянуть на данные https://github.com/aspnet/benchmarks, то видно что .net уступает java/scala...
Netty (java) так и вообще вне конкуренции, рвет и .net и scala
Razaz
Эти бэнчи давно не обновлялись. Это пример разницы между Win и Linux платформой.
ggrnd0
Вы говорите, что на лине aspnetcore летает?
А мне все равно если aspnet стал быстрее aspnet, он все еще кратно проигрывает java...
Razaz
Я говорю что в абсолютном выражении на Винде он шустрее. Плюс latency забыли…
Razaz
Почему не соответствуют?
Только это Windows. А в целом вполне себе топ производительность.
ggrnd0
R/sec: 3,4 M/sec
T/sec: 432 Mb/sec
Почему вы считаете скорость отдачи пакетов размером в 125 байт?
Это что вы тестили? HTTP HEAD на кешированной в памяти статике?
Кому это инетересно???
Razaz
Вы тест видели который сравнивается?
Это то же TechEmpower.
Это показатель того, на сколько шустро работает рантайм + вебсервер.
Думаю многим это интересно, особенно в стадии гринфилд.
ggrnd0
Кто его будет без MVC использовать?
А с MVC (aspnetcore-mvc-linux) он становится неожиданно ужасно медленным...
aspnetcore-linux фактически libuv + coreclr.
То есть максимум натива, минимум managed кода…
Не релевантно же совсем...
Razaz
Я использую. Мне контроллеры не нужны. Только Middleware.
Забыли веб сервер :) Самую малость :D Managed там дофига. Только еще unsafe фигачат в полный рост.
Если бы не веб сервер — перевалило бы за 5 лямов :D
ARG89
На самом деле, есть нюанс. Filip специально указал, что речь о производительности фреймворков:
А в таблице сортировка идет по `platform` и `micro-framework`. Если смотреть на фреймворки, забыв о платформах, то получается честное третье место.
kekekeks
Там основной прирост не сколько от рантайма, сколько от нормальных веб-сервера и конвеера обработки запросов. На Mono тоже достаточно шустро работает.
Razaz
Это где там PHP? :) Вижу C, C++, C#, Go, Java, Scala.
Зачем Mono? CoreClr + CoreFx уже вполне нормально на Debian живут. В 2.0 довезут остатки основных апи и еще оптимизаций. Да и Мигель уже в МС :D
По поводу места хз — так как непонятно попал ли билд с PGO на Linux или нет. Может кто помнит и уточнит.
Tantrido
Да вижу. А ASP.NET MVC, WCF и т.п. когда будут работать? И что теперь моно будет ненужно, можно будет .Net Core из коробки использовать? Где можно популярно почитать?
Razaz
В топ 10 PHP нет на Plaintext. Базу смотреть бесполезно, так как там Npgsql.
А разве MVC не работает? Уже даже LTS релиз есть. WCF не будет больше развиваться в серверной части. Давно уже сказали.
Я уже использую без Mono.
https://docs.microsoft.com/en-us/aspnet/core/tutorials/your-first-mac-aspnet. Тут Mac, но это не принципиально.
Вся каша в так называемых Target Framework Monicker. Если вы напишите net462 — будет бинарник для обычного .Net. А если netcoreapp1.1 — то будете запускать через dotnet run и это работает на любом совместимом дистре.
Tantrido
Интересно! И что ASP.NET уже можно полностью в Linux-e делать? И MVC или MVC только в моно (только no async features supported)? В Visual Studio Code есть уже визуальный редактор для Web Forms или ещё нет?
Razaz
ASP.NET Core и MVC Core полностью работоспособны и живут на проде. 1.0 LTS релиз и 1.1 Current. Mono там никаким боком нет, так как используется CoreClr. WebForms не будет — зачем вам редактор визуальный? :)
Просто надо понимать — весь легаси выкинули, апи перетрясли и кучу всего переписали.
То есть WebForms, серверная часть WCF, ВебСервисы(которые asmx), HttpModule's все выкинуто.
Tantrido
Навсегда или со временем добавят? Или оно уже не нужно? Чем заменили?
Razaz
Странички это Razer View Engine в MVC. Либо просто SPA шаблон любой и Angular/React.
Я не видел редактора WebForms с 2009 года :D
Берёте Node.JS + Rails(еще кусочки Go типа Channels), переводите на C# и у вас .Net Core + Mvc Core.
1. WebForms только в legacy приложениях остались у тех, кто не переписал все на MVC.
2. WCF — ну как-то SOAP сейчас не сильно интересен :) Даже в Enterprise. REST, микросервисы и всякая подобная лабуда сейчас.
3. Это тем более труп еще как WCF вышел.
4. Middleware.
ASP.NET Core похож на классический только названием :)
Живет без IIS, а если и с ним, то IIS только как реверс прокси используется.
Tantrido
Я понял, благодарю! Будем изучать Razor.
SPA — это что? Можно попросить скинуть ссылочки на какой-нибудь мануал или туториал, пожалуйста?! Благодарю!В смысле?
Понятно, я просто думал, что в WCF есть REST, оказывается нет. Значит надо использовать всякие ServiceStack и ит.п.? Непонятно только почему ещё столько предложений работы с WCF.
Razaz
Single Page Application. Тоесть фронтенд у вас это js приложение, а бэк отдает данные.
http://asp.net-hacker.rocks/2016/09/19/aspnetcore-and-angular2-using-dotnetcli-and-vscode.html
MVC в момент своего появления очень многое взял от Ruby on Rails. Потом появился OWIN и Middleware, как в Node.JS. Go и Scala оказывают влияние на сам фреймворк(CoreFx). Например добавили каналы как в Go.
Тот кусочек(WebHttpBinding) постепенно отпочковался, переписался и обозвался WebApi :)
В классическом ASP.NET часто используется связка MVC + WebApi(2). В Core это безобразие свели в одно целое.
Если нужен просто формат SOAP — То форматтер накидать не проблема. Если начинается разговор про WS-Security, WS-Adressing и тд — то тут мимо.
Вакансии есть, так как огромное количество компаний имеют легаси код и/или просто боятся чего-то нового. Иногда просто пишут для галочки :)
Tantrido
Понятно, похоже, что Троелсен даже 7-й редакции сильно устарел :) А я думал его купить, теперь не буду. :) Спасибо большое!
Razaz
Да пожалуйста :) Просто благодаря Рослину фичи штампуют на раз. Я смотрю по репозиторию на гитхабе :D
Tantrido
Вот, что нужно брать: :)
«ASP.NET Core MVC с примерами на C# для профессионалов», Адам Фримен, (перевод Юрия Артёменко), бумага офсетная-белая, твердый переплет, 992 стр., ISBN 978-5-9908910-4-3, «ВИЛЬЯМС», 2017
Нашёл ещё хороший источник:
https://metanit.com/sharp/aspnet5/
Razaz
Годная ссылка. Даже RewriteMiddleware описали :)
nightwolf_du
В wcf есть REST-вариант службы. И работу чисто по http можно настроить.
Вроде бы, можно даже json-сериализацию прикрутить при отдаче ответов.
Просто wcf слишком тяжел, монструозен и сложно настраиваем для большинства программистов.
Ну и просто уже не модно.
Razaz
Зачем вам тогда WCF?
Это чрезмерная абстракция, заточенная на SOAP и RPC. REST сервисы там очень неудобно делать. Странно что в 2017 году про этот ахтунг все еще вспоминают при наличии WebApi :)
Tantrido
Блин, сколько за день полезного узнал! Спасибо! :)
Razaz
Всегда пожалуйста :)
nightwolf_du
Большой объем и частота обмена данными по сети между внутренними сервисами.
А серваков не так много.
Выручают фичи, о которых Encarmine написал ниже — бинарная сериализация и замыкание сервисов на одной машине через pipes.А для удобства использования теми, с кем обмен данными пожиже — конечные точки с удобными клиентам интерфейсами.
Да и для моих задач soap оказался удобнее.
Razaz
Ниже ему ответил.
Повторюсь еще раз — WCF для REST в 2017 году — это самое плохое, что можно посоветовать человеку.
Есть бинарные веб-сокеты, есть всякие NetMQ. Есть фигалион инструментов для решения конкретных задач.
И самое главное что WCF(серверная часть) не поедет на CoreClr.
Encarmine
Почему-то, когда про WCF говорят в контексте «не нужен», речь обычно идет про SOAP, wsdl и enterprise. Но ведь умеет не только это! Есть еще межпроцессный обмен на named pipes, есть двусторонний обмен данными по одному соединению, есть очень быстрая бинарная сериализация сообщений, есть обнаружение сервисов, ServiceRouting в конце-концов. Неужели
640кбhttp хватит всем?Razaz
1.Пайпы без WCF
2. Двусторонний обмен — WebSockets. На порядки более удобное и масштабируемое решение.
3. Бинарная сериализация не привязана к WCF.
4. Для Discovery есть много решений. Тот же NetMQ предлагает из коробки
5. Обычный роутер ;)
Вы приводите узкоспециализированные примеры использования WCF, но при этом защищаете эту чрезмерную абстракцию. Не проще просто использовать нужный инструмент для задачи?
Encarmine
1. Но зачем мне писать и поддерживать столько кода, дающего 0.0 value, если я могу просто в конфиге прописать нужный транспорт?
2. Забыли упомянуть, что оно не поддерживается подавляющим большинством клиентов;
3. Не отменяет того факта, что в WCF она есть;
4. WCF одно из множества решений, предлагающих discovery;
5. Скиньте доку где можно почитать про protocol bridging на обычном роутере?
Но это все неважно, я не утверждал что невозможно построить сервис на чем то другом, и отвечать на это не нужно. Мне просто печет от того, что на волне хайпа вокруг web-api незаслуженно забыли такое архитектурно-мощное решение. Если бы серверный WCF реализовали в .net core, он был быхорошим инструментом для любой задачи.
Razaz
1. Там кода минимум. Вы же не просто так используете пайпы. Наверняка производительности охота? А если нет, то нафиг вам пайпы?
2. Это какими? Либы под вебсокеты есть под любую мэйнстрим платформу.
3. И причем она тут тогда?
4. WS-Discovery если быть точнее.
5. Protocol Bridging в основном используется с SOAP. Без него самой проблемы не возникает.
Какой хайп? Хайпом это было в 2012. Меня печалит, что в 2017 году все еще есть разработчики, которые верят в универсальные инструменты для всех задач. Это фантастика из середины двухтысячных и какой-то бич .Net комьюнити. :) WCF это пример дикой необоснованной абстракции. Именно текучесть этой абстракции и привела к появлению WebApi, который, напомню от него же и отпочковался.
Encarmine
Я думаю мы ни к чему не придем, поэтому дискуссию сворачиваю. Но чисто для разминки моих мозгов, приведите мне сценарий который по вашему мнению WCF не сможет поддержать, или решение выдйет очевидно убогое.
Razaz
REST Maturity Model 3? :D
Нормальный роутинг? Например комбинации версионирования апи по заголовку/пути/query параметру?
Производительность даже обсуждать нечего.
При желании натянуть можно очень многое. На то она и абстракция всего надо всем. Мне приходилоссь и JWT токены в XML заворачивать и тд. С SAML-P вообще ахтунг. Но это все последствия одной текучей абстракции, которая не несет никакого профита, кроме как быстрый старт(типа веб формы в редакторе накидать, а потом е**сь оно конём). Как только надо кастомизировать — получается что проще и дешевле использовать специализированный инструмент, чем натягивать глаз на одно место. Да еще и производительнее будет.
Tantrido
2) Если ли в Net Core WinForms, настольные приложения или планируют? Или здесь только моно поможет?
Razaz
1. Туториал же для Mac:) https://github.com/dotnet/corefx — можете посмотреть билды для своей ОС.
2. Нет. Десктоп либо UWP(с AOT компиляцией даже) или Mono. Основной фокус CoreClr на серверные приложения сейчас.
Tantrido
1) Я имел в виду: как оно по скорости? Моно тормозил сильно особенно WinForms
2) В смысле? Оно будет на линуксе ли маке работать или только windows?Razaz
1. Серверные приложения норм. Как раз и обсуждали что они в топе сейчас.
2. UWP только Windows. Для остального там биндингов нарисовали в Mono вроде. Но тут не подскажу. Товарищ kekekeks возможно лучше в десктопной теме ориентируется :)
Tantrido
AvaloniaUI/Avalonia — A multi-platform .NET UI framework (formerly known as Perspex)? Жаль, что пока альфа.
kekekeks
Тут "альфа" — это скорее показатель того, что апи ещё может ощутимо меняться. В частности сейчас на рассмотрении висит рефакторинг виджетов верхнего уровня, переписывается стек отрисовки, практически наверняка будет меняться процедура инициализации. А в целом оно работает уже достаточно стабильно, более полутора тысяч тестов покрывают 60% кодовой базы.
В общем, если бы это делали в Microsoft, то обозвали бы бетой или даже rc1 (кавардак с тулингом .net core, я смотрю на тебя)
Tantrido
Короче учим XAML? :) Клон WPF — имеется в виду так же и АПИ, название виджетов или нет?
kekekeks
Апи во многом схож, но не повторяет 1 в 1 таковой из WPF. Так, иначе внутри устроены биндинги (активно используется RX), система смены визуальных состояний основана не на триггерах, а на селекторах, работающих с классами (назначаются значением атрибута каждому конкретному элементу) и псевдоклассами (примеры псевдоклассов:
:pressed, :pointerover`). В целом система стилей заимствует из идеологии CSS. Но в целом это всё тот же самый XAML с шаблонизорованными контролами и биндингами.Tantrido
At — это что? :)
kekekeks
С биндингами моновскими основная проблема в том, что они либо активно используют либо свои нативные врапперы, которрые надо собирать на целевой системе (GTK и вообще glib-based либы), либо гвоздями приколочены к моновскому рантайму и зависят от его кастомной сборки (xamarin.Mac). С At вообще всё грустно, биндинги вроде и есть, но я на deabian-based дистрах ни разу не видел, чтобы они из репозитория сами нормально работали. В итоге это всё счастье совершенно непригодно для использования с .NET Core. Мне тут с месяц назад с GTK3 пришлось через P/Invoke вручную взаимодействовать.
Tantrido
At — это что? :)
kekekeks
Это опечатка, должно было быть Qt
Tantrido
Понятно. Глянул в эту сторону: есть QtSharp, ещё пилят его хотя и не слишком активно, но поддержки .Net Core пока нет.
kekekeks
С Qt основная проблема в том, что оно не предоставляет пригодного для использования через P/Invoke C API. Соответственно, надо либо генерировать сишную обвязку (которую опять же надо собирать под целевую платформу), либо брать обвязку для скриптов SMOKE (подход, который используется «официальными» биндингами).