Василий Банников

Это не "создание объекта через родителя". Создание во всех случаях происходит одинаково. Здесь ссылка на ребенка сохраняется в переменную типа родителя. В этом, типа, и заключается динамический полиморфизм. Смысл в том, что ты можешь разных, заранее не определенных детей, складывать в коллекцию с типом родителя, например. Или принимать и возвращать из методов - тоже родителя, а не конкретных детей.
Зачем? Например, у тебя есть объект клетка, который содержит животное. Условно, ты не должен делать разные клетки - PigCage, DogCage, CatCage, а должен использовать одну.

Всё зависит что вы делаете. Спецэффекты, тени и так далее, занимается видеокарта, если что-то простое, то процессор.

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

2) Таски используют пул потоков, поэтому особой разницы между ThreadPool.QueueUserWorkItem и запуском Таски нет.

3) Что Thread.Sleep(10000) что Task.Delay(10000).Wait() - это блокирующая операция, которая приводит к тому что называют thread pool starvation. То есть поток не имеет возможности вернуться в пул и переиспользоваться. У пула потоков есть задержка на ввод нового потока в работу, поэтому у вас все и тормозит.

Вывод в том, что вы некорректно готовите асинхронность. Во всех случаях вы блокируете потоки и количество потоков у вас во всех случаях примерно одинаковое задействуется. Если вы ограничены 4.0, то скорее всего, лучшим вариантом будет старая модель асинхронности .net
https://docs.microsoft.com/en-us/dotnet/standard/a...
У сокетов есть соответствующие методы

На домене висит заглушка о продаже. Сайт закрылся или куда-то переехал.

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

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

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

using System;
using System.Windows.Forms;

namespace WinFormsApp
{
    public partial class MainForm : Form
    {
        private readonly Random _random;
        private readonly Timer _timer;

        public MainForm()
        {
            InitializeComponent();

            _random = new Random();
            _timer = new Timer();
            _timer.Interval = 500;
            _timer.Tick += OnTimerTick;
        }

        private void OnFormLoad(object sender, EventArgs e)
        {
            _timer.Start();
        }

        private void OnTimerTick(object sender, EventArgs e)
        {
            label.Text = _random.Next(0, 1000).ToString();
        }
    }
}

Объекты в C++ имеют постоянный размер, известный на этапе компиляции и равный sizeof(экземпляр)

Утверждение:

объект класса может содержать и вектор ... а значит разные элементы массива(объекты класса) могут занимать разное количество байт в памяти.

неверно, так как вектор хранит свои данные не в своем экземпляре, а туда, куда их засунет аллокатор (обычно засовывает на кучу).

Утверждение:

[объект класса] и шаблонным может быть ... а значит разные элементы массива(объекты класса) могут занимать разное количество байт в памяти.

неверно, так как все шаблоны конкретизируются на этапе компиляции.

Следовательно, объекты класса сидят в массиве друг за дружкой, имеют фиксированный размер, и по ним можно ползать указателем, сдвигая его на этот размер.

Браузер - это ограниченная среда, каким бы ни был язык, за пределы возможностей этой среды он не выйдет, а значит не сможет предоставить программистам достаточно веских оснований для усложнения собственного трудоустройства. Попытки заменить JS периодически делаются, но не могут собрать критической массы разработчиков и отмирают. Можете попробовать изучить например Dart и устроиться с ним на работу.

А вы точно понимаете, что такое "поддержка нового языка"? Это целый долбаный интерпритатор в браузер тянуть надо (если язык интерпритируемый, для компилируемых есть webassembly ). А браузер и так много памяти потребляет

Язык, который был бы по сути тем же JS, но разрабатывался бы с нуля

Серьёзно, вы представляете себе масштаб работ? Попробуйте как-нибудь на досуге написать интерпритатор)

Получается, что JS развиваясь, становится все сложнее и запутаннее,

Имхо, за последние 5 лет JS стал... ну, не то чтобы проще, но точно удобнее. Я понимаю, о какой проблеме вы говорите, но новый ЯП не позволит отказаться от поддержки старых языковых конструкций JS . Просто добавится ЯП, где через 10 лет появится всё та же проблема с устаревшими вещами, от которых нельзя отказаться

Скобки int не закрыты.

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

Оправданием разрастанию стека является необходимость подстроиться под узкую специализацию задач (писать запросы к СУБД на CSS несколько странно, как и писать фронт на SQL).

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

Но вот идея написать в проекте на C++ кусок на Rust "патамуштамодна" - это скорее проблема, чем идея.