Станислав Макаров

Компьютерная графика - очень большая и сложная область. Обучаться до конкурентного уровня нужно очень усердно и очень долго.

С чего стоит начать. С математики, начала анализа, геометрии, линейной алгебры, с теории множеств. С физики, оптики и механики.
В этих областях информации нужно буквально плавать.

Куда двигаться дальше. В инженерию П.О, в архитектуру П.О, в шаблоны проектирования, в общие концепции разработки программ. Языки программирования на этом этапе все еще не нужны, т.к. архитектура оперирует терминами над инструментами разработки. В наше время очень много талантливых и образованных разработчиков компьютерной графики, но их ярким отличием является абсолютная бездарность в инженерии и архитектуре П.О. Они считают что раз математику и физику знают, то остальное им не нужно. Это должно стать их фатальной ошибкой в конкурентном плане. Сегодня системным инженерам приходится за такими людьми хвосты чистить и слушать их брюзжание о том, что их прелестный код снова испорчен и ничего опять не работает.

После этого двигаться стоит в сторону инструментов разработки. Их должно быть несколько. C# и F# ты знаешь, это хорошо. Java будет прекрасным дополнением. Настоящий инженер не имеет права зажимать себя рамками одного лишь инструмента, это будет его минус в конкуренции. Rust слабо востребован и мало применяется, но знать его на некотором уровне будет просто полезно в качестве инвестиции и для общего развития. C++ сильно распространен и сильно востребован, однако рынок труда сейчас переполнен слабыми середнячками, которые мало на что годятся в реальной работе, а C++ является крайне сложным инструментом и не позволит тебе быстро начать с ним работать на том же уровне, на котором тебе позволяет тот же C#. Поэтому если брать C++, то уходить в него надо прямо очень серьезно для того чтобы получить конкурентное преимущество перед описанными выше людьми.

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

Компьютерная графика - это не треугольнички рисовать. Это одна из самых сложных для обучения областей на сегодня.
Просто посмотри в 7-м разделе примерный список книг, с которыми нужно ознакомиться.
По окупаемости сказать ничего нельзя. Все зависит от тебя лично и от твоих личных качеств. Станешь лучше остальных соискателей - все окупится.

хеллоуворд видится как какой-то буддистский коан.

Минимальный современных хеллоу ворлд выглядит так:
Console.WriteLine("Hello world!");

Чтобы разобраться во всех следующих пунктах тебе следует продолжать изучать (хоть по курсу, хоть по книге), иначе всё расписывание само по себе потянет на небольшую книгу, или хотябы брошюру, и при этом врядли как-то тебе поможет:

1. Можно просто убрать этот конкретный using, используя global usings или используя полные имена типов
2. Можно не писать namespace или написать любой свой собственный. Или можно использовать file scoped namespace
3. Можно придумать своё имя класса, можно сделать его статичным, можно сделать явно приватным или публичным.
4, 5, 6. Main (точка входа) обязан быть статичным. Другие методы могут быть не статичными.
Main можно сделать публичным или приватным, можно дать другое имя, но тогда придётся в опциях компилятора указать, какое имя.
Main можно сделать асинхронным - тогда вместо void или int (Да, он может возвращать int) будет Task или Task<int>
7,8,9. string[] args можно не указывать, или дать этому параметру другое имя (не args), но принимать что-то иное нельзя
10,11. Это уже относится к телу метода и оно может быть любым. Но вместо Console.WriteLine можно написать полное имя - System.Console.WriteLine или сделать using static System.Console и тогда можно будет написать просто WriteLine

Почему ни кто не читает документацию????
https://doc.qt.io/qt-6/resources.html

If the user's locale is French (i.e., QLocale::system().language() is French), :/cut.jpg or qrc:/cut.jpg becomes a reference to the cut_fr.jpg image. For other locales, cut.jpg is used.

See the QLocale documentation for a description of the format to use for locale strings.

See QFileSelector for an additional mechanism to select locale-specific resources.

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

Какая разница между clang и GCC.
Разница большая. GCC обладает обширной поддержкой наследия идиом и конструкций из языка C, которые, вынужденно или по своей воле, поддерживает в современном C++.
VLA, тип по умолчанию, всевозможные изыски синтаксиса C. Это все GCC не глядя принимает за C++ код и позволяет трансляцию.
GCC даже сегодня многократно нарушает стандарты C++ просто потому что выбрал стратегию поддержки экзотической функциональности C в коде C++. Так же GCC не хвастается и скоростью поддержки стандартов C++.
В 2016 году Google полностью отказались от поддержки GCC в Android NDK из-за слишком плохой поддержки стандартов и слишком свободного следования стандартам C++. В этот момент GCC стал неконкурентоспособным относительно оставшихся двух самых широко используемых трансляторов.
Clang же, наоборот, сегодня считается, буквально, бастионом идеального следования стандартам C++. Clang точно поддерживает стандарты во всех деталях, максимально быстро интегрирует изменения и добавления стандартов, позволяет в самых первых рядах поиграться с функциональностью из драфтов следующего стандарта C++.
Clang обладает обширной системой статической и динамической проверки кода: богатый статический анализ, возможность подключения санитайзеров, поддержка C++ Core Guidelines, очень качественные отчеты об ошибках трансляции, хорошая скорость трансляции.
Это все ставит clang в предпочтение перед GCC на третьих для GCC платформах.

О полной совместимости между трансляторами.
Полная совместимость между трансляторами есть. Иначе я бы не мог делать то, что я делаю. А дело мое заключается в создании полностью кроссплатформенного кода, который однозначно собирается на всех целевых платформах и на всех них выполняется так же однозначно.
Полная совместимость между трансляторами заключается в строгом соответствии кода выбранному стандарту C++. Всё, точка. На этом к трансляторам требования заканчиваются.
Только тут есть небольшая проблема. Каждый транслятор по-своему поддерживает стандарт и по-своему реализует неоговоренные стандартом механики. Каждый транслятор имеет свои ошибки трансляции. И вскрывается это все именно в процессе работы над кроссплатформенным кодом.

Я в своей работе видел многое. Я видел как при смене GCC на clang люди хватались за голову и отказывались от последнего просто потому что он нашел горы нарушений стандарта, которые молча принимал GCC. Я видел как группа из 5 человек 3 месяца рефакторила код при переходе с MSVS2015 на MSVS2017 (т.е. просто при смене версии транслятора) просто потому что разработчики из рук вон плохо знают используемый ими стандарт C++.
Я видел ошибки в clang, приводящие к неверной генерации кода. Я видел ошибки в GCC, не позволяющие использовать его для кроссплатформенной сборки. Я видел ошибки в MSCL, в результате которых последний явно нарушает стандарт, а команда его разработки отказывается это исправлять потому что "иди нафиг".

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

Самый надёжный способ вычистить репозиторий от файла — использовать скрипт filter-repo

# клонируем репозиторий в соседний каталог
# иначе придётся использовать ключ --force
git clone --no-local . ../clonerepo/
# переходим в свежий клон
cd ../clonerepo
# чистим
git filter-repo --path "path/to/file" --invert-paths
# проверим что файл исчез
git log --all --oneline --name-status -- "path/to/file"

class Test
{
    public T X<T>(T x) => x;
    public T X<T>() => throw new InvalidOperationException();
}

typeof(Test)
.GetMethods() // Берём методы
.Where(x => x.Name == "X") // с именем "X"
.Where(x => x.IsGenericMethod) // обобщённые
.Where(x =>
{
    var parameters = x.GetParameters();
    var genericParameters = x.GetGenericArguments();
    // У которых только один generic-параметр и 1 аргумент, которые равны
    if (parameters.Length == 1 && genericParameters.Length == 1)
    {
        var t0 = parameters[0].ParameterType;
        var t1 = genericParameters[0];
        return t0 == t1;
    }
    else
    {
        return false;
    }
})

Сейчас редко нанимают чистых растаманов, тк язык молодой.
Обычно нанимают тех, кто переходит с других, более традиционных языков.
Так что тебе сначала надо стать мидлом/сеньором в C++/Java/C#/C а потом дотянуть знания раста, чтобы уметь на нём решать задачи, аналогичные тем, которые ты решаешь с основным языком.

Ну и соответствующий коммерческий опыт ~5 лет.
Учитывай ещё и специфику Rust-проектов: это что-то новое, что требует безопасности и эффективности, где нельзя/нежелательно/невозможно использовать "Традиционные" языки.
Так что и уровень ответственности и требуемых знаний будет выше, чем на аналогичную, например Java-позицию.

Из обсуждения https://github.com/golang/go/issues/50182 видно что проблема с производительностью generics не новая.
При запуске бенчмарков с флагами получается ожидаемое мной ± равное время выполнения ф-ций:
go test -bench=. -count=2 -gcflags=all=-d=unified

BenchmarkNativeFunc-4            2029149               600.5 ns/op
BenchmarkNativeFunc-4            2018277               591.7 ns/op
BenchmarkNativeMethod-4          1962086               592.0 ns/op
BenchmarkNativeMethod-4          2024234               603.9 ns/op
BenchmarkGenericFunc-4           1985313               573.4 ns/op
BenchmarkGenericFunc-4           2053454               585.1 ns/op
BenchmarkGenericMethod-4         2067790               591.3 ns/op
BenchmarkGenericMethod-4         2054346               612.2 ns/op

что форсирует применение при компиляции stenciling (трафарет по отдельным типам) вместо словарного подхода реализации дженериков (текущая реализация).
Остаётся ждать оптимизаций в обновлениях языка

Там же написано

Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.

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

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

Во-вторых, часто неизвестно заранее, сколько и каких ресурсов надо будет выделять. Плюс ресурсы могут быть использованны в куче разных функций, а значит должны жить глобально или отдельно от какой-то одной функции (например в main), но тогда все будет в куче в одном месте и это тупо неудобно.

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

Edit: да, если вам нужно больше стека, можно сделать так, чтобы программа получала больше стека. В С++ это делается параметром линкера.