О необходимости возрождения C #

В 2011 году Боб Ли, выступая в OSCON, сплотил Java-разработчиков против сокращения использования этого языка после появления Ruby on Rails и определил, что настало время для Java Renaissance: https://www.youtube .com / watch? v = k-PyVYY7QFI

В 2017 году нам нужно сплотить разработчиков C # против упадка языка на стороне сервера, сообщить о росте Rails, Django и Node.JS. Пришло время для эпохи Возрождения C #.

Это длинный пост, но я хочу осветить некоторые вещи.

Во-первых, некоторые могут сомневаться в том, что мы находимся в каком-то темном веке, требующем Возрождения. Конечно, для разработчиков, ориентированных на рабочий стол Windows, конкуренция невелика; Xamarin хорошо работает на мобильных устройствах; и Unity сильна в программировании игр. И любой взгляд на данные о вакансиях говорит о том, что для .NET-разработчиков существует много вакансий. Но что касается .NET на стороне сервера, у многих возникает неприятное ощущение, что там количество рабочих мест иссякает и новых проектов становится все меньше. Я продемонстрирую с некоторыми данными, почему люди считают, что, как и на сервере, картина менее радужная.

Во-вторых, я хочу взглянуть на некоторые из причин этого упадка на сервере: что пришло на смену .NET и почему.

В-третьих, я хочу поговорить о том, почему происходящие события создают возможность переломить эту ситуацию.

В-четвертых, возрождение .NET требует от нас совокупности знаний, чтобы открыть и оживить наш язык. Откуда это взялось?

Наконец, любое Возрождение, которое использует преимущества этого развития, наступит только в том случае, если мы, сообщество, создадим его. Мы не можем полагаться на MS. Мы должны вызывать интерес к .NET на сервере на мероприятиях сообщества и заражать этим энтузиазмом людей за пределами сообщества. В этом посте все это не рассматривается, нам понадобится больше времени, чтобы поговорить об этом, но, надеюсь, он сможет создать основу для разговора.

Я надеюсь, что этот пост станет началом дискуссии. Я не обязательно имею это право. У других может быть совсем другая точка зрения на то, были ли мы в темных веках и можем ли мы создать ренессанс. Я мог ошибаться. Но давайте вместе узнаем правду.

Темные века

Отклонить

Новости для серверных разработчиков C #, ищущих платформу для поддержки своей карьеры, в последние годы были плохими.

Данные с сайта Indeed.com показывают, что общее количество рабочих мест по C # сократилось с 1,4% от общего числа вакансий в области разработки программного обеспечения до 0,84%.

В США сейчас вдвое меньше новых позиций C #, чем было четыре года назад. Для сравнения, Python за тот же период вырос с 0,54% до 1,11%.

Эта ситуация действительно зависит от географии. В некоторых местах C # более популярен, чем другие, например, исторически сложились кластеры вокруг Сиэтла, Остина, Нью-Йорка и Лондона.

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

Великобритания уже давно является сильным рынком C #, поэтому можно судить о здоровье языка там.

Взглянув на C # в Великобритании, можно предположить, что в период с 2009 по 2012 год он пользовался большим спросом, а затем упал, причем в большей степени на контрактном, чем на постоянном рынке.

Но в целом количество рабочих мест на C # в Великобритании остается значительным, поэтому не похоже, что вы останетесь без работы завтра, выбрав C #. Конечно, C # имеет тенденцию к снижению, но достаточно ли значительны эти 5% для постоянного и 8% для контракта, чтобы нас беспокоить? Работы еще много.

Вызывает беспокойство то, что спад на контрактном рынке может быть ведущим индикатором спада новых проектов. Опасность заключается в том, что это означает, что магазины используют C # только там, где он уже используется, а не в новых разработках. Если это правда, то в то время как существующие магазины .NET будут продолжать работать над существующими базами кода в течение некоторого времени, из-за проникновения C # на рынок все эти годы такая ситуация сохраняется до тех пор, пока этого не произойдет.

Но все мы знаем, что речь идет не только о разработке. Это о «хорошей» работе. Например, мало кому нравится Sharepoint, но обычно это считается работой на C #:

Как ни странно, опыт многих моих коллег из Великобритании при поиске работы для проектов C # показывает, что «хорошие» должности труднее найти. Что такое хорошая позиция? Я думаю, что большинство людей думают о роли, которая обрабатывает как веб-роли, так и рабочие роли на сервере, а не роли Sharepoint. Coure YMMV.

Однако, в частности, иссякают бэкэнд-роли. C # имеет меньшую конкуренцию на рабочем столе Windows или в Office Automation, но на сервере есть гораздо больше возможностей.

Так объясняют ли данные разницу между тем, что люди чувствуют, когда ищут работу, и тем, что предлагают эти цифры для разработчиков C #?

Что ж, давайте рассмотрим подробнее.

Взгляните на этот график для вакансий ASP.NET в Великобритании:

В то время как спрос на постоянные роли упал, мы наблюдаем чрезвычайно резкое падение именно в контрактных ролях: с 2009 года контрактные роли упали с 20% всех ИТ-должностей до менее чем 10%. Половина открытых контрактных позиций исчезла с 2009 года.

Это подкрепляет картину данных Indeed по США, хотя она началась в 2009 году.

Не жалко подрядчиков? Помните, что контракты часто являются ведущим показателем, учитывая, что подрядчики часто привлекаются для новых проектов. Это говорит о том, что новые серверные роли для C # вымирают.

Именно это резкое сокращение контрактных ролей ASP.NET соответствует неофициальным свидетельствам коллег об их борьбе за хорошие роли: краху .NET на сервере.

Чтобы понять силу C #, мы могли бы взглянуть на некоторые индикаторы популярности языка. Опять же, некоторые из заголовков выглядят позитивно, C # неизменно остается в пятерке лучших по большинству тестов.

Что больше беспокоит, так это линия тренда.

Для Tiobe популярность C # достигла пика в 2012 году, с тех пор снижается и снизилась вдвое по сравнению с пиком.

Осень

Что касается серверной части, то эта новость вызывает беспокойство, поскольку предполагает, что для проектов ASP.NET C # близок к тому, чтобы стать унаследованной платформой. Эти анекдотические истории, похоже, подтверждаются данными.

Теперь я хочу подробнее разобраться в тяжелом положении C # на сервере. Опять же, я действительно понимаю это лучше. Прошло какое-то время с тех пор, как я делал рабочий стол Windows, или телефон и игры выходят за рамки моего опыта. Там может и не быть спада, и это здорово, если это правда.

Но сначала давайте вспомним, что Великобритания - хороший рынок для C #. Заданий на C # больше, чем на Java.

Так зачем волноваться?

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

Хорошая новость в том, что C # начался со значительной базы, особенно здесь, в Великобритании. Так что его падение не обязательно должно быть окончательным, если мы этого не хотим.

Java и .NET в виде дерева

Прежде чем кто-либо, использующий Java, получит слишком много злорадства по поводу того, что старые соперники упадут, их график данных о вакансиях показывает точно такое же снижение за тот период времени - они начали примерно с 3,5% и снизились до 1,5%. в США то же самое.

Помните тот разговор о местных горячих точках? По сравнению с США, постоянный рынок C # в Великобритании кажется лучше, чем Java, что отражает популярность этого стека за последние годы. Но мы показываем аналогичные общие данные. Java потеряла около 5% своих постоянных ролей за последние 5 лет и снизилась примерно на 10% по сравнению с 10-летней давностью:

Рынок контрактов на Java демонстрировал аналогичную картину, но, похоже, с 2013 года он восстановился, увеличившись на 10% по сравнению со своим рекордным минимумом в 24% рабочих мест в сфере ИТ в Великобритании, что говорит о том, что возрождение Java может быть не просто шумихой. Все мы знаем истории о том, как Java заставляли делать тяжелую работу на успешных сайтах, написанных на других языках, что является ключевой целью возрождения Java.

У Java был менее крутой путь по индексу Tiobe, хотя он все еще снижался за тот же период, не совсем потеряв половину, и снова, похоже, недавно получил отскок.

Хотя у меня есть только данные по Великобритании, чтобы показать это, восстановление контрактного рынка, опережающий индикатор, может быть признаком того, что Java Renaissance Боба Ли приносит свои плоды:

Я думаю, что у Java была сила, которая позволила ей вернуться на сервер: рабочие нагрузки, связанные с процессором. Python, Ruby и особенно Node.JS хорошо работают с рабочими нагрузками, связанными с вводом-выводом. Но все используют модель процесса для масштабирования. Если ваша рабочая нагрузка связана с процессором, может быть преимущество использования виртуальной машины, такой как JVM (или CLR), для масштабирования. Это известная проблема, которая поразила такие сайты, как Twitter, подтолкнув их к тому, чтобы использовать JVM с холода.

Куда делись все люди?

Во-первых, давайте убьем стойкое убеждение, что все разработчики C # любого уровня подготовки теперь являются разработчиками F #. В Великобритании нет реального спроса на разработчиков F #.

или США:

Как ни странно, многие из моих друзей F # используют Scala, по крайней мере, для работы на языке FP.

Да, F # любят, и многие в сообществе .NET увлечены им. Он хорошо соответствует самым популярным рейтингам в опросе разработчиков Stack Overflow:

Но его количество настолько мало, что любая революция в F # - это выход. Для этого нужно время, и я считаю, что ему нужно время, которое может купить только C #, чтобы получить более значительную долю рынка. Сейчас он слишком зависит от состояния экосистемы .NET, чтобы выжить в одиночку.

F # - это не ваш парашют. Теперь.

Если не F #, Scala? Что ж, у Scala есть некоторые заметные цифры по сравнению с 6% вакансий в области программирования в Великобритании.

Это может быть причиной некоторого отклонения, особенно от Java, в Великобритании или США. И снова это будет соответствовать анекдотическим свидетельствам того, куда люди переходят на серверную часть, оставляя C # позади. Но я не думаю, что мы можем объяснить все это движение.

Scala не намного более значима, чем Ruby, которая также демонстрировала стабильный рост за тот же период, хотя она не пользуется такой популярностью в Tiobe, как даже Java или C #.

Хотя Ruby, возможно, достиг пика в соответствии с линией тренда Tiobe:

Тем не менее, хотя количество рабочих мест Ruby или Scala меньше, чем ASP.NET, оба они все же могут утверждать, что их тенденция к рабочим местам растет, а не снижается.

Оба они уступают Python, у которого столько же рабочих мест, сколько у них обоих вместе взятых. В войне Python против Ruby Python может объявить о победе:

Python также демонстрирует рост на Tiobe, хотя, возможно, даже он преодолел свой пик:

Но слон в комнате - это JavaScript. Данные о вакансиях в Великобритании стремительно растут:

Конечно, проблема с JavaScript заключается в том, что трудно понять, представляет ли он интерфейсные задания (которые могут быть связаны с C #) или серверные задания. Однако опрос разработчиков Stack Overflow предполагает, что JavaScript доминирует как в интерфейсных, так и в внутренних рабочих процессах:

Но даже если мы называем бэкэнд просто заданиями Node.js (и игнорируем такие термины, как Fullstack), кривая будет крутой (и, вероятно, она представляет больше бэкэнд-заданий, чем Python, несмотря на большее общее число Python).

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

Конечно, разработчиков все еще меньше, чем ASP.NET, но тенденция идет вверх, а не вниз. А разработчиков на контрактных позициях чуть меньше, чем у ASP.NET.

На Tiobe у JavaScript сложная картина: он набирает и теряет популярность, хотя его тенденция все еще растет.

Возможно, стоит вкратце поговорить о Go, Elixir и Clojure. Они определенно «крутые ребята» для многих за пределами CLR. Во многих отношениях они занимают позицию, аналогичную F # для сообщества .NET. Умные дети любят о них говорить.

Clojure для JVM так же, как F # для CLR. Он функциональный, и многим умным людям, которых я уважаю, нравится этот язык, но на сегодняшний день он не набирает достаточно высоких показателей, чтобы объяснить большую часть диаспоры.

Elixir - это предназначение для умных детей Ruby, но, опять же, у него почти нет пользователей. Опять же, это мало что говорит о нашей истории.

Go примечателен тем, что на нем разрабатывается значительная часть инфраструктуры и, как известно, стек Node.JS + Go с микросервисами Go, обслуживаемыми веб-сервером Node.JS, все чаще рассматривается многими, как я знаю, как «новый стек». Цифры помещают его в другой парк мячей, нежели Clojure, Elixir и F #, хотя все еще далеко позади больших мальчиков:

Я думаю, что Go - это «то, что нужно наблюдать», поскольку разработчикам Java и C # намного проще перейти на Go over Clojure и F #.

В целом, я подозреваю, что это не так просто, как сказать, что серверные роли перешли на один «новый» язык. Некоторые перешли на JavaScript, некоторые перешли на Python, некоторые перешли на Ruby, а третьи на Scala. Некоторые из этих языков лучше справляются с одной частью этого стека, чем с другой. Но что касается серверной части, в основном за последние четыре-пять лет, C # истекает кровью на сервере.

Причины падения

Так почему же C # пришел в упадок?

Думаю, ответ сложен.

Посмотрим, что мы знаем.

На сервере Unix

Сначала давайте рассмотрим аргумент о том, что, поскольку Linux победил на сервере, .NET приходит в упадок, потому что его основная хост-платформа сокращается.

Почему победил Linux? Поскольку все больше приложений ориентированы на сценарии Cloud Native, в Linux появляется лучший инструментарий для инфраструктуры в виде кода, контейнеров и т. Д.

Windows чувствует, что постоянно находится в режиме наверстывания упущенного в этих областях. (Хотя по мере того, как мы движемся к контейнерам и бессерверным приложениям, ОС, обеспечивающая хост вашего приложения, может иметь все меньшее и меньшее значение).

В самом деле, я знаю несколько предприятий, которые заявили, что они будут предоставлять Unix только на сервере, обрекая C # на клиентские сценарии.

Согласно этой теории .NET Core, решение на платформе x является ответом на потерю рабочих мест C #. Поддержка Linux должна остановить или даже обратить вспять этот спад, сведя на нет любые риски платформы.

К сожалению, хотя это определенно важно, я не думаю, что риск платформы не может полностью объяснить снижение, потому что Java, которая всегда была способна ориентироваться на Unix, за тот же период пережила спад. В пространстве Unix есть конкуренция.

Я очень рад, что .NET станет x-платформой, и я смогу разместить его в лучшей доступной среде, будь то Windows или Unix. Несомненно, разрыв между Java и C # можно частично объяснить тем, что JVM доступна в Unix.

Для обеспечения соответствия на стороне сервера необходимо использовать Unix, чтобы поставлять ядро ​​.NET. Конечно.

Но одного объяснения потерь недостаточно.

Кафедральный собор и базар

Теперь давайте обратимся к аргументу о том, что мир перешел на экосистемы OSS и доминирование Microsoft над экосистемой .NET никогда не позволяло этой экосистеме дышать и расти.

По сравнению с Java, .NET часто отстает в инструментарии для серверной архитектуры и, как и в ОС, всегда догоняет.

В соответствии с этим аргументом решением будет работа над улучшением экосистемы .NETs OSS. Если мы создадим OSS среду выполнения и фреймворк, мы сможем поощрять участие в OSS всего сообщества. Если бы MS работала с проектами OSS вместо их замены, экосистема больше не боялась бы 500-фунтовой гориллы в комнате.

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

Но, хотя здоровая экосистема OSS, возможно, является еще одним ключевым преимуществом Java, снова объясняющим ее большую долю на рынке, упадок Java показывает, что вам нужен правильный стек - тот, который поддерживает сегодняшние сценарии. Все OSS в мире вам не помогут, если ваша платформа затмевает то, как люди хотят работать сегодня.

Здоровая экосистема необходима для актуальности на стороне сервера. Конечно.

Но он должен постоянно приспосабливаться, продолжать развиваться, продолжать вводить новшества.

В этом контексте OSS имеет такое же отношение к гибкости, как и открытость. Двухлетний цикл усовершенствований традиционных корпоративных программных продуктов уже не успевает за темпами. Ваша платформа будет сочтена бюрократической и брошена на произвол судьбы, если таков ваш подход.

Скорость доставки вашей платформы решает все. Сбрасывать каждые 6 месяцев - это слишком мало, слишком поздно.

Если никто не создает OSS на вашей платформе для лучшей поддержки появляющихся шаблонов и практик, вы вполне можете оказаться отмеченными как «предприятие», и ваше будущее быстро превратится в управляемый упадок и наследие.

Так что для C # недостаточно иметь OSS, он должен иметь OSS, соответствующий сегодняшним сценариям, с активным сообществом, которое продвигает его вперед в темпе.

Язык - это карта мира

Учитывая сходство C # и Java, виноваты ли сами языки? Появились более новые, лучшие парадигмы.

Функции, функции

Вы заметили, что многие умные дети перешли от парадигмы объектно-ориентированного программирования к парадигме FP? Просто люди переключаются с парадигмы объектно-ориентированного программирования в этих языках на F #, Clojure или Scala.

Как отмечалось выше, свидетельств значительного перехода к F # или Clojure недостаточно. Они могут стать альтернативой завтра, но не конкурентами сегодня. Количество открытых позиций F # просто недостаточно, чтобы представить изменение преобладающего языка .NET. Количество позиций Clojure еще не отражает изменения доминирующей парадигмы для JVM.

Все ли они перешли на Scala? Конечно, был удар.

Но рост платформ без FP, таких как Python, предполагает, что не просто FP отвлекает людей от объектно-ориентированного программирования. И рост популярности Go предполагает, что в парадигмах ОО-языка все еще есть жизнь.

Многие люди, которых я знаю, великолепно поддерживают функциональность. В некоторых сценариях (финансы) это явно лучший инструмент для работы. Наличие функционального языка среды выполнения важно для ее работоспособности. Он предлагает разнообразное предложение, которое поддерживает разные сценарии.

Может даже собственное завтра, думаю, что еще рано звонить. Хороший OO тоже может вернуться. Как ни странно, я знаю больше людей, которые причисляют себя к поклонникам F # или Clojure, чем я знаю людей, работающих с F # или Clojure. Мы еще не достигли переломного момента.

Но у них недостаточно внимания, чтобы объяснить, почему C # (или Java) отказался от сервера. C # часто заимствовал функции из F #, как и Java. Там, где это имеет смысл, это может иметь смысл, поскольку живой язык лучше мертвого.

Динамический и статический

Когда мы смотрим на некоторые языки, на которые вышли Java и C #, мы видим, что динамические языки играют важную роль. JavaScript, Python и Ruby получили распространение, и многие из 10 лучших динамических языков Tiobe являются динамическими. Являются ли динамические языки более популярными, чем языки со статической типизацией, потому что в них меньше церемоний, больше гибкости и удобен для запястий подход.

Лично мне эта дискуссия интересна. Когда я начал свою карьеру много месяцев назад, я начал разбираться в языках семейства Dbase. По общему признанию, это было до TDD, но количество ошибок, связанных с типами, и количество связанной с типами документации, чтобы попытаться победить их, означало, что мы с радостью бросились в объятия статически типизированного языка (C ++ в моем случае) даже хотя в этом языке было больше церемоний и, возможно, он был менее продуктивным.

Я подозреваю, что этот статический или динамический флип-флоп, выбор между статическим и динамическим, имеет столько же общего с проблемами, как сначала создание, а затем поддержание большой базы кода и поиск `` серебряной пули '' для проблем, с которыми мы столкнулись последними. время, чем что-либо еще. На создание потребовалось много времени: в следующий раз используйте динамический; трудно поддерживать: в следующий раз используйте статический.

Я могу утверждать, что возрождение интереса к системам типов через такие языки, как F # и Haskell, частично является реакцией на поддержку больших баз кода в таких языках, как C # и Java. Я тоже не уверен, что это правильное решение, как и большинство серебряных пуль.

TDD вполне может быть для меня лучшим ответом.

Я подозреваю, что для долговечности языка может быть аргумент в пользу необязательной типизации, но я не думаю, что именно поэтому C # и Java отказались.

Сложность

Я давно утверждал, что ключевой проблемой как для Java, так и для .NET является их «барьер для входа».

.NET Framework уже 15 лет, и за эти годы в ней появилось много функций, которые мы сейчас редко используем, например .NET Remoting или WebForms. Эта большая площадь устрашает новичков. Это порождает анекдотическое ощущение, что Java и C # - архаичные языки, с которыми трудно начать работать. Снова и снова в программном обеспечении мы видим соблазн нового, уводящий разработчиков от устоявшихся языков и фреймворков к тем, которые кажутся менее эффективными или в лучшем случае лучше в небольшом диапазоне сценариев, но не кажутся подлинными. конкурент более устоявшемуся языку. Привлечение новых языков связано не столько с «новым блеском» или проблемами с существующим набором языков и фреймворков, сколько с большой поверхностной областью, которую вы должны понимать, если попадете на первый этаж старых.

Я часто сравниваю эту проблему с телешоу или сериалом фильмов со сложной предысторией. Трудно начать смотреть «Игру престолов» на полпути или «Людей Икс». Конечно, наличие коробочных наборов и т. Д. Означает, что люди могут наверстать упущенное, точно так же, как они это делают при изучении C # или Java, но новая франшиза устраняет необходимость в этом. В результате Голливуд любит "перезагрузку". Мы можем перезагрузить часы и впустить новых людей, надеясь, что при этом сохраним интерес фанатов.

Я считаю, что для уменьшения сложности нам необходимо сократить площадь поверхности .NET Framework, чтобы мы могли сосредоточиться на поддержке ключевых сценариев на стороне сервера.

C # поддерживает множество сценариев: настольные, игры, серверные и мобильные. Большинство разработчиков не делают все четыре, и лишь немногие делают больше одного. Создавая фреймворки, чтобы уменьшить вероятность того, что разработчики в этих сценариях должны понимать, вы можете снизить барьер для входа и увеличить принятие. Язык и ядро ​​фреймворка остаются прежними, но разные сценарии развертывания содержат только те зависимости, которые им необходимы. Это также позволяет вам нацелить обучение и документацию на те сценарии, которые требуются разработчикам для этих сред. Мы можем пояснить, как можно использовать фреймворк для решения типичных проблем.

Также важно помнить, что диапазон доступных фреймворков OSS должен уравновешивать как желание многих иметь победителей, которые сокращают количество фреймворков, которые новичку, возможно, придется учить, чтобы чувствовать себя продуктивно с языком, так и быть достаточно открытыми для новых участников. люди чувствуют, что они могут что-то внести, и имеют шанс, что этот вклад будет признан за его ценность. Как хаотическая масса вариантов OSS без четкого указания, «что использует большинство людей», так и неспособность людей внести свой вклад, который может быть признан, могут быть фатальными. Иногда по этой дороге тяжело идти.

Сообщество

Когда люди пишут в блогах посты типа «оставив x», они часто привлекают внимание к сообществу. «Это сообщество гораздо более открыто для новых идей», мы здесь или «Это сообщество намного лучше умеет делиться знаниями».

Установленные языки могут стать закрытыми эхо-камерами. Не потому, что участники этого хотят, а потому, что они не пытаются активно завербовать людей на свой язык, поскольку уже создали свою базу. Это представляет ряд опасностей:

  • Отсутствие новых участников означает, что сообщество в конечном итоге будет сокращаться, поскольку убытки от убыли не возмещаются.
  • «Истеблишмент», который вознаграждает существующих экспертов за новые голоса, может показаться элитарным и нежелательным, что создает барьер для новых участников на языке и в сообществе.
  • Это особенно проблематично в сочетании со сложным наращиванием библиотек в рамках, которые новички должны освоить, прежде чем «зарекомендовать себя».
  • Это также подкрепляется закрытыми частными сообществами, такими как слабые каналы, которые трудно обнаружить новым участникам.
  • Это укрепляет представление о том, что сообщество смотрит внутрь себя, как эхо идей.
  • Вознаграждение учреждения по сравнению с новыми участниками создает сопротивление изменениям, поскольку влияние часто основывается на знании существующих структур или подходов. Сохранение «авторитета» часто означает сопротивление изменениям, поскольку это само по себе воспринимается как подрыв авторитета, полученного благодаря опыту в более старых подходах.
  • В результате язык превращается в устаревшие сценарии, потому что оба его приверженца отвергают новые подходы, а посторонние воспринимают язык как тот, который не может реализовать новую идею, или сообщество не приветствует их.
  • Разнообразие часто отсутствует, поскольку сообщество неприветливо.

Языки с приветливыми сообществами растут, а те, у кого нет, обречены на упадок. Прекрасным примером является приверженность сообщества Python к разнообразию: https://wiki.python.org/moin/DiversityInPython, и, возможно, оно во многом обязано своим ростом попыткам решить проблемы разнообразия. Лично я всегда находил сообщество Python исключительно приветливым.

C # не выживет, если он не будет активно поощрять разнообразие в отрасли.

Выводы

Я не думаю, что какой-то один фактор - это дымящийся пистолет, но я думаю, что мы могли бы сделать вывод, что все эти факторы в совокупности создают условия для снижения C # в серверных сценариях.

Скорость или масштаб

Так почему же Java пришла в упадок (а затем отскочила) и почему C # все еще находится в упадке?

Интересно пересмотреть утверждение Боба Ли о том, что в 2011 году людей отвлекло от Java то, что люди ушли в Rails, потому что struts в качестве веб-платформы уступает Rails. Rails решил проблемы, с которыми люди сталкивались при разработке Java, и таким образом преодолел пропасть от первых последователей до мейнстрима. Эти проблемы были связаны с отсутствием инфраструктуры MVC и инфраструктуры CLI, что создавало проблемы чрезмерной сложности, но, прежде всего, увеличивало время сборки для проектов Java по сравнению с конкурентами Rails.

Rails был более продуктивным опытом разработки.

Но позже, когда успешным сайтам пришлось масштабироваться, у Java появились лучшие библиотеки (и среда выполнения), чтобы помочь командам удовлетворить потребности веб-масштабирования.

Итак, один простой ответ - люди перешли на более продуктивные языки и фреймворки для своих сценариев разработки.

Если это правда, то понимание Боба предполагает, что есть две причины для выбора серверной платформы: скорость начальной доставки и затем, в случае успеха, необходимость масштабирования.

Действительно, общедоступная информация говорит нам, что Twitter начинал с Rails, но для масштабирования перешел на Java. Uber начинал с Node.JS и Python, но все чаще переходит на Go.

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

И, конечно же, возможность предложить как скорость (время выхода на рынок), так и масштабирование (библиотека, среда выполнения, даже система типов) была бы чем-то вроде Святого Грааля. Потому что это позволит вам использовать один язык при разработке на стороне сервера от начала до крупномасштабного.

Конечно, это была золотая середина, которую пытались найти Java и C #. Это все еще возможно.

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

Одна большая тенденция, которая может работать против многих действующих компаний, - это переход к одностраничным приложениям и Mobile First, который переместил разработку на стороне сервера от рендеринга Html к выполнению роли сервера API.

Еще одна важная тенденция - это переход от монолитов к микросервисам, помогающий организациям расширяться.

Наконец, рост инфраструктуры по запросу, будь то контейнеры, PAAS или Serverless, создает совершенно новые парадигмы для разработчиков на стороне сервера.

Вчерашние рамки - это не рамки завтрашнего дня. Конечно, этот сбой создает возможность для .NET Renaissance, при условии, что он не растрачивается на вчерашние сражения с акцентом на унаследованные проблемы.

Я бы выбрал набор приоритетов, часто описываемых как Cloud Native, в сочетании с производительностью хорошего инструментария:

  • Микросервисы
  • API First
  • Веб-роли и рабочие роли
  • Запуск в контейнерах, PAAS и бессерверных средах
  • Инфраструктура CLI

Вы можете резюмировать это как: target Cloud Native.

Если вы хотите самостоятельно генерировать данные с помощью Pivotal, вы можете получить отчет Gartner от Pivotal, в котором обсуждается состояние рынка серверов приложений и прогнозируется его снижение с переходом на Cloud Native; в частности, они предсказывают упадок Java EE в пользу таких фреймворков, как Play, Spring Boot и DropWizard, поскольку последний обеспечивает лучшую поддержку подходов Cloud Native. Https://content.pivotal.io/analyst-reports/gartner-market-guide-for-application-platforms Я подозреваю, что очень похожая судьба ожидает ASP.NET, размещенный в IIS. Будущее за автономными процессами, прослушиванием портов и масштабированием с помощью модели процесса.

Несколько ключевых цитат из этого отчета, которые находят у меня отклик:

«Создавайте все новые приложения для облачных вычислений, независимо от того, планируете ли вы развертывать их в облаке: переходите от трехуровневого к MASA и внедряйте минисервисы или микросервисы для повышения гибкости и масштабируемости».

а также

«Отдавайте предпочтение поставщикам, которые формулируют стратегию платформы, которая поддерживает требования современных приложений, таких как развертывание общедоступного, частного и гибридного облака; вычисления в памяти; многоканальные клиенты; микросервисы; обработка событий; непрерывная доставка и управление API ».

Восстановление Java может указывать на то, что наличие правильных продуктов в пространстве OSS для работы с рабочими нагрузками веб-масштаба может быть причиной успешного возрождения Java. Java смогла увеличить масштабирование сайтов, которым больше не нужна скорость. Это было предложение Боба Ли еще в 2011 году, и, хотя трудно найти данные, подтверждающие это, я считаю это возможным.

Конечно, господство Java в этом пространстве не гарантируется. Но многие рассматривают Go как замену Java в тех сценариях, где Java вмешалась, чтобы помочь компаниям, работающим с веб-масштабированием, поскольку преобладают сценарии Cloud Native.

Как статический компилируемый язык, C # должен считать себя конкурентом Go и Java в плане масштабирования. И он должен соответствовать сценариям Cloud Native, чтобы позиционировать себя на сервере.

Я считаю, что люди, которые говорят о «хорошей» работе .NET, заинтересованы в том, чтобы их фреймворк мог конкурировать в этих сценариях.

Ренессанс

Хорошие новости

Хорошая новость в том, что я считаю, что команда ASP.NET действительно это понимает.

Игра, которую они сделали с .NET Core, похоже, решила многие ключевые проблемы:

  • Работает на Unix
  • Быстро
  • Хорошая инфраструктура CLI и поддержка быстрого развития
  • Снижение сложности библиотек, удаление избыточного кода
  • Поддержка разработки API First
  • Поддержка 12-факторного приложения, подходы к разработке (в том числе самостоятельная разработка, масштабирование с помощью модели процесса и т. Д.)

Еще одна ключевая хорошая новость заключается в том, что по мере того, как мы меняем парадигму с микросервисов на функции (бессерверные), C # становится удачным. Наряду с Python, Java и JavaScript он, как правило, доступен на всех ключевых платформах IAAS. Это реальная возможность для сообщества C # поднять шум, став активным участником этих идей и этого пространства. Конечно, присоединится больше языков, что усилит конкуренцию, так что самое время начать говорить об этом.

Конечно, это преимущество первопроходца сводится к тому, что .NET Core работает в контейнерах x-платформы. В этих средах нет необходимости ждать следующего выпуска .NET Core, поскольку библиотеки, которые вы не можете поддерживать в этой версии, в основном относятся к вашим существующим стекам, а не к новой разработке в рамках этой парадигмы.

Помимо Docker и бессерверных сценариев, такие инструменты, как Service Fabric, поддерживают модели PAAS и .NET Core.

Нам нужно поговорить о Рабочих

Но хотя это показывает, что у нас много вариантов рабочих ролей, а также веб-ролей, я беспокоюсь, что мы склонны больше говорить о веб-роли для Server Side .NET и забываем о рабочей роли. Нам нужно изменить этот диалог. Даже если ваш API находится на Node.JS, сложно написать свои микросервисы на этой платформе из-за отсутствия набора текста и т. Д. Java-разработчики уже выбрали доставку микросервисов в качестве ключевого оптимального места, и я считаю, что это так. для C # тоже.

Теперь мы можем использовать там веб-фреймворки, такие как Nancy или ASP.NET, но у нас нет эквивалентов Netty или Spring Boot, и это не обрабатывает сценарии, управляемые событиями. У нас действительно есть хорошая экосистема OSS (Service Fabric, Orleans, Akka.NET, Brighter, Mass Transit, NServiceBus и др.), Которую мы можем использовать, но мы недостаточно говорим в сообществе об этом.

Нам нужно поговорить об Cloud Native

В целом мы недостаточно говорим об Cloud Native. Это похоже на работу, которую используют за пределами сообщества C #. Когда я отправляю доклады по 12-факторным приложениям или другим темам Cloud Native на конференции в ответ на CFP, многие никогда не слышали об этой практике.

Я бы хотел это изменить.

Нам нужно, чтобы больше людей говорили о том, что нужно для работы в этих средах, и как .NET интегрируется с инструментами, которые вам нужны при развертывании микросервисов, такими как мониторинг производительности приложений, репозитории журналов ??, инструменты трассировки ?? и т.п.

Нам нужно поговорить о том, что мы видим как наши версии Netty, Play, DropWizard или Spring Boot. Нам нужно поговорить о том, есть ли у нас новые парадигмы, которые лучше этих.

Эти области особенно привлекательны для сообщества, потому что MS имеет здесь меньшее доминирующее влияние; у сообщества есть реальная возможность активизировать свою деятельность и оказать влияние.

Кто знает, мы могли бы даже внедрять инновации и внедрять новые подходы.

Но только если мы сделаем шаг вперед и начнем разговор о том, как мы создаем приложения на C # для будущего Cloud Native.

У нас есть возможность создать .NET Renaissance для завтрашних рабочих нагрузок, но только если мы, как сообщество, начнем обсуждать проблемы создания приложений для завтрашних сценариев и расширения нашего сообщества, чтобы включить в него новые голоса, а не только те же старые лица и люди.

Нам нужно поговорить о сообществе

Как указано выше, нам нужно говорить о том, чтобы вдохнуть новую жизнь в наше сообщество и привлечь новые лица и большее разнообразие.

Мы отметили этот шаг к новому .NET Renaissance как результат нового движения Alt.NET. Почему?

Alt.NET должен был открыть разработчикам C # глаза на многие шаблоны и практики, происходящие вокруг них, и поддерживать актуальность разработчиков C #: TDD, Agile, SOLID, Design Patterns, POCO, DDD, CQRS и ES и др. Alt.NET был направлен на поддержание актуальности сообщества. Я считаю, что это удалось, и в то время был первый .NET Renaissance, учитывая, что эти методы теперь стали новой нормой для большинства разработчиков C #, работающих сегодня.

Это возрождение Alt.NET означает открытие разработчикам C # глаз на новые разговоры, которые они должны понимать. То, что спросил на днях, я сказал, что чувствую, что столпами будут Unix, Cloud Native, Diversity. Сегодня разработчикам C # необходимо обсуждать эти идеи и работать над их реализацией в нашем сообществе.

Нам нужно действовать быстрее

Неопределенность, связанная с проектом .NET Core, повредила парадигме «быстрого движения» OSS. Хотя ASP.NET Core 1.1 очень удобен, объявления о .NET Core отложили внедрение и перенос библиотек. Возможно, что еще хуже, возможность для новых проектов OSS взять на себя нагрузку на проекты, которые полагались на старые API-интерфейсы, которые больше не были частью поверхности, и, таким образом, предоставить место для новых проектов, идей и людей, чтобы дышать, была растрачена людьми '' жду следующего релиза ».

Если C # рассматривается как привязанный к платформе с медленными графиками выпуска, он будет воспринят, как и Java, как бюрократический. Это больше не мешает разработке на стороне сервера.

Двигайтесь быстро и ломайте вещи

У MS есть желаемое обязательство поддерживать своих существующих клиентов. Но у него также есть ограниченное количество ресурсов. Акцент на поддержке существующих клиентов отвлекает внимание от фреймворков, поддерживающих сценарии Cloud Native, на те, которые поддерживают более старые модели доставки (ASP.NET MVC, WCF и т. Д.).

Одна из причин, по которой новые языки и фреймворки так привлекательны, заключается в том, что они не обременены прошлым и могут развиваться быстрее. Это не просто «новый блеск». В этой модели Go имеет преимущества перед Java и C #, поскольку в нем меньше устаревшего кода, который отвлекает его энергию.

Так что нам действительно нужно меньше беспокоиться об устаревших сценариях, если мы хотим оставаться конкурентоспособными - они присоединятся к нам, когда смогут, - и готовы двигаться быстро и ломать вещи.

Это сложнее для Microsoft, у которой есть обязательства перед своими существующими клиентами, так что именно здесь у сообщества есть возможность взяться за руль, чтобы создать новые структуры, чтобы заполнить пробелы.

Зачем беспокоиться?

Конечно, один вопрос: зачем заморачиваться? Почему бы просто не написать Go или Python и оставить позади C #?

Что ж, я всегда рекомендовал бы вам быть полиглотом и думать о своих навыках сегодня, завтра и послезавтра. Будущее неопределенно, а опыт работы с более широким спектром языков и платформ помогает защитить вас от потрясений.

Так что возьмите парашют на случай, если C # продолжит снижаться. Python - мой, и я, скорее всего, добавлю Go в эту смесь. Не делайте ставку на то, что C # появится завтра, только потому, что он был там сегодня. Мы начали с того, что поместили наши приемочные тесты в Python, а затем развернули его для некоторых сценариев API. Легко внести небольшие изменения, чтобы застраховать свои ставки.

А использование различных инструментов также поможет вам в перекрестном опылении. Вы можете вернуть идеи из этих сред в C #. Alt.NET всегда был ориентирован на то, чтобы смотреть вверх и наружу, видеть, о чем говорит более широкое сообщество, и вовлекать сообщество .NET в эти обсуждения. Раннее движение Alt.NET многому научилось у сообщества Ruby on Rails. Кого мы узнаем от этого времени?

Но учитывая, что многие из нас обладают навыками в C #, а размер установленной базы означает, что C # по-прежнему полезен сегодня. И этот резерв талантов может продвигать свои навыки в завтрашнем дне.

Но для этого сообщество должно начать говорить о сценариях на стороне сервера для C #, которые позволяют ему конкурировать с Java и Go.

Мне нравится C #, это отличный язык, и я встречал замечательных людей, работающих на этом языке. C # может быть столь же полезным завтра или послезавтра. Но сначала нам нужно поговорить о том, как C #, .NET и сообщество будут выглядеть завтра, если мы решим двигаться вперед.

Есть хорошие люди, которые пытаются что-то изменить. Я считаю, что, например, команда ASP.NET делает реальную попытку решить эту проблему. Но им нужно, чтобы мы активизировались. И это должно принадлежать сообществу, а не MS. Давайте продвинемся вперед по C #.

Alt.NET Redux

В Великобритании Alt.NET вдохновлял многих и помог продвинуть их карьеру дальше, чем они могли себе представить. Он отстаивал новый тип сообщества, открытого и коллективного, которое избегало «слова свыше» в пользу действий сообщества.

Я хотел бы еще раз увидеть это волнение. И в рамках этого я хотел бы, чтобы новое поколение разработчиков Alt.NET продвигалось вперед, ведя нас к новому нормальному, а не только к тем же старым (белым мужским) лицам.

Нам есть чему поучиться

Я думаю, это того стоит.

Последний крик перед закрытием.