.NET Framework скоро Open Source и на *nix


    Основное

    • Reference Source для .NET 4.6 перелицензируется под MIT;
    • В дальнейшем фреймворк будет с открытыми исходниками и поставляться по частям через NuGet, можно будет с приложением поставлять свою сборку, которая будет изолирована от всего остального;
    • Разработка переезжает на GitHub;
    • Скоро откроют исходники рантайма, включая RyuJit и сборшик мусора;
    • Для всего этого счастья планируется официальная поддержка никсов.





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

    На закуску


    • Новая бесплатная редакция Visual Studio с поддержкой расширений;
    • Поддержка grunt, gulp и npm со стороны Visual Studio и ASP.NET;
    • Для ASP.NET будет подготовлен сервер на базе libuv;
    • MSBuild тоже открывают. Собирающие сложные солюшны на Mono больше не должны страдать.


    Материалы:
    1. www.hanselman.com/blog/AnnouncingNET2015NETAsOpenSourceNETOnMacAndLinuxAndVisualStudioCommunity.aspx
    2. blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
    3. www.linux.org.ru/gallery/2978937.jpg
    4. tirania.org/blog/archive/2014/Nov-12.html
    5. habrahabr.ru/company/microsoft/blog/243067 (появилось позже этой заметки)
    6. lists.ximian.com/pipermail/mono-devel-list/2014-November/042315.html
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 259
    • +38
      Хм, это шутка, или сказка? :)
      Я правильно понимаю, что на c# можно будет под Linux официально писать?
      • +25
        Это тренд. Они ещё весной компилятор новый открыли, да и до этого многие вещи изначально с открытыми исходниками делали, те же Typescript и SignalR. В общем, если всё пойдёт нормально, то Java можно будет хоронить. А если ещё шеневмерл ( полноценный .NET функционально-ориентированого язык с адекватной системой макросов и возможностью при желании из него сделать superset C#) со своим компилятором на базе Nitra из под крыла JetBrains подтянется наконец (что даст нормальную поддержку в Visual Studio и ReSharper), то хоронить можно будет уже скалу.
        • +10
          Про тренд, я, конечно же, слышал: слежу за .NET. Но всё-равно всё это выглядит очень круто.
          Помрёт или нет java — не могу сказать. Уж больно много кода написано на ней, да и «восьмёрка» вполне себе хороша. Ещё же и студии нет под Linux, а для Java есть прекрасная IDEA.
          • +3
            На Java уж извините, столько энтерпрайза написано, что C# до такого показателя, очень и очень далеко. Да и нет у C# каких либо киллер фич которые давали бы повод перейти с java на C#.
            • +1
              Ну написано, и? Есть Sharpen, есть IKVM, всё это можно под CLR запустить после некоторой обработки напильником и автоматическими трансляторами. Вот в обратную сторону не получится, да.
              • +33
                Проперти, делегаты, нормальные (вменяемые) дженерики,…
                • +29
                  ..., Value-типы, P/Invoke вместо страшного сна под названием JNI, возможность прямой работы с указателями,…
                  • +1
                    Вот только это все для кодеров счастье, энтерпрайз этим не заманишь.
                    • +8
                      То есть как это? Это напрямую влияет на продуктивность.
                      • +2
                        Да, но при крупном планировании в первую очередь смотрят на коммерческую поддержку продуктов и компонентов, а также на инфраструктуру. SharePoint не отдадут.
                        • +7
                          Ещё там лубят пускать код на больших машинах с непривычной архитектурой, туда вряд ли станут портировать .NET — банально не хватит ресурсов.
                        • –4
                          Да не на что это не влияет. В яве лямбды появились пол года назад. В шарпе они бог знает сколько. Как же они жили до этого? Да очень просто и не принужденно.
                          Ну появились они, ну ок будим их использовать, да удобней, ок живем дальше.
                          • +7
                            Да ни на что это не влияет. В яве лямбды появились полгода назад. В шарпе они бог знает сколько. Как же они жили до этого? Да очень просто и непринужденно. Ну появились они, ну ок, будем их использовать, да, удобней, ок, живем дальше*.
                            Лямбды — это не просто «стало удобнее», они дали возможность создания такой штуки как LINQ, которая
                            1) позволяет простыню из циклов на несколько страниц свернуть в одну-две строки и превратить императивный код в декларативный;
                            2) позволяет делать DSL к различным хранилищам данных;
                            3) позволяет делать вещи наподобие Rx;

                            Деревья выражений, позволившие сделать Linq2Sql и наследников, до сих пор не реализованы, и о планах пока не слышно.

                            *Прошу не считать подсветку красным проявлением «нечего сказать — докопайся до орфографии», просто из глаз начинает сочиться кровь от такого.
                            • –2
                              Мне кажется, что вы ответили не на мой комментарий. А на фразу, выдернутую из контекста — «стало удобнее». Потому, что я не спрашивал о том чем полезны лямбды. Проясню вам смысл.
                              Месседж моего комментария в том, что интерпрайзу эти лямбды сто лет в обед. Он медленный и не поворотливый. И ему просто не нужно все это новомодное и продвинутое. И основное правило там — работает не трогай.
                              Чем проще, понятней и сопровождаемей будет код, тем лучше.
                              Поэтому много где до сих пор 6 ява. Чтоб никто в свич не пихал стринги, а максимум энум. Чтоб даже возможности такой не было.
                              • +3
                                Чем проще, понятней и сопровождаемей будет код, тем лучше.
                                1) позволяет простыню из циклов на несколько страниц свернуть в одну-две строки и превратить императивный код в декларативный;
                                Одну строку на LINQ проще читать и поддерживать чем портянку на несколько страниц
                                • –4
                                  А теперь представьте, что в каком-то интерпрайзе, а в интерпрайзе, как мы знаем, все на яве, один умник (большой любитель функцональщины и декларотивности) сделал свое дело. И через время уволился.
                                  Напомню лямбды в яве пол года.
                                  Какие программисты придут на его место? Что они будет со всем этим делать?

                                  Вот вам понятность и сопровождаемость. А отладка и тестирование с лямбдами — ммм…
                                  Спасибо джетбрейнс, что они хоть что-то в этом направлении делают.

                                  Одну строку на LINQ проще читать и поддерживать чем портянку на несколько страниц

                                  Я видел Rx. Ничего понятного для объектно ориентированного разума там нет.
                                  • +7
                                    Напомню лямбды в яве пол года.
                                    Какие программисты придут на его место? Что они будет со всем этим делать?

                                    Если разобраться с лямбдами для вас представляется сложным, то может лучше пойти вон из профессии?
                                    • –2
                                      А других нету, понимаете. Специалистов катастрофически не хватает.
                                      Вот, очень показательный пример: morgen-krsk.livejournal.com/3474.html
                                      Человек привел два кода и говорит, что познал истину. Слева у меня плохой императивный код, а справа декларативный. Значит императивный подход — плохой, а декларативный — что надо.
                                      • +1
                                        Не вижу, что не так со статьёй. Тот код, что справа легче читать и поддерживать чем тот, что слева. Единственная проблема состоит в деградации производительности. Если бы ещё компилятор умел нормально разворачивать правое в левое (а это должно быть задачей компилятора, а не человека, при профилировании увидевшего что оно тормозит), было бы вообще отлично. Сейчас приходится использовать костыли типа LinqOptimizer.
                                        • –1
                                          Тот код, что справа легче читать и поддерживать чем тот, что слева.

                                          Все верно. Действительно, тот код, что справа легче читать и поддерживать чем тот, что слева. Потому, что слева человек наговнокодил, а справа использовал функциональщину. И выдает все это за плюсы и минусы соответствующих подходов.
                                          Если нужно повторное использование кода, связность и т.д. то напиши так.
                                          Зачем сравнивать теплое с мягким.
                                          • +1
                                            Смотрю на статью, вижу там нахождение суммы значения функции от элемента массива, когда элемент больше 10. Я правда не понимаю, почему это заговнокодено. И в императивном и «декларативном» подходе оба кода оптимальные с точки зрения количества строк кода (хотя форматирование страдает), прозрачности намерений и производительности которую можно выжать при данном подходе. Если переписать код слева так, чтобы в нем была возможность повторного использования вы получите оверхед по количеству строк и понимаемости кода.

                                            Да, статья однобокая. Императивный/функциональный подходы бывают удобны в разных случаях. Если объяснять поближе к императивному подходу — метод можно написать с рекурсией и без рекурсии, только в одном случае один подход будет красив, а в другом случае второй подход будет красив. Но тут уж такие приколы, что функциональный подход для обработки коллекция покрывает большую часть нужд программиста. Именно поэтому LINQ хорош.
                      • –12
                        Вы знаете как у вас там рантайм открыт? Или как гц работает или ануего, описание есть? Про JIT много информации?
                        • –1
                          Минусуем, но не отвечаем? Правильно! :-)
                        • +1
                          Java тоже развивается — в 9 версии заявлены Value типы. Да и вместо JNI можно использовать framework JNA.
                          • +1
                            Не будет в девятке value типов.
                            • +1
                              Ну Владимир Иванов на Joker'е, который был в октябре, сказал что работают над ними. А у Вас откуда такая информация?
                          • +2
                            Прямая работа с указателями есть — смотрите на Unsafe класс. Там еще много чего прямого есть ;)
                            • +4
                              Под прямой работой с указателями подразумевалось что-то типа
                              unsafe void Foo(IntPtr ptr, int count)
                              {
                              	var s = (MyStruct*)ptr;
                              	for(var c=0; c<count; c++)
                              	{
                              		s->Field = c;
                              		s++;
                              	}
                              }
                              То, что через Unsafe-класс, сильно напоминает работу с памятью из VB6, где всё сводилось к постоянным вывовам kernel32!CopyMemory.
                              • –5
                                Возможность есть — это факт :) мы вроде именно о ней говорили :)
                                А вообще имхо — Unsafe не на много более сложный, но намного более явный чем приведенный код, в рамках парадигмы managed среды.
                                • +3
                                  Через промежуточный класс-хелпер — это не напрямую.
                                  • –1
                                    Хмм а какая разница? Возможность оперировать памятью напрямую есть. Use case покрывается.
                                    • +2
                                      Эм. Объявить структуру с нужным выравниванием и байтовыми смещениями(опционально), а потом переключить язык в режим чистой сишки — это несколько не одно и то же, что стучаться к памяти через мутный враппер.
                          • 0
                            Проперти действительно не хватает. А что с дженериками в джаве не так? Действительно интересно.
                            • +11
                              Type Erasure. Если кратко — во время исполнения нет информации о типах, и все дженерики представлены как Object.
                              • +8
                                Type erasure :( вся инфа потерта в рантайме. Считайте дженериков и не было.
                                • +1
                                  Не всегда так и немного не так, но в целом есть такое дело. Если что — можно понять в рантайме какие были дженерик параметры в особых случаях. Создавать дженерики в рантайме нельзя.
                                  • –4
                                    Кого я вижу! Едешь на .NEXT?
                                    • –2
                                      Неа :) я же теперь Java девелопер :)
                                      • –2
                                        Ну и что?
                                        • –2
                                          Денех жалко :)
                                          • –3
                                            Ты ж вроде в хэдж-фонде. Для фонда эти деньги — нуль без палочки.
                                            • –2
                                              Уже нет :)
                                              • –4
                                                Всем чпоки в этом чатике. Use private messages, Luke!
                              • +1
                                Многие косяки явы обещает поправить цейлон, ну и прочие языки новой волны под платформу явы. Интересно, кто быстрее займёт нишу…
                              • +14
                                На Java уж извините, столько энтерпрайза написано, что C# до такого показателя, очень и очень далеко. Да и нет у C# каких либо киллер фич которые давали бы повод перейти с java на C#.


                                15 лет назад можно было бы заменить в этой фразе C# на джаву, а джаву на кобол и смысл остался бы тот же ;)
                                • +10
                                  Сначала джаву на кобол, потом шарп на джаву. Если заменять в обратном порядке, то все языки на кобол заменятся.
                                  • 0
                                    Верным путем. Так и до асма доберемся.
                                • –2
                                  • +14
                                    Каноническая ссылка: en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java

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

                                    Ну уж а с выходом следующих двух версий, где всё от строковых интерполяций до паттерн-матчинга…
                                    • 0
                                      Pattern-matching отложили пока до 7-ой версии.
                                      • +2
                                        Так и планировалось же? Шестая — фенечки, седьмая — прогресс. Из планируемого на шестую версию, но отменённого, там разве что всякие «конструкторы по умолчанию» и прочий сомнительный хлам повыкидывали (ну и объявления переменных как выражения, их жалко, да).

                                        Зато строковую интерполяцию запили, причём с поддержкой локалей. Я уж и не ждал, всё время упирались, что нафиг надо.
                                        • +3
                                          а что такое строковая интерполяция?
                                          • +5
                                            roslyn.codeplex.com/discussions/570292
                                            string name = ...;
                                            Console.WriteLine($"Hello, {name}!");
                                            
                                            • +4
                                              Perl смотрит на это и улыбается :)
                                              • +14
                                                Все смотрят на Perl и улыбаются ;)
                                                • +29
                                                  Одному мне хочется плакать, глядя на перл? (
                                                  • +2
                                                    Не, просто кактус со временем становится вкусный :)
                                                    • 0
                                                      Стокгольмский синдром, ага.
                                  • +6
                                    >Да и нет у C# каких либо киллер фич которые давали бы повод перейти с java на C#.

                                    Да ну? Один Linq чего стоит!
                                    • +5
                                      Не холивара ради, но в джаве есть Стримы, которые, кажется, могут представлять собой замену Linq.
                                      • +5
                                        Мощь Linq заключается в Expression Trees, а насколько мне известно, Стримы ничем похожим не обладают.
                                        • +2
                                          Более того, раз уж зашла речь, есть такая конструкция Reactive Extensions которая, я не знаю как сейчас, но имела свой аналог в Java под названием ESPER, где надо было что-то писать в строках на SQL-образном диалекте. Так вот, Rx под дотнетом намного комфортней работать. Сейчас да, возможно будет что-то похожее для Java.
                                        • –3
                                          и в чем же мощь Expression Trees?
                                          • +3
                                            Идея в том, что вы можете написать свой транслятор деревьев выражений для практически любого языка запросов(например для SQL).

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

                                        • +6
                                          в джаве есть Стримы, которые, кажется, могут представлять собой замену Linq

                                          Кроме уже упомянутого отсутствия деревьев выражений, есть ещё нюанс: из-за отсутствия полноценных дженериков в стримах костыль на костыле, когда дело касается примитивных типов. Та же петрушка с функциональными интерфейсами.
                                    • +2
                                      Зачем нужен Nemerle, если есть C# и F# (которые уже сейчас фактически open source)? Разве что макросы писать… и то, очень спорная фича.
                                      • +6
                                        В C# жутко не хватает концепции всё есть выражение (полноценно и везде её вкрутить уже не получится, сломается обратная совместимость), паттерн-матчинга, гарантированной оптимизации хвостовой рекурсии и ещё по мелочи. F# не плох, но чужероден. Одна необходимость писать нижнимКемельКейсом в .NET-языке вызывает недоумение, да и он ближе к чисто функциональным языкам, чем к смеси парадигм. Nemerle этими проблемами не страдает.
                                      • +3
                                        Вы меня очень расстраиваете. Я только начал знакомиться со Scala на уровне A2/L1, толком ничего не писал на ней кроме заданий, но буквально влюбился в этот язык. Как думаете, есть ли шанс, что в Scala вернут поддержку .NET в связи с этими событиями?
                                        • +1
                                          MSIL-бакэнд уже два года как заброшен и не похоже, что им кто-то будет заниматься.
                                          У меня вот от скалы смешанные впечатления. Вроде бы всё хорошо, но когда выяснилось, что мне нужно в полуручном режиме писать сериализацию в JSON, а при попытке работы с анонимным типом компилятор предложил разрешить использовать для этого рефлексию, так как без неё он не могёт…
                                          В общем, посмотрите в сторону Nemerle. Оно наверняка вам понравится.
                                          • +4
                                            Наезд на скалу безосновательный. С JSON куча вариантов есть, можно полностью автоматически сериализовать, можно вручную но с проверкой возможности сериализовать во время компиляции, можно объединять оба подхода.
                                            А рефлексия нужна не для анонимных типов, а для структурных, которые используются довольно редко.
                                        • +12
                                          Ценность Java не в синтаксисе и не только в кроссплатформенности. Ее главная ценность в opensource community.
                                          Взять тот же Spring Framework со всем обвесом (Security, Spring Data, Spring MVC, ...), за развитием которого не успевает канонический Java EE.
                                          А сколько разных реализаций Java EE контейнеров…
                                          Много ли Вы знаете альтернатив ASP.NET MVC, к примеру? В мире .NET кроме собственных продуктов Microsoft очень мало альтернатив.
                                          • –1
                                            а нужна ли эти альтернативы, если в мире .NET они будут кое-как поспевать за родным стеком MS? Тем более ASP.NET с легкостью можеть потягаться со Spring.
                                            • +9
                                              На мой взгляд, коммьюнити и альтернативы это хорошо, т.к. в разных командах появляются и проверяются разные идеи, и таким образом выживают лучшие идеи. Плюс если разные команды фокусируются на разных приоритетах, то разработчик может выбрать ту альтернативу, в которой реализовано то, что важно именно ему. В мире .NET, если в Microsoft решили, что какая-то фича неважна, то разработчикам приходится годами ждать ее появления. WPF уже много лет не развивается, и тут на хабре не раз проскакивали возмущения этим фактом. В opensource коммьюнити давно бы уже кто-нибудь сделал fork проекта и продолжил его развитие.

                                              Моя мысль в том, что Microsoft не в состоянии заменить все opensource community. Вот если вокруг opensource кроссплатформенного .NET появится массовое коммьюнити и сторонних проектов, это будет круто. В принципе, это уже сейчас реально благодаря проектам Mono и Xamarin. Но говорить о том, что теперь Java обречена, по меньшей мере наивно.
                                              • –2
                                                как только выйдет ASP.NET vNext также opensource-проектом, ничто не мешает (если лицензия позволяет, не помню, что они там заявляли) делать форки с лучшими с точки зрения коммунити решениями на базе существующей кодовой базы.
                                                • +3
                                                  Да, тенденция понятна. Но Microsoft тут в роли догоняющего все-таки.
                                                  • +1
                                                    догоняющего в плане коммунити — возможно и так. В плане технологий — точно нет. Как я уже заметил, написать альтернативу тому же ASP.NET vNext как есть альтернатива в виде Spring для JEE, — задача, которая ставит сообщество в догоняющие, пока не сделает действительно достойный форк основного стека, который далеко ушел от оригинала
                                                    • +3
                                                      ASP.NET ни в коей мере не аналог ни Java EE не Spring. Это скорее Servlet API + JSP.
                                                      В спринг и в ее входит гораздо больший набор технологий.
                                                      • 0
                                                        я не знаю, какими критериями вы руководствовались, я лишь грубо их сопоставил. Тем более Spring — это вообще комбайн решений, поэтому да, он в сравнении впереди планеты всей. Глубокий анализ я не проводил, да и не хочу, ибо на стеке java ee писал последний раз более 3х лет назад.
                                                        Но я с радостью (это без сарказма) почитал бы информацию, на которой основывается ваше мнение, если оно не ограничивается только личным опытом.
                                                        • +3
                                                          ASP.NET = Servlet API + JSP? У вас низкие знания о .NET. Попрошу внимательно посмотреть на все фичи ASP.NET WebForms, ASP.NET MVC, ASP.NET Web Api, ASP.NET SignalR. Ну и на стандартную библиотеку и многие опенсорсовые библиотеки для .NET.

                                                          Сообщение случайно получилось слишком закапсленным.
                                                          • 0
                                                            Я не говорю про стандартную библиотеку .NET (и ее бы сравнивать с Java SE) а именно о ASP.NET. Поверьте — я очень хорошо разбираюсь в .NET мире. Знаю например и о Autofac (а может Unity или NInject), NHibernate и Entity Framework. Наверное я немного сгустил краски, но ASP.NET это набор библиотек для создания web — приложений. Spring — это фреймворк для создания любых приложений и в нем намного больше всего. Как минимум поддержка работы с базами данных (Templates, Transactions) и поддержка AOP. Ну и мессаджинг.
                                                            • +1
                                                              • +1
                                                                так см Spring Projects. Ну нет в .NET ниодного framework который ВСЕ это реализует. Найти соответствия в разных библиотеках можно.
                                                                • +1
                                                                  Ну нет в .NET ниодного framework который ВСЕ это реализует.


                                                                  А что это за святая цель — фреймворк, который делает ВСЕ? Очевидно такой фреймворк будет тем еще говном, потому что ВСЕ хорошо нельзя делать по определению.
                                                              • +2
                                                                Я не говорю про стандартную библиотеку .NET (и ее бы сравнивать с Java SE)

                                                                Некоторые вещи в spring/guava и прочих полезных хелперных либах — это разница между стандартной библиотекой .NET и стандартной библиотекой Java SE. Кстати, у вас там уже определись какой класс должен использоваться для работы с временем и датой?

                                                                Знаю например и о Autofac (а может Unity или NInject)
                                                                и поддержка AOP

                                                                Unity умеет AOP в runtime, Windsor умеет AOP в runtime (с этим работал), Fody предоставляет самые примитивные возможности code rewriting (в compile-time; работал с этим), LinFu предоставляет AOP в compile time, PostSharp (вот он правда платный) предоставляет AOP в compile time.

                                                                Наверное я немного сгустил краски, но ASP.NET это набор библиотек для создания web — приложений

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

                                                                Как минимум поддержка работы с базами данных (Templates, Transactions)

                                                                Сборка System.Transactions (стандартная библиотека), linq2sql, Entity Framework.

                                                                Ну и мессаджинг

                                                                Что вы подразумеваете под мессаджингом? Publish/Observe внутри одной программы, WCF или что-то типа RabbitMQ?

                                                                Нет, я верю что Spring огромен. Это DI контейнер (Unity/Autofac/Windsor/Ninject), это MVC (ASP.NET MVC), это еще куча всего. Внутри springа все побито на модули, только походу вы этого не видите и не понимаете. Просто в .NET мире принято по другому именовать модули; не вкидывая общее название в название отдельного проекта.

                                                                Кстати, я же правильно перевожу эту фразу «The spring-orm module provides integration layers for popular object-relational mapping APIs, including JPA, JDO, and Hibernate.» как «Для интеграции Hibernate в Spring нужна тонна костылей, держите spring-orm — мы уже их написали»?
                                                                • +1
                                                                  >Кстати, у вас там уже определись какой класс должен использоваться для работы с временем и датой?

                                                                  А вам с какой с таймзон офсетом или без него? LocalDateTime, ZonedDateTime, Instant и еще много других.
                                                                  А как там в вашей стандартной библиотеки можно unix timestamp в объект времени и даты перевести?

                                                                  >Unity умеет AOP в runtime, Windsor умеет AOP в runtime (с этим работал), Fody предоставляет самые примитивные возможности code rewriting (в compile-time; работал с этим), LinFu предоставляет AOP в compile time, PostSharp (вот он правда платный) предоставляет AOP в compile time.

                                                                  Ага, вот Spring c помощью AspectJ умеет это делать в одном месте и сам — без попытки скрестить ежа с ужом в вашем коде.

                                                                  >Ну да. Если хотите создавать десктопные приложения есть WPF. Если кто-то думает, что можно эффективно писать десктопные, мобильные и веб-приложения на одном фреймворке, то мне кажется, что он упоролся и не понимает, что конечно же можно. Но цена этого…

                                                                  Воу воу — у нас только 2 типа приложений есть? Есть например сервисы обрабатывающие данные в бекэнде и их тоже можно писать с помощью Spring.

                                                                  >Внутри springа все побито на модули, только походу вы этого не видите и не понимаете.

                                                                  Да нет — прекрасно вижу и понимаю. Заслуга Spring в том что создатели скрестили в нормальном виде кучу библиотек и отдали нам готовый, ясный и непротиворечивый продукт, в котором есть решение для практически любой часто повторяющейся проблемы.
                                                                  В .NET мире все по другому — я не спорю. Разные подходы.
                                                                  Но если вы обратите внимание на начало этой ветки то вы увидите что было сравнение Spring c ASP.Net, я же в резкой и саркастической форме указал на то, что сравнение не корректно.
                                                                  • 0
                                                                    А вам с какой с таймзон офсетом или без него? LocalDateTime, ZonedDateTime, Instant и еще много других.

                                                                    А еще java.util.Date, java.util.Calendar. Вы правда думаете, что нужно так много классов?

                                                                    А как там в вашей стандартной библиотеки можно unix timestamp в объект времени и даты перевести?

                                                                    Норм, C# и .NET хорошо спроектированы. В стандартной библиотеке никак, она спроектирована с учетом того, чтобы предоставить удобное API. В итоге везде можно передавать DateTime и не медитировать над тем чтобы конвертировать дату из одного класса в другой. Если мы хотим конвертировать в unixtime и обратно (правда, не очень сложный алгоритм), то можно написать extension метод для DateTime, который в коде будет выглядеть родным методом над DateTime. А, ну да, можно установить nuget package, который дает эту возможность.

                                                                    Ага, вот Spring c помощью AspectJ умеет это делать в одном месте и сам — без попытки скрестить ежа с ужом в вашем коде.

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

                                                                    Воу воу — у нас только 2 типа приложений есть? Есть например сервисы обрабатывающие данные в бекэнде и их тоже можно писать с помощью Spring.

                                                                    А зачем там Spring простите? Вот я пишу веб-приложение на ASP.NET MVC + Web API. Зачем сервису эти фреймворки-то? Доступ к системе роутинга и движку рендеринга? Ну дык, это решается подключением парочки библиотек.

                                                                    Но если вы обратите внимание на начало этой ветки то вы увидите что было сравнение Spring c ASP.Net, я же в резкой и саркастической форме указал на то, что сравнение не корректно.

                                                                    Меня покоробило сравнение c Servlet API + JSP. Валидации данных нет, биндинга моделей нету, security нету, к населена роботами.

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

                                                                    И почему вы думаете, что весь стек .NET это сырой, неясный и противоречивый продукт-то? Только потому что у всех библиотек нету префикса SuperPuper? Или потому что библиотеки писались так, чтобы их можно было использовать не только внутри asp.net?
                                                                    • –1
                                                                      >А еще java.util.Date, java.util.Calendar. Вы правда думаете, что нужно так много классов?

                                                                      Ок давайте поговорим о System.Collection — которые явный костыль для совместимости с 1.0. Или 2 API для работы с XML.

                                                                      >Норм, C# и .NET хорошо спроектированы. В стандартной библиотеке никак, она спроектирована с учетом того, чтобы предоставить удобное API. В итоге везде можно передавать DateTime и не медитировать над тем чтобы конвертировать дату из одного класса в другой. Если мы хотим конвертировать в unixtime и обратно (правда, не очень сложный алгоритм), то можно написать extension метод для DateTime, который в коде будет выглядеть родным методом над DateTime. А, ну да, можно установить nuget package, который дает эту возможность.

                                                                      Бла-Бла-Бла — вам это не нужно, а если нужно, то просто самому написать, а если сложно самому написать у нас есть менеджер зависимостей. Вот это да, вот это я понимаю ответ! Не несите такого пожалуйста. У .Net в стандартной библиотеки есть очень хорошо написанные куски — но есть моменты где стандартного функционала явно не хватает.

                                                                      > Зачем сервису эти фреймворки-то?

                                                                      Оо — как зачем. А весь life-time management мне самому писать? Или разбор конфигурации в 21м веке?

                                                                      > Вот я пишу веб-приложение на ASP.NET MVC + Web API. Зачем сервису эти фреймворки-то? Доступ к системе роутинга и движку рендеринга?

                                                                      Не зачем — я их не подключу в бекэнд задаче

                                                                      >Ну дык, это решается подключением парочки библиотек.

                                                                      Да вы сделаете так — потом будем думать как сделать в winsdor lifetime scope на wcf — сессию по мультеплексированному коннекшенну, ну или создавать дерево классов руками приковывая зависимости

                                                                      >Меня покоробило сравнение c Servlet API + JSP. Валидации данных нет, биндинга моделей нету, security нету, к населена роботами.

                                                                      Ну я тоже признал что сравнение не корректное 2 комментариями выше.

                                                                      >И почему вы думаете, что весь стек .NET это сырой, неясный и противоречивый продукт-то?

                                                                      Ну где я это написал? .Net стек я люблю — у меня блин 9 лет опыта разработки на нем. Я прекрасно его знаю и знаю какие проблемы возникают при попытках скрестить разные библиотеки. Spring пытается решить эти проблемы. В .Net ему к сожалению аналогов нет. Может и не нужно — тк задача у него в generic виде дать вам ужа-ежа. В Java тоже много веселого. Попробуйте скрестить Guice и Netty, так чтобы на каждый channel создавался свой scope — найдете кучу увлекательного времяпрепровождения. Задача которую решает Spring очень сложная — создать среду где вы пишите минимум кода и все инструменты у вас под рукой и интегрированы в эту среду. Пока на .Net необходимости в такой среде нет. Но на Java жить без нее уже сложно.

                                                                      • 0
                                                                        Ок давайте поговорим о System.Collection — которые явный костыль для совместимости с 1.0.

                                                                        Ок, давайте поговорим о том, что в Java нету genericов в runtime и value-types тоже нету. Просто в .NET решили оставить старый код; а в Java решили жить без настоящего type safety (что смешно для языка в котором нету даже автовывода типов).

                                                                        Бла-Бла-Бла — вам это не нужно, а если нужно, то просто самому написать, а если сложно самому написать у нас есть менеджер зависимостей. Вот это да, вот это я понимаю ответ! Не несите такого пожалуйста. У .Net в стандартной библиотеки есть очень хорошо написанные куски — но есть моменты где стандартного функционала явно не хватает.

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

                                                                        Оо — как зачем. А весь life-time management мне самому писать? Или разбор конфигурации в 21м веке?

                                                                        O_o. Я же правильно понимаю, что мы говорим сейчас про IoC-контейнер? При описании зависимостей для Windsor считается хорошим тоном группировать описания зависимостей в специфичном классе (который реализует интерфейс IWindsorInstaller), а потом вызывать container.Install. При этом можно из одного инсталлятора вызывать другой инсталлятор, таким образом выделить сущности нужные и тому, и тому, и отдельно сервисам, и отдельно вебу. Ну или можно юзать одну и ту же конфигурацию. Проблем с управлением life-time в сервисных проектах не испытывал, так что не понимаю, о чем вы говорите.
                                                                        • +1
                                                                          Да вы сделаете так — потом будем думать как сделать в winsdor lifetime scope на wcf — сессию по мультеплексированному коннекшенну, ну или создавать дерево классов руками приковывая зависимости

                                                                          O_o. Ручное DI это вредно. С WCF не работал серьезно, поэтому не могу ничего сказать по этому поводу. Но, вы уверенны, что есть большая проблема в прикручивании Windsorа/другого DI-контейнера к WCF?

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

                                                                          Увы-увы, я не верю, что можно написать универсальный всем подходящий продукт, который не будет говном. Вы уверены, что Spring вот такой вот офигенный, что используется во всех компаниях которые пишут на Java? А то я знаю как минимум одну компанию не по наслышке, которая живет без Springи в куче проектов и чувствует себя нормально.

                                                                          А, ну и о интегрированности продуктов. Asp.net MVC и Entity Framework вроде разные продукты, только студия из коробки имеет средства генерации контроллера и вьюх по EF-сущности. Может оно все не настолько уебищно как кажется?

                                                                      • +3
                                                                        А как там в вашей стандартной библиотеки можно unix timestamp в объект времени и даты перевести?

                                                                        В 4.6 будет, если не путаю. Но там код в одну строчку, так что в целом пофиг.
                                                        • –2
                                                          Откройте Codeplex.com, NuGet.org (большинство доступных там библиотек открыто), поищите на том же гихабе. Есть у .Net сообщество.
                                                          • +3
                                                            Я не говорю, что его нет. Но масштабы пока несопоставимы. Посмотрите хотя бы на проекты вроде Hadoop + HBase, Hive, Impala, Spark, Pig, ZooKeeper… Это проекты, в которые помимо Apache и Cloudera вкладываются такие гиганты, как Facebook, Twitter, LinkedIn, Yahoo.
                                                            Примеров такого уровня из .NET я не знаю.
                                                    • –2
                                                      Ага, да, Spring, да, конечно. А потом начинается: на проекте Java 5/6, Spring устаревших версий.
                                                      Половина туториалов ущербны чуть более чем полностью, четверть относится к новым версиям, из оставшейся части большая часть относится к старым версиям. Ой, а что это за исключение «java.lang.NoSuchMethodError».

                                                      На Java много чего хорошего написано. Например Elasticsearch, который можно юзать и в .NET и в куче других языков.
                                                      А на erlangе написан RabbitMq, но в .NETе и кучи других языков можно использовать RabbitMq.
                                                      Дело в том, что необязательно использовать Java, чтобы использовать продукты написанные на Java.
                                                      И оп-па одно из преимуществ Java внезапно улетучивается, если правильно смотреть.

                                                      P.S: я думаю, что написать конвертер Java Bytecode -> .NET IL не такая уж трудная задача при необходимости.
                                                      • +2
                                                        Все уже написано и работает. www.ikvm.net/userguide/ikvmc.html It converts the Java bytecodes in the input files to .NET CIL
                                                        • 0
                                                          Хм. Круто. А я и не знал, что такое реализовано. Правда несколько настораживают SourceForge и CVS.
                                                    • 0
                                                      Ну если Scala и Clojure на .net нормально поддерживаться будут, да еще TCO на нем использовать — надо будет переходить.
                                                      IDE я все равно пользоваться так и не научился, без студии обойдусь.
                                                    • 0
                                                      Linux линуксом, подскажите, а про официальную поддержку разработки под мобильные платформы информация есть?
                                                      • 0
                                                        Насколько я понял, этой частью продолжат заведовать Xamarin. Они возьмут части кода из оригинального .NET и заменят не полностью или спорно реализованные части mono.
                                                        • 0
                                                          Xamarin и Cordova.
                                                          МС со своей стороны поддерживает плагин для студии, андроид эмулятор, C++ разработку под андроид и прочее.
                                                    • +4
                                                      Внезапно.
                                                      • +7
                                                        Кстати, не очень. MS давно к этому шли.
                                                      • +22
                                                        Ущипните меня, это похоже на сон!
                                                        Кто-то когда-то шутил о том, что RMS покусал ребят из Microsoft, похоже что это была не шутка.

                                                        • +17
                                                          Я и шутил. Только вот по ходу оказалось не шуткой.
                                                          • +4
                                                            А если в следующей версии Microsoft ещё и своё DE запилит под Unix + офис… :D
                                                            • +3
                                                              Microsoft Linux 2015?
                                                              • 0
                                                                См. 3-ю ссылку в посте.
                                                                • +8
                                                                  А я был бы не против. Я даже платил бы за DE. Удобство yum или apt + удобство bash/zsh вылизанная графическая оболочка = обожание и любовь с моей стороны. Меня мало волнует GNU/не гну.
                                                              • +5
                                                                RMS за copyleft и против пермиссивных лицензий, а тут лицензия MIT.
                                                              • +7
                                                                Вот ещё одна интересная картинка с конференции.
                                                                • +8
                                                                  Уиииии!!! :))))) Если сделают свободную кроссплатформенную реализацию без Xamarin-рабства, будет просто конфетка!
                                                                  • +7
                                                                    Так в оригинале и написано: Visual Studio 2015 and .NET 2015: build for any device (Built from the ground up with support for iOS, Android and Windows)
                                                                    • 0
                                                                      Под
                                                                      Built from the ground up with support for iOS, Android and Windows
                                                                      подразумевается Apache Cordova.
                                                                      А ещё в Xamarin в бесплатной версии лимиты на приложения увеличили в 2 раза и оно ставится на бесплатную же VS Community 2013.
                                                                      • 0
                                                                        А на платные скидку MSDN подписчикам сделали. Будем надеяться это только начало.
                                                                        • 0
                                                                          Ей тоже где-то полгода.
                                                                    • +2
                                                                      Возможно, они таки купят Xamarin и сделают все именно на их базе.
                                                                      • 0
                                                                        Реально от Xamarin хочется полноценную некоммерческую версию для некоммерческой разработки и обучения. Для коммерческой разработки у них вроде бы вполне адекватные цены.
                                                                        • 0
                                                                          Для обучения у них есть разные программы бесплатные. Попробуйте просто им написать
                                                                          • 0
                                                                            Без официального статуса учащегося в официальном учебном заведении?
                                                                          • 0
                                                                            Xamarin бесплатен для студентов и преподавателей xamarin.com/student
                                                                            • 0
                                                                              А что учиться могут только студенты и преподаватели? А если я просто сам хочу пообучаться в свободное время?
                                                                              • 0
                                                                                Триал — 30 дней бесплатно. (в последней статье они писали про то, что могут подарить ещё 30 дней).
                                                                                Starter Edition, для маленьких по размеру приложений — бесплатно.
                                                                                • 0
                                                                                  Это никак не отменяет написанного мной в исходном комментарии, который был ответом на

                                                                                  Возможно, они таки купят Xamarin и сделают все именно на их базе.


                                                                                  Мне бы не хотелось чтобы MS покупал Xamarin, пусть лучше остаются независимыми но сделают нормальную версию для инди как Unity.
                                                                                  • 0
                                                                                    Простите, а оно должно отменять написанное в том комменте, на который я не отвечал?
                                                                                    • +1
                                                                                      В таком случае я могу просто сказать что знаю что у Xamarin есть несколько очень жестко урезанных бесплатных вариантов, но это нельзя назвать полноценной некоммерческой бесплатной версией в том смысле в каком такие версии есть у Unity например или Visual Studio (даже до последних новостей)
                                                                        • +1
                                                                          на слайде за остальные платформы отвечает Xamarin.
                                                                      • +9
                                                                        Сперва посмотрел на календарь, убедился, что не первое апреля; не поверил; посмотрел на компе жены, убедился.
                                                                        Я шокирован и удивлен (приятно).

                                                                        Это значит, что WPF-приложения можно будет использовать на *nix?
                                                                        • +7
                                                                          WPF если и будет, то в самую последнюю очередь.
                                                                          • 0
                                                                            Технические причины к этому вижу, имплементировать его на базе *nix будет непросто.
                                                                            Интересно, есть ли именно намерения его в принципе имплементировать или дело в их отсутствии.
                                                                            • +3
                                                                              имплементировать его на базе *nix будет непросто.
                                                                              Им бы то, что есть открыть, там народ подтянется. Реализация Silverlight для Linux с рендерингом на OpenGL уже много лет существует.
                                                                              • 0
                                                                                *nix UI все же им не интересен, всю GUI кроссплатформенность отдали xamarin, похоже.
                                                                              • +1
                                                                                На самом деле не так уж и сложно. Там слой графики хорошо изолирован от собственно XAML и всего такого, и портировать надо в основном его (ну и работу с WM).
                                                                            • +1
                                                                              К сожалению отдельно сказано, что открыт и портирован на никсы будет только серверный сабсет (asp.net 5.0). На Wpf и winforms планов, как я понял, нет
                                                                              • 0
                                                                                А толку и нет, на самом деле. В десктопных приложениях на каждый чих winapi тянется. Не с winelib линковать же.
                                                                                • 0
                                                                                  То, что WinForms гвоздями прибит к WinApi это ясно, но я не очень понимаю, почему нельзя портировать Wpf? Wpf вроде не сильно завязан на WinApi. Кто-нибудь может прояснить ситуацию чайнику?
                                                                                  • +2
                                                                                    Дык есть реализация подмножества WPF, используемого в сервелате, Moonlight называется. Если открыть WPF и взять рендеринг из мунлайта, можно относительно малой кровью завести.
                                                                                    • 0
                                                                                      WPF-ное приложение можно запустить на линуксе под вайном с виндовым дотнетом? А то как-то фигово гуглится. С одной стороны, встречаются ответы «WPF под линуком не работает», с другой — в багтрекере вайна можно встретить исправленные баги типа «под .NET такой-то версии не грузятся картинки в WPF», что как бы намекает, что что-то работает (и в комментариях увлекательное чтиво — эпическая декомпиляция с анализом недокументированных методов в недокументированных интерфейсах).

                                                                                      WPF поторохами упирается в энное количество виндовых интерфейсов, как я понимаю, то есть при наличии сорцов WPF с одной стороны и вайна со всеми виндовыми поторохами с другой, портирование WPF становится уже не настолько фантастическим. Ну и линуксоидные стили прикрутить.
                                                                                      • +1
                                                                                        Под вайном сейчас можно хоть чёрта лысого запустить, но нативности, скорости работы и стабильности это чёрту лысому не прибавит.
                                                                                • 0
                                                                                  Для открытия и портирования winforms им, наверное, половину winapi портировать и открыть придётся.
                                                                                  • 0
                                                                                    Есть WinPR, можно на его базе что-то сделать.
                                                                                    • 0
                                                                                      А что мешает оставить существующие интерфейсы, а реализацию написать новую?
                                                                                      • +1
                                                                                        Подозреваю, что это долго, дорого и почти никому не нужно. Всё-таки winforms приложения не основной козырь .NET платформы.
                                                                                        • +2
                                                                                          Проблема в том, что в WinForms практически все классы — это обёртки к винапишным контролам. В Mono есть managed-реализация, но она местами хромает.
                                                                                    • +2
                                                                                      Вот уж надеюсь, что нельзя будет. Статья «7 лет WPF» уже сколько висит, уже далеко не 7 лет, а воз и ныне там.

                                                                                      Сделать бы аналог, с вменяемым синтаксисом и платформенной независимостью (раз уж как раз назрела необходимость) — цены бы не было. А портировать индусский код на линукс — не стоит. Насколько прекрасен Asp.Net, настолько ужасен WPF.
                                                                                      • +3
                                                                                        Сама идея с декларативным UI на XAML и MVP была хороша. Сейчас в Xamarin.Forms используется.
                                                                                        • +2
                                                                                          Возможность использовать имеющиеся приложения, написанные на WPF, где-либо, кроме винды — уже благо.
                                                                                          • 0
                                                                                            Есть GTK#. На нем Monodevelop написан, например.
                                                                                            Вот только не особо удобно его юзать, даже если прикрутить Glade.
                                                                                            Когда последний раз его тыкал, с небольшими костылями удалось сложный интерфейс вменяемо реализовать. На линуксах вышло отлично; на венде тема для gtk была на тот момент кривовата. Не уверен как сейчас.
                                                                                        • +7
                                                                                          Вау! Вот это поворот! :)
                                                                                          Не верится, что я до этого дожил! :D
                                                                                          Майкрософт в последнее приятно время удивляет! Еще бы сделали свободную реализацию для мобильных платформ (помимо виндафона) и будет просто БОМБА! ^____^
                                                                                          • +6
                                                                                            iOS и Android они на откуп Xamarin отдали же.
                                                                                          • –9
                                                                                            [тэг «диванная аналитика»]
                                                                                            Кмк, они увидели готовность рынка к приёму этого продукта и перспективу отжать у него (рынка) бОльшую долю.
                                                                                            Смотрите: несколько лет назад почти весь веб (кроме энтерпрайза и узких нишевых вещей) писался на PHP. Какие-то более суровые языки — ой, да зачем они нам? Изучать долго, инфраструктура сложнее и дороже… Оставим их большим корпорациям, а мы тут по-быстренькому на LAMP-е и замечательно. Поддерживать в таких условиях .NET под Линукс — это большой гемор, который в обозримом будущем не окупится.
                                                                                            Что сейчас? Народ избаловался, проникся любовью к плюшкам, новомодных технологий не чурается, железо подешевело. Всякие там питоны, руби, го, ноды, хаскелы-шмаскелы внезапно получили не только академическую, но и совершенно практическую популярность.
                                                                                            И почему бы не подвинуть их си-шарпом?!
                                                                                            • +7
                                                                                              Ну с вебом то особенно ничего и не поменялось. Все также большинство написано на том же пхп, а для некоторых узких целей используются другие языки, типа ноды и т.д.

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

                                                                                              Врядли кто-то будет писать простенький сайт с фоточками котов на Го или хаскеле, да даже на ноде врядли, оно просто незачем.
                                                                                              • +3
                                                                                                Хмм, а когда Haskell успел стать супер-популярным?
                                                                                                • 0
                                                                                                  Я где-то написал «супер»? Он стоит в перечислении последним, как дополнение общей картины.
                                                                                                  • 0
                                                                                                    Просто добавка «шмаскел» намекает на то, что на нем пишет каждый ребенок.
                                                                                              • +5
                                                                                                Это просто праздник какой-то!
                                                                                                • +5
                                                                                                  Ну это просто праздник какой-то! Больше слов нет, одни чувства =)
                                                                                                  • +5
                                                                                                    Восхитительно! Вот так корпорации зла становятся корпорациями добра :)