Хм... / it-юмор :: geek (Прикольные гаджеты. Научный, инженерный и айтишный юмор)

Примерно в 2010.
ФЯП (функциональные) и ИЯП (императивные) возникли почти одновременно — в 50-х годах. Функциональным был лисп, который жив до сих пор, но на этом и всё — их было слишком сложно компилировать, быстро с ними работала разве что лисп-машина, умершая в конце 70-х (более привычные ПК её вытеснили по закону Мура). Лисп-машина дала многое, но она не стала массовой.
Императивщина же была представлена фортраном (жив из-за накопившегося кода), алголом (мёртв), паскалем (еле ворочается) и бейсиком (аналогично). Большие изменения принесли в 70-х и 80-х C и C++. Они заняли все доступные ниши, а библиотека си стала системной, так как системы писались… на си и больше ни на каком другом языке.
В 90-х с новыми мощностями пришли языки, дающие гарантии надежности — эрланг, джава с её JVM и JIT, и пародия на джаву — шарп. Джава вытеснила си целиком с развитых встраиваемых систем (телефонов, а позже — смартфонов и планшетов), заняла прочное место в огромных проектах (потому что на си их писать было слишком небезопасно), где можно было жертвовать скоростью. В то же самое время появились первые претенденты на легкую распараллеливаемость — эрланг и хаскел, тоже гарантирующие надёжность благодаря математической основе. Хаскел стал потомком лиспа, который не был диалектом лиспа (за долгие годы это действительно уникальное событие). Но они были слабы в плане производительности, а поток по-прежнему был один.
На маках си отбросили — всё апи гвоздями стали прибивать к objective-c, а позже — к swift.
Ближе к 2010 джаву стали выталкивать её потомки, а сейчас и вовсе рекомендуется предпочитать kotlin (со слов представителей гугла).
Функциональные же языки наконец получили многопоточность и ресурсы для компиляции, а так же учли прошлые ошибки. Поэтому появились раст, эликсир, кложура и другие. Императивные языки не хотели отставать и принесли голанг, который за счёт стандартизации решений, широкой поддержке юникода и многопоточности обрёл славу надёжного и эффективного с точки зрения разработки языка (опять же относительно си). Но в нём до сих пор живёт сборщик мусора, появившийся со времён лисп-машин, потому на роль системного и встраиваемого он не годится. Другое дело раст — он захватил встраиваемые системы (avr, arm), графику (gfx — почти бесплатная абстракция над мантл-подобными апи, на которой строят webgpu и пользовательские движки), способен компилироваться в код для самих видеокарт (для opencl и скоро обещают подвезти шейдеры), да ещё на нём стали писать ОС (redox). То есть он может забрать оставшиеся ниши си.
Си был потеснён дважды — в 95 году, когда пришла более надёжная jvm и в ≈ 10 году, когда новые языки принесли скорость, многопоточность, встроенный юникод и очень высокую надежность. Он навсегда останется стандартом, как Вавилонская башня, между языками, но как самостоятельный язык он стремительно теряет силы. Его судьба в моём понимании — новый фортран, живущий за счёт древних проектов. Си пытается не отставать, встраивая дженерики (последний на сегодня стандарт), llvm, С++ вообще превратил себя в какую-то кашу, которую ни один компилятор полноценно не поддерживает. Их тянет на дно обратная совместимость, которая гвоздями прибита к реалиям 70-х.
Ну и ещё одна важная черта — отсутствие менеджера пакетов. В си они так и не прижились, зато слоями обрастали обёртки — makefile, cmake, auto tools… Да и само встраивание библиотек — дубовое встраивание одних исходников в другие, из-за которого современные автоконверторы на современных языках не могут нормально подключиться (приходится или использовать плохое подключение, или допиливать руками). Lex и yacc тоже себя изживают — создавать код на си так же сложно, как и обрабатывать вывод его компилятора, поэтому правки вносить очень сложно, зато внести правки в комбинаторный парсер очень легко — их популярность растёт.
Вот поэтому я называю си и его ближайшую родню устаревающими — они теряют популярность, их вытесняют, они справляются всё хуже со своей работой в новых реалиях.
Если я был излишне субъективен, то… прошу прощения и с удовольствием выслушаю альтернативную точку зрения — нужно знать как можно больше недостатков и плюсов, чтобы умело использовать их в будущем.