Наверняка, вы знаете, кто такой Джон Скит: №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 это не требовалось, в итоге это было исправлено. В итоге я обнаружил, что эта проверка и вызывала проблемы. Это было примерно так: - я вижу, что это занимает очень много времени
- задаю себе вопрос — это мой код тормозит процесс, или какой-то другой?
- я нашёл один тест, который показал проблему
- далее я убрал столько кода, сколько мог из этого теста
- после этого я исключил Noda Time, написав маленький проект, запускающий NUnit вообще без логического кода
- после чего исключил NUnit из схемы, покопавшись в коде NUnit-код и найдя проблему «ааа,
String.EndsWith(), окей, давай посмотрим, как оно выполняется» - в этот момент я уже мог воспроизвести проблему с кодом 10 строк длины, запускавшим
String.EndsWith()в цикле тысячи раз - стало понятно, что именно этот код на Linux отрабатывал медленно, а на Windows очень быстро
- и предоставив всю эту информацию на SO, я смог получить ответ о том, что причина в локали: она оптимизирована под Windows с UK English и не оптимизирована для Linux
- в итоге я смог подтвердить это путём запуска этого куска на 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 Акиньшина за помощь в подготовке поста. Плюсы вам в карму!
Поделиться с друзьями
vba
Ага когда выпустили .NET говорили что он убьет java очень скоро, мс даже спец программу организовало JUMP — Java User Migration Path. Не выгорело тогда, не выгорит и сейчас. MS с core конопашуться уже больше года, у java jigsaw должен выйти этим летом, не все так просто.
ARG89
Так никто не говорит об убийстве. Речь о возможности выбора и здоровой конкуренции.
vba
Выбор есть и сейчас. Вы уж простите но слышать о здоровой конкуренции в отношении MS как то без тика не получается.
VolCh
С Oracle получается?
vba
Не Oracle единым жива java, хвала аллаху.
ad1Dima
Не Microsoft единым жив .Net ;)
webmasterx
А чем еще он жив? Не продвигай Microsoft активно свой продукты среди студентов и университетов, ситуация с .NET была бы в худшую сторону
ad1Dima
Да, именно на студентах .Net и держится. (до оракла у Sun были Java ambassador если что).
justmara
смешно видеть на этой картинке JetBrains, которые даже под .net (resharper) пишут на Java/Kotlin ;)
DragonFire
Смешно читать такие глупости на хабре
ad1Dima
Решарпер-то как раз на .NET. Вот тут они пишут про проблемы с ним на Mono.
Lailore
решарпер написан на c#. Вы путаете с графической оболочкой написанной на java. Даже доклад про то, как они делали протокол общения между рантаймами
ARG89
Alexsey
Как минимум есть еще Unity, в котором большинство людей предпочитает использовать именно c#, несмотря на кучу других вариантов языков. А это уже очень большой приток людей.
ZimM
Нет в Юнити никакой кучи языков. Кроме C#, были еще UnityScript и Boo, второй уже окончательно похоронили давно, первый собираются похоронить со следующей версии. Так что да, практически все пишут на С#
pnovikov
Простите что вмешиваюсь, а разве Javascript в Unity не было?..
ZimM
Был UnityScript, который все называли JavaScript. Между ними огромная пропасть, но если не присматриваться, то было похоже на JS. Всего лишь завлекалочка для новичков и веб-разработчиков.
khoramus
Javascript в Unity отличается от стандарта и называется UnityScript.
mrsantak
Java заняла нишу enterprise когда oracle был ещё не при делах. Тогда это был ещё Sun.
OnYourLips
А о здоровой конкуренции в отношении Oracle? Это ещё менее вероятно.
TheKnight
Ждем IDE уровня IntelliJ IDE написанную на .NET и кроссплатформенную при этом. Тогда можно будет говорить о переходе.
Уточню — целиком на .NET. Проект Rider — не то. Хотя если имплементировать какой то бекэнд, который сможет воспользоваться наработками Rider…
Там Visual Studio еще не портировали на Linux?
Oxoron
Visual Studio --
Vadem
Visual Studio Code и Visual Studio это две совершенно разные вещи.
izzholtik
Это как Java и JavaScript. Обречены на неразбериху во имя маркетинга.
TheKnight
Во первых это не Visual Studio, как заметили выше. В качестве текстового редактора я могу и ViM (Sublime, emacs, etc.) использовать.
Во вторых
достаточно того что и во первыхэто приложение на Electron. Увы :(mayorovp
Какое отношение эта гипотетическая IDE имеет к энтерпрайзу?
TheKnight
Показатель зрелости платформы. Наличие на Linux/MacOS IDE для .NET написаной на этом самом .NET означает возможность писать самые разнообразные приложения(desktop + server).
Уточню — это лишь мое мнение, но в любом случае — в чем то же надо писать код? Пока что я не вижу IDE уровня IntelliJ IDEA или Visual Studio под эти платформы (да даже не важно на чем оно написано). Ежели я ошибаюсь — прошу меня поправить и указать на мою ошибку ссылкой.
mayorovp
Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.
Используют же некоторые дизайнеры MacOS чтобы рисовать интерфейсы под винду...
Karpion
Вообще-то, между «писать код» и «рисовать интерфейсы» имеется принципиальная разница. Но т.к. целевая аудитория маркетоложцев эту разницу не знает, то в рекламе Ваш аргумент вполне сгодится.
yorick_kiev_ua
Ну вообще-то куча всего для мобильных устройств /приставок/всякого специального железа пишется в Винде отлаживается в ней же или в эмуляторах, и никакая «принципиальная разница» никого не.
В случае «пилим кговавый ынтерпрайз, работающий на сервере в виртуальной машине» ИМХО вообще пофигу на среду, к которой пишем. И довольно значительный процент явистов, пишущих в винде тому подтверждение.
TheKnight
Мешает. Самооценка и тараканы в голове. Ну это лично мне.
Мне не повезло познакомится с линуксом в раннем возрасте и учиться писать код я начинал именно с линукса. С тех пор родовая травма — не могу использовать Windows для разработки. Точнее могу, но это неприятно.
khim
Понятно, что живущие в «default operating system» об этом не задумываются (как и живущие в «default city»), но Microsoft Windows — это «остров, у которого всё своё». Собственно это специально сделали — и этот подход отлично работал: стоит вам использовать хоть что-то от Microsoft — и вам придётся использовать массу других вещей от них же. Но в Enterprise — всё не так: не нужен там никакой Microsoft (у них Oracle рулит и стонут они от него так же, как от Microsoft'а стонет малый бизнес — но это другая история), так что IDE под «default opertaion system», извините, не вариант.
Собственно Microsoft это осознал примерно тогда же, когда и все остальные — но, увы, если «стены» стоить десятилятеями, то дальше их разрушить за пару лет — не выйдет.
mayorovp
Э… а конкретные примеры того, что нельзя подружить, будут?
Для меня, как для программиста, все довольно понятно — есть задача, есть протокол/формат/что-то еще, есть библиотека, пишу решение. Если нет библиотеки — пишу решение дольше, с перспективой создания библиотеки.
В какой момент возникают пляски с бубнами, которые не позволяют мне писать решение для задачи?
khim
В тот момент, когда вы решили, что хотите использовать «default operation system».
Вспомните ещё раз: мы тут про «ынтырпрайз», да? Ну и хорошо, понеслась. Для доступа в Internet — у вас какой-нибудь Uberproxy с правами доступа в LDAP и авторизацией через Kerberos. Печатаете вы через CUPS, общие файлы — выкладываются на NFS, а управляется это всё — через Ansible.
И вот вы во всё это желаете вкрутить вашу «default operation system». Кто будет «дружить» эти два мира? Притом, что Windows-админы, которых вы можете найти на рынке обычно — «ни в зуб ногой в области POSIX-технологий», а POSIX-админам — ваши «default operation system» со всеми их заморочками — не нужны от слова «совсем»?
mayorovp
Все еще не понимаю, зачем в такой структуре нужны виндовые серверы.
TheKnight
Они не нужны. Как и виндовые десктопы для разработки :)
mayorovp
А, я понял. Вы рассматриваете гипотетическую ситуацию, когда какая-то совтописательная фирма с инфраструктурой только на линуксе пытается начать писать на .NET.
Да, это может внезапно оказаться довольно сложным процессом.
Но конкретному разработчику, в отличие от организации, перейти на новый язык довольно просто. Достаточно всего лишь его выучить, после чего найти себе новое место работы.
TheKnight
Вы забыли время на изучение инфраструктуры для разработки на этом языке и время на изучение ОС. Разработчики они разные. Я вот Windows дома не держу уже несколько лет.
Neftedollar
ок, тогда что вы тут в комментариях делаете? Да, вам .net core не подходит, это стало понятно из комментариев выше, мне это было важно и дествительно интересно услышать. Но если вам он не подходит, не значит что не подходит другим.
TheKnight
Внезапно! Они утверждают, что .NET пригоден для разработки под Linux без лишних телодвижений!
Вот я и пытаюсь понять, они немного преувеличивают, преувеличивают нагло или же все хорошо и можно писать код?
Пока что получается, что преувеличивают нагло и среднестатистический разработчик не желающий использовать Windows удобным образом писать под .NET не сможет. Согласны?
khim
Собственно в этом весь смысл всех этих телодвижений. Как уже говорилось много лет назад: Microsoft категорически не заинтересован в том, чтобы люди могли использовать их инструменты без их экосистемы. Попытку сделать так, чтобы люди использовали везде и всюду только и исключительно экосистему Microsoft провалилась. Таким образом приходится мириться с существованием других систем и пытаться сделать так, чтобы разработчики туда не убежали.
Ну подумайте сами: какой смысл Microsoft'у делать хоть что-то для того, чтобы улучшить жизнь разрабочиков, использующих не Windows?
khim
Через год-два .NET Core потеснит Java на рынке enterprise решений
Это у вас «конкретный разработчик» не связанный ни с какой организацией играет на рынке «enterprise решений»?
mayorovp
Все проекты делаются конкретными разработчиками.
khim
Вот только в случае с «enterprise решениями» они, как правило, работают не в одиночку, а в команде. И интересы пресловутого «enterprise» в 100 раз важнее интересов конкретного разработчика.
Разработать без интеграции с существующими решаниями вам дадут разве что «приложение» для заказа пиццы в офис. Во всех остальных случаях — я придётся учитывать и ограничения вещей, созданных 40 лет назад на Cobol'е и 10 лет назад на Java.
mayorovp
Не вижу никаких проблем интегрироваться с чем-то, созданным 40 лет назад на Cobol или 10 лет назад на Java.
Kyoki
Т.е. Вы предлагает к ИДЕ докупить еше и винду + выделить для нее машину (виртуалку), только чтобы…?
mayorovp
Удобный язык программирования — это вполне достаточный повод купить винду, IDE и даже новый компьютер. Если вы и правда квалифицированный энтерпрайз-разработчик, чье время ценно.
khim
В мире энтерпрайзра Windows — так и не стала «default operation system», несмотря на все потуги (если бы стала — рассказов про то, что она вот-вот «всех порвёт на энтерпрайз-рынке» не было бы). Так что вам, в прикуску к «новому языку» придётся одновременно изучить новую OS и новую IDE.
То есть вы должны быть фактически готовы переехать в другую страну, выучить новый язык, сменить машину, работу
и жену— и всё это ради каких-то мифических плюшек этого языка, про которые вы заранее ничего не знаете?Вы точно уверены, что вы всё ещё «квалифицированный энтерпрайз-разработчик, чье время ценно», а не «безбашенный стартапер, которому семь вёрст не крюк»?
navion
AD и Exchange есть у всех, даже в Яндексе с Фейсбуком.
TheKnight
А можно чуть подробней про Exchange в Яндексе? Зачем он им?
navion
OWA извне больше недоступна, есть только Autodiscover:
Подробности надо спрашивать у яндексоидов, думаю оставили для бизнеса привыкшего к удобству: достойных конкурентов связке Outlook + Exchange так и не появилось.
khim
Одно дело — иметь тестовый стенд для разработки Windows-приложений, совсем другое — давать доступ в корпоративную сеть.
navion
Большинство российских банков использует AD для авторизации/аутентификации, хотя бизнес-приложения могут крутиться на Linux, AIX или OS/400.
Paskin
Продакшен-системы мобильных операторов тоже. Лично писал надстройку над OpenLdap для интеграции нашей Linux-системы — нахождения нужных данных в распределенном по разным серверам дереве AD.
TheKnight
В моей жизни было полгода(с конца августа по середину марта) когда я вынужден был использовать Windows 7 как ОС для разработки на Java.
Спасало только наличие неплохого GUI в IntelliJ IDEA. Любой шаг в сторону от стандартного флоу «закодил — > запустил тесты -> закоммитил» был тяжек и труден. Все что в линуксе решается в одном окошке консоли на винде требовало больше усилий и движений. В гробу я видал Windows 7 как ОС для разработки на Java.
Если работа в энтерпрайзе требует работы на винде — к черту такую работу, я лучше продолжу писать тулы по автоматизации тестирования или переквалифицируюсь хипстеры :)
P.S.: Удобное рабочее окружение — это повод купить Mac. Однако не все могут согласиться с этим.
mayorovp
Пытаюсь вспомнить какие лишние движения мне приходится совершать при ежедневной разработке — и не могу. Разве что установка нужных программ вспоминается — но она делается всего один раз.
Мне кажется, это просто сказывалась субъективная непривычность обстановки, а не какие-то объективные недостатки.
Не могли бы вы уточнить что именно требовало у вас избыточного числа движений?
TheKnight
Поясню на примере — для выполнения этих задач в Linux мне требовалось всего одно окошко терминала в котором я мог все эти задачи выполнить одинаково хорошо. В Windows это требовало 4 разных окошек — Git Bash, SuperPutty, окошко запуска команд в IntelliJ IDEA и наконец Cygwin. Половина из этих инструментов не кастомизировалась или кастомизировалась весьма не просто в плане внешнего вида(банальные шрифты).
Этого достаточно?
mayorovp
Для всех этих задач вполне достаточно одного окна, раз уж для вас это так важно.
Для начала, Git Bash для работы с Git не обязателен.
Далее, никто не запрещает вместо Putty (кстати, что это за сборка такая — SuperPutty?) использовать OpenSSH, тем более что ssh.exe идет вместе с git.
Сборку проекта можно делать в том же самом окне если правильно прописать переменные окружения.
Для четверной задачи, раз вы привыкли к linux-окружению, конечно же придется использовать cygwin… Вот только cygwin не отбирает у вас возможность использовать git, openssh и собирать проект в том же самом окне.
TheKnight
К сожалению все вместе так и не получилось это настроить удобным образом. Возможно дело в руках или отсутствии желания.
Да и выглядит это все как то не очень красиво (я сейчас именно про внешний вид), возможно из-за ограничений виндового терминала.
mayorovp
Ну, это больше ограничения стандартных шрифтов. И стандартного же cmd.exe. Те же git bash или консоль cygwin выглядят довольно неплохо, на мой вкус.
Говорят, еще в десятой винде консоль значительно переделали. Но сам я десятку еще не трогал, сижу на семерках-восьмерках.
TheKnight
Была бы на моей прошлой работе десятка с Ubuntu on Windows — я бы может и относился бы к винде по другому. С семеркой подружиться после нескольких лет линукса не получилось.
P.S.: Хабрасуицид совершен успешно)
Razaz
Вот тут ссылочку давал :)
pnovikov
При всем обилии адептов Windows, которые плачутся что Linux слишком сложен, я впервые вижу линуксоида, который плачется что windows слишком сложен. Как говорится, не думал что доживу до этого момента.
TheKnight
Он не сложен, он не удобен. Он заставляет ломать сложившиеся привычки. Как и Linux для пользователей Windows.
Все дело в привычках. Банальная вставка по средней клавиши мыши(отвыкать пришлось долго). Удобный и красивый эмулятор терминала. И много других мелочей которых нет на тех версиях Windows, с которыми я работал и которые есть в Linux. Ну и разумеется отсутствие привычного софта без костылей для установки и использования.
Аналогично можно расписать неудобства Linux — отсутствие привычного софта, установка ПО из репозитария через GUI либо командную строку, настройка определенной части оного путем редактирования текстовых конфигов вместо удобной GUI. Да даже банальная структура директорий непривычна. Все это влияет на удобство и сложность использования.
Возможно, Windows 10 многое изменит, но когда она еще попадет на рабочие места в кровавом энтерпрайзе? Я искренне радовался выходу Ubuntu on Windows. А потома до меня дошло, что большая часть работодателей вряд ли в ближайшее время запланируют апгрейд. И следовательно смысла в этой подсистеме не очень много.
kekekeks
Вставку по средней кнопке в протоколе Нового Более Лучшего Дисплейного Сервера убрали, кстати. Во всяких федорах её сбоку изолентой прикрутили
TheKnight
Это вы так вайланд обозвали?
Блин, сволочи они(
ad1Dima
Razaz
Это что-то меняет для разработика или админа? :)
ad1Dima
На клиентской машине баш-скрипты не запустишь.
Razaz
А зачем они вам на клиентской машине, а не серваке? 0_о
mrsantak
Использовать можно. Удобно — далеко не всегда. Можно конечно пользоваться виртуалками, но это опять таки менее удобно получается. Всякие hot redeploy и прочее далеко не всегда работают сквозь виртуалку.
Razaz
Ubuntu on Windows. Там вполне неплохо поддержали много апи в AE. Редиска уже там, все утилиты то же через это чудо. wrk нормально собирается и работает. Пока другое не пробовал, но вполне. Может будет интересно.
mayorovp
Напомню, мы говорим об энтерпрайзе. Тут считается нормальным купить за большие деньги Talend MDM, который идет со своей Talend MDM Studio на базе Eclipse и не имеет консольных утилит для сборки (прощай, CI и CD!), и посадить опытных Java-разработчиков парсить XML-документы регулярками, потому что другого API не завезли.
И чтобы жизнь медом не казалась, надо загнать всех на удаленную работу через тормозной и глючный VPN, работающий только через IE на терминальный сервер, где один экземпляр Talend MDM Studio выжирает по 2 гига памяти, а их запущено пять штук...
А когда настанет время развертывания релиза на стенде интеграционного тестирования — то десять тысяч документов будут загружаться напрямую в базу вручную разработчиками потому что Talend на таких объемах умирает.
А другой разработчик будет их же публиковать на портале, потому что интеграция не работает в этом режиме.
И после этого вы жалуетесь на какие-то виртуалки? Между прочим, на хорошем железе виртуалки довольно шустро работают, даже если внутрях — серверная винда с Sharepoint… Тоже, кстати, тормозная хрень, но хотя бы память не выжирает и CI поддерживает.
mrsantak
Рассуждения "у кого-то процесс разработки построен через жопу, поэтому мы тоже через жопу делать будем" порочны по самой своей сути.
А виртуалки мне не нравятся не из-за тормознутости (вот как раз эта проблема решается легко).
Вот один пример из жизни пример — на одном из проектов были тесты, которые нормально работают только под линукс. А разработка под виндой. Как результат нельзя просто взять и запустить тесты из IDE. Можно запустить из консоли через билд систему (maven), но там запускаются все тесты, а прогон всех тестов занимает минут 20-30. Да, это можно решить отдав правильные аргументы maven'у, но все-равно неудобно. Ну и запустить таким образом тесты с дебагом становится отдельным испытанием.
TheKnight
Remoute build?
staticlab
Насколько я понимаю, на альтернативных платформах у дотнета в принципе нет официально поддерживаемого GUI.
DragonFire
А чем все-таки Rider не угодил?
TheKnight
В остальном я верю в JetBrains и в то, что у них выйдет офигенный инструмент. У меня и претензий то к нему нет, есть претензии к отсутствию аналога написанного целиком на .NET.
P.S.: [humor]А как прописывается тег хабрасуицид?[/humor]
DragonFire
Абсолютно согласен, что Rider нельзя называть примерном зрелости кросплатформенного .net, мой вопрос был больше к фразе «Пока что я не вижу IDE уровня IntelliJ IDEA или Visual Studio под эти платформы (да даже не важно на чем оно написано). » =)
TheKnight
Наверное дело все же в EAP статусе Rider. Все же этот статус накладывает определенные ограничения на его использование. Точнее, на его оценку как хорошего инструмента.
Что то может измениться, в том числе и критично для пользователя. Посему, конкретные выводы делать рано. Но я в вас верю :)
23derevo
зачем вам чистый .NET?
TheKnight
Затем что мне не хочется писать гибридное приложение с GUI на Java и логикой на .NET.
Кроме того хочется переиспользовать имеющиеся наработки и просто портировать приложение внутри одной платформы, не переписывая его целиком на другом языке.
Lailore
Rider. В нем графическая оболочка это java, а логика c#. Как раз тот пример, который вам нужен?
TheKnight
Это как раз пример того, что мне не нужно. Читайте пожалуйста внимательней.
Lailore
Точно, приношу извинения.
worldxaker
уже есть либы позволяющие писать кросплатформенную графику на .net core
MonkAlex
Примеры бы. Я пока только авалонию видел.
kekekeks
Как минимум
https://github.com/mellinoe/ImGui.NET
https://github.com/robertsundstrom/gtk-core
MonkAlex
Выглядит как заброшенная попытка в обоих случаях.
А wpf-like у авалонии мне нравится, смотрю как процесс движется уже давно)
kekekeks
Приезжайте в мае на .NEXT, там про неё слот будет.
DistortNeo
Тем, что он не является полноценной заменой Visual Studio:
Лично для меня эти моменты очень приципиальны. Поэтому для написания кода я обычно использую Rider, но если нужен отладчик — переключаюсь в VS.
DragonFire
Ну так и в статье написано, что «через год-два». Первый пункт неоспорим, а остальные мы надеемся поправить к этому времени =)
inormis
В нашем solution (150 проектов, WPF, Xamarin), тянет на ура. При вытягивании изменений из гита, за 1-2 секунды готов уже к работе, тогда как студия с трудом переживает внешние изменения в более чем 2-3 проектах. Как правило выжирает 2гб оперативной памяти и зависает.
Райдер (не холодный запуск) за 5с открывает наш solution, тогда как студия (2015) 30-40с.
Никаких тормозов уже не наблюдаю. 2 месяца пишу только в нем.
Последние 2-3 EAP стали вполне рабочими, хотя баги встречаются, но не были для меня принципиальными.
sshikov
Да дело далеко не только в IDE. И вообще не в языках. Я бы лично хотел посмотреть на хоть какой-то аналог OSGI. Или ESB (что-нибудь вроде Camel). Или я не туда смотрю — но ничего подобного вобще не попадается на глаза.
dimaaan
OSGI -> AppDomains
ESB -> WCF
Конечно они не идентичны, но решают похожие задачи
ggrnd0
AppDomains это всего навсего аналог ClassLoaders, только медленный.
С OSGi можно MEF сравнить
sshikov
Насколько я понимаю (хотя тут я могу ошибаться), WCF далеко не аналог шине в нормальном ее виде. Т.е. скажем это ближе к Apache CXF, в лучшем случае, а до Karaf + Camel + CXF + MQ, так как выглядит нормальная шина в мире Java, ему как до луны.
Вот насколько они не идентичны — настолько .Net code Java и потеснит в энтерпрайзе :)
dimaaan
Все дело в том, что значит "нормальная".
Когда я делал корпоративное ПО на 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-системах, вот и получается прямая конкуренция.
sshikov
Что значит "нет проблемы", которую решает Camel?
Camel не решает технические проблемы JVM или языка — он решает бизнес проблемы интеграции. И аналоги у него есть совершенно прямые — например MS SSIS. И это не просто ужас, а ужас-ужас-ужас. Это я не к тому, что решения от MS плохие, а к тому, что есть бизнес проблема интеграции, которую пытается решать например SSIS, и решает ее по сравнению с Camel ужасно. Суть в том, что потребность есть, и еще какая.
OSGI в общем-то тоже — потому что проблема иметь независимые взаимодействующие компоненты называйте их как хотите, но не будете же вы утверждать, что возня вокруг "микросервисов" происходит на пустом месте?).
Так вот OSGI — это и есть микросервисы в чистом виде. IOC ему кстати не замена, а лишь маленькая его часть.
Ну и кстати в разрезе IDE — меня лично гораздо больше волнуют другие инструменты, потому что после maven/gtadle/чего угодно такая штуковина как MSBuild просто выводит из себя.
Razaz
Не MSBuild ом единым.Есть PSake, Cake. Для F# есть Fake. Это из тех что я знаю.
А что у вас с MSBuild? В принципе после прочтения пары док вполне неплохо. Собираю им сложные проекты, в него же уехали gulp, npm, webpack и куча PS скриптов.
Neftedollar
Fake не только для F#, так же как и PSake и Cake не только для проектов на C#.
mayorovp
SSIS — это хрень, которую продают никогда не писавшие кода маркетологи никогда не писавшим кода архитекторам.
Не следует по этой хрени судить о экосистеме .NET, тут есть и более приятные вещи.
sshikov
Я его привел исключительно в качестве примера наличия потребности, которой якобы нет.
mayorovp
Честно говоря, я не понимаю какую потребность предполагается решать с помощью SSIS, потому что оно ничего не решает. Под словом же "интеграция" иногда подразумеваются совершенно разные вещи...
sshikov
Ну, типичный кейс выглядит как-то так — есть несвязанные между собой изначально системы. Нужно как-то их связать, передавая данные. Как принято, на входе с ними работает процесс ETL. Он может принимать файлы, а может таблицы из другой базы. И на выходе может делать разное. Как мне тут намекнули, WCF все-таки очень похожая штука — есть endpoints, которые являются входами и выходами, и есть некие маршруты обработки и передачи данных между ними (обычно именуемые EIP).
Вот эти вот ETL на нем и пишут. В моем проекте я ровно тоже самое делал на Camel, при этом значительно удобнее.
Опять же — это не довод за то, что какие-то там другие решения плохи или хороши — это довод именно за то, что потребность в разного рода ETL очень широкая.
Я про банки, если что...
mayorovp
Нет, WCF — это не про ETL. WCF — это про SOA.
У меня был опыт работы с ETL, и я считаю, что самый лучший формат для ETL-процедуры — это обычное консольное приложение.
Возможно, это связано с тем, что в мире .NET и правда нет хорошего инструмента для этих целей. А возможно, это связано с тем что мне приходилось выполнять одновременно работу программиста и системного администратора, и все те вещи, которые создавались для перекладывания работы с первых на вторых, лично мне работы лишь добавляли.
sshikov
А какая разница, SOA или нет, если там реально есть EIP? На входе например клиент SOA, потом маршрут обработки, потом какой-то выход. Если входы и выходы хоть как-то настраиваются, и есть какой-никакой язык для описания маршрутов (ну скажем, годится BPEL), то это и будет в конечном счете ESB или шина. Все же ETL это как правило некий клей для сервисов, написанных разными командами, и для этого удобнее средства типа скриптовых языков, или похожие инструменты.
Что же до консольного приложения в качестве ETL, то оно как бы и нормально, пока у вас их два. А когда их двадцать два, ими надо рулить, хотя бы в объеме чтобы само запустилось после рестарта сервера. Ну и как вы представляете себе 22 микросервиса в виде сервисов windows, например? Ну и потом, они могут быть хоть и независимые друг от друга по логике, но все равно зависимы по данным (например, на 100 сервисов порядка 10 коннектов к разным базам), поэтому настраивать теже коннкеты все-таки проще один раз, нежели для каждого из 100 микросервисов помнить, какая у нас тут база, это PROD или тестовый сервер, ну и все такое.
Ну то есть если совсем просто — то ESB или шина это обычно куча мелких сервисов интеграции, но с централизованным управлением и мониторингом.
mayorovp
Какой нафиг язык для описания маршрутов? Какой клей? Не выдумывайте чего не знаете. WCF — это библиотека для написания веб-сервисов, и ничего более.
sshikov
Это вопрос не ко мне. Про наличие там EIP не я придумал. Отмотайте комменты, да посмотрите.
@dimaaan 28 апреля 2017 в 18:40
Так вы договоритесь между собой, есть в WCF pipes, filters, или нету? Если есть — то то и есть маршруты.
mayorovp
Это случайное совпадение — одни и те же слова используются в разных смыслах. Тот кого вы цитируете увидел знакомые слова и сказал что это все есть.
Повторюсь: WCF — это библиотека для написания веб-сервисов или подключения к ним, а не платформа для их интеграции
sshikov
Я совершенно не специалист в WCF, но по-моему вы как минимум упрощаете. Я видел в документации (а не в комментах) и упоминание workflow, и message filters, и много чего еще, что явно не является веб-сервисами, а именно интеграцией. Это конечно может быть случайным совпадением, но MS в явном виде упоминает в доках на WCF как EIP вообще, так и конкретные паттерны, со ссылками на их реализацию.
mayorovp
Workflow — это отдельная библиотека, WWF (Windows Workflow Foundation).
Message filters и routing в WCF действительно есть — но нет инструментов для трансформации сообщений. И никаких аналогов биндингов из вот этого списка кроме трех там тоже нет.
mayorovp
Что же до ETL, то постоянно они работать не должны, ETL это по определению пакетная обработка по расписанию.
Для 22 ETL-процедур за глаза хватает одного консольного приложения с одним конфигом, нет необходимости разводить 22 отдельных проекта до тех пор, пока их разрабатывает один разработчик.
Запускать их можно через системный планировщик или через MS SQL Server Agent. К слову, те же джобы SSIS или Pentaho запускаются точно так же, в этом плане запуск консольного приложения ничем не отличается от того что предлагают якобы профессиональные инструменты.
Зато консольное приложение:
sshikov
Кто вам сказал эту чепуху? Если вы никогда не видели ETL, работающего по сообщениям скажем из MQ — это не значит, что их не бывает.
mayorovp
Если вы знаете больше меня по этой теме, не могли бы вы привести источники? В той же Википедии через слово пишется про базы данных и раздельные стадии обработки.
sshikov
Я просто работаю над этой темой уже лет 10. Базы даных и файлы — это было когда-то. А сейчас нормальные инструменты для делания ETL предполагают и позволяют переваривать данные, приходящие в любом режиме, и откуда угодно. Информатика какая-нибудь, или тот же camel — им по большому счету все равно, сообщения это или база. Возможно это меняет смысл термина, но тем не менее — то на чем сегодня делается ETL, оно именно такое. 24/7, терабайты данных в сутки, смесь пакетных загрузок и стриминга.
mayorovp
Одинаковые инструменты не говорят об одинаковости задач.
Но да, если мне нужно будет делать онлайн-обработку сообщений, бегущих через MQ — консольное приложение для этого я писать уже не буду. Сделаю вин-сервис :-)
Кстати, в 22 вин-сервисах на самом деле нет ничего страшного. Но проще, конечно же, обойтись одним.
dimaaan
Не знаком с SSIS, да и с Camel тоже. Насколько я понимаю это ETL инструменты. Я лишь хотел сказать, что EIP типа Каналы сообщений, Pipes, Filters, Router, Translator, Endpoint это все тоже часть WCF, поэтому и нет проблемы.
Насчет "OSGI — это и есть микросервисы", тогда и WCF — это тоже микросервисы. Значит опять нет проблемы.
П.С.
maven все же не совсем аналог msbuild. скорее аналог Ant.
Или же maven аналог msbuild+nuget.
А знакомство с системами сборки вообще частенько выводит из себя :)
В maven'е куча плагинов, надо с каждым разбираться (прямо как webpack).
В .net core конфиги msbuild похудели, так что все не так уж и плохо.
sshikov
Я в общем слабо знаком с WCF, поэтому пожалуй в такой формулировке соглашусь с тем, что это похоже на Camel. Лучше или хуже — не знаю, по похоже очевидно.
По вопросу микросервисов — ну тут дьявол как обычно в деталях.
OSGI в виде реализации — это все же не одни только микросервисы, там много чего поверх уже есть. Если совсем уж просто — то на сегодня это ближе скажем к kubernetes Т.е. это еще и оркестрация кластеров микросервисов, например.
Что же до msbuild… ну тут сложно и длинно. Например, первое что не нравится — его еще и устанавливать надо? Ни maven, ни ant, ни gradle не требуют никакой установки (как впрочем и JDK/JRE) — это просто папки.
Тоже самое впрочем касается и проблемы зависимостей как таковых, в мире Java это как правило jar, в разных его подвидах, и некий набор соглашений, где в нем могут лежать зависимости. И он рекурсивный по сути, т.е. один jar внутри другого — ничего такого в этом нет, и обработать это тоже легко.
То есть, я могу собрать только свои классы, запаковать обычным zip, и посмотреть потом тоже, и ресурсы положить туда же — и тоже посмотреть например far-ом. И поправить, если что. А могу собрать свои + зависимости, и сделать так называемый fat jar или uber jar — и задеплоить одним куском. Ничего близкого к этой идеологии в мире .Net мне пока не попадается.
mayorovp
Как вы запустите maven или ant из агента CI, если это "просто папка", лежащая незнамо где?
Надо или в PATH прописать, или положить в известное место, или завести отдельную. переменную окружения, или настроить свойство в агенте...
Хоть это все и мелочи, но в итоге получается что установить msbuild не сложнее чем maven. Хоть там и надо прокликать "далее"-"далее"-"далее" или заморачиваться с "тихой" установкой — но зато msbuild всегда лежит по известному пути.
Для деплоя на IIS можно собрать zip-архив и задеплоить его одним куском при помощи msdeploy.
Для деплоя на Sharepoint нужно собирать не zip, а cab.
Для деплоя на винду существует msi, который можно собрать при помощи wix и развернуть на ферме серверов через групповые политики домена.
И одна сборка всегда может достать из своих ресурсов другую и загрузить ее, так что велосипедостроение никто тоже не запрещает.
sshikov
Я запущу, и для этого конечно нужно знать папку. Но этих папок можно быть сколько угодно (как это обычно и бывает под Jenkins где-нибудь). Т.е. десять разных версий maven — никаких проблем не вызывает. Более того, дженкинс сам их и поставит, когда нужно. Одна версия из IDEA, другая из эклипса.
А внутри у Weblogic (и у груви заодно) — своя версия ant. Зачем — не знаю, но есть и работает.
Т.е. установки, как таковой, нет вообще, начиная с JDK, которую конечно тоже можно ставить из msi — а можно потом взять готовую папку и скопировать, и не будет никакой разницы (ну, почти никакой, если честно).
А что до msi… ну я как бы прекрасно знаю, что это такое. По сравнению с форматами установок типа jar/war — это примерно также, как старый OLE формат файлов ворда, по сравнению с новым zip форматом у него же — удобство просто несравнимое.
Суть моих мыслей — она простая, и вовсе не состоит в том, чтобы ругать .Net и принятые вокруг решения. Я изначально хотел сказать, что для энтерпрайза (и вообще успеха платформы) гораздо важнее, чем язык, вот такие вот мелочи типа системы сборки, или возможности прикрутить свою систкему сборки, если штатная не нравится.
И еще, в целом — поддержка или возможность ее допилить, для самых экзотических и старинных фиговин, которые только можно себе вообразить — потому что энтерпрайз это в первую очередь многолетние традиции, и куча внедренных и работающих легаси систем, которые никто не собирается выбрасывать просто потому, что они не модные.
mayorovp
Ну, разные версии msbuild тоже в разные папки ставятся.
Можно и скопировать. Но вы же сами хотели деплоить одним куском...
Полностью с вами согласен, я и сам считаю так же. Но поверьте — в .NET в этом плане все сделано правильно.
msbuild — это расширяемая система сборки, возможностей которой хватает для очень большого круга задач. А где не хватает — там можно сделать
<Exec Command="..." WorkingDirectory="..." />.sshikov
А зачем тогда msdeploy? ) Тут я кстати серьезно — сталкивался ровно с тем же, когда результат работы SSIS нужно установить на хост с базой. И написано, что нужно (или можно) для этого некую утилиту. При этом кто-то из команды просто взял, и скопировал, и оно работает, что вызывает некоторые вопросы — а зачем собственно утилита-то, и что она делает кроме копирования файлов?
Я не хотел одним куском. Я хотел в зависимости от задачи.
Ни разу и не говорил, что она никуда не годится — это у меня с ней некоторая несовместимость. Ну скажем так — я предпочитаю несколько больший уровень контроля с моей стороны, куда и что класть. И больший уровень понимания, как оно внутри работает (при том что претензий к MSDN у меня в общем-то никогда не было, документации много, и она приличного качества — но вот подиж ты, зачастую части идеологии куда-то ускользают).
mayorovp
Во-первых, msdeploy умеет создавать сайты, пулы и прочее (простое копирование сделает приложение частью существующего сайта или заменит существующий сайт).
Во-вторых, msdeploy работает по сети и является заменой колхозу на сетевых папках.
Соответственно, в зависимости от задачи можно использовать msdeploy, а можно — копирование.
SSIS хранит свои задачи в своей базе данных. Утилита читает файлы и загружает их в базу, раскладывая по табличкам. Да, это бред, но людям, которые привыкли строить энтерпрайз-решения вокруг сервера СУБД такой подход нравится.
Ну, если вы не понимаете чего-то конкретного, можете задать вопрос на ru.SO. Я там часто отвечаю.
Что же до идеологии… Я не вполне понимаю что такое идеология системы сборки но думаю, что у msbuild и ant идеология общая.
sshikov
Ну. exec command — это не плагин, это бяка ) Понятно что это на клайний случай, но все равно, это какая-то фича из эпохи make, по-хорошему, команде должен передаваться проект, а не непойми что. Причем она должна понимать, как он устроен, и где что лежит.
kekekeks
Ну вообще говоря можно и плагины писать и их подключать к проекту через nuget, мсбилд их подхватит. Всякий постпроцессинг сборок обычно так и работает.
mayorovp
exec я упомянул скорее как возможность сбежать с msbuild на любую другую систему сборки, поставив заглушки на цели Build, Rebuild и Clean :-)
Проект Visual Studio — это обычно и есть msbuild-файл. Если не использовать кривые магические надстройки для студии, то любой проект студии может быть собран msbuild, а любой файл msbuild может быть открыт студией как проект если дать ему правильное расширение и прописать правильный ProjectType.
Я так, кстати, часто делаю — создаю шарповый проект, удаляю из него импорт шарпового тулчейна и добавляю свои таргеты. Например, есть у меня проект, где исходниками являются jar-файлы, которые при сборке подаются на вход ikvmc...
Кстати, задача Exec в msbuild намного мощнее чем то же самое в make за счет языковых средств msbuild. MSBuild умеет работать со списками элементов проекта, преобразовывать их, фильтровать, группировать. Сами элементы проекта могут быть добавлены в явном виде (например, через IDE), получены сканированием директорий или получены как выходные параметры других задач.
Ну и ничто не мешает добавлять свои задачи, причем для этих целей есть аж три способа. Можно сделать свою сборку с задачами, можно создать задачу из C#-кода при помощи фабрики задач или же можно создать задачу из скрипта на powershell при помощи сторонней фабрики.
sshikov
Это пока у вас он один. Как только вам нужно подерживать скажем старую версию — вы приплыли.
mayorovp
Старая версия лежит по другому пути, не беспокойтесь.
Bronx
Что же до msbuild… ну тут сложно и длинно. Например, первое что не нравится — его еще и устанавливать надо?
Он с .NET поставляется, в "%SystemRoot%\Microsoft.NET\Framework\" соответствующей версии.
mayorovp
Нет, последние версии MSBuild ставятся отдельно.
Bronx
Про «последнююю версию» речи не было. Если нужна хоть какая-то — она есть сразу из коробки.
mayorovp
А нужна не "хоть какая-то", а та, которая способна собрать проект.
Bronx
Это уже от проекта зависит. Если человека ломает ставить MSBuild, значит и VS он не будет ставить, и значит в его «рукопашном» проекте не будет таргетов из студии и прочего. Если человек хочет делать проекты «как в Java», которые билдаются без необходимости ставить билд-систему, у него всё для этого есть (нужно ли это делать и почему так никто не делает — отдельный вопрос).
sshikov
Вы не поняли. "ломает ставить" — это не лично человека. Вот например, возьмите Jenkins. Для большинства систем сборки (и вообще инструментов) он сам умеет скачать и поставить их нужные версии, и подключить к сборке. То есть установка maven — это галочка в настройках проекта "нужен maven версии ххх". Потому что далеко не всегда (а скорее наоборот) сборка делается на машине разработчика. По-идее на машине CI одна должна делаться чаще.
Bronx
А эта галочка в настройках сама cкачивает maven, или, чтобы галочка работала, для неё нужно поставить Jenkins или что-то ещё? Непонятно, где выигрыш, если по-любому на CI-сервер нужно хоть что-то установить и ничего там «само» не заработает?
sshikov
Jenkins это и есть CI. Нет, не нужно, он сам все установит, начиная с JDK и кончая ant. Или maven.
Neftedollar
Я могу ошибаться, но вот про ubуr jar у нас был uber-nupkg (мне решение не очень нравится, но тогда оно было оправдвннаым) в этот nupkg пихали все-все-все деплоили его в локальный репозиторий nuget пакетов и потом скачивали на целевой машине и разворачивали, nupkg это тот же zip. Это если уж говорить о подходе убер-штук, но на самом деле ваш кей в .net не очень нужен. Я просто не могу представить зачем такое нужно.
sshikov
Дело даже не в uber jar — дело в том, что субъективно развертывание можно делать несколько проще (и даже сильно проще), чем это делает MS, когда предлагает свои продукты. И эта простота развертывания в какой-то степени важнее для успеха платформы в целом нежели качество языка (которое у c# вполне хорошее), или многоплатформенность (которая в какой-то степени опять же уже у .Net уже есть). Все остальное — это просто более или менее наглядные примеры, первые какие пришли в голову.
Razaz
Все развертывание .Net core — скопировать папку и запустить бинаркник с self-contained .Net.
sshikov
P.S. Кстати, то что я называл — это лишь часть. Например, вы можете представить аналог Hadoop на .Net? Или даже еще проще — любой софт, сильно завязанный на кластер, ну хоть тот же GridGain/Ingite?
И если нет, то почему его не существует?
Razaz
Вполне могу. Тут проблема не в платформе или ЯП, а в том, что Java заняла эту нишу раньше из за недальновидности менеджеров MS. Хотя уже появляются всякие RavenDB.
xhumanoid
после слов «вполне могу» желательно бы список продуктов на уровне 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), а достаточно долгий марафон. остается лишь пожелать удачи, конкуренция и обмен идеями никогда никому не вредила.
Razaz
Ну дак смысл то в том, что сам рантайм может многое потянуть при желании. А вот политика и менеджмент решают по своему. Сейчас вот включили мозги. Dryad помню, но решили просто использовать Hadoop. Ничего плохого в этом не вижу.
А по части оптимизации — магии не существует. Вы либо тюните параметры GC либо более точно работаете с памятью. Ну или и то и другое :) Даже Go с его типа уникальной разработкой ничего нового не принес.
Как раз возможность более детерминировано работать с ресурсами сейчас отличает .Net от Java в лучшую сторону.
Время покажет. В любом случае Java очень долго будет оставаться релевантной, ну если Оракл еще чего не учудит :) А .Net вполне занимает нишу между ней и node/ruby. Но это мои личные ощущения.
sshikov
Не-не. RavenDB это может и выглядит похоже, но совершенно не то. Суть в выполнении кода на том узле кластера, где у вас лежат данные. Это далеко не просто шардинг или кластеризация.
Razaz
Это хоть на перле все можно писать. Или у Java есть секретный ингредиент? ;D
sshikov
Покажите аналог на перле, я не против.
Razaz
Вы не поняли вопрос похоже. Повторю:
Что в Java отличает ее от других языков и платформ так, что только на ней можно написать Hadoop или GridGain или Ignite?
У Java есть одно преимущество — в тот момент, когда эти проекты рождались другой альтернативы не было, а сейчас просто нет смысла переписывать до тех пор пока всех это устраивает. Есть Golang, Rust, С++, тот же .Net. Или вы серьезно считаете, что нельзя выполнить .Net код на том же узле кластера где лежат данные? :D
sshikov
Это вы не поняли вопрос. Повторяю — расскажите, каким образом софт, написанный на перле или на питоне, попадет на нужный узел кластера, где расположены нужные нам сегодня данные? Кто скомпилирует этот софт, написанный на Go, Rust, C++, или том же .Net, именно под нужную архитектуру и ОС этого узла, и как доставит этот код с зависимостями на нужные узлы, прежде чем их можно будет там выполнить?
Razaz
Берете Рослин, компилируете, исполняете. Доставка на нужный узел — на ваше усмотрение, хоть через сообщения, хоть через что угодно. Можете либы готовые слать и вызывать.
Причем тут Java? Это просто написано на ней, но может быть переписано на другом ЯП, например Akka.Net.
sshikov
Эк вы ловко с перла и питона на рослин-то свалили...
Ага. Берете и исполняете. А потом у вас Process.execute("shutdown") где-то в коде затесался )))
У вас, простите, какой-то очень наивный взгляд на то, как можно выполнять заранее неизвестный код (ad-hoc) на кластере, так чтобы он а) работал (зависимости тоже нужно передать, а для начала собрать их) б) не завалил узлы кластера ни по какой причине, в том числе — потребляя чрезмерно ресурсы, в) имел доступ только к тем данным, к которым ему положено.
P.S. вы правда не знаете про такую секретную фичу, как возможность загрузить в JVM байт-код прямо из потока байт, не передавая никакие "готовые либы"?
Перепишите все на перл, да. У хадупа при всех достоинствах куча недостатков, тянущихся с рождения, когда он был просто MR поверх HDFS. Устраните — озолотитесь. Без всяких шуток. Все что вы тут рассказывали про "всех все устраивает" — не более чем байки. Не всех и не все.
dimaaan
Был аналог — DryadLINQ.
Его уже не поддерживают, т.к. Hadoop начал поддерживать взаимодействия с другими языками и смысл пилить Dryad пропал, ибо малая популярность.
Так что проблемы сделать аналог нет.
Да и вообще, что именно в .net не позволяет завязываться на кластер?
П.С. промахнулся с веткой
dimaaan
Вообще, если подумать, c# как раз таки больше подходит для систем обработки данных из-за более тонкого управления памятью (value type, указатели, ref return)
sshikov
Честно говоря, я так и не понял, есть ли тут аналог HDFS, и используется ли data locality. Т.е. распределяется ли код по кластеру, и каким именно способом.
xhumanoid
было, помимо локалити было много здравых идей там.
вот только dryad был на уровне beta и даже пару универов смогли «скачать-поиграться». потом его закрыли со словами «кастомеры как-то не горят желанием еще одной системы поэтому будем делать коннектор к хадупу».
из хороших идей там там был нормальный стриминг промежуточных результатов на следующий этап конвеерной обработки, в случае если этап находится на этой же физ ноде стриминг выполнялся по name pipe (а не через сетевой сокет), там же были зачатки RDD (spark их потом развил в уже законченное решение). в общем полезных и интересных вещей было очень много, если бы их действительно развили до промышленного состояния, то вполне возможно у нас сейчас была бы еще одна распределенная система обработки данных.
но ms слили свой шанс и сейчас вокруг jvm и c++ в этих областях и .net там бедный родственник
Paskin
Я не знаю насчет специфики корпоративного ПО — но работая над довольно большим проектом (50 разработчиков в 3х странах, не считая сторонних модулей) проблемами видятся:
mayorovp
Что такое в вашем понимании "слабая поддержка Dependency Injection"? Чего именно вам не хватает или не хватало?
И каким образом затрудняется интеграция из-за сильных связей между компонентами? Вы пробовали эти связи делать слабыми? :-)
Paskin
Не хватает — 1. field injection 2. простого способа оборачивания методов в транзакции, логи и что еще понадобится.
Связи не между компонентами, а между компонентами и ОС. В Яве достаточно остановить апп-сервер и можно деплоить новую версию — в .Net (на Windows) надо останавливать IIS, WAS, собственные сервисы — и только тогда можно быть уверенным что ваши тесты бегут с нужной версией ассембли.
mayorovp
Property Injection работает так же как и field injection, не вижу проблем написать
{get;set;}чтобы превратить field в property.Чем вам
using (var ts = new TransactionScope())— не простой способ?Paskin
1. Property Injection — это некий костыль. Надо менять документацию на интерфейс, раскрывает детали имплементации и т.п.
2. Тем, что это засоряет код и для уже скомпилированной сборки не меняется.
3. Я в GAC ничего и не добавлял (это вообще требует прав администратора для инсталляции — что убивает возможность самоапгрейда).
mayorovp
Вы так пишите как будто field injection — не костыль...
Менять скомпилированные сборки — нехорошо. Но если очень хочется — есть же Mono.Cecil
Paskin
1. Костыль — но гораздо меньший
2. Вы не поняли. Есть скомпилированный класс с методом DoSomething — разработчик которого о транзакциях, логах и прочем мог вообще не знать. В Джаве (Спринге например) я могу написать внешний файл аннотаций и включать/выключать все вышеописанное как мне хочется, не затрагивая оригинальной функциональности.
3. Это в теории. На практике — если у вас больше одного сервиса, начинается веселуха, особенно с инфраструктурными компонентами. Но не исключено что какие-то гуру DevOps действительно смогли бы это починить.
mayorovp
Вы хотите сказать, что когда перед использованием объекта надо установить ему некоторое поле — это нормально, не нуждается в документировании и не раскрывает деталей реализации?..
Необходимости использования транзакций зависит от алгоритма, а не от желания левой пятки. Поэтому не вижу пользы от внешнего файла аннотаций, который управляет транзакциями.
По поводу же логов — повторюсь:
А что вы делаете в Java, когда у вас более одного сервиса? И почему вы не смогли сделать то же самое на .NET?
Paskin
У обьекта не все поля равнозначны. Есть поля, относящиеся к бизнес-логике и есть поля инфраструктурные — логгер, конфигурация, подключение к БД и другие сервисы, по определению внешние и гарантированно существующие (имплементированные сервером аппликаций). Чем меньше обьект занимается связыванием и инициализацией последних — тем чище и проще его код.
Необходимость использования транзакций может меняться чуть ли не каждый спринт. Поэтому от внешнего файла аннотаций есть прямая польза. А при отладке больших систем, особенно профилировании — это вообще незаменимо. Замена реальной имплементации моком, включение/выключение логов и т.п. делается без единого изменения в самом коде.
В Джаве я делаю рестарт серверу апликаций. В .Net (точнее в Виндоус) граница между AS и OS довольно размыта.
mayorovp
И что же меняется при замене полей на свойства?
Алгоритм, использующий транзакции и алгоритм, их не использующий — это два разных алгоритма. Если вы можете один из них превратить в другой простым обертыванием в транзакцию — значит либо первый неоптимальный, либо второй некорректный.
А в .NET даже это делать не обязательно, достаточно папку bin заменить. Правильно настроенный IIS заметит это и перезапустит веб-приложение.
Paskin
… а если одна из сборок была загружена еще куда-то кроме IIS — вы откроете для себя чудный мир DLL shadowing, когда на диске одно — а исполняется другое ;)
mayorovp
И куда же могла быть загружена сборка, которая лежит в папке bin сайта IIS? Не надо грузить что попало куда попало, вот и все.
Razaz
1. DI в филды вообще ахтунг. Причем ноги у этого ахтунга растут из Спринга. Тот же Guice уже пропагандирует нормальный constructor injection.
2. DynamicProxy — оборачивайте что хотите. Только за транзакции прикрученные непонятно к чему на code review будет много вопросов.
3. Это у вас кривой devops. Это надо очень постараться, что бы устроить конфликты библиотек между изолированными приложениями на IIS. На Core и IIS не нужен. HAProxy/Nginx/Apache + Kestrel.
Проблема .Net проектов, что есть большой пласт разработчиков, которые считают, что освоив инструментарий один раз( зачастую лишь очень поверхностно) больше ничего учить не надо. Только вот инструментарий развивается и меняется.
Paskin
1. Ахтунг — понятие религиозное. У вас может быть с десяток инфраструктурных сервисов — замучаетесь их все в конструкторе перечислять. А любое изменение в «популярном» классе повлечет ребилд приличной части проекта.
2. DynamicProxy — неплохой костыль, но лучше когда такое сразу встроено в язык.
3. Приложения — они не только на IIS бывают, Web/REST/WCF — это часто только фронтенд.
mayorovp
То есть вы сравниваете Java-приложение, запущенное на сервере приложений, с .NET-приложением, запущенным абы где — и приходите к выводу что в .NET сложно администрировать приложения?..
Все с вами ясно...
Lailore
Насчет первого. Откройте для себя мир декораторов и перехватчиков
MonkAlex
Таки со сборками вроде есть простое решение — appdomain. В том плане что, выгрузил домен, загрузил домен — и вот ты уже со свежими сборками.
RomanPokrovskij
wcf нет на core и видимо не будет.
Микрософт ставит на то что в его стеке и EAI и SOA будут заабстрагированы микросервисами.
mayorovp
Насколько я знаю, серверный WCF на Core в будущем портировать Microsoft все же собирается. А клиентский со многими фичами там уже есть.
ennui
Как минимум это
TheKnight
Прочитайте пожалуйста внимательней. Про проект Rider я упоминал. GUI в нем написан не на .NET, это довольно таки важная проблема.
Это если забыть про EAP статус Rider…
mezastel
А какая разница, на .NET или не на .NET если оно летает в 10 раз быстрее чем студия? Вам, в конечном счете, шашечки или ехать?
TheKnight
Мне в конечном счете нужно уметь писать GUI на .NET кроссплатформенные. Наличие кроссплатформенной IDE на .NET как по мне является прекрасным доказательством того, что данную платформу можно для этого использовать.
Sing1e
Есть многообещающий проект Avalonia, который ещё пока находится в разработке. Кросплатформенный, даже на мобильных устройствах. Очень похож на WPF, но с некоторыми улучшениями. Можно использовать псевдоклассы, как в CSS и указывать размеры колонок и строк в гриде вот так ColumnDefinitions=«24,Auto,24». Может через год-два дойдут до версии 1.0.
kekekeks
Для штуки типа коммерческой IDE проект ещё не готов. Нет таких банальных вещей как API информации о шрифтах, да и вообще в целом куча шероховатостей. Плюс из-за проблем с разработкой не-на-windows (кроме райдера нормальных IDE просто нет, а райдер не умеет в отладку, да и плагин с автокомплитом и preview xaml под него соорудим не скоро, ибо кроме меня этим заниматься некому) вылезают платформозависимые косяки. В итоге когда начинают портировать штуки типа AvalonEdit, вылезают косяки типа этого:
mezastel
В этом конечно спору нет, я сам бы не отказался. Но согласитесь, у Java в плане GUI тоже все не супер. Сейчас многие приходят к тому, что GUI проще написать на веб-страничке, а потом засунуть в программу вебконтрол. Сам инсталлятор студии например — это же NodeJS с веб мордочкой. Я не говорю что это хорошо, но если нужно x-plat GUI «здесь и сейчас», я бы советовал делать на вебе.
DistortNeo
Это проблема не Java, это проблема отсутствия единых стандартов по рисованию GUI на разных платформах.
petuhov_k
Маленькая поправочка: «быстрее чем студия с решарпером». Попробуйте его отключить и тогда вы узнаете, что такое скорость. Никаких тормозов при наборе, ненужных дополнений кода, которые приходится удалять. И студия, оказывается, сама по себе не вешается насмерть при переключении между бранчами в hg.
А вообще это хорошо, что появился Rider и развивается всё активнее Xamarin — остаётся надежда, что под .net таки появится идеальная среда разработки.
kekekeks
Попробуйте в 2017-ой студии открыть солюшн с десятком NETStandard/NETCore-проектов, которые друг на друга ссылаются и при этом тянут кучу разного хлама с нугета. Узнаете, что такое отсутствие скорости.
petuhov_k
Неужели у Rider-а с этим лучше? Не знаю как там с Core — не балуюсь, а тормоза нюгета — это отдельная песня.
kekekeks
В 2017-ой многие вещи замедлились, из-за этого дополнительно лезут проблемы у расширений. Например, обход дерева зависимостей через [Reference::SourceProject](https://msdn.microsoft.com/en-us/library/aa984592(v=vs.71).aspx), на достаточно большом солюшне теперь занимает секунды против миллисекунд на 2015-ой, позавчера полдня убил на переписывание отслеживалки этого дела.
ChymeNik
Работает без тормозов.
kekekeks
ЛПП. Ну или у вас 3.5 проекта, вы не пытаетесь ничего подключать через нугет, не пытаетесь пользоваться билдом с несколькими целевыми фреймворками итп. Любые изменения в составе солюшна, если он достаточно большой, приводят к подвисаниям на десятки секунд. Это при выключенном решарпере. Райдер на том же самом солюшне себе такого не позволяет.
sasha1024
Я никогда не пользовался resharper'ом.
Но студия довольно таки тупит.
По крайней мере, внутри виртуалки.
vba
Кстати позвольте заметить что студия тоже не на .net вовсе, вот и сидим в 2017 году с х32 битным процессом и кучей лагов.
TheKnight
Эм. Мне почему то казалось что гуй там на .NET точно. Ну если я ошибся — так это еще один повод не считать .NET универсальной платформой пригодной для большинства серверных и десктопных задач.
ElectroGuard
Когда MS начнет писать свой софт на .NET'е — тогда можно о чем-то говорить.
vba
Я помню когда MS выпустила первую версию .NET, они во всю начали
трендеть про Новые Васюкизаявлять что де в ближайшем будущем все у них будет на .NET, не исключая даже операционной системы. Вот все так и ждем до сих пор.yorick_kiev_ua
Ну так я вам скажу, что вы давно уже дождались.
В Вижуал Студии GUI — WPF, в Expression Blend — тоже. MSN, Bing и прочие cервисы — .net
Даже Singularity три года назад допилили. Чего еще ждать-то?
vba
MSSQL например, или всю студию полностью…
IvaYan
Должен ли в таком случае Oracle переписать свою БД на Java?
vba
Не припомню что бы Оракл подобные заявления делал. В Оракле можно хранимые процедуры на Java писать?
GlukKazan
Да
sshikov
Да. И давно. И не только их. Там внутри полноценная JVM, с очередями сообщений, например, и всем остальным.
ElectroGuard
Мог бы, только врятли сделает. Видел про Кассандру писали, что медленная из-за того, что на жаве.
ad1Dima
Вы хотите БД на дотнете? Хм, бывают задачи которые не стоит решат в managed языке…
Razaz
RavenDB, DensoDB ,STSdb, Trinity Api, BrighstarDB, VelocityDB, HSS Database, NDatabase, DaggerDB. Не дофига, но что-то есть.
Что вас смущает в managed?
ad1Dima
Мне кажется, что СУБД — штука очень критичная для всех машинных ресурсов в силу фундаментальности. Любые тормоза и жор всплывут в приложении. Собственно только по этому я считаю это не лучшей идеей.
Razaz
Ну на .Net можно очень тонко работать с памятью сейчас. Это и ref returns, Channels, Pipelines, Spans, явная работа с памятью(stackalloc, Marshal.AllocHGlobal).
Это валидный C# код:
Подробнее тут. Вот еще неплохой овервью.
pnovikov
Чегойто «сейчас»? Всегда можно было. Плюс сложные и критичные к быстродействию куски можно писать на C++ и интеропиться с этим кодом из .NET
mayorovp
Пожалуйста, прочитайте ветку комментариев сначала. Кажется, вы забыли о чем тут шел спор.
Razaz
И когда всегда можно было ref returns, spans, channels с селектом и zero copy буферами?
Что-то вы могли сделать пометив пол проекта как unsafe, но сейчас можно
Ничего не замечаете в этом примере? ;) Вы хоть ознакомьтесь с теми ссылками :)
vba
Нет ядро студии точно на Cи, плагины, обертки и всякая прочая окружная мишура на .NET и вроде бы еще на Cи можно что то делать (тут не уверен, раньше точно была такая возможность, раньше были кучи оберток над COM+ типа VSTO, короче черт ногу сломит).
ad1Dima
Там хитро. Там гуй вроде как на XAML, так же как с Пейнтом в 7ке, Но при этом они на C++ (CX??).
pnovikov
Visual Studio и ReSharper вполне себе дают жару.
DistortNeo
Вы точно причинно-следственные связи не попутали?
Rider был создан как кросс-платформенная альтернатива связке VS + ReSharper. Ну и ещё потому, что решарперу тесно в 32-битном адресном пространстве студии.
pnovikov
Ваши слова не опровергают моих.
Я к тому, что есть JetBrains, который в состоянии снабдить нас нормальной IDE для C#. Есть MonoDevelop, как вариант «на крайний случай» есть VS + R#. Так что нормального окружения для работы с C#-кодом полно и на моей памяти VS+R# самая удобная связка.
kekekeks
Ну вообще MonoDevelop (aka Xamrin Studio aka Visual Studio for Mac) — вполне себе кроссплатформенная IDE, написанная целиком .NET. По уровню до фич решарпера, конечно, не дотягивает, но рослином пользоваться в состоянии.
ad1Dima
Ну, она не совсем на .NET, она на моно. Но вроде переезжает на .Net Core потихоньку.
kekekeks
Эм. Вообще говоря на Windows работает поверх обычного .NET. На .NET Core переехать не может по причине того, что под него нет GTK#. Ну и на макоси они, вроде, что-то используют от Xamarin.Mac, а тот требует патченого моновского рантайма для работы.
alaudo
А мы, энтерпрайзные .Net-чики, уже годы ждём компилятор Java написанный на Java, и «тогда можно будет говорить о переходе» :)
Да, еще бы и работу с коллекциями сделать более понятной, потому что после LINQ работать что с java.util.collections, что с Guava — это ж просто застрелиться…
TheKnight
Ээээ… Я чего то не знаю про javac? Он вроде как написан на Java. Навскидку в исходниках я не нашел упоминаний про другие языки.
cypok
А вот мне все-таки и правда интересно, что значит «компилятор Java написанный на Java»? Вы имеете ввиду компилятор в байткод, виртуальную машину или JIT/AOT-компилятор?
dimaaan
Думаю речь одет о компиляторе в байт-код
ad1Dima
Бывший Mono Develop сейчас переезжает на .NET Core под видом Visual Studio for Mac.
vba
Пытался его поставить на мак, так он не захотел ставиться без android sdk и xcode, "what a hell", подумал я и не стал его устанавливать.
ad1Dima
Наследственность от Xamarin Studio. Но без чего-то одного точно можно поставить (по крайней мере, я без андроида ставил)
vba
Помнится мне monodevelop можно было без всего этого ставить
kekekeks
Откуда информация про переезд? GtkSharp работает сейчас только поверх Mono (технически можно портировать), а Xamarin.Mac гвоздями приколочен к патчам в моновском рантайме для поддержки интеграции с ObjC.
ad1Dima
Вот сейчас я точно это не найду. На каком-то из кейноутов говорилось про движение в этом направлении и желании влить в .net core наработки из mono.
Т.е. это не конкретный роудмап, а вектор развития.
mrsantak
Какая связь между десктопным приложениями и enterprise?
VolCh
Толстые клиенты вестимо.
mrsantak
Ну это довольна маленькая часть enterprise и его доля всё уменьшается. Все-таки enterprise это больше про серверную логику.
TheKnight
Маленькая, большая… Я хочу
одно кольцо что б править всемиодин универсальный язык для десктопной разработки и серверной. Питон — подходит. Java — подходит. А вот C# — нет. И это плохо. Конкуренция помогает становится лучше.mrsantak
Ну мы тут обсуждаем enterprise в целом, а не вас конкретно. То что вы хотите несколько ортогонально потребностям кровавого enterprise.
Я так-то тоже хочу язык на котором можно писать и серверную часть, и RIA, и десктопные приложения. Но я такого языка не наблюдаю. Это же не повод говорить, что все языки не подходят для enterprise.
vedenin1980
На Java можно и и серверную часть, и RIA, и десктопные приложения и мобильные приложения под все основные платформы (RIA на чистом Java это Gwt, десктоп — Swing, SWT, мобильные — под андроид натив, под Apple тоже есть возможность писать). Что-то лучше, что-то сложнее, но потенциально можно все. Только не надо разводить холивар на тему разве GWT лучше ангуляра или что за приложения получаются на Swing/SWT, та же Idea это десктопное приложение, на GWT написано много RIA энтерпрайза (сам писал), есть свои проблемы, но у кого их нет?
Наоборот тоже бывает (сам видел). Это не только зависит от языка/технологии. Десктоп на java вполне встречается (из известных те же IDE от JetBrains), хотя в ней акцент больше на веб приложения
staticlab
Из широко применяемого в энтерпрайзе — Lotus Notes.
mrsantak
Потенциально можно и на brainfuck'е всё это делать :)
Писать RIA на чистой java — это боль. Да, возможно, но будет на порядки сложнее чем если делать это на js. Десктопные приложения на java писать проще и лучше чем RIA, но все равно проблемы есть.
Я имел ввиду, что хочу язык на котором все вышеперечисленное действительно удобно писать, а не просто возможно. Но я понимаю, что через чур много хочу :)
Razaz
В 2017 году GWT? :) Вроде бы живем в эпоху победившего HTML5 + JS(React/Angular) :D
pnovikov
Кстати связка C# на бэке + Java/ObjC (нативные мобильные клиенты) так же весьма популярна — инфрастркуткра Azure дает о себе знать
pnovikov
Прошу прощения, о благородные доны, но я вот как-то все перечисленные задачи до этого момента благополучно решал с помощью C# (ну за исключением клиентского web-а, хотя и тут есть варианты) и впервые слышу что кто-то испытывает сложности подобного характера.
(вероятно это потому что я плотно сижу на windows-инфраструктуре)
Neftedollar
Нf F# все можно. Нет парвда. Fable для RIA, для всего остального FSC.
yorick_kiev_ua
Ява подходит настолько плохо, что в некоторых «интерпрайзах»(например ДойчеБанке) сервера на java, а клиенты — .net
Язык с динамической типизацией в enterprise? Это шутка, правда?
TheKnight
Selectel.
sshikov
А еще у дойче были клиенты на Flex, и что?
И кстати про питон — это нифига не шутка. Более того, его становится все больше.
Shrike
Это не имеет никакого значения с точки зрения зрелости платформы.
Это как вопрос:
— назовите серьезное Java-приложение с пользовательским интефейсом?
— IDEA.
И? Кто-то пишет клиентские приложения с UI на Java? Ну нет, не пишет.
Не стоит путать тулы и end-user приложения.
Кросс-платформенного UI в .NET Core сейчас нет. Так же как и во многих других платформах. Это ничего не говорит о зрелости.
Нужен кросс-платформенный UI — Electron. Даже инсталлятор VS на нем :) (ну или на чем-то аналоичном, не смотрел внутрь).
TheKnight
Vuze, TuxGuitar. Хватит для пруфа?
webmasterx
Вы забыли о Qt.
Shrike
да, и Qt )
phillennium
По моим ощущениям, все радикальные новшества вроде Core и Jigsaw требуют «конопашиться» годы, и если в случае с Core уже прошло больше года и теперь всё наконец становится осмысленненее, то в Java летом с выходом Jigsaw долгое конопашенье только начнётся :)
ggrnd0
Ничего страшного.
В любом случае у .Net нет полного аналога Jigsaw.
alaudo
А в чем сила Jigsaw? Я прочитал немного, но там только про модульность. Тот же принцип, что и в .Net Standard, но я не знаю деталей (ни того, ни другого).
ggrnd0
Это более гибкие возможности контроля доступа к классам чем InternalsVisibleToAttribute.
А сама модульность платформы вообще ни при чем, просто небольшой рефакторинг, и там и там...
ad1Dima
vba
Jigsaw это не только разбиение монолитного JDK на кусочки как с .net core где System.Web всех просто достал. Это тотальная
электрификация батенькамодуляризация с такими понятиями как объявление и выгрузка модулей, это своего рода эволюция по пути node.js(но только в плане модулей!).Lailore
Эм. Как бы .net тоже самое, вплоть то до того, что рантайм это зависимость в nuget
vba
В .net все "пакуется" в dll, в java в jar/war/ear потом это все может распространятся через nuget/maven. Так вот jigsaw привносит так же понятие модулей, вот что можно вкратце почерпнуть из указанного выше источника
Тоже самое но в меньшей степени касается .net, там вероятность dll ада меньше из за "сильных" имен сборок.
В .NET core никаких понятий модуля нет, просто монолитный .NET порезан и разливается через nuget.
Razaz
Вообще все проекты могут быть собраны в nuget пакет, который так же объявляет свои зависимости(причем не либами, а пакетами). Единственное отличие, которое я пока увидел — exports. Но зачем, если есть модификаторы видимости..?
Не помню, оставили ли они или нет, но .Net Core можно было просто исходниками в пакете гонять, и компилировать рослином по необходимости.
vba
Зависимости в случае maven/nuget указываются на уровне упаковки(package).
Razaz
PackageReference Include="System.ComponentModel" Version="4.3.0"
Прям в csproj файле.
Не понимаю прикола в языке с модификаторами видимости пытаться копировать js…
vba
Нет в csproj файле насколько я помню вы указываете локальные зависимости а вот nuget зависимости идут отдельно в отдельном файле на уровне проекта вроде в
packages.config. Когда в вы устанавливаете что то, то нугет вам это бережно пихает в csproj.Я не сказал что они пытаются копировать js, я говорил про схожий путь.
Razaz
Уже неправильно помните. Дополнения к формату CSPROJ для .NET Core. Оно кстати и для не Core проектов в 17 студии работает вроде.
vba
Я не могу помнить чего не ведаю :), я говорил о среде до .net core, с чем приходилось работать. С .net core я прекратил все общение когда они забросили project.json ибо не вижу смысла тратить время на то что возможно не доживет до релиза.
Razaz
Ну собственно это и есть замена project.json. Только ее можно включать в билд процессы нормально, импортировать таргеты и пропсы. На большом проекте это просто счастье.
Ну сам Core уже до второго релиза почти дожил :)
pnovikov
Простите, а вы действительно считаете project.json хорошим решением?
Szer
Всё ещё можно. Просто пропишите файл как content и он nuget pack'ом будет доставляться при установке.
Razaz
А можно поподробнее про node и jigsaw? Не совсем понимаю просто про объявление модуля.
vba
Вот пожалуйста, там файлы
module-infoописывают что должен экспортировать модуль плюс его зависимости итд.staticlab
А в описании требуемых модулей версионирование предусмотрено?
vba
Пока не знаю но каждый модуль имеет свою версию. Что бы точно ответить на ваш вопрос нужно покопаться в спецификации.
guai
Вот как раз выгрузки-загрузки модулей там нет, говорят, пользуйтесь OSGI, но OSGI не распилит нам ядро. И версионирования этих модулей по-моему в итоге тож не сделали.
ggrnd0
пользуйтесь OSGi © КО
guai
Дык пользуемся. С допотопных времен еще. Только jigsaw и OSGI — это совсем не одно и то же. А там вон выше попытались приписать jigsaw свойства, которыми он не обладает.
vba
Если не ошибаюсь то Jigsaw был начат под другим названием еще под Sun(между java 6 и 7), так что ему не пол года от роду. А вот по .net core, там не столько кропотливый труд сколько терзания сомнениями и ошибки на стадии дизайна, отсюда и фокусы типа был poroject.json и нет его, прыг скок обратно на msbuild. До осмысленного конца там еще боюсь далеко, и может не дойти до него вовсе, а выпилят какой нибудь сурагат.
phillennium
Вы правы, над Jigsaw дольше работают (хотя .NET Core анонсирован в 2014-м, тоже не сказать чтобы вчера). Но по внешним признакам мне кажется, что там всё равно с релизом начнётся веселье, и переход к модулям будет долгим и болезненным.
Shrike
Ну всё таки project.json это не «ошибки дизайна платформы». Это желание новых людей сделать модно «как у них» сейчас и здесь. В смысле как Node/npm. Это понятно. Но нужна обратная совместимость и преемственность. Откатили. Конечно, лучше бы сразу сделали всё правильно. Но тогда, возможно, вообще бы всего этого не было. Потому как есть ощущение, что просто команда asp.net тихой сапой решила сделать новый .net для себя сначала. А потом убедила всех, что это реально и надо развивать. Это чисто моё ощущение.
pnovikov
Вот! Вот от таких мыслей при проектировании хорошие системы и загибаются. «Как у них» — не значит «хорошо». project.json для сборки .NET-проектов очевидно не подходит, ибо как вылазит проблема совместимости со старыми системами, завязанными на специфические особенности msbuild-а, как верно команда .NET Core заметила в своем блоге.
У меня просто солидный опыт работы с MSBuild и это реально очень удобная система сборки чем-то похожая на ant. project.json сильно уступает ей в функциональности. project.json отлично работает на маленьких и простых проектах и превращается в сущий ад на попытке собрать большой проект (я собирал свой фреймворк с помощью project.json — прошелся по такому количеству граблей, что страшно становится)
Dywar
Большие компании используют open source, и .net core скоро заинтересует их, как и другие языки в свое время.
senpay
Я думаю, что тут выдается желаемое за действительное. Мне кажется, что .Net Core был скорее вопросом выживания платформы, а не ее доминирования. Как можно прочесть между строк в самой статье — не кросс платформенные решения уже практически не жизнеспособны.
С другой стороны, странно было бы слышать от идеологов и сторонников технологии «надеюсь теперь не сдохнем» — это вряд ли привлечет новых сторонников :)
Хотя в любом случае, я сторонник здоровой конкуренции — если .Net Core будет объективно лучше Java — выиграют все.
bluetooth
Есть ли данное интервью на английском языке?
ARG89
Есть, пока нигде не опубликовано. Надо?
Miraage
Как я понял, это перевод. Хочется видеть ссылку на оригинал.
ARG89
Считайте, что это оригинал. Интервью брал я, переводил итогово я, этот текст в интернете выложен впервые.
Английскую версию надо тоже редактировать и куда верстать. Когда выложу, в этой ветке отпишусь.
bonzaster
Да, хочется поделиться с коллегами из UK
ARG89
Напишу вам, когда будет готово.
Wingtiger
одна реклама. «Используйте это, потому что ваше старое с багами. Используйте это, а это тоже устарело» и ни одного примера чем же лучше и какие баги.
Пытался понять что за NET Core, вроде как мне не надо. «Главное убедитесь, что не используете WPF и WinForms, и всё будет хорошо». А как там рисовать формы для десктопов (вин и линь)? Или это чисто веб? Также весело насчёт веба — из бесплатного и/или доступного только пхп и больше ничего.
Virviil
Сделать интерфейс энтерпрайз приложения в виде rich web application с учётом всяких websockets и single page application frameworks это довольно хорошая идея в 2017 году. Excel может запуститься в браузере, а опердень нет?
И поясните пожалуйста по поводу php — так то это самый незахайпленный сегодня язык из бесплатных и доступных.
kekekeks
Проблема в прожорливости таких решений. Наш каталог контролов после прокликивания всех вкладок кушает 42 мегабайта в private working set. И это на альфа-версии фреймворка, который никто особо не оптимизировал. Открываем в качестве единственной вкладки в хроме "хэлловорлд" на ангуларе (если кто возьмётся склепать аналог приложения для нормального сравнения — велкам), то спавнится в сумме 5 процессов, отъедающих больше сотни мегабайт в сумме.
И если при большом числе вкладок хром внутри себя ещё как-то нормально управляет ресурсами, то когда люди начинают делать "десктопные приложения", по факту перепаковывая сайт с браузерным движком, становится очень грустно.
pnovikov
Ну так-то есть CEF, позволяющий невозбранно клепать UI-часть на web-стеке. Правда что у них там с .NET Core пока неясно.
ad1Dima
Веб и консоль, пока.
dmitry_dvm
Что-то недопонял. Если donetcore — это не про десктоп и не про asp.net core, то про что же?
alek_sys
Как перебежчик из .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 к тому времени!
ElectroGuard
Ничего нового, MS всегда так делала:
огонь и движение
23derevo
тоже сразу вспомнил эту статью :)
ad1Dima
Я не вебер, сложно судить всесторонне, но те фичи, что выведены главными на сайте фреймворка в .net присутствуют.
NUnit — портированный JUnit. И он не единственный фреймворк.
https://www.visualstudio.com/ru/vso/
Azure
Если я все правильно понял, то тоже Azure (+ Docker??)
.Net Core, Xamarin
docs.microsoft.com (он же: https://github.com/MicrosoftDocs), stackoverflow.com
мм?
Так бывает с бетаверсиями продуктов, более того это нормально, о чем и упоминается в интервью. У отдельных компаний стабильные версии языка каждый год ломают существующий код…
VolCh
Разве его можно установить у себя?
ad1Dima
Вроде, нет. но Windows server и TFS позволяют делать все то же, кроме метрики (или я не нашел как хоcтить у себя Application Insights) Вероятно ahriman может меня поправить.
ahriman
ApeCoder совершенно верно указал на Azure Stack.
Вопрос в том, что имеется в виду под всем этим делом — если IaaS, то ОК, это есть. Если PaaS или фичи типа AppInsights, то не только процесс адаптации любого PaaS-а под вариант поставки on-premise, но и наличие у потенциальных клиентов ресурсов под то, чтобы это работало хорошо, а не в режиме «один сервер — пять ролей» или маленького кластера сложны для однозначного ответа. Хотя планы есть.
nikolayv81
Разве windows server бесплатен?
ApeCoder
Azure Stack в стадии Technical Preview
crea7or
Кстати, как раз сейчас можно получить $15 в месяц на год в azure и всё попробовать самому. Мне хостинг виртуалки с несколькими тысячами посетителей в день стоит 100р. в меся, например.
alek_sys
Все так, но, как говорится, «есть один нюанс» (С)
Сразу дисклеймер — я не пытаюсь говорить что .NET лучше или хуже JVM как платформа, я описываю лишь свои личные ощущения от миграции на другую платформу после многих лет на .NET. Так вот, мое впечатление — в современном (это важно) стеке разработки на JVM решены проблемы о которых я даже не думал в .NET и это сильно помогает в ежедневной разработке.
Например, тестирование — NUnit, конечно есть. Но если взять тот же Spring (я скоро стану адвокатом Spring!) — то там Mockito, Spring и JUnit не просто есть, а образуют органичную систему. Например, чтобы взять полностью Spring-приложение, запустить его как есть на случайном порту и остановить после теста, но замокать взаимодействие с внешним сервисом нужно сделать просто:
А потом это легко подхватит любой CI/CD, эти тесты понимает IDEA, по этим тестам можно считать покрытие и т.п… Это не набор разрозненных инструментов — это экосистема. И мне не передать как это важно. И здесь сочетание всего — и моков, и тестового фреймворка, и DI, и рантайма который можно легко запустить — да много всего. Могу ли я это написать сам? Конечно могу, да и любой более-менее профессиональный программист сможет. Но зачем? А это только один пример — тесты, и в целом частный случай. Но так во многом — эти утилиты полировались и использовались годами, чтобы получить такую синергию. И вот именно это и нужно .NET — органичную экосистему. Чтобы разработчик мог не думать как решать типовые задачи — разработки, деплоймента, тестирования. И Майкрософт делает отличную работу, чтобы эти инструменты дать — но просто нужно время на все на это. Время и отсутствие потрясений в платформе.
Razaz
xUnit. Все органично, подхватывается, работает с любым CI. И можно покрытие считать и все что захотите. Вы уже высасываете проблемы из пальца, причем не имея представления о том, в каком состоянии сейчас .Net.
Есть и тестовые сервера, и с контейнерами делайте то, что вам вздумается.
alek_sys
Я охотно допускаю, что это просто мое невежество и в .NET такие вещи уже появились, тогда это очень здорово. Даже в ASP.NET 4 (5?) запустить приложение в рамках интеграционного теста было не самой тривиальной задачей, не говоря уже про доступ к внутреннему DI приложения. А на фразу «тестовый сервер» приходил в голову только IIS Express, который был в общем-то единственным вариантом и оставался внешней и чужеродной к приложению сущностью. Важно понимать, что это и правда тривиальный пример, таких примеров (опять же, только из личного опыта) я могу привести на каждую фазу работы над приложением. Но в целом, тренд отличный, и может Джон Скит и прав, Java скоро придется потесниться!
Razaz
Сейчас тестируется все и все. Для Owin уже были тестовые сервера(пример). DI в Core из коробки.
В Core все стало по человечески. IIS можно выкинуть и использовать весь спектр ништяков для деплоя :)
dimaaan
У меня, наоборот, был отрицательный опыт пару лет назад.
Казалось бы, есть простая задача: hello world на Spring+CXF с конфигурацией в коде.
Открываем мануал: http://cxf.apache.org/docs/writing-a-service-with-spring.html
Читаем, понимаем, что там конфиг в xml.
Внизу приписка: For more information on using Spring… первая ссылка — полотно XML, вторая ссылка вообще битая.
Мучаем поисковик. Нам говорят, что нужен spring boot.
Я понимаю, что у меня будет не типовой конфиг и spring boot мне не нужен.
Да и вообще, отдельная библиотека просто для того, чтобы запустить hello world?
Я так и не нашел способа сделать это.
Возможно сейчас все поменялось и мне, наконец, покажут пример, который бы поместился в небольшой комментарий.
та же задача, но с использованием .net core для сравнения:
alek_sys
Конечно, и в Spring, и в JVM мире есть куча своих проблем, у меня нет иллюзий что это серебряная пуля. И именно по части SOAP сервисов — все тяжело, да. Грустное наследие Java EE угнетает, здесь я не спорю. Но именно поэтому я отметил «современная JVM разработка» — и я под этим понимаю Spring Boot (никакого xml) и REST. Тогда все тоже тривиально.
dimaaan
Я знаю, просто, когда вы начали говорить об органичности у меня немного "подгорело".
dimaaan
Страшно даже подумать, во что надо вляпаться, что сделать Spring'овский hello world асинхронным...
alek_sys
Надо отдать должное команде Spring — начиная со Spring 5 реактивный web-framework доступен из коробки. И это интегрируется со Котлиновскими корутинами в том числе, так что (скоро) можно будет писать C#-style асинхронный код и на JVM тоже.
khim
При всей проработанности Java-мира очень многое в нём делается не так, как в других мирах.
Ни разу не простая, так как вы идёте наперекор всем канонам: хотите конфигурацию в коде (в коде, Карл!), и без создания всех этих WAR'ов.
Библиотеки, позволяющие делать в Java «конфигурацию в коде» существуют (практически я с Guice работал), но что там бывает на замену CXF — не скажу (у нас всё своё было). А Spring изначально предполагает что в коде конфигурации не будет и, соответственно, старается сделать так, чтобы её там не оказалось — странно после этого ожидать, что ваша задача, которая требует ровно противоположного, окажется «простой».
И не мечтайте. Вот узнать как это сделать тремя кликами мышки, которые породят 100500 файлов и несколько мегабайт кода — это ещё есть шанс. Увидеть пример, который «поместится в небольшой комментарий» — вряд ли.
alek_sys
Это поменялось. Я серьезно думаю написать статью, чтобы развенчать мифы о современном Spring (Boot). Там нет XML, и пример REST приложения вполне умещается в комментарий:
Все. Это не генерит никакой код — просто автоматически конфигурирует приложение. И это полностью self-contained приложение — ему не нужно application server-а, его можно просто запустить — т.к. JAR вполне себе executable. На Kotlin или Groovy это еще лаконичнее и проще.
pnovikov
Вставлю свои 5 коппеек: пока в Java нет деревьев выражений о нормальной «конфигурации в коде» можно даже не заикаться
pnovikov
Я что-то не понял, а все минусующие чтоли никогда не видели fluent-конфигурации в коде например у того же EF? Там же дерево на дереве сидит и деревом погоняет.
mayorovp
Это не единственный возможный подход. В том же EF можно настраивать все через DataAnnotations, которые деревьев не требуют.
А если не хватает возможностей стандартных аннотаций — можно добавить свои через конвенции. Которые тоже не требуют деревьев.
pnovikov
Да можно и свой edmx сдуру написать руками :) Вопрос в том, что удобнее. Аннотации неудобны, потому что размазывают конфигурацию по всему коду — и потом ищи свищи где ты там [Column] поставил. К тому же статической проверки типов там нет.
Fluent-конфигурация удобна тем, что её можно комбинировать через поведенческие примеси, что позволяет легко и непринужденно, например, выносить общую конфигурацию для каких-либо специфических и похожих сущностей в отдельный обобщенный метод. У нас в проекте например довольно много сущностей с полем Name (помимо Id). И все они у нас 128 байт в длину, типа nvarchar, не допускающие пустых строк. Все они конфигурируются через один и тот же метод конфигурации, что весьма удобно.
mayorovp
Такие вещи обычно удобно делаются через общего предка.
pnovikov
Я еще раз повторюсь — такие вещи можно сделать десятком разных способов — хоть через edmx с T4. Однако наша основная дискуссия была на тему того, что без деревьев выражений не бывает нормальной конфигурации в коде. EF использовался для иллюстрации этого утверждения. Видимо, не очень хороший пример, ладно. Надо было указать на Moq, automapper или любой другой фреймворк на fluent-конфигурации.
mayorovp
С каких пор прибитая гвоздями к языку CI/CD считается чем-то хорошим?
pnovikov
Задался тем же вопросом.
У моего основного клиента CI/CD это jenkins. Проект выкладывается на инфраструктуру Amazon из github-репозитория. Работает без запинки, из чего складывается крамольная мысль: если автор комментария не смог подобную связку настроить — это не значит что оной нет :)
Razaz
1. Rider?
2. ASP.NET MVC + куча расширений от самой же MS.
3. xUnit, NUnit, Storyteller, моков вообще налепили.
4. VSO, да и вообще на всем подряд можно собираться. В чем тут проблема? Берите Jenkins и вперед :)
5. CoreClr, ETW и куча всего.
6. DotNet Foundation.
7. Уже. Есть пара деплоевв прода на Debian.
8. https://docs.microsoft.com/ru-ru/dotnet/
Ну логично, что процесс открытой разработки порождает быстрое устаревание туториалов. Раньше вы бы просто этого не узнали, пока РТМ не вышел.
Не гонит, а медленно движется — народ с беты на проде внедряет и довольны. Если вы можете открыть исходники, найти проблему и решить — хоть альфой пользуйтесь.
ElectroGuard
Пока что, судя по статистике, дела у сишарпа так себе, даже не взирая на то, что MS открыл код:
C# Tiobe
vba
Да какая то прямо C# fatigue
ad1Dima
У Java тоже отрицательная динамика. Классно статистику из контекста вырывать, да?
ElectroGuard
У Делфи + Лазаруса положительная динамика. Тоже чем дальше — тем более кроссплатформенные.
ad1Dima
Ну да, делфи кроссплатформенный, у них даже GUI был кроссплатформенный
ElectroGuard
Да, сейчас в Делфи всё кроссплатформенное. Мы сами пишем несколько кросс-платформенных программ (Windows + Linux). Успешно.
petuhov_k
C# это ещё не весь .net. Вот вам положительная динамика.
pnovikov
*картинка_медведь_из_кустов_кричит_VB.NET.jpg*
Как имеющий опыт скажу, что указанная положительная динамика ни коим образом не мешает компаниям плеваться от VB.NET и отказываться от него в пользу C#. Основная проблема VB.NET — это просто дикое, неуправляемое приведение типов, громоздкий синтаксис для лямбда-выражений и сильно урезанная поддержка у ReSharper. Даже литеральные даты и пара полезных LINQ-словечек не спасает
crea7or
А вот последний параграф меня сильно удивил.
AndreyDmitriev
Если вы о фразе «аудитория, как правило, — белые мужчины, и это расстраивает меня. Нам нужно больше гендерного разнообразия, нам нужно больше расового разнообразия», то тут просто надо учесть место пребывания Джона и компанию, в которой он работает. Я сам работаю в очень большой корпорации и нахожусь территориально в центре Европы — тут в полный рост работает пропаганда всеобщего равенства и братства. Я ни в коем случае не говорю, что это плохо, просто об этом очень много говорят, и у Джона это засело в голове. Мне постоянно прилетают по корпоративной рассылке письма типа «мы организовали ЛГБТ сообщество внутри компании», или «доведём количество женщин на технических должностях до 50 процентов» и так далее. Самое смешное, что дискриминации я вообще никакой не вижу, ни по гендерному ни по расовому признаку. Однако работая на инженерной должности много лет, должен признать, что большинство инженеров (программистов и не только) — мужчины. И мне вот думается, что тут просто склад ума у женщин и мужчин несколько разный. Почему природа так устроила — это загадка. Ну или взять хотя бы программистов в Индии — там тоже своя специфика, причём чётко прослеживаемая.
Самое обидное, что мы на грани переворота с «ног на голову». Я о том, что если на одну и ту же должность претендуют мужчина и женщина, то единственным критерием выбора должны быть деловые качества, но мы уже на грани того, что женщина получит преимущество только потому, что в отделе недостаток «слабого пола». Я тоже за равенство, но наличие в зале аудитории в основном из белых мужчин вовсе не говорит о неравенстве. Опять же низвестно, где эта конференция проводилась — в Бангалоре логично увидеть полный зал индусов, а на конференции швей-мотористок в зале будут женщины.
ApeCoder
Феминистки считают, что причина в-основном в женской гендерной социализации — с детства им говорят, надевай розовое, будь слабой эмоциональной, интересуйся куклами, а не машинками и т.д.
AndreyDmitriev
Ну это феминистки так считают — сейчас, пожалуй, такого стереотипа уже нет. Более того, у нас (да и не только у нас) каждый год проходит «Girls Day», где девочкам устраивают экскурсию по фирме и предлагают пройти практику после школы (а подразделение сугубо инженерное). У меня самого растут две дочки, я сделал отчаянную попытку вырастить двух программистов, но дальше Scratch дело не пошло. Поставил им компьютер, но он большую часть времени выключен. С Лего играют, да, но Mindstorm NXT интерес вызвал только у папы. До .net дело явно не дойдёт — это уже сейчас видно.
pnovikov
Кстати в порядке троллинга можно вывернуть дело так, что Girls Day является гендерной дискриминацией — это вы типа вот так на уровне компании решили, что девушки глупее и поэтому им надо проводить специальные экскурсии, да? Вуаля и вы — шовинист. :)
Феминизм и меньшинства — очень, очень опасная тема :)
ApeCoder
Присмотритесь на все окружение, включая игрушки: Кто нарисован на конструкторах, кто на коробках с куклами и т.д. Т.е. ту фиг знает что причина, а что следствие, но гендерные стереотипы есть и окружают детей везде.
У знакомого мальчик, но даже до скретч дело не дошло.
PsyHaSTe
ApeCoder
Перечитайте сообщение на которое я отвечал — там не было статистики, а только личный пример :)
crea7or
Вот я примерно про тоже, будто есть примеры какой-то дискриминации.
ad1Dima
PsyHaSTe
Очень разочаровывает такое отношение, и вербовка "феминистов". Джон неглупый мужик, но видно, что он довольно наивный, и немного критического мышления и матстатистики ему бы не помешало, а то его ложными дихотомиями прям завалили настолько, что он во всем видит дискриминацию. Писсуары наверное тоже надо называть дискриминацией, ведь они уменьшают время, проводимое человеком в туалете в разы! Девочки играют в куклы только потому, что им об этом говорят родители, а на самом деле они все сплошь да рядом в солдатиков хотят да машинки погонять… Люди просто пытаются в упор не замечать разницы...
О, вот что еще придумал. 100% детей были рождены женщинами. По-моему, это дискриминация. Я требую, чтобы не менее 50% детей были рождены мужчинами.
ApeCoder
Из чего вы сделали такой вывод и какую матстатистику вы имеете ввиду? Джон ничего не говорил ни про писсуары ни про 50% — у него достаточно общие слова.
PsyHaSTe
Статистика такая, что если только 20% девочек после школы идут в технические вузы, из них еще 20% идут работать по специальности, а из них еще 20% идут до кандидатской и защищают её. Вопрос, стоит ли ожидать, что на конференции по условным "сферическим затополуполям" будет поровну мужчин и женщин?
Да что там говорить, stackoverflow проводил же опрос масштабный недавно, по разным срезам, в том числе и по половому признаку. Уж не думаете ли вы, что на форуме, где человек сидит под анонимной аватаркой с ничего не говорящим именем "абвырлг123" будет подвергаться дискриминацией по половому признаку? Да в большинстве случаев никто даже не знает, какого пола тот или иной человек, благо в английском произношение от первого лица никак не выдает пол говорящего. Однако статистика там такая, что как будто всех девушек застращали и не пустили.
Тут обычно идут аргументы, что это их общество так задавило, вот они и не заходят, все начинается в детстве и т.п. Да не вопрос, подойдите тогда к деткам 10 лет и проведите опрос, среди мальчиков и девочек, кому нравится в компе копаться, а кому — с куклами играть.
В итоге имеем смешную (сквозь слезы) ситуацию, когда типа "задавленность" взрослых объясняется детскими травмами (которых по сути никто не видел), а "задавленность" детей объясняется тем, что на них давят общественное мнение, а из кого оно состоит? Да из взрослых. В итоге имеем типичную веру без аргументов, в которой есть 2 тезиса, ссылающихся друг на друга, которые конечно же невозможно опровергнуть. "Почему Бог всегда прав? Потому что так написано в библии. А почему нужно верить тому, что написано в библии? А потому, что Бог всегда прав" Поэтому это чистая демагогия в чьих-то не очень чистоплотных целях. Спорить с этим бесполезно, нужно только сделать для себя выводы.
ApeCoder
С чего вы решили что он не знает эту статистику? Может именно это и его растраивает.
Кстати, Women considered better coders – but only if they hide their gender
Почему вы решили что общество не может формировать определенные стереотипы в возрасте до 10 лет?
PsyHaSTe
Что его расстраивает? Физиология? Или мы считаем, что мужская и женская психика ничем не различаюстя?
Такая статистика без нормального исследования не может считаться достоверной. Ну простой пример, у женщин как правило нет склонности к этим наукам, поэтому если она все же занимается этим, то это значит, что она сделала серьезный шаг и много над собой работало. В таком случае можно переформулировать как "программисты, которые над собой работают, добиваются большего успеха, чем средний кодер" — кто-то удивился?
Видео в тему:
ApeCoder
Если немного подумать, то в голову могут придти еще варианты кроме этих двух. Вы почему-то приписываете оппоненту радикальную точку зрения и пытаетесь с ней категорично спорить :).
Провел — они одинаково отвечают на вопрос "Агу" :)
PsyHaSTe
Ну как бы закон исключенного третьего говорит о том, что либо отличаются, либо нет. Так что да, другого варианта кроме этих двух — нет.
ApeCoder
Давайте подумаем вместе, какие могут быть еще вырианты?
Например чем-то различаются, но не в той мере чтобы обусловить такую сильную разницу в поведении :)
PsyHaSTe
Придираемся к формулировкам? Ок. "Мужская и женская психика недостаточно отличаются для того, чтобы объяснить такую сильную разницу в поведении" — да или нет?
ApeCoder
Да именно категоричная формулировка человека который знает как оно на самом деле побуждает меня дискутировать с вами :)
Нет.
"Совокупность душевных процессов и явлений (ощущения, восприятия, эмоции, память и т. п.); специфический аспект жизнедеятельности животных и человека в их взаимодействии с окружающей средой[1]." мне кажется тут нет ничего про то, врожденное это или воспитанное обществом.
Я бы сказал так, "Надо убедиться в том, насколько врожденные или приобретенные факторы влияют на разницу в поведении и по возможности предоставить разным людям побольше возможности выбирать чем заниматься, особенно из групп которые исторически дискриминировались"
PsyHaSTe
Есть мнение, что дискриминация есть, но она направлена как раз на белых мужчин.
Противно видеть бородатых женщин — и я уже нетолерантный гомофоб.
Нас с каждым днём становится всё меньше,
К тому же я не верю в гороскоп,
В богов и духов, в Атлантиду и приметы…
Мне кажется, хоть я и не статист,
Что самый угнетённый тип на свете:
Мужчина. Белый. Натурал. И атеист.
Местами не согласен, но где-то так и есть. Ситуация с Оскарами, например, или всевозможные квоты в западных правительствах: не важно, какие у тебя скиллы, если ты женского пола или нетрадиционной ориентации — велкам.
ApeCoder
Ок — лирический герой сопоставил нейтральный врожденный признак нейтральному врожденному признаку (это если так, не ипользовал слово ниггер)
Вы не видите принципиальной разницы между этим двустишием и предыдущим? Тут он приписал половине человечества отрицательно окрашенный признак, вернее приписал отрицательную окраску нейтральному признаку "повышенная эмоциональность". Например в этой ветке вы высказываетесь в категоричной эмоциональной манере, но я же не оцениваю это как вздор, а обсуждаю с вами по существу. Если заглянуть в словарь, то мне кажется термин "сексист" вполне подойдет.
Наверное что там ему внутри противно всем пофиг, мне вот тоже могут быть противны какие-то вещи (какая-нибудь безобразная рана или типа того). Другое дело что он выражает. Мы не знаем, но есл опять-таки посмотреть в словарь, вполне может быть, что если он не сдерживается перед выражением неприязни перед гомосеками он и нетолерантный и гомофоб.
Разумеется если пытаться скоменисировать перекосы то может перекосить в другую сторону. Это нормально — надо любить людей и стараться помочь тем кому трудно но не давать сесть на шею.
То есть совсем не важно? Даже собесеования не проводят? Сразу половину населения принимают в правительство?
Итого: феминистические убеждения автора не означают, что он не знаком со статистикой. Он просто может ее интерпретировать не так как вы.
Если вы хотите разобраться в теме, рекомендую взглянуть на нее со стороны женщин — почитать феминистические сайты, побеседовать с жещинами об их жизни, причем чтобы выслушать, а не навязать свою точку зрения — с искренним любопытством.
nikolayv81
Психика это продукт "обучения", а за основную часть обучения отвечают родители, у которых есть свои взгляды на жизнь.
Scf
Ага, потеснит Java на рынке. Через пару лет, в лучшем случае, .net core будет только готов к серьезному применению. Потом для него нужно написать софт и инфраструктуру, потом набрать опыт администрирования серверных приложений под эту платформу. А уже потом — "потеснит". Может быть.
Пока же .net core сильно отстает даже по быстродействию:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=csharpcore
Я думаю, что майкрософт пошел не туда — .net является лучшей платформой в мире для разработки оконных приложений. Если бы они портировали поддержку GUI на линукс и мак — это была бы бомба, даже если с платной лицензией.
ad1Dima
Lailore
под mac есть xamarin. А зачем GUI под линукс? Очень мало людей использует линукс как рабочую операционную систему, а не серверную
TheKnight
Нужен даже не гуй под линукс а кроссплатформенный гуй. Который можно было бы написать один раз с минимальными правками под разные ОС.
Lailore
Это надо смотреть в сторону web. Операционки похоже никогда не договорятся о GUI.
Simplevolk
а браузеры?)
Lailore
У веба есть хотя бы общие стандарты, а у операционное их нет.
kekekeks
А чего им договариваться. Их дело дать фреймбуфер, куда этот гуй рисовать. А то наплодили всяких гайдлайнов и изображают из себя невесть что. Почти как провайдеры, которые думают, что они не просто труба в интернет.
TheKnight
Как ни странно, есть примеры универсального языка, который позволяет писать GUI на разных платформах. Java, C++ в связке с QT, Python в связке с wxWidget, много их. А вот C# пока не умеет.
ad1Dima
С# в связке с XAML с помощью XF.
TheKnight
А примеры есть? Кроме MonoStudio с которой все как то не особо понятно.
ad1Dima
Примеры чего, приложений? Ну вон СКБ Контур запиливал приложение на XF делал
А так, не все анонсируют технологии, а отличить качественное XF приложение от полностью нативного невозможно.
ad1Dima
Ну, как бы Xamarin.Forms В данный момент поддерживает iOS, Android WinRT/Windows 10. Ожидается поддержка WPF и Win 7+ соответственно. В каком-то виде поддерживается Mac OS (сам не видел)
pnovikov
Прошу прощения что вмешиваюсь, но вот сугубо ИМХО — кроссплатформенный GUI (речь о десктопе) по моему опыту использования приложений с таковым (видел реализацию на Java) в результате означает что этот самый GUI, уж простите, одинаково отстойно выглядит на всех платформах.
Мораль сей басни обычно сводится к тому, что если хочешь сделать серьезный GUI в серьезном приложении — пиши отдельно на каждую платформу. Ну то есть примерно та же ситуация, что и с мобильными приложениями.
letchik
Я щас чуть чаем не поперхнулся.
kekekeks
Ну за пределы 1% на десктопах ведь так и не вылезли.
TheKnight
Ну дык и не много людей на компьютерах работают а не в игрушки играют :)
codemax
Здесь скорее имелось в виду в целом, во всех сферах, в том числе и не связанных с IT напрямую. Тогда выходит действительно мало линукса на рабочих десктопах.
nikolayv81
Поэтому и не используют(с gui проблемы), потому ms и не портирует, чтобы не терять рынок.
staticlab
Боюсь, что GUI они как раз-таки не перенесут, опасаясь конкуренции Linux в области десктопа.
Razaz
Он уже сейчас активно внедряется. Каукю инфраструктуру вы для него собрались писать? Контейнеры? :D
Запустите ради интереса этот бенч с CoreClr 1.1 собранным с PGO и ништяками C#7.
Для серверов весьма торт. А гуй нафиг. вон Электрон + Реакт и вперед.
mayorovp
Нельзя так просто взять и портировать гуи
(тут нужна картинка с Боромиром)
Сейчас в .NET есть два варианта создания GUI, и оба прибиты гвоздями к WinAPI. Портирование этого всего на линукс — само по себе нетривиальная задача, а тут надо еще и кроссплатформенно это сделать...
kekekeks
Вообще говоря в Mono есть худо-бедно работающая реализация Windows.Forms. Так что не то чтобы совсем гвоздями к WinAPI прибито.
mayorovp
Ну, в Mono приложили довольно много усилий чтобы этого добиться, аж три раза меняя реализацию (Gtk, интеграция с Wine и наконец полностью своя отрисовка).
ElectroGuard
Мы используем Delphi + Lazarus, рекомендую.
FMX и LCL отвязаны от WinAPI, на подходе crossvcl, тоже отвязанный от WinAPI.
Siemargl
Ядро норм, гуи норм, теперь будет и шелл норм.
Разрабатывай, если хочешь, все на месте, без миграций (на встроенной линух-подсистеме). Окончательный результат задеплоишь куда-угодно в облака.
C# Гуй перестали развивать, как минимум активно. Возможный таргет (я не вижу этому опровержений) -> сервер сайд днет + JS клиенты
ad1Dima
aristarh1970
Такие «откровения» от майкрософтовского деятеля — либо реклама очередной «судбоносной версии дот-нет», либо самореклама, либо начавшийся склероз.
С самого появления на свет Джавы — Майкрософт стремится заменить ее на рынке своими продуктами и чуть ли ни каждый свой релиз кричит что вот-вот, ну завтра, в крайнем случае послезавтра, максимум через год — новейшая и лучшая дот-нет-какая-то-там вытеснит отсталую Джаву с рынка серверных технологий!..
Но через год у Майкрософта появляется дот-нет еще новее, еще лучше и еще серверней прежней и все начинается сначала…
Майкрософт слишком подвержена шараханиям от технологии к технологии и стремлению намертво привязать пользователя к своим продуктам, чтобы серьезные компании сделали окончательный выбот в пользу ее серверных прдуктов.
Qbit
Джон Скит работает в Google; в работе на Майкрософт вроде замечен не был.
ggrnd0
Angular2 на TypeScript, скорее всего MS пытается "захватить" Google.
aristarh1970
Каюсь, каюсь — по-привычке читал, пропустив регалии…
Но тогда «это все меняет», да?
И дот-нет вместе с ее явыками от МС от этого становится удивительно стабильной, без шараханий от технологии к технологии, без нагромождения ориентированных на МС сервисов/библиотек/продуктов, без гонки новых версий при недоработанных предыдущих?..
Razaz
Как раз вырезали все привязки к чисто MS технологиям в Core. И в принципе C# стабилен и развивается будь здоров. И как раз начали активно интегрироваться со всеми. Бабки в облаке водятся, а там пофигу на ОС :)
Qbit
Да, C# язык удивительно стабильный.
Про ориентированные на МС сервисы говорить не буду, так как занимаюсь разработкой игр под iOS и Android. На C#.
Сама риторика типа «шараханий» и «нагромождений» свидетельствует о заведомой предвзятости. Развеивать ваши предубеждения я не берусь.
uldashev
Когда читал, в голове все более навязчиво звучало два вопроса:
1) Может MS уже перестанут ломится на платформы конкурентов, а всерьез уже возьмутся за развитие своей платформы, в лицензировании что нибудь исправят например. Вон Apple живет на своей платформе и не плохо так живет, с каждым годом все лучше и лучше живет.
2) Что это?, MS в очередной раз решило кинуть разработчиков под win платформу? Ау, чуваки, у вас под win все отлично работает и прям нечем больше заняться, а вот давайте dotNet на linux перепишем, а вот давайте python в MSSQL пихнем, а вот давайте c SilverLight что нибудь нехорошее сделаем и т.д. и т.п.
Lailore
Что не так с разработкой под win?
ad1Dima
mayorovp
Silverlight умер когда Google Chrome перестал поддерживать NPAPI.
pnovikov
На самом деле значительно раньше — когда пользователи отказались ставить себе левое расширение для браузера, а программисты открыли для себя удивительно бажное окружение и чудовищно негибкий WCF RIA
mayorovp
Unity значит пользователи ставить себе соглашаются, а Silverlight — наотрез отказались? :-)
Что же до WCF RIA — это дополнительная возможность, а не нечто обязательное к использованию.
pnovikov
Ну дык… Про Unity можно доступно объяснить, мол, пока вот это кнопку не жмакнешь — игруленька не запустится. И пользователь жмакает, потому что хочет игруленьку. Проделывать то же самое, например, для видеоплеера он наотрез откажется, ибо как ему это видео при наличии ютуба никуда не уперлось :) Ну это сугубо ИМХО.
WCF RIA, на сколько я помню, был нужен обязательно для работы с датагридами от Silverlight. И вот пересадить оные на DTO вместо прямого подключения к контексту данных EF/Linq2Sql, да еще и попутно внедрить IoC привносило некоторый геморрой и нотку сюрреализма в решаемую задачу. Дело было давно, всех деталей уже не упомню, но я взялся тогда писать внутреннюю корпоративную админку для одного веб-сайта на этом стеке и меня постигла боль и разочарование при том, что изначально технология смотрелась весьма вкусно. Полагаю, я не один такой был.
mayorovp
Вы просто не с тем сравниваете. Альтернативой Silverlight является обычное десктопное приложение. Так вот — все механизмы, доступные ему, доступны и Silverlight, а еще в Silverlight есть WCF RIA. Обычный контекст EF/Linq2Sql, к примеру, декстопному приложению тоже не доступен если разработчики хоть немного думают о безопасности.
pnovikov
Эмм… альтернативой Silverlight является приложение — извините — на flash. Сейчас уже можно на голом JS (во времена Silverlight ни angularjs, ни react не было). В самом хардкорном случае C#-код исполнялся в браузере — это уже ActiveX-ом попахивает. Ну или да — или NPAPI. Я знаю про WCF RIA довольно много и как инструмент пробрасывания запросов он, извините, неудобен.
mayorovp
js и flash имеют еще большие проблемы с датагридами, нежели Silverlight
pnovikov
Никто не спорит. Но я имею наглость полагать, что коль у MS хватило духу перенести .NET-рантайм в браузер, то неплохо бы собрать яйца в кучку и довести дело до конца, доработав инфраструктуру передачи данных до состояния, когда он будет демонстрировать шокирующую простоту и скорость разработки не только на проектах уровня Hello World.
mayorovp
"Передача данных" в вебе — это SOAP или JSON REST, и с ними все в Silverlight в полном порядке.
pnovikov
Ну и что дальше? Я вам про WCF RIA, вы мне про Ерему.
ElectroGuard
Всегда дотнет недолюбливал, как и жаву. Коллега пишет:
10 мбитный канал у него, если что.
Удобно, когда программам для работы не нужно еще кучи прослоек. Моё личное многолетнее мнение. Что бы кто ни говорил.
mayorovp
А офлайн-инсталятор скачать он что, не догадался?
ggrnd0
Веб инсталяторы такая же зараза как и доп ПО которое ставится по умолчанию если не снять галки.
Кроме того, иногда найти оффлайн-инсталятор бывает сложно...
mayorovp
Сложно найти его только для Хрома. Microsoft же пишет тип установщика в заголовке страницы.
cdmnk
Вес установщика 4.6.2 — 59 мб. Пусть обижается на свою камтазию.
AlexTheLost
За такие заголовки я бы заставлял их менять…
Про JVM:
Сервер-сайд, мобильные устройства(андроид), встраиваемые устройства и устр. обладающие небольшими ресурсами, библиотеки/фреймворки почти на любой случай жизни, много качественных языков Java, Scala, Clojure, Kotlin, огромное сообщество, отличная кросплатформенность. Что из этого есть у .Net? С аналогичным успехом можно перейти на любую другую платформу. Реальная конкуренция JVM|.Net существует только в устах маркетолога MS и студентов которых научили #C за счет агрессивного продвижения всяких курсов в университетах.
Про .Net:
Если вдруг что-то случиться с JVM что звучит смешно если знать о экосистеме что-то за пределами маркетинговых усилий от MS. То я лично предпочту что-то не связанное с MS, почему? MS, исторически доказано, демонстрирует стратегию -> захват рынка и внедрение максимум проприетарных стандартов, после прекращение всякого развития как следствие следствие, вспомнить хотя бы веб захват рынком IE, офисного софта(сейчас есть альтернативы и это круто). Крупный бизнес: Google, IBM, Amazon, Facebook, Oracle и д.р. никогда не переведет свои продукты на технологии от MS, потому что это означает зависимость от MS который может манипулировать развитием технологии и лицензиями для давления на своих конкурентов, хотя бы на рынке облачных технологий. Есть варианты конечно, это полностью открытое и переданное в руки сообщества развитие .Net, включая соответствующую лицензию. Но возникает вопрос зачем, когда есть JVM которая сейчас отлично развивается, которая реализована не только для сервер сайда но и для мобильных устройств(Android), в экосистему которой входят готовые решения почти на все случаи жизни, тщательно протестированные и проверенные годами.
ad1Dima
TheKnight
А расскажите про встраиваемые устройства где C# родной язык?
Lailore
Кхм, мы тут говорим о предпочтениях? И кстати, начали мы с enterprise решениях, а теперь о встраиваемых устройствах? Кстати, тут java суется в королевство си :)
TheKnight
Ну человек говорит что они есть для C# — чеб не расширить свой кругозор и не узнать что то новое?
ad1Dima
Что такое «родной язык»?
под Intel Edison, Raspberry Pi 2, например можно UWP запускать.
TheKnight
Пример Java Card вам о чем нибудь говорит? Если нет — то как бы объяснить будет сложно.
ad1Dima
Настолько урезанной версии .NET я не знаю (хотя кто мешает нормально в native компильнуться).
Ну и Java Card это платформа, а не устройство
AlexTheLost
Ни кто не мешает. Просто тогда вычеркните этот пункт из "все".
ad1Dima
Какой этот? смарткарты? Это не встраиваемые устройства, это рядом. Ок, их нет (или я не знаю)
TheKnight
Поинтересуйтесь на досуге, на чем пишется прошивка SIM-карт.
ad1Dima
Нашли одну точку и бьете в нее. Там поди еще и последняя версия Java поддерживается нормально, или так же как в андроиде?
А если серьезно, читайте внимательно: я уже написал, что .net на смарткартах не поддерживается. ОК.
mayorovp
Хе-хе, на самом деле даже сборщика мусора может не оказаться, а вся память — энергонезависимая или притворяющаяся таковой. Поэтому любые объекты разрешается создавать только при установке приложения...
kekekeks
Отсутствие нормального нативного компилятора. corert только с месяц назад перестал падать на
Console.ReadKeyZashikivarashi
Есть такая вещь
https://en.wikipedia.org/wiki/.NET_Micro_Framework
Razaz
.Net Micro.
TheKnight
Ага, спасибо, буду знать.
UPD: Именно то что нужно!
AlexTheLost
Простите но такого уровня поделки можно найти почти под каждый более/менее популярный язык.
https://github.com/NETMF репозиторий говорит сам о себе.
К тому же это не серьезная система поддерживаемая на уровне свей платформы а любительская разработка.
Razaz
Ну я в свое время юзал. Там еще и UI нормальный был.
Че серьезно? Какая любительская? Прям от самого МС?
AlexTheLost
P.S.
Мне кажеста что для вашего уровня понимаия платформа и языки под неё это одно целое, т.е. C# и .Net.
Минусануть и написать три слова просто. Написать развернутый внятный ответ, нет. Простите что задел ваши религиозные чувства.
ad1Dima
раз два
Из нормального C#, VB.Net, F#, C++. ну и всякие резвлекаловки типа brainfuck или портов питона и руби.
AlexTheLost
Как я и писал у вас нет понимания отличий платформы и языка. Xamarin это .net? Это транслятор для C#.
О встраиваемых устройствах. Первая ссылка на WIndows 10 т.е. на OS. Вторая на что-то любительское и уже мертвое судя по активности.
Из нормального C#, VB.Net, F#, C++. В итоге что-то ощутимо используемое для разработки под .Net это только C#.
P.S. я писал о платформе и в статье обсуждается платформа .Net. Давайте ограничимся этим. Левые ссылки на что-то что просто связано с деятельностью MS, не нужно приводить в доказательство.
По итогу получается что-то на .Net есть, но в меньшем кол-ве чем под JVM и в основном худшего качества, кроме продуктов которые непосредственно поддерживаются MS. Если бы под .Net все было в реальности так хорошо как вы пишите. Я, да и многие кто сейчас использует JVM уже давно бы использовали эту платформу.
mayorovp
Xamarin основан на Mono, так что это именно что реализация .NET, а не просто компилятор.
ad1Dima
Вы просили ссылку на ресурс, где мс поддерживает это направление. Это именно та ссылка. win10 IOT с поддержкой UWP.
Ну если вы не можете левое от не левого отличить…
Отличная логика, я не использую — никто не использует.
pnovikov
При всем уважении, господин хороший, если вы уберете из CTS IDisposable, то у вас в C# перестанут компилироваться using-и, если уберете Func<...> и Expression<...>, то перестанут работать лямбды, про Monitor и lock и Task с async/await упоминать?
Так что вы ошибочно разделяете платформу и язык. Они взаимосвязаны настолько, что если вы выбрасываете составляющую часть платформы — у вас перестают работать фичи языка.
kekekeks
Компилятору сиренево, где брать эти типы, в mscorlib или в вашей вручную изготовленной dll-ке. Я так LINQ и async/await на .NET 2.0 заводил.
pnovikov
Я знаю. Но факт в том, что если в mscorlib этого не упомянуть — не заведется. Вот я о чем. В этом плане async/await не являются чисто языковыми конструкциями
pnovikov
Извините, не в mscorlib конечно же, а где-либо в вашем приложении. Это как если бы работоспособность операции "+" зависела от того, какие у вас references. Ну то есть само по себе это не плохо и не хорошо, однако если у вас такая ситуация наличествует, то я бы не стал картинно напирать на понимание различий между языком и рантаймом.
kekekeks
Windows for IoT хочет 256 мегабайт оперативки. 512 для отрисовки хэлло ворлда на UWP.
Для сравнения авалония при отрисовке в фреймбуфер кушает порядка сотни. На 32-битном арме это ужмётся где-то до 70. Ну и системный линуксовый хлам скушает мегабайт 20. Но это всё пока на уровне альфы, да.
ad1Dima
Я понимаю, что вы пиарите свою утилиту, Вопрос был про целевые платформы и сравнение с Java.
kekekeks
Ну вот эти «встраиваемые устройства» с .NET либо хотят 512 мегабайт памяти, либо используют микрофреймворк, на котором ничего толком нет.
ad1Dima
Во встраиваемые устройства никакой BCL/STD тянуть не выгодно, так-то.
Если в Яву копнуть там тоже начинаются нюансы. На Android`е либо частичная поддержка java 8, либо instant run.
mayorovp
А нам не нужно иметь 3 дополнительных языка только по той причине что основной язык создатели развивать не желают.
AlexTheLost
Java развивается отлично. Просто есть нюанс, обратная совместимость, которая очень важна в долгоживущих проектах.
К тому же в Scala/Clojure это далеко за пределами доп. фич в C#.
mayorovp
Ну так и в C# обратная совместимость терялась только 1 раз, когда скоуп для переменной цикла в foreach заменили — но то изменение исправило больше багов чем создало.
Что фич в Scala/Clojure больше — я не спорю, это шутка была.
Но полного аналога LINQ в Scala все равно нет.
ggrnd0
В scala есть все, только не все успели написать…
querydsl выглядит хорошо: https://bitbucket.org/atlassian/querydsl-examples
Конечно там нет именно что Language Integrated Queries, но лично я им и не пользуюсь — использую чисто IQueryable<T> ...
Попрошу так же заметить, что в java традиционно поддерживаются api не только для чтения, но и модификации данных в БД.
LINQ может только читать, прочие возможности не поддерживаются.
ad1Dima
Вы не поверите…
mayorovp
Но это же ужас какой-то...
А что если в конструкторе ProductDTO не три параметра? А что если там другие типы данных?
Тот самый "чисто IQueryable" такие вещи проверяет.
pnovikov
Этот замечательный пример стоит дополнить тем, что C# так же умеет в анонимные типы, что делает возможным кровавые группировки и джоины. По моему скромному мнению, человек, утверждающий что LINQ не нужен, а он-де пользуется extension-методами для IQueryable ни разу не писал джоинов по составному ключу и группировок этими самыми методами. Я тоже когда-то был маленький и мне LINQ казался не нужным, ибо .Select написать проще чем from x in y select x. Однако потом я столкнулся с частным случаем построения отчетности через EF без SQL. И все заверте…
mayorovp
Кстати, тут пишут что Clojure может исполняться в CLR...
ad1Dima
Сейчас вам скажут, что это неправильный кложур, и он делает неправильный
медкодTheKnight
С LINQ та же фигня)
vba
Почему? Это какие то фанатики вам сказали это. Я как истинный полиглот могу только приветствовать мультиплатформеность. Скалу обещали компилировать под .NET, Kotlin тоже самое, все ограничилось JavaScript.
AlexTheLost
Да можно, только это ответвление. Разработчики Clojure непосредственно уже не поддерживают CLR(на начальной стадии развития языка это было). Со всеми вытекающими.
DistortNeo
Если рассматривать только синтаксис языка, то C# оказывается более динамично развивающимся, чем более инертная Java. Нововведения, появляющиеся в C#, доходят до Java только через год-два.
Razaz
А VM Android уже прошла сертификацию Oracle? ;)
http://www.netmf.com/.
Ну расскажите чего не хватает.
Вообще есть Scala.Net. Только нафиг никому не сдалась. ClosureClr. Сравнивая C#7 c Kotlin и Scala… ну как бы они и не нужны особо, так как ЯП очень активно развивается в сторону гибрида между OO и FP.
Это вы как посчитали?
pnovikov
Не вижу смысла в Scala/Clojure если у вас в руках C#. Если вы пишете на C# и хотите при этом Scala, то вы плохо знаете C#. Когда знаете нормально — начинаете хотеть Nemerle
Lailore
Есть все из этого. А еще например у java есть возможность нативно использовать что-то наподобие F#?
kekekeks
Scala
Lailore
Точно, я про нее забыл. Спасибо
vba
Позвольте поправить, scala все таки далеко до F#, но есть Clojure
nehaev
Почему Scala далеко до F#?
vba
Мой следующий проект я буду вынужден пилить на скале, как бы я хотел что бы он был на F#.
TheKnight
Кстати о фа диез — а его компилятор работает на .NET Core?
P.S.: Если сравнивали с oCaml — будет любопытно почитать.
vba
Пока нет. И это не Ф диез а FSharp даже по FR. В oCaml плюшек будет больше но он не на .NET.
TheKnight
Я и не говорил что это Ф диез. Я сказал это Фа диез. Никак не приучу себя называть эти два языка как написано на вики.
Кстати, где то читал, что там оригинальный знак должен быть именно диезом.
Судя по логотипам — очень на то похоже.
UPD: Это реально диез. Тык!
irium
.NET Core 1.0 Update for F# Tooling
IvaYan
У Java есть Clojure — Лисп поверх JVM.
Да и в целом, альтернативных языков для JVM полно: Groovy, Kotlin, Scala. Хотя у .Net тоже выбор есть: VB, F#. Это все не считая Ruby и Python, которые могут использоватсья и там и там, хотя я не знаю, насколько это распространено.
pnovikov
Еще раз озвучу мнение, что если для платформы плодят кучу разных альтернативных языков, то это означает что нормального языка, который бы всех устраивал под неё нет :)
TheKnight
То бишь наличие под .NET F# и VB.NET означает что C# не нормальный язык? Я вас правильно понял?
pnovikov
Не совсем. F# появился, насколько я врубаюсь, скорее от желания MS повыкабениваться в пору повального увлечения всех функциональным программированием. Его, я думаю, можно не считать. Ну серьезно — это как если бы Scala сделал сам Oracle.
VB.NET появился для удовлетворения одной объективной потребности — миграции внушительного количества
лемминговlegacy-пользователей VB6 на .NET, которым учить С-like язык хуже горькой редьки. Авторство так же за самим Microsoft.Ваше замечание было бы хорошим аргументом, если бы вы упомянули, скажем, Nemerle или Boo :). Но вот беда — оба они широкого распространения не получили и так и остались на уровне такого своеобразного концепта, который люди реферируют в пламенных интернет-дискуссиях, когда надо подчеркнуть богатство возможностей CLR/CTS/CIL. Не встречал ни одного человека, который использовал бы оные в продакшене. Nemerle бедный — так вообще загнулся в развитии по ходу дела и остался притчей во языцех и интересным материалом для теоретических исследований.
Ну т.е. под .NET не было такого случая, когда команда сторонних по отношению к платформе людей заявляет с огромной помпой что вот, мол, сейчас мы сделаем самый-лучший-язык для JVM, который будет лучше чем Java. И в результате получается Scala или Kotlin, который активно начинает использоваться в живом продакшне и в который влюбляются тысячи разработчиков — уж не знаю плохо это или хорошо.
То есть поймите меня правильно, за столько лет ничего лучше чем C# для продакшна и массового использования придумать не удалось :)
Вот список языков, о которых вы никогда не слышали и не станете использовать в продакшне
pnovikov
Я учился в НГУ и сейчас преподаю в НГУ (как раз C#/.NET). Так вот, про агрессивное продвижение всяких курсов скажите Oracle (тогда еще Sun), когда курс ООП читается в первом семестре на C++, а потом внезапно съезжает на Java, сетевые технологии (лабораторные работы) — на Java, компьютерная графика — на Java (но тут правда у студентов есть выбор), в магистратуре курс распределенных систем — Globus Toolkit, базы данных на Oracle зачастую с жестким ограничением на него в лабораторных работах, на терминальных компьютерах в дуалбуте стоит (стояла?) солярка с LibreOffice.
А агрессивно продвигает всякие курсы в университетах все равно Microsoft, ну.
Наладить контакт с Microsoft просто чтобы выбить ну хоть какую-то поддержку локальному коммьюнити (хотя бы информационную — о деньгах не говорю) — оооочень сложная задача в отличие от безгрешного в ваших устах Oracle. Даже гугл лучше поддерживает локальные коммьюнити.
ad1Dima
Когда я учился там ещё был препод, который на MFC древней версии заставлял писать. Потом его таки подвинули.
За это нужно сказать спасибо ровно 2м людям. Тов. Иртегову, и товарищу ex Java Ambassador Романенко, последний в том числе терминальные классы админил и пассивно-агресивно противился раздаче ПО из купленного ФИТом MSDN )
Гугл двигает комьюнити инициативами другого небезразличного частного лица. Собственно есть вузы, где МС продвигается примерно как у нас Java то же за счет личной инициативы. Просто в нск менталитет специфичный, тут ни одно МС-сообщество не зашло.
pnovikov
Само собой. Однако если не интересуешься, то кроме Oracle ничему и не научат. Именно на это одностороннее освещение я и указывал.
Я тоже писал графику на MFC. Сейчас Java с возможностью выбора.
Ну и зачем? Люди деньги потратили, купили, а тут внутри все отказываются использовать, мотивируя это… чем?
ad1Dima
Когда это добро перешло в другие руки, девушка хотела настроить заведение студентов, но я не знаю, чем это закончилось. На других факультетах (ММФ, ФФ) примерно так же.
Я еще помню как в 2006 первокурсникам раздали блокнотики sun с «live»-CD солярки. Причём на CD был записан ISO-файл :D. Кстати, региональный представитель Sun'а живет(жила?) в академе (последний раз я видел её в IBM). Вероятно это тоже сыграло большую роль на засилие Sun в НГУ. Универам-то особо без разницы с кем сотрудничать.
Ну а вообще, в МАИ, ТПУ, в Кемерово (вуз не помню), в некоторых других вузах МС хорошо зашел.
Dimfield
Мечтать не вредно.
Она уже 15 лет теснит. Таким макаром она будет еще лет 100 теснить.
В среде джавистов говорят, что даже если появиться язык заменяющий джаву то хорошо оплачиваемой работы будет еще года так 4. Так как 60-70% ентерпрайза на джава.