В Go есть ООП, а в C нет?

Пару шурупов можно и отвёрткой закрутить, но когда планируют провинтить, например, пол в крупном помещении - обычно берут шуруповёрт. Так и здесь - когда будут делать крупный ООП-проект с обильным наследованием, скорее всего возьмут ООП-язык. Это не означает, что без него невозможно, но писать какую-нибудь бизнес-логику, UI или игровую логику на макроассемблере никто в здравом уме не будет.
Для небольшого бэкенда может и сишка с макросами подойти, но здесь идёт речь о минималистичности.
Мне даже под vulkan писать на чистом Си не удобно - там структуры большие, шаблонов нет, скорее всего без промежуточного кодогенератора/стороннего препроцессора не обошлось бы, хотя конечно 90% сложностей там решается обычными макросами

да, возьмут язык с ООП потому что его абстракции будут ближе к языку описания бизнес-логики, и проще и быстрее будет написать.
любимый бизнесом быстрый «тяп-ляп и в продакшен» :)
тот же дизигнер никогда не будет оперировать «завинтить пару шурупов отверткой»
всё б было бы хорошо, если компиляторы делали высокоинтелехтуальными. но приложение делают на джава-скрипте обмазывают электроном и получается тяжелый ресурсоемкий монстр.
если ты этого желаешь от видеодрайвера vulkan - ю а велком

фигасе, «для небольшого бэкенда». так-то на сишке много всего написано. и маленького, и очень большого. вопрос не в ЯП, а в квалификации того, кто пишет. если голова на плечах, а руки откуда надо растут, то и сишка вполне безопасная, и никаких проблем со структурами и прочим нет. опыт, опыт и ещё раз опыт.

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

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

а сейчас макаки ещё и сгенерированный всякими «ИИ» шлак туда натащат и будет ваще «караул!». это ж голубая мечта всякого ленивого дурака: чтобы «по щучьему веленью, по моему хотенью...». но реальность такова, что всё это не работает. но, безусловно, это будет усукагублять общую проблему говнокода и блоатвари и всё дальше ухудшать общее состояние софтостроения.

Если говорить про ООП синтаксический сахар, то в Go есть ещё интерфейсы, коих нет в C. В C нету какого-либо специального сахара для ООП. По такому критерию многие относят C к языку без ООП.

Но с другой стороны, в принципе практически на любом языке можно писать в ООП стиле и C не исключение. Просто методы будут обычными функциями, берущим указатель на структуру с полями объекта первым аргументом. Виртуальные методы будут обычными полями структуры типа указатель на функцию (опять же, по соглашению первый аргумент будет инстанс объекта). Либо можно сделать отдельную структуру с указателями на все виртуальные функции и хранить указатель уже на неё в одном из полей основной структуры. Наследование реализуется через встраивается структуры родителя первым полем в ребёнка и кастами типа указателя туда-сюда в зависимости от того вызываем ли мы метод родителя или потомка.

Такой подход применяется во множестве сишных программ и библиотек. Даже банальный libzip принимает некое подобие такого объекта с виртуальными методами для возможности создавать кастомный ридер данных архива. Есть и комбайны типа GLib и построенным на нём GTK, которые активно используют ООП и позволяют расширять прикладному коду.

extended variety, т.е. расширенное на столько, что пришлось дать отдельное имя ESPOL.

Идея алгола и паскаля, что поставщики сами добавят туда нужные расширения. Ядро тоже не на С написано, а на GNU C. В алголе даже небыло функции печати.

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

Я думаю оригинальное высказывание kaldeon, это про мнение, что до UNIX все операционные системы писались исключительно на ассемблере, без применения высокоуровневых языков. OS/360 вышла позже B5000, но была написана на ассемблере по большей части, если верить википедии, с VMS тоже самое.

А сам C уже давно не соответствует железу, это иллюзия

Он никогда ему не соответствовал в полной мере, он соответствует средней машине, и за счет этого является переносимым. Там не было многих возможностей PDP-11, и не будет многих возможностей x86, иначе это будет язык под конкретную платформу.

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

int64_t mul(int64_t a, int64_t b) 
{
    return ((__int128)a * b) >> 32;
}

mul:
mov rax, rdi
imul rsi
shrd rax, rdx, 32
ret

int cmp(uint64_t a, uint64_t b)
{
    return (a > b) - (a < b);
}

cmp:
cmp rdi, rsi
seta al
sbb al, 0
movsx eax, al
ret

OS/360 вышла позже B5000, но была написана на ассемблере по большей части, если верить википедии,

Мне верьте.
На ассемблере.
У меня были исходники OS-360.
Собственнно в те года в СССР были исходники любой ОС и не было никаих проблем вять ленточную катушку, поехать и переписать исходники и бинарники.
Тогда была совсем иная духовная атмосфера.
Смысла писать о ней нет, так как воспримут это как сказку или обман.

На каком сайте возможно познакомиться с девушкой?

Немножко об этом треде.

Ребята очнитесь.
В этом мире есть много более интересного чем «подюпочные технологии».

Мне вас искренне ЖАЛЬ.

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

Прямой вопрос - что вы все кодите? Формы на кутях и обработку жсона по кнопке ok?

Покажите или расскажите пример реальных программ. Я знал пару местных, но они ушли отсюда.

Вот её например просишь показать код или реальный какой-то продукт итоговый, а она говорит «не могу показать».

Ясно)

Вот её например просишь показать код или реальный какой-то продукт итоговый, а она говорит «не могу показать».

Бывает такое.
Лет десять назад разработал вэб интерфейс для 1С 7.7.
Функионировал он как ныне вэб интерфейс 1С 8,3.
Программистам ничего в конфигурации добавлять не нужно было кроме использования дополнительно одно внешней компоненте.
Хотел поделиться с другими и выложить код и бинарник в inet, а начальник не разрешил.
Ныне вот на подходе хранилище данных в которое в частности можно загрузить конфигурации 1С 7.7 и 1C 8.3.
Конечно формат хранения метаданных и данных не такой как в 1С.
Так помимо этого можно будет разрабатывать графические и мультимедийные приложения и …

Так что - «всему своё время».
А ВК для 1С 7.7 теперь нет смысла публиковать.

Конечно хранилище данных разрабатываю не в пику фирме 1С.
Просто конфигурации 1С весьма хороший тест для разработки core API.

Не вините Iron_Bug.

Кстати вот и у меня дилема - публиковать исходники или нет.
Опубликую и народятся проприетарные а-ля PostgressPro.
А цель то совсем иная …