Cамо сравнение по скорости языков программирования по иx названию, уже лоллище.. от коротого сползаешь под стол ...

.clocker
от того, что сократили слово "написанная на %prog_lang%" ничего не изменилось. Тебе-то, немецкому специалисту, это должно быть очевидно.

Ну господа к "группе" языков Си относиться тот же С# (который Net) и если говорить о скорости (точней возможной не типичного подхода к программированию) Си (именно С без знаков) наиболее пластичный язык которым написан весь мир ОС и тд фактически какой нас окружает.
С++ это язык уже более жесткий и я б не сказал что он так же крут как и чистый Си. Про Шарпы и Джавы можно говорить как о си подобных языках... и неком будущем, но меня тянет блевать от такого будущего.
Нет я согласен что Джавы и подобное хорошо в производстве где чаще всего задачи утилиты "выполнила свою работу и хорошо" и где через год о ней никто не вспомнит, но не на конкретных системах пользователей. Если я поставлю все на "net" или "jvm" то у меня система просто зависнет и больше работать не будет. (вы просто никогда не запускали 10 быдло утилит на байткоде).

Тут меня конечно посчитают опять фаном аппла, но фактически лучшей адаптацией Си под новые правила является objective-c, но не сам язык, а инфраструктура вокруг. Тенденция снижения кода на Си сейчас даже в Линуксе уже начинается все стремятся писать на чем то "повыше" и забивают на 0.1% производительности. правда 10 таких "повыше" вставок это уже 1% - вы скажите 1% производительности системы пф пф... а через 10 лет?!

Современные компиляторы которые компилируют программы непосредственно в исполняемый бинарный код процессора состоят из двух вещей: фронт-энд который парсит программу написанную на каком-то языке программирования и сам компилятор, который из этого промежуточного результата делает исполняемый код. То есть чтобы добавить в компилятор поддержку языка достаточно сделать для него фронт-энд, после чего компилятор будет собирать из нее бинарник так-же клево, как и из других языков, т.к. оптимизации идут уже после фронт-энда. GCC поддерживает кучу языков, включая такие древние, как ада, или фортран, clang поддерживает с, с++, objective-c, еще что-то. В этом плане говорить, что какой-то из языков поддерживаемых данным компилятором будет быстрее других просто бред.
Но кроме обычных языков, есть интерпретируемые языки (всякие перлы, жабаскрипты, баши и т.д.) и управляемые, когда программа компилируется в промежуточный байт-код который выполняется специальной средой выполнения (джава, c# и т.д.). Интерпретируемые по-определению самые медленные, скорость выполнения программ исполняемых средой выполнения в некоторых случаях на уровне обычных программ, но, как правило, все-таки ниже их хоть и не особо значительно в последнее время. Правда памяти на них тратится намного больше во-первых на саму среду и ее библиотеки, во-вторых объекты удаляются не сразу а специальным сборщиком мусора.
Тем не менее среды выполнения довольно популярны там, где разрабатывается серверный код, всякие банковские системы и т.д., тормоза там основные при запуске, т.к. в отличии от интерпретируемых языков процессорный код из байт-кода компилируется только один раз в момент запуска/первого обращения и при повторном обращении используется уже то, что было скомпилировано ранее.

C++, кстати, до сих пор довольно динамично развивается.

у меня есть не один пример, когда даже самая простая программа на C# работает быстрее, чем на С++. So?

Вы просто видимо никогда не пытались написать задачу сложнее "напишите мне прошивку на контроллер ZU-H538GT"

В одной фразе свалили в кучу JIT и интерпретируемые языки... А это две большие разницы ©

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

Зато работа GC быстрее ручного управления памятью

я на это уже ответил:

простые программы окей! а дальше что?

да ну не врите сами себе. я писал консольные вещи и на плюсах и на шарпе ) то есть мс vs компиляция... даже при таком раскладе сама утилита меньше весит в памяти чем ее сородич на шарпе (где то на треть) а если прибавить Нет весящий в памяти это будит чистая победа по фейлу.

mag_ai с чего бы мне врать? Я тоже и плюсы уважаю, и шарп. 3мб весит некоторые системные вызовы CLR и прочие, они занимают фиксированный объем, как бы.