Microsoft планирует к 2030 году исключить весь код на C и C++ из основных баз

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

Microsoft планирует к 2030 году исключить весь код на C и C++ из основных баз

За счет чего операционка должна ускоряться от версии к версии?

В России запустили верификацию для иностранных сим-карт

Gibberlink

Зумеры изобрели Dial-up?😁

Вышел PHP 8.5

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

Вышел PHP 8.5

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

Увы, ваш синтаксис подсвечен безграмотно

Бойан

ASP.Net MVC vs Blazor: чья возьмет?

View в MVC - это презентационный слой для данных, визуальным он может быть, но не обязан. REST API своему клиенту могут презентовать данные в виде JSON - фронтенду или другому (микро)сервису. Визуализируются они дальше или нет - не важно.

В ASP.NET Core средства создания REST API лежат в сборке Microsoft.AspNetCore.Mvc.Core, поэтому логично было бы считать их частью ASP.NET Core MVC-сабфреймворка. Раньше этому у MS было отдельное название - Web API, а сейчас в документации скупое Controller-based APIs.

ASP.Net MVC vs Blazor: чья возьмет?

Что значит "до дотнета"?

Это значит, что ASP и ASP.NET - разные технологии. Ссылку я привел выше.

У актуального дотнета уже несколько лет нет слова Core в названии

У дотнета - уже нет, а у библиотек и фреймворков - так и осталось. ASP.NET Core, EF Core и т.п.

У MS всю дорогу проблемы с неймингом =3

MVC - это шаблон проектирования Model-View-Controller, и я затрудняюсь представить, кто и как пишет с его помощью микросервисы.

В чем именно тут затруднение? Микросервисы накладывают ограничения на архитектурные паттерны? Или что "View" может быть не только куском готового HTML, но и JSON-моделькой?

ASP.Net MVC vs Blazor: чья возьмет?

ASP, еще до дотнета который? Нет, речь идет об актуальном ASP.NET Core MVC, хотя автор в посте по почему-то отбросил слово "Core", но из контекста понятно, что речь идет не про оригинальный ASP.NET MVC под .NET Framework.

ASP.Net MVC vs Blazor: чья возьмет?

JS Interop — это головная боль. Да, можно использовать JS-библиотеки, но там, где TypeScript подсвечивает синтаксис и проверяет типобезопасность на этапе компиляции, в Blazor все проверки смещаются в рантайм

Если говорить именно про библиотеки на JS, то TS будет полагаться на декларации контрактов (*.d.ts), которые в рантайме так же могут разъехаться с реализацией. При том TS, как известно, не силен рантаймовыми проверками, в отличие от.

ASP.Net MVC vs Blazor: чья возьмет?

На MVC в том числе делают микросервисы. Кроме того, сейчас MS ативно форсит более аскетичный Minimal API для этих целей, но этот подход еще не победил.

ASP.Net MVC vs Blazor: чья возьмет?

А какое преимущество в вебе дает интерпретация?

Чем это лучше Laravel Livewire?

WebSocket против HTTP и полноценный WASM-режим с возможностью делать полноценные PWA.

О дивный новый C#

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

О дивный новый C#

Это буквально означает, что нужно и то, и другое)

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

О дивный новый C#

почему-то язык не самый популярный.

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

почему-то они компилятор ts портируют не на c# и не на rust, а на go.

Этому был ответ от разработчиков - проще было автоматически портировать, т.к. у Go простая грамматика. Если смотреть по системным задачам, то для разработки виндов MS выбирают таки Rust, а не Go.

Rust и приведение типов

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

Наивное решение через типы-суммы

enum DomNode {
    Card(CardType),
    Wrapper(Vec<DomNode>),
}

enum CardType {
    Text(String),
    NoText,
}

impl CardType {
    fn echo(&self) {
        match self {
            CardType::Text(content) => println!("A TextItem's content: {content}"),
            _ => {}
        }
    }
}

fn main() {
    let dom = DomNode::Wrapper(vec![
        DomNode::Card(CardType::NoText),
        DomNode::Card(CardType::Text("Hello World".to_string())),
        DomNode::Wrapper(vec![
            DomNode::Card(CardType::Text("Hello World".to_string())),
            DomNode::Card(CardType::NoText),
        ]),
        DomNode::Card(CardType::NoText),
    ]);

    visit_node(&dom);
}

fn visit_node(node: &DomNode) {
    match node {
        DomNode::Card(card) => card.echo(),
        DomNode::Wrapper(inner) => {
            for node in inner {
                visit_node(&node);
            }
        }
    }
}

прейграунд

О дивный новый C#

golang, он менее многословный и более выразительный

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

Выразительность - это субъективная мера, но многословность здесь очков как будто бы не добавляет.

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

В целом, согласен с мыслью о том, что Rust - сложноват, для того, чтобы быть заменой C# для написания логики с умереннымыми требованиями к ресурсам. Но ведь и Go слишком сильно проигрывает шарпам по облегчалкам жизни для программиста, чтобы делать на нем зубодробительную бизнес-логику. Его роль сейчас устаканивается где-то на стыке технологий: в решении боттлнеков, где C++ еще оверкилл, но условный Python уже не вывозит.

О дивный новый C#

Тем временем Java уже имеет версию 25 и релизится дважды в год.

Чем заменить роутеры Keenetic, которых больше не будет в России

1 раз в год перезагружаешь, если нет интернета больше 30 минут

Ради этого за сотни км к железке смотаться - почему бы и да!

Мне жаль, но вы используете подсветку кода неправильно

вы точно живёте в каком то другом мире, где люди не ошибаются и задачи планируются сразу

Низкая квалификация и недобросовестная работа - это ошибка выбора профессии, в таких "мирах" я стараюсь не задерживаться. Чего и другим желаю.

приходили люди, которые пытались починить код, который даже не исполнялся

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

работаю над задачей у которой уже 12 итераций

12 раз переделывать одну фичу - это похоже на безумие само по себе) Звучит, как процессы стартапа под конец бюджета, когда требования рождаются по ходу пьесы и нет времени на исследование кодобазы перед взятием фичи в разработку. Почему так? Никто заранее не знал, что те же А/Б тесты нужны?

если сейчас сделали задачу, а потом оказалось что надо распилить функционал пополам, потом сделать две итерации над одной частью, потом АБ тесты, потом ещё что-то, никто не будет тащить комментарий о том, в какой ветке спрятана вторая половина функционала.

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

была в комментариях к одной из тасок, которые с учётом правок и дополнений уже на поэму тянут

Если следовать git flow или подобной методологии, где каждая единица работы делается в отдельной ветке, и id таски в имени, то проблем с поиском не должно быть.