semen_grinshtein 20 окт 2016 в 19:30

Каковы перспективы у «немодной» платформы .NET — мнения экспертов

9 мин

47K

.NET*ASP*C#*

+33

127

Комментарии 127

ad1Dima 20 окт 2016 в 20:33

Странные вбросы про потребление памяти. В сравнении с чем? с С++? ASM? Мне казалось, что эта тема была закрыта лет 10 назад.

Dywar 20 окт 2016 в 20:52

Когда в ноутбуке на редкость было 4гб :)
Сейчас магазин DSN ноутбуков 1051шт, из них с памятью 4гб и выше — 857шт, а это 82%.

ad1Dima 21 окт 2016 в 04:13

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

tangro 21 окт 2016 в 10:26

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

Pakos 21 окт 2016 в 11:00

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

Dywar 21 окт 2016 в 21:16

Каждый день по терабайту отъедаю :)

Дело не в том как кто пишет, что и зачем. А в том что острота вопроса уже не та что 10 лет назад.

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

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

zenkz 21 окт 2016 в 01:05

Да, зря на .Net бочку катят за использование памяти. К тому же часто проблема использования памяти — это не проблема языка, а проблема конкретного кода и алгоритмов.

Посмотрите к примеру на любой современный браузер. Firefox с радостью съедает 2-3 Гб памяти всего с 10-15 открытыми вкладками. Вот уж где нужна оптимизация.

Dark_Daiver 21 окт 2016 в 10:36

>К тому же часто проблема использования памяти — это не проблема языка, а проблема конкретного кода и алгоритмов.
Ну строго говоря нет. Язык может быть построен на принципах, которые трудно или невозможно реализовать без оверхеда (или грязных трюков).
Гипотетический язык с «честной» динамической типизацией будет априори проигрывать гипотетическому языку со статической типизацией (по производительности и потреблению памяти), к примеру.

DizelGenerator 20 окт 2016 в 22:40

С возросшими объемами памяти в устройствах (ноутбуках, серверах) разработчикам .NET нынче не приходится заморачиваться особенностями ее использования, оттого и низкая их квалификация, и качество кода становится поистине ужасным. «Кодируй, как получится, все равно будет работать». Это и плюс (скорость разработки, ниже порог вхождения), и минус (непродуманно написанное приложение рано или поздно все равно сожрет всю память объектами GC2).

Splo1ter 20 окт 2016 в 22:57

Ниже чем что? (Про порог вхождения)

Anarions 20 окт 2016 в 22:57

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

Anarions 20 окт 2016 в 23:26

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

ennui 20 окт 2016 в 23:40

Это не замечаение, это вброс на три с минусом.

Anarions 20 окт 2016 в 23:52

Вброс на три с минусом — говорить о том что из-за GC «качество кода становится поистине ужасным»

ennui 20 окт 2016 в 23:55

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

Anarions 21 окт 2016 в 00:05

И именно это я и сказал двумя комментариями выше.

ennui 21 окт 2016 в 01:54

Так как управлением памяти не надо замарачиваться- .net программисты = фиговые програмисты, а все остальные дартаньяны. Вот что вы сказали

senya_z 21 окт 2016 в 02:10

Вы точно не путаете обсуждаемый коментарий с коментарием, на который он был ответом? Потому что лично для меня

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

и

«Качество кода становится поистене ужасным, когда его пишет поистине ужасный кодер вне зависимости от языка и платформы.»

несут примерно одинаковую смысловую нагрузку, хоть и с разной эмоциональной окраской.

Anarions 21 окт 2016 в 06:35

У меня есть ощущение что я лучше знаю что я сказал. То что вы поняли — уже другой вопрос.

ennui 21 окт 2016 в 08:48

извините, каюсь, не посмотрел на коментатора и не ложидал ответа самому себе, ох уж эти древовидные коментарии.

0xdedc0de 29 сен 2021 в 10:50

Ой, не поверите какие исключительные «шедевры» пишут!
А по существу, говнокод он не от языка зависит, ~~если это не perl~~, а от того места которым некоторые авторы думают, а еще у них бывает и руки прямо из него ростут.

Anarions 29 сен 2021 в 18:13

Прошло всего 6 лет.

Кстати, интересно видеть прогресс платформы с тех пор

0xdedc0de 29 сен 2021 в 20:59

Интересно что на хабр не заходил уже года 3-4, комментарий был написан 6 лет назад и ждал своего апрува до сегодняшнего дня))

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

mezastel 21 окт 2016 в 00:00

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

Serginio1 21 окт 2016 в 10:37

Есть Avalonia Пока правда pre, но развивается

mezastel 21 окт 2016 в 10:39

Ну, с UI реальная проблема — по идее, нужен портативный WPF, но Microsoft завязали его на аппаратное ускорение, что не очень переносимо.

Serginio1 21 окт 2016 в 11:05

На DitectX. Вин фоны тоже поддерживают DitectX. Но вот XAML есть и на Xamarin http://metanit.com/sharp/xamarin/2.4.php

Надо подождать NetStandard 2 и следующей версии .Net Core

kekekeks 21 окт 2016 в 12:29

Скажите, а зачем вам нужен NetStandard2? Чего именно не хватает в 1.1?

Serginio1 21 окт 2016 в 12:38

Ну 1.1 еще нет. А вот в 1.01 очень многого нет. Смотрим дорожную карту

kekekeks 21 окт 2016 в 13:16

Кого нет? Профили сборки .NETStandard вплоть до 1.6 доступны (карта поддержки оных фреймворками есить по же ссылке из предыдущего комментария), мы уже пользуемся. По последней ссылке дорожная карта .NET Core.
Не надо путать наборы API (NETStandard, PCL) и целевые платформы (.NETFX, Mono, .NET Core)

Serginio1 21 окт 2016 в 13:57

Так в .Net Core не хватает кучи классов. Нет WCF, SignalR и еще кучи классов. Библиотек под NETStandard раз два и обчелся. И в Итоге то .Net Core 1.2 и будет совместим с NetStandard 2

Planned 1.2 features
•.NET Standard 2.0 support, bringing .NET Core to parity with .NET Framework and Mono for a large collection of base types.

Notes:

•The 1.0 release is accompanied with a preview version of the Visual Studio and command-line tooling. The Visual Studio tooling for 1.0 through 1.2 based on MSBuild and csproj should be publicly available in Fall 2016 and reach RTM quality in Spring 2017.

kekekeks 21 окт 2016 в 14:08

А как .NET Core 1.2 связано с UI и аппаратным ускорением графики и зачем для этого ждать NETStandard2.0? .NET Core в текущем своём виде мало полезен, пока на этот самый NETStandard не перенесут все библиотеки.

От профиля сборки NETStandard же польза вполне определённая вот уже сейчас: единый бинарник для NETFX, десктопного Mono, WinPhone и Xamarin-овских мобильных платформ. Мы сами на него хотим переносить авалонию, но нам для этого за глаза должно хватить 1.1, там всё нужное есть.

Serginio1 21 окт 2016 в 14:18

Ну например я хотел поработать с XML Schema, SignalR, WCF, а их пока нет. Авалония пока в альфе. Хотел к Xamarin прикрутить NetStandard пока не получилось. Там как раз и проблема с кучей профилей. А когда 1.1 то вышел. Вот NET Core 1.0.2 И то там инсталятор для IOS подправлен

1.1 там только исправления. То, что можно использовать и 1.0 не спорю, но с 1.2 это делать будет значительно проще

kekekeks 21 окт 2016 в 14:19

Вы сейчас путаете версии .NET Core и .NETStandard. Это разные вещи.

Serginio1 21 окт 2016 в 14:30

.NET Core это Фреймворк.
Но в .NET Core 1.2 есть поддержка NETStandard2
А в NetStandard 2 поддержка большего количества классов
Я то как раз и использую библиотеки под NetStandard https://habrahabr.ru/users/serginio1/topics/

Опять же, что касается профилей PCL https://docs.microsoft.com/en-us/dotnet/articles/standard/library

Мы говорим NetStandard 2, подразумеваем .Net Core 1.2

kekekeks 21 окт 2016 в 14:32

Мы говорим NetStandard 2, подразумеваем .Net Core 1.2

Вот не надо одно с другим перемешивать, это вызывает ненужную путаницу.

Serginio1 21 окт 2016 в 14:35

Так .Net Core 1.2 бессмысленен без NetStandard 2. А NetStandard 2 это стандартная библиотека для всех .Net Фреймворков. Поэтому основой то как раз и является NetStandard 2.
Прошу прощения, если неправильно выразился.

kekekeks 21 окт 2016 в 14:39

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

Serginio1 21 окт 2016 в 14:47

Угу вместо кучи профилей, при смене которых все ломается будет 1 профиль.
Да и с выходом NetStandard 2 появится больше библиотек под него, так как он будет уже совместим со всеми Фреймворками. Сейчас выгоднее делать под PCL, а вот они не все совместимы с .Net Core

kekekeks 21 окт 2016 в 14:51

Да и с выходом NetStandard 2 появится больше библиотек под него, так как он будет уже совместим со всеми Фреймворками.

Вообще-то нет. Чем ниже версия .NETStandard, тем больше фреймворков с ним совместимо. Чтобы быть совместимым с .NET 4.5 нужно использовать .NETStandard1.1, например, более поздние версии .NETStandard с .NET 4.5 не совместимы.

Serginio1 21 окт 2016 в 14:57

Здесь главное не совместимость, а возможности. Кстати в NetStandard 2 они откатились до 4.6.1. Сейчас то под NetStandard очень мало библиотек

kekekeks 21 окт 2016 в 14:38

Хотел к Xamarin прикрутить NetStandard пока не получилось.

В августе поддержку выпустили же.

Serginio1 21 окт 2016 в 14:42

Я знаю. По этой статье и хотел прикрутить, но что то не получилось.

VioletGiraffe 21 окт 2016 в 13:35

А кому он нужен без UI, осмелюсь спросить? Кроме серверного back-end, конечно. Какой же это мейнстрим, если клиентские приложения можно писать только под Windows?

kekekeks 21 окт 2016 в 14:18

Ну во-первых, есть универсальная обёртка с поддержкой XAML над нативными для платформ фреймворками (набор контролов достаточно богатый, сейчас вот заснял как оно с GTK-бакэндом на убунте выглядит). А что касается аналога WPF с полностью своим рендерингом, то мы работаем над этим.

VioletGiraffe 21 окт 2016 в 14:35

Спасибо, это очень интересно. WPF или нет — это уже не так важно, ИМХО. Я даже люблю, когда на разных платформах одно и то же приложение выглядит нативно.

Serginio1 21 окт 2016 в 14:48

Спасибо! Интересно.

Serginio1 21 окт 2016 в 21:37

Я не думаю, что для MS интересно делать WPF кроссплатформенным учитывая процент декстопов на котором стоит Windows.
А вот для мобильных устройств будут развивать Xamarin Forms.

А вот для серверов WPF не нужен, а интересны им юниксы линуксы именно из-за облаков.

yarric 21 окт 2016 в 18:03

Язык C# прекрасен, лучшего мейнстрим языка пока нет.

Что думаете о Swift?

mezastel 21 окт 2016 в 18:05

Очень нравится. Серьезно, продуманный язык, вот так сходу придраться не к чему, но с другой стороны я на нем не пишу. У Swift и C# одна проблема — кроссплатформенный UI. Ну, у Swift еще проблема что Windows этому языку амбивалентен, но у нас сейчас и порты есть, и Ubuntu под Linux стоит, так что проблемы вроде особой нет.

robert_ayrapetyan 21 окт 2016 в 00:33

Есть некий кровавый ынтырпрайз проект 16-летней давности на classic ASP. С начала 2016 года вдруг взялись все переписывать на .NET 4.6, а тут как раз вышел .NET Core (сырой и недоделанный), а ведь остальные .NET-ы прикажут долго жить к моменту, когда проект будет полностю переписан. Как быть камрады?

ZOXEXIVO 21 окт 2016 в 00:53

Вашему enterprise так необходим .NET Core? Вы думаете, там другой диалект C#?

robert_ayrapetyan 21 окт 2016 в 15:33

Еще хотят засунуть все это в Azure, и типа там .NET Core более применим (во всяк. случае MS об этом кричит, маркетинговая замануха или реальность?)

ZOXEXIVO 21 окт 2016 в 15:57

.NET Core это не новый C# и ничего «учить» там не нужно. Просто другой способ дистрибуции вашего приложения, такое микроядро с подключаемыми модулями.
Основная сложность в портировании — исключение Windows-специфичных вещей из своего приложения. Если это жесткое legacy, то скорее всего все будет плохо.
В Azure очень важно кнопочкой быстро создать виртуальную машину и быстро ввести ее в действие. Windows Nano Server + .NET Core позволит за считанные секунды развернуть новую виртуалку задеплоить на нее ваше приложение, которое, к тому же, быстро начнет работать.

robert_ayrapetyan 21 окт 2016 в 16:15

Ну с C# то как раз понятно, непонятно на чем щас переписывать classic ASP проект с нуля — на .Net Core или .Net 4.6, если все это хотят тут же засунуть в Azure?

ZOXEXIVO 21 окт 2016 в 16:29

Вам нужно просто переделать его на ASP.NET Core.
net46 или netcoreapp1.0 выбирается в конфиге.

Serginio1 21 окт 2016 в 16:35

Я уже давал ссылку на бенчмарки

Кроме того несложно перенести проект на Asp.Net Core Портирование большого проекта на .NET Core

Так или иначе .Net Core будет развиваться бОльшими темпами. За ним будущее.

kekekeks 22 окт 2016 в 01:36

Так там производительность не за счёт .NET Core вместо .NETFX, там производительность за счёт libuv и более легковесного пайплайна обработки запросов.

Serginio1 22 окт 2016 в 11:17

Ну там весь Asp.Net Core переработан Microsoft.AspNetCore.Server.Kestrel

kekekeks 22 окт 2016 в 19:53

Я вам по секрету скажу, что Kestrel — это всего лишь OWIN-совместимый сервер и ASP.NET Core можно при желании завести поверх IIS integrated pipeline (прямо как старый, да)

Serginio1 22 окт 2016 в 20:42

По ссылочке

AspNetCoreModule
Хостирование приложений ASP.NET Core на IIS происходит с помощью нативного модуля IIS под названием AspNetCoreModule, который сконфигурирован таким образом, чтобы перенаправлять запросы на веб-сервер Kestrel. Этот модуль управляет запуском внешнего процесса dotnet.exe, в рамках которого хостируется приложение, и перенаправляет все запросы от IIS к этому хостирующему процессу.

При этом
Публикация на IIS

Традиционно веб-сервер IIS (Internet Information Services) применялся для развертывания веб-приложений. Для хостирования веб-приложений ASP.NET Core также может применяться IIS, только в отличие от предыдущих версий ASP.NET теперь его роль будет сводиться к прокси-серверу. Хостирование приложений ASP.NET Core на IIS происходит с помощью нативного модуля AspNetCoreModule, который сконфигурирован таким образом, чтобы перенаправлять запросы на веб-сервер Kestrel. Этот модуль управляет запуском внешнего процесса dotnet.exe, в рамках которого хостируется приложение, и перенаправляет все запросы от IIS к этому хостирующему процессу.

При этом пул приложения выбирается

В открывшемся окне для параметра Версия среды CLR .NET установим значение Без управляемого кода:

kekekeks 22 окт 2016 в 20:59

Я рад за ваши ссылки. Теперь рекомендую прочитать код и узнать, как всё вышеописанное внутри работает.

Serginio1 22 окт 2016 в 21:02

Спасибо. Попробую.

kekekeks 22 окт 2016 в 21:19

Начать можете с взгляда на реализацию WebHostBuilderKestrelExtensions::UseKestrel, далее посмотреть, что такое IServer, затем изучить документацию, а конкретно раздел "Run ASP.NET Core on an OWIN-based server". после чего осознать, что реализация IServer без проблем делается на базе Microsoft.Owin.Host.SystemWeb, так как предоставляет точно такой же стандартный OWIN-овский Dictionary<string, object> со всем необходимым.

Выглядит примерно так:

Реализация IServer с кодом для настройки

public static class SystemWebAspNetCoreShim
{
public static IAppBuilder UseAspNetCore(this IAppBuilder builder, IWebHostBuilder hostBuilder, bool continueOn404)
{
    var server = new Server(continueOn404);
    hostBuilder.ConfigureServices(services => services.AddSingleton<IServer>(server));
    hostBuilder.Build();
    hostBuilder.Start();
    builder.Use<Middleware>(server);
    return builder;
}

class Middleware
{
    private readonly AppFunc _next;
    private readonly Server _server;

    public Middleware(Func<IDictionary<string, object>, Task> next, Server server)
    {
        _next = next;
        _server = server;
    }

    public Task Invoke(IDictionary<string, object> environment)
    {
        return _server.HandleRequest(environment, () => _next(environment));
    }
}

class Server : IServer
{
    private readonly bool _intercept404Errors;

    public void Dispose()
    {

    }

    public Func<IDictionary<string, object>, Func<Task>, Task> HandleRequest { get; private set; }

    public Server(bool intercept404Errors)
    {
        _intercept404Errors = intercept404Errors;
    }

    public void Start<TContext>(IHttpApplication<TContext> application)
    {
        HandleRequest = async (env, next) =>
        {
            var features = new FeatureCollection(new OwinFeatureCollection(env));
            var context = application.CreateContext(features);
            try
            {
                await application.ProcessRequestAsync(context);
            }
            catch (Exception ex)
            {
                application.DisposeContext(context, ex);
                throw;
            }

            application.DisposeContext(context, null);
            /*if (_intercept404Errors && owinContext.Response.StatusCode == 404)
            {
                await next();
            }*/
        };
    }

    public IFeatureCollection Features { get; } = new FeatureCollection();
}
}

Потом всё это счастье цепляете к обычному ASP.NET приложению:

Startup-класс для OWIN-хоста в IIS

[assembly: OwinStartup(typeof(SystemWebStartup))]
public class SystemWebStartup
{

public void Configuration(IAppBuilder appBuilder)
{
    var appPath = Directory.Exists(Path.Combine(HttpRuntime.BinDirectory, "Views"))
        ? HttpRuntime.BinDirectory
        : HttpRuntime.AppDomainAppPath;
    appBuilder.UseAspNetCore(
        new WebHostBuilder().UseContentRoot(appPath).UseStartup<Startup>(), false);
}
}

}

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

Serginio1 22 окт 2016 в 21:37

Спасибо! Интересно.

Serginio1 22 окт 2016 в 21:02

Добавлю, что я сделал SignalR сервер на ASP.NET Core. При этом под хамарин есть клиент, а для .Net Core нет даже альфы пока. Вот ссылка SignalRSample.Web/

https://chsakell.com/2016/10/10/real-time-applications-using-asp-net-core-signalr-angular/
https://radu-matei.github.io/blog/aspnet-core-mvc-signalr/

kekekeks 22 окт 2016 в 21:26

А в чём проблема "сделать SignalR сервер", если он изначально хостится на OWIN? Это делается ровно в 1 (одну) строку: app.UseAppBuilder(appBuilder => appBuilder.MapSignalR());

Serginio1 22 окт 2016 в 21:42

https://github.com/aspnet/SignalR-Server/blob/dev/samples/SignalRSample.Web/Startup.cs

Ну да. из вот варианты

 app.UseWebSockets();

            app.UseSignalR<RawConnection>("/raw-connection");

            app.UseSignalR();

Serginio1 22 окт 2016 в 11:47

И главное, что им не нужна была совместимость с ASP.NET Core сегодня: за и против

Платформе ASP.NET более 15 лет. Кроме этого, на момент создания System.Web содержала большое количество кода для поддержки обратной совместимости с классическим ASP. За это время платформа накопила достаточное количество кода, который просто больше уже не нужен и устарел. Microsoft встала перед непростым выбором: отказаться от обратной совместимости или анонсировать новую платформу. Они выбрали второй вариант. Одновременно с этим они должны были отказаться и от существующего runtime. Microsoft всегда была компанией, ориентированной на создание и запуск всего и вся на Windows. Существующая ASP.NET не был исключением. Сейчас ситуация сильно поменялась: значительное место в стратегии компании стали занимать Azure и Linux.

ASP.NET Core – это работа над ошибками классического ASP.NET MVC, возможность начать с чистого листа. Кроме этого, Microsoft также стремится стать такой же популярной, как Ruby и NodeJS среди более юных разработчиков.

— Что значит для нас переход на новую платформу?

— .NET Core не содержит многих компонентов, к которым мы привыкли. Забудьте про System.Web, Web Forms, Transaction Scope, WPF, Win Forms. Их больше нет.

zenkz 21 окт 2016 в 00:54

Верной дорогой идёте товарищи!

.Net 4.6 является наиболее оптимальным вариантом на сегодняшний день.
Проверенный и надёжный. Ведь ещё не понятно, приживётся ли .Net Core или нет. И стабильная версия с исправленными ошибками появится не раньше чем через 1-2 года. Раз классический ASP в вашем проекте прожил 16 лет, то не думаю, что .Net 4.6 проживёт меньше. Очень уж много кода уже написано на .Net. А через 10-15 лет можно будет ещё раз переписать уже на .Net Core 4 или 5 (или какая там версия будет через 10 лет).

robert_ayrapetyan 21 окт 2016 в 03:38

Не получится ли так, что поддержка .Net 4.6 полностью схлопнется через пару лет?

gandjustas 21 окт 2016 в 04:45

Уже ведутся разговоры о том, то надо все версии .NET FW привести к одному знаменателю. Поэтому будет один базовый .NET и разный набор либ в зависимости от платформы — Windows\Portable\Linux\Xamarin\еще_что_то.

Serginio1 21 окт 2016 в 10:49

Ну ждать немного осталось https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
А то с этими профилями одно мучение. Кроме того пока инструменты в pre/ Ждемс .NET Core Tooling in Visual Studio “15”
Кстати Announcing the October 2016 Update for .NET Core 1.0

Serginio1 21 окт 2016 в 10:44

Ну и сейчас уже Asp.Net Core быстрее обычного Asp.Net причем в разы https://github.com/aspnet/benchmarks

Master_Dante 21 окт 2016 в 15:06

Посмотрел вашу ссылку и удивился. Есть там какой то Netty который еще быстрее в три раза. Спасибо за ссылку буду копать.

Serginio1 21 окт 2016 в 15:09

Ну не в 3 и на Plain Text with HTTP Pipelining
Для Plain Text всего 1.4

Master_Dante 21 окт 2016 в 16:35

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

korzh 21 окт 2016 в 11:22

Если это classic ASP, то значит это некое веб приложение.

В таком случае идеальный подход сейчас — писать на ASP.NET Core over .NET Framework 4.6 (но не .NET Core).
Если потом понадобится кросс-платформенность — то, думаю, перенос на .NET Core можно будет через некоторое время осуществить простым добавлением target платформы и перекомпиляцией.

zenkz 21 окт 2016 в 00:42

Я люблю .Net за его «монолитность» и удобные инструменты.
Преимущество «монолитности» является в том, что 80-90% того, что мне нужно реализовать, я могу реализовать с использованием стандартных классов и средств языка, а не искать сторонние плагины (которые могут быть криво написаны или с плохой документацией).

В отличии от Java и того ада, что творится в JS frontend-разработке, я могу запустить Visual Studio, нажать «Create Project» и нажать «Run». И веб-приложение запустится. Не нужно настраивать всякие конфигурации, подключать сборщики и менеждеры пакетов и т.д.

Синтаксический сахар C#а шикарен. Язык хорошо стандартизирован и документирован и на нём приятно писать.

.Net, как и Java, ещё долго не уйдут с рынка Enterprise-решений и будут сильны для серверной части приложений. Движение в сторону кросс-платформенности также даёт повод для оптимизма.

Жду выхода следующей версии .Net Core и надеюсь что основные детские болезни будут в ней устранены и он будет годен для Enterprise-разработки.

ad1Dima 21 окт 2016 в 04:17

что 80-90% того, что мне нужно реализовать, я могу реализовать с использованием стандартных классов и средств языка
В случае не монолитности то же самое можно использовать с помощью стандартных плагинов. Хотя на самом деле сейчас так и есть. и я не понимаю претензии в статье.

gandjustas 21 окт 2016 в 04:51

В случае не монолитности то же самое можно использовать с помощью стандартных плагинов

Это неправда. Посмотри на C++ — до сих пор в каждом фреймворке свой класс строк, и все эти строки не совместимы между собой.

ad1Dima 21 окт 2016 в 04:55

Просто строки нужно в микроядро, монолитность/модульность тут не причём. Когда делали C++ полагали, что массива символов для строк более чем достаточно. А потом пришёл UI и понеслась...

gandjustas 21 окт 2016 в 05:23

Ну по такой логике много что нужно в микроядро:

строки
работа с сетью и веб-клиент
асинхронность и многопоточность
сериализация

Причем эти все вещи взаимосвязаны.

Собственно в .NET так и сделали — включи все это в "монолитное ядро", а в С++ до сих пор разброд и шатание.

ad1Dima 21 окт 2016 в 05:39

Строки, многопоточность и асинхронность да. (асинхронность — вообще синтаксический сахар, так-то.)

Вебклиент лучше стандартным модулем, сереализацию тоже. А то получается сейчас в .net 3 или 4 разных сериализации (xml, json, runtime), а большинство пользуется только json.net.

Причем эти все вещи взаимосвязаны.

связ не полная. Явно прослеживаются доли графа.

ad1Dima 21 окт 2016 в 05:44

Но на самом деле, что-то мне подсказывает, что Рихтер имел в виду не библиотеки, которые и так разделены, а саму исполняемую среду.

TreyLav 21 окт 2016 в 02:24

Что может быть лучше C#, если ваша целевая платформа — Windows only, да ещё с GUI? C# — хороший язык с как минимум одной чёткой нишей, с чего бы ему умирать?

geekmetwice 21 окт 2016 в 04:04

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

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

Ни разу не новинка. Просто скомпилённая DLL-ка в Delphi и заюзаная в VB — ровно то же, только «под одной крышей» Венды.

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

А если быть совсем точным, то ТОЛЬКО на тех языках, которые были написаны под .NET; Фактически, юзабельных языков было всего ДВА — школотронский васик и сишарп.

> которые лучше подходили для решения своих задач.

Чего?? Чем васик для «своих задач» лучше/хуже C#? Что за бестолковая привычка лепить «язык для своих задач»! Мы используем ЯОН — внимательно расшифруйте эту аббревиатуру и не позорьтесь этим мемом «язык — задачи».

> Сложно переоценить роль такого нововведения, как веб-сервисы

Да не сложно! Фуфло это проприетарное. После них ещё пяток технологий выкатили, из последних велосипедов — WCF. Ну и какова тут «роль веб-сервисов»? И без них было что юзать — Corba, TCP.

> тесная интеграция ASP.NET с Windows IIS… критики со стороны сообщества

Да ладно! Критики ОТ КОГО? Красноглазых линуксоидов? Коммерческие разрабы спокойно сидели в нише Windows и никто даже не думал куда-то валить.

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

Серьёзно? Да уж… если во времена Delphi автор ходил в детсад — тогда да, можно простить такой пробел в знаниях.

> разработчики пошли навстречу поклонникам других ОС. Так, например, в сообществе open source появился проект Mono

Не надо опять гнать пургу! Никакие разработчики не шли навстречу — микрософт был анально огороженной средой, а Моно — энтузазистский проект Мигеля, НИКАК не поддерживаемый разработчиками MS.

> который был официально признан реализацией .NET на Unix-подобных операционных системах

Опять бестолковщину пишете! Моно НЕ ЯВЛЯЕТСЯ официальной и поддерживаемой платформой! .NET Core — да, а мексиканское поделие — нет.

> Главная претензия критиков – это нерациональное использование памяти системы.

Ха-ха! ДА ЛАДНО?! :) Вот уж чего никогда не считали, так это память под дотнет — она просто есть и по-умолчанию её навалом.
Фактически, дотнет даже не за что критиковать — он идеален с точки зрения среднего прогера, пишущего для венды. Критиканы прибегают в основном с Линуксов, которым уже прилетело сипиписными граблями по всем местам и они мечтают об удобном инструменте типа VS/C#.

Ну и в довершении этой смехотворной статьи, мои личные ответы: Перспективы у .NET ОЧЕНЬ МРАЧНЫЕ. Если «обычный» дотнет — вполне себе юзабельная платформа, то кому обздался Core — ещё большой вопрос. На венде он точно не нужен, кто хотел скоростей/памяти — давно подружились с С++. На Линуксе — тем более, там одних языков ДЕСЯТКИ — пиши-не хочу. И главное — поганая привычка MS портить то, что уже хорошо сделано. Например, WinForms. Было скучно — запилили неуклюжего монстра WPF. Поддержку Win XP похерили ещё в .NET 4.5 (хотя казалось бы, что умного понаписали для 7, чего нельзя сделать в XP??). Silverlight — в могиле. То же ждёт и Core — потратят деньги и ресурсы на очередной всемогутер, а потом окажется, что юзают его 2.5 инвалида из самого же MS. А отрасль и винда в частности опять затормозится в развитии. Эпик фэйл с Win 10 ещё впереди!
Эх, гнусные времена ждут мелкомягких танцоров-диско!

gandjustas 21 окт 2016 в 04:49

Делфи-батхерт детектед.

Делфи сдох. C# — новый делфи и это было изначальной целью.

tangro 21 окт 2016 в 10:27

Делфи сдох. C# — новый делфи и это было изначальной целью.

Тоже сдохнуть через пяток лет?

gagarinstas 8 сен 2021 в 14:10

вижу «детектед» — да только не у того))
geekmetwice правильно указал на многие ошибки статьи включая — «тогда качественный инструмент для создания GUI был в новинку».

aikixd 21 окт 2016 в 11:45

то кому обздался Core — ещё большой вопрос. На венде он точно не нужен, кто хотел скоростей/памяти — давно подружились с С++.

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

DistortNeo 21 окт 2016 в 13:18

Минус только в потреблении памяти. Всё-таки неприятно видеть, когда игра потребляет 11 гигабайт памяти.

Anarions 21 окт 2016 в 16:18

Не видел такого ни разу в жизни.

denismaster 21 окт 2016 в 16:23

Значит вам повезло и вы не играли в Space Engineers=)

aikixd 21 окт 2016 в 16:53

Дело в инженерах а не среде. С тем же успехом вы можете десятком строк заплодить все пространство Objectами на 128 гигов. Так игра устроена.

denismaster 21 окт 2016 в 17:32

Я категорически с вами согласен, что там проблема в самой игре, а не в дотнете) Я просто привел пример игры, которая легко кушает 11 гигов памяти)

DistortNeo 21 окт 2016 в 19:43

А зря, столько памяти потребляют последние новые игры (на максимальных настройках): GTA V, Mirror's Edge Catalyst. Из игр на .NET могу привести Cities: Skyline, которая вполне может и 7-8 гигов откушать.

Последние 5 лет мне за глаза хватало 16 гигабайт памяти (игры + разработка + виртуальные машины + обработка изображений на одном компе), сейчас же что-то захотелось уже 32 или даже 64.

Master_Dante 21 окт 2016 в 15:13

Друх .Net Core сделали опенсорс а это значит бессмертие. Я уже на нем пишу ;)

YmNIK_13 8 сен 2021 в 14:11

Такое ощущение что вы уснули в 2010 и проснулись в 2016, а потом написали этот комментарий.

Win XP тащило все пережитки прошлого, вы как любитель делфи должны помнить WinAPI, а уж говорить о том что WinForms выигрывает против WPF — это вообще за гранью.

2 языка, вы серьезно? Даже последние версии делфи были заточены под .Net.

Silverlight сдох по той же причине почему сдох флеш — появился HTML5.

Вот за что стоит критиковать МS так это за то, что они не правильно прогнозируют развитие той или иной технологии и очень долго приходят к правильным решениям.
Когда-то давно профукали поддержку JS и веб-разработчики до сих пор смотрят на IE как на зло.
Потом профукали мобильный рынок и потянули за собой нокию
И точно так же паралельно профукали кроссплатформенность, хотя .Net именно первоначально под это задумывался, а реализовали только вот.

Но лучше уж поздно чем никогда.

ad1Dima 8 сен 2021 в 14:27

И точно так же паралельно профукали кроссплатформенность, хотя .Net именно первоначально под это задумывался, а реализовали только вот.

Если что, в 2016 ксамарин уже был куплен, а .NET Standard уже существовал. В пролёте был только линукс.

ZOXEXIVO 21 окт 2016 в 09:50

Модные Go, Swift программисты конечно скажут что .NET не моден

S_A 21 окт 2016 в 11:00

Внезапно тут открыл для себя F# (постоянно пишу на C#), и теперь вообще не планирую куда-то переходить (хотя на том же Swift писал, на Java тоже, и на node.js периодически пишу).

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

В чем по-моему имхо плюсы? C# сам по себе я не считаю мегаплюсом, и уж тем более его «сахар» (что спорно, но не буду об этом). Сам по себе .net тоже не особо уникален или примечателен. Примечательно то, что если node.js хорош во всем, что связано с вебом, html (в том числе для мобил), и пусть даже десктопом (electron), то ms — это в первую очередь десктопная экосистема (и с Xamarin теперь еще и мобильная). И я не вижу ничего плохого, если бы XAML работал на Linux. Не так уж плохо у ms всё спроектировано, не хуже чем в Java-мире или Python-мире.

А, да. F#… есть холивары насчет языков с отступами. Удобство в том, что легко оборачивать код в подфункции, и подобные манипуляции делаются обычным (ctrl+)shift+tab, не надо ставить скобки :) А если серьезно, то надеюсь у F# будет большое будущее. Писать нужно очень мало кода по сравнению с С# до достижения того же эффекта. В голове правда держать нужно больше контекста, но к этому привыкаешь.

aikixd 21 окт 2016 в 11:53

Плюсанул за F#.

Если ты, %username%, не писал на F# — кликай и пиши.

Master_Dante 21 окт 2016 в 15:17

Я без скобок в BSD стиле жить не могу. Думаю с F# мы не подружимся.

Pakos 21 окт 2016 в 11:06

asm умер, Delphi умер, .Net умер… а посмотришь вокруг — работают эти живые мертвецы.

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

Anarions 21 окт 2016 в 16:20

Ещё чуть позже. Ынтырпрайс, вин приложения, unity, CryEngine, Xamarin.

Disbeleiver 21 окт 2016 в 11:23

.NET — вполне модная платформа в игрострое благодаря Unity (и CryEngine в бесплатные подтянулся).

Mamboking 21 окт 2016 в 11:23

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

gbr 21 окт 2016 в 11:23

Я на дотнете лет 15, у меня практически руки под дотнет заточены. Но последний раз хорошую позицию я нашел за 1.5 года! Это при том, что лет 5 назад я проходил по 9 собеседований в неделю. Сейчас я на Java+Spring+Maven. В России ИТ движет госзаказ, а здесь импортозамещение в разгаре — уход в сторону java и open source, особенная неприязнь к Microsoft (мне так кажется). Дотнет будет жить во всем остальном мире, поскольку он прекрасен, но не в России. Мне удавалось на дотнете иной раз в одиночку создавать большие системы, которые на Java можно сделать за те же сроки только командой и с худшим качеством. Кстати, откуда этот график? Он совсем не отражает действительность. Вы давно на hh заходили? Сейчас дотнет в упадке, трудно найти Java разработчика (может все нарасхват?). А в конечном счете всех уделает JavaScript

ZOXEXIVO 21 окт 2016 в 12:46

Вы пропустили важный этап в жизни .NET и теперь он тоже попадает в категорию «Импортозамещения»

gbr 22 окт 2016 в 11:14

Вы имеете в виду Core? Это бесполезно, поскольку на .NET и C# навсегда наклеен нелюбимый бренд Microsoft. Вы думаете я не был бы рад использованию .NET? Чиновникам не объяснить, что Core работает под Linux и что под .NET полно open source — бесполезно: ".NET — это Microsoft? Да? Нафиг его! "

DistortNeo 22 окт 2016 в 21:39

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

gbr 23 окт 2016 в 16:14

Искренне за Вас рад, держите нас в курсе. Но сильно не кричите о том, что у вас все на шарпе, мало ли что.

marshinov 23 окт 2016 в 20:59

У вас какие-то другие чиновники и другая Россия. У Барс Груп, тот что входит в тройку крупнейших интеграторов в B2G и был недавно приобретен Ростехом большая часть разработки на .NET.

senglory 8 сен 2021 в 14:11

а здесь импортозамещение в разгаре — уход в сторону java и open source, особенная неприязнь к Microsoft (мне так кажется).

Не только в РФ — попробуйте поискать вакансии для .NET в Германии/Голландии/Франции и пр. странах Старой Европы. Фиг да ни фига по сравнению с Java.

ad1Dima 8 сен 2021 в 14:28

а здесь импортозамещение в разгаре — уход в сторону java и open source, особенная неприязнь к Microsoft (мне так кажется).

хм GitHub - dotnet/core: Home repository for .NET Core

Naglec 8 сен 2021 в 14:16

.NET в упадке? В Мск по C# сейчас находится порядка 800 вакансий. Год назад было около 450. Два года назад около 600. Динамика вполне очевидна.

dmitry_dvm 21 окт 2016 в 12:01

Что-то можно, а что-то вечно. Шарп прекрасный язык. У дотнета отличная инфраструктура, отличные инструменты. Где сейчас модный CoffeeScript? Некогда гремевший jQuery тоже на грани забвения.

gbr 21 окт 2016 в 12:42

Не путайте плз CoffeScript, jQuery с JavaScript. А насчет уделает — время лучший судья, вспомните мои слова потом. А вот еще: http://stackoverflow.com/research/developer-survey-2016
Кто до сих пор не понимает, тот и дальше будет испытывать проблемы с поиском разработчиков и работы.

Anarions 21 окт 2016 в 16:23

Там опросник с множественным выбором. Естественно все кто связан с вэбом, или гибридными приложениями, помимо «основного» языка указали javascript. Из «серьёзных» языков на первом месте, как раз, C#

ilya-chumakov 21 окт 2016 в 12:12

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

ad1Dima 24 окт 2016 в 08:53

@semen_grinshtein — Редактор

Pavki 9 сен 2021 в 13:00

Такой заголовок могут дать только конкуренты в Enterprise сегменте.

Neuyazvimy1 8 сен 2021 в 14:15

Пишу на C# и на Java. Больше нравится C#. Но не представляю backend на .NET-е потому как геморно будет все это поднимать на linux-е. З.Ы так и выходит пишем игры на Unity3d (c#), а backend на java.

ad1Dima 8 сен 2021 в 14:30

Я, конечно, не бекенд-разработчик, но в 2021 всё прекрасно поднимается )

KMaxI 10 сен 2021 в 10:27

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Каковы перспективы у «немодной» платформы .NET — мнения экспертов

Комментарии 127

Публикации

Истории