Гуру велосипедостроения
0,2
рейтинг
12 ноября 2014 в 20:46

Разработка → .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
Никита Цуканов @kekekeks
карма
31,5
рейтинг 0,2
Гуру велосипедостроения
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (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 я не знаю.
                • 0
                  Mono?
        • –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/не гну.
          • 0
    • +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
    Восхитительно! Вот так корпорации зла становятся корпорациями добра :)
  • +3
    Теперь халтурка и под linux будет у меня…
  • +19
    В стане джавистов аж всем поплохело )
    • +10
      Не поплохело :) Наоборот, джависты всячески приветствуют эту тенденцию. Наконец-то народ начнёт понимать внятно, как внутри оно работает. Ещё лет 5 чтобы догнать рантайм Java и еще лет 10, чтобы отвоевать долю рынка. По фичам языка дотнет — впереди. По фичам рантайма — впереди джава.

      В общем, и я и все мои знакомые джависты очень рады за вас! Поздравляю!
      • +5
        Это по каким таким фичам рантайма впереди джава? Что, неужели там генерики появились? Value Types? App Domains? Ngen? RyuJIT?
        • +4
          • Value Types — принято. Но на худой конец, кому очень нужен перфоманс, вопрос решается массивами.
          • App Domains — не принято: не понимаю, что в этом такого особенного
          • Ngen — принято: хорош для клиентских приложений. Для серверных не принципиален. Но фича интересная.
          • RyuJIT — не принято. Да, он лучше чем предыдущий, но непонятно, как он выглядит на фоне JIT-ов для HotSpot или других JVM.


          • 0
            Ограниченные привилегии куску кода. Компиляция в SIMD есть?
            • 0
              привилегии куску кода
              AppDomain
              Компиляция в SIMD есть?
              Mono.Simd
              • 0
                Дак я спрашиваю про джаву. И RyuJIT умеет сам в SIMD.
                • 0
                  SIMD есть, конечно. Особенно в последних версиях JVM. Но есть тонкости: на целой арифметике оно работает, а вот на вещественной нет. Потому что вещественная арифметика в Java не ассоциативна. И при анроллингах не получается переупорядочить последовательные сложения.
                • +1
                  про привилегии: надо смотреть, как устроена Java Security Model. Там каждый кусок кода может требовать определённые пермиссии. И если SecurityManager их не даёт, то летит исключение времени выполнения.
        • +4
          Видимо, имеется ввиду HotSpot VM с его адаптивной оптимизацией кода (горячие участки проходят более дорогую и продвинутую оптимизацию) и особым, уличным GC.
          • +1
            много, много всего. Я не спец по дотнету, но из того, про что в дотнете сходу не помню — Biased Locking, on stack replacement. Но самое интересное — это, конечно, JIT. Фишка в том, что он очень разный. Только в HotSpot 2 JIT-компилятора, а в других VM — тоже есть свои. И это видно: на разных JVM очень разные сценарии частенько получаются. Ну и с GC та же история. Сейчас в продакшенах по всему миру трудится десяток разных GC :)
            • +2
              On stack replacement к дотнету не применим в принципе, весь прогоняется через JIT всегда (если до этого не обработан NGen или Mono-вским AOT-компилятором, конечно), интерпретатора нет (единственный интерпретатор MSIL о котором я слышал использовался в Mono на заре проекта). С мониторами тоже проблем нет, они практически бесплатны если не заняты другим потоком. JIT же сейчас переписывается с большим прицелом x64 (шёл 2014-ый год, да)
              • +1
                • про x64 забавно, да :))) Легаси оно такое легаси...
                • про On stack replacement — интересно! Расскажите, плиз!
                • про мониторы понятно, наверняка почти ничего не стоит без контеншена и спинлупы в промежуточном случае
                • про JIT и GC — мой «упрёк» в том, что мало разнообразия. И настроек кстати немного.


                Слушайте, а как дела обстоят со спекулятивными оптимизациями?
                • +3
                  про On stack replacement — интересно! Расскажите, плиз!
                  Ну, если я всё правильно помню, то в Java оно нужно в случае, если рантайм решает, что метод надо бы уже скомпилировать, а он на данный момент выполняется и выполняться будет ещё долго. В .NET компиляция в машинные коды производится при первом вызове. Это же и его недостаток — JIT вынужден применять ко всему коду один и тот же набор оптимизаций, а не заниматься глубокой оптимизацией конкретного участка.
                  • +2
                    почти. Может быть так: от менее оптимизированного JIT-кода к более оптимизированному. То есть от скомпилированного к скомпилированному. Но вообще, да, видимо в дотнете компилируется один раз и поэтому не актуально.

                    А что с Escape Analysis?
                  • 0
                    А можете пояснить, это какая-то особенность .NET, или возможна какая-то другая релизация JIT, которая будет использовать отложенную компиляцию кода, например как в Java?
                    • +2
                      Так реализовано как в CLR, так и в Mono, в принципе, ничто не мешает сделать иначе, просто не было особой нужды ввиду изначального отсутствия интерпретации кода.
                      • 0
                        23derevo вы случайно не знаете, есть ли какая-нибудь статистика по тому, какой прирост производительности даёт подобная фича в Java(имеется ввиду отложенная компиляция)?

                        Я просто не могу понять почему MS её не реализовало? Это дорого? Это того не стоит? Лень поддерживать две версии JIT?
                        • 0
                          У меня подозрение, что так исторически сложилось, в Java изначально был интерпретируемый байткод, в .NET изначально JIT-компиляция.
                        • +1
                          Дорого и легаси. Сделать такой JIT, чтобы он на всех сценариях какой-то другой — не выйдет. Даже приближение к этому — это много-много лет работы. Если же просто заменить один JIT на другой, то у многих кастомеров начнятся деградация производительности. Они начнут гнать на майкрософт, а майкрософт этого не хочет.
                          • 0
                            Я не очень понял аргумент насчет легаси, возможно же создание нового JIT не вместо, а как альтернатива уже имеющемуся. Т.е. по-умолчанию пусть работает как есть, а для продвинутых можно использовать другю опцию.
                            • 0
                              Это правда. Но тогда придётся поддерживать два джита. А это дорого.
                              • +1
                                RyuJIT именно это из себя и представляет — альтернативный джит. И ничего, поддерживают. Понятно, что в перспективе он станет основным.
                                • 0
                                  Это не «альтернативный JIT», это следующая версия. Просто его переписали с нуля и пафосно назвали. Насколько я понимаю, новый JIT целиком и полностью заменяет старый во всех областях применения, и причин использовать старый не будет.
                                  • 0
                                    Так вроде об этом и разговор выше по треду — что новый улучшенный JIT можно изначально зарелизить как альтернативу, чтобы не ломать легаси (как это и сделали для RyuJIT), а потом уже назначить его основной реализацией, и дропнуть старую еще через релиз.
                                    • 0
                                      Так будут две версии сосуществовать или нет? Я думал, что к релизу старый JIT выпиливают и RyuJIT полностью его заменяет, то есть они сосуществуют только на стадии беты, когда никакой масштабной поддержки не надо, только баг-трекер для энтузиастов.
                                      • 0
                                        Думаю, происходит как с различными API — в новом релизе старое помечают как deprecated, а в следующем уже выпиливают. Т.е 2 версии сосуществуют лишь в одном релизе, который будет переходным.
                                      • +1
                                        В .NET 4.6 RyuJIT по умолчанию (т.е. уже не бета), но старый пока оставили как опцию. В перспективе — да, его тоже выпилят когда-нибудь, но некоторое время будет поддержка обоих.
                      • 0
                        Мне доводилось слышать мнение, что джавский байткод изначально затачивался под эффективный его интерпретатор, а вот в дотнете такой задачи не ставилось, поэтому там его дизайн не шибко этому способствует.

                        Не берусь сказать, в чем именно это проявляется, но слышал я это от человека, занимающегося VM в .NET.
                    • –2
                      Как вариант, можно предварительно скомпилировать код, один раз сделал и все.
                      А вообще, со скорым приходом нативной компиляции о JIT можно будет не париться)
                      • 0
                        Часть кодогенерации всё равно останется в рантайме. Например, дженерики компилируются на каждую специализацию, да и генерация MSIL во время выполнения сейчас весьма активно используется в сериализаторах, ORM, DI-контейнерах и прочих инфраструктурных вещах.
                      • +3
                        Конечно же нет. Глубокий инлайнинг и оптимизации на основе динамического профиля. То есть, на основе статистики вызываемого кода. Например, есть целый класс спекулятивных оптимизаций, которые ahead-of-time компиляторы не могут сделать.
  • 0
    Mono жалко
    • +2
      Не похоже, что они сами себя жалеют.
      • 0
        Ну как, в комментариях же внизу написано, что «Пока .NET не заменит Mono везде, где оно работает, Mono будет существовать». Не слишком радужно, что уж и говорить)
        • +1
          Мигель вроде бы объяснил, что .NET не планирует заменять mono, активно будет совместно дорабатываться (до кроссплатформенности) только .NET Core, а .NET Framework Class Libraries останутся win-only, а mono оттуда надергает на замену того, что было еще недоделано.
        • 0
          Xamarin едва ли уйдет с mono в ближайшее время.
        • +2
          MSFT заявили что они активно работают совместно с Mono чтобы смерджить код. Вангую что через n лет люди из Mono просто мягко перетекут в MSFT и продолжать делать то что делали.
          • +1
            Пока движение в другую сторону: Xamarin покупает разработчиков из MS
  • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • +7
      Там ещё компиляцию в нативный код обещают. Так что если переход на C был обусловлен требованиями производительности, можно возвращаться.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        А сейчас во что компилируется? Не в нативный код?
        • 0
          В MSIL, который на целевой машине уже JIT компилирует.
          • 0
            А, типа AOT. Понял. И почему же это так волшебно улучшит производительность?
            • 0
              Потому что в рантайме не будет затрат на JIT. Как минимум, должно ускорить запуск приложений.
              Но overhead на GC и всякие проверки границ массивов останется, разумеется.
              • 0
                Не серверах время запуска по барабану.
            • +1
              У JIT есть ограничения на время работы из-за которых нельзя делать агрессивно оптимизацию. В случае со статической они снимаются.
              • 0
                Ну если в данный момент JIT в C# компилирует без профиля, то да, оффлайн должен улучшить производительность. Хотя без спекулятивного инлайнинга, переупорядочивания бранчей и прочих оптимизаций, основанных на профиле, как в Java и С/С++, не говоря уж об оверхеде рантайма и GC, не понятно, о каком возврате на C# с C можно говорить.
                • +1
                  Ну PGO-то должны прикрутить, если уж AOT делают.
                  • +2
                    Если прикрутят, перейду с Java на C# :)

                    Кстати, интересно, что в C# с гарантиями точности трассировки стека? Ведь есть штучки, которые AOT «не имеет права», скажем так, оптимизировать, например.
                  • +1
                    В .NET Native для генерации кода используется бэкенд от VC++, если что.
      • +1
  • +1
    А рассматривать внутренности, а конкретно работу с кодировками, то как, интересно, будут обстоять дела в MS .NET под *nix? В Mono, понятное дело, везде внутри используется utf-8 для хранения строк, даже методы маршаллинга вроде Marshal.StringToHGlobalAnsi на самом деле на выходе дают utf-8. Как все это будет шевелиться, интересно)

    В любом случае для порта на *nix придется проделать большую работу по абстракции от платформы в mscorlib как минимум…
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      В Mono, понятное дело, везде внутри используется utf-8 для хранения строк
      Внутри используется UCS-2. При передаче во внешний код да, там идёт перекодирование.
      • 0
        Внутри класса String так и есть, а для различных путей, параметров командной строки и прочего внутри используется utf-8.
  • +3
    Волшебно, конечно. Но пока только щелочку приоткрыли. До полноценного кодирования на .net под никсами еще лет пять, наверное.
    • +5
      Под никсами лет пять. Под никсы — полгода-год. Ну и MonoDevelop никто не отменял, он вполне себе рабочий.
      И вообще у меня Mono уже лет пять в продакшне.
  • +1
    Наконец-то не только Java разработчиков будут мучать вопросами по внутренней реализации коллекций, многопоточности и прочего. На самом деле это хорошо, готовьтесь, коллеги :)
    • +5
      да, я лично уже потираю руки, предвкушая больше (БОЛЬШЕ) хардкора на апрельской .NEXT в Питере!
  • +3
    Три раза дату перепроверил. Это невероятная новость и очень неожиданная, хоть и одна из самых желанных. Времена меняются и эти перемены радуют.
  • 0
    Супер. Не терпится попробовать :)
  • +3
    Это конечно безумно радует. Но не понятна мотивация.
    MS давно пытается отвоевать рынок серверов. И .Net был на мой взгляд самым существенным аргументом.
    Если он будет портирован в хорошем качестве (все понимают что в mono в разы больше багов и производительность заметно ниже), то это должно ударить по продажам Windows Server. Как-то это странно.
    Вспоминается комментарий Спольски про самоубийство Sun, зарабатывавшей на серверах, но выпустившей кросплатформенную Java.
    Не повторит ли MS её путь?
    С другой стороны если MS сконцентрируется на том, что ей удаётся хорошо, и уйдёт с поляны Open Source, да ещё оставив миру такую потрясную вещь как .NET, то это будет замечательно. Для всех кроме самого MS.
    • –1
      У MS огромная проблема с разработчиками в мобильном и серверном сегменте. Думаю, немало народа обожглись, вкусив их бездумную политику vendor lock-in'а, ну и синдром Not Invented Here сыграл свою злую шутку, что мало кто хочет с ними связываться, тратить время на изучение технологии, которую могут очень легко ещё живой и здоровой похоронить на уровне менеджмента, и технология, таки, умрёт в этом гробу, т.к. сообщество форк не сделает по причине закрытого кода. Если так будет продолжаться и дальше, хуже для компании в условиях меняющегося рынка не сделаешь.

      Видимо, дела идут совсем плохо, что MS решила отдать .NET в open source. Возможно, решат сосредоточиться на более перспективных направлениях, чем Windows Server (опять же, крупные компании никуда не денутся, т.к. им нужен enterprise со всеми вытекающими), например, будут прокачивать облачный сегмент со своей Azure.

      Так у них хоть есть шанс заинтересовать разработчиков своими технологиями. Особенно в мобильной среде. А может, здесь и хитрый план есть, по завоеванию мирового господства, который пока ещё неясен. Посмотрим.
      • +4
        Извините, но у вас комментарий в стиле давно известной олимпиады «венде скоро капец».

        Дела идут у MS вполне себе неплохо, а уж в плане развития .NET они вообще впереди планеты всей. IDE — одна из лучших, C# — самый развивающийся язык программирования. Виндовыми серверами как пользовались так и пользуются и не обязательно большой энтерпрайз: мелкий и средний бизнес также им пользуется — стоимость поддержки все еще ниже чем линукс. Плюс, с webmatrix, хостить всякий пэхэпэ стало делом нескольких кликов.

        У Микрософта интересная стратегия — помимо своей инфраструктуры, они активно лезут на поля конкурентов. Запилили офис на Android и iOS, теперь вот дотнет портируют. Хитрый план.
    • +3
      не понятна мотивация
      Embrace, extend, extinguish?
  • +1
    Чувствую коммюнити скоро начнёт находить кучу багов в открытых исходниках.

    бесплатная редакция Visual Studio с поддержкой расширений;
    Вот это замечательно.
    • +4
      Что мешало это делать раньше? для просмотра исходники открыты давно.
  • +7
    Я кончил.
  • 0
    Может тогда и SQL Server с SSAS в openSource? А вдруг? Ну или хотя бы olap движок вынести в отдельный открытый продукт.
  • +1
    techrights.org/2014/11/12/openwashing-lockin/
    Если верить анализу по этой ссылке, то не все так радужно. Во-первых, открывают не весь фреймворк, а только его часть.
    Во-вторых, «студия бесплатна для скачивания» это не то же, что «опенсорс».
    • +2
      А зачем опенсорсовая IDE? Для расширения функциональности есть плагины. Даже если среду заопенсорсить, то 99% кода всё равно будут писать в Майкрософте. Риска, что забьют на разработку, нет. Разработка тесно переплетена с кучей проектов.

      Если от заопенсорсивания языка профит очевидный, то среды — уже не очень. Майкрософту, соответственно, тоже невыгодно впустую тратить ресурсы.
      • +3
        там опенсорс только серверных компонентов. десктопный .NET остается закрытым.
        • +1
          Десктопный код сильно завязан на winapi и портировать его нереально дорого.
          Ждем опенсорсных разработок и портов WPF :)
          • 0
            Я так и не понял, собираются ли мелкомягкие открывать код WinForms и WPF под MIT. Если откроют, то WPF и без MS портируют. WPF завязан на виндовый API, но всё-таки на графические функции и прочие нейтральные приблуды, а не является тонкой обёрткой над нативными контролами как WinForms.
            • +1
              Не собираются пока. Я спрашивал вчера на конференции мне сказали дословно: «Пока не планируем, но идея хорошая.»
              • 0
                Жаль. Для полного опенсорсного экстаза только этого не хватает. Ну, будем надеяться на лучшее.
    • 0
      Открывают весь фреймворк, просто не сразу. Постепенно выкатят все.
      • 0
        Видимо за некоторые комментарии в коде стыдно. Вот почистят и… :)
        • 0
          Комментарии уже чистили, когда выкладывали сорцы под Ms-RSL.

          sourceof.net

          Некоторые забавные комментарии выживали, надо сказать. И в основном чистили, вроде, чтобы не палить уязвимости.
  • 0
    Давно пора.
  • 0
    Как-то непоследовательно…
    При разработке энтерпрайз приложений на. Net под Линукс вместо MS sqlserver предполагается использовать постгре? Или они предполагают не потерять продажи серверов базы данных?
  • 0
    Эта новость сделала мой день.
    • –2
      Same :)
      • +1
        палите какую-то голосовалку )
        Скрытый текст
        ... jQuery17201666310257698811_1415889108864({«cmd»:«vote»,«status»:«ACK»,«data»:{«questionaryId»:«197»,«scheduleId»:«194»,«questionId»:«20644»,«uniqueType»:«4»,«voteType»:1,«rate»:«22»}})
        • 0
          Это ж мылору. Чего от них еще ожидать.
  • +3
    Что интересно, на мой взгляд Mono давно уже более «каноничен», чем .Net. Задумайтесь, в .Net для Windows Store/Windows Phone уже нет System.Xml, System.Data, System.Drawing, изменена работа с System.IO, нельзя подключить библиотеки от «нормальных» .Net 2-4.5. И все это, чтобы «было удобнее разрабатывать».
    • 0
      Гм… Да, в текущем виде ситуация печальная, я как бывший разработчик Windows Store/Windows Phone говорю. Но, .NET сделался таким по многим причинам. Портировать весь .NET на планшеты (ARM) и телефоны нереально и в общем-то не особо нужно. Т.е. да многих фич не хватает, но когда нужные добавят то останется еще куча фич, которые есть в десктопном .NET, но которые не нужны на планшетах и телефонах.

      По поводу System.Xml ничего не знаю, но с сериализацией/десериализацией в XML и JSON проблем не было.

      В Windows RT практически весь UI реализован нативно (для скорости, естественно), а .NET видит только интерфейсы к ним. Предлагает тащить туда GDI+, Windows Forms и WPF? System.Drawing не нужен

      В PCL нету System.Data и вы считаете это ужасным? Вы правда хотите написать мобильное приложение которое напрямую общается с удаленным SQL Serverом? Поддержка SQlite в Windows Store/Windows Phone есть (возможно кривая).

      Изменена работа с System.IO, банально потому что часть фич не нужна (потому что слоупочно и никому не нужно); потому что работа с файловой системой другая (заточенная на больший контроль за приложением).

      Так же изменено API для работы с рефлексией.

      Вы сейчас видите изменения которые происходят с .NETом. И это:
      1) Портирование .NET фич на другие платформы в порядке приоритета и необходимости.
      2) Рефакторинг кода
      3) Удаление старого ненужного кода.
      • +2
        Погодите, я не утверждал, что работать в таком формате нельзя. Вполне можно, почему бы и нет? Но если в библиотеке не сделан велосипед вроде собственного Rectangle и Point, то большая вероятность, что она использует System.Drawing и без перекомпиляции работать не станет. Или если где-то вдруг был задействован File.ReadAllText, XmlDocument, а к базе был коннект через System.Data.SQLite, а не самописный враппер над нативными вызовами, то будут проблемы. О не совместимости Silverlight/WPF кода с Windows Store я вообще молчу.

        В то же время на Mono уже 5 (!!) лет пишутся программы для Android и iOS, к любой из которых можно подключить готовые части кода и библиотеки из мира .Net. Хотите архивацию ZIP — берете в чистом виде ICSharpZipLib, хотите ORM — берете NHibernate, нужна работа с базой — берете коннектор вроде System.Data.SQLite или любой другой. По большому счету портирование десктопных .Net приложений там было задачей замены и переработки GUI, а не перехода на целиком другую технологию (хотя это и не самый лучший путь на мой взгляд). В стане же Windows Store для работы c SQLite первые пол-года вообще не было ничего схожего с базами данных, пока сами SQLite не собрали с грехом пополам враппер. Вдумайтесь, нам предлагали делать W8 приложения без локального хранения структурированных данных вообще!

        Я рад, что над фреймворком работают, развивают его. Но одновременно хочу рассказать историю про некий кросс-платформенный движок: во время аудита его C++ исходников мы удивились, что не использованы в принципе STL, Boost, не говоря о QT, wxWidgets и пр. Все, что можно и нельзя написано с нуля. Автор ответил просто: не хотел заморачиваться совместимостью с разными версиями STL от STLPort, Dinkum, SGI и пр., потому для настоящей кросс-платформенности сделал все сам, с иерархией дефайнов, подключаемыми на разных платформах файлами и пр.
        Так вот, сейчас для приложений мобильная бизнес-логика на C# для Android, iOS и WP/W8 выглядит именно так — куча велосипедов, гроздья дефайнов, дополнительные файлы именно для WP8/W8, где, например, сделана имитация System.Console.WriteLine через Debug.WriteLine и т.д.
        • 0
          В тему
  • 0
    Новая бесплатная редакция Visual Studio с поддержкой расширений;

    Цитата по ссылке:
    This edition of Visual Studio is available at no cost for non-enterprise application development.
    • 0
      Для компаний с <250 сотрудников и <$1KK дохода в год.
      • 0
        И правда. Но только 5 пользователей. Подробности тут. Может стоить это в статью вставить?

    • +1
      И? Если у вас 250 компов и миллионы дохода, в чём проблема платить?
  • +6
    Люди, как правильно произносится RyuJIT?
    • +5
      РюДжит.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.