История изменений

Я бы не сравнивал переход от С++ к Go тем же самым, что и переход от ассемблера к С.

Переход от ассемблера к С закономерен. И является эволюционным развитием все того же ассемблера.

Ведь как вообще выглядело программирование вначале. Есть некое число, команда процессора. У нее есть операнды, числа, записанные после нее. Первый шаг - а может мы заменим числа коды команд некими мнемоническими обозначениями? И стало уже веселее. Человеку легче читать такой код.

Далее. Если у нас есть переходы между участками кода, можем мы эти участки кода оформить в виде подпрограмм? А чего бы и нет? И почему бы не заменить адреса переходов на некие названия подпрограмм? Так появились функции.

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

А это уже макро-ассемблер. Половина от компилятора.

Следующий шаг, как заменить выражение ADD rax, rbx; на c = a + b, уже было делом времени. Потому что ведь на самом деле программисты использовали одни и те же регистры каждый раз для схожих операций. Так почему же не вынести эту работу за скобки? Это дело времени и очередной закономерный виток эволюции.

Таким образом С не накладывает никаких накладных расходов. Все тот же макро-ассемблер.

–

Go - это все-таки совсем другое. Rust - не знаю. Проблема именно в отличии. Таких язычков появляется чуть ли не каждый день пачками. И умирают. А С - это старый добрый макроассемблер, который построен на соглашениях, соглашениях как вызывать функции, как использовать регистры. Это та работа, которая вынесена за скобки. Ничего не добавлено и не убавлено. Программисты на ассемблере делали все то же самое каждый день.

Я бы не сравнивал переход от С++ к Go тем же самым, что и переход от ассемблера к С.

Переход от ассемблера к С закономерен. И является эволюционным развитием все того же ассемблера.

Ведь как вообще выглядело программирование вначале. Есть некое число, команда процессора. У нее есть операнды, числа, записанные после нее. Первый шаг - а может мы заменим числа коды команд некими мнемоническими обозначениями? И стало уже веселее. Человеку легче читать такой код.

Далее. Если у нас есть переходы между участками кода, можем мы эти участки кода оформить в виде подпрограмм? А чего бы и нет? И почему бы не заменить адреса переходов на некие названия подпрограмм? Так появились функции.

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

А это уже макро-ассемблер. Половина от компилятора.

Следующий шаг, как заменить выражение ADD rax, rbx; на c = a + b, уже был делом времени. Потому что ведь на самом деле программисты использовали одни и те же регистры каждый раз для схожих операций. Так почему же не вынести эту работу за скобки? Это дело времени и очередной закономерный виток эволюции.

Таким образом С не накладывает никаких накладных расходов. Все тот же макро-ассемблер.

–

Go - это все-таки совсем другое. Rust - не знаю.