Интервью с Мигелем де Икасой: Microsoft, Mono, смартфоны и многое другое
У Мигеля де Икасы много заслуг в прошлом (создание GNOME, Mono, Xamarin и не только), но он не живёт былыми заслугами, а продолжает активно трудиться — теперь в компании Microsoft, отношения с которой когда-то были непростыми.
Поэтому на конференции DotNext мы задали ему вопросы и о том, и о другом:
О прошлом: зарождение Mono, взаимоотношения с Microsoft и так далее.
О настоящем: к чему это всё пришло? Как Мигель, ранее создавший Xamarin, смотрит на современную кроссплатформенную мобильную разработку? И чем он занят сейчас?
И теперь мы сделали для Хабра текстовую версию этого интервью.
Интервью брали Игорь Лабутин, разработчик на C# и архитектор, и Андрей Акиньшин (@DreamWalker), перформанс-лид Rider, мейнтейнер проекта BenchmarkDotNet.
Текст интервью и видео — под катом.
Mono и проблемы выбора
— Мигель, ты получил известность за создание инструментов типа Midnight Commander, GNOME, инструментов для мира Linux. Что побудило тебя размышлять над тем, как перенести .NET на Linux, с учетом того, что там уже была кроссплатформенная Java и, возможно, какие-то другие кроссплатформенные решения?
—Это отличный вопрос. Я уже сталкивался с ним, но вы добавили один интересный фактор: зачем было заниматься этим, если уже имелось решение, например, Java. Знаете, я смотрю на календарь, мне уже почти 50, и думаю, многие нынешние разработчики гораздо моложе, они не помнят, как тогда работали. Думаю, любопытно будет начать с понимания того, что, когда мы начинали этот проект около 2000-х годов, у людей были достаточно громоздкие компьютеры, имевшие в лучшем случае по 64 Мб оперативной памяти, и это было достаточно много. Сегодня же мы измеряем все гигабайтами, даже самые небольшие компьютеры имеют по 8 Гб оперативной памяти, что гораздо больше, чем мы могли мечтать тогда. Не помню точно, сколько было у моего ноутбука, кажется, что-то около 16 или 32 Мб.
Еще одна вещь, о которой следует помнить, — это язык Java на момент 2000-х. Его исходный код не был открытым. Java была бесплатной, ее можно было скачать и использовать, но не было доступа к исходному коду, нельзя было его модифицировать. В тот момент я был довольно активным в сообществе открытого исходного кода, особенно в проекте GNU, в котором затем появился GNOME.
Одним из главных принципов свободного ПО является наличие полностью открытого исходного кода. Это значит, что у тебя есть доступ к этому коду, и ты можешь получить права, связанные с ним. Для людей тогда и для меня лично важно было создать своего рода инструмент для всего человечества. Это и называется открытым исходным кодом, он принадлежит всем нам. И когда я вношу вклад в исходный код, он в равной степени принадлежит и мне, и вам, у вас такие же права на его изменение и модификацию, что и у меня.
На тот момент Windows уже обрела популярность, Mac в какой-то степени был на периферии, также были и закрытые ОС типа Solaris и другие. Мы же пытались создать будущее, в котором бы у нас была полностью бесплатная ОС. Звучит довольно безумно, и нужно понимать, что в тот момент Windows была абсолютным лидером, и идея создания новой ОС с нуля считалась нелепой. Linux тогда возымел некоторый успех на стороне сервера: Red Hat вышла в релиз, люди использовали ее для размещения сайтов, — то было в начале роста Интернета — для файлообменных серверов. Так появился Linux, это было во время начала работы над GNOME, в 1997 или около того, тогда компьютеры имели еще меньше памяти.
Довольно скромное начало, но мы строили что-то по одному принципу, который заключался в том, что всё должно иметь открытый исходный код, а Java на тот момент не имела такого. Поэтому мы не могли строить будущее на технологии, которая не задавала одинаковые правила для всех, где у некоторых было больше прав, чем у остальных. Поэтому Java отпала сразу же. На самом деле за несколько лет до Mono были попытки создать воплощение Java с открытым исходным кодом (Kaffe Virtual Machine и, возможно, некоторые другие). Проблемой при этом всегда был пользовательский интерфейс, мы начинали с виртуальных машин, но интерфейс в них был сложноватый, и даже была попытка копировать AWT (Abstract Window Toolkit) на основе отдельного инструментария Bliss.
Главной проблемой, которую нам предстояло решить в 1998 или 1999, было то, что Java была бесплатной, но не имела открытого исходного кода, и люди не могли вносить свой вклад в его развитие, ввиду чего оно двигалось медленно. Поэтому Java с открытым исходным кодом не получила широкого распространения, потому что уже была хорошая альтернатива в виде официальной версии. Это не сработало, и мы не могли полагаться на этот опыт, но было очевидно после многих лет разработки классического ПО для Linux, что использовать C или C++ невероятно сложно. Даже когда мы запускали GNOME в 1997, мы знали, что эти языки — не идеальный выбор. И если вы посмотрите на анонс проекта, найдете там слова, что мы хотели использовать высокоуровневые языки и сначала предлагали использовать Scheme, который был предпочтительным языком проекта, но мы хотели добавить и другие скриптовые языки.
Это стало своего рода темой GNOME, что мы хотим поднять уровень программирования и абстрактности и не хотим использовать низкоуровневый код. Все это было в 1997 или 98 году, когда компьютеры не могли похвастаться мощностью. Если не ошибаюсь, первой программой, которую мы написали на Scheme, был небольшой интерфейс для запуска команд ping и netstat. То был простенький интерфейс, созданный при помощи библиотеки GTK и написанный на Scheme, но проблема была в том, что он запускался около 17 секунд. Мы попробовали Scheme, но в то время он был мало оптимизированным и довольно медленным, поэтому нам пришлось вернуться к С. Думаю, если поищете первые версии GNOME, то найдете там код на Scheme, и сразу же поймете, что нам пришлось переписать его, поскольку он невероятно медленно работал.
Нужно помнить, что многие подобные вещи разрабатывались в мире, где не было таких мощностей, как сейчас, поэтому нам пришлось вернуться к С.
Mono появился, когда Microsoft анонсировала .NET. И это была та смесь, которую мы искали: смесь высокоуровнего языка (C#) и производительности. Да, можно было добиться производительности и с Java, но в .NET было принято несколько дополнительных решений, которые сыграли нам на руку, например, введение структур против классов. Помните, что это только начало 2000-х, и такие вещи были важны тогда, это сейчас люди уже привыкли ко всем тогдашним нововведениям.
Мы начали изучать возможность внедрения, получили некоторые неполные спецификации, и IBM была вовлечена в процесс, — IBM с Microsoft, насколько я помню, были не совсем в хороших отношениях — она участвовала в процессе стандартизации ECMA и пригласила нас участвовать в процессе в качестве приглашенных экспертов. Тогда нам удалось добыть достаточно документации от ECMA, что позволило нам создать Mono. Я мог напутать некоторые детали, но это не столь важно.
По сути .NET был именно тем, что мы хотели использовать для создания классических приложений на Linux, так, собственно, и начался проект. Оказалось, что это было нам по силам, и позднее мы начали гораздо больше его использовать. Так все и началось: мы хотели работать с системами лучше, у Microsoft была такая система, и она оказалась в нужное время в нужном месте.
Думаю, если кому-то бы захотелось создать подобный проект сейчас, можно было бы просто использовать JavaScript или Python, поскольку современные компьютеры настолько мощные, что, начни вы тот проект в настоящее время, вы бы приняли иные решения. Тем не менее я считаю, что .NET тогда был отличным выбором, но, как оказалось, выбором политическим. И он был сильно политизирован, так как, если помните, Microsoft на тот момент была настроена против открытого исходного кода.
С технической точки зрения это был отличный проект, у меня нет каких-либо сожалений на его счет. Когда я начал создавать компанию с этим проектом, было много стресса, поскольку люди не хотели быть его частью, но, к счастью, те, кто в итоге присоединились к проекту, внесли неоценимый вклад в развитие Mono.
Вернемся к начальному вопросу. Если сравнивать Mono с Java с открытым исходным кодом, то Java с открытым исходным кодом не получила широкую поддержку в сообществе открытого исходного кода, а сообщество, образовавшееся вокруг Mono, было огромным. Очень много людей внесли свой вклад в развитие этого проекта в самом начале. Было потрясающе наблюдать за его ростом.
Поэтому мы и выбрали .NET вместо Java, поскольку у неё было открытого исходного кода в полном смысле, пускай это изменилось позднее, но тогда было уже слишком поздно.
Политика некопирования и отношения с Microsoft
— Отлично, спасибо, у меня есть вопрос касательно моего pull request для Mono, который я отправил 6 лет назад. Это был небольшой запрос, в котором я подправил класс Stopwatch и решил тупиковую ситуацию, когда значение прошедшего времени отрицательно, заменив его на 0. Я также прикрепил ссылку на исходный код Microsoft с их сайта со словами: «Привет, у них уже исправлено это, пора это исправить и в Mono», но запрос был закрыт с сообщением: «Пожалуйста, не прикрепляйте какой-либо исходный код Microsoft». Я создал запрос заново, и он был одобрен спустя год тобой, Мигель, это было уже в 2015 году, тогда отношения между Mono и Microsoft несколько поменялись. Вопрос мой касается политики Mono «не копировать», по которой вы, говоря простыми словами, не могли брать код Microsoft. Думаю, было сложно реализовывать некоторые простые методы в библиотеке Base Class Library, и в большинстве случаев была всего одна целесообразная реализация, которую очень сложно переписать. Так как же вы решали вопросы подобных случаев?
—Сначала поговорим про политику. Ее можно отследить вплоть до проекта GNU. Помните, что мы пытались создать публичный инструмент, и нельзя было просто взять чьи-то наработки и сделать их публичными — у нас не было такого права. Поэтому было важно как для проекта GNU, так и для нас самих, чтобы у него была хорошая история, то есть чтобы мы создавали код только на основе публичных данных. Одной из практик, которую мы внедрили в самом начале, стало то, что мы просили пользователей писать тесты для своего кода, потому что многие тогда просто присылали декомпилированные файлы. Мы настояли, чтобы сначала люди тестировали свой код, и только после этого его отправляли. Так мы могли в какой-то степени быть уверены, что человек понимает, что делает. Такой способ — не панацея, разумеется, но он помог нам убавить количество людей, которые просто использовали декомпилятор, бывший в ходу на тот момент, а иногда даже присылали исправления с вирусами.
Такова была политика проекта «не брать чужое», и она берет свое начало в GNU. Мы всегда были за идею, что мы можем сделать лучше, и в некоторых случаях у нас получалось, а в других у людей не было достаточно интереса, чтобы исправить ту или иную вещь. Среди последних можно встретить вещи, которые не были реализованы. В итоге было много такого, когда либо было слишком сложно, либо не было достаточного интереса у людей, достаточно пользователей или простого спроса.
Поддержка и возможности Mono были очень неравномерно распределены. Наиболее популярные API получали лучшую оптимизацию и поддержку, наименее популярные порой вообще не были реализованы. Это своего рода встроенное изучение клиентских потребностей. В Microsoft, например, нужно заниматься этим, то есть общаться с клиентами, приоритизировать, собирать данные, строить графики, делать выводы о том, что клиентам нужно, а что — нет. С открытым исходным кодом это происходит как-то само. Например, в какой-то момент мы думали, что WCF — это отличная идея, и мы даже немного начинали работать с ним. Тем не менее многие его сложные части не были реализованы, и во многих случаях до этого никому не было дела. Оказалось так, что в WCF было создано много функций, которые использовались немногими. Открытый исходный код в какой-то степени позволяет отслеживать, что используется чаще, а что — реже. На этом завязано много трудностей, когда ты пытаешься воссоздать целую платформу, потому что у тебя нет этих данных в самом начале.
Взаимоотношения с Microsoft с течением времени изменились, было весьма любопытно наблюдать за этим. Microsoft начала свои отношения с открытым исходным кодом с позиции антагониста и рассматривала его как угрозу. Это все было до облачной эпохи, до того, как люди осознали, что многие обычные бизнес-модели себя исчерпают. Было множество перемен, одна из которых — это процесс ECMA, в результате которого появилось больше доступной документации. Документация API, которую Mono использовал многие годы, была основана на документах ECMA. Microsoft пришлось лицензировать свою документация для публичного пользования, и мы взяли ее за основу и переделали для Mono.
С этим даже связана целая история. Мы написали очень много инструментов для импорта документов ECMA. Microsoft просто брали, что у них было внутри компании, экспортировали в формат XML, который передавали ECMA, а мы брали эту документацию и создали целый набор инструментов для документирования API. Впоследствии мы использовали этот набор и для других API, расширяли и дополняли его. Годы спустя наши взаимоотношения с Microsoft стали получше, и они еще раз экспортировали в XML свою документацию и передали нам, после чего мы ее импортировали и положили в репозиторий. Затем проходит еще несколько лет, и выясняется, что их инструменты, которыми они поддерживали свою документацию, оказались нерабочими. Никто не знает, как загрузить документацию: инструменты не работают, а люди, знавшие, как все устроено, уже не являются частью компании по тем или иным причинам. Случилось так, что единственный существующий источник документации — это документация Mono. Мы импортировали всю документацию Mono обратно в подходящий Microsoft формат.
Это привело к забавной оказии. В .NET есть API, который называется system.net.mail. На мой взгляд, он, скорее всего, был разработан одним из стажеров за лето. Этот API довольно плох в том плане, что это, вероятнее всего, был своего рода игрушечный API, который использовался для отправки простых сообщений. В нем полно недостатков проектирования, багов, ограничений, и он не соответствует современным стандартам. Да, он вполне мог быть уместен в 2002 году, но не для современной эпохи с ее различными мерами обеспечения безопасности. Так вот, мы поправили документацию и написали: «пожалуйста, не используйте этот API, он ужасен. Лучше используйте другой проект с открытым исходным кодом с названием MailKit и MimeKit, который написал один из разработчиков Mono», и обозначили тот API устаревшим. То же самое было и в нашей документации.
Когда Microsoft импортировала нашу документацию в свою официальную, естественно, это стало официальной позицией, ведь комментарий, который я оставил еще несколько лет назад, никуда не делся. Люди были в бешенстве, многие из них пользовались этим API многие годы и возмущались тому, что их заставляли использовать что-то другое. На Github до сих пор можно найти почти 300 комментариев по этому поводу. Люди были весьма расстроены такому вот побочному эффекту обратного импорта документации.
Забавно, что вся документация по .NET основана на документации Mono. Она сильно изменилась и улучшилась, поддерживает гораздо большую функциональность, и над ней работает гораздо больше людей. Инструменты Mono стали тем, что сейчас фактически поддерживает документацию Microsoft. Все это — долгий способ сказать, что начали мы с небольшого сотрудничества, а затем были небольшие попытки выложить в открытый доступ свои внутренние наработки. Различные менеджеры проектов и инженеры Microsoft утверждали, что нужно выложить некоторые технологии, чтобы мы могли ими пользоваться, не имею ни малейшего понятия, как они смогли убедить в этом руководство в то время. Тем не менее технологии вроде DLR (Dynamic Language Runtime), Math (я не самый большой фанат Math, но это одна из самых первых вещей, которую Microsoft выложила в открытый доступ), также часть ASP.NET или какое-то его расширение, которое было пакетом с дополнительными функциями.
Затем, в 2007, в разгаре политики Mono против открытого исходного кода, когда компания принадлежала Novell, была подписана договоренность с Microsoft, которую посчитали невероятным предательством сообщества открытого исходного кода. Эта договоренность сделала жизнь многих гораздо сложнее в политическом плане, все было так же плохо, как сейчас в мире, только внутри сферы программного обеспечения.
Я по-прежнему считал, что следует использовать .NET для создания классических приложений на Linux, а Microsoft представила Silverlight. Тогда в течение трех недель я описывал в блоге, как команда из 10 человек, включая меня, реализовали Silverlight на Linux на уровне, достаточном для подтверждения жизнеспособности идеи. Мы занялись этим, потому что кто-то из французского подразделения Microsoft не спросил разрешения и написал мне с предложением выступить основным докладчиком по Silverlight на конференции, посвященной .NET. Я согласился, а моим выступлением по сути была реализация Silverlight на Linux за 3 недели. Я закончил мержить код команды за 20 минут до выступления. В итоге это привело к более тесному сотрудничеству с Microsoft, а человек, пригласивший меня, наверняка получил по рукам за это.
В рамках регулярных встреч между Microsoft и Novell у нас была встреча с Бобом Муглией в офисе Novell, тогда я показал ему, что мы смогли сделать, и он был впечатлен. После этого мы подписали соглашение о сотрудничестве, по которому Novell получила аудио- и видеокодеки. Это было невероятно важно для Linux, для нас, и это очень сложный вопрос, касающийся патентов, лицензий и так далее, поэтому в подробности я не буду вдаваться. Но мы их получили, а также получили набор тестов для основных библиотек .NET. То есть для всего, что использовал Silverlight, у нас были тесты. Это был способ проверить Mono, благодаря чему мы исправили просто огромное количество багов абсолютно во всех аспектах проекта. Процесс занял несколько лет, поскольку Microsoft довольно неохотно делилась внутренними наборами тестов. Хоть это и было официальное соглашение, участвовала в процессе не вся команда.
Затем у .NET начались некоторые проблемы. Точно сейчас не вспомню, но когда выпустили Windows 8, .NET как-то отошел на второй план, Silverlight в некотором смысле перестал пользоваться спросом. Мы же нашли новое призвание. Пока Microsoft усердно продвигала Windows 8, мы поняли, что Microsoft и Mono были очень политизированы в мире открытого исходного кода, и решили, что можно перенести .NET на мобильные устройства, ведь там людям не было дела до политики, им важно было продавать приложения, да и C# был лучше Objective-C и Java. Мы фактически забросили мир открытого исходного кода и стали продавать продукт для мобильных устройств, и, должен сказать, как же замечательно это было. С одной стороны, я люблю открытый исходный код. С другой, как же это хорошо, когда тебе не нужно иметь дела с очень категоричными людьми, с жалобами, нытьем, нападками. Одним словом, мне понравился переход на работу с закрытым исходным кодом, и по множеству причин это было великолепно.
В тот момент отношения с Microsoft были иными. Позднее компания осознала, что .NET — это ключ к успеху Windows. Он был немного забыт, поскольку считалось, что за JavaScript будущее. А затем выясняется, что .NET всем нравился, и мобильные устройства были одним из компонентов, который поможет ему оставаться востребованным для большой части пользователей. Так мы начали сотрудничать более тесно, чаще проводить встречи с сотрудниками и инженерами Microsoft, но с переменным успехом. В какой-то момент позднее руководитель облачного подразделения пригласил нас сделать презентацию его отделу, после чего у нас сложились очень хорошие рабочие отношения, а затем его назначили на должность CEO, мы были этому рады.
Как-то так развивались отношения Mono с Microsoft. Впоследствии они нас приобрели, и теперь Mono — часть .NET. Сегодня все совсем по-другому, чем раньше.
Пользовательский интерфейс, Mono и .NET, отношения с Mac
— Спасибо за подробный рассказ и историческую справку. Мы еще вернемся к Mono и .NET, но до этого и до того, как мы поговорим о Xamarin, мобильных устройствах и прочем, я хотел бы задать немного другой вопрос. Ты упомянул, что твоей целью было создание классических приложений для Linux, и мое впечатление о Mono всегда были таким, что это больше нечто вроде чистого терминала с серверной стороны без какого-либо интерфейса, а единственный интерфейс, существующий в .NET, — это WinForms и позднее WPF. Какова история интерфейса на Linux для Mono и .NET?
—Замечательный вопрос. Mono началась с того, чтобы полностью поддерживать GNOME. Мы сделали привязку .NET к родному API, GTK, который используется в самом GNOME. Во времена Novell мы использовали его для создания нескольких ключевых приложений. С его помощью мы создали приложения для работы с фотографиями, музыкальный плеер, конструктор, IDE и другие. Всего таких приложений, созданных с помощью Mono, было около 6–7, которые были включены в версию Linux от Novell. Ubuntu включила некоторые из них, если мне не изменяет память.
Как я уже сказал, тогда было много политики, и было много попыток реализовать их на других языках, чтобы никто не был «загрязнен» технологией Microsoft. Мы написали несколько приложений, они были включены в некоторые дистрибутивы Linux, но в тот момент из-за слишком большой политизированности они не нашли большого успеха. Для нас же это был большой успех, поскольку мы считали, что никто больше не написал столько классических приложений для Linux.
Когда же мы перешли на мобильные устройства, мы увидели, на что способны люди в мире: мы гордились 6–7 приложениями на Linux, а в течение всего 6 месяцев на мобильных устройствах уже было более 300 приложений, созданных при помощи Mono, и с того момента их число значительно выросло и до сих пор растет.
Как ты и сказал, у людей .NET ассоциировался прежде всего с разными серверными штуками, поскольку большая часть классических приложений Linux используется только некоторыми профессионалами индустрии, и крупным игроком те приложения пока что не стали. Выбор классических приложений на Linux несколько ограничен в настоящее время, и, если повезет, можно получить что-то вроде Electron, или что-то на его основе. Время классических приложений на Linux еще не настало, и очевидно, что огромный рынок ОС типа iOS и Android — место, где и происходит все действие в настоящий момент.
В общем, у нас был инструментарий, он нам нравился, мы попытались скопировать WinForms, попытка эта была очень сложной, поскольку для этого при любом раскладе потребуется воссоздать Win32. Никому такого не посоветую.
— Да, но Microsoft, тем не менее, все равно в какой-то степени это сделала в .NET 5. Мы говорим о Linux, но MacOS также уделяет большое внимание классическим приложениям, и мой вопрос: какие отношения у Mono и MacOS?
— Это отличный вопрос! Перед ответом должен сказать, что поддержка WinForms, которую реализовала Microsoft, доступна только на Windows, мы же пытались ее воссоздать на других платформах.
На MacOS другой API, AppKit, и множество других фреймворков. AppKit — это своего рода основа, с помощью которого можно строить пользовательские интерфейсы. И мы просто создали привязку, она называется Xamarin.Mac. Если у тебя Visual Studio на MacOS, и ты делаешь проект для нее, то так или иначе придется использовать AppKit. Если ты, конечно, хочешь создать родное приложения для MacOS.
В случае с .NET я думаю, что почти все существующие платформы имеют привязку к родным API. Сегодня ты всегда можешь использовать родной API для связи с хостом. Существует множество попыток абстракций, будь то Avalonia, Xamarin Forms и другие. В общем, большой выбор у людей, которые хотят написать код один раз и запускать его где угодно с учетом различных ограничений. Либо можно построить связь напрямую с родным API платформы.
Мы называем привязки к AppKit Xamarin.Mac, они состоят примерно из 60 фреймворков. Можете думать о них как, скажем, о способе общения с DirectX. У вас есть API, который вы используете для общения DirectX, OpenGL или Vulkan. Есть люди, которые хотят использовать такие низкоуровневые API, а есть люди, которые хотят сделать что-то на 3 уровня выше, например вывести на экран куб, и не важно, как это будет работать. Либо можно пойти на низкий уровень и самому создать шейдеры и прочее. Сегодня это выбор, который есть у разработчиков. И прошу прощения за такие длинные ответы, я постараюсь быть покороче.
Мобильные устройства и будущее технологий
— Нет-нет, было очень интересно. Итак, мы поговорили о разработке интерфейсов классических приложений, теперь я хочу спросить про разработку интерфейсов на мобильных устройствах и про будущее разработки на них. Сейчас у нас много различных технологий, которые позволяют разрабатывать мобильные приложения, будь то Xamarin, какие-то родные инструменты, JavaScript, Kotlin/Native и многие другие. Что ты думаешь о будущем мобильного мира, какая технология преуспеет? Какую технологию следует использовать сейчас?
—Трудно ответить на этот вопрос. Не уверен, что у меня есть какие-то рекомендации для людей по той причине, что у всего есть обратная сторона, и у всех людей свое мнение. Приведу пример: сообщество Apple iOS просто невероятные фанаты родных API, которые оно использует для создания безупречного пользовательского опыта и тратит годы на разработку таких приложений. Проблема в том, что не у всех есть время, деньги, знания или необходимость делать это. Да, было бы идеальным вариантом всегда разрабатывать что-либо с таким подходом, но не всегда это возможно или необходимо. И в таких случаях на первый план выходят технологии вроде React Native. Это отличный вариант, если ты веб-разработчик с опытом в JavaScript. Я его не так много использовал, но у него хороший режим интерактивной работы. Пускай Swift и Kotlin — это отличные инструменты, у тебя не всегда есть доступ к разработчикам, работающих с этими инструментами. Или, например, в странах третьего мира Mac мало у кого есть, поэтому используются более дешевые компьютеры. Ты разрабатываешь приложение, используя такие компьютеры, на Android и скрещиваешь пальцы, чтобы кто-нибудь создал версию для iOS.
Есть множество ограничений и компромиссов для выбора чего-то одного. Я думаю, что все эти технологии проделали хорошую работу для своего развития, и все они работают над расширением своих возможностей. Мне не довелось пользоваться Kotlin/Native, но Flutter, например, является отличным примером подхода «напиши один раз и запускай где угодно», но, разумеется, у такого подхода есть обратная сторона. Он не совсем родной, а только выглядит таким, плюс интеграция не всегда гладко проходит, но для многих людей этого достаточно. Думаю, еще важный вопрос заключается в том, а есть ли у тебя код, который нужно повторно использовать? И он повлияет на многие твои решения. Допустим, у тебя есть какой-то код на Java, на .NET, или на Objective-C, твои решения будут больше касаться фреймворков, чем каких-то практических вопросов.
Не знаю, окажется ли на вершине какая-то конкретная технология, по той причине, что мир разработки невероятно большой со множеством различных нужд. .NET пытается предоставлять доступ как к низкому уровню, так и к уровню абстракций. Честно скажу, что, если бы у меня был небольшой бюджет, я бы сделал нечто аналогичное тому, что сделал Flutter: создал бы свою систему рендеринга. Не потому что мне она нравится, а потому что она нравится пользователям, даже, скорее, разработчикам. Проблема, которая мне видится, заключается в том, что подобная Flutter-система потребует очень больших средств для разработки. Не думаю, что в ближайшее время мы увидим какой-нибудь клон Flutter, а Avalonia, пожалуй, самое близкое к нему, что есть на данный момент, но ему потребуются годы на решение проблем, которые Flutter уже решил.
В любом случае, боюсь, я не могу дать какого-то четкого ответа. Естественно, у меня эмоциональная привязанность к .NET, я думаю, что это прекрасная технология. Тем не менее потребности у всех разные, и даже .NET не удовлетворяет все потребности пользователей. Нет какого-то единого решения, которое подойдет всем, но мы все равно продолжим видеть блоги с посылом, что нужно использовать ту или иную технологию.
Хочу сказать, что сам лично я обожаю писать код на Swift. Это очень интересный язык. Проблема только в том, что SwiftUI, который мне нравится, работает только на платформах Apple, поэтому он не подходит для большей части мира, потому что она использует Android. Но это интересная вещь, и, когда есть свободный вечер, и если не смотрю что-то на Netflix, мне нравится играть со Swift. Уверен, есть какой-то аналог на Java, но, как вы могли понять, я не пользуюсь Java.
— Не похожа ли история с SwiftUI, который работает только на Mac, на то, что 20 лет назад .NET работал только на Windows, а ты был одним из тех, кто сделал так, чтоб он работал и на Linux. Кто-то должен взять его у Apple и перенести на Android и все остальные платформы.
— Думаю, что кто-то этим должен заняться, но это буду не я. Отчасти из-за того, что у меня трое детей, и порой они не дают мне отдохнуть. Совмещать работу в Microsoft и троих детей достаточно тяжело. Это должен быть кто-то до 30 лет, у кого нет детей, чтобы он мог полностью сосредоточиться на таком проекте. Но это отличная задумка. На самом деле, если кто-то хочет начать над этим работать, у меня есть пара идей, как это можно реализовать, и я буду рад научить кого-нибудь, только сам я этого делать не буду. Плюс ко всему, это довольно долгий процесс.
Есть очень хорошая вещь, называется SwiftWebUI. Кто-то просто взял и сделал реализацию SwiftUI для веба, которая генерирует HTML. Его можно использовать как основу в том плане, что кто-то уже разобрался, как этот движок работает, и привязать к чему-то другому, чтобы выводить картинку на Android. Займись я этим сам, я бы, скорее всего, использовал Flutter в качестве движка, поскольку его система рендеринга наиболее близка к тому, что предлагает SwiftUI. Не совсем идеальное решение, но оно поможет найти верный путь.
Как я сказал ранее про Flutter и Avalonia, эти рендеринговые движки гораздо сложнее и дороже, чем люди привыкли думать. Если бы я занялся переносом SwiftUI, я бы взял SwiftWebUI и объединил бы его с Flutter для создания кроссплатформенного решения. Но опять же, не думаю, что в этом есть потребность, многим людям хватает React Native.
Официальная Xamarin Forms на всех платформах
— Раз мы заговорили про различные UI, есть еще одна область для обсуждений в .NET. Сейчас у нас есть Xamarin Forms как некое официальное кроссплатформенное решение от Microsoft на .NET, у нас также есть Blazor и MAUI. Это еще одна попытка Microsoft создать решения для разных сегментов, или они будут объединены каким-то образом?
—Хороший вопрос. Мне кажется очень интересной программная модель Blazor. Microsoft его довольно хорошо сделала. Он разработан с использованием серверной модели приложения, сохраняет состояния и является хорошим решением для интерактивных приложений. Он появился из желания создать технологию, которую веб-разработчикам было бы проще использовать. И думаю, это удивительно, что нечто, начавшееся как эксперимент, набрало большую популярность среди веб-разработчиков. Я очень впечатлен скоростью его роста.
Затем была версия Blazor, которая для выполнения логики приложений полагалась больше на клиент, а не на сервер. Если у вас миллион и больше пользователей, то лучше, чтобы приложение как можно больше работало на стороне клиента, вместо того чтобы наращивать мощности сервера. Так вот, такая версия была реализована на Web Assembly, и она тоже пользуется относительной популярностью. Все это доступно в .NET 5, то есть у тебя есть выбор, будет ли твой код больше работать на стороне сервера или на стороне клиента.
Blazor появился в результате эксперимента, который набрал популярность и впоследствии стал продуктом. Отсюда все и появляется: из идей, экспериментов и попыток попробовать что-то новое. Если они нравятся людям, над ними продолжают работу. Вы можете пронаблюдать некоторые такие эксперименты, например поддержка Kubernetes. Мы много с чем экспериментируем, что-то получит поддержку, что-то нет. Blazor стал одним из того, что получило поддержку.
Xamarin Forms и MAUI. Первая официально работает на iOS и Android, а неофициально она доступна и на Windows, и на Mac, и на WPF, и так далее. Но это все неофициальные порты. MAUI — это попытка сделать все эти порты официальными, и в процессе MAUI решили, почему бы им не взять и не исправить проблемы некоторых API, не сделать их лучше. Вы можете считать MAUI официальной версией Xamarin Forms на всех платформах. И, возможно, это пока неточно, в будущем мы попытаемся улучшить некоторые API. С одной стороны, если мы улучшим их, они очевидно станут лучше, а с другой, если ты решаешь изменять API, то ты по сути перезапускаешь всю экосистему. Нужны поставщики компонентов, нужно работать над новыми версиями, людям придется переносить свой код и тому подобное.
Простыми словами, MAUI — это тот же Xamarin Forms с официальной поддержкой всех платформ. Если верно помню, изначальный план был отбросить название Xamarin, namespace, assembly, чтобы было понятно, что он кроссплатформенный и является частью .NET. А потом мы поняли, что из-за этого многим придется переписывать свои проекты, и это может вызвать определенные сложности в работе людей. Он точно будет поддерживать все платформы, вопрос лишь в том, будем ли мы ломать проделанную людьми работу или сделаем все по-простому.
Работа в Microsoft, текущие интересы и .NET Foundation
— У нас осталось немного времени, и я бы хотел обсудить твою ж
