Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?

Автор оригинала: Andrei Alexandrescu
Несмотря на мой статус и очевидную предвзятость как одного из создателей D, я постараюсь отвечать откровенно; Я следовал путям Go и Rust, и я абсолютно точно знаю, где стирают грязное белье в D. Я поощряю людей на аналогичных позициях в сообществах Rust и Go чтобы и они делились своим мнением. Так вот.

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

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

Позвольте мне для начала разделаться с D


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

  • Плохой прием публикой после многих лет номинального существования. Долгожители комьюнити могут раскритиковать такое заявление (D в его текущей форме относительно молод, популярность растет, итд). Но такое отношение сохраняется и влияет на дальнейший рост популярности и это факт. В итоге менеджеры и инженеры скептически относятся к популяризации языка, который был неудачником так долго. Более того, время работает против D до тех пор, пока не будет очевидного прироста популярности.
  • Печальная история в связи D со сборкой мусора (GC). GC великое изобретение, но решение его использовать в D мгновенно изолировало его от основной целевой аудитории – программистов на С и С++. Для них линия партии выглядела так «Не хотите GC? Не проблема! Можете также использовать D с RAII или с ручным управлением!». Несмотря на то, что в целом это верно, такой подход был практически бесполезным из-за отсутствия поддержки такого стандартной библиотекой, что означало для предполагаемого пользователя оказаться раздетым до трусов и начинать с создания базовой инфраструктуры. Даже для тех, кто не возражал против GC, качество его реализации было довольно невзрачным. В общем можно сказать, что D получил все недостатки GC, но не воспользовался преимуществами.
  • Исторические сложившееся отсутствие визионеров. Лишенный корпоративной поддержки, D вело вперед сообщество, в котором проще найти проницательного инженера, нежели проектного управленца или харизматичного лидера. В течение долгого времени успешность попыток D в продвижении и саморекламе имела отрицательный результат. Первый документ о планировании датирован 1 января 2015, а следующая итерация (Vision/2015H2 — D Wiki) вышла на четыре месяца позже запланированного, что является прекрасным примером самоиронии с точки зрения планирования

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

10х-бонусы для D я полагаю следующими (еще раз, когда я говорю в 10 раз, это разговорное «лучше на порядок»):

  • В 10х компиляция быстрее чем С++ для сравнимого кода. Эту дыру нельзя принципиально закрыть в С++, и запредельно сложно перепрыгнуть в любых других языках. (Go компилируется чуть быстрее D, но результирующий код медленнее) Опыт использования системного языка, который так быстро компилирует в быстрый код, является преобразующим старые практики и очень перспективным. В комбинации с мощностью абстракций в D это, по сути, делает D хорошим выбором для написания высокооптимизированного кода по той простой причине, что экспериментирование обходится дешево.
  • В 10х быстрее скриптовых языков со сравнимыми удобствами. D хорошо подходит для удобного скриптования повседневных задач. Цикл компиляции/запуска остается таким же быстрым, а выгода в скорости грандиозна. Также нет проблемы «уперлись в пределы» — если скрипт становится большим, в D всегда хватает языковых средств и модульности. Есть, конечно, и ложка дегтя, например в Python’е гораздо больше готовых библиотек. Но 10х-бонус тут фундаментален – системные языки не имеют столько синтаксического сахара, а скриптовые безнадежно отстают в скорости.
  • В 10х проще интегрироваться с С и С++, чем любой другой язык. D использует такие же структуры в памяти, что и С и С++; и строит свои поверх них, но чтение нижележащих слоев остается бесплатным в плане скорости. Стандартная библиотека С полностью доступна без всяких штрафов — ни в плане скорости, ни в синтаксическом, и хотя еще нужны некоторые доработки для аналогичной простоты в плане библиотеки С++, многие С библиотеки уже доступны (https://github.com/D-Programming...). Можно заявить буквально, что ни один другой язык не сможет достигнуть такого уровня интеграции.
  • В 10х раз лучше любого другого системного языка в дженериках и метапрограмировании. В D статическая интроспекция, вычисления на этапе компиляции (CTFE) и основанная на mixin (примесях) генерация кода составляют коктейль Молотова, который весьма затруднительно корректно смешать в других языках, ни в новых ни в выживших; в этой игре Go настолько не в себе, что даже не сечет фишку; C++17 безнадежно заблудился в темном лесу; а Rust только пытается лепетать.

Вперед к Go


Я должен подчеркнуть, что это исключительно мое мнение, тем не менее стоящее вашего внимания. Проблемы Go в следующем:

  • Фундаментальное замедление по причине косвенных вызовов и сборщика мусора (GC). Практически ни одно существенное приложение на Go нельзя написать, не прибегая к косвенным вызовам и GC, которые являются центровой функциональностью. Это основные препятствия для производительности ядра Go. Ответ команды Go был в основном тактическим – например улучшить работу GC. Однако, маловероятно победить в челлендже по замене С тактически.
  • Политика. Линия партии в Go непропорционально сильна и жестка по ряду вопросов, как маленьких, так и больших. Один из примеров больших проблем — подход к дженерикам был настолько бессмысленным и беспощадным, что сделал дженерики словом на букву «Г»; вся тема превратилась в кровавые слезы, препятствуя любым попыткам наладить конструктивный диалог. Я думаю, что политизация технических вопросов в долгосрочной перспективе является крайне пагубной моделью, и я надеюсь, что Go найдет способ исправить это.
  • Простота хуже воровства. Пойти очень просто (игра слов. Go — ходить, прим.перев) – есть даже анекдоты по этому поводу. Однако со временем это становится проблематичным; Код на Go безнадежно пешеходный — Go-кодеры ловят себя на том, что снова и снова пишут одни и те же вещи с точки зрения муравья, потому что Go не может абстрагировать даже самые простые понятия или алгоритмы. Понятия, которые еще не реализованы библиотеками интеграции, сложно реализовать. Наблюдается негативная реакция со стороны программистов, которые использовали Go для одного проекта и больше не хотят использовать его снова. Было бы неплохо, если бы Go сделал жизнь лучше для постоянных клиентов.

Go 10х-бонусы в моем восприятии следующие:

  • 10x в скилле Стратегия. После краткого периода, когда Go позиционировался как системный язык, было решено позиционировать его для сетевых сервисов. Это было великолепным маркетинговым шагом, который использовал сильные стороны команды Go (одни из лучших инженеров в мире по сетевым сервисам). Это очень горячий рынок и Go просто стал глотком свежего воздуха для мира, в котором прежде доминировала Java EE со своим бюрократизмом и медленные скриптовые языки. Теперь Go – основной игрок в этой области и его будет трудно подвинуть.
  • 10x в скилле Инженерия. Go за собой имеет крепкую команду инженеров, и это основной фактор влияния на качество языка и в частности на сетевую библиотеку и тулсет. До сих пор хороший инжиниринг вполне компенсировал слабосильность языка.
  • 10x в скилле Брэндинг. Многие из нас готовы признать, что главный мотиватор использования Go – это связи с Google. Это придает ему авторитет профессионализма, качества и стабильности. Конечно, брэнд это не все, но это уже делает Go достойным языком; он не должен быть фантастически хорош. Брэнд сделает остальное.

Последний, но не менее важный, Rust


Позвольте мне снова напомнить, что это только мое мнение. Я думаю, что Rust сталкивается с некоторыми интересными проблемами:
  • Дисгармоничная личность. После чтения некоторого количества кода на Rust возникают анекдоты типа «Чувак пропускал дни кача ног», иллюстрируемых комиксами с людьми с перекачанным торсом но ногами-спичками (прим.перев. По-русски, «Колосс на глиняных ногах», но неточно) Rust ставит на первое место точное и безопасное управление памятью и представляет это центром мира. Внезапно, это редко является проблемной областью, что приводит к тому, что большая доля планирования и кодирования уделяется, по сути, канцелярской работе (которую языки с GC автоматизируют не глядя). Безопасное, предопределенное переиспользование памяти — серьезная задача, но не единственная, или как минимум не самая важная в программе. В итоге Rust тратит непропорциональное количество ресурсов языкового дизайна только на это. Было бы интересно посмотреть, насколько Rust разбухнет ради других аспектов языка; единственный вариант это расширение языка, но вопрос в том, насколько абстракции смогут помочь с неприятной необходимостью контролировать ресурсы на всех уровнях.
  • Чуждый синтаксис. Синтаксис Rust’а отличный [от всех], но нет очевидного преимущества в такой экзотичности. Это раздражает людей, пришедших из языков семейства Algol’а, которым приходится иметь дело еще и с кардинально другим синтаксисом, помимо необходимости ручного ведения всей бухгалтерии с ресурсами.

Rust’овские 10х-бонусы такие:

  • В 10х раз лучшие теоретики. Из этой тройки, только у Rust есть теоретики мирового уровня в разработке языков программирования в обойме. Это можно заметить по точности технического описания языка и в глубине технического подхода.
  • В 10х раз больше безопасности, чем в других системных языках. Безусловно это должно быть здесь, мы можем только подискутировать о стоимости такого подхода.
  • В 10х раз лучший PR (пиар, реклама, прим.пер.) Был довольно долгий период, когда Rust был у сообщества любимицей, которая не могла ошибаться: для любой проблемы Rust уже либо имел решение, либо должен был получить его с выходом 1.0. Реальность выхода 1.0 прервала этот медовый месяц и отметилась (в моих измерениях и ожиданиях) резким снижением общего интереса, хотя эти факторы имеют тенденцию к пролонгации. Плюс, в конечном итоге, Rust — это приличный язык с реальными достижениями, и он хорошо спозиционирован, чтобы превратить этот затяжной хайп в стабильный рынок.

Вкратце


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

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

Комментарии 393

    +9
    I think Rust is facing some interesting challenges

    Я считаю, что Rust лицом к лицу с некоторыми весьма интересными проблемами

    is facing — это совершенно точно не лицом к лицу
      0

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

        +2
        Вариации:
        1. На мой взгляд Rust встретил некоторые вызовы.
        2. Я считаю Rust столкнулся с определенными вызовами.
          +2

          "Слицовался" тогда стоит перевести.

            +2
            Это далеко не самый худший перевод

            Я бы сказал, это необравданный буквализм: нет никакой необходимости вставлять лицо в перевод «is facing», как нет необходимости упоминать бога при переводе «bless you». Но этот перевод в целом получился очень буквальным.


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


            Немного спорных переводческих решений

            Хотя моя предвзятость в этом вопросе очевидна, я постараюсь ответить на него откровенно. Несмотря на статус одного из создателей D, я пристально слежу за присходящим с Go и Rust, и я определённо знаю многие неприглядные вещи о D. Было бы неплохо, если бы люди на аналогичных позициях в сообществах Rust и Go тоже высказали бы здесь свои мнения. Итак, начнём.


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


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


            Кстати замечу, что для понимания текста важен контекст: Александреску отвечает на чей-то вопрос на Quora и прямо ссылается на формулировку этого вопроса.

              0
              А разве тут нужен точный перевод? Куда лучше подойдёт вольная отсебятина, надо только держаться в русле контекста. Полагаю, для перевода этого текста лучше не понимать английского или вовсе его презирать, как я. =)

              Примерно так.
              Хоть моя предвзятость, как соавтора D, очевидна, постараюсь быть предельно откровенным. Я слежу за Go и Rust, но куда лучше знаю грязные стороны D. Настоятельно советую коллегам по статусу из сообществ Rust и Go тоже поделиться откровениями. Итак, начну:

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

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

            +12

            Наткнулся в самом начале на "Я следовал путям Go и Rust", плюнул, ушел читать оригинал, а там "I follow Go and Rust", т.е. просто "Я слежу за Go и Rust"

            +2

            Nous y verrons

              +3

              Еще одно (неожиданное для меня) мнение от ребят из Microsoft Security Response Center: Why Rust for safe systems programming.

              • НЛО прилетело и опубликовало эту надпись здесь
                  +3
                  Да, и тоже пока присматриваются.
                  While researching Rust, we found some issues that gave and continue to give us pause...
                  Возможно, подключатся и помогут.

                  Их похоже, не устраивает
                  ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues
                  . Это из предыдущей статьи в их блоге.

                  Кстати, статьи интересные, подкидываю идею Растерам про перевод.
                    +3

                    Как сказать "присматриваются".
                    Например, один из локомотивов асинхронного Rust — Actix — творение рук одного из сотрудников Microsoft: есть сведения, что очень даже активно используется ин-продакшн. Есть и другие примеры.

                      +2
                      вдвойне приятно, когда заявляние подкреплены пруфами/линками.
                        0

                        Спроси у Николая в чате, он с пруфами тебе покажет.


                        Сервисная часть ажуры у майкрософта на актиксе основывается.

                          +4
                          Было бы отлично, если бы ты, как раст-евангелист, показал эти ссылки всем, а не посылал каждого на ними в чат (какой из всех?) к Николаю.
                            0

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


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

                          +8

                          Я главный разработчик actix. Активно использую раст и actix в azure iot. Хотя пруфы показать не смогу

                            0
                            Это здорово, так как я и сам использую actix. Но, если я правильно вижу, вы писали что это был тестовый проект, или он уже поменял статус?, что, в любом случае, тоже хорошо.
                              +1

                              Тестовый проект уже работает. Сейчас работаю над большим проектом.

                                +1
                                Я думал, это иллюстрирующая шутка, как про Росгвардию…
                                Вот эта

                    +7
                    Rust ставит на первое место точное и безопасное управление памятью и представляет это центром мира. Внезапно, это редко является проблемной областью,

                    А разве всякие HeartBleed и EternalBlue, не были вызываны как раз ошибками в управлению памятью?

                      +9

                      А на чём бизнес больше теряет, на хардблидах или на том, что не успевает за конкурентами?
                      Сколько бы не хайпали за безопасность, в реальности она не несёт в себе столько потерь, сколько прибыли дают фигак-фигак аджайлы. Sad but true.

                        +8

                        Одна из ниш, где Rust уверенно завоёвывает себе место под солнцем — HFT. Как раз по причине того, что нужно максимум скорости, при этом действительно надёжно и без эзотерических багов как в C/С++. Ибо бизнес в случае чего теряет столько, что мало не покажется. До последнего времени здесь доминировала Java.

                          0
                          Там вроде как раз на плюсах частенько пишут, нет?
                            +9

                            Конечно пишут. А куда деваться?
                            Тот случай когда действительно такты процессора считают.
                            Но я как минимум знаю компании, где от плюсов именно отказались и зареклись.
                            И вот Rust теперь предлагает эту плюсовую скорость без компромиссов с надёжностью. Его осторожно пробуют и находят лучшей заменой. Разумеется, жизнь сложная штука: не везде и не все, подобное было бы странно утверждать. Природа поощряет разнообразие :-)

                              +3
                              Я знаю пример, где HFT переехал с плюсов на java, но вот с явы, и все очень довольны насколько жизнь упростилась, а вот на Rust это дальше переезжать как-то не торопится.
                            0

                            Я как раз рядовой HFT'шник, и когда наша компания перешла на Яву — это было странным, вокруг все писали на плюсах. Лет через 5 мы вернулись обратно на плюсы, и я не очень понимаю, чем современные плюсы хуже. Ошибки с памятью встречаются весьма редко, скорость работы софта выше (что очень важно). Многие трюки с шаблонами в Яве сделать сложно, язык там зачастую более многословный. Ну окей, контейнеров разных в Яве больше конечно, в т.ч. и потокобезопасных.


                            Где Ява лучше — так это в скорости разработки. IDE подсказывают, упрощают чтение и поиск кода. Ну и модульность — подсунуть нужный jar'ик это не всю плюсовую тряхомудию пересобрать. Но если это даётся ценой лишних us… то извините.


                            Rust не трогал… но вот этот комментарий (ссылка) очень заинтересовал. У нас без шаблонов никуда, если в Расте с этим плохо — то беда. Модель памяти там пытался найти (по диагонали) — тоже пока как-то не впечатлило.


                            Кстати, как у Раста со скоростью разработки? Можно, как в Яве, залезть в кучу незнакомого кода и за десяток кликов в IDE прочитать и понять сложную иерархию вызовов? Fuzzy-поиск по имени типа? Подсказки вида — что может делать этот объект (с всплывающим аналогом JavaDoc'а)?

                              +1

                              Шаблоны в Rust есть, в Rust нет переменного количества параметров в шаблоне и нет констант в качестве параметра шаблона.


                              Модель памяти же в Rust простая: вы можете владеть объектом, исключительно заимствовать его для чтения-записи, или неисключительно заимствовать его для чтения. А дальше — работают стандартные контейнеры и примитивы синхронизации.

                                +4
                                и нет констант в качестве параметра шаблона

                                Есть надежда в обозримом будущем (этом году или начале следующего?) получить — работающая в ночнике реализация есть, до стабилизации не так уж и много осталось работы: https://github.com/rust-lang/rust/issues/44580

                                  0

                                  Откуда в расте возьмется переменное количество параметров шаблона, если там нет шаблона?

                                    +1

                                    Шаблоны, дженерики — в данном контексте это не важно.

                                      –3

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

                              +1

                              Как говорили ребята из биокада, у нас нет времени запускать обработку на несколько часов на тысяче серверов чтобы в итоге увидеть "undefined is not a function" или "SIGSEGV".


                              Не говоря про то, что корректность зачастую дается бесплатно. Я вроде писал про это недавно.

                                0

                                Поэтому ребята из биокада запускают туже обработку на сутки и недели, на десятках тысяч серверов, и вместо SIGSEGV видят unhandled exception, зато с GC

                                  0

                                  Нет, не видят. Потому что у ребят эррор-хендлинг на эффектах с АДТ построен, где нельзя взять и забыть обработать ошибку.


                                  Но писать приходится больше, да. Ту же обработку писать надо.

                                    0

                                    Я не знаю, как там у них, но в х-ле делать ошибки в IO на АДТ не принято, например.

                                      0

                                      Ошибки так и так принято в Either заворачивать. Как дальше с этим работать — МТЛ ли, фримонада ли, уже дело десятое.

                                        +1

                                        IO (Either Err Res) таки considered harmful (и, по моему опыту, дизайн тупо на экзепшонах в той мелкой части вашего кода, которая сама по себе живёт в IO, оказывается чище и разумнее).

                                          0

                                          А чем плохо-то? Какой смысл писать IO, если ошибка (намного более существенный эффект нежели ио собственно) оказывается спрятанной?

                                            +1

                                            Тем, что экзепшоны вам тоже придётся обрабатывать. Ваш тред могут прибить, какая-нибудь нижележащая библиотека для работы с HTTP/постгресом/ФС может кинуть экзепшон (потому что IO, да и протягивать все возможные ошибки от всех возможных источников по всему стеку — ну такое), и так далее.


                                            Вот, положим, пишу я скрейпер какого-нибудь сайта. У парсера страниц там, действительно, будет тип вроде parsePage :: (MonadError ParseError m, MonadReader ParseEnv m) => BS.ByteString -> m ParsedPage (на самом деле чуть сложнее, но не суть). Там это удобно, там это оправдано: я сразу в типе показываю, какие эффекты имеет мой парсер.


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


                                            То есть, я признаю, что есть некоторая ценность в типе вроде IO (Either Err Res) в том смысле, что он показывает, что ошибки вида Err точно ожидать стоит. Но дело в том, что:


                                            1. либо вы пишете код, чувствительный к экзепшонам, и тогда вам надо учитывать ошибки и из IO в любом случае (благо это легко, в 99% прикладного кода взял bracket, и этого достаточно),
                                            2. либо вы всё равно не можете локально обработать ошибку в рамках данного слоя приложения,
                                            3. либо это внутренняя функция модуля, сигнатура которой уже не столь интересна.
                                              0

                                              Но ведь можно написать IO Maybe Res, чем он лучше Either? Или любой другой враппер. Емнип трансформеры именно для того и придумали, чтобы можно было использовать любую вложенность и не прятать всё в IO ()

                                                0

                                                Я лучше просто оставлю ссылку: вот.

                                                  0

                                                  … хотя я что-то её сейчас перечитал, и Снойман там хрень какую-то пишет про MonadThrow.


                                                  Можно же как с Has, только наоборот. Время писать статью на Хабр!

                                                    0

                                                    Буду ждать статью, тогда.


                                                    Потому как любая ФП статья\книжка рассказывает про то, какие эксепшоны плохие и некомпозабельные, и как все на Either'ах классно (ну взять хотя бы вот эту).


                                                    Я лично думал, что эксепшоны исключительно как паники роняющие приложение используются.

                                                      0

                                                      Either тоже так себе композабельный. Если у вас есть foo :: Either a Ret и bar :: Either b Ret, то в общем случае совместить их без танцев сложно.


                                                      Вообще прикольно получается. У MonadReader есть аналогичная проблема, связанная с тем, что тип окружения фиксируется в монадическом стеке, и две разных функции, требующих два разных окружения (например, MonadReader Foo m и MonadReader Bar m), сочетаются, ну, плохо. Для этого есть Has-паттерн, когда вы вместо MonadReader Foo m => m a пишете (MonadReader r m, Has Foo r) => m a, и я как раз вчера оформил в библиотечку обобщённый способ эти Has-инстансы генерировать (по тестам видно, как этим пользоваться, хотя доки дописать таки стоило бы).


                                                      То есть, Has part record — это такой тайпкласс, означающий, что из типа record можно достать тип part.


                                                      А тут возникает совершенно дуальная проблема: надо в тип sumError уметь засунуть тип part. Надо тоже дженериками обмазаться и сделать.

                                +3

                                Так для того тулинг и развивают, чтобы в продакшн и быстрее и безопаснее. Однажды Раст (или кто-то похожий) перешагнет планку «достаточно просто» и мы забудем, как было до него. Мне папа однажды отдал все свои чистые перфокарты, который до этого лежали в важно шкафчике.

                              +1
                              Вроде, я это несколько лет назад читал на английском. А в отношении «лицом к лицу» — то можно и лицом к лицу, не хватает сказуемого: что именно Rust вытворяет лицом к лицу с весьма интересными проблемами. Например — сталкивается.
                              А так перевод норм.
                                +1
                                Ок, пишите замечания в личку, буду править, пока карма позволяет.
                                А по мне так перевод вышел корявым =)
                                +23
                                Ответ на вопрос в заголовке: никакой не имеет. /thread
                                  –1

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

                                    +1
                                    А почему люди должны менять C на что-то другое? Мучится? Вы много мучались на C? Это стереотип, главный аргумент апологетов других языков… Какие проблемы есть в C, которые решают другие языки?

                                    По моему опыту, независимо от языка, подавляющая часть времени уходит на реализацию бизнес-логики, на отладку и поиск логических ошибок…
                                      +6

                                      Си не способствует реализации бизнес-логики. Он как бы слишком низкоуровневый. Как пример — почем взлетел Питон? Потому что в его "стандартной" комплектации есть модули для решения любых задач и он позволяет практически не отвлекаться на особенности языка при реализации именно бизнес-логики.

                                        –2
                                        Приведите, пожалуйста, пару примеров, которые показывают, что C не способствует, а тот же Python способствует реализации бизнес-логики.
                                          +7

                                          Все настолько очевидно, что даже приводить не хочется. Ну, ок, если очень хочется. Типичная задача для бизнеса — взять данные из какого-то REST API, преобразовать, обогатить, отсортировать в каком-то порядке. Python — можно уложиться с модулями типа requests в 1000 строчек кода. Сколько будет на Си? Какова будет сложность поддержки и развития кода? Сколько там будет "глупых" ошибок с выделением памяти?

                                            +2
                                            Взять из REST API — это не бизнес-логика, это библиотечная функция. На C запрос по HTTP с помошью библиотечной функции из libcurl займёт десяток строк, написать в первый раз — 5-10 минут, но у меня давно есть обёртка, т.е. один вызов одной функции…

                                            Какой смысл вы вкладываете в «преобразовать, обогатить, отсортировать в каком-то порядке» я не знаю, не могу как-то откомментировать… 1000 тоже не говорит ни о чём, сколько займёт на C не могу сказать…

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

                                            Количество «глупых» ошибок с выделением памяти зависит, опять таки, от архитектуры и качества кода. Я использую собственные менеджеры памяти, которые написал лет 15 назад… В текущем проекте, написанном «с нуля», за более чем 2 года, у меня была одна утечка, которая была обнаружена и исправлена на этапе тестов. И раза 3-4, опять таки на этапе тестов, были падения в корку из-за использования освобождённых указателей, все они были быстро исправлены…

                                            Но эти проблемы не касаются бизнес-логики, они касаются «скелета» приложения. Бизнес-логика «наращивается» на этот скелет, она оперирует отлаженными структурами скелета… У меня не было проблем с памятью в бизнес-логике…

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

                                            Если у вас простая логика, например, получить какой-то набор данных в JSON, пройтись по ним, посчитать какие-то агрегаты, на C это займёт не сильно больше времени чем на Python, так же обращение к REST API по HTTP в несколько строк (с проверкой на ошибки), так же парсинг JSON в несколько строк, чуть более сложное итерирование (на плюсах так же легко как в Python), чуть более сложная работа с ассоциативным массивом (на плюсах не сложнее). Ну займёт это, условно, 15-20 минут вместо 10 минут на Python, не критично. Но такие задачи у меня встречаются крайне редко… Обычно что-то посложнее…

                                            Например, у вас есть база 100М пользователей, надо выбрать всех пользователей, соответствующих заданным критериям (от 7 до 15 критериев). И хорошо бы уложиться в 100мс. И тут ни какие готовые структуры не помогут. Как на C, так и на Python придётся думать над архитектурой, исследовать и тестировать разные варианты, библиотеки, а потом уже написать решение и отладить его… Времени займёт примерно одинаково…
                                              +4

                                              А потом выясняется, что в этом условном cURL условная уязвимость типа https://imagetragick.com/
                                              /к самому cURL у меня претензий практически нет… хотя иногда проскакивает/


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

                                              и да, и нет. С одной стороны — тот же Питон прекрасно подходит для прототипирования и написания чего-то типа CRUD'ов. С другой — что-то серьезное на нем написать та еще морока. Именно из-за особенностей самого языка. Действительно, начиная с какого-то уровня сложности ты больше упираешься не в язык, а в библиотеки.


                                              В текущем проекте, написанном «с нуля», за более чем 2 года, у меня была одна утечка, которая была обнаружена и исправлена на этапе тестов

                                              Ошибка выжившего. Выявленные ошибки — устраненные ошибки. А сколько не выявлено?


                                              Я использую собственные менеджеры памяти, которые написал лет 15 назад…

                                              тоже отличная иллюстрация — строим свои велосипеды ((((


                                              Например, у вас есть база 100М пользователей, надо выбрать всех пользователей, соответствующих заданным критериям (от 7 до 15 критериев). И хорошо бы уложиться в 100мс. И тут ни какие готовые структуры не помогут. Как на C, так и на Python придётся думать над архитектурой, исследовать и тестировать разные варианты, библиотеки, а потом уже написать решение и отладить его… Времени займёт примерно одинаково…

                                              1. и в конечном счете упрешься в базу. Т.е. проблему нужно решать комплексо, а не локально локальными средствами.
                                              2. уложиться в 100мс — это особые требования. Которые требуют особого решения. Вполне возможно, что придется ту же базу переделывать на распределенную и переписывать все на хранимки )

                                              Если у вас простая логика, например, получить какой-то набор данных в JSON, пройтись по ним, посчитать какие-то агрегаты, на C это займёт не сильно больше времени чем на Python, так же обращение к REST API по HTTP в несколько строк (с проверкой на ошибки), так же парсинг JSON в несколько строк, чуть более сложное итерирование (на плюсах так же легко как в Python), чуть более сложная работа с ассоциативным массивом (на плюсах не сложнее). Ну займёт это, условно, 15-20 минут вместо 10 минут на Python, не критично. Но такие задачи у меня встречаются крайне редко… Обычно что-то посложнее…

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

                                                0
                                                Давайте вспомним уязвимости процессоров, и всё равно, си у вас или пайтон… Да и для пайтона CVE-шек хватает…
                                                Ошибка выжившего. Выявленные ошибки — устраненные ошибки. А сколько не выявлено?

                                                В других языках их нет? Я надеюсь, что более 19К проверок в юнит-тестах и порядка 10 000 rps на проект говорят о том, что критичных ошибок нет :)
                                                тоже отличная иллюстрация — строим свои велосипеды ((((

                                                Велосипедистом можно назвать почти любого программиста, потому как практически всё уже написано, бери и используй… Мой менеджер памяти — это фреймворк, библиотека, позволяющая мне работать эффективнее и не писать лишний код. Да и решает проблему с ошибками, потому как давно отлажено.
                                                и в конечном счете упрешься в базу. Т.е. проблему нужно решать комплексо, а не локально локальными средствами.
                                                уложиться в 100мс — это особые требования. Которые требуют особого решения. Вполне возможно, что придется ту же базу переделывать на распределенную и переписывать все на хранимки )

                                                Ни одна база не решит эту задачу, может ClickHouse позволит решить её за разумное время, но не за 100мс. Локальными средствами она вполне решаема, но время на разработку почти не будет зависеть от языка.
                                                вот с этим категорически не согласен. На С (не С++!) это будет ад и морока. А еще оно может поплыть в любой момент времени, когда входные параметры изменятся. На С++ это будет скорее всего нечитабельная и неподдерживаемая магия на шаблонах. И время компиляции в космос.

                                                Какой у вас опыт на си и на плюсах? Да, работа на си с JSON будет менее приятная, чем на плюсах или пайтоне, но не ад… На плюсах ничего сложного. Вот, к примеру, чтение конфига:
                                                void
                                                Worker::initConfig(const rapidjson::Document& config)
                                                {
                                                    userTtl_ = Utils::configUInt(config, "user_ttl", defaultUserTtl_);
                                                    userEvents_ = Utils::configUInt(config, "user_events", defaultUserEvents_);
                                                    impTtl_ = Utils::configUInt(config, "imp_ttl", defaultImpTtl_);
                                                    trackBaseUrl_ = Utils::configMandatoryString(config, "track_base_url");
                                                    cookieDomain_ = Utils::configMandatoryString(config, "cookie_domain");
                                                    paramsEncKey_ = Utils::configMandatoryString(config, "params_enc_key");
                                                    paramsEncIv_ = Utils::configMandatoryString(config, "params_enc_iv");
                                                    const auto& ssp = Utils::configSection(config, "ssp");
                                                    googlePriceEncKey_ = Utils::base64Decode(Utils::configMandatoryString(ssp, "gdn_enc_key"));
                                                    googlePriceIntKey_ = Utils::base64Decode(Utils::configMandatoryString(ssp, "gdn_int_key"));
                                                }
                                                

                                                Вот пример вспомогательной функции:
                                                std::string
                                                Utils::configMandatoryString(const rapidjson::Value& config, const std::string& key)
                                                {
                                                    if (!config.HasMember(key.c_str())) {
                                                        throw ConfigException(key + " not found");
                                                    }
                                                    if (!config[key.c_str()].IsString()) {
                                                        throw ConfigException(key + " must be a string");
                                                    }
                                                    std::string value = config[key.c_str()].GetString();
                                                    if (value.empty()) {
                                                        throw ConfigException(key + " can't be empty");
                                                    }
                                                    return value;
                                                }
                                                

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

                                                Время полной сборки проекта на 100К строк 1 минута 45 сек. Но сборка инкрементальная, в реальной работе сборка обычно занимает 5-10 сек…
                                                  +8

                                                  И один #[derive(Deserialize)] на расте.

                                                    +3
                                                    Какой у вас опыт на си и на плюсах?

                                                    Примерно 15 лет.


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


                                                    На плюсах ничего сложного. Вот, к примеру, чтение конфига:

                                                    Я как представлю себе, что это всё писать надо, так становится грустно и пальцы сводит.


                                                    Впрочем, при мыслях о питоне тоже пальцы сводит.

                                                      0
                                                      Ну, вопрос по опыту я не вам задавал :)

                                                      Я думаю, не совсем корректно сравнивать си и хаскель в задаче парсинга JSON, таки разные парадигмы, а задача парсинга JSON должна очень элегантно решаться функциональным языком, как мне кажется. Завидую вам по-хорошему, у меня не хватает времени серьёзно взяться за хаскель, весь мой опыт в функциональных языках — это пролог в начале 90-х и эрланг в начале 00-вых…

                                                      На плюсах есть rapidjson, с которым я не испытываю ни какой боли… На голом си всё не так хорошо, но много с JSON-ом работать не приходилось, сделал сериализацию/десериализацию и забыл…

                                                      Я как представлю себе, что это всё писать надо, так становится грустно и пальцы сводит.

                                                      Ну у каждого своя аллергия… У меня вон на алкоголь вылезла, а дома Glenmorangie The Nectar d'Or стоит, вот это обидно, да :)
                                                        0
                                                        а задача парсинга JSON должна очень элегантно решаться функциональным языком, как мне кажется

                                                        Да там в большинстве случаев даже решать ничего не надо. Структуру данных описал с именами полей, соответствующими полям в жсоне, deriving (Generic, Aeson.FromJSON) написал, и всё.


                                                        На плюсах есть rapidjson, с которым я не испытываю ни какой боли…

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


                                                        Вот nlohmann_чётотам неплохо, да.

                                                  +2
                                                  Времени займёт примерно одинаково…

                                                  Сомнительно, но представим, что так. Одинаково, ли стоит хороший разрботчик на С и Python? Достаточно ли много разработчиков на С на рынке, чтобы быстро сделать хорошую команду? Можно, ли взять любого толкого студента изучившего синтаксис и дать ему делать простые вещи на С не боясь, что он что-то сломает?

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

                                                  собственные менеджеры памяти, которые написал лет 15 назад

                                                  Вы написали, а та команда, которая нужно сделать проект с нуля на С? Это ведь не честное сравнение, на любом языке можно написать такой фреймворк, где вообще большая часть типовых задач будет решаться настройкой параметров в вебинтерфейсе. Вот вы потратили время на свой велосипедный «менеджер памяти», это уже косвенные издержки на разработку текущих проектов. А если вы уйдете, вы уверены, что другие разработчки в команде смогут поддерживать и развивать ваш велосипед так же легко?
                                                    0

                                                    Мне кажется, что вообще о честности говорить странно. Что в общем, что в частном (в применении к коллеге).
                                                    И еще меня все-таки очень интересует не происходит ли подмены С vs C++ в нашем споре.

                                                      +1
                                                      Сомнительно, но представим, что так. Одинаково, ли стоит хороший разрботчик на С и Python? Достаточно ли много разработчиков на С на рынке, чтобы быстро сделать хорошую команду? Можно, ли взять любого толкого студента изучившего синтаксис и дать ему делать простые вещи на С не боясь, что он что-то сломает?

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

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

                                                      Я говорю о решении реальных задач на языке специалистом, а не о решении задач студентом, без опыта работы. Давайте тогда уберём из языков стандартные библиотеки, закроем доступ в интернет и будем сравнивать ))))
                                                        +3
                                                        Стоит денег не язык, стоит опыт и умение решать проблемы. Студенты-кодеры буду косячить на любых языках примерно одинаково. Т.е. если у вас цель заплатить 2-3 раза, то можно «взять любого толкого студента изучившего синтаксис». Если вы хотите решить задачу, вам должно быть всё равно на каком языке она решается (исключая экзотику). И вы, как бизнесмен, должны это понимать…

                                                        Тем не менее — стоимость разработки на разных языках будет разная (иначе почему сайты на ассемблере не пишут?). И мастерство профессионала как раз и состоит в подборе правильного инструментария.

                                                          –1
                                                          Я считаю, что стоимость разработки разными разработчиками (командами) будет разная, а не на разных языках. Время разработки на том или ином языке сильно зависит от того, что и кем разрабатываться, т.е. зависит от специфики проекта и опыта разработчика.

                                                          Сайты не пишутся на ассемблере потому, что это неэффективно, «стрельба из пушки по воробьям»… Но местами ассемблер незаменим, например, при git-компиляции…
                                                          +2
                                                          Стоит денег не язык, стоит опыт и умение решать проблемы. Студенты-кодеры буду косячить на любых языках примерно одинаково.

                                                          "Ни одна техника не спасет от всех багов, поэтому давайте пользоваться тем что работало в 80х" (с)


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

                                                        +2

                                                        Как вы думаете, сколько UB у вас в коде на С?


                                                        А то я тут вчера пытался кое-что написать, и мне в очередной раз припекло. Ну там, кусочек памяти заммапить и проинтерпретировать как int, условно говоря.

                                                          –2
                                                          Что такое UB? И что вы хотели этим сказать?
                                                            +4

                                                            Вы не знаете что такое UB? Очень жаль....

                                                              +4

                                                              Undefined behavior. Неопределенное поведение. Если кратко — ситуация, которая не должна возникать во время работы программы, а если возникнет — то компилятор за дальнейшее поведение программы ответственности не несет.


                                                              Странно слышать от вроде как опытного сишника, что он не знает расшифровку этой аббревиатуры...

                                                                0
                                                                Я знаю, что такое Undefined behavior, но за аббревиатурой не признал, бывает… Спасибо, что пояснили…
                                                                +4

                                                                Дяденька, а вы точно сишник?


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


                                                                Вот, к слову, в С встречается паттерн


                                                                struct Foo { int a; int b; };
                                                                ...
                                                                Foo *foo = (Foo*)(malloc(sizeof(Foo)));
                                                                foo->a = 1;
                                                                foo->b = 2;
                                                                ...

                                                                Как думаете, это валидный C++-код? Обратная совместимость ведь, да?

                                                                  0

                                                                  А какие новые проблемы могут тут в С++ возникнуть, кроме той что malloc устарела?

                                                                    +2

                                                                    Лайфтайм объекта (не в смысле ООП, а в смысле стандарта) не начался. Надо placement new сделать в выделенный кусок памяти, например.


                                                                    Умный чувак Richard Smith описал это всё лучше меня: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0593r3.html

                                                                    0
                                                                    Точно, на всю голову ))))

                                                                    Скажем так, я с проблемами в таких местах не сталкивался, но понимаю, что компиляторы в некоторых случаях могут перемудрить… И эту «мудрость» можно искать ой как долго… Я стараюсь в плюсах не выделять память под классы (структуры) через маллоки…
                                                                      +6
                                                                      Если компилятор не нашёл в вашей программе ошибку, обратитесь к системному программисту, чтобы он исправил ошибку в компиляторе ©

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

                                                                      0
                                                                      Тока тут такой момент — в C не требуется делать (Foo*). А ошибка при компиляции типа «cannot convert void* to Foo*» как бы намекнет писателю, что он уже не на C пишет и надо бы заменить malloc на new. Обратной совместимостью тут и не пахнет, а то, что погромист решил заткнуть дырку через по сути reinterpret_cast — ну, сам виноват. В расте такие же погромисты будут подобные дырки через unsafe затыкать.
                                                                        0

                                                                        Это уже частности. Давайте смотреть абсолютно формально: вышеприведённый код является корректным кодом на С (ну с точностью до struct там перед Foo), но не является корректным кодом на C++, no diagnostic required.


                                                                        А вообще я в предыдущем комментарии не зря про mmap говорил. Его вы на что замените?

                                                                          0
                                                                          Я к тому, что «обратная совместимость» тут не при чем, и ее тут нет. Компилируемость достигается через добавление reinterpret_cast, который говорит компилятору «я погромист, я лучше знаю, делай, как сказано». Он для этого и предназначен.
                                                                            0
                                                                            Я к тому, что «обратная совместимость» тут не при чем, и ее тут нет.

                                                                            Именно.


                                                                            Но количество кода, которое так что-то считывает из сокета, или из файла, или ещё откуда, меня немножко печалит. Или пугает, хз.

                                                                            0
                                                                            На счет корректности в C не уверен на 100% — там выравнивание может не сойтись. К сожалению требования к выравниванию — не часть типа.
                                                                              0
                                                                              malloc() обычно реализован так, что возвращаемый им указатель корректно выравнен для любого built-in type на целевой архитектуре. Это не проблема.
                                                                                0
                                                                                Это-то да, но добавьте __attribute__((aligned(16)) — и упс(
                                                                                  0

                                                                                  Если вы любите всякие искусственные выравнивания на 16 байт в куче, то просто не используйте malloc. Используйте aligned_alloc и иже с ним. Но обычно все-таки этого не требуется, а требуется просто не трапнуться при доступе к int/long по невыравненному указателю. malloc с этим справляется искаропки.

                                                                                    0
                                                                                    Я прекрасно понимаю, что код conformant. И работает практически всегда. Но даже в подобном коде можно легко спрятать ошибку.
                                                                0
                                                                Какие проблемы есть в C, которые решают другие языки?

                                                                Стоимость разработчиков, время разработки и отладки. Если бизнесу нужен некоторый продукт определенного качества, ему будет непонятно за что платить цену в несколько раз выше. Понятно, что если без максимальной производительности в этом продукте никуда, то цена в 2-3 раза больше обоснована, если продукт одинаковый, то возьмут более «дешевый» и «быстрый» язык. Все что угодно можно сделать и на ассемблере, просто сильно дороже.
                                                                  0
                                                                  Вот статья по зарплатам разработчиков за 2018 год habr.com/ru/company/moikrug/blog/420391. Средняя зарплата Go-ика 130К, C-ика 100К, Rust- нет, но подозреваю, что их зарплаты будут ближе к 130К, чем к 100К. Как видно, другие языки, указанные в статье, не решают проблему стоимости. Более того, средняя зарплата Python-ниста 100К, как у сишника, а PHP-ика 90К, на 10% меньше чем в сишника… В 2-3 раза — это зарплата в 30-50К, в приведённой статье нет таких зарплат.

                                                                  Время разработки и отладки зависит от архитектуры и бизнес-логики. REST API проще написать на Go, не в 2-3 раза, но проще. Что-то более-менее сложное потребует сопоставимых усилий… У нас в компании есть два похожих, сопоставимых по сложности проекта, я пишу на плюсах, коллега на Go, скорости решения задач сопоставимы.

                                                                  Интерфейсы и некритичные по скорости скрипты, кстати, я пишу на PHP. Простые скрипты, типа пойди в ClickHouse, получи данные, агрегируй их и положи в MySQL, думаю, можно написать в 2-3 раза быстрее чем на плюсах. Но если логика становится сложной, этот выигрыш сходит на нет, большая часть времени уходит на написание и отладку логики… Для меня плюс PHP в том, что я могу за 10 секунд вставить var_dump в любое место скрипта и посмотреть результат, в плюсами это займёт больше времени, надо компилировать код.
                                                                    0
                                                                    C-ика 100К, Python-ниста 100К
                                                                    А сколько нужно питонисто-часов и сишнико-часов, что бы довести один прикладной проект до одной и той же степени безбаговости? А при условии низких требований к производительности? Возможно, питонисты справятся быстрее.
                                                                      0
                                                                      «Возможно» — это не в 2-3 раза, как писал vedenin1980 так ведь?

                                                                      Прошу прощения, но я не знаю, что такое «прикладной проект». Может быстрее будет на пайтоне, может на плюсах, а может быстрее будет на эрланге…
                                                                        0

                                                                        Я соглашусь, что у каждого языка своя ниша и условный проект на Питоне можно заколотить как прототип БЫСТРО и ДЕШЕВО, но потом стоимость его поддержки резко взлетает в космос. Хотя можете привести пример openstack, который на Питоне чуть более, чем полностью, и вроде даже дышит… Поэтому обсуждать виртуальные "усредненные" проекты, наверное, бессмысленно. Ну, и есть некоторая когнитивная сложность.
                                                                        К тому же, интересно, но по ощущениям крестовики получают больше всех. Хотя нет. Джависты (скалисты) тоже на уровне. А Сишники — о каких именно мы говорим? Их же много разных — от системщиков до ембеддеров. А еще мойкруг точно не может быть верным срезом рынка, т.к. мне достоверно известно, что "вкусные" и "интересные" вакансии распространяются только внутри профильных сообществ. Это примерно как с арендой квартир или покупкой б/у машин. Некоторые висят годами, потому что дорого и есть изъян (бабушкин ремонт, неудобное расположение и т.п.), а реально ценные предложения улетают как горячие пирожки (т.к. спрос превышает предложение).

                                                                          0
                                                                          Моя мысль была в том, что ни один язык не обладает магией или серебрянной пулей, позволяющий существенно ускорить разработку. Скорость разработки, стоимость поддержки в большей степени зависит от разработчика, а не от языка. Я о реальной разработке, а не о REST API на Python или в машинных кодах…

                                                                          Мне кажется, ещё немного и вы со мной согласитесь :)
                                                                            +2
                                                                            Моя мысль была в том, что ни один язык не обладает магией или серебрянной пулей, позволяющий существенно ускорить разработку.

                                                                            Конечно имеет. Например ГЦ это вполне такая серебрянная пуля. Платите прозиовдительностью, получаете продуктивность. Гц придумали уже давно. Чуть позже придумали вон те же линейные типы, где не надо жертвовать производительностью ради корректности. Получили в некотором смысле тот же гц, но без ранатйм оверхеда. Это не ускоряет разработку?

                                                                              –3
                                                                              Нет, не ускоряет.
                                                                                +2

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

                                                                                  0
                                                                                  Выше я уже выссказывал своё мнение по этому поводу и высказывал весьма пространно.
                                                                                    0

                                                                                    А чего не считая боттома? Дайте завтипам и проверке тотальности развернуться!

                                                                +2
                                                                А почему люди должны менять C на что-то другое? Мучится? Вы много мучались на C? Это стереотип, главный аргумент апологетов других языков… Какие проблемы есть в C, которые решают другие языки?

                                                                Проблему "тут у нас оказывается null", проблему "обязать компилятор обрабатывать неуспешый вызов функции", "обязательные бесплатные проверки выхода за границы", ну и все в таком духе.


                                                                Посмотрите на CVE майкрософта про винду. Или линуса про линукс. Вот все это.


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

                                                                  0
                                                                  Я с такими проблемами не сталкивался. Но меня заинтересовали «обязательные бесплатные проверки выхода за границы», можете поделиться, как это можно сделать?
                                                                    0

                                                                    Ну вот здесь. вкратце: https://habr.com/ru/post/460989/#comment_20433889 .


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

                                                                      0
                                                                      В том комментарии не указанно как именно делаются проверки выхода за границы без проверки.
                                                                        +1

                                                                        Компилятор знает, что итераторы никогда не выходят за границы, и в релизе их не проверяет, всё просто ведь.

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

                                                                            Не совсем так. Вот вы написали цепочку xs.map().order_by().then_by().filter().collect() — проверок не будет. Потому что компилятор видет, в что в любой момент времени i < n.

                                                                      0

                                                                      Зависимыми типами, например.


                                                                      А именно, например, функция доступа к элементу массива одним из аргументов просит доказательство того, что индекс корректен. Если вы можете статически на этапе компиляции это доказательство построить, то проверка для вас окажется бесплатной. Более того, даже если данные приходят, например, в рантайме, и статически ничего про них сказать нельзя, то проверку вы можете сделать ровно один раз, а потом таскать с собой результат этой проверки (propositions as types, proofs as terms, вот это всё).

                                                                    0
                                                                    В современном мире во главу угла ставится реиспользование кода. Велосипедостроение уже лет пять как считается дурным тоном, поэтому современный ЯП должен обладать мощным набором инструментов для быстрой сборки кода из готовых кусочков.
                                                                    Если функцию в 10 строк можно написать за 5 минут, то среда должна позволять так заворачивать и публиковать эту функцию, чтобы её можно было загрузить и добавить со всеми зависимостями к вашему проекту не более чем за 3 минуты, и чтобы при этом ничего не сломалось.
                                                                    В случае же C на реиспользование кода уходит столько времени, что проще оказывается написать код заново, чем добавить к проекту уже готовый. Собственно, издержки добавления готового кода тут столь велики, что добавлять имеет смысл только достаточно крупные библиотеки.
                                                                    В мире С в принципе не может существовать ничего подобного npm-пакетам, слишком уж трудно изолируются куски кода и слишком легко «уплыть» программе после добавления такого пакета, особенно если у него в свою очередь есть пачка зависимостей.
                                                                      0
                                                                      Я не завидую вашему опыту в Си, да и вообще в разработке… У меня нет ни каких проблем в повторном использовании кода как сторонних библиотек, так и своих… И задачи у меня нестандартные и интересные, они не решатся подобием npm-пакетов.
                                                                        0

                                                                        npm тоже, к сожалению, не идеал. Ибо реиспользование атомарных кусочков типа leftpad приводит к dependency hell.

                                                                  +17
                                                                  что приводит к тому, что большая доля планирования и кодирования уделяется, по сути, канцелярской работе

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

                                                                  Мне в расте нравится именно это, он _заставляет_ меня думать об архитектуре моего решения.
                                                                    +3
                                                                    Это да. Но жалуются на то, что _приходится менять_ архитектуру решения под язык.
                                                                      +22
                                                                      И это правильно. Иначе, как говорится, программист на фортране может написать программу на фортране на любом языке.
                                                                        +5

                                                                        Я сначала тоже жаловался. Потом понял, что язык все-таки прав, и что архитектура, которую "не хочется менять", на самом деле была шизофренична. То, что приходится делать из-за borrow checker, намного логичнее первоначальной идеи. Независимо от языка.

                                                                          –1
                                                                          Хотелось бы посмотреть на реализацию простого [шизофреничного] двусвязного списка на Расте…
                                                                              0
                                                                              А, ну как обычно. Если нужно на Расте сделать что то реальное, например ОПАСНЫЙ двусвязный список, то OB уже не работает и только unsafe =)

                                                                              Что ес-но, ценность unsafe делит на нуль. 26шт только в этом файле.
                                                                                0

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

                                                                                  +1

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

                                                                                    +2

                                                                                    может все-таки тогда pub/sub по сети? зачем тут списки?

                                                                                      0

                                                                                      Я не понял о чём вы. То, о чём я говорю, фактически и есть pub/sub только без накладных расходов.

                                                                                      0

                                                                                      Ну так да, бывают случаи.


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


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


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


                                                                                      Но везде делается один раз подобная обертка (да, с ансейфом), и потом везде используется. Просто структура данных плохо ложится на RAII, который является краеугольным в расте.


                                                                                      Ну а на тему того, что написали ансейф — потеряли все гарантии, могу разве что поделиться статьей (кстати, в качестве примера взят как раз связный список).

                                                                                        0

                                                                                        Вот как раз при реализации реактивности само собой напрашивается проставить всюду Rc/Weak — и никакого unsafe тут не понадобится.


                                                                                        Для двусвязного списка такое решение — дикий оверхед, а для реактивности оно напрямую следует из природы самой задачи.

                                                                                          0

                                                                                          RC/Weak сможет вызвать деструктор у значения, когда от него все отпишутся?

                                                                                            +1

                                                                                            Да, если каждая из подписок будет удерживать сильную ссылку.

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

                                                                                        Я последний раз применял 2-список в менеджере динамической памяти.

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

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

                                                                                        Ах, еще. Модель с одним владельцем применялась еще с Дельфи 1 — где прекрасно себя зарекомендовала и без заумных механизмов.
                                                                                          +2
                                                                                          Я не это имел в виду, а то что ансейф из-за необходимого количества его применений, перестает быть маркером «осторожно, волки»

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


                                                                                          • код в std это одно дело (ему даже нестабильные nightly штуки использовать можно, не то что unsafe),
                                                                                          • код крейтов со структурами данных (тут unsafe по практическим соображениям и правда часто может встречаться) или FFI это второе,
                                                                                          • а обычный код библиотек и приложений (где причин иметь unsafe мало) это третье.
                                                                                            +1
                                                                                            Я последний раз применял 2-список в менеджере динамической памяти.

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


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


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

                                                                                            Двусвязность — да. Список — нет.


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

                                                                                            Ну, я не могу говорить про чужой опыт, только про свой. Что типовое приложение это какой-то сервис, который состоит из контроллеров, которым нужны какие-то сервисы, которые в свою очередь работают с какими-то репозиториями и другими сервисами… Везде прослеживается дерево зависимостей в одном направлении, сервис про БД знает, а наоборот — нет.


                                                                                            Ну вот возьмем самый быстрый на текущий момент веб-фреймворк для примера, actix. Я нашел 12 unsafe в нем. Вопрос — означает ли это, что список в 2 раза труднее написать, чем полноценный веб-сервер с поддержкой http2/реконнектов/пайплайнинга/ssl/… ?


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

                                                                                            Не перестает — см. выше. На полсотни тысяч строк кода 12 ансейфов. Это много?

                                                                                              –1
                                                                                              Предлагаю флейм вести не ради флейма, а хотя бы сохраняя топик.

                                                                                              А топик, напоминаю, замена С/С++.

                                                                                              Из ваших примеров получается, что Раст хорошо заменяет С в области веб-фреймворка, но неудобен на низком уровне.
                                                                                              А я первоначально полагал, что должно было быть наоборот....o_O

                                                                                              Т.е я теперь запутался в позиционировании Раста.
                                                                                                +1

                                                                                                Позиционирование раста — быть безопасным, создавая иногда обертки над небезопасным подмножеством. Если у вас в задаче много "небезопасного" — вам раст все равно будет полезен, потому что позволит все это описать через безопасные абстракции. В худшем случае у вас ансейфа будет ну 10% от кодовой базы, это если FFI через FFI на микроконтроллерах со своим аллокатором, что-то в таком духе. А 90% будут юзать сейф подмножество, в котором все чистенько и сломаться не может. Всегда приятно сократить область поиска сегфолта в 10 раз (как правило, до единственного места где есть ансейф), не так ли?


                                                                                                Можете у humbug поинтересоваться его опытом написания tox-rs.

                                                                                                  +3

                                                                                                  0 unsafe в реализации протокола и сетевой части.

                                                                                                  +4
                                                                                                  Т.е я теперь запутался в позиционировании Раста.
                                                                                                  Вы запутались в слоях абстракции. Руст требует unsafe и особой внимательности при написании низкоуровневых абстракций. Однако оные абстракции — обычно составляют небольшой кусок кода.

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

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

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

                                                                                                  Вот rust — это как раз следующий этап: тут уже всякие стурктуры типа завязанных в узел списков объявляются «небезопасными» и выносятся «в угол»… что вовсе не значит, что они, вдруг, исчезают. Они не исчезают… просто в бо́льшей части кода (хоть низкоуровневого, хоть высокоуровневого) — они не нужны.

                                                                                                  Был бы ещё синтаксис у него не таким вырвиглазным — цены б ему не было. А так, похоже, придётся, рано или поздно, на него переходить — а глазам больно…
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                0
                                                                                Ну, Java и C# именно с этой мотивацией были созданы…
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                    +2
                                                                                    Ну Microsoft и J# пилил. Просто, как я понимаю, Microsoft сильно тянул одяло на себя и тогда очень недолюбливал Линукс как ОС, если бы не поругались кросплатформенности Java не было бы, скорее всего.

                                                                                    Java создавалось именно, как более просто и надежный C++, для прикладных задач бизнеса. Я еще помню эпоху прикладного энтерпрайзного C++, зарождения Java (да, я настолько древний) и жалобы программистов С++ «добавили новый код, ломается код в далеком модуле вообще никак не связанный с новым и потом неделями ищем почему.» Ошибки при работе с памятью в С++ давали очень сложно находимые артефакты, но относительно быстрого и удобного Си подобного языка не было.
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                        0
                                                                                        но это тоже не взлетело

                                                                                        Почему не взлетело? Взлетело. Был момент, и на девайсами миллионами ставили, и апплеты на каждом втором сайте были. Просто со времением заменилась другими технологиями (Flash, JavaScript и т.п.).

                                                                                        в те времена, когда все начиналось, Java рассматривалась

                                                                                        Тогда С и С++ были главными языками чуть ли не в каждой нише, даже сервисы и сайт на них делали, Java сразу создавалась как улучшенно-упрощенная версия С++, просто никто не расчитывал, что она так взлетит, поэтому сначала искали разные узкие ниши.
                                                                                          +2
                                                                                          Ява заняла свою нишу, но притом С++ не заменила. И за ней тоже уже пришли, в виде того же Go, в контексте данной статьи.
                                                                                        0
                                                                                        C# родился благодаря COM Object Runtime — попытки Microsoft устранить неустранимые недостатки COM, связанные с утечками объектов и неуправляемым доступом к памяти.

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

                                                                                        На этот момент были проблемы с использованием для этого Java, поэтому и приняли решение делать свой язык для решения своих проблем.
                                                                                          –1
                                                                                          На этот момент были проблемы с использованием для этого Java
                                                                                          Проблемы были в том, что Java не давали изуродовать, сделав Windows-only поделку. Так-то, скорее всего, в J++ 2.0 или 3.0 всё было бы… в 1.x уже были зачатки. Но суд не дал.
                                                                                      +2

                                                                                      Учитывая количество Легаси на си — да, его хоронить рано
                                                                                      Но писать в здравом уме что-то новое — не, спасибо. Иначе действительно будешь в аду и постоянно править постоянно всплывающие cve

                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                          +6

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

                                                                                            +6
                                                                                            Проблем с безопасностью меньше не становится.
                                                                                            Именно что становится, когда у вас автоматически решается целый класс проблем с безопасностью. В худшем случае приложение упадёт, вместо того, чтобы обеспечить неизвестно какой доступ/привилегии/возможности злоумышленнику. И да, лучше пусть оно падает.
                                                                                              –2

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

                                                                                                0
                                                                                                Вы еще забываете, что цена этой "безопасности" — вычислительные ресурсы

                                                                                                Это миф


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

                                                                                                И неверное следствие.


                                                                                                Ну и имеем еще поколение разработчиков, которые даже близко не понимают, как работает компьютер.

                                                                                                Перефразированный сократ, 400 лет до н.э.


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

                                                                                                Насчет абстракций — не могу высказться лучше, чем товарищ 1Tiger1 https://habr.com/ru/post/442112/comments/?mobile=no#comment_19821382

                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                    0

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

                                                                                                      0

                                                                                                      Еще чуть-чуть и для того, чтобы отредактировать текстовый файл потребуется десятки ядер и несколько десятков гб оперативной памяти. Зато разработчику не нужно будет вообще думать

                                                                                                      0

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

                                                                                                      +3

                                                                                                      Простите, но в каком именно месте Rust жертвует вычислительными ресурсами в пользу безопасности?

                                                                                                        +2

                                                                                                        Проверки границ в доступах к элементам массивов?

                                                                                                          +1

                                                                                                          Проверки в релизе оптимизируются же :dunno:


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

                                                                                                            0

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

                                                                                                              0

                                                                                                              Тоже можно, если доказать.


                                                                                                              Но обычно не нужно. Я не помню, когда последний раз писал for, всегда комбинаторы над всей коллекцией.

                                                                                                                0

                                                                                                                Динамическое программирование вы тоже будете через итераторы делать?

                                                                                                                  0

                                                                                                                  Динамическое программирование отлично работает индуктивно, а значит и на итераторах.


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

                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                        +8
                                                                                                        Утечка памяти и переполнение буферов достаточно известные проблемы, чтобы опытный программист никогда их не допускал.

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

                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                            +5

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

                                                                                                              0
                                                                                                              Внезапно, языки с сборщиком мусора и реализованной на уровне рантайма/языка проверкой доступа к элементам массива именно это и делают (ну да, утечки так устраняются не все, но много).
                                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                  +1
                                                                                                                  Внезапно, у всего есть недостатки, но эти языки сделали ровно то, что, как вы сказали, «вы не сможете придумать». Эти языки устранили некоторые классы ошибок целиком.
                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                      –1
                                                                                                                      На любом языке вы сможете сделать машину Тьюринга, поверх неё C++-машину, а поверх неё — любые ошибки, какие захотите.

                                                                                                                      Потому непонятно — о чём вы, собственно, говорите вообще.
                                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                        0

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

                                                                                                                  0

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

                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                      0
                                                                                                                      Про гонки данных — я ничего не могу сказать. Каким образом Rust их избегает?


                                                                                                                      doc.rust-lang.org/nomicon/races.html
                                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                          +3

                                                                                                                          Гонки бывают разные.
                                                                                                                          Гонки данных — лишь частный случай.
                                                                                                                          Rust не может исключить те же dead-lock'и на мьютексах, например. Но Rust не позволит просто так взять и забыть освободить мьютекс. И Rust не позволит иметь ссылку на данные, защищённые мьютексом, после его освобождения.

                                                                                                                            +2
                                                                                                                            Rust вроде запрещает гонки данных при обращении через ссылки: правила заимствования не дают. Т.е. по сути запрещен мутабельный алиасинг. Предотвращение гонок между потоками только за счет типов аргументов: библиотеки написаны так, что ссылки, уходящие в другой поток, должны быть потоко-безопасны.
                                                                                                                            Как я понимаю, можно извратиться и обойти, но зачем?
                                                                                                                          +2
                                                                                                                          И вместо SIGFAULT вы получите некорректный результат.

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

                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                              +3

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

                                                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                  +1

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

                                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                        +1
                                                                                                                                        Я больше недели искал дефект в ядре, который появился из-за того, что происходил доступ за выделенный буфер. Проявлялась она очень редко, при опросе ARP-записей, причём никакого отношения к этой подсистеме дефект не имел.
                                                                                                                                        Память в неуправляемых языках — это глобальный ресурс, поэтому это осложняет поиск, так как необходимо быть готовым рассматривать весь код, включая бинарные блобы.
                                                                                                                              +5
                                                                                                                              Статический анализ не способен отследить перемещения ссылок для объектов которых еще не существует на момент компиляции

                                                                                                                              Статический анализ при наличии соответствующих деклараций может гарантировать исключительность ссылок или их иммутабельность. Там, где он не может гарантировать — Вы не сможете использовать бесплатный механизм заимствования в таком виде, и Вам придётся использовать "платные" механизмы доступа/синхронизации в runtime. Цена "платных" механизмов тоже может существенно различаться и у программиста есть выбор. Но это совершенно не значит, что, если в каком-то месте пришлось задействовать runtime, то его придётся использовать везде, как в языках с GC. Механизм заимствований продолжает приносить пользу для всего кода между обращениями к runtime-механизмам.


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

                                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                          0
                                                                                                                          А еще вы упомянули про взломы интернет-ресурсов, но забыли отметить, что наиболее шумное и массовое событие из этой области за последнее время было связано, внезапно, с heartbleed в реализации библиотеки написанной на Си :)

                                                                                                                          Хм, а я думал, что heartblead наполовину хайп, как проблема 2000 года. Принципиально лечится.
                                                                                                                          А вот аппаратные дыры из-за спекулятивного выполнения…
                                                                                                                            0

                                                                                                                            Лечится-то оно лечится, но вылечить вовремя не успели. В отличии от проблемы 2000 года.

                                                                                                                              0
                                                                                                                              И..? Мир рухнул?
                                                                                                                                0

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

                                                                                                                          +5
                                                                                                                          Вы так смело пишите «криворукие программисты». Аж диву даешься. Вам 15 лет? Как можно быть настолько уверенным в собственной непогрешимости.
                                                                                                                          Люди делали, делают и будут делать ошибки.
                                                                                                                          Я вас лично конечно не знаю, но знаю очень крутых ребят. И даже они очень сильно временами косячат.
                                                                                                                          Конечно если у вас 200 строк кода на Си может это не страшно, но это смешно такое такое читать, когда накоплена такая огромная статистика.

                                                                                                                          Это все-равно что сейчас заявить: «что я не пристегиваюсь ремнем безопасности, потому что я аккуратно вожу. А вокруг криворукие водители.»
                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                        +8

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


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


                                                                                                                        Опасности при работе с системными ресурсами эмбедом на самом деле намного меньше, чем некоторые думают. Просто почему-то люди решили, что это норма.

                                                                                                                          +4
                                                                                                                          Опасности при работе с системными ресурсами эмбедом на самом деле намного меньше, чем некоторые думают. Просто почему-то люди решили, что это норма.

                                                                                                                          Поддержу. Среда выполнения стандартного сервера куда более "дикая", чем какой-то микроконтроллер, где, во-первых, работает закрытый перечень программ, а, во-вторых, общение с МК производится по вполне конкретным декларированным интерфейсам, а не так, что кто-то может влезть сбоку-припеку в Вашу программу.

                                                                                                                            0
                                                                                                                            а не так, что кто-то может влезть сбоку-припеку в Вашу программу

                                                                                                                            Да вы прямо в условиях дикого запада программируете…
                                                                                                                      0
                                                                                                                      C не похоронят, а С++ могут. C++ могут через С ABI и новые модули написать уже на чем угодно…
                                                                                                                      А если учесть, что С наконец-то начал развиваться и туда подвезут простых и полезных фишек.
                                                                                                                        0
                                                                                                                        А если учесть, что С наконец-то начал развиваться и туда подвезут простых и полезных фишек.

                                                                                                                        Да что-то не слишком. С расширениями, столь необходимыми для встраиваемых систем (и не только) уже сколько тянут…