Как стать автором
Обновить

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

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

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

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

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

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

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

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

Посмотрите к примеру на любой современный браузер. Firefox с радостью съедает 2-3 Гб памяти всего с 10-15 открытыми вкладками. Вот уж где нужна оптимизация.
>К тому же часто проблема использования памяти — это не проблема языка, а проблема конкретного кода и алгоритмов.
Ну строго говоря нет. Язык может быть построен на принципах, которые трудно или невозможно реализовать без оверхеда (или грязных трюков).
Гипотетический язык с «честной» динамической типизацией будет априори проигрывать гипотетическому языку со статической типизацией (по производительности и потреблению памяти), к примеру.
С возросшими объемами памяти в устройствах (ноутбуках, серверах) разработчикам .NET нынче не приходится заморачиваться особенностями ее использования, оттого и низкая их квалификация, и качество кода становится поистине ужасным. «Кодируй, как получится, все равно будет работать». Это и плюс (скорость разработки, ниже порог вхождения), и минус (непродуманно написанное приложение рано или поздно все равно сожрет всю память объектами GC2).
Ниже чем что? (Про порог вхождения)
Как будто на языках с GC пишут исключительно говнокод, а на языках с ручным управлением памятью — исключительно шедевры.
И это замечание, естественно, повод сливать мне карму. Надеюсь все поучавствовавшие чувствуют себя лучше, потому-что в остальном у них явно какие-то проблемы.
Это не замечаение, это вброс на три с минусом.
Вброс на три с минусом — говорить о том что из-за GC «качество кода становится поистине ужасным»
Качество кода становится поистене ужасным, когда его пишет поистине ужасный кодер вне зависимости от языка и платформы.
И именно это я и сказал двумя комментариями выше.
Так как управлением памяти не надо замарачиваться- .net программисты = фиговые програмисты, а все остальные дартаньяны. Вот что вы сказали
Вы точно не путаете обсуждаемый коментарий с коментарием, на который он был ответом? Потому что лично для меня

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

и

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

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

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

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

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

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

Я не понимаю с чего тут взяли что .NET «немоден» вдруг. Язык C# прекрасен, лучшего мейнстрим языка пока нет. .NET вон становится переносным, хоть и без UI. Вообще все супер!
Есть Avalonia Пока правда pre, но развивается
Ну, с UI реальная проблема — по идее, нужен портативный WPF, но Microsoft завязали его на аппаратное ускорение, что не очень переносимо.
На DitectX. Вин фоны тоже поддерживают DitectX. Но вот XAML есть и на Xamarin http://metanit.com/sharp/xamarin/2.4.php

Надо подождать NetStandard 2 и следующей версии .Net Core
Скажите, а зачем вам нужен NetStandard2? Чего именно не хватает в 1.1?

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

Так в .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.

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


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

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

1.1 там только исправления. То, что можно использовать и 1.0 не спорю, но с 1.2 это делать будет значительно проще
.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
Мы говорим NetStandard 2, подразумеваем .Net Core 1.2

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

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

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

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

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

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

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

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

А вот для серверов WPF не нужен, а интересны им юниксы линуксы именно из-за облаков.
Язык C# прекрасен, лучшего мейнстрим языка пока нет.

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

Очень нравится. Серьезно, продуманный язык, вот так сходу придраться не к чему, но с другой стороны я на нем не пишу. У Swift и C# одна проблема — кроссплатформенный UI. Ну, у Swift еще проблема что Windows этому языку амбивалентен, но у нас сейчас и порты есть, и Ubuntu под Linux стоит, так что проблемы вроде особой нет.
Есть некий кровавый ынтырпрайз проект 16-летней давности на classic ASP. С начала 2016 года вдруг взялись все переписывать на .NET 4.6, а тут как раз вышел .NET Core (сырой и недоделанный), а ведь остальные .NET-ы прикажут долго жить к моменту, когда проект будет полностю переписан. Как быть камрады?
Вашему enterprise так необходим .NET Core? Вы думаете, там другой диалект C#?
Еще хотят засунуть все это в Azure, и типа там .NET Core более применим (во всяк. случае MS об этом кричит, маркетинговая замануха или реальность?)
.NET Core это не новый C# и ничего «учить» там не нужно. Просто другой способ дистрибуции вашего приложения, такое микроядро с подключаемыми модулями.
Основная сложность в портировании — исключение Windows-специфичных вещей из своего приложения. Если это жесткое legacy, то скорее всего все будет плохо.
В Azure очень важно кнопочкой быстро создать виртуальную машину и быстро ввести ее в действие. Windows Nano Server + .NET Core позволит за считанные секунды развернуть новую виртуалку задеплоить на нее ваше приложение, которое, к тому же, быстро начнет работать.
Ну с C# то как раз понятно, непонятно на чем щас переписывать classic ASP проект с нуля — на .Net Core или .Net 4.6, если все это хотят тут же засунуть в Azure?
Вам нужно просто переделать его на ASP.NET Core.
net46 или netcoreapp1.0 выбирается в конфиге.
Я уже давал ссылку на бенчмарки

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

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

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

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

По ссылочке
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 установим значение Без управляемого кода:

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

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

Начать можете с взгляда на реализацию 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-представлений, оно почему-то не видит нужные типы, поэтому никаких публикаций на эту тему ещё не делал.

Спасибо! Интересно.
Добавлю, что я сделал 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/

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

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

Ну да. из вот варианты
 app.UseWebSockets();

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

            app.UseSignalR();
И главное, что им не нужна была совместимость с 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. Их больше нет.
Верной дорогой идёте товарищи!

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

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

Ну ждать немного осталось 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
Ну и сейчас уже Asp.Net Core быстрее обычного Asp.Net причем в разы https://github.com/aspnet/benchmarks
Посмотрел вашу ссылку и удивился. Есть там какой то Netty который еще быстрее в три раза. Спасибо за ссылку буду копать.
Ну не в 3 и на Plain Text with HTTP Pipelining
Для Plain Text всего 1.4
Да я посмотрел там ява, а я ее не перевариваю )). Если уж и зайдет об этом речь, мы просто напишем свой web сервер, который будет эффективнее управлять подключениями.
Если это classic ASP, то значит это некое веб приложение.

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

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

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

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

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

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

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

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


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

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


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

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


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


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

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

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

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

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

Ни разу не новинка. Просто скомпилённая 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 ещё впереди!
Эх, гнусные времена ждут мелкомягких танцоров-диско!

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


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

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

Тоже сдохнуть через пяток лет?
вижу «детектед» — да только не у того))
geekmetwice правильно указал на многие ошибки статьи включая — «тогда качественный инструмент для создания GUI был в новинку».
то кому обздался Core — ещё большой вопрос. На венде он точно не нужен, кто хотел скоростей/памяти — давно подружились с С++.


Бред. На шарпах сейчас игр развелось хоть обавляй. Он проще, лучше отлаживается и более предсказуем. И для этих игр любой школьник может написать аддон и не угробить всю систему. На сях инди сцены бы просто не появилось.
Минус только в потреблении памяти. Всё-таки неприятно видеть, когда игра потребляет 11 гигабайт памяти.
Не видел такого ни разу в жизни.
Значит вам повезло и вы не играли в Space Engineers=)
Дело в инженерах а не среде. С тем же успехом вы можете десятком строк заплодить все пространство Objectами на 128 гигов. Так игра устроена.
Я категорически с вами согласен, что там проблема в самой игре, а не в дотнете) Я просто привел пример игры, которая легко кушает 11 гигов памяти)
А зря, столько памяти потребляют последние новые игры (на максимальных настройках): GTA V, Mirror's Edge Catalyst. Из игр на .NET могу привести Cities: Skyline, которая вполне может и 7-8 гигов откушать.

Последние 5 лет мне за глаза хватало 16 гигабайт памяти (игры + разработка + виртуальные машины + обработка изображений на одном компе), сейчас же что-то захотелось уже 32 или даже 64.
Друх .Net Core сделали опенсорс а это значит бессмертие. Я уже на нем пишу ;)
Такое ощущение что вы уснули в 2010 и проснулись в 2016, а потом написали этот комментарий.

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

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

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

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

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

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

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

Внезапно тут открыл для себя 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# будет большое будущее. Писать нужно очень мало кода по сравнению с С# до достижения того же эффекта. В голове правда держать нужно больше контекста, но к этому привыкаешь.
Плюсанул за F#.

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

Я без скобок в BSD стиле жить не могу. Думаю с F# мы не подружимся.
asm умер, Delphi умер, .Net умер… а посмотришь вокруг — работают эти живые мертвецы.
НЛО прилетело и опубликовало эту надпись здесь
Ещё чуть позже. Ынтырпрайс, вин приложения, unity, CryEngine, Xamarin.
.NET — вполне модная платформа в игрострое благодаря Unity (и CryEngine в бесплатные подтянулся).
Очень странная подборка очень странных мнений. Посмотрите лучше на рынок труда — спрос на .net программистов есть, достаточно большой и стабильный, значит и проекты на .net востребованы.
Я на дотнете лет 15, у меня практически руки под дотнет заточены. Но последний раз хорошую позицию я нашел за 1.5 года! Это при том, что лет 5 назад я проходил по 9 собеседований в неделю. Сейчас я на Java+Spring+Maven. В России ИТ движет госзаказ, а здесь импортозамещение в разгаре — уход в сторону java и open source, особенная неприязнь к Microsoft (мне так кажется). Дотнет будет жить во всем остальном мире, поскольку он прекрасен, но не в России. Мне удавалось на дотнете иной раз в одиночку создавать большие системы, которые на Java можно сделать за те же сроки только командой и с худшим качеством. Кстати, откуда этот график? Он совсем не отражает действительность. Вы давно на hh заходили? Сейчас дотнет в упадке, трудно найти Java разработчика (может все нарасхват?). А в конечном счете всех уделает JavaScript
Вы пропустили важный этап в жизни .NET и теперь он тоже попадает в категорию «Импортозамещения»
Вы имеете в виду Core? Это бесполезно, поскольку на .NET и C# навсегда наклеен нелюбимый бренд Microsoft. Вы думаете я не был бы рад использованию .NET? Чиновникам не объяснить, что Core работает под Linux и что под .NET полно open source — бесполезно: ".NET — это Microsoft? Да? Нафиг его! "
Ну не знаю, вот я сейчас разрабатываю серверную часть для госзаказчика. Заказчику все равно, на чём написано, ему главное, чтобы работало под Linux. Поэтому разработка ведётся на C# из соображений удобства разработки и отладки.
Искренне за Вас рад, держите нас в курсе. Но сильно не кричите о том, что у вас все на шарпе, мало ли что.
У вас какие-то другие чиновники и другая Россия. У Барс Груп, тот что входит в тройку крупнейших интеграторов в B2G и был недавно приобретен Ростехом большая часть разработки на .NET.
а здесь импортозамещение в разгаре — уход в сторону java и open source, особенная неприязнь к Microsoft (мне так кажется).

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

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

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

.NET в упадке? В Мск по C# сейчас находится порядка 800 вакансий. Год назад было около 450. Два года назад около 600. Динамика вполне очевидна.
Что-то можно, а что-то вечно. Шарп прекрасный язык. У дотнета отличная инфраструктура, отличные инструменты. Где сейчас модный CoffeeScript? Некогда гремевший jQuery тоже на грани забвения.
Не путайте плз CoffeScript, jQuery с JavaScript. А насчет уделает — время лучший судья, вспомните мои слова потом. А вот еще: http://stackoverflow.com/research/developer-survey-2016
Кто до сих пор не понимает, тот и дальше будет испытывать проблемы с поиском разработчиков и работы.
Там опросник с множественным выбором. Естественно все кто связан с вэбом, или гибридными приложениями, помимо «основного» языка указали javascript. Из «серьёзных» языков на первом месте, как раз, C#
Заголовок в лучших традициях желтой прессы. Не затруднит ли вас пояснить, кто считает .NET немодным?

@semen_grinshtein — Редактор

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

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

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

Публикации

Истории