https://en.wikipedia.org/wiki/OSEK

http://makesystem.net/?p=2028#.V3di9fqmXeQ

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

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

так у gc, в отличии от ручной аллокации, ликов не бывает

я посмотрель ваш профиль на нн.

оставляя в стороне половой диморфизм(косаясь его тока этим абзацем).

вы наверно помните(из третьих рук), что Си в первых своих применениях на ряду с переписыванием уже имевшейся издательской системы патентного отдела - си стали использовать в merv-системе и в специализированных аттишных железках комутаторах - из тех же задач из пролога(который из лиспа) ерланг вырос.

в ерланге одно из решений языка - что задач много и желательно падать если чё не так.

в си(читай лабораторном юниксе) 70ых так и было организованно почти всё - если чё не так - бросай кору - и либо(в случае «разбирательств») постмортем отладка либо(когда упал «подпроцес») надзирающий процесс(ака супервизор) примет какие запланированно меры - отсюда и сотрудничество беллабс с Хоаром и даже < чёт не находится книга с птичками на обложке про отладку многопроцессных реализаций через чёткие интерфейсы и состояния>

и повторюсь вы ведь уже пользуетесь стеком - и даже если апаратно его нет не гнушаетесь его эмулировать подсобными средствами.

и таки да - для индустриального способа бывает выгодно найм малоквалифицированных толп готовых очень тщательно полировать код.

питон не универсален как и си

у питона очень понятная ниша и даже gil пока не достаточный для прекращения роста питонопользования недостаток.

как шелл над си-реализованными кусками вполне годный ибо его модель последовательностей вполне удобна.

советую вам ознакомиться с любой виртуальной машиной реализующей байткод питона - там вполне годного много.

вы же в курсе что google golang не от хорошей жизни создала.

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

я не спорю, что у питона есть ниша: обучение студентов и мелкие скрипты на коленке (хотя тут есть гораздо лучшие варианты типа lua). но нельзя его тащить в продакшн. он не приспособлен для нагрузок и никогда не будет приспособлен. в питоне есть одно главное зло: его фактическая однопоточность. она убивает его производительность на корню. и есть ещё куча мелких зол с выделением памяти, которые убивают его эффективность. это нельзя исправить, не переписав его весь с нуля и его автор явно не собирается этого делать.
я не лезла в golang, если честно. но там тоже есть свои тараканы, судя по всему. я со стороны наблюдала, как на нём реализуют сетевой фильтр. ну, что я могу сказать... он, конечно, работает. но ценой каких ресурсов! в общем, пока что конкуренции С/C++ для софта, который должен молотить данные с большой скоростью, объективно я не вижу. я не спорю, что проще выучить сто программистов на питоне, чем одного на С. но оно того стоит, когда вопрос стоит об эффективности.

а насчёт мракобесия

вот займите свой досуг:

https://psoberoi.github.io/stepanov-civilization/canon.html

ps. челу не мешало при умении в С уметь в прочие ады схемы и плюсы

http://www.stepanovpapers.com/

У питона гораздо более обширная ниша.

мелкие скрипты

По факту, на нем написано очень много больших проектов типа серверов eve online или dropbox, Или вещей типа openerp или openstack. Если бы там всё делали на си - не закончили бы никогда.

эффективность
производительность

Да, числодробилки на нем писать глупо, ниша у него другая. Но ниша числодробилок и сетевых фильтров и молотилок данных с большой скоростью в современном мире уже, чем ниша питона.

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

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

не осилили ничего более стоящего

Например?

разработчиков. они просто не осилили

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

жрут так много ресурсов

У вас профессиональная деформация. Не все считают каждый байт/такт процессора, тем более bottleneck где-нибудь в сети, IO или базе данных. Тем более железо дешевое, а вермя разработки - нет. И не только в плане стоимости времени разработчиков - за месяц, который вы потратите на оптимизацию какой-то ерунды или отладку, чтобы сэкономить копейки на железе, конкурент сделает какую-нибудь киллер-фичу и вы потеряете всех клиентов.

А неэффективно - это не требуется от glue кода. Давайте все конфиги и логи хранить в двоичной форме вместо текста, откажемся от текстовых протоколов типа http. От баш скриптов в конце концов. Всё будем писать в машинных кодах и оптимальных структурах данных. Есть вопрос удобства и простоты.

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

Про Java что скажете?

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

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

это_не_тролинг.jpg

https://ru.wikipedia.org/wiki/Домострой_(Ксенофонт)

если переписать всю ересь на питоне на С (да даже на плюсах), то работать оно будет «хорошЕе» раз этак в сто, как минимум

Нет, не будет. Потому что затык в сети/диске/базах данных(которая уже на си). Это io-bound приложения, а не числодробилки. Зато падать оно будет чаще(легче выстрелить в ногу и допустить ошибки вот тут покопаться хотя бы http://www.viva64.com/en/a/0084/), сложнее будет вносить измнения(потому чо код на скриптовых языках очень плотно покрывают тестами), сложнее развивать.

Любые крупные компании типа гугла используют и питон и си и плюсы и java, там где это целесообразно - пишут на си.

ставить десять серверов там, где может справиться и один

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

начинается уход с питона.

Не начинается. У этих языков просто разные ниши.

Да, бывают что делают какой-то макет и прототип на питоне, а потом переписывают на языкнейм, и то, чаще какие-то критические части, а не весь. Но это отдельный случай.

Ах да

чтобы не нужно было много думать.

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

десять серверов там, где может справиться и один? зачем жрать сто гигабайт если хватит и десяти

Даже если бы это было так - это всё мелочи, в контексте того, что.. Как я уже писал выше, пока вы будете экономить на спичках, конкуренты - говнокодеры на скриптовом языке выкатят готовый продукт и будут добавлять новые и новые фичи, нужные юзерам и получать прибыль. Как питоноподелия типа dropbox, instagram, disqus, etc, etc. А вы вылетите из бизнеса вообще, зато на памяти и серверах сэкономили(ценой отладки месяцами). И на оплату труда кодеров за эти месяцы вы потратите куда больше чем стоили бы лишние сервара, особенно учитывая недополученную прибыль.

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

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

Тут проблема не в манагерах, а в рыночке и конкуренции. Приходиться гнать. Хотя, конечно, бывают разное и откровенно плохие продукты. Чаще правда, такие плохие продукты - что-то, что пишут для внутреннего использования - иногда специально делают некачественно, чтобы больше разаботать на поддержке, заказчик тоже иногда в курсе и в доле или ему плевать.

Но критерий качественности это явно не какие языки и технологии использованы. Это вообще какой-то максимализм и фанатизм. Как и не всегда так уж важна производительность. Простой пример - какая разница жрет какое-нить GUI приложение с формочками к БД 1мб оперативки или 200мб, если любая офисная машина его одинаково тянет. Или там вебсайт - когда он начинает тормозить, его не переписывают на другом языке, а оптимизируют БД, прикручивают кэши всякие. Некоторые начинают изобретать под свои нужны очередные nosql хранилища.

А питон, он в своей нише скриптовых языков, которая весьма востребованна смотрится неплохо. Выразительный, простой, с большой стандартной библиотекой и встроенными типами данных, которыми удобно пользоваться. К тому же, у него адекватный C API и легко делать биндинги ко всему, поэтому их так много. И производительность у него адекватная на фоне языков этого же класса.

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

это понятие не абсолютное, а очень относительное

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

С часть целого.

если переписать всю ересь

http://www.softpanorama.org/scriptorama.shtml

s/merv/mert/

https://en.wikipedia.org/wiki/Multi-Environment_Real-Time

< чёт не находится книга с птичками на обложке про отладку многопроцессных реализаций через чёткие интерфейсы и состояния>

https://en.wikipedia.org/wiki/SPIN_model_checker

а конкретно птички

Gerard J.Holzmann. Design And Validation Of Computer Protocols

об археологии языков программирования и границах(умозрительных в головах некоторых неофитов):

http://www.iwriteiam.nl/HaCAR_CDR.html

в вышеуказанном и про дин.память и про тегирование и про представление NIL и атомов

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