D, Go и Rust, взлетит ли что-нибудь?

Кстати что за проблемы например? вываливание фотографии

Это не проблемы языка программирования, а проблемы приложения. Мы же вроде ЯП тут обсуждаем, а не вк. Я понимаю, что проблемы сайтиков тебе ближе, но всё же не отклоняйся от темы.

А самые насущные проблемы ЯП, это писать меньше кода для рутинных операций, избавляться от копипасты, освобождать ресурсы там же, где ты их выделил. И за последние 30 лет прогресс здесь огромный. И есть реализации, которые не приводят к тормозам.

Если будет типо-безопасный си, с защитой от утечек памяти, то ...

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

Тоже в штанишки дудонишь?

Дрочишь на свою уникальность, при этом ничего больше 1000 строчек не писал?

хоспидя, какой же ты идиот...

найдется ни одна сотня индусов, которые и на этом наговнокодят

Спасибо кэп. И что?

хоспидя, какой же ты идиот...

Прости, о мудрейший, что посмел с тобой заговорить. Подумал, что ты всё таки обладаешь интеллектом. Видимо ошибся.

Си и так нормальный языке в своей нише

Си - устаревшее говно. То, что пока нет ничего лучше, не меняет этого простого факта.

какой-то таилганнер его ниасилил

Утипути.

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

«Подсунули ей железный лом. „КРЯК!“ — сказала пила. „Ага, бля!!!“ — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес топорами»?

Примеры java|python|.net

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

у этой сказки будет другой финал. Суровым сибирским лесорубам будут всучивать все новые и новые пилы, и времени на то, чтоб валить лес у них не останется. Они будут инструкции изучать. Ну может свалят пару сосен.

А потом придет очередная корпорация и скажет что rust/go/ocaml/чтототутеще это говно-пила и надо новую язык-пилу или, еще лучше, пилу-технологию (!!!)

А браузеры как тормозили и жрали память, так и будут. прогресс, мать его.

А браузеры как тормозили и жрали память, так и будут. прогресс, мать его.

Но ведь прогресс остановился 30 лет назад, когда браузеров не было. NNTP твое всё. Или UUCP. Оно точно не тормозит и память не жрет.

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

очень медленно и мучительно отвоёвывают себе внимание и место под солнцем

Очень быстро заняли свои ниши, и дальше ничего отвоёвывать не будут. Ибо не должны.

никто не стремится полностью портировать под новый язык

А зачем это кому-то может понадобится? Только ради фана. А ради фана мало чего делается. В особенности бесполезного.

ради повышения скорости многие модули намерено переписываются на старых языках (си и даже ассемблер)

Покуда ничего высокоуровнего быстрее сишки нет, там где нужна скорость будет править сишка (с крестами в обнимку). Только скорость нужна в небольшом объёме кода.

Там где от производительности программы напрямую зависит прибыль

А вот здесь хотелось бы пару примеров из несистемщины. Понятно, что linux-kernel должен быть маложрущим. А вот большие приложения должны эффективно масштабироваться. И сишка и прочее байтодрочерство здесь сильно вредит.

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

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

Уровень подготовки отдельных школьников с дипломами Кембриджа (лол) не говорит ровным счетом ни о чем.

Давай список фич, добавленных в Си (не в стандарт, а в язык) после 1985.

Тебе VLA мало штоле?

А всякие там векторные расширения? А OpenMP?

А вот здесь хотелось бы пару примеров из несистемщины.

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

с какого нибудь PHP на C++ (или куда там фейбук перешёл)

Может быть я ошибаюсь, но емнип фэйсбук написал HHVM под себя. А HHVM это пыха с плюшками.

Базы данных - да, они все сплошь на си, за исключением пары nosql на жабе. Но в этом они сродни библиотекам. Для них нужна скорость, и поэтому их пишут на си с крестами. И это оправдано. Но БД - это всё таки системный уровень, а не прикладное приложение. Так что давай ещё примеры.

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

Я точно не знаю, но могу предположить, к примеру в высокочастотном трейдинге, где уже не хватает скорости оптоволокна и конкурентным преимуществом считается сигнал доставленный на 100 милисекунд быстрее, как думаете долго будут мириться «приемлемой» производительностью?

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

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

ну знаете IT мир ядром и окошечками не ограничивается

Несомненно это так.

идёт борьба за милисекунды

В таких компонентах даже кресты не очень часто можно встретить.

Но мы начинали разговор про

массового перехода на них значительной части индустрии не произойдёт

А то, что ты описал выше - весьма специализированные случаи.

100 милисекунд быстрее, как думаете долго будут мириться «приемлемой» производительностью?

В таких системах объём кода, влияющий на эти 100 миллисекунд крайне мал, в сравнении с остальным кодом. Поэтому, например, nginx написан на си, а остальное на пыхе/жабе/питоне и т.д.

И переписывать даже фэйсбук, при их то масштабах, на си/кресты никто не спешит. Дешевле оптимизировать пыху.

А при меньших масштабах куда дешевле поставить десяток доп серверов, чем нанимать два десятка сишников.

А в прикладных вещах от си уже давно ушли на языки на порядок медленнее. И все довольны, даже пользователи.

Это да. Но на жабкин паровоз не все успели, и там уже полно народу. А на гоу ещё можно купить билеты. Книга Кернигана скоро выходит, опять же. Вот некоторые и чешут бороду, что кроме C и C++ изучить.

Но мы начинали разговор

это всё были примеры того

где от производительности программы напрямую зависит прибыль

а что касается

массового перехода на них значительной части индустрии не произойдёт

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

А при меньших масштабах куда дешевле поставить десяток доп серверов

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

и когда у тебя сервера имеют больше 10 ядер загруженных на 100% 24 часа 7 дней в неделю, и оперативной памяти больше чем места на дисках и забита она тоже на 100%, но не дисковыми кешами, и программа не сидит в блокировке потоков или ожидании сетевых пакетов, то есть когда оптимизировать больше нечего, тогда ты узнаешь что такое хардварные счётчики и будешь оптимизировать программу изменением порядка ассемблерных инструкций только потому, что больше уже ничего не остаётся, но надо ещё хотябы 1%

А в прикладных вещах от си уже давно ушли

но осталась куча библиотек которые на низком уровне выполняют всю ту работу (например кодирование\декодирование) которую невозможно переложить

на языки на порядок медленнее

иначе это будет настолько медленнее что даже пользователи будут недовольны.

Тебе VLA мало штоле?

Так, как они сделаны - да, маловато. Но условно засчитаем как новую фичу.

А всякие там векторные расширения?

Конкретные названия - в студию. Обычно операции над векторами в Си сделаны библиотеками.

А OpenMP?

Расширение языка прагмами... ладно, засчитываем.

Итак, за 30 лет - VLA и OpenMP. В основном домене Си - системном программировании применимы только VLA. Охренеть прогресс.

про «30 лет назад» другой аноним говорил, поняшка

Прокурору расскажешь, аноняшка.

безопасность указателей

Не нужно, потому что без адресной арифметики невозможна куча трюков.

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

Нет ни одного по-настоящему эффективного (с точки зрения «железа») высокоуровневого языка, а неэффективных как собак нерезаных, так что еще один попросту не нужен.

Погугли уже про ржавчину.

Мне как-то показывали, как в этом говне адресная арифметика выглядит. НЕНУЖНО и НЕ ВЫСТРЕЛИТ. Можешь скринить.

Нет ни одного по-настоящему эффективного (с точки зрения «железа») высокоуровневого языка

define эффективность

Ну в общем со всем описанным тобой я ни в коем случае не спорю.

Видимо под массовым переходом на них значительной части индустрии мы понимаем разные вещи.

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

Мне как-то показывали, как в этом говне адресная арифметика выглядит

А она точно нужна?

Обычно операции над векторами в Си сделаны библиотеками.

Чего?!? Altivec не библиотека. https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

Расширение языка прагмами... ладно, засчитываем.

Тебя колышет, как именно семантика реализована? C изначально так строился, чтобы его можно было атрибутами и прагмами безболезненно расширять, не насилуя существующий синтаксис.

В основном домене Си - системном программировании применимы только VLA

Этот «эксперт» мне тут сейчас будет рассказывать за то, как целочисленные векторные операции не нужны в системном программировании. А я буду ржать.

Из несистемщины ещё можно вспомнить про базы данных которые

хм, может я перегибаю, но из того что я наблюдаю - каждая вторая на Java

к примеру в высокочастотном трейдинге

вот уж кто не нужен - так это спекули всяческие

Altivec не библиотека.

Altivec это вообще набор команд. Специфичный для PowerPC.

https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

И что? В GCC даже typeof есть, который не включили в Си из-за того, что он якобы недостаточно полезен. Ты мне еще про Ivy расскажи.

Этот «эксперт» мне тут сейчас будет рассказывать за то, как целочисленные векторные операции не нужны в системном программировании

Я сказал «OpenMP». Читать научись, чучелко.

я буду ржать

В штанишки не насцы.

Что б ты вообще знал за эффективность и за железо, ламеришко из Мухосранска?!?

Сишка старый язык и весь его путь развития обременен обратной совметимостью. Начать стоит с выпиливания всякого мусора, потерявшего актуальность.

Что касается добавить - вот ты же сам пишешь про gcc-шны расширения, неплохо бы все это пересмотреть и засунуть в стандарт. Расширения раширениями - а стандарт лучше.

Если идити еще дальше, то не надо думать, что Сишка - идеальный кроссплатформенный ассемблер, Rust с его zero weight abstractions выглядит на эту роль более привлекательно.

Rust с его zero weight abstractions

Они не его, а крестов. Пока раст генерирует более тормозной и прожорливый код. Так что, видимо, не zero. Или руки кривые у разработчиков.

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

Начать стоит с выпиливания всякого мусора, потерявшего актуальность.

с адресной арифметики (например)? :)

Для высокоуровнего ассемблера не получится. В том же Rust есть адресная арифметика.

Начать стоит с выпиливания всякого мусора, потерявшего актуальность.

Например? Что-то ничего в голову не приходит..

Они не его, а крестов

Неправда, там далеко не все из крестов. Например borrow checker там из cyclone. Более того далеко не все абстракции в крестах zero weigth, например исключения.

Или руки кривые у разработчиков.

Есть такое, он оочень сырой пока. Поживем - увидим.

Ну вот например бери все что здесь перечислено, и выкидывай: https://msdn.microsoft.com/en-us/library/bb288454.aspx

Я начинаю понимать, что такое «сишка»... это какая-то хрень, включающая в себя микрософтовскую библиотеку.

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

Ты сказал «всё, что здесь перечислено» - значит, makepath, _tmakepath, _makepath, _wmakepath и прочее говно. В любом случае, я не о библиотеке спрашивал.

Ну да, все что перечислено :) С точки зрения теория множества все верно ведь))

Для высокоуровнего ассемблера не получится.

вообще я имел в виду выбрасывать как явление

на мой скромный взгляд C вполне соответствует тем задачам для которых он задумывался, он лаконичный, простой и компактный, для работы с аппаратными ресурсами

а вот попытки его «расширить» и «улучшить» приведут к появлению +1 C++

я бы хотел сохранения C именно в таком виде как сейчас, чтобы он +- соответствовал архитектурным особенностям под крышкой условной железки

Ну начать хотя бы с препроцессора вместе с инклудами — сделать человеческие модули, неявного преобразования типов — только хардкор, уродливого switch с его fallthrough — нужен хотя бы лисповый cond, оператора запятая, возвращающих значение инкремента/декремента, то же касается остальных in-place операторов. Выкинуть по максимуму все фичи, создающие UB, стандартизировать implementation defined, бить по рукам за «clever» код. Выпиливать не так уж и много, на самом деле. Больше добавлять нужно (и получим очередной раст).

А если рассматривать Rust как замену Си, чем он не соответвует архитектурным особенностям условной железки? Вон, уже есть такие проекты: http://zinc.rs/

Всем соответствует.