27 апреля в 17:10

«Через год-два .NET Core потеснит Java на рынке enterprise решений», — Интервью с Jon Skeet, Google

Наверняка, вы знаете, кто такой Джон Скит: №1 на Stack Overflow, автор C# in Depth, одной из лучших книг по .NET, разработчик в Google и 14-кратный MVP. Разработчиков такого масштаба не так много, хватит двух порядков, чтобы их всех перечислить. 19-20 мая Джон приедет в Петербург и выступит на DotNext 2017 Piter.

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



Если говорить конкретно, то обсудили следующие вопросы:

  • Общее направление развития .NET и ошибки Microsoft;
  • Чего ждать от .NET Core в ближайшем будущем;
  • Стоит ли мигрировать на .NET Core, если у вас легаси на .NET Framework;
  • Проблемы и победы .NET на поприще кроссплатформенности;
  • Java vs .NET на рынке enterprise решений;
  • Чем хороши tuples и pattern matching в С# 7, а что стоило сделать иначе;
  • Небольшие, но приятные фичи C# 7;
  • Деградация сообщества разработчиков (и есть ли она);
  • Правильный подход к диагностике багов и постановке правильных вопросов на SO;
  • Гайд по изучению новых языков и платформ;
  • Проблемы с базовыми типами: числа, текст, дата и время;

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

О развитии .NET как платформы


— Приветствую, Джон, начнём с простых вопросов. В последнее время .NET Core и ASP.NET Core развиваются очень быстро и постоянно меняются. Вам, как разработчику, кажется, что платформа взяла верный курс?

— Я думаю, вопрос затрагивает два разных аспекта. Первый — это направление развития платформы, а второе — процесс поиска этого направления: Microsoft стали гораздо более открытыми во всём, что связано с .NET. сейчас почти все стало open source и это здорово. С другой стороны, это влечёт за собой изменения в ряде вещей: например, в процессе принятия решений. Мы будем наблюдать промежуточные шаги, вроде project.json-проектов и KVM. Во времена «старого» Майкрософт с его традиционным корпоративным путем разработки ПО подобного бы точно не произошло, и, возможно, мы сразу увидели бы инструментарий .NET в его текущем виде. Да, в сообществе была полная неразбериха, и лично мне было многое непонятно, но со временем ситуация прояснялась. На этой неделе я задал вопрос на Stack Overflow о том, что же представляет собой .NET Standard Library, и ситуация становится все лучше.

Однако, по-моему, мы как сообщество должны понимать, что преимущество открытости платформы в виде возможности планировать, видеть и влиять на происходящее сопровождается одним недостатком: вы должны либо сознательно игнорировать ещё не финализированные изменения, либо погружаться в них, осознавая вероятность того, что вы просто потеряете время, если эти изменения откатят. Судя по всему, большинству это подходит, и открытость идёт на пользу, но для .NET-сообщества это своего рода культурный шок.

С учетом всего этого нельзя не отметить несколько, как бы сказать… коммуникативных осечек, которые можно легко понять: несложно допустить ошибку при создании принципиально новой версии чего-либо. Конечно, ещё были ошибки с нумерацией версий, с выбором дат релизов, с решениями о готовности. В общем, всё шло не так гладко, как хотелось бы, но это не страшно: в конце концов, никто не совершенен, и мы как сообщество должны это принять. Чем больше видишь, тем больше несовершенства замечаешь. Это что касается процесса развития платформы.

Если же говорить о направлении движения .NET, то здесь я крайне, крайне оптимистичен. Приятно видеть и активное развитие .NET как платформы, и её расширение на мобильные платформы, и то, как Xamarin ложится на всю эту историю. Все это сложно, но вдохновляет, и также наблюдается большой прогресс в языках, в инструментах. На мой взгляд, ситуация в целом прекрасна. Для меня это всё ещё и происходит в то время, когда я работаю над Google Cloud Platform в Google, стараясь сделать GCP отличным окружением для C#-разработчиков, и, конечно, .NET Core — важная часть этого.

Недавно на конференции Google Cloud Next 2017 мы с моим менеджером обсуждали возможность работы ASP.NET Core-приложений на GCP как в App Engine Flexible Environment, так и в контейнерах. И это одна из тех вещей, которые буквально несколько лет назад считались бы нелепыми. Требовалось провести работу с нашей стороны (в Google у нас есть расширение для Visual Studio, позволяющее деплоить в обе среды напрямую из VS), но также в этом не было бы смысла и без того, что Microsoft сделали с .NET Core. Честно говоря, мне кажется, что складывается выигрышная ситуация для всех.

— Я правильно понимаю, что сейчас вы занимаетесь Google Cloud Platform, которая является прямым конкурентов для MS Azure?

— Всё так, GCP конкурирует с MS Azure и Amazon AWS. Вообще, напрямую в разработку «кишков» платформы я не вовлечён. Все те крутые штуки, которые создают мои коллеги — вроде Cloud Spanner, BigQuery, Datastore или различных API машинного обучения — это великолепно, но не приносит пользы С#-разработчику, если он не может это использовать. Так что я создаю мост: у нас есть автогенерируемые библиотеки классов и некоторые новые виды кодогенераторов для упрощения всего процесса. И я добавляю туда немного рукописного кода в качестве клея или обёртки, чтобы сделать всё как можно бесшовнее и элегантнее.

Зачастую, видя автоматически сгенерированный код, можно понять, что он сгенерированный, так как он не очень-то хорош. Моя часть работы — сделать так, чтобы кодогенерация была максимально похожа на естественную. Представьте, что вам нужно получить список каких-либо ресурсов, а на выходе вы получаете 20 ответов на вызовы удаленных процедур, хотя вам надо всего-то проитерировать их, — я занимаюсь тем, чтобы подобные ситуации решались бесшовно и пишу именно такой код — маленькие финальные штрихи, из-за которых общая картина выглядит совсем по-другому.

— То есть ваша работа, фактически, сделать так, чтобы автогенерируемый код мог пройти тест Тьюринга? :)

— Хаха, это было бы замечательно! Я не думаю что мы близки к этому, но он проходит другой тест: когда используешь кодогенератор, то либо чувствуешь себя подчинённым его капризам, либо чувствуешь, что он работает на тебя. Я твёрдо уверен, что в нашем случае разработчик контролирует процесс.

— Возвращаясь к платформе .NET: какие наиболее масштабные изменения следует ждать .NET-разработчикам в ближайшем будущем? На годы вперёд загадывать сложно, но возможно, поделитесь ожиданиями на ближайшие месяцы?

— Всё зависит от того, где вы находитесь. Если ваш проект застрял в эпохе project.json или «я плевал на всё, я до сих пор на VS2013», то есть что наверстывать до последних релизов. Вышла VS2017, вышел .NET Core SDK, всё зарелизили, это больше не beta — и я призываю всех разобраться в том, что это значит. Да, на это нужно время, а документация всё ещё активно улучшается. Но это речь о пути, который надо проделать, чтобы нагнать текущее положение дел.

А если говорить о будущем, следующая глобальная вещь, которая нас ожидает — это .NET Standard 2.0. У нас уже были .NET Standard 1.0, 1.2, 1.3, и т.д. — это не первая попытка облегчения кроссплатформенной разработки относительно portable class libraries. Но .NET Standard 2.0 — это дивный новый мир, покрывающий гораздо больше платформ, чем мы привыкли по десктопному .NET. Будут невероятно умные инструменты, позволяющие использовать библиотеки классов, написанные только под .NET 4.5: их авторы может быть даже их уже не поддерживают, но это не помешает запустить их в .NET Standard 2.0. Кроме того, я верю, что инструментарий становится все более низкоуровневым. Главное убедитесь, что не используете WPF и WinForms, и всё будет хорошо, такую библиотеку можно использовать в контексте .NET Standard 2.0.

Нам обещают именно такой путь развития, и текущий .NET Core SDK не просто хорош, а по-настоящему хорош — огромный шаг вперед по сравнению с тем, что было раньше. И я думаю, Microsoft на этом не остановится. Поэтому, если вы не пишете пользовательские приложения (где, очевидно, UI будет важен, и от платформы будет многое зависеть), вы во многом можете полагаться на то, что .NET есть .NET, и кроссплатформить по полной. Что всё это будет означать в контексте деплоя из Xamarin для Android и iOS — пока непонятно, но мне будет очень интересно посмотреть, как все получится.

— Вы рекомендуете всем по мере возможности переходить на новые версии .NET Core как можно раньше, поскольку он уже стабилен. А что делать с древними .NET 4.0 легаси проектами?

— В таком случае нет необходимости обновляться до .NET Core. Я бы сказал, что если используешь .NET Core со старой SDK, используешь project.json, то вот тогда определённо стоит мигрировать на новый инструментарий как можно поскорее. Торопиться не надо, но в roadmap это добавить стоит.

А если у вас только унаследованное приложение, которое работает только с .NET 4… тут все зависит от конкретного случая: если вы видите у него долгосрочное будущее, то может быть смысл инвестировать время в его обновление до .NET Core есть. Если у вас TargetFramework это .NET 4.0, и вы не используете какие-нибудь сомнительные библиотеки, то, скорее всего сможете просто портировать его на .NET Core и обнаружить, что выбор сред развёртывания сильно расширился.

Скажем, у вас уже есть некоторое количество сервисов, крутящихся на Windows Server, и вы слышите много хорошего о Linux-контейнерах (я в курсе, что существуют win-контейнеры, но в случае с Linux выбор куда шире). Если вы портируете их в .NET Core (а если предположить, что у вас ASP.NET-приложение, то в ASP.NET Core, это немного другое), то выиграете от улучшений тулинга и ширины выбора платформ. Скажем, когда дело дойдёт до Continuous Integration, у вас будет куда больше доступных окружений: вы можете использовать Travis, который не поддерживается Windows: «Эй, это не проблема, я всё также могу запускать тесты на Travis в рамках моей обычной CI». Все эти вещи улучшают жизнь.

Конечно, это относится не ко всем. Если у вас старое приложение, в котором не ожидается больших изменений, и которое в идеале вообще будет заменено в ближайшее время, то вся работа по портированию будет бессмысленна. Но я думаю, мы склонны недооценивать время, которое проект будет находиться в продакшене, и то количество изменений, которое ему предстоит. Не стоит думать «ничего, вот тут допилю, соберу билд на какой-нибудь старой VS или типа того, в конце концов, таких изменений больше толком и не будет». После того, как вам придётся сделать 20 подобных изменений, год за годом расходуя силы на деплой в устаревших окружениях, вы наконец придёте к мысли «мне стоило постараться раньше и перейти на что-то более современное».

Кроссплатформенность .NET и конкуренция на рынке серверного enterpise


— Понятно. Есть ещё вопрос о кроссплатформенности .NET: вы действительно думаете, что поддержка многих платформ — это хорошая идея? Вы уже упомянули, что у вас огромная инфраструктура, но сможет ли .NET соперничать с Java в категории кроссплатформенного энтерпрайза и бэкенда?

— Абсолютно! Я бы сказал, что это не просто хорошая идея для .NET, это необходимая идея для .NET. Я считаю, что судьба .NET в виде Windows-only платформы с поддержкой сторонних не-очень-то-хорошо-поддерживаемых окружений, нишевых платформ, с которыми люди больше страдают, чем работают, никогда не была перспективной. Так что это была необходимая работа, которая не просто высвободила большой потенциал, но также и не позволит .NET устареть через несколько лет. Я думаю, не-кроссплатформенным серверным решениям придётся несладко. Мы видим то же с окружениями, которые раньше были Linux-only или относились к среде Windows как к «бедной родственнице»: в Windows появилась поддержка для Ruby и Python, которая с течением времени стала заметно лучше. То же самое с Git… Да даже Bash (Shell) теперь есть на Windows. Я думаю, что мультиплатформенность сейчас — это «прожиточный минимум».

— Понятно. Не могу не задать холиварный вопрос: что вы думаете про .NET в сравнении с Java? Особенно на энтерпрайз-рынке, который, насколько я понимаю, глядя на работу Microsoft над Azure и энтерпрайз-инфраструктурой, является одним из целевых для компании.

— Я бы сказал, .NET определённо может конкурировать с Java, и если быть честным, я лично всегда предпочту разрабатывать на C#. Просто потому что сам язык намного лучше.

Тем не менее, у Java есть определенные преимущества: гораздо больше библиотек с открытым кодом (хотя не факт, что они лучше), больше вариантов решения какой-либо проблемы. Если ты выбираешь фреймворк вебсервиса, в Java у тебя, скорее всего, будет не менее 30 вариантов, а в .NET, возможно, 5. Но в любом случае использовать вы будете только один из них, так что в случае, когда и в Java, и в .NET есть хотя бы один хороший вариант, разнообразие Java помогает, но в то же время может сбивать с толку. А если нет доминирующего игрока, разнообразие только усложняет процесс поиска хороших решений. Так что, если вы хотите просто найти фреймворк с хорошей реализацией, это получается почти преимуществом на стороне .NET.

Кроме того, существует инерция. Мы знаем, что в мире много энтерпрайзных Java-программистов и приложений, и я не думаю, что многие люди скажут «Давайте возьмем это работающее Java-приложение и перепишем его под .NET». Скорее будет так: «Нам по-любому переписывать приложение, поэтому надо выбрать из парочки платформ». А если вы создаете новое приложение — неважно, веб-приложение, сервис или что-то подобное, я думаю, в этом случае Java и .NET должны идти ноздря в ноздрю. Я предполагаю что энтерпрайз будет остерегаться .NET Core ещё год-два, пока он не докажет свою состоятельность, но после этого ожидаю рост использования в энтерпрайзе, и тогда преимущества C# должны дать о себе знать.

— Да, я понял, спасибо. Я не буду здесь затрагивать более developer-friendly JVM-языки, потому что мы здесь не для холивара :) Но у меня ещё один вопрос: у вас уже есть реально накопленный опыт актуального живого опыта разработки приложений или сервисов под Linux на .NET?

— Вообще я не разрабатываю приложения в чистом виде, но недавно для Google Cloud Next 2017 вместе с моим менеджером мы внедрили очень маленькое веб-приложение на ASP.NET Core, которое я потом задеплоил в контейнер в AppEngineFlexible Environment. В таком масштабе — да, опыт есть. Также сайт Noda Time построен на ASP.NET Core, сейчас он задеплоен на Windows, но я надеюсь перенести его на Linux, и я не вижу абсолютно никаких причин, почему оно не должно заработать из коробки.

И по моему опыту, .NET Core для Linux очень хорош, пока вы используете только его. Места, в которых я нашёл проблемы, были в билд-скриптах: только сегодня утром я установил VS Code на мой Linux box, и с Noda Time всё было прекрасно для netcoreapp и netstandard-версий, но при попытке собрать код для .NET 4.5.1 оно сказало: «Эй, я понятия не имею что такое .NET 4.5.1» — поэтому потребовалось включить в билд пару ссылок на референсные сборки. Итак, если вы абсолютно кроссплатформены и нацелены только на .NET Core, я думаю всё хорошо, но если у вас уже есть несколько сборок, где некоторые куски кроссплатформенны, а другие привязаны к полному .NET Framework, тогда все не так хорошо, как хотелось бы. Я уверен, MS работают над этим, и я сам бы мог исправить ситуацию установкой референсных сборок в определённых местах, но я не хочу запускать Windows-код под Linux — я просто хочу кроссплатформеннный код. И эта часть, как я уже сказал, особенно хороша.

Пара слов о С# 7


— Поговорим о С#. Версия C# 7 уже вышла и доступна в VS 2017, у нас есть классы кортежей (tuples), pattern matching и другие фичи. Что вы как девелопер думаете об этом релизе и новых фишках? Будут ли они широко использоваться? Или вы бы предпочли, чтобы язык получил какие-то другие примочки?

— Я крайне доволен C# 7. Сейчас я пишу о нём в четвёртом издании «C# in Depth», поэтому узнаю его гораздо лучше, чем раньше. Прямо сейчас я пишу о кортежах (tuples), фиче, которая выглядит простой, но имеет много скрытых мелочей. Изначально я настороженно относился к кортежам, но теперь вижу их преимущества в реализации. В чём я сейчас не уверен, так это стал бы ли я писать публичные API и выставлять кортежи наружу. Это решение ограничивает разработчиков языка легковесным неинкапсулируемым возвратным типом. В то время как, если возвращать определённый класс, это можно было бы улучшить с течением времени.

Кортежи станут большим подспорьем для ленивых разработчиков, а мы все должны быть в какой-то мере ленивыми. В пределах определённого класса или даже библиотеки, использующей кортежи (tuples) как легковесный способ группировки переменных вместе, всё должно быть круто.

Другая важная фича, которую ты упомянул — pattern matching. И самое ценное в pattern matching в С# 7 — это не паттерны, которые мы получили, а введение самой идеи паттернов. Я сознательно разделяю эти понятия. В данный момент мы можем использовать паттерны в операторе «is» и в switch cases. Единственные паттерны, которые у нас есть сейчас — это эквивалентность и совпадение типов. Так что можно или задать «case x is 5», и найдётся совпадение, если значение равно 5, или можно искать совпадение по типу: «x is String». Ранее type matching вызывал возражения, но на практике оказался реально полезным.

Я уже принял первый C# 7 пулл-реквест в Noda Time от моего друга Билла Вагнера, и этот пулл-реквест наглядно показывает преимущества pattern matching на конкретных примерах. Но на самом деле это показывает извлечённые уроки из F# и Haskell, позволяющих описать функцию через то, как она будет вести себя в разных ситуациях — это по-настоящему понятный путь описания по сравнению с if-else-if-else-if-else. Когда мы говорим «этот case соответствует такому результату, а этот такому», по сути, мы делаем то же, что и if-else, но в гораздо более простом для понимания виде. Все это выглядит многообещающе, и я надеюсь, что в каких-то промежуточных релизах, вроде C# 7.1, мы увидим больше паттернов, таких как деконструкция значений.

Представим такую ситуацию. У вас есть DateTime, вы можете деконструировать его и найти с pattern matching случаи, где год больше 2016. Вы можете сделать нечто подобное и в C# 6, но поиск соответствий не будет использовать деконструкцию. Так что pattern matching в будущем может дать ещё многое. Это самые большие фичи С# 7, и их не стоит недооценивать.

Другое большое преимущество для большинства ASP.NET Core пользователей лежит в плосткости async/await: если раньше async-метод мог вернуть только Task, Task или void, то теперь можно вернуть что угодно, совпадающее с определённым паттерном (но это не то же, что pattern matching!), если там есть атрибут, говорящий если ты не создаёшь значение данного типа, используй эту фабрику». Я не думаю, что многие люди будут применять этот паттерн в своем коде, но они могут использовать имплементацию других людей. И ValueTask — более легковесную версия Task — будут использовать почти все, это структура, которую команда ASP.NET Core оптимизировала различными способами, и она будет особенно полезна в ситуациях с низким временем отклика, когда хочется получить все преимущества async, но при этом не нагружать GC заботой о лишних Task-объектах. На мой взгляд, это интересная фича, которую многие будут использовать, не вникая в детали «как имплементировать свой собственный возвратный тип».

Если просто посмотреть на список фич, то C#, помимо крупных нововведений, получает и небольшие — штуки вроде ref-local и ref-return, довольно сложные для понимания (по крайней мере, для меня). Я полагаю, они будут весьма полезны для Unity-разработчиков высокопроизводительных игр, которые весьма чувствительны к определённым аспектам перфоманса, вроде GC и тому подобного — есть ощушение, что они используют structs больше, чем другие разработчики.

Также есть замечательные маленькие улучшения вроде out-переменных: возможности объявить переменную в то же время, когда вы используете её для аргумента для выходного параметра, так что больше нет необходимости объявлять:

int x;
if (int.TryParse("some text", out x))
{
// ...
}

достаточно просто if (int.TryParse("some text", out int x)), это объявит и распарсит одновременно. Это просто устранение маленького неудобства, и оно показывает намерения проектировщиков C#: везде, где есть какой-то дискомфорт и приходится писать какой-то код, который не хочется писать, потому что он выглядит некрасиво, это исправляют. И out-переменные помогают в этом, как и числовые литералы.

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

О сообществе разработчиков и умении диагностировать проблемы


— Я думаю, на этом мы закончили с вопросами по .NET, но у меня есть еще пара более общих вопросов. В данный момент вы #1 в рейтинге Stack Overflow — вы годами отвечали там на тонны вопросов. Можете ли вы сказать, эволюционируют ли разработчики или становится всё больше глупых вопросов?

— Дело не в том, становятся ли программисты умнее или нет. Я бы сказал так: в ранние периоды вопросы на Stack Overflow были в целом качественнее, так как сайт был не так популярен. Уже давно его использование стало обычным делом, но сейчас это повсеместная практика — а это означает, что менее опытные разработчики, которые были всегда, теперь с большей вероятностью задают свои вопросы. Кроме того, множество хороших вопросов были заданы давно и остаются актуальными и по сей день, и если их задают сейчас, их по вполне понятным причинам закрывают как дубликаты. И я поймал себя на том, что я меньше отвечаю на вопросы, зато оставляю куда больше комментариев вида: «Вам следует попытаться продиагностировать проблему чуть глубже до того, как задавать вопрос, вот несколько советов, как это сделать, а пока что вопрос не очень хороший по содержанию». Я куда больше времени трачу на это, чем непосредственно отвечая на вопросы, потому что, по сути, сейчас не так много вопросов, на которые требуется ответ. Хотя в свете выхода C# 7 должны начать появляться хоршие вопросы конкретно об этой версии.

Нельзя сказать, что разработчики хуже, чем они должны быть, или что не осталось интересных вопросов. Просто баланс слегка сместился… А вто что меня действительно расстраивает: я вижу множество неопытных разработчиков (часть из которых не считает себя неопытными), демонстрирующих невнимание к другим людям. Они просто думают: «У меня есть проблема, но я не собираюсь сам искать решение, поэтому я попросту задам вопрос», — после чего идёт либо простыня кода, либо вообще никакого кода и фраза: «У меня тут проблемка, можете помочь?». Мы действительно сталкиваемся с вопросами, где нет никакой информации, кроме такой. Хотелось бы, чтобы люди прикладывали больше усилий к формулировке вопроса или учились исследовать проблему, если у них пока недостаточно навыков в диагностических техниках. Когда я учу новый язык или у меня возникает проблема, я всегда пытаюсь свести пример к необходимому минимуму. Ведь даже если люди ожидают, что я знаю ответ, это не всегда так.

Некоторое время назад я написал блог-пост о том, как запускал некоторые тесты на NUnit для Noda Time, и по каким-то причинам на Linux они работали сильно медленнее, чем на Windows. Следует заметить, что я запускал тесты с локалью en-uk, где было немного кода на NUnit, и в итоге оказалось, что он приводил к использованию String.EndsWith() на каждый assert.EndsWith() делает проверку с учётом локали, хотя NUnit это не требовалось, в итоге это было исправлено. В итоге я обнаружил, что эта проверка и вызывала проблемы. Это было примерно так:

  1. я вижу, что это занимает очень много времени
  2. задаю себе вопрос — это мой код тормозит процесс, или какой-то другой?
  3. я нашёл один тест, который показал проблему
  4. далее я убрал столько кода, сколько мог из этого теста
  5. после этого я исключил Noda Time, написав маленький проект, запускающий NUnit вообще без логического кода
  6. после чего исключил NUnit из схемы, покопавшись в коде NUnit-код и найдя проблему «ааа, String.EndsWith(), окей, давай посмотрим, как оно выполняется»
  7. в этот момент я уже мог воспроизвести проблему с кодом 10 строк длины, запускавшим String.EndsWith() в цикле тысячи раз
  8. стало понятно, что именно этот код на Linux отрабатывал медленно, а на Windows очень быстро
  9. и предоставив всю эту информацию на SO, я смог получить ответ о том, что причина в локали: она оптимизирована под Windows с UK English и не оптимизирована для Linux
  10. в итоге я смог подтвердить это путём запуска этого куска на US English, который был быстр и на Linux.

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

И я обнаружил, что многие люди не знают, как это делать, или просто не запариваются — они предпочитают задавать вопросы. Еще многие прыгают с головой в языки и платформы до того, как будут действительно готовы. Лично я пытаюсь изучать вещи по одной, зато как следует, но есть куча людей, которые говорят: «Я совершенно новенький в программировании. Сейчас я пишу приложение под Android на Java, взаимодействующее с SQLite. И этот код не работает», — окей, а это проблема Java, проблема Android или проблема SQLite? Вряд ли все три сразу. Что вы сделали, чтобы понять, что является источником проблемы? Поймите, я не докапываюсь, я пытаюсь научить людей помогать самим себе. Я твёрдо убежден, что понимание «как работает мой язык», отдельное от «как работает моя платформа» — это реальное преимущество в отношении того, как быстро вы сможете разобраться и начинать применять что-то при изучении нового.

— Что вы посоветуете начинающим программистам для относительно гладкого старта в целом или на какой бы то ни было платформах? Стоит ли мне обучаться самостоятельно, или лучше начать с фундаментального образования? На что делать в первую очередь?

— Учиться можно по-разному, рекомендую начать с книги, — я сам автор, так что это и в моих интересах тоже, но мои книги не предназначены для новичков. Я пытался написать книгу формата «С# для начинающих», но это сложно. В целом, я бы выбрал конкретный язык, и большинство языков подходят для того, чтобы освоиться в них с нуля, если есть подходящий обучающий материал. Так что просто найдите книгу, и убедитесь, что она относительно свежая и охватывает последние изменения языка/платформы. Я бы не начинал с платформ, на которых сложно заниматься диагностикой.

При изучении новой платформы или языка я всегда начинаю с небольшого консольного приложения, если там вообще есть консоль. С JavaScript сложнее, если только не учишь Node.js или что-то подобное. Для обычных языков вроде C#, Java, Ruby, Python убедитесь, что у вас есть набор инструментов, подходящий для старта. И не пытайтесь сразу сделать веб-приложение или веб-сервис — начните с маленького консольного приложения. У меня есть небольшой набор приложений, которые я пишу на старте. Одна из них — игра, которая загадывает число, а задача пользователя за 5 попыток угадать его, а она говорит, твой вариант больше правильного, меньше или правильный.

Разработка подобной программы отлично подходит в качестве первого шага овладения языком, потому что нет необходимости знать много о структурах данных, которые поддерживает платформа, о том, как работают словари и другие подобные вещи. Но ее достаточно, чтобы начать. А после этого уже можно сказать: «Окей, теперь я знаю, как выводить в консоль, как читать из консоли». Это может быть не слишком нужно для веб-приложения, но просто необходимо для диагностики: можно разбираться с кодом в отладчике, и вы скорее будете делать это в консольном приложении, чем в iOS-приложении, например. Я уверен, что под iOS отладочные инструменты тоже есть, но их гораздо сложнее понять, пока вы не погрузитесь в язык полностью.

Как я уже упоминал, этот первый шаг не затрагивает словари, списки, функции и тому подобное. Поэтому дальше начинайте писать следующее консольное приложение, которое покрывает все эти возможности, например: «создать список Strings и сделать на его основе другой список из перевёрнутых Strings» — маленькое приложение, которое делает только это. И если у вас появятся какие-либо проблемы, вы будете знать, что проблема только в понимании той конкретной темы, над которой вы сейчас работаете. Если вы хотите создать бесподобное приложение или игру, то держите это в голове. Но никогда не начинайте погружение в проект с нее. Вам нужен серьёзный фундамент, прежде чем создать что-то большое. Это всё равно что сказать «Мне хочется пробежать марафон, так что завтра, никогда раньше не бегав, я пойду и пробегу марафон». У вас не получится, это деморализует вас, и это только навредит вам — до этого нужно дорасти. Так же и с программным обеспечением.

Сложности в создании компьютерной модели реального мира


— Ого, последний пример хорош. Вот о чем я еще хотел спросить, в своем докладе для DotNext «Back to Basics» вы говорите о связи между реальной жизнью и моделями, которые мы создаём в разработке ПО: типами данных, структурами и тому подобным. Что-либо поменялось в этой области за последние пару лет?

— Доклад посвящён трём наборам типов: как компьютеры взаимодействуют с числами, текстом, и датой/временем. В широком смысле за последние годы ничего не поменялось, легче точно не стало, возможно, даже стало слегка сложнее из-за Unicode как общемирового способа работы с текстом. Существует 65536 кодовых пунктов, некоторые из которых не назначены, и всё это называется Basic Multilingual Plane. А есть ещё другие planes, и раньше я мог говорить «можете их игнорировать, всё, что вам когда-либо понадобится, есть в BMP», так что не нужно беспокоиться о представлении не-BMP символов как пар BMP. И даже это уже неправда из-за эмодзи! 10 лет назад можно было никогда встретить символ не из BMP, а теперь большинство людей, читающих это интервью, видят как минимум один не-BMP символ в день.

Вот пример: у вас есть поле ввода, где пользователь может набрать не более 10 символов, что это значит? Даже без BMP вы можете иметь «e» с острым ударением на нём, и это может быть представлено как двумя символами, так и одним, в зависимости от нормализации. То же самое работает для emoji: в Java и .NET, если вы используете String.Length(), увидите длину два символа для каждого символа эмодзи. Значит ли это, что пользователь может ввести всего пять? Это будет странно с точки зрения пользователя: им говорят, что у них есть десять символов, но они могут ввести только пять. Так что да, эмодзи сделали жизнь сложнее.

В отношении чисел, похоже, ничего не изменилось. В отношении даты и времени с момента, когда я выступал с этим докладом впервые, кое-что поменялось на фронте .NET: Noda Time, моя собственная библиотека для работы с датами и временем. Она дошла до релиза, а сейчас я уже выпустил версию 2.0. Я бы сказал, что в случае с датой и временем всё постепенно становится лучше, всё больше людей проникаются пониманием, что проблема существует. У меня есть пара друзей, которые работают над улучшением основных типов даты и времени в JavaScript и добавлением новых, потому что мы использовали Date в JS очень долго, а оно во многих случаях работает неправильно. Поэтому они усердно работают над созданием более практичного JavaScript API для даты и времени, чем есть сейчас.

Все развивается, но базовые задачи компьютеров предполагают простые модели, а разработчики считают, что компьютер должен понимать и предметную область, и тогда возникают вопросы вроде: «я разделил 5 на 10 и получил 0, а не 0.5», — ну, стоило использовать числа с плавающей точкой или ещё что.

Вместо заключения


— Да, последний пример ярко демонстрирует тот факт, что люди все чаще вместо самостоятельных поисков задают вопросы в интернете. Поэтому может быть, есть пара вещей, которые хотелось бы добавить к концу интервью для своих читателей — возможно, пару советов?

— Хорошо, я перейду от некоторых очень конкретных идей к некоторым обобщениям:

1. Определённо, попробуйте Noda Time, если вы используете где-либо в вашем коде дату и время. Если у вас есть DateTime.Now() где-то в вашей кодовой базе, то есть вероятность, что у вас есть ошибки. Поэтому я настоятельно рекомендую изучить Noda Time.

2. Если говорить в общем, мне также хочется, чтобы люди больше думали о документации. Есть проект под названием DocFX, который в некотором роде превзошёл Sandcastle, но я думаю, что мы можем сделать намного больше. Дополнительная документация с перекрёстными ссылками между разными элементами. Только представьте мир, в котором документация является достаточно машиночитаемой, чтобы, когда вы ссылаетесь на какую-либо документацию в Stack Overflow, вы просто нажимаете кнопку, начинаете вводить имя типа, и видите предварительный просмотр: «это тот тип, который вы имеете в виду?» Я думаю, жить в таком мире было бы замечательно.

3. Ещё важнее этого разнообразие людей в мире технологий. Я выступаю на многих конференциях, и аудитория, как правило, — белые мужчины, и это расстраивает меня. Нам нужно больше гендерного разнообразия, нам нужно больше расового разнообразия, просто взгляните на статистику… она расстраивает. Каждый должен участвовать в искоренении всех форм сексуального домогательства, всех форм расизма в нашей отрасли. Более того, поощрять окружающих, понимать подсознательные предубеждения и бороться за то, чтобы создать как можно более равное условия деятельности для всех.

Если отстраниться от нашей индустрии, мои личные интересы — это гендерное равенство в целом, скажем так, я уже 2,5 года начинающий феминист. Поэтому я рекомендую всем прочитать что-то вроде «Everyday sexism», чтобы посмотреть, как этот мир выглядит с точки зрения других людей. Все это довольно страшно, и это, безусловно, изменило мой взгляд на многие вещи.



Отдельно хочу поблагодарить Женю phillennium Трифонова и Андрея DreamWalker Акиньшина за помощь в подготовке поста. Плюсы вам в карму!
Автор: @ARG89
JUG.ru Group
рейтинг 344,20
Конференции для взрослых. Java, .NET, JS и др. 18+

Комментарии (530)

  • +13

    Ага когда выпустили .NET говорили что он убьет java очень скоро, мс даже спец программу организовало JUMP — Java User Migration Path. Не выгорело тогда, не выгорит и сейчас. MS с core конопашуться уже больше года, у java jigsaw должен выйти этим летом, не все так просто.

    • +18
      Так никто не говорит об убийстве. Речь о возможности выбора и здоровой конкуренции.
      • +5

        Выбор есть и сейчас. Вы уж простите но слышать о здоровой конкуренции в отношении MS как то без тика не получается.

        • +13
          С Oracle получается?
          • 0

            Не Oracle единым жива java, хвала аллаху.

            • +8
              Не Microsoft единым жив .Net ;)
              • +2
                А чем еще он жив? Не продвигай Microsoft активно свой продукты среди студентов и университетов, ситуация с .NET была бы в худшую сторону
                • +11
                  Да, именно на студентах .Net и держится. (до оракла у Sun были Java ambassador если что).


                  • –14

                    смешно видеть на этой картинке JetBrains, которые даже под .net (resharper) пишут на Java/Kotlin ;)

                    • +19
                      Смешно читать такие глупости на хабре
                    • +5
                      Решарпер-то как раз на .NET. Вот тут они пишут про проблемы с ним на Mono.
                    • +5
                      решарпер написан на c#. Вы путаете с графической оболочкой написанной на java. Даже доклад про то, как они делали протокол общения между рантаймами
                      • +1
                • +7
                  Как минимум есть еще Unity, в котором большинство людей предпочитает использовать именно c#, несмотря на кучу других вариантов языков. А это уже очень большой приток людей.
                  • 0
                    Нет в Юнити никакой кучи языков. Кроме C#, были еще UnityScript и Boo, второй уже окончательно похоронили давно, первый собираются похоронить со следующей версии. Так что да, практически все пишут на С#
                    • +2
                      Простите что вмешиваюсь, а разве Javascript в Unity не было?..
                      • +2
                        Был UnityScript, который все называли JavaScript. Между ними огромная пропасть, но если не присматриваться, то было похоже на JS. Всего лишь завлекалочка для новичков и веб-разработчиков.
                      • +1
                        Javascript в Unity отличается от стандарта и называется UnityScript.
          • +4

            Java заняла нишу enterprise когда oracle был ещё не при делах. Тогда это был ещё Sun.

        • +2
          А о здоровой конкуренции в отношении Oracle? Это ещё менее вероятно.
      • +3
        Ждем IDE уровня IntelliJ IDE написанную на .NET и кроссплатформенную при этом. Тогда можно будет говорить о переходе.

        Уточню — целиком на .NET. Проект Rider — не то. Хотя если имплементировать какой то бекэнд, который сможет воспользоваться наработками Rider…

        Там Visual Studio еще не портировали на Linux?
        • 0
          • +11
            Visual Studio Code и Visual Studio это две совершенно разные вещи.
            • +8

              Это как Java и JavaScript. Обречены на неразбериху во имя маркетинга.

          • +4
            Во первых это не Visual Studio, как заметили выше. В качестве текстового редактора я могу и ViM (Sublime, emacs, etc.) использовать.
            Во вторых достаточно того что и во первых это приложение на Electron. Увы :(
        • +4

          Какое отношение эта гипотетическая IDE имеет к энтерпрайзу?

          • +3
            Показатель зрелости платформы. Наличие на Linux/MacOS IDE для .NET написаной на этом самом .NET означает возможность писать самые разнообразные приложения(desktop + server).

            Уточню — это лишь мое мнение, но в любом случае — в чем то же надо писать код? Пока что я не вижу IDE уровня IntelliJ IDEA или Visual Studio под эти платформы (да даже не важно на чем оно написано). Ежели я ошибаюсь — прошу меня поправить и указать на мою ошибку ссылкой.
            • 0

              Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.


              Используют же некоторые дизайнеры MacOS чтобы рисовать интерфейсы под винду...

              • +4
                Вообще-то, между «писать код» и «рисовать интерфейсы» имеется принципиальная разница. Но т.к. целевая аудитория маркетоложцев эту разницу не знает, то в рекламе Ваш аргумент вполне сгодится.
                • +1
                  Ну вообще-то куча всего для мобильных устройств /приставок/всякого специального железа пишется в Винде отлаживается в ней же или в эмуляторах, и никакая «принципиальная разница» никого не.

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

                Мне не повезло познакомится с линуксом в раннем возрасте и учиться писать код я начинал именно с линукса. С тех пор родовая травма — не могу использовать Windows для разработки. Точнее могу, но это неприятно.
              • –1
                Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.
                Мешает. Для того, чтобы использовать «default operating system» в местах, где она не «default» нужна уйма инфраструктуры. Kerberos и LDAP использовать нельзя, нужны сервера на Windows и масса плясок с бубнами, чтобы две операционки подружить. Это для начала. А потом выяснится что и принтеры нужно особо поддерживать и прочее.

                Понятно, что живущие в «default operating system» об этом не задумываются (как и живущие в «default city»), но Microsoft Windows — это «остров, у которого всё своё». Собственно это специально сделали — и этот подход отлично работал: стоит вам использовать хоть что-то от Microsoft — и вам придётся использовать массу других вещей от них же. Но в Enterprise — всё не так: не нужен там никакой Microsoft (у них Oracle рулит и стонут они от него так же, как от Microsoft'а стонет малый бизнес — но это другая история), так что IDE под «default opertaion system», извините, не вариант.

                Собственно Microsoft это осознал примерно тогда же, когда и все остальные — но, увы, если «стены» стоить десятилятеями, то дальше их разрушить за пару лет — не выйдет.
                • 0

                  Э… а конкретные примеры того, что нельзя подружить, будут?


                  Для меня, как для программиста, все довольно понятно — есть задача, есть протокол/формат/что-то еще, есть библиотека, пишу решение. Если нет библиотеки — пишу решение дольше, с перспективой создания библиотеки.


                  В какой момент возникают пляски с бубнами, которые не позволяют мне писать решение для задачи?

                  • –1
                    Э… а конкретные примеры того, что нельзя подружить, будут?
                    А того, что написано выше — недостаточно?

                    В какой момент возникают пляски с бубнами, которые не позволяют мне писать решение для задачи?
                    В тот момент, когда вы решили, что хотите использовать «default operation system».

                    Вспомните ещё раз: мы тут про «ынтырпрайз», да? Ну и хорошо, понеслась. Для доступа в Internet — у вас какой-нибудь Uberproxy с правами доступа в LDAP и авторизацией через Kerberos. Печатаете вы через CUPS, общие файлы — выкладываются на NFS, а управляется это всё — через Ansible.

                    И вот вы во всё это желаете вкрутить вашу «default operation system». Кто будет «дружить» эти два мира? Притом, что Windows-админы, которых вы можете найти на рынке обычно — «ни в зуб ногой в области POSIX-технологий», а POSIX-админам — ваши «default operation system» со всеми их заморочками — не нужны от слова «совсем»?
                    • –1

                      Все еще не понимаю, зачем в такой структуре нужны виндовые серверы.

                      • –1
                        Они не нужны. Как и виндовые десктопы для разработки :)
                    • 0

                      А, я понял. Вы рассматриваете гипотетическую ситуацию, когда какая-то совтописательная фирма с инфраструктурой только на линуксе пытается начать писать на .NET.


                      Да, это может внезапно оказаться довольно сложным процессом.


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

                      • 0
                        Вы забыли время на изучение инфраструктуры для разработки на этом языке и время на изучение ОС. Разработчики они разные. Я вот Windows дома не держу уже несколько лет.
                        • –1
                          ок, тогда что вы тут в комментариях делаете? Да, вам .net core не подходит, это стало понятно из комментариев выше, мне это было важно и дествительно интересно услышать. Но если вам он не подходит, не значит что не подходит другим.
                          • 0
                            Внезапно! Они утверждают, что .NET пригоден для разработки под Linux без лишних телодвижений!

                            Вот я и пытаюсь понять, они немного преувеличивают, преувеличивают нагло или же все хорошо и можно писать код?

                            Пока что получается, что преувеличивают нагло и среднестатистический разработчик не желающий использовать Windows удобным образом писать под .NET не сможет. Согласны?
                            • 0
                              Собственно в этом весь смысл всех этих телодвижений. Как уже говорилось много лет назад: Microsoft категорически не заинтересован в том, чтобы люди могли использовать их инструменты без их экосистемы. Попытку сделать так, чтобы люди использовали везде и всюду только и исключительно экосистему Microsoft провалилась. Таким образом приходится мириться с существованием других систем и пытаться сделать так, чтобы разработчики туда не убежали.

                              Ну подумайте сами: какой смысл Microsoft'у делать хоть что-то для того, чтобы улучшить жизнь разрабочиков, использующих не Windows?
                      • 0
                        Но конкретному разработчику, в отличие от организации, перейти на новый язык довольно просто.
                        Читаем заголовок статьи, которую мы тут обсуждаем, да?
                            Через год-два .NET Core потеснит Java на рынке enterprise решений

                        Это у вас «конкретный разработчик» не связанный ни с какой организацией играет на рынке «enterprise решений»?
                        • 0

                          Все проекты делаются конкретными разработчиками.

                          • 0
                            Вот только в случае с «enterprise решениями» они, как правило, работают не в одиночку, а в команде. И интересы пресловутого «enterprise» в 100 раз важнее интересов конкретного разработчика.

                            Разработать без интеграции с существующими решаниями вам дадут разве что «приложение» для заказа пиццы в офис. Во всех остальных случаях — я придётся учитывать и ограничения вещей, созданных 40 лет назад на Cobol'е и 10 лет назад на Java.
                            • 0

                              Не вижу никаких проблем интегрироваться с чем-то, созданным 40 лет назад на Cobol или 10 лет назад на Java.

              • +1
                Т.е. Вы предлагает к ИДЕ докупить еше и винду + выделить для нее машину (виртуалку), только чтобы…?
                • +6

                  Удобный язык программирования — это вполне достаточный повод купить винду, IDE и даже новый компьютер. Если вы и правда квалифицированный энтерпрайз-разработчик, чье время ценно.

                  • –2
                    Если вы и правда квалифицированный энтерпрайз-разработчик, чье время ценно.
                    Если вы «квалифицированный энтерпрайз-разработчик, чье время ценно», то вы в гробу видали «винду, IDE и даже новый компьютер», зато, возможно, неплохо знаете Cobol.

                    В мире энтерпрайзра Windows — так и не стала «default operation system», несмотря на все потуги (если бы стала — рассказов про то, что она вот-вот «всех порвёт на энтерпрайз-рынке» не было бы). Так что вам, в прикуску к «новому языку» придётся одновременно изучить новую OS и новую IDE.

                    То есть вы должны быть фактически готовы переехать в другую страну, выучить новый язык, сменить машину, работу и жену — и всё это ради каких-то мифических плюшек этого языка, про которые вы заранее ничего не знаете?

                    Вы точно уверены, что вы всё ещё «квалифицированный энтерпрайз-разработчик, чье время ценно», а не «безбашенный стартапер, которому семь вёрст не крюк»?
                    • 0
                      В мире энтерпрайзра Windows — так и не стала «default operation system»

                      AD и Exchange есть у всех, даже в Яндексе с Фейсбуком.
                      • 0
                        А можно чуть подробней про Exchange в Яндексе? Зачем он им?
                        • +1
                          OWA извне больше недоступна, есть только Autodiscover:

                          Non-authoritative answer:
                          Name:    exchange-2013.yandex-team.ru
                          Addresses:  2a02:6b8:0:3400::1:25
                                    213.180.205.25
                          Aliases:  autodiscover.yandex-team.ru
                                    amber.yandex-team.ru
                                    amber-2013.yandex-team.ru
                          

                          Подробности надо спрашивать у яндексоидов, думаю оставили для бизнеса привыкшего к удобству: достойных конкурентов связке Outlook + Exchange так и не появилось.
                      • 0
                        Одно дело — иметь тестовый стенд для разработки Windows-приложений, совсем другое — давать доступ в корпоративную сеть.
                        • 0
                          Большинство российских банков использует AD для авторизации/аутентификации, хотя бизнес-приложения могут крутиться на Linux, AIX или OS/400.
                          • 0
                            Продакшен-системы мобильных операторов тоже. Лично писал надстройку над OpenLdap для интеграции нашей Linux-системы — нахождения нужных данных в распределенном по разным серверам дереве AD.
                  • –3
                    В моей жизни было полгода(с конца августа по середину марта) когда я вынужден был использовать Windows 7 как ОС для разработки на Java.

                    Спасало только наличие неплохого GUI в IntelliJ IDEA. Любой шаг в сторону от стандартного флоу «закодил — > запустил тесты -> закоммитил» был тяжек и труден. Все что в линуксе решается в одном окошке консоли на винде требовало больше усилий и движений. В гробу я видал Windows 7 как ОС для разработки на Java.

                    Если работа в энтерпрайзе требует работы на винде — к черту такую работу, я лучше продолжу писать тулы по автоматизации тестирования или переквалифицируюсь хипстеры :)

                    P.S.: Удобное рабочее окружение — это повод купить Mac. Однако не все могут согласиться с этим.
                    • 0

                      Пытаюсь вспомнить какие лишние движения мне приходится совершать при ежедневной разработке — и не могу. Разве что установка нужных программ вспоминается — но она делается всего один раз.


                      Мне кажется, это просто сказывалась субъективная непривычность обстановки, а не какие-то объективные недостатки.


                      Не могли бы вы уточнить что именно требовало у вас избыточного числа движений?

                      • 0
                        1. Работа с Git
                        2. Работа с удаленными серверами по SSH
                        3. Сборка проекта с нестандартными параметрами
                        4. Обработка данных при помощи простеньких скриптов

                        Поясню на примере — для выполнения этих задач в Linux мне требовалось всего одно окошко терминала в котором я мог все эти задачи выполнить одинаково хорошо. В Windows это требовало 4 разных окошек — Git Bash, SuperPutty, окошко запуска команд в IntelliJ IDEA и наконец Cygwin. Половина из этих инструментов не кастомизировалась или кастомизировалась весьма не просто в плане внешнего вида(банальные шрифты).

                        Этого достаточно?
                        • +1

                          Для всех этих задач вполне достаточно одного окна, раз уж для вас это так важно.


                          Для начала, Git Bash для работы с Git не обязателен.


                          Далее, никто не запрещает вместо Putty (кстати, что это за сборка такая — SuperPutty?) использовать OpenSSH, тем более что ssh.exe идет вместе с git.


                          Сборку проекта можно делать в том же самом окне если правильно прописать переменные окружения.


                          Для четверной задачи, раз вы привыкли к linux-окружению, конечно же придется использовать cygwin… Вот только cygwin не отбирает у вас возможность использовать git, openssh и собирать проект в том же самом окне.

                          • –3
                            К сожалению все вместе так и не получилось это настроить удобным образом. Возможно дело в руках или отсутствии желания.

                            Да и выглядит это все как то не очень красиво (я сейчас именно про внешний вид), возможно из-за ограничений виндового терминала.
                            • 0

                              Ну, это больше ограничения стандартных шрифтов. И стандартного же cmd.exe. Те же git bash или консоль cygwin выглядят довольно неплохо, на мой вкус.


                              Говорят, еще в десятой винде консоль значительно переделали. Но сам я десятку еще не трогал, сижу на семерках-восьмерках.

                              • 0
                                Была бы на моей прошлой работе десятка с Ubuntu on Windows — я бы может и относился бы к винде по другому. С семеркой подружиться после нескольких лет линукса не получилось.

                                P.S.: Хабрасуицид совершен успешно)
                                • 0
                                  Вот тут ссылочку давал :)
                    • –2
                      При всем обилии адептов Windows, которые плачутся что Linux слишком сложен, я впервые вижу линуксоида, который плачется что windows слишком сложен. Как говорится, не думал что доживу до этого момента.
                      • +3
                        Он не сложен, он не удобен. Он заставляет ломать сложившиеся привычки. Как и Linux для пользователей Windows.

                        Все дело в привычках. Банальная вставка по средней клавиши мыши(отвыкать пришлось долго). Удобный и красивый эмулятор терминала. И много других мелочей которых нет на тех версиях Windows, с которыми я работал и которые есть в Linux. Ну и разумеется отсутствие привычного софта без костылей для установки и использования.

                        Аналогично можно расписать неудобства Linux — отсутствие привычного софта, установка ПО из репозитария через GUI либо командную строку, настройка определенной части оного путем редактирования текстовых конфигов вместо удобной GUI. Да даже банальная структура директорий непривычна. Все это влияет на удобство и сложность использования.

                        Возможно, Windows 10 многое изменит, но когда она еще попадет на рабочие места в кровавом энтерпрайзе? Я искренне радовался выходу Ubuntu on Windows. А потома до меня дошло, что большая часть работодателей вряд ли в ближайшее время запланируют апгрейд. И следовательно смысла в этой подсистеме не очень много.
                        • +1

                          Вставку по средней кнопке в протоколе Нового Более Лучшего Дисплейного Сервера убрали, кстати. Во всяких федорах её сбоку изолентой прикрутили

                          • 0
                            Нового Более Лучшего Дисплейного Сервера

                            Это вы так вайланд обозвали?

                            Блин, сволочи они(
                        • 0
                          Я искренне радовался выходу Ubuntu on Windows.
                          Это не клиентская фича, она работает только в режиме разработчика.
                          • 0
                            Это что-то меняет для разработика или админа? :)
                            • 0
                              На клиентской машине баш-скрипты не запустишь.
                              • 0
                                А зачем они вам на клиентской машине, а не серваке? 0_о
                                • 0
                                  Я не админ, поэтому плохо понимаю, зачем они на винде вообще. Но в комменте, на который я отвечал
                                  Возможно, Windows 10 многое изменит, но когда она еще попадет на рабочие местав кровавом энтерпрайзе?
                                  Так что перенаправьте вопрос TheKnight, зачем ему Ubuntu на клиентских виндах.
                                • +1
                                  Задачи разные бывают. К примеру, иногда эти скрипты надо отлаживать и писать.
              • 0
                Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.

                Использовать можно. Удобно — далеко не всегда. Можно конечно пользоваться виртуалками, но это опять таки менее удобно получается. Всякие hot redeploy и прочее далеко не всегда работают сквозь виртуалку.

                • 0
                  Ubuntu on Windows. Там вполне неплохо поддержали много апи в AE. Редиска уже там, все утилиты то же через это чудо. wrk нормально собирается и работает. Пока другое не пробовал, но вполне. Может будет интересно.
                • +1

                  Напомню, мы говорим об энтерпрайзе. Тут считается нормальным купить за большие деньги Talend MDM, который идет со своей Talend MDM Studio на базе Eclipse и не имеет консольных утилит для сборки (прощай, CI и CD!), и посадить опытных Java-разработчиков парсить XML-документы регулярками, потому что другого API не завезли.


                  И чтобы жизнь медом не казалась, надо загнать всех на удаленную работу через тормозной и глючный VPN, работающий только через IE на терминальный сервер, где один экземпляр Talend MDM Studio выжирает по 2 гига памяти, а их запущено пять штук...


                  А когда настанет время развертывания релиза на стенде интеграционного тестирования — то десять тысяч документов будут загружаться напрямую в базу вручную разработчиками потому что Talend на таких объемах умирает.


                  А другой разработчик будет их же публиковать на портале, потому что интеграция не работает в этом режиме.


                  И после этого вы жалуетесь на какие-то виртуалки? Между прочим, на хорошем железе виртуалки довольно шустро работают, даже если внутрях — серверная винда с Sharepoint… Тоже, кстати, тормозная хрень, но хотя бы память не выжирает и CI поддерживает.

                  • 0

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


                    А виртуалки мне не нравятся не из-за тормознутости (вот как раз эта проблема решается легко).
                    Вот один пример из жизни пример — на одном из проектов были тесты, которые нормально работают только под линукс. А разработка под виндой. Как результат нельзя просто взять и запустить тесты из IDE. Можно запустить из консоли через билд систему (maven), но там запускаются все тесты, а прогон всех тестов занимает минут 20-30. Да, это можно решить отдав правильные аргументы maven'у, но все-равно неудобно. Ну и запустить таким образом тесты с дебагом становится отдельным испытанием.

                    • 0
                      Remoute build?
            • +3

              Насколько я понимаю, на альтернативных платформах у дотнета в принципе нет официально поддерживаемого GUI.

            • +2
              А чем все-таки Rider не угодил?
              • 0
                1. EAP — релиз обещали осенью 2016, ЕМНИП
                2. Не чистый .NET
                3. Из-за некоторых технических решений является пруфом(возможным) того, что .NET Core из коробки нельзя использовать для определенного класса задач совсем. Подразумевается написание десктопных приложений.


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

                P.S.: [humor]А как прописывается тег хабрасуицид?[/humor]
                • +1
                  Абсолютно согласен, что Rider нельзя называть примерном зрелости кросплатформенного .net, мой вопрос был больше к фразе «Пока что я не вижу IDE уровня IntelliJ IDEA или Visual Studio под эти платформы (да даже не важно на чем оно написано). » =)
                  • 0
                    Наверное дело все же в EAP статусе Rider. Все же этот статус накладывает определенные ограничения на его использование. Точнее, на его оценку как хорошего инструмента.

                    Что то может измениться, в том числе и критично для пользователя. Посему, конкретные выводы делать рано. Но я в вас верю :)
                • +1
                  зачем вам чистый .NET?
                  • +1
                    Затем что мне не хочется писать гибридное приложение с GUI на Java и логикой на .NET.

                    Кроме того хочется переиспользовать имеющиеся наработки и просто портировать приложение внутри одной платформы, не переписывая его целиком на другом языке.
                    • –2
                      Rider. В нем графическая оболочка это java, а логика c#. Как раз тот пример, который вам нужен?
                      • +1
                        Это как раз пример того, что мне не нужно. Читайте пожалуйста внимательней.
                        • 0
                          Точно, приношу извинения.
                    • 0
                      уже есть либы позволяющие писать кросплатформенную графику на .net core
                      • 0
                        Примеры бы. Я пока только авалонию видел.
                        • 0
                          • 0
                            Выглядит как заброшенная попытка в обоих случаях.
                            А wpf-like у авалонии мне нравится, смотрю как процесс движется уже давно)
                            • 0

                              Приезжайте в мае на .NEXT, там про неё слот будет.

              • +2

                Тем, что он не является полноценной заменой Visual Studio:


                1. Он будет платный, тогда как VS бесплатна даже для использования в небольших коммерческих проектах.
                2. Не поддерживает несколько языков в одном солюшене.
                3. В стадии EAP: имеет ряд багов, тормозит на больших проектах и файлах, которые VS тянет легко.
                4. Имеет очень слабый функционал по отладке приложений по сравнению с Visual Studio:
                  • слабый Expression Evaluation (нет поддержки пользовательского отображения значений);
                  • нет нормальной поддержки асихронных задач (невозможность пошаговой отладки при использовании async/await);
                  • нет остановки в момент выброса любого исключения (проблему в разы быстрее решить прямо на месте, чем изучать стектрейсы).

                Лично для меня эти моменты очень приципиальны. Поэтому для написания кода я обычно использую Rider, но если нужен отладчик — переключаюсь в VS.

                • 0
                  Ну так и в статье написано, что «через год-два». Первый пункт неоспорим, а остальные мы надеемся поправить к этому времени =)
                • +2
                  ормозит на больших проектах и файлах, которые VS тянет легко.

                  В нашем solution (150 проектов, WPF, Xamarin), тянет на ура. При вытягивании изменений из гита, за 1-2 секунды готов уже к работе, тогда как студия с трудом переживает внешние изменения в более чем 2-3 проектах. Как правило выжирает 2гб оперативной памяти и зависает.

                  Райдер (не холодный запуск) за 5с открывает наш solution, тогда как студия (2015) 30-40с.
                  Никаких тормозов уже не наблюдаю. 2 месяца пишу только в нем.

                  Последние 2-3 EAP стали вполне рабочими, хотя баги встречаются, но не были для меня принципиальными.
                  • 0
                    Решит ли проблему, использования nuget пакетов вместо проектов? Можно ли подцепить туда pdb, чтобы можно было отлажиывться в «чужих» проектах?
        • 0

          Да дело далеко не только в IDE. И вообще не в языках. Я бы лично хотел посмотреть на хоть какой-то аналог OSGI. Или ESB (что-нибудь вроде Camel). Или я не туда смотрю — но ничего подобного вобще не попадается на глаза.

          • +2

            OSGI -> AppDomains
            ESB -> WCF
            Конечно они не идентичны, но решают похожие задачи

            • НЛО прилетело и опубликовало эту надпись здесь
            • 0

              Насколько я понимаю (хотя тут я могу ошибаться), WCF далеко не аналог шине в нормальном ее виде. Т.е. скажем это ближе к Apache CXF, в лучшем случае, а до Karaf + Camel + CXF + MQ, так как выглядит нормальная шина в мире Java, ему как до луны.


              Вот насколько они не идентичны — настолько .Net code Java и потеснит в энтерпрайзе :)

              • +2

                Все дело в том, что значит "нормальная".
                Когда я делал корпоративное ПО на java, я тоже так считал, но потом у меня появилась возможность сравнить.
                В java нет такого понятия как сборка (Assembly — the smallest unit of versioning, security, deployment and reusability of code in .Net.)
                Из этого маленького нюанса растут все различия в корпоративных фреймворках для .net и jvm.
                Например, в .net не аналога Camel, не потому что он "не энтерпрайзный", а потому что нет самой проблемы которую он призван решить. Поэтому же нет прямого аналога OSGI. WCF+IOC+MQ-брокер + AppDomains, как изолированная среда, это примерный аналог.
                Я не вижу такой технической проблемы в корпоративном ПО, которую невозможно/сложнее решать на .net, чем на java. Просто используется другой набор фреймворков, немного другие подходы.
                Думаю посыл статьи в том, что с приходом .NETStandard 2 все это добро будет доступно на unix-системах, вот и получается прямая конкуренция.

                • 0

                  Что значит "нет проблемы", которую решает Camel?


                  Camel не решает технические проблемы JVM или языка — он решает бизнес проблемы интеграции. И аналоги у него есть совершенно прямые — например MS SSIS. И это не просто ужас, а ужас-ужас-ужас. Это я не к тому, что решения от MS плохие, а к тому, что есть бизнес проблема интеграции, которую пытается решать например SSIS, и решает ее по сравнению с Camel ужасно. Суть в том, что потребность есть, и еще какая.


                  OSGI в общем-то тоже — потому что проблема иметь независимые взаимодействующие компоненты называйте их как хотите, но не будете же вы утверждать, что возня вокруг "микросервисов" происходит на пустом месте?).


                  Так вот OSGI — это и есть микросервисы в чистом виде. IOC ему кстати не замена, а лишь маленькая его часть.


                  Ну и кстати в разрезе IDE — меня лично гораздо больше волнуют другие инструменты, потому что после maven/gtadle/чего угодно такая штуковина как MSBuild просто выводит из себя.

                  • 0
                    Не MSBuild ом единым.Есть PSake, Cake. Для F# есть Fake. Это из тех что я знаю.
                    А что у вас с MSBuild? В принципе после прочтения пары док вполне неплохо. Собираю им сложные проекты, в него же уехали gulp, npm, webpack и куча PS скриптов.
                    • 0
                      Fake не только для F#, так же как и PSake и Cake не только для проектов на C#.
                  • +1

                    SSIS — это хрень, которую продают никогда не писавшие кода маркетологи никогда не писавшим кода архитекторам.


                    Не следует по этой хрени судить о экосистеме .NET, тут есть и более приятные вещи.

                    • 0

                      Я его привел исключительно в качестве примера наличия потребности, которой якобы нет.

                      • 0

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

                        • 0

                          Ну, типичный кейс выглядит как-то так — есть несвязанные между собой изначально системы. Нужно как-то их связать, передавая данные. Как принято, на входе с ними работает процесс ETL. Он может принимать файлы, а может таблицы из другой базы. И на выходе может делать разное. Как мне тут намекнули, WCF все-таки очень похожая штука — есть endpoints, которые являются входами и выходами, и есть некие маршруты обработки и передачи данных между ними (обычно именуемые EIP).


                          Вот эти вот ETL на нем и пишут. В моем проекте я ровно тоже самое делал на Camel, при этом значительно удобнее.


                          Опять же — это не довод за то, что какие-то там другие решения плохи или хороши — это довод именно за то, что потребность в разного рода ETL очень широкая.


                          Я про банки, если что...

                          • 0

                            Нет, WCF — это не про ETL. WCF — это про SOA.


                            У меня был опыт работы с ETL, и я считаю, что самый лучший формат для ETL-процедуры — это обычное консольное приложение.


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

                            • –1

                              А какая разница, SOA или нет, если там реально есть EIP? На входе например клиент SOA, потом маршрут обработки, потом какой-то выход. Если входы и выходы хоть как-то настраиваются, и есть какой-никакой язык для описания маршрутов (ну скажем, годится BPEL), то это и будет в конечном счете ESB или шина. Все же ETL это как правило некий клей для сервисов, написанных разными командами, и для этого удобнее средства типа скриптовых языков, или похожие инструменты.


                              Что же до консольного приложения в качестве ETL, то оно как бы и нормально, пока у вас их два. А когда их двадцать два, ими надо рулить, хотя бы в объеме чтобы само запустилось после рестарта сервера. Ну и как вы представляете себе 22 микросервиса в виде сервисов windows, например? Ну и потом, они могут быть хоть и независимые друг от друга по логике, но все равно зависимы по данным (например, на 100 сервисов порядка 10 коннектов к разным базам), поэтому настраивать теже коннкеты все-таки проще один раз, нежели для каждого из 100 микросервисов помнить, какая у нас тут база, это PROD или тестовый сервер, ну и все такое.


                              Ну то есть если совсем просто — то ESB или шина это обычно куча мелких сервисов интеграции, но с централизованным управлением и мониторингом.

                              • 0

                                Какой нафиг язык для описания маршрутов? Какой клей? Не выдумывайте чего не знаете. WCF — это библиотека для написания веб-сервисов, и ничего более.

                                • 0

                                  Это вопрос не ко мне. Про наличие там EIP не я придумал. Отмотайте комменты, да посмотрите.


                                  @dimaaan 28 апреля 2017 в 18:40


                                  Я лишь хотел сказать, что EIP типа Каналы сообщений, Pipes, Filters, Router, Translator, Endpoint это все тоже часть WCF

                                  Так вы договоритесь между собой, есть в WCF pipes, filters, или нету? Если есть — то то и есть маршруты.

                                  • 0

                                    Это случайное совпадение — одни и те же слова используются в разных смыслах. Тот кого вы цитируете увидел знакомые слова и сказал что это все есть.


                                    Повторюсь: WCF — это библиотека для написания веб-сервисов или подключения к ним, а не платформа для их интеграции

                                    • 0

                                      Я совершенно не специалист в WCF, но по-моему вы как минимум упрощаете. Я видел в документации (а не в комментах) и упоминание workflow, и message filters, и много чего еще, что явно не является веб-сервисами, а именно интеграцией. Это конечно может быть случайным совпадением, но MS в явном виде упоминает в доках на WCF как EIP вообще, так и конкретные паттерны, со ссылками на их реализацию.

                                      • 0

                                        Workflow — это отдельная библиотека, WWF (Windows Workflow Foundation).


                                        Message filters и routing в WCF действительно есть — но нет инструментов для трансформации сообщений. И никаких аналогов биндингов из вот этого списка кроме трех там тоже нет.

                                        • –1

                                          image

                              • 0

                                Что же до ETL, то постоянно они работать не должны, ETL это по определению пакетная обработка по расписанию.


                                Для 22 ETL-процедур за глаза хватает одного консольного приложения с одним конфигом, нет необходимости разводить 22 отдельных проекта до тех пор, пока их разрабатывает один разработчик.


                                Запускать их можно через системный планировщик или через MS SQL Server Agent. К слову, те же джобы SSIS или Pentaho запускаются точно так же, в этом плане запуск консольного приложения ничем не отличается от того что предлагают якобы профессиональные инструменты.


                                Зато консольное приложение:


                                1. проще в отладке и настройке;
                                2. пишется на богатом на возможности статически типизируемом языке с возможностью обобщенного программирования, рефлексии и метапрограммирования;
                                3. может использовать любые библиотеки, а не те которые удалось подключить;
                                4. использует общепринятые системы ведения логов а не то что придумали вендоры;
                                5. может поддерживаться любым разработчиком, а не редким специалистом, прошедшим кучу курсов.
                                • 0
                                  Что же до ETL, то постоянно они работать не должны, ETL это по определению пакетная обработка по расписанию.

                                  Кто вам сказал эту чепуху? Если вы никогда не видели ETL, работающего по сообщениям скажем из MQ — это не значит, что их не бывает.

                                  • 0

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

                                    • 0

                                      Я просто работаю над этой темой уже лет 10. Базы даных и файлы — это было когда-то. А сейчас нормальные инструменты для делания ETL предполагают и позволяют переваривать данные, приходящие в любом режиме, и откуда угодно. Информатика какая-нибудь, или тот же camel — им по большому счету все равно, сообщения это или база. Возможно это меняет смысл термина, но тем не менее — то на чем сегодня делается ETL, оно именно такое. 24/7, терабайты данных в сутки, смесь пакетных загрузок и стриминга.

                                      • 0

                                        Одинаковые инструменты не говорят об одинаковости задач.


                                        Но да, если мне нужно будет делать онлайн-обработку сообщений, бегущих через MQ — консольное приложение для этого я писать уже не буду. Сделаю вин-сервис :-)


                                        Кстати, в 22 вин-сервисах на самом деле нет ничего страшного. Но проще, конечно же, обойтись одним.

                  • 0

                    Не знаком с SSIS, да и с Camel тоже. Насколько я понимаю это ETL инструменты. Я лишь хотел сказать, что EIP типа Каналы сообщений, Pipes, Filters, Router, Translator, Endpoint это все тоже часть WCF, поэтому и нет проблемы.


                    Насчет "OSGI — это и есть микросервисы", тогда и WCF — это тоже микросервисы. Значит опять нет проблемы.


                    П.С.
                    maven все же не совсем аналог msbuild. скорее аналог Ant.
                    Или же maven аналог msbuild+nuget.
                    А знакомство с системами сборки вообще частенько выводит из себя :)
                    В maven'е куча плагинов, надо с каждым разбираться (прямо как webpack).
                    В .net core конфиги msbuild похудели, так что все не так уж и плохо.

                    • 0

                      Я в общем слабо знаком с WCF, поэтому пожалуй в такой формулировке соглашусь с тем, что это похоже на Camel. Лучше или хуже — не знаю, по похоже очевидно.


                      По вопросу микросервисов — ну тут дьявол как обычно в деталях.


                      OSGI в виде реализации — это все же не одни только микросервисы, там много чего поверх уже есть. Если совсем уж просто — то на сегодня это ближе скажем к kubernetes Т.е. это еще и оркестрация кластеров микросервисов, например.


                      Что же до msbuild… ну тут сложно и длинно. Например, первое что не нравится — его еще и устанавливать надо? Ни maven, ни ant, ни gradle не требуют никакой установки (как впрочем и JDK/JRE) — это просто папки.


                      Тоже самое впрочем касается и проблемы зависимостей как таковых, в мире Java это как правило jar, в разных его подвидах, и некий набор соглашений, где в нем могут лежать зависимости. И он рекурсивный по сути, т.е. один jar внутри другого — ничего такого в этом нет, и обработать это тоже легко.


                      То есть, я могу собрать только свои классы, запаковать обычным zip, и посмотреть потом тоже, и ресурсы положить туда же — и тоже посмотреть например far-ом. И поправить, если что. А могу собрать свои + зависимости, и сделать так называемый fat jar или uber jar — и задеплоить одним куском. Ничего близкого к этой идеологии в мире .Net мне пока не попадается.

                      • 0

                        Как вы запустите maven или ant из агента CI, если это "просто папка", лежащая незнамо где?


                        Надо или в PATH прописать, или положить в известное место, или завести отдельную. переменную окружения, или настроить свойство в агенте...


                        Хоть это все и мелочи, но в итоге получается что установить msbuild не сложнее чем maven. Хоть там и надо прокликать "далее"-"далее"-"далее" или заморачиваться с "тихой" установкой — но зато msbuild всегда лежит по известному пути.




                        Для деплоя на IIS можно собрать zip-архив и задеплоить его одним куском при помощи msdeploy.


                        Для деплоя на Sharepoint нужно собирать не zip, а cab.


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


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

                        • 0

                          Я запущу, и для этого конечно нужно знать папку. Но этих папок можно быть сколько угодно (как это обычно и бывает под Jenkins где-нибудь). Т.е. десять разных версий maven — никаких проблем не вызывает. Более того, дженкинс сам их и поставит, когда нужно. Одна версия из IDEA, другая из эклипса.


                          А внутри у Weblogic (и у груви заодно) — своя версия ant. Зачем — не знаю, но есть и работает.


                          Т.е. установки, как таковой, нет вообще, начиная с JDK, которую конечно тоже можно ставить из msi — а можно потом взять готовую папку и скопировать, и не будет никакой разницы (ну, почти никакой, если честно).


                          при помощи msdeploy.
                          А что, просто скопировать никак? Вот из таких мелочей оно все и состоит.

                          А что до msi… ну я как бы прекрасно знаю, что это такое. По сравнению с форматами установок типа jar/war — это примерно также, как старый OLE формат файлов ворда, по сравнению с новым zip форматом у него же — удобство просто несравнимое.


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


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

                          • 0

                            Ну, разные версии msbuild тоже в разные папки ставятся.


                            А что, просто скопировать никак? Вот из таких мелочей оно все и состоит.

                            Можно и скопировать. Но вы же сами хотели деплоить одним куском...


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

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

                            Полностью с вами согласен, я и сам считаю так же. Но поверьте — в .NET в этом плане все сделано правильно.


                            msbuild — это расширяемая система сборки, возможностей которой хватает для очень большого круга задач. А где не хватает — там можно сделать <Exec Command="..." WorkingDirectory="..." />.

                            • 0
                              Можно и скопировать.

                              А зачем тогда msdeploy? ) Тут я кстати серьезно — сталкивался ровно с тем же, когда результат работы SSIS нужно установить на хост с базой. И написано, что нужно (или можно) для этого некую утилиту. При этом кто-то из команды просто взял, и скопировал, и оно работает, что вызывает некоторые вопросы — а зачем собственно утилита-то, и что она делает кроме копирования файлов?


                              Но вы же сами хотели деплоить одним куском...

                              Я не хотел одним куском. Я хотел в зависимости от задачи.


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

                              • 0

                                Во-первых, msdeploy умеет создавать сайты, пулы и прочее (простое копирование сделает приложение частью существующего сайта или заменит существующий сайт).


                                Во-вторых, msdeploy работает по сети и является заменой колхозу на сетевых папках.


                                Соответственно, в зависимости от задачи можно использовать msdeploy, а можно — копирование.




                                SSIS хранит свои задачи в своей базе данных. Утилита читает файлы и загружает их в базу, раскладывая по табличкам. Да, это бред, но людям, которые привыкли строить энтерпрайз-решения вокруг сервера СУБД такой подход нравится.




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

                                Ну, если вы не понимаете чего-то конкретного, можете задать вопрос на ru.SO. Я там часто отвечаю.


                                Что же до идеологии… Я не вполне понимаю что такое идеология системы сборки но думаю, что у msbuild и ant идеология общая.

                            • 0

                              Ну. exec command — это не плагин, это бяка ) Понятно что это на клайний случай, но все равно, это какая-то фича из эпохи make, по-хорошему, команде должен передаваться проект, а не непойми что. Причем она должна понимать, как он устроен, и где что лежит.

                              • 0

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

                              • 0

                                exec я упомянул скорее как возможность сбежать с msbuild на любую другую систему сборки, поставив заглушки на цели Build, Rebuild и Clean :-)


                                Проект Visual Studio — это обычно и есть msbuild-файл. Если не использовать кривые магические надстройки для студии, то любой проект студии может быть собран msbuild, а любой файл msbuild может быть открыт студией как проект если дать ему правильное расширение и прописать правильный ProjectType.


                                Я так, кстати, часто делаю — создаю шарповый проект, удаляю из него импорт шарпового тулчейна и добавляю свои таргеты. Например, есть у меня проект, где исходниками являются jar-файлы, которые при сборке подаются на вход ikvmc...




                                Кстати, задача Exec в msbuild намного мощнее чем то же самое в make за счет языковых средств msbuild. MSBuild умеет работать со списками элементов проекта, преобразовывать их, фильтровать, группировать. Сами элементы проекта могут быть добавлены в явном виде (например, через IDE), получены сканированием директорий или получены как выходные параметры других задач.


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

                        • 0
                          зато msbuild всегда лежит по известному пути.

                          Это пока у вас он один. Как только вам нужно подерживать скажем старую версию — вы приплыли.

                          • 0

                            Старая версия лежит по другому пути, не беспокойтесь.

                      • –1
                        Что же до msbuild… ну тут сложно и длинно. Например, первое что не нравится — его еще и устанавливать надо?

                        Он с .NET поставляется, в "%SystemRoot%\Microsoft.NET\Framework\" соответствующей версии.
                        • 0

                          Нет, последние версии MSBuild ставятся отдельно.

                          • +1
                            Про «последнююю версию» речи не было. Если нужна хоть какая-то — она есть сразу из коробки.
                            • +4

                              А нужна не "хоть какая-то", а та, которая способна собрать проект.

                              • 0
                                Это уже от проекта зависит. Если человека ломает ставить MSBuild, значит и VS он не будет ставить, и значит в его «рукопашном» проекте не будет таргетов из студии и прочего. Если человек хочет делать проекты «как в Java», которые билдаются без необходимости ставить билд-систему, у него всё для этого есть (нужно ли это делать и почему так никто не делает — отдельный вопрос).
                                • 0

                                  Вы не поняли. "ломает ставить" — это не лично человека. Вот например, возьмите Jenkins. Для большинства систем сборки (и вообще инструментов) он сам умеет скачать и поставить их нужные версии, и подключить к сборке. То есть установка maven — это галочка в настройках проекта "нужен maven версии ххх". Потому что далеко не всегда (а скорее наоборот) сборка делается на машине разработчика. По-идее на машине CI одна должна делаться чаще.

                                  • 0
                                    А эта галочка в настройках сама cкачивает maven, или, чтобы галочка работала, для неё нужно поставить Jenkins или что-то ещё? Непонятно, где выигрыш, если по-любому на CI-сервер нужно хоть что-то установить и ничего там «само» не заработает?
                                    • 0

                                      Jenkins это и есть CI. Нет, не нужно, он сам все установит, начиная с JDK и кончая ant. Или maven.

                      • 0
                        Я могу ошибаться, но вот про ubуr jar у нас был uber-nupkg (мне решение не очень нравится, но тогда оно было оправдвннаым) в этот nupkg пихали все-все-все деплоили его в локальный репозиторий nuget пакетов и потом скачивали на целевой машине и разворачивали, nupkg это тот же zip. Это если уж говорить о подходе убер-штук, но на самом деле ваш кей в .net не очень нужен. Я просто не могу представить зачем такое нужно.
                        • 0

                          Дело даже не в uber jar — дело в том, что субъективно развертывание можно делать несколько проще (и даже сильно проще), чем это делает MS, когда предлагает свои продукты. И эта простота развертывания в какой-то степени важнее для успеха платформы в целом нежели качество языка (которое у c# вполне хорошее), или многоплатформенность (которая в какой-то степени опять же уже у .Net уже есть). Все остальное — это просто более или менее наглядные примеры, первые какие пришли в голову.

                          • 0
                            Все развертывание .Net core — скопировать папку и запустить бинаркник с self-contained .Net.
                • 0

                  P.S. Кстати, то что я называл — это лишь часть. Например, вы можете представить аналог Hadoop на .Net? Или даже еще проще — любой софт, сильно завязанный на кластер, ну хоть тот же GridGain/Ingite?


                  И если нет, то почему его не существует?

                  • +2
                    Вполне могу. Тут проблема не в платформе или ЯП, а в том, что Java заняла эту нишу раньше из за недальновидности менеджеров MS. Хотя уже появляются всякие RavenDB.
                    • 0
                      после слов «вполне могу» желательно бы список продуктов на уровне hadoop/ignite =)

                      ravendb это в лучшем случае couchdb, но даже со своим rest интерфейсом очень часто проигрывает в измерениях.

                      hadoop это полноценная платформа поверх и совместно с которой крутится очень много чего: mapreduce, spark, flink, storm, hbase, accumulo, phoenix, cassandra, kafka и можно продолжать очень долго

                      у MS была хорошая попытка в виде dryad, правда они её слили, а вот идеи из неё уже и вошли в spark/flink.

                      вообще в сфере перемалывания и nosql доминируют 2 языка java и c++, местами другие jvm языки в виде scala и clojure.

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

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

                      с появлением .net core может что-то и поменяется, но тут начинается уже битва рантаймов (именно поэтому некоторые продукты отходят от jvm и переходят на c++), и тут опять же у jvm пока рантайм смотрится чуть лучше. на данный момент я не видел в жизни как себя ведет gc у .net на хипах по 64GB и выше, а в реальной жизни встречались и выше.

                      для той же jvm вот ultra-low pause допиливает redhat и odnoklassniki его уже в прод пустили

                      признаюсь, что плотно под .net не разрабатываю, но когда смотрю доклады по кишкам .net в части оптимизации расходов памяти (те же доклады по memory traffic в resharper) и вопросов производительности, то очень часто случается культурный шок от того, что у себя на jvm о данных вопросах даже не задумываешься, все из коробки уже работает хорошо.

                      так что повторюсь: вопрос далеко не только в маркетинге, но и в рантайме (как и где он может запускаться, ну и насколько утилит готовых на все случаи жизни для него существуют), возможно с появлением .net core что-то начнет меняться, но это займет не год и не два, а в лучшем случае пять лет.

                      p.s. с интересом слежу за развитием .net платформы и попыткой её стать действительно кроссплатформенной, но уже видно отрезвление у многих, что это не спринт (через год-два у нас все будет отлично работать на linux/mac), а достаточно долгий марафон. остается лишь пожелать удачи, конкуренция и обмен идеями никогда никому не вредила.
                      • +1
                        Ну дак смысл то в том, что сам рантайм может многое потянуть при желании. А вот политика и менеджмент решают по своему. Сейчас вот включили мозги. Dryad помню, но решили просто использовать Hadoop. Ничего плохого в этом не вижу.

                        А по части оптимизации — магии не существует. Вы либо тюните параметры GC либо более точно работаете с памятью. Ну или и то и другое :) Даже Go с его типа уникальной разработкой ничего нового не принес.
                        Как раз возможность более детерминировано работать с ресурсами сейчас отличает .Net от Java в лучшую сторону.

                        Время покажет. В любом случае Java очень долго будет оставаться релевантной, ну если Оракл еще чего не учудит :) А .Net вполне занимает нишу между ней и node/ruby. Но это мои личные ощущения.
                    • 0

                      Не-не. RavenDB это может и выглядит похоже, но совершенно не то. Суть в выполнении кода на том узле кластера, где у вас лежат данные. Это далеко не просто шардинг или кластеризация.

                      • 0
                        Это хоть на перле все можно писать. Или у Java есть секретный ингредиент? ;D
                        • 0

                          Покажите аналог на перле, я не против.

                          • 0
                            Вы не поняли вопрос похоже. Повторю:
                            Что в Java отличает ее от других языков и платформ так, что только на ней можно написать Hadoop или GridGain или Ignite?
                            У Java есть одно преимущество — в тот момент, когда эти проекты рождались другой альтернативы не было, а сейчас просто нет смысла переписывать до тех пор пока всех это устраивает. Есть Golang, Rust, С++, тот же .Net. Или вы серьезно считаете, что нельзя выполнить .Net код на том же узле кластера где лежат данные? :D
                            • 0

                              Это вы не поняли вопрос. Повторяю — расскажите, каким образом софт, написанный на перле или на питоне, попадет на нужный узел кластера, где расположены нужные нам сегодня данные? Кто скомпилирует этот софт, написанный на Go, Rust, C++, или том же .Net, именно под нужную архитектуру и ОС этого узла, и как доставит этот код с зависимостями на нужные узлы, прежде чем их можно будет там выполнить?

                              • 0
                                Берете Рослин, компилируете, исполняете. Доставка на нужный узел — на ваше усмотрение, хоть через сообщения, хоть через что угодно. Можете либы готовые слать и вызывать.
                                Причем тут Java? Это просто написано на ней, но может быть переписано на другом ЯП, например Akka.Net.
                                • –1

                                  Эк вы ловко с перла и питона на рослин-то свалили...


                                  Ага. Берете и исполняете. А потом у вас Process.execute("shutdown") где-то в коде затесался )))


                                  У вас, простите, какой-то очень наивный взгляд на то, как можно выполнять заранее неизвестный код (ad-hoc) на кластере, так чтобы он а) работал (зависимости тоже нужно передать, а для начала собрать их) б) не завалил узлы кластера ни по какой причине, в том числе — потребляя чрезмерно ресурсы, в) имел доступ только к тем данным, к которым ему положено.


                                  P.S. вы правда не знаете про такую секретную фичу, как возможность загрузить в JVM байт-код прямо из потока байт, не передавая никакие "готовые либы"?


                                  Перепишите все на перл, да. У хадупа при всех достоинствах куча недостатков, тянущихся с рождения, когда он был просто MR поверх HDFS. Устраните — озолотитесь. Без всяких шуток. Все что вы тут рассказывали про "всех все устраивает" — не более чем байки. Не всех и не все.

                                  • +3
                                    Perl — как передать по сети личное дело каждого.exec, compile, eval в Python.
                                    А вы серьезно не вкрусе о Assembly.Load?
                                    Все что вы описываете можно делать через Рослин, зависимости хоть через Nuget гоняйте и динамически загружайте. Хотите — генерите динамические сборки прямо в коде, компилиркйте их в IL и гоните по сети. Java тут никаких преимуществ не дает. Для защиты от дурака — AppDomain.

                                    Кому надо и делают. Пример выше я уже привел. Пилить свое — не всегда лучший вариант. Если не устраивает — перепиливайте. Только надо бабок на это, комьюнити и время, когда на рынке уже есть аналог в который активно инвестируют. Поэтому проще Hadoop к сиквелу прикрутить чем переделывать.

                                    И опять повторюсь — причем тут Java? Какие уникальные фичи есть только в ней, что другим нельзя в кластере код передавать и изолировать процесс/данные?

                  • 0

                    Был аналог — DryadLINQ.
                    Его уже не поддерживают, т.к. Hadoop начал поддерживать взаимодействия с другими языками и смысл пилить Dryad пропал, ибо малая популярность.
                    Так что проблемы сделать аналог нет.
                    Да и вообще, что именно в .net не позволяет завязываться на кластер?


                    П.С. промахнулся с веткой

                    • +1

                      Вообще, если подумать, c# как раз таки больше подходит для систем обработки данных из-за более тонкого управления памятью (value type, указатели, ref return)

                    • 0

                      Честно говоря, я так и не понял, есть ли тут аналог HDFS, и используется ли data locality. Т.е. распределяется ли код по кластеру, и каким именно способом.

                      • 0
                        было, помимо локалити было много здравых идей там.

                        вот только dryad был на уровне beta и даже пару универов смогли «скачать-поиграться». потом его закрыли со словами «кастомеры как-то не горят желанием еще одной системы поэтому будем делать коннектор к хадупу».

                        из хороших идей там там был нормальный стриминг промежуточных результатов на следующий этап конвеерной обработки, в случае если этап находится на этой же физ ноде стриминг выполнялся по name pipe (а не через сетевой сокет), там же были зачатки RDD (spark их потом развил в уже законченное решение). в общем полезных и интересных вещей было очень много, если бы их действительно развили до промышленного состояния, то вполне возможно у нас сейчас была бы еще одна распределенная система обработки данных.

                        но ms слили свой шанс и сейчас вокруг jvm и c++ в этих областях и .net там бедный родственник
                • 0
                  Я не знаю насчет специфики корпоративного ПО — но работая над довольно большим проектом (50 разработчиков в 3х странах, не считая сторонних модулей) проблемами видятся:
                  • Гораздо более слабая поддержка Dependency Injection и Aspects, усложняющая создание mocks, добавление логов, проверок авторизации и т.п.
                  • Сильная зависимость между компонентами и OS/AppServer, затрудняющая интеграцию — модель JAR/WAR гораздо гибче Assembly
                  • 0

                    Что такое в вашем понимании "слабая поддержка Dependency Injection"? Чего именно вам не хватает или не хватало?


                    И каким образом затрудняется интеграция из-за сильных связей между компонентами? Вы пробовали эти связи делать слабыми? :-)

                    • 0
                      Не хватает — 1. field injection 2. простого способа оборачивания методов в транзакции, логи и что еще понадобится.
                      Связи не между компонентами, а между компонентами и ОС. В Яве достаточно остановить апп-сервер и можно деплоить новую версию — в .Net (на Windows) надо останавливать IIS, WAS, собственные сервисы — и только тогда можно быть уверенным что ваши тесты бегут с нужной версией ассембли.
                      • 0
                        1. Property Injection работает так же как и field injection, не вижу проблем написать {get;set;} чтобы превратить field в property.


                        2. Чем вам using (var ts = new TransactionScope()) — не простой способ?


                        3. Что же до версий сборок — решение проблемы очень простое. И не нужно было добавлять в GAC.
                        • 0
                          1. Property Injection — это некий костыль. Надо менять документацию на интерфейс, раскрывает детали имплементации и т.п.
                          2. Тем, что это засоряет код и для уже скомпилированной сборки не меняется.
                          3. Я в GAC ничего и не добавлял (это вообще требует прав администратора для инсталляции — что убивает возможность самоапгрейда).
                          • 0
                            1. Вы так пишите как будто field injection — не костыль...


                            2. Менять скомпилированные сборки — нехорошо. Но если очень хочется — есть же Mono.Cecil


                            3. В таком случае никаких проблем с обновлением.
                            • 0
                              1. Костыль — но гораздо меньший
                              2. Вы не поняли. Есть скомпилированный класс с методом DoSomething — разработчик которого о транзакциях, логах и прочем мог вообще не знать. В Джаве (Спринге например) я могу написать внешний файл аннотаций и включать/выключать все вышеописанное как мне хочется, не затрагивая оригинальной функциональности.
                              3. Это в теории. На практике — если у вас больше одного сервиса, начинается веселуха, особенно с инфраструктурными компонентами. Но не исключено что какие-то гуру DevOps действительно смогли бы это починить.
                              • 0
                                Костыль — но гораздо меньший

                                Вы хотите сказать, что когда перед использованием объекта надо установить ему некоторое поле — это нормально, не нуждается в документировании и не раскрывает деталей реализации?..




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


                                По поводу же логов — повторюсь:


                                Но если очень хочется — есть же Mono.Cecil



                                А что вы делаете в Java, когда у вас более одного сервиса? И почему вы не смогли сделать то же самое на .NET?

                                • 0
                                  У обьекта не все поля равнозначны. Есть поля, относящиеся к бизнес-логике и есть поля инфраструктурные — логгер, конфигурация, подключение к БД и другие сервисы, по определению внешние и гарантированно существующие (имплементированные сервером аппликаций). Чем меньше обьект занимается связыванием и инициализацией последних — тем чище и проще его код.
                                  Необходимость использования транзакций может меняться чуть ли не каждый спринт. Поэтому от внешнего файла аннотаций есть прямая польза. А при отладке больших систем, особенно профилировании — это вообще незаменимо. Замена реальной имплементации моком, включение/выключение логов и т.п. делается без единого изменения в самом коде.
                                  В Джаве я делаю рестарт серверу апликаций. В .Net (точнее в Виндоус) граница между AS и OS довольно размыта.
                                  • 0

                                    И что же меняется при замене полей на свойства?


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

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


                                    В Джаве я делаю рестарт серверу апликаций. В .Net (точнее в Виндоус) граница между AS и OS довольно размыта.

                                    А в .NET даже это делать не обязательно, достаточно папку bin заменить. Правильно настроенный IIS заметит это и перезапустит веб-приложение.

                                    • 0
                                      … а если одна из сборок была загружена еще куда-то кроме IIS — вы откроете для себя чудный мир DLL shadowing, когда на диске одно — а исполняется другое ;)
                                      • +1

                                        И куда же могла быть загружена сборка, которая лежит в папке bin сайта IIS? Не надо грузить что попало куда попало, вот и все.

                                      • 0
                                        Если разработчик загрузил сборку из другого приложения на IIS — ему надо руки оторвать. .Net тут не причем.
                                        Shadow cope при прямых руках вообще никак не мешает. Ей даже можно пользоваться, если умеете.
                                        .Net Core в принципе живет без IIS, и именно он является темой топика.
                                        • 0
                                          Хорошо, можно и без IIS/WAS — хотя не совсем понятно, где предлагается хостить standalone/stateful компоненты. Представьте себе, что у вас по всей системе используется один и тот же логгер. Если каждый сервис использует свою копию — билд должен уметь эти копии делать, а система интеграции — деплоить. Если же копия одна и разделяется всеми (как было задумано задолго до .NET) — CI должен уметь опускать все сервисы и поднимать их после деплоймента.
                                          • +1
                                            Сервисы винды, на Linux вообще вариантов море. Билд просто сделает nuget restore.
                                            Что значит общий логгер? Если одна и та же либа — nuget restore во время билда. GAC вообще не используется сейчас. И тем более никто не шарит либу между пачкой приложений. Для оптимизации как раз tree shaking подъедет. И ещё забыли что зависимости можно тянуть исходниками и собирать Рослином налету.
                              • +1
                                1. DI в филды вообще ахтунг. Причем ноги у этого ахтунга растут из Спринга. Тот же Guice уже пропагандирует нормальный constructor injection.
                                2. DynamicProxy — оборачивайте что хотите. Только за транзакции прикрученные непонятно к чему на code review будет много вопросов.
                                3. Это у вас кривой devops. Это надо очень постараться, что бы устроить конфликты библиотек между изолированными приложениями на IIS. На Core и IIS не нужен. HAProxy/Nginx/Apache + Kestrel.

                                Проблема .Net проектов, что есть большой пласт разработчиков, которые считают, что освоив инструментарий один раз( зачастую лишь очень поверхностно) больше ничего учить не надо. Только вот инструментарий развивается и меняется.

                                • –2
                                  1. Ахтунг — понятие религиозное. У вас может быть с десяток инфраструктурных сервисов — замучаетесь их все в конструкторе перечислять. А любое изменение в «популярном» классе повлечет ребилд приличной части проекта.
                                  2. DynamicProxy — неплохой костыль, но лучше когда такое сразу встроено в язык.
                                  3. Приложения — они не только на IIS бывают, Web/REST/WCF — это часто только фронтенд.
                                  • 0

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


                                    Все с вами ясно...

                                  • +1
                                    Насчет первого. Откройте для себя мир декораторов и перехватчиков
                                  • 0
                                    1. У нормальных DI контейнеров есть возможность делать агрегаты из зависимостей.
                                    2. В «язык» не будет встроено. А для жаждущих есть DispatchProxy.
                                    3. Конечно, не только. Берете виндовый сервис и делайте как хотите. Он так же может быть полностью self-сontained. Если вы не работали с квалифицированными .Net разработчиками, то тут уж сочувствую. Накосячить можно на любом ЯП/платформе.

                      • 0
                        Таки со сборками вроде есть простое решение — appdomain. В том плане что, выгрузил домен, загрузил домен — и вот ты уже со свежими сборками.
            • 0
              wcf нет на core и видимо не будет.

              Микрософт ставит на то что в его стеке и EAI и SOA будут заабстрагированы микросервисами.

              • 0

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

        • +1
          Как минимум это
          • 0
            Прочитайте пожалуйста внимательней. Про проект Rider я упоминал. GUI в нем написан не на .NET, это довольно таки важная проблема.

            Это если забыть про EAP статус Rider…
            • +5
              А какая разница, на .NET или не на .NET если оно летает в 10 раз быстрее чем студия? Вам, в конечном счете, шашечки или ехать?
              • +8
                Мне в конечном счете нужно уметь писать GUI на .NET кроссплатформенные. Наличие кроссплатформенной IDE на .NET как по мне является прекрасным доказательством того, что данную платформу можно для этого использовать.
                • 0
                  Есть многообещающий проект Avalonia, который ещё пока находится в разработке. Кросплатформенный, даже на мобильных устройствах. Очень похож на WPF, но с некоторыми улучшениями. Можно использовать псевдоклассы, как в CSS и указывать размеры колонок и строк в гриде вот так ColumnDefinitions=«24,Auto,24». Может через год-два дойдут до версии 1.0.
                  • +1
                    Для штуки типа коммерческой IDE проект ещё не готов. Нет таких банальных вещей как API информации о шрифтах, да и вообще в целом куча шероховатостей. Плюс из-за проблем с разработкой не-на-windows (кроме райдера нормальных IDE просто нет, а райдер не умеет в отладку, да и плагин с автокомплитом и preview xaml под него соорудим не скоро, ибо кроме меня этим заниматься некому) вылезают платформозависимые косяки. В итоге когда начинают портировать штуки типа AvalonEdit, вылезают косяки типа этого:
                • 0
                  В этом конечно спору нет, я сам бы не отказался. Но согласитесь, у Java в плане GUI тоже все не супер. Сейчас многие приходят к тому, что GUI проще написать на веб-страничке, а потом засунуть в программу вебконтрол. Сам инсталлятор студии например — это же NodeJS с веб мордочкой. Я не говорю что это хорошо, но если нужно x-plat GUI «здесь и сейчас», я бы советовал делать на вебе.
                  • 0

                    Это проблема не Java, это проблема отсутствия единых стандартов по рисованию GUI на разных платформах.

              • +4
                … если оно летает в 10 раз быстрее чем студия?

                Маленькая поправочка: «быстрее чем студия с решарпером». Попробуйте его отключить и тогда вы узнаете, что такое скорость. Никаких тормозов при наборе, ненужных дополнений кода, которые приходится удалять. И студия, оказывается, сама по себе не вешается насмерть при переключении между бранчами в hg.

                А вообще это хорошо, что появился Rider и развивается всё активнее Xamarin — остаётся надежда, что под .net таки появится идеальная среда разработки.
                • +3
                  Попробуйте в 2017-ой студии открыть солюшн с десятком NETStandard/NETCore-проектов, которые друг на друга ссылаются и при этом тянут кучу разного хлама с нугета. Узнаете, что такое отсутствие скорости.
                  • –1
                    Неужели у Rider-а с этим лучше? Не знаю как там с Core — не балуюсь, а тормоза нюгета — это отдельная песня.
                    • +2
                      В 2017-ой многие вещи замедлились, из-за этого дополнительно лезут проблемы у расширений. Например, обход дерева зависимостей через [Reference::SourceProject](https://msdn.microsoft.com/en-us/library/aa984592(v=vs.71).aspx), на достаточно большом солюшне теперь занимает секунды против миллисекунд на 2015-ой, позавчера полдня убил на переписывание отслеживалки этого дела.
                  • 0
                    Работает без тормозов.
                    • +1
                      ЛПП. Ну или у вас 3.5 проекта, вы не пытаетесь ничего подключать через нугет, не пытаетесь пользоваться билдом с несколькими целевыми фреймворками итп. Любые изменения в составе солюшна, если он достаточно большой, приводят к подвисаниям на десятки секунд. Это при выключенном решарпере. Райдер на том же самом солюшне себе такого не позволяет.
                • 0
                  Я никогда не пользовался resharper'ом.
                  Но студия довольно таки тупит.
                  По крайней мере, внутри виртуалки.
            • 0

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

              • 0
                Эм. Мне почему то казалось что гуй там на .NET точно. Ну если я ошибся — так это еще один повод не считать .NET универсальной платформой пригодной для большинства серверных и десктопных задач.
                • –2
                  Когда MS начнет писать свой софт на .NET'е — тогда можно о чем-то говорить.
                  • +3

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

                    • 0
                      Ну так я вам скажу, что вы давно уже дождались.
                      В Вижуал Студии GUI — WPF, в Expression Blend — тоже. MSN, Bing и прочие cервисы — .net

                      Даже Singularity три года назад допилили. Чего еще ждать-то?

                      • –1

                        MSSQL например, или всю студию полностью…

                        • +3

                          Должен ли в таком случае Oracle переписать свою БД на Java?

                          • 0

                            Не припомню что бы Оракл подобные заявления делал. В Оракле можно хранимые процедуры на Java писать?

                            • 0
                              Да
                            • 0

                              Да. И давно. И не только их. Там внутри полноценная JVM, с очередями сообщений, например, и всем остальным.

                          • 0
                            Мог бы, только врятли сделает. Видел про Кассандру писали, что медленная из-за того, что на жаве.
                        • 0
                          Вы хотите БД на дотнете? Хм, бывают задачи которые не стоит решат в managed языке…
                          • 0
                            RavenDB, DensoDB ,STSdb, Trinity Api, BrighstarDB, VelocityDB, HSS Database, NDatabase, DaggerDB. Не дофига, но что-то есть.
                            Что вас смущает в managed?
                            • 0
                              Мне кажется, что СУБД — штука очень критичная для всех машинных ресурсов в силу фундаментальности. Любые тормоза и жор всплывут в приложении. Собственно только по этому я считаю это не лучшей идеей.
                              • +1
                                Ну на .Net можно очень тонко работать с памятью сейчас. Это и ref returns, Channels, Pipelines, Spans, явная работа с памятью(stackalloc, Marshal.AllocHGlobal).
                                Это валидный C# код:
                                void StackAllocExample() {
                                    unsafe {
                                        byte* data = stackalloc byte[128];
                                        var span = new Span<byte>(data, 128);
                                        // not shown: populate data / span
                                        ProcessData(span);
                                    }
                                }
                                

                                Подробнее тут. Вот еще неплохой овервью.
                                • –1
                                  Чегойто «сейчас»? Всегда можно было. Плюс сложные и критичные к быстродействию куски можно писать на C++ и интеропиться с этим кодом из .NET
                                  • –1

                                    Пожалуйста, прочитайте ветку комментариев сначала. Кажется, вы забыли о чем тут шел спор.

                                  • 0
                                    И когда всегда можно было ref returns, spans, channels с селектом и zero copy буферами?
                                    Что-то вы могли сделать пометив пол проекта как unsafe, но сейчас можно
                                    void StackAllocExample() {
                                        unsafe {
                                            byte* data = stackalloc byte[128];
                                            var span = new Span<byte>(data, 128);
                                            // not shown: populate data / span
                                            ProcessData(span);
                                        }
                                    }
                                    void ProcessData(Span<byte> span) {
                                        for (int i = 0; i < span.Length; i++) {
                                            DoSomething(span[i]);
                                        }
                                    }
                                    

                                    Ничего не замечаете в этом примере? ;) Вы хоть ознакомьтесь с теми ссылками :)
                • 0

                  Нет ядро студии точно на Cи, плагины, обертки и всякая прочая окружная мишура на .NET и вроде бы еще на Cи можно что то делать (тут не уверен, раньше точно была такая возможность, раньше были кучи оберток над COM+ типа VSTO, короче черт ногу сломит).

                • +1
                  Там хитро. Там гуй вроде как на XAML, так же как с Пейнтом в 7ке, Но при этом они на C++ (CX??).
        • 0
          Visual Studio и ReSharper вполне себе дают жару.
          спойлер
          Потому что ReSharper и IntelliJ пишет JetBrains, у которых уже есть Rider
          • +1

            Вы точно причинно-следственные связи не попутали?
            Rider был создан как кросс-платформенная альтернатива связке VS + ReSharper. Ну и ещё потому, что решарперу тесно в 32-битном адресном пространстве студии.

            • 0
              Ваши слова не опровергают моих.
              Я к тому, что есть JetBrains, который в состоянии снабдить нас нормальной IDE для C#. Есть MonoDevelop, как вариант «на крайний случай» есть VS + R#. Так что нормального окружения для работы с C#-кодом полно и на моей памяти VS+R# самая удобная связка.
        • +4
          Ну вообще MonoDevelop (aka Xamrin Studio aka Visual Studio for Mac) — вполне себе кроссплатформенная IDE, написанная целиком .NET. По уровню до фич решарпера, конечно, не дотягивает, но рослином пользоваться в состоянии.
          • 0
            Ну, она не совсем на .NET, она на моно. Но вроде переезжает на .Net Core потихоньку.
            • +1
              Эм. Вообще говоря на Windows работает поверх обычного .NET. На .NET Core переехать не может по причине того, что под него нет GTK#. Ну и на макоси они, вроде, что-то используют от Xamarin.Mac, а тот требует патченого моновского рантайма для работы.
        • +6
          А мы, энтерпрайзные .Net-чики, уже годы ждём компилятор Java написанный на Java, и «тогда можно будет говорить о переходе» :)

          Да, еще бы и работу с коллекциями сделать более понятной, потому что после LINQ работать что с java.util.collections, что с Guava — это ж просто застрелиться…
          • +3
            Ээээ… Я чего то не знаю про javac? Он вроде как написан на Java. Навскидку в исходниках я не нашел упоминаний про другие языки.

            Заголовок спойлера
            theknight@theknight-laptop:~/tmp/langtools-7e0ac3c3eaba$ cloc .
                9399 text files.
                8696 unique files.                                          
                1569 files ignored.
            
            http://cloc.sourceforge.net v 1.60  T=14.75 s (489.1 files/s, 55453.6 lines/s)
            -------------------------------------------------------------------------------
            Language                     files          blank        comment           code
            -------------------------------------------------------------------------------
            Java                          7091          81717         273836         428338
            Javascript                      13           3021           4718          14932
            CSS                              7             71            177           2756
            XML                             32            180            326           2555
            Bourne Shell                    20            299            763            845
            HTML                            44            141            531            628
            Ant                              3             80            131            455
            C/C++ Header                     5            141            690            358
            make                             1             53            142            305
            XSLT                             1              4              0             20
            -------------------------------------------------------------------------------
            SUM:                          7217          85707         281314         451192
            -------------------------------------------------------------------------------
            



            Что там c компилятором C# — не смотрел.

            Про коллекции — Stream API + лямбда-функции все еще не решают проблемы?
          • 0

            А вот мне все-таки и правда интересно, что значит «компилятор Java написанный на Java»? Вы имеете ввиду компилятор в байткод, виртуальную машину или JIT/AOT-компилятор?

            • 0

              Думаю речь одет о компиляторе в байт-код

        • +2
          Бывший Mono Develop сейчас переезжает на .NET Core под видом Visual Studio for Mac.
          • 0

            Пытался его поставить на мак, так он не захотел ставиться без android sdk и xcode, "what a hell", подумал я и не стал его устанавливать.

            • 0
              Наследственность от Xamarin Studio. Но без чего-то одного точно можно поставить (по крайней мере, я без андроида ставил)
              • 0

                Помнится мне monodevelop можно было без всего этого ставить

          • 0
            Откуда информация про переезд? GtkSharp работает сейчас только поверх Mono (технически можно портировать), а Xamarin.Mac гвоздями приколочен к патчам в моновском рантайме для поддержки интеграции с ObjC.
            • 0
              Вот сейчас я точно это не найду. На каком-то из кейноутов говорилось про движение в этом направлении и желании влить в .net core наработки из mono.

              Т.е. это не конкретный роудмап, а вектор развития.
        • +1

          Какая связь между десктопным приложениями и enterprise?

          • +1

            Толстые клиенты вестимо.

            • +1

              Ну это довольна маленькая часть enterprise и его доля всё уменьшается. Все-таки enterprise это больше про серверную логику.

              • +3
                Маленькая, большая… Я хочу одно кольцо что б править всеми один универсальный язык для десктопной разработки и серверной. Питон — подходит. Java — подходит. А вот C# — нет. И это плохо. Конкуренция помогает становится лучше.
                • +1

                  Ну мы тут обсуждаем enterprise в целом, а не вас конкретно. То что вы хотите несколько ортогонально потребностям кровавого enterprise.
                  Я так-то тоже хочу язык на котором можно писать и серверную часть, и RIA, и десктопные приложения. Но я такого языка не наблюдаю. Это же не повод говорить, что все языки не подходят для enterprise.

                  • 0
                    Я так-то тоже хочу язык на котором можно писать и серверную часть, и RIA, и десктопные приложения. Но я такого языка не наблюдаю.

                    На Java можно и и серверную часть, и RIA, и десктопные приложения и мобильные приложения под все основные платформы (RIA на чистом Java это Gwt, десктоп — Swing, SWT, мобильные — под андроид натив, под Apple тоже есть возможность писать). Что-то лучше, что-то сложнее, но потенциально можно все. Только не надо разводить холивар на тему разве GWT лучше ангуляра или что за приложения получаются на Swing/SWT, та же Idea это десктопное приложение, на GWT написано много RIA энтерпрайза (сам писал), есть свои проблемы, но у кого их нет?


                    Ява подходит настолько плохо, что в некоторых «интерпрайзах»(например ДойчеБанке) сервера на java, а клиенты — .net

                    Наоборот тоже бывает (сам видел). Это не только зависит от языка/технологии. Десктоп на java вполне встречается (из известных те же IDE от JetBrains), хотя в ней акцент больше на веб приложения

                    • 0

                      Из широко применяемого в энтерпрайзе — Lotus Notes.

                    • 0
                      Что-то лучше, что-то сложнее, но потенциально можно все.

                      Потенциально можно и на brainfuck'е всё это делать :)


                      Писать RIA на чистой java — это боль. Да, возможно, но будет на порядки сложнее чем если делать это на js. Десктопные приложения на java писать проще и лучше чем RIA, но все равно проблемы есть.


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

                    • 0
                      В 2017 году GWT? :) Вроде бы живем в эпоху победившего HTML5 + JS(React/Angular) :D
                    • 0
                      Кстати связка C# на бэке + Java/ObjC (нативные мобильные клиенты) так же весьма популярна — инфрастркуткра Azure дает о себе знать
                  • +1
                    Прошу прощения, о благородные доны, но я вот как-то все перечисленные задачи до этого момента благополучно решал с помощью C# (ну за исключением клиентского web-а, хотя и тут есть варианты) и впервые слышу что кто-то испытывает сложности подобного характера.
                    (вероятно это потому что я плотно сижу на windows-инфраструктуре)
                  • 0
                    Нf F# все можно. Нет парвда. Fable для RIA, для всего остального FSC.
                • +4
                  Ява подходит настолько плохо, что в некоторых «интерпрайзах»(например ДойчеБанке) сервера на java, а клиенты — .net

                  Питон — подходит

                  Язык с динамической типизацией в enterprise? Это шутка, правда?
                  • 0
                    Selectel.
                  • +1

                    А еще у дойче были клиенты на Flex, и что?


                    И кстати про питон — это нифига не шутка. Более того, его становится все больше.

        • +1
          Это не имеет никакого значения с точки зрения зрелости платформы.
          Это как вопрос:
          — назовите серьезное Java-приложение с пользовательским интефейсом?
          — IDEA.

          И? Кто-то пишет клиентские приложения с UI на Java? Ну нет, не пишет.
          Не стоит путать тулы и end-user приложения.

          Кросс-платформенного UI в .NET Core сейчас нет. Так же как и во многих других платформах. Это ничего не говорит о зрелости.
          Нужен кросс-платформенный UI — Electron. Даже инсталлятор VS на нем :) (ну или на чем-то аналоичном, не смотрел внутрь).
          • 0
            Vuze, TuxGuitar. Хватит для пруфа?
          • 0
            Вы забыли о Qt.
            • 0
              да, и Qt )
    • +6
      По моим ощущениям, все радикальные новшества вроде Core и Jigsaw требуют «конопашиться» годы, и если в случае с Core уже прошло больше года и теперь всё наконец становится осмысленненее, то в Java летом с выходом Jigsaw долгое конопашенье только начнётся :)
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          А в чем сила Jigsaw? Я прочитал немного, но там только про модульность. Тот же принцип, что и в .Net Standard, но я не знаю деталей (ни того, ни другого).
          • НЛО прилетело и опубликовало эту надпись здесь
            • +6
              Это более гибкие возможности контроля доступа к классам чем InternalsVisibleToAttribute.
              Вот вы сейчас вообще ничего не прояснили
          • 0

            Jigsaw это не только разбиение монолитного JDK на кусочки как с .net core где System.Web всех просто достал. Это тотальная электрификация батенька модуляризация с такими понятиями как объявление и выгрузка модулей, это своего рода эволюция по пути node.js(но только в плане модулей!).

            • +2
              Эм. Как бы .net тоже самое, вплоть то до того, что рантайм это зависимость в nuget
              • –2

                В .net все "пакуется" в dll, в java в jar/war/ear потом это все может распространятся через nuget/maven. Так вот jigsaw привносит так же понятие модулей, вот что можно вкратце почерпнуть из указанного выше источника


                In short, JARs are a good attempt at modularization, but they don't fulfill all the requirements for a truly modular environment.

                Тоже самое но в меньшей степени касается .net, там вероятность dll ада меньше из за "сильных" имен сборок.


                В .NET core никаких понятий модуля нет, просто монолитный .NET порезан и разливается через nuget.

                • 0
                  Вообще все проекты могут быть собраны в nuget пакет, который так же объявляет свои зависимости(причем не либами, а пакетами). Единственное отличие, которое я пока увидел — exports. Но зачем, если есть модификаторы видимости..?
                  Не помню, оставили ли они или нет, но .Net Core можно было просто исходниками в пакете гонять, и компилировать рослином по необходимости.
                  • 0

                    Зависимости в случае maven/nuget указываются на уровне упаковки(package).

                    • 0
                      PackageReference Include="System.ComponentModel" Version="4.3.0"

                      Прям в csproj файле.

                      Не понимаю прикола в языке с модификаторами видимости пытаться копировать js…
                      • –1

                        Нет в csproj файле насколько я помню вы указываете локальные зависимости а вот nuget зависимости идут отдельно в отдельном файле на уровне проекта вроде в packages.config. Когда в вы устанавливаете что то, то нугет вам это бережно пихает в csproj.


                        Я не сказал что они пытаются копировать js, я говорил про схожий путь.

                        • 0
                          Уже неправильно помните. Дополнения к формату CSPROJ для .NET Core. Оно кстати и для не Core проектов в 17 студии работает вроде.

                          <Project Sdk="Microsoft.NET.Sdk">
                            <PropertyGroup>
                              <OutputType>Exe</OutputType>
                              <TargetFramework>netcoreapp1.0</TargetFramework>
                            </PropertyGroup>
                          
                            <ItemGroup>
                              <PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
                            </ItemGroup>
                          </Project>
                          
                          • –3

                            Я не могу помнить чего не ведаю :), я говорил о среде до .net core, с чем приходилось работать. С .net core я прекратил все общение когда они забросили project.json ибо не вижу смысла тратить время на то что возможно не доживет до релиза.

                            • +1
                              Ну собственно это и есть замена project.json. Только ее можно включать в билд процессы нормально, импортировать таргеты и пропсы. На большом проекте это просто счастье.
                              Ну сам Core уже до второго релиза почти дожил :)
                            • +1
                              Простите, а вы действительно считаете project.json хорошим решением?
                  • 0

                    Всё ещё можно. Просто пропишите файл как content и он nuget pack'ом будет доставляться при установке.

            • –1
              А можно поподробнее про node и jigsaw? Не совсем понимаю просто про объявление модуля.
              • 0

                Вот пожалуйста, там файлы module-info описывают что должен экспортировать модуль плюс его зависимости итд.

                • 0

                  А в описании требуемых модулей версионирование предусмотрено?

                  • 0

                    Пока не знаю но каждый модуль имеет свою версию. Что бы точно ответить на ваш вопрос нужно покопаться в спецификации.

            • 0
              Вот как раз выгрузки-загрузки модулей там нет, говорят, пользуйтесь OSGI, но OSGI не распилит нам ядро. И версионирования этих модулей по-моему в итоге тож не сделали.
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Дык пользуемся. С допотопных времен еще. Только jigsaw и OSGI — это совсем не одно и то же. А там вон выше попытались приписать jigsaw свойства, которыми он не обладает.
      • 0

        Если не ошибаюсь то Jigsaw был начат под другим названием еще под Sun(между java 6 и 7), так что ему не пол года от роду. А вот по .net core, там не столько кропотливый труд сколько терзания сомнениями и ошибки на стадии дизайна, отсюда и фокусы типа был poroject.json и нет его, прыг скок обратно на msbuild. До осмысленного конца там еще боюсь далеко, и может не дойти до него вовсе, а выпилят какой нибудь сурагат.

        • +1
          Вы правы, над Jigsaw дольше работают (хотя .NET Core анонсирован в 2014-м, тоже не сказать чтобы вчера). Но по внешним признакам мне кажется, что там всё равно с релизом начнётся веселье, и переход к модулям будет долгим и болезненным.
        • +1
          Ну всё таки project.json это не «ошибки дизайна платформы». Это желание новых людей сделать модно «как у них» сейчас и здесь. В смысле как Node/npm. Это понятно. Но нужна обратная совместимость и преемственность. Откатили. Конечно, лучше бы сразу сделали всё правильно. Но тогда, возможно, вообще бы всего этого не было. Потому как есть ощущение, что просто команда asp.net тихой сапой решила сделать новый .net для себя сначала. А потом убедила всех, что это реально и надо развивать. Это чисто моё ощущение.
          • –1
            Это желание новых людей сделать модно «как у них» сейчас и здесь

            Вот! Вот от таких мыслей при проектировании хорошие системы и загибаются. «Как у них» — не значит «хорошо». project.json для сборки .NET-проектов очевидно не подходит, ибо как вылазит проблема совместимости со старыми системами, завязанными на специфические особенности msbuild-а, как верно команда .NET Core заметила в своем блоге.

            У меня просто солидный опыт работы с MSBuild и это реально очень удобная система сборки чем-то похожая на ant. project.json сильно уступает ей в функциональности. project.json отлично работает на маленьких и простых проектах и превращается в сущий ад на попытке собрать большой проект (я собирал свой фреймворк с помощью project.json — прошелся по такому количеству граблей, что страшно становится)
    • 0
      Большие компании используют open source, и .net core скоро заинтересует их, как и другие языки в свое время.
      Видео 34:41

    • –2
      Я думаю, что тут выдается желаемое за действительное. Мне кажется, что .Net Core был скорее вопросом выживания платформы, а не ее доминирования. Как можно прочесть между строк в самой статье — не кросс платформенные решения уже практически не жизнеспособны.

      С другой стороны, странно было бы слышать от идеологов и сторонников технологии «надеюсь теперь не сдохнем» — это вряд ли привлечет новых сторонников :)

      Хотя в любом случае, я сторонник здоровой конкуренции — если .Net Core будет объективно лучше Java — выиграют все.
  • 0

    Есть ли данное интервью на английском языке?

    • +5
      Есть, пока нигде не опубликовано. Надо?
      • +1
        Как я понял, это перевод. Хочется видеть ссылку на оригинал.
        • +4
          Считайте, что это оригинал. Интервью брал я, переводил итогово я, этот текст в интернете выложен впервые.

          Английскую версию надо тоже редактировать и куда верстать. Когда выложу, в этой ветке отпишусь.
      • +1
        Да, хочется поделиться с коллегами из UK
        • +2
          Напишу вам, когда будет готово.
  • –10
    одна реклама. «Используйте это, потому что ваше старое с багами. Используйте это, а это тоже устарело» и ни одного примера чем же лучше и какие баги.

    Пытался понять что за NET Core, вроде как мне не надо. «Главное убедитесь, что не используете WPF и WinForms, и всё будет хорошо». А как там рисовать формы для десктопов (вин и линь)? Или это чисто веб? Также весело насчёт веба — из бесплатного и/или доступного только пхп и больше ничего.
    • +2

      Сделать интерфейс энтерпрайз приложения в виде rich web application с учётом всяких websockets и single page application frameworks это довольно хорошая идея в 2017 году. Excel может запуститься в браузере, а опердень нет?


      И поясните пожалуйста по поводу php — так то это самый незахайпленный сегодня язык из бесплатных и доступных.

      • 0

        Проблема в прожорливости таких решений. Наш каталог контролов после прокликивания всех вкладок кушает 42 мегабайта в private working set. И это на альфа-версии фреймворка, который никто особо не оптимизировал. Открываем в качестве единственной вкладки в хроме "хэлловорлд" на ангуларе (если кто возьмётся склепать аналог приложения для нормального сравнения — велкам), то спавнится в сумме 5 процессов, отъедающих больше сотни мегабайт в сумме.


        И если при большом числе вкладок хром внутри себя ещё как-то нормально управляет ресурсами, то когда люди начинают делать "десктопные приложения", по факту перепаковывая сайт с браузерным движком, становится очень грустно.

    • +1
      Ну так-то есть CEF, позволяющий невозбранно клепать UI-часть на web-стеке. Правда что у них там с .NET Core пока неясно.
    • +1
      одна реклама. «Используйте это, потому что ваше старое с багами. Используйте это, а это тоже устарело» и ни одного примера чем же лучше и какие баги.
      Не используйте бета-версию .Net core потому что она старая и с багами. Если используете более старый, но стабильный .NET, то смотрите по ситуации. С каких пор это реклама?

      А как там рисовать формы для десктопов (вин и линь)? Или это чисто веб?
      Веб и консоль, пока.
  • 0
    Что-то недопонял. Если donetcore — это не про десктоп и не про asp.net core, то про что же?
  • +6
    Как перебежчик из .NET лагеря на территорию потенциального противника, могу сказать что главный фокус .NET сейчас должен быть не на платформе или языке. Платформа в целом неплохая, язык так вообще один из лучших мейнстримовых языков по балансу «фичность — практичность» (хотя кажется, команду C# все больше сносит в сторону «фичи»). Фокус должен быть на экосистему и сообщество. Java рулит не из-за языка — а из-за невероятного количества production-ready библиотек на любой вкус и наличия решения для почти любой инфраструктурной задачи. .NET как минимум нужны:
    — IDE уровня IDEA (+ бесплатная community версия)
    — аналоги Spring Framework (для политкорректности — или Java EE)
    — экосистема тестирования (Mockito, WireMock, JUnit, Spring Test)
    — экосистема CI/CD
    — полный набор для production — легковесные контейнерные runtime-ы, мониторинги, анализы, да много всего
    — проекты уровня Netflix OSS для облака и микросервисов
    — про отвязку от Windows думаю даже говорить не нужно
    — база знаний сообщества
    — … и многое другое

    И здесь немного парадоксальный вывод: как мне кажется, чтобы помочь платформе развиваться Майкрософт… нужно слегка притормозить. Нужно перестать менять форматы проектов, менять инструментарий, менять API, выпускать тонны разных продуктов с разными версиями, часто несовместимые друг с другом. Я помню ситуации когда туториалы по .NET Core двух-трех месячной давности были не актуальны! Даже среди .NET Core сторонников иногда звучат голоса, что Майкрософт слишком гонит вперед. И если платформа стабилизируется, будет понятно куда она развивается, если Оракл окончательно настроит против себя сообщество и клиентов, то может через год-два .NET Core и потеснит Java. Хотя как бы не пришлось теснить и какой-нибудь Go к тому времени!