Почему советуют начинать обучение программированию не с C++, а с C?

да ладно чо ты уж. дай адептам подрочить на очередную серебрянную пулю.

кстати а кто-нить видел код циклического двунаправленного списка на расте?

Фортран сдох ? Ню-ню, в твоей общаге если только. Фортран поддерживают МС, Интел, GNU. На нём хренова туча кода и библиотек.

У тебя явно что-то личное против Rust.

Против чего (кого) я и каким образом вроде достаточно очевидно, но ты умудрился при этом ничего не угадать. Стоит поднять с колен свои аналитические навыки, они могут оказаться полезными где-нибудь ещё.

Против чего (кого) я и каким образом вроде достаточно очевидно

Конечно. Мне интересно, не вызван ли такой градус «противности» личными причинами.

но ты умудрился при этом ничего не угадать."

Я не гадал, а прямо спросил. Ты в ответ раздул щеки.

Сейчас уже вся Америка учит своих падаванов на примере Питона. Но не Си. В этом плане лучше учиться программированию на Swift - прекрасно можно компилировать консольные утилиты для Линукс дистров. Также Java вполне неплох для обучения - богатая стандартая библиотека.

вся Америка учит своих падаванов на примере Питона

Дык, это ж тупые пиндосы! Что с них взять? Пхытон — это вообще жесть! А начинать учиться погромированию с питона — нонсенс!

Ты, похоже, ТеХ совсем не знаешь ☺

Ну, если учесть сколько всего написали тупые пиндосы и сколько умные русские, то всё становится ясно - питон победил в сфере обучения.

А где-то уже есть статистика по написанному исключительно американскими студентами и выпускниками за последние 10 лет? То есть, после массового внедрежа питона? Имхо, пока рановато делать выводы.

А зачем тебе? В любом случае будет что-то вроде двухсвязного списка из стандартной библиотеки.

и непродуманность во всём остальном

Можно несколько примеров?

Сколько там драйверов устройств написано на питоне американскими студентами, а системных утилит, а приложений?

Алсо нирикамендую Си, как первый учебный язык.

Меня в школе учили так: кенгурёнок ру->basic->pascal.

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

А ассемблер я так и не выучил, да...

C++ не особо-то ООП (в java смысле).

Хм... а чем Java сильно ООП-шнее? Я бы понял, если бы ты какой-нибудь смалталк упомянул.

Фортран поддерживают МС, Интел, GNU...

МС - это кто?

ну просто интересно

двухсвязного списка из стандартной библиотеки.

Сделана через жуткую анальную боль и блоки unsafe (привет, «безопасность раста»!) Можно конечно и из нее сделать циклический список, добавив больше боли и unsafe ада.

и блоки unsafe (привет, «безопасность раста»!)

Ну да, некоторый код эффективно без unsafe не написать. И что?

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

Так вот, ни хрена она не позволяет.

Типичный подростковый максимализм (еще вспоминается анекдот про японскую пилу и суровых сибирских лесорубов).

Как говорил Остап Бендер, полную гарантию дает только страховой полис. Всё остальное только снижает вероятность проблем. И, если ты считаешь, что вероятность проблем с памятью в Rust настолько же велика, как и в Си, ты лжешь самому себе.

А окупится ли относительная сложность написания программ на Rust снижением количества проблем - время покажет.

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

И конечно же этот «эффективный код» будет писать «совершенный человек»

Нет, этот код обложат тестами и на ревью обратят дополнительное внимание из-за наличия unsafe. В идеале, код будет в библиотеке, что обеспечит ему дополнительное внимание и тестирование.

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

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

Конечно. Мне интересно, не вызван ли такой градус «противности» личными причинами.

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

Я не гадал, а прямо спросил. Ты в ответ раздул щеки.

Какими-то намёками издалека, и без обозначения намерения что-то спросить, вопросы задают неопытные девушки, или школьницы. Такой стиль точно не является прямым.

И, если ты считаешь, что вероятность проблем с памятью в Rust настолько же велика, как и в Си, ты лжешь самому себе.

Нет.

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

А окупится ли относительная сложность написания программ на Rust снижением количества проблем - время покажет.

Не окупится: переписыванием всего и вся на Rust никто заниматься не будет, ибо это миллионы человеколет работы. А без переписывания всего и вся это будет...как бы попонятней сформулировать... всё равно, что попытка защитить голову от пули куском стали размером с 5-рублевую монету.

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

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

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

ЛЮТО БЕШЕНО НУЛЬЧУЮ!!1

Если бы я был тянкой, я бы тебе дал!

Назови мне хоть что-то полезное и красивое, писаное на пхытоне! Нет ничего!

Да, есть всякие уродства вроде того же portage'а, но это ж жесть! было бы прикольно, если б говнопоцтеринг напейсал свои фекалии на пхытоне.

Сейчас уже вся Америка учит своих падаванов на примере Питона. Но не Си...

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

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

В этом плане лучше ... Swift ... Также Java вполне неплох ...

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

Можно несколько примеров?

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

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

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

This document gives coding conventions for the Python code comprising the standard library in the main Python distribution...

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

адов error handling через ручную композицию вместо исключений

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

В любом случае, это не «непродуманность», а осознанное решение. Не идеальное, да. Вот только исключения тоже на идеал не тянут.

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

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

Второй пласт проблем это засовывание в язык непрофильной функциональности - юнит тесты, документация в коде и тесты прямо в документации.

Это не проблема, а обалденное удобство.

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

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

Нет, этот код обложат тестами и на ревью обратят дополнительное внимание из-за наличия unsafe. В идеале, код будет в библиотеке, что обеспечит ему дополнительное внимание и тестирование.

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

В плюсах, например, сделают точно так же.

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

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

Если что, пишу я как раз на плюсах и не страдаю по этому поводу.

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

всё равно, что попытка защитить голову от пули куском стали размером с 5-рублевую монету.

Поэтому продолжаем защищаться от пуль дуршлагом. Откуда этот подход «всё или ничего»?

Ладно, пойду выяснять от чего графические драйвера в очередной раз с сегфолтом упали. В прошлый раз им не понравилось «static const float» в шейдере.

А такие библиотеки есть на Си? Почти все пишут свои велосипеды

Адова обработка ошибок на Rust'е.

::perf_start("tbr");
try!(res.calloc.reset());
core.dump_info_queue_tagged("tonemapper");
try!(res.clear_list.reset(&res.calloc, None));

Элегантная обработка ошибок в C++

ThrowIfFailed(m_commandAllocator->Reset());
ThrowIfFailed(m_commandList->Reset(m_commandAllocator.Get(), m_pipelineState.Get()));

Вот только исключения тоже на идеал не тянут.

Ничего лучше на практике нет.

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

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

Там нет однозначной «красной тряпки» на которую будут бросаться

Ее нигде нет(unsafe не показатель, что код обязательно небезопасен, да и без unsafe можно накосячить, ведь unsafe, как я понимаю, «незаразный»).

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

пишу я как раз на плюсах и не страдаю по этому поводу.

Я после нескольких лет страдания(первые лет 10 писал без особых жалоб) смирился. Главное, использоваться другие языки к месту, а не все подряд писать на C++. Мне на практике хватает 3х языков: C++ для основного кода, питона для скриптов и утилит, а так же scala для запусков на готовых кластерных решениях или просто в случае необходимости работы с миром jvm. Если бы приходилось кодить железки, то добавил бы еще чистый си в список.

Как это ничего? А Ansible?

Ну и смысл забивать голову 100500 разными ЯП, если абсолютно все (CLI, GUI, железо, веб-сервисы) можно писать на сях?

Ничего лучше на практике нет.

Практика разной бывает.

Как по мне, идеально когда предоставляется два варианта АПИ, но понятное дело, что так писать и поддерживать больше. Ещё неплохой вариант у плюсов в стандартной библиотеке: исключений почти нет, а где есть - там опционально (не считая bad_alloc). Если надо, то можно их поверх накрутить в своей логике. Собственно, раст недалеко от второго варианта ушёл.

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

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

Нет, удобно когда есть (удобный) «стандартный способ». Меньше удивления, проще разобраться и вносить изменения. Давай тогда и C++ выкинем - ООП там «дядя сверху навязал», будем как в С сами реализовывать каждый раз.

Опять же, кто мешает любые свои тесты прикрутить?

Я имел в виду, что использование легаси на C/C++ == голова без чего либо.
Rust имеет смысл использовать в крупных проектах, написанных с нуля, то есть: загрузчик + ядро + все дрова + все системные библиотеки + весь прикладной код.
А если у тебя маленькая нашлепка в виде приложения на Rust над кучей всего, написанного на C/C++, то толку от безопасности Rust, как... от лобковых волос в плане защиты от изнасилования.

unsafe не показатель, что код обязательно небезопасен

Это однозначно повод присмотреться получше. Ну или unsafe там без дела приткнули.

ведь unsafe, как я понимаю, «незаразный»

Смотря что ты под этим подразумеваешь. unsafe функции только в unsafe блоке вызывать можно.

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

Если тебе на ревью попадает пару страниц кода (N раз в день) и ты мега-внимательно всё просматриваешь, то могу только позавидовать.

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

А окупится ли относительная сложность написания программ на Rust снижением количества проблем - время покажет.

Не окупится: переписыванием всего и вся на Rust

Кто, кроме тебя, говорит о переписывании?

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

Не старайся формулировать понятно, старайся формулировать корректно.

Существуют на этом свете разного рода инициативные идиоты (ИИ), дилетанты, профаны и тому подобные персоны производящие много бесполезного шума отвлекая тем самым на себя людские ресурсы. [...] Rust же одновременно является неуклюжим детищем таких персон и их аттрактором.

«Категорично, скромно и со вкусом» (ц).

Какими-то намёками издалека, и без обозначения намерения что-то спросить, вопросы задают неопытные девушки, или школьницы. Такой стиль точно не является прямым.

Ты не понял вопроса. Впрочем, это само по себе является ответом.

Как насчет заменить какой-нибудь системный сервис на сервис гарантированно не добавляющий ошибок работы с памятью? Или взять всякие парсеры. Написал я декодер HDR, пошёл посмотреть на issues к С декодеру в stb_image, а там примеры с buffer overflow лежат. Естественно, Rust'овский декодер к ним иммунен бай дизайн.

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

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

Ты кстати пробовал сделать

Command::new("ls /dev | grep tty")

Файл 'ls /dev | grep tty' не найден. Чтобы заработало надо

Command::new("bash").arg("-c").arg("ls /dev | grep tty")