У Интернета могут быть серьёзные проблемы из-за языков, подобных C и C++, которые способствуют появлению уязвимостей

Привет, Хабр! Представляю вашему вниманию перевод статьи "Internet aurait de sérieux problèmes à cause de langages comme C et C++ favorisant la survenue de failles" (фр. язык).

Но мало кого из разработчиков это волнует


Один баг затрагивает iPhone, другой – Windows, а третий – сервера, работающие на Linux. На первый взгляд эти баги не имеют ничего общего, так как касаются разных платформ: Android, iOS, macOS, Windows, Linux. Однако, на самом деле, всё иначе, по мнению Алекса Гейнора, инженера по безопасности программного обеспечения в Mozilla, ранее работавшего в USDS (United States Digital Service).

[1]
Подробнее — https://www.usds.gov, здесь и далее прим. переводчика.

Во время третьего «Weakest Link», ежегодного мероприятия, организованного Motherboard Vice,

[2]
Подробнее — https://motherboard.vice.com/en_us

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

Гейнор объяснил, что три ранее упомянутые ошибки существуют, потому что программное обеспечение, которое они затрагивают на разных платформах, было написано с помощью языков программирования, имеющих неприятную тенденцию способствовать возникновению ошибок типа «memory unsafety», разрешая доступ к невыделенным областям памяти.

[3]
Скорее всего, имелось в виду, что обращение к 6 элементу массива, состоящего из 5 элементов, допустимо, хотя в других языках программирования, более «безопасных», как минимум будет выведено сообщение об ошибке.

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

Давая возможность для возникновения ошибок типа «memory unsafety», языки программирования, такие как C и C++, могут способствовать распространению почти бесконечного потока критических уязвимостей безопасности на протяжении многих лет. В качестве примера этих уязвимостей можно привести:

  • несоответствие типов
  • переполнение буфера
  • переполнение целочисленных переменных
  • уязвимость «use after free»

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

Переполнение буфера (или «buffer overflow» на английском языке) является критической уязвимостью безопасности, которая возникает, когда пользователь вводит строку, которая будет находиться в массиве символов недостаточного размера. Это приводит к записи данных вне области памяти, выделенной для массива. HeartBleed, например, оказавший влияние на 17% защищенных серверов в интернете, был уязвимостью переполнения буфера, позволяющей считывать 60 КБ после конца списка, включая пароли и другие пользовательские данные.

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

Уязвимость «use after free» обычно возникает в случае использования указателя или данных в памяти, когда указатель (или блок памяти) уже освобожден.

Вместе эти уязвимости представляют собой эксплойты, наиболее часто встречающиеся в популярном программном обеспечении, к примеру, Firefox, Chrome, Windows, Android или iOS. Гейнор уже насчитал по крайней мере 400 и утверждает: «Я следил за безопасностью этих проектов более года, и почти во всех версиях этих продуктов более половины уязвимостей — это «memory unsafety». И еще более тревожно то, что тяжелые и критические уязвимости [...] почти всегда имеют этот тип».

Несмотря на значительные риски, связанные с безопасностью программного обеспечения, которое они поддерживают, языки программирования «memory unsafety friendly», такие как C или C++, всё ещё используются разработчиками, в то время как проверенные альтернативы, такие как Rust, Swift, которые можно рассматривать как языки «memory safe», редки.

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

Кроме того, большинство программных проектов, даже самых важных для безопасности Интернета, не являются новыми. Они были запущены десять лет назад, если не больше. Linux, OpenSSL и веб-серверу Apache, например, более двадцати лет. Для масштабных проектов, подобных этим, переписывание всего кода на новом языке не вариант. Они должны быть преобразованы постепенно, что значит, что проекты должны быть написаны и сохранены на двух разных языках вместо одного. Это также предполагает необходимость формирования большой команды, которое занимает много времени и требует больше средств.

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

А что Вы думаете по этому поводу?



Отмечу, что здравая критика перевода также приветствуется.

Спасибо за внимание!
Поделиться публикацией

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

    +2

    уязвимости будут всегда, пофиг какой язык

      +16
      Вопрос в количестве уязвимостей.

      Если язык способствуют созданию ошибок, то количество уязвимостей всегда будет больше, чем если используется относительно безопасный язык. Даже у очень умных и опытных программистов.
        +3
        Если какой то язык становится популярным, то на нем начинаю программировать люди разной квалификации. И те у которых она не высокая, смогут завсегда сделать что то такое что приведет к уязвимости. И что то мне кажется хотя я возможно и не прав, но чем популярней язык тем больше в нем низкоквалифицированных людей(ничего плохого, это норма) и значит больше которые совершенны при помощи него. И то что там memory safe не спасёт их от другой кучи ошибок, которые порадят уязвимости.
          0
          Вот да. Уязвимость — в первую очередь ошибка и/или допущение в алгоритме. Не важно, на каком языке, например, писать веб-форму для записи в бд. Если запросы к бд строятся конкатенацией строк да без фильтрации — однажды обязательно прилетит DROP DATABASE; как значение поля и выполнится.
            +1
            Ну теоретически можно уменьшить вероятность этого техническими средствами. Например, если входящие строки имеют тип ExternalString, а строковые константы из исходников InternalString, и их можно приводить друг к другу без создания нового объекта, но только явно, то компилятор покажет ошибку типа «Cannot concat InternalString with ExternalString». Автор задумается и поищет информацию почему так, и уязвимость появится только из-за намеренных действий.
              +3
              И автор найдёт, как прикастить ExternalString к InternalString и добавит один каст и всё будет работать. Как будто вы не видели небезопасный код, проходящий проверку всеми статическими анализаторами.
                +1
                Ну это и будут намеренные действия. Большинство SQL-инъекций все-таки не намеренно делают, а потому что «работает же».
                  +2
                  Где вы видите намеренные действия? Низкоквалифицированный программист написал код с инъекцией, например так:
                  ExternalString userInput = myWebSocketClient.receive();
                  InternalString query = "SELECT password FROM `users` WHERE username = " + userInput;
                  myDatabase.query(query);
                  

                  Компилятор рассказал ему, что нельзя конкатить ExternalString и InternalString, на что программист ответил «ну ладно» и написал
                  ExternalString userInput = myWebSocketClient.receive();
                  InternalString query = "SELECT password FROM `users` WHERE username = " + (InternalString) userInput;
                  myDatabase.query(query);
                  

                  Вот и уязвимость.
                    +1

                    Добавление (InternalString) само произошло, или все-таки программист намеренно написал? Кто-то просто напишет, а кто-то задумается и поищет информацию, почему возникает ошибка, и найдет что конкатенировать внешние данные с внутренними приводит к инъекциям. То есть это уменьшает вероятность появления инъекции в коде на этом языке. Низкоквалифицированные программисты низкоквалифицированны потому что не знают, а не потому что специально вносят баги. А если компилятор ничего не говорит, то и нет повода что-то узнавать.

                      +3
                      Кто-то просто напишет, а кто-то задумается и поищет информацию, почему возникает ошибка,

                      Один то может задумается, а потом придет «обезьянка» и тупо у себя в коде точно так-же нафигачит, потому что Большой Тим Лид тоже ваяет именно так. Это никак не решает проблему.
                        0
                        Проблему не решает, а вероятность уменьшает. Тесты тоже можно неправильно написать, это ведь не значит, что тестами не надо пользоваться.
                          +1

                          А еще обезьянка может по умному совету со StackOverflow rm -rf / куда-нибудь вставить.

                            0
                            Вы так говорите, будто этого никто не делал.
                            sudo только не забудьте.
                              0
                              Инсталлятор NVidia-драйверов запускался с root-правами )))
                                0
                                Зачем его запускать руками, если это делает пакетный менеджер?
                                0

                                Естественно, делал.
                                Более того, недавно я даже стал этому свидетелем)
                                Но это же не повод отменить разграничение прав?
                                Аналогично, возможность понаделать небезопасных кастов не повод отказаться от защиты от инъекний на уровне типов.

                +8
                Конечно, более популярные языки привлекают менее квалифицированных программистов.

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

                Можно попытаться сравнить число уязвимостей в проекте, написанном супер-профессионалами на C с числом уязвимостей в проекте, написанном средними программистами на Java. Тут непонятно, как выйдет. Но те же супер-профессионалы, перейдя на Java, допустят меньше ошибок, чем сами же на C.

                [зануда_mode on]
                Напомню, что в любом реальном проекте на сотню тысяч строк уязвимости точно есть. Вопрос только в количестве и трудности поиска.
                И да, сторонние библиотеки точно так же содержат уязвимости и, вообще говоря, их строки надо добавлять к строкам проекта. Они могут быть лучше написаны и протестированы, и ошибок в них может быть меньше, но в достаточно объемной библиотеке они точно есть.
                [зануда_mode off]
                  +4
                  А можно взять PHP который вроде тоже memory safe и поглядеть число дырявых движков на нем написанных.
                  0
                  ieee.org: The Top Programming Languages 2018. (из анализа выборки в 300 языков)
                  Есть вкладки-фильтры данных

                  spectrum.ieee.org/static/interactive-the-top-programming-languages-2018

                  P.S. Что не удивительно выводит на пик популярности язык программирования Python.
                    0

                    Зато спасет от memory unsafe.

                      +1
                      Да причём тут квалификация, Си нужно было развивать, как это сейчас пытаются развить плюсы(с переменным успехом).
                      Что за глупость заморозить язык на десятилетия, я этого совершенно не понимаю.
                      Столько очевидных источников ошибок.
                      Си и С++ стоило развивать в тандеме, чтобы не терялась обратная совместимость, но при этом было развитие и устранение врождённых недостатков.
                    +3
                    Микробы будут всегда, пофиг мыть или не мыть руки.
                    +4
                    А что Вы думаете по этому поводу?

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


                      +1
                      А какую воду вы предпочитаете пить? Дешёвую – из-под крана, или значительно более дорогую – бутилированную?
                        +5
                        Не важно, что предпочитает один человек. Важно заставить всех перейти на хорошую воду. В том числе и при приготовлении продуктов, которые употребляет человек, выбравший себе бутилированную воду (а пирожки для него, например, готовят на воде из-под крана, а он даже и не подозревает).
                          +2
                          Согласен. Но для начала нужно прийти к согласию, что есть вещи, которые более вредны, а есть те, которые менее. Как и с курением: вы не снизите уровень курильщиков в стране, пока в общественном сознании не закрепятся медицинские факты, что курение реально повышает шасны преждевременно умереть из-за рака.
                            –4
                            И сразу ошибки, которые можно выявить на этапе тестирования.
                            1) Про вред курения. Если сравнивать курение человека, который живет на природе в чистой среде и питается исключительно чистыми продуктами (иных нет), живя далеко в Сибири, в Африке и т.д. с человеком, который ни разу не курил в жизни, но живет через дорогу от металлургического комбината, хим.завода или даже все вместе. Про всякие тепловые электростанции молчу. То я бы не сказал, что курение вредно, оно даже может быть полезно, вроде прививок, при количестве 1-2 сигареты в месяц или год. Особенно, если человек из природной среды поедет к человеку города или живущему рядом с промышленностью. так сказать — заблаговременная подготовка к нахождению в опасных условиях.
                            Был даже забавный случай, когда некоторых знакомых пытались убедить бросить курить, аргументируя вредом здоровью. Особенно смешно звучало для металлургов и сварщиков, особенно для сварщика, который варит без какой либо защиты для органов дыхания. Покупка защиты отложена до лучших времен, а сейчас банально з/п не хватит, ныне платят за такой труд всего лишь около 6 тыс руб (инфа 2-х летней давности по з/п, но я не слышал о кардинальных подъемах з/п).

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

                            Отсюда — приходим к известному «все лекарство и все яд. Зависит от дозы». Слишком много с/с++ стало ядом, причем на подобии медленно действующего токсического яда. В небольших дозах незаметен, а позже ошибки накапливаются и могут вызвать смерть пациента (тут ссылку про разорение кого-либо из-за ошибки программиста)
                              0
                              1) Идея про «прививки для подготовки к городу» интересная. У вас есть данные, что она помогает, или это только идея?

                              2) С выпусканием воздуха скорее проблема в том, что в существующем в городе есть процент нежелательных примесей. Скажем, угарного газа в воздухе 40 мг/м3 (вдвое выше ПДК). Чтобы заменить половину воздуха в комнате 20м2, надо выпустить ~62 кг смеси азота с кислородом (на самом деле больше, т.к. выходить из комнаты будет смешанный воздух, где есть и чистый, и «грязный»).

                              В общем, не очень практичный метод — слишком много его надо привозить очищенного.
                                0
                                В далекие доинтернетные годы читал японское исследование, утверждавшее, что в группе курящих до 5 сигарет в день заболеваемость обычно связываемыми с курением болезнями ниже, чем в сопоставимой по демографическим показателям группе некурящих. Но уж очень давно это было, так что ссылку не найду и за что купил, за то и продаю.
                              –3
                              Риск рака, как показывает практика, не работает.
                              Лучше продвигать очевидную истину, что курильщик при прочих равных глупее, безвольней, больнее, беднее.
                              Ух, сейчас курильщики набросятся на объективную реальность! Наркотик давит на мозг.
                              0
                              Важно заставить всех перейти на хорошую воду

                              Важно заставить

                              Зачем заставлять?

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

                                  Есть санитарные нормы. Вряд ли можно ожидать что-то лучше них, если не брать випобслуживание. Надеяться на культуру можно, но не ясно, как это могло бы выглядеть. Промышленный фильтр в ресторане? Это возможно, но без требования санитарных норм всё равно каждый второй владелец будет игнорировать.
                                  Расходы же.

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

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


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

                              +3
                              А вы уверены, что в бутылке качественная вода?
                                +1
                                … и вода ли…
                                Вот например, спирт этиловый и спирт метиловый. На запах/вкус/цвет одинаковы, даже эффект по началу одинаковый…
                                  0
                                  Я правильно понял вашу аналогию, что может быть «С++, идентичный натуральному»?
                                    0

                                    Ну тут вопрос философский. Что такое натуральный ароматизатор и идентичный натуральному? И то и то химия. Где-то все лишнее убрали или где-то все нужное добавили.

                                      –1
                                      Аналогия была к воде. С виду одно, а последствия могут быть всякие — не сразу и поймешь, что случилось.
                                      К слову, на «С++, идентичный натуральному», действительно, тоже ложится. Всякие rust'ы и swift'ы, конечно, здорово, — а с производительностью там что? Не в масштабе поделки-микросервиса, а по-больше и по-ответственнее. Взять то же ядро линукса: сетевая подсистема, менеджер памяти — как они себя поведут?..
                                      0
                                      У нас другой случай был. Покупали качественную бутылированную воду, а в один прекрасный день увидели в бутылке мусор. Производителья сменили, но где гарантия?
                                        –1
                                        Простые действия — звоните конкурентам этого производителя (только уточните, что это конкуренты, а не борьба нанайских мальчиков) и выгодно продаёте эту бутыль. А уж соперник, поверьте, отработает ситуацию по-максимуму.
                                    +2

                                    Хм… Вариантов больше чем два. Вода из-под крана фильтрованная. Вода из-под крана кипяченная. :) бутилированая тоже может быть из крана с нашлепкой "из артезианского источника на глубине пяти километров".

                                      0
                                      где-то читал, что 70% всей бутилированной воды это именно водопроводная фильтрованная. Опять же, есть разные фильтры (включая обратный осмос, где она будет вообще дистилированной, добавь нужных солей и разливай), как и обслуживать их можно по разному.
                                      +1
                                      А какую воду вы предпочитаете пить? Дешёвую – из-под крана, или значительно более дорогую – бутилированную?

                                      Там где я живу, вода из под крана — качественная. Так что бутилированная мне дома не нужна.
                                      А есть районы города, где вода из под крана — ржавая и им приходится пить бутилированную и на ней же готовить еду.
                                        –1
                                        Проблема с качеством дорогой бутилированной воды всё равно останется. Если все перестанут потреблять дешёвую воду из под крана, то качество дорогой воды вероятнее всего снизится.
                                        Экономика? Не, не слышал.
                                      0
                                      Хорошая статья, а ведь была идея Java OS, где все проблемы решались, кроме быстродействия в момент сборки мусора :)
                                        –3
                                        Ой, вечно Вы со своей JVM влезете куда не следует. Безопасность на уровне, описанном в статье, нужно реализовывать через Rust, а не через Java. Любая жабоось будет серверным решением худшим, чем серверные решения мелкомягких — адекватного тюнинга в жизнь не добиться.
                                        Статья формулирует проблему, которую не решить — переписать код ядра *nix. По человеко-часам это займёт приблизительно… лет 30, при том, что текущее ядро параллельно с этим не перестанет развиваться.
                                          +2
                                          И даже если кто-то всерьёз скажет, состроив злобную гримасу и стукнув кулаком по столу, «срочно совершаем [ре|э]волюцию!» — ничего не произойдет. Это как с IPv6 — «… а воз и ныне там...»
                                            +1
                                            там скорее не в переписывании как таковом, а в наследии. Существуют системы, в которых уже залиты ядра линукса. И им обновления уже никогда не прилетят. Например, какой-нибудь медицинский прибор. Но вот поддерживать такой аппарат — вполне нужны те, кто будут ориентироваться в ядре линукса, чтобы избавить уж совсем критические ошибки, которые могут повлиять на пациентов. А утечка данных иной раз с таких аппаратов не опасна, т.к. физически невозможна — аппарат может банально не включен в интернет-сеть за ненадобностью.
                                            Весь сыр-бор в первую очередь из-за утечек данных, а часть индустрии на это клала. Образование (те же школы), медицина (кроме данных пациентов), многие бюрократические организации (особенно на просторах СНГ). Еще есть те, у которых компьютеры к сети просто не подключены.
                                              0
                                              В медицинских приборах запросто может быть какой-нибудь Windows 2000 Embedded.
                                              Кстати, мы решали проблему с УЗИ аппаратом. Врачи хотят в него втыкать флэшки, а куст реестра в 2000 имеет ограничение, по-моему, 64МБ, иначе система падает в BSOD. Решение: регулярно чистить раздел с подключенным когда-либо устройствам.
                                              С точки зрения же безопасности… Ну, есть «золотой» образ системы, снятый механизмом типа ghost/acronis. Ну, и всегда такие штуки нужно защищать по периметру снаружи, т.к. в них самих почти наверняка настройка файрволла и т.п. запрещена.
                                                0
                                                Вот ведь дичь… Ответственные системы, конечно, должны загружаться исключительно с ROM носителя. Всё в ОЗУ. Если очень надо сохранять пользовательские конфиги/параметры от вкл к вкл, то другая память, отдельная от системной с контролем целостности.
                                                  0
                                                  Никто таким не заморачивается. Даже не под рутом и хотя бы 2 раздела на диске (С — системный и Д — пользовательский, с разными правами на доступ) — даже такое в условиях старой ОС, маленького HDD, проблем с администрированием (как аппаратные/программные, так и низкая квалификация администратора) — полностью уничтожает безопасность.
                                                  Самому было лень настраивать полноценно подобные компьютеры на волонтерских началах. Поэтому со временем туда и вирусы попадали, и всякие игры устанавливались третьими лицами.
                                            0
                                            По человеко-часам это займёт приблизительно… лет 30

                                            То бишь, 30 разработчиков справятся за год? И не надо только про 9 женщин и ребенка за месяц, ок?)
                                              +1
                                              Там зависимость нелинейная. То что один разработчики в идеальном случае сделает за 30 лет, то 30 разработчиков сделают года за два минимум, т.к. нужно учитывать накладки на синхронизацию и управление командой. Да и не все задачи параллелятся
                                                0
                                                Еще есть эффект «вторых глаз» и «второго мозга» — когда новый человек может что-то увидеть / посоветовать, до чего первый так никогда и не догадался бы.

                                                Хотя, конечно, после подключения 3-го человека расходы на синхронизацию обычно превышают этот эффект.
                                                0

                                                Если этот год не будут спать, есть и как-либо отрываться от кода, при этом зная Pure C, Rust, архитектуру ОС и архитектуру ВМ и сетей и частное — отдельные конкретные реализации и воркараунды для железячных мест, где воркараунды нужны и почему на уровне способности "читать и писать без подсказок в 90% случаев и знать где быстро найти для остальных 10%" — то да, года будет достаточно. Утрированно, конечно, у каждого из этих тридцати своя нечеткая специализация, и 90% можно даже превратить в 70%, уух, задачу облегчили уже! Четкой специализации для команды в 30 человек не нужно, но понятие о всех остальных отраслях у них должно быть. Найдете 30 таковых по всему миру?

                                                0
                                                Так вроде в Redox уже переписали все ядро на Rust, но похоже им денег не дают, да и будущее самого Rust и Мозиллы тоже не безоблачно, и хотя они действительно хорошие разработчики, но гугл богаче…
                                                  +1

                                                  "Переписали" — всё же громко сказано, это был PoC операционной системы на Rust, сделанный с нуля и после этого уже несколько раз переписанный с пониманием "как делать не надо". Изначально Redox позиционировался как игрушечный проект и на вопрос "это замена Linux?" авторы давали определённый отрицательный ответ.

                                                    0
                                                    Спасибо
                                                0

                                                Добро пожаловать в Android. Одни проблемы решились, другие появились.

                                                  0
                                                  Это точно. Так хочется серебряную пулю, а ее все нет и нет…
                                                0
                                                Сам посыл, звучит как: «У яйца могут быть серьёзные проблемы из-за курицы»…
                                                  –1

                                                  Я думаю, нужно начинать переписывать *nix и другие критически важные для сети вещи на Rust.

                                                    +5

                                                    Как там у Rust с формальной верификацией?

                                                      +6

                                                      https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf
                                                      http://plv.mpi-sws.org/rustbelt/


                                                      Отлично. Раст — формально верифицированный язык.

                                                        –5

                                                        Rust не может быть верифицирован на данный момент, потому что у него даже спецификации нет.


                                                        То, что верифицировано в этой статье, это некоторое пожножество системы типов Раста, как его понимают авторы статьи.


                                                        Если говорить о реальности, то известно, что Раст в текущей реализации небезопасен (содержит десятки "багов", самому старому из которых >5 лет).


                                                        Так что ситуация хоть и несравненно лучше, чем с C и C++, но далека от той идиллии что рассказывает Rust-пропаганда.

                                                        +6

                                                        Мы работаем над этим. А как у C++ дела?

                                                          +7

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


                                                          Конкретно в https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf формально доказывается, что система типов Раста, владение, заимствование и прочее — корректны. Доказывается, что программа безопасна, если написана на безопасном подмножестве Раст. Доказывается, что программа безопасна, если в ней есть вкрапления unsafe, в которых программист не допустил ошибки, UB.


                                                          Кроме того, проект RustBelt на текущем этапе занимается формальной верификацией библиотеки std, но полная проверка требует времени. Поэтому библиотеку проверяют по кускам. Да, были найдены и исправлены 2 ошибки в unsafe коде (что показывает, что ребята делом занимались), тем не менее все эти thread, mutex, Arc/Rc формально безопасны.

                                                            0
                                                            Ну хорошо, язык и компилятор пускай корректны. Но ведь большинство проблем не в компиляторе, который многократно перепроверен и оттестирован. Большинство проблем в коде, который пишут прикладные программисты. На корректном языке можно написать некорректную программу. Чтобы решить проблему, поставленную в статье, нужно верифицировать не раст, а программы, на нём написанные.
                                                              +5
                                                              Чтобы решить проблему, поставленную в статье, нужно верифицировать не раст, а программы, на нём написанные.

                                                              Давайте я подробнее распишу свою цитату:


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

                                                              Эта означает, что формально доказано, что в программе, написанной на Rust без unsafe, отсутствуют проблемы с памятью, нет use after free, нет buffer overflow, то есть всех этих memory unsafety. И гонок данных тоже нет.


                                                              Проверка всех правил и контрактов в блоке unsafe { } ложится на плечи программиста. Потому что unsafe означает: заткнись, компилятор, я знаю, что я делаю, хватит меня поправлять. Никто не запретит вам вызвать два раза подряд libc::free на один и тот же указатель, вопрос в том, что ручное освобождение с помощью free возможно только внутри unsafe.


                                                              И тут мы приходим к статистике: в 99.9999999% случаев вам не понадобится ручное управление памятью в Rust (ну прям как в CppCoreGuidelines, используйте RAII). В 99.9999999% случаев вам не нужен unsafe. А если он и нужен, то он строго локализован (иначе на ревью надо отрывать руки). unsafe — это явное ключевое слово, его можно грепать по проекту, на него можно настраивать триггеры, любое появление unsafe в проекте — эпохальное событие, которое необходимо проверить. Ибо внутри unsafe можно выстрелить себе в ногу. И люди стреляют. Надеюсь, вы понимаете разницу между двумя проектами в 300 KLOC, но один написан на Rust с 1 строчкой unsafe, а второй написан на C++. Как говорится, happy debugging.


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

                                                              Ну это правда, и Rust не позиционирует себя как язык, защищающий от int getRand() { return 42; }. Он защищает от целого класса ошибок, связанных с памятью, что доказано формально, т.е. математически =)

                                                                0
                                                                Так вроде понятно. А как можно было трактовать ваше Доказывается, что программа безопасна, если написана на безопасном подмножестве Раст. Я решил, что это отсутствие ошибок.
                                                                  0

                                                                  От логических ошибок не защищает =)

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

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

                                                                        0
                                                                        Да. Если бы не понимал, то не оставил бы предыдущий комментарий.

                                                                        Хотя, возможно, мы просто по-разному парсим исходный вопрос этой ветки. Он неоднозначен.
                                                                          0

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


                                                                          aeeneas, не могли бы вы уточнить, что вы имели ввиду под:


                                                                          Как там у Rust с формальной верификацией?
                                                            0
                                                            Я имею ввиду — помогает ли Rust доказать корректность программ, как это можно делать, например, в Coq? Если нет — то какой смысл переходить на него с C/C++, для которых уже есть кодогенераторы из высокоуровневых сред разработки, верифицируемое подмножество и соответствующие инструменты.
                                                              +7
                                                              Programming Defeatism: No technique will remove all bugs, so let's go with what worked in the 70s.
                                                                0

                                                                Просто не оправдывает возложенного на него хайпа.

                                                          +3

                                                          Ну переписывай. В чём проблема?

                                                          +7
                                                          Ну тут мужик в корне не прав. Это не С++ виноват. Это мышка не того цвета, клавиатура не так клацала, фазы луны не те…
                                                          Тут JS может из браузера вломится в соседнюю вируальную машину. Тоже С++ виноват?
                                                          Может архитектуру безопасности ОС пересмотреть, раз такие косяки ОС допускает сделать?
                                                            +3

                                                            А на чем написан JS?))

                                                            –2
                                                            Ахаха, даёшь безопасный браузер на джаваскрипт, с js движком на питон) Раст ещё сырой, чуть что быстрое надо — используй unsafe, за синтаксическим сахаром — в ночные сборки компилятора. Вобщем выбор без выбора.
                                                              0
                                                              Автор не понимает вещей о которых он рассуждает. Действительно зачем разбираться в теме, если можно сделать пару угодных публике заявлений, в духе: cтарые ЯП ужасны, ведут к ошибкам, поэтому вы их даже не учите. Расслабьтесь с нашим новым модным ЯП, где ошибок нет. Поэтому не напрягайте голову, а пополняйте ряды нашей секты. Все кто думают иначе еретики.
                                                              Давайте сразу так:
                                                              Кроме того, большинство микропроцессорных архитектур, даже самых важных для безопасности Интернета, не являются новыми. Они были запущены десят лет назад, если не больше. X86 например, более тридцати лет. И они не разделяют команды и данные «memory unsafely». Для масштабных проектов, подобных этим, замена всего оборудования потребует десятки лет…
                                                                +1
                                                                X86 например, более тридцати лет. И они не разделяют команды и данные «memory unsafely»
                                                                Так-то запрет исполнения кода из сегмента данных (NX bit) возник лет 15 назад, а на архитектуре x64 он вообще обязателен.
                                                                +3

                                                                Я понимаю, им надо пиарить rust, но все же современный C++ далеко не так плох, как его описывает автор. Другое дело, что адаптация новых стандартов идет медленно. Но все равно, куда проще плавно перевести код с C++98 на C++17, чем на rust.


                                                                Ну а C — там да, нужно только по спец разрешению пускать людей писать на нем код, только с десятикратным code review. Тк за кажущейся примитивностью и понятностью языка, скрывается возможность понаделать таких ляпов…

                                                                  0
                                                                  «Адаптация» — простите, наверное, «внедрение»?
                                                                  Ну, просто английское «adoption» — действительно плохой друг переводчика.

                                                                  Насчёт «проще перевести на С++17»… Спорно. Зависит от объема проекта.
                                                                  Шаблонно (т.е. автоматизированно) это все равно не сделаешь. А выгоды какие? Только переиспользование существующего кода?
                                                                    +1

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


                                                                    Про C++17 — как минимум 3 из 4 названных основных проблем, указанных в статье, за исключением целочисленного переполнения, в современных плюсах проблемами не являются.


                                                                    Сам по себе, конечно, переход от C++98 ко всяким там умным указателям, лямбдам, итп — задача не из тривиальных. Уж тем более с учетом того, что нельзя перевести только часть проекта на те же умные указатели, да конкретного типа объектов. Либо все, либо ничего. Плюс придется еще поотдавливать всякие возможные циклические зависимости. Но по своему опыту скажу, стабильность кода, даже от простого перехода на умные указатели, поднимается в разы. Ну а более современные фишки, вроде той же move semantic, позволяют проводить оптимизации, которые раньше можно было сделать только хардкорно, вручную.

                                                                      +3
                                                                      в современных плюсах проблемами не являются

                                                                      Ну не прям так категорично. Уверен, что в условиях многопоточности, все эти проблемы все равно всплывут даже если прям вообще все на stl и умных указателях. Решаются такие вещи только кардинально — либо как раст, либо сборщиком мусора и кучей компиляторных вставок с проверками, где вообще любое действие с памятью обернуто в безопасную конструкцию. Даже целочисленное переполнение будет уже не страшно, т.к. сработает проверка выхода на за границы.
                                                                        0
                                                                        Да можно и по частям на умные указатели проект переводить. От умных указателей выиграть может даже отдельный метод.
                                                                          0
                                                                          так что бывают такие вот "англицизмы" в моей речи.

                                                                          В английском слова adapt и adopt тоже имеют совершенно разный смысл, и путать их не стоит.

                                                                            +1

                                                                            i.kym-cdn.com/photos/images/newsfeed/000/111/795/Image1.png

                                                                        –1
                                                                        адаптация новых стандартов идет медленно.

                                                                        Адаптация, простите, к чему?!
                                                                          +2
                                                                          Я понимаю, им надо пиарить rust, но все же современный C++ далеко не так плох, как его описывает автор.

                                                                          Именно настолько плох. Чего стоит только нескончаемый перечен CVE, в котором встречаются слова «buffer overflow», «double free», «use after free»,…

                                                                          Другое дело, что адаптация новых стандартов идет медленно. Но все равно, куда проще плавно перевести код с C++98 на C++17, чем на rust.

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

                                                                            Могу сказать, что разница в 50 раз на производительности, в зависимости от того как вы напишете код того стоит. Напишете 100% безопасно с «автоматикой» — будет x1, напишете грамотно с «ручным управлением» — будет x50 скорость.
                                                                            Да во втором случае придется немножко почитать логи на предмет утечек памяти в отладке и протестить корректно. Да, для этого нужна квалификация.
                                                                            Но С++ то тут причем ?!
                                                                            Нефиг браться мокрыми руками за оголенные провода под напряжением. Они от этого ржавеют…
                                                                              +4
                                                                              Напишете 100% безопасно с «автоматикой» — будет x1, напишете грамотно с «ручным управлением» — будет x50 скорость.

                                                                              Есть ссылка откуда такие числа, особенно в контексте Rust'а?

                                                                                0
                                                                                Могу сказать, что разница в 50 раз на производительности, в зависимости от того как вы напишете код того стоит.

                                                                                В 50 раз? Если не брать в расчет встраиваемые системы, то какая реальная программа для центрального процессора работает в 50 раз быстрее, чем программа на .Net/Java?


                                                                                Не синтетическая, а именно реальная.

                                                                                  0
                                                                                  Даже синтетика настолько не отличается
                                                                                    0
                                                                                    Даже синтетика настолько не отличается

                                                                                    2005/6 год. Notebook CPU Core2Duo и Ram 4 GB DDR2.
                                                                                    Алгоритм кеширования (нюансы не помню) и цель была выжать максимальную производительность.
                                                                                    С++: Замена double на double* и _smart_ptr на IFn* в сигнатурах функцияй ну и управление памятью (изменено были на ручное new/delete) при сохранении алгоритма.
                                                                                    Сам удивился результату. Сейчас, думаю, результат будет поскромнее. Надо будет проверить на досуге.
                                                                                    0
                                                                                    Простите что вклиниваюсь, но не могу удержаться, и мой ответ — сравнение C# со сборкой мусора и кучей аллокаций vs С# реализация той же системы с оптимизацией памяти на выделенные буферы и их переиспользование и ручное освобождение с пул аллокаторами и явными зонами ответственности… так вот как минимум на сборку мусора по скорости дало раза в 5-10 ускорения (зависит от условий теста) — на том же самом языке, кроме прочего потребление памяти снизилось, и это было и на ПК и в WebGL — основа на unity. Я могу предположить что при нормальной оптимизации скорость по C++ должна быть еще чуток выше. До 50 раз — может быть а может и нет.
                                                                                      0
                                                                                      Вопрос то сложный. Насколько много мусорит приложение. Ведь если чисто вычисления, то оптимизируй сколько влезет, но не в сборщике дело. Unity, игровая логика — тут как раз на сборщик весь упор может быть, если каждый кадр тонны объектов пересоздавать. Собственно, даже без сборщика кучу трюков в плюсах используют по памяти.
                                                                                        0
                                                                                        Уточняю — в нашем проекте не игрорвая логика каждый кадр, а один очень толстый pipeline по генерации кое-чего в рунтайме, и испольщзующий кучу алгоритмов и данных, как исходных так и промежуточных, в таком случае — применять собственные менеджеры памяти — очень помогает как ускорить так и снизить потребление памяти. Но задача не из частых.
                                                                                        Просто как пример привел.

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

                                                                                        Что до юнити — да можно переиспользовать игровые объекты классически — чтоб не создавать каждый раз новый, но речь не только об этом.

                                                                                        Вот например есть либа для триангуляции, вот она при написании на Си имела производительность Х, потом при переписывании на С++ стала Y, потом на C# стала в разы быстрей чем была на Си, изза аллокаций памяти неоптимальныъх в Си, а в C# сборщик памяти ускорил дело, представляете (можно было бы использовать как контр-пример что мол круто сборка мусора ускоряет). Но потом ее еще оптимизировали на пулы и она стала быстрей чем была, на всех платформах, т.е. на C# с ручным менеджментом памяти стала быстрей чем на C# со сборкой мусора, и быстрей чем на Си с ручным менеджментом.
                                                                                        Либа эта LibTessDotNet на C# и при желании нагуглите ее версии На Си и С++ и т.п.
                                                                                        А в моем проекте кроме ее я юзаю еще кучу разного.
                                                                                  +2
                                                                                  автор исследовал кодобазы возрастом 10+ лет. Rust вышел в 15-м году, после c++14. Может хватит уже сравнивать Rust 2015 с с++03?

                                                                                  Если хотя бы новый функционал не писать на С и С++

                                                                                  перепишите мне все используемые мной API с с++ на Rust и я подумаю. Только в моей конторе это тысячи человеколет кода
                                                                                    0
                                                                                    А зачем все API переписывать с C++ на Rust?
                                                                                    Если у системы достаточная степень decoupling'а, все в разделяемых библиотеках, или что лучше — коммуникация между модулями по протоколу типа REST, то все же прекрасно переписывается?
                                                                                      +1
                                                                                      а если нет? У нас например монорепа, статическая линковка и куча API на шаблонах.
                                                                                        0
                                                                                        Ну, я думаю, что основная проблема все-таки не в «монорепа» и «куча API на шаблонах» (это вообще можно трактовать совершенно по-разному), а в «статическая линковка»
                                                                                        0
                                                                                        Вот бы, скажем, intel mkl, eigen или dlib какой-нибудь через REST дёргать! Производительность будет на высоте.
                                                                                          0
                                                                                          Повторюсь — для всех популярных библиотек уже есть биндинги.
                                                                                          Intel mkl: github.com/termoshtt/rust-intel-mkl
                                                                                          Eigen: github.com/GuillaumeGomez/rust-GSL/blob/master/src/eigen.rs
                                                                                          github.com/vberger/dlib — dlib, это оно?

                                                                                          Или вы действительно все статически влинковываете в С++ коды?
                                                                                            0
                                                                                            https://github.com/GuillaumeGomez/rust-GSL/blob/master/src/eigen.rs

                                                                                            Чё-т не похоже на http://eigen.tuxfamily.org/index.php?title=Main_Page ну вот прямо совсем. Похоже на биндинги к GSL.


                                                                                            github.com/vberger/dlib — dlib, это оно?

                                                                                            Нет, не оно. Оно — это http://dlib.net/ .


                                                                                            Или вы действительно все статически влинковываете в С++ коды?

                                                                                            Увы, с темплейтами иначе никак.

                                                                                              0
                                                                                              То, что вы привели, как Eigen — реализация поиска собственных чисел из GSL.

                                                                                              Имелась в виду вот эта библиотека: eigen.tuxfamily.org/index.php?title=Main_Page, которая, как назло, линкуется статически с C++ кодом, ибо header-only на шаблонах :P

                                                                                              Вообще, прям очень любопытно было заодно увидеть биндинги для OpenCV и PCL для Rust'а, вот только это как-то очень долго делать, имхо.

                                                                                              P.S. по вашим ссылкам в части GSL все вызовы плюсовых функций помечены как unsafe. В чем в таком случае будет преимущество использования Rust, если у меня какой-нибудь суровый математический модуль с gpu-оптимизациями? Проще уж тогда к этому моему C++ модулю писать Rust биндинг. Но вызовы модуля мне придется точно так же помечать как unsafe…

                                                                                              P.P.S. Как, кстати, у Rust'а с Cuda/OpenCL?
                                                                                          +1
                                                                                          автор исследовал кодобазы возрастом 10+ лет. Rust вышел в 15-м году, после c++14. Может хватит уже сравнивать Rust 2015 с с++03?

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

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

                                                                                          перепишите мне все используемые мной API с с++ на Rust и я подумаю. Только в моей конторе это тысячи человеколет кода

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

                                                                                          Ну и да, я обычно пишу на C#, у нас обычно проект — это десятки-сотни отдельных модулей, линкуемых динамически, которые могут быть даже на разных языках, и которые спокойно можно менять/заменять по одному. Ситуация статически линкуемых шаблонов мне действительно чужда, и тут нужно сильно увеличивать стоимость внедрения. И если она превышает некоторый порог — говорить «нет, у нас плюсы. Да, это плохо, но профит от переписывания на раст никогда не окупит затрачиваемые усилия».
                                                                                            0
                                                                                            и все равно там будут ошибки этого класса

                                                                                            а можете привести пример ошибки памяти в хромиуме, в модуле, написанном на «распоследних» плюсах?

                                                                                            А статическая линковка решает очень много проблем с зависимостями и версионированием библиотек, а также с воспроизводимостью конфигурации. В расте, емнип, именно статическая сборка является вариантом по умолчанию
                                                                                      0
                                                                                      Проблема подобных ошибок — непонимание логики работы, особенно в нетипичных ситуациях. Работа в нетипичных ситуациях вообще приводила к падениям ракет, когда новая ракета падала из-за старого кода. «Ariane 5». Хотя ошибки аэропорта Хитроу куда жестче.

                                                                                      Системы нынче стали настолько сложные, что даже болванка (заготовка) игры на новомодном движке может весить 200 МБ! Проблема в том, что человечество до этого момента не сталкивалось ни с чем подобным. До этого приходилось управлять максимум небольшими командами либо огромными однотипными системами. Или вообще пускать все на самотек и придерживаться традиций. А цена ошибки не была большой, т.к. часть людей вполне официально можно было считать даже рабами, как в той же Америке до 1865г.
                                                                                      Проходит 150 лет (+3) и системы усложнились на порядки. Ладно бы просто найти решение, но что делать с Legacy/наследием? Раньше решалось проще — повоевали и все, строй заново, без Legacy.

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

                                                                                      Может, стоит подумать в направлении такого созидательства? Посмотреть, что уже существует и делать свое, развивать. Типа «общество сложных систем», который позже станет институтом/университетом. На самом деле не взлетит, т.к. нужны будут финансы. Требовать финансирования глупо — можно перейти в режим грантоедов. Поэтому нужно подумать и в сторону о пользе, которую можно получить уже сейчас, пускай и другим путем.
                                                                                        –1
                                                                                        Системы нынче стали настолько сложные, что даже болванка (заготовка) игры на новомодном движке может весить 200 МБ

                                                                                        А «Hello, World” на Go весит больше мегабайта! Сложнейший проект? Нет, просто разработчики языка не смогли в нормальную статическую линковку и пихают в исполняемый файл всю стандартную библиотеку.

                                                                                          +1

                                                                                          … и это хорошо. У этой библиотеки открытый исходный код, как и у любой библиотеки на Go. Это классно! Вливайтесь! Размер 1мб тем не менее позволяет запуститься в Docker-образе scratch, т.е. с нуля, без всего. А минимальный java-образ весит сотню мегабайт несколько я знаю.

                                                                                            +1
                                                                                            Этот неловкий момент, когда Lazarus (открытый аналог Delphi) дает exe-файл в десятки мегабайт (10-20МБ). Но там тащутся оконные библиотеки для получение Windows (или Linux) окошечка.
                                                                                            А вот консольная программа того же, да и еще с выключенным дампом откладки дает уже в районе сотни килобайт, причем часть можно сэкономить, если не использовать некоторые системные библиотеки, типа SysUtils.

                                                                                            Почему не пропагандируется Lazarus? Открытый развивающийся язык, куча библиотек. Можно писать даже драйвера. Можно даже GNU Pascal вспомнить.

                                                                                            Хотя уже существует KolibriOS, которая написана на ассемблере. Там нет упора на безопасность, но разработка на ассемблере намекает, что на ассемблере писать можно даже ОС, только не все осилят.
                                                                                              0
                                                                                              У меня Lazarus даёт 2 мегабайта для гуя. ЧЯДНТ? Включаю релиз сборку вместо дебаг?
                                                                                                +2
                                                                                                2мб это тоже очень много. как насчет сравнить с 10-50Кб для родных С-приложений
                                                                                                  0
                                                                                                  родные С-приложения с окошками? Наверняка про чисто консольные, без всяких Qt и Gtk, которые явно не 10кб займут.
                                                                                                  Если без GUI в консоли, то получаем 32КБ. Сравниваем с С-приложениями и как-то порядок особо не различается.

                                                                                                  DevCpp х64 для простенького консольного HelloWorld на C++ c iostream дает приложение 1,83Мб
                                                                                                  Lazarus 1.8.0 x64 для консольного приложения с расширенными возможностями (включен объект App) дает приложение 278 Кб
                                                                                                  FPC 3.1.1 x64: для HelloWorld с библиотеками Classes и SysUtils дает 162 Кб,
                                                                                                  без библиотек дает 32 Кб (первая библиотека дает несколько встроенных классов, вторую либу использовал только ради функции перевода из Str в Int и обратно вместо процедуры для того же самого результата).
                                                                                                    0
                                                                                                    родные С-приложения с окошками?

                                                                                                    Например на WinAPI.


                                                                                                    DevCpp х64 для простенького консольного HelloWorld на C++ c iostream дает приложение 1,83Мб

                                                                                                    Там же gcc, который тянет свой рантайм.

                                                                                                      0
                                                                                                      Например на WinAPI.

                                                                                                      и потеря кроссплатформенности.
                                                                                                      Опять же — реализовывать можно по-разному. Для Lazarus:
                                                                                                      1) не парясь что под капотом. LCL, создавая кнопочки как в Delphi. WinApi, Qt или GTK выбирается переключателем в настройках проекта. Но итоговое приложение будет в районе 2МБ.
                                                                                                      2) делая с готовыми обертками на WinAPI, но прирост все равно будет — в районе 300-600КБ, т.к. линкуются библиотеки
                                                                                                      3) найдя усеченные библиотеки отрисовки (уже не помню как называется), направлены на минимизацию итогового размера приложения. Итоговое приложение 150-400 Кб
                                                                                                      4) Писать все ручками, в том числе обертки для DLL. Можно уложиться до 150 КБ
                                                                                                      У меня все цифры примерные и иногда указаны в большую сторону. Например, думал что минимальное консольное приложение 52Кб, а оказалось — всего 32Кб, т.е. я в 1,5 раза завысил.

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

                                                                                                      Доходя до размеров, сопоставимых с размерами дискет в 1,44Мб, я перестаю задумываться о дальнейшем уменьшении размеров минимально компилируемой программы. К сожалению, у многих современных разработчиков эта планка превышает 100Мб и вовсю стремится к гигабайтным высотам.
                                                                                                        0
                                                                                                        Я не улавливаю твою мысль. В целом, Лазарус не такое уж и масштабное зло, а если сравнивать с текущими тенденциями — то даже весьма на передовой.

                                                                                                        Но до идеала ему как до Луны (особенно в качестве, ну и размере генерируемого кода). Потому твое бахвальство неуместно.
                                                                                                    0
                                                                                                    Согласен что много, в дельфях это было меньше, и я знаю что и там много мусора лишнего.
                                                                                                    При сравнимом удобстве написания гуя Qt и Wx дают по ~50/~25 мегабайт (емнип), они включают фреймворк. На Qt ещё и станцевать надо для получения дистрибутива (в бесплатной версии).

                                                                                                    На чистом WinAPI не пишу, зачем это в 2к18? Если со скуки, то можно и на FPC написать с вызовами WinAPI, а лучше — на ассемблере.

                                                                                                    Или вы знаете некий секретный вариант с Си?
                                                                                                      0
                                                                                                      Какие там секреты. Чтобы программа быстро запускалась и была компактной, достаточно брать встроенный в систему фреймворк, например MFC или .NET.
                                                                                                    0
                                                                                                    Дебаг сборка = включение дампа (для) отладки.
                                                                                                    В дебаг сборке еще можно поставить флажок «файл отладки отдельно» и тогда отладочный файл генерируется, но не включается в готовый exe-файл.
                                                                                                    Все равно размер будет гулять ± несколько процентов из-за версии Lazarus и ОС, но это уже не так заметно.
                                                                                                    0

                                                                                                    Fortran тоже в некоторых применениях просто идеален, оптимизированный и быстрый, но время языка прошло, ровно как и время pascal. Этим языкам даже поддержка корпорации не поможет. Я дорабатывал проект на Delphi, и объективно и непредвзято могу сказать, что он устарел. Я пару раз уже писал об этом на Хабре. А если субъективно, то меня ничто не заставит на нем больше работать, даже, скажем, оффер х2 от текущей денежной компенсации.

                                                                                                      –2
                                                                                                      Я пишу для души на Pascal, типа хобби и ностальгии. Или надо что-то быстро простенькое и одноразовое создать — тут Lazarus/FreePascal у меня делит место с Python. Или для различных извращений, вместо Brainfuck.
                                                                                                      Вообще нужно выбирать инструмент исходя из задач. У меня:
                                                                                                      — 1С для бухгалтерии
                                                                                                      — Python для веб-сервера (ранее использовал PHP)
                                                                                                      — C# (Unity) для разработок игр/приложений на телефон
                                                                                                      — Lua для скриптов (тут еще Python и Bash, скриптов много)
                                                                                                      — Visual Basic for Application для Microsoft Word/Excel/Access
                                                                                                      — SQL для баз данных
                                                                                                      — JS для клиентских браузерных скриптов
                                                                                                      и прочее.
                                                                                                      И тут я солидарен с автором статьи, что от С/С++ стоит отказываться во многих направлениях.
                                                                                                      А если субъективно, то меня ничто не заставит на С/С++ больше работать, ибо полиформизм инструкций в зависимости от контекста как у тех же звездочек — очень сильно бесит, а про код в стиле регулярок я даже не расписываю. Про указатели упомянуто у автора статьи. И я не собираюсь пихать С/С++ в бухгалтерию, веб-разработку, скрипты, базы данных и т.д.

                                                                                                      про время принятия решения
                                                                                                      Надо учитывать время принятия решения о разработке. Если это были в первом десятке лет этого века (нулевые, до 2010), то ни о каком Rust и Swift даже близко не могло быть и речи, на тот момент эти два языка (а также некоторые другие) были в крайне ужасном состоянии. И человек, который собирался тогда писать на этих языках серьезные приложения с необходимостью получить минимальным результатом через пару лет, но не участвовал в разработке этих языков — явно псих, которого нельзя допускать к программированию. Основание? Первое десятилетие закончилось в 2010 году, а первые стабильные версии этих языков выйдут только через 4-5 лет. Соответственно, разработка того приложения могло зависнуть на 4-15 лет! Либо разработчик хитросделанный и хотел эти 4-15 лет получать з/п просто за ожидание, пока выйдет «достойный язык».
                                                                                                      Я уже не буду рассказывать про рекомендации в сторону NASA выбрать Rust/Swift для разработки, если решение принималось в 90-е! Там вообще клиника.
                                                                                                        +2
                                                                                                        Ну не знаю, я люблю на C++ писать именно для души. Можно рисовать такие штуки, за которые rust даст по рукам.

                                                                                                        Например, я хочу организовать иерархические слои данных. Выделяю мегабайт памяти и располагаю там свои любые данные. Выделяю следующий мегабайт и располагаю там новый слой данных, со ссылками на предыдущий слой. И так далее. Следующие слои ссылаются на предыдущие, но не наоборот. Можно удалить N последних слоёв и вся структура останется ссылочно корректной. На расте так не сделаешь.
                                                                                                          0
                                                                                                          Для души можно писать на любом языке и под любую архитектуру, даже несуществующую. Сложнее, когда нужно в продакшен, тут уже выбор иногда между:
                                                                                                          1_) текущим знанием
                                                                                                          2_) легкостью обучения для опытных и для новичков, кривые обучения
                                                                                                          3_) з/п специалистов и предложения на биржах труда — влияет на стоимость поддержки
                                                                                                          4_) уровень и планируемая длительность поддержки
                                                                                                          5) доступность исходного кода
                                                                                                          6) лицензии
                                                                                                          7) возможности языка
                                                                                                          8_) доступные компоненты/библиотеки
                                                                                                          9) поддерживаемые целевые ОС и архитектуры
                                                                                                          10_) количество изменений в новых версиях языка и влияние на предыдущие
                                                                                                          11_) предсказуемость языка, т.е. предсказуемость поведение готовой программы
                                                                                                          12) защита от ошибок на уровне языка
                                                                                                          13) возможности языка по отстрелу ног и уничтожению всей вселенной
                                                                                                          14_) развитость IDE
                                                                                                          15_) доступность отладчиков (стандартных для языка, а не сторонних)
                                                                                                          16) читабельность
                                                                                                          17_) легкость установки от «запустил exe, установил и можно кодить» до «скачай, скомпилируй, исправь ошибки компиляции, скомпилируй более новую версию, настрой конфигурацию, докупи оборудование...»
                                                                                                          и т.д.
                                                                                                          Например, си допускает в конструкции if присвоение вместо сравнения, а это — частая ошибка, которая отслеживается только некоторыми IDE, в блокнотах можно и пропустить. Про «докупить оборудование» намекнула Unity, которая для создания приложения для Android требует самую новую видеокарту (DirectX 9 уже не устраивает) и х64 систему.

                                                                                                          И все языки хоть где-то, но накосячат, т.е. не являются идеальными, поэтому п.1-4, 8, 10, 11, 14, 15, 17 вполне могут быть провалены, особенно новичками п.2,8,14,17
                                                                                                    –2
                                                                                                    Это я к тому, что скорее всего в той заготовке игры реальной логики совсем не на 200 Мб: просто никто не парился выкинуть лишнее. Как и в случае с Go: супер-инженеры Google поленились/не смогли в линковку, которая со времён C ещё существует.
                                                                                                      +3
                                                                                                      А зачем, если это замедлит компиляцию, а значит и цикл разработки (написал код — запустил — проверил — внёс изменения). Кроме того, большой исполняемый файл не является проблемой для современных ОС, т.к. в память загружаются только страницы, по которым действительно прошло исполнение кода.
                                                                                                        0
                                                                                                        Большой файл-долгая линковка, тоже удлиняет цикл разработки.

                                                                                                        Кроме того, пример Дельфи, Явы, да и впрочем любого приложения со сплеш-скрином «гружусь» показывает, что проблема загрузки никуда не делась.

                                                                                                        Много сейчас программ с мгновенным временем запуска <200мс?
                                                                                                          +3
                                                                                                          Ява так долго грузиться может именно из-за динамической линковки всего и вся. Пока в память загрузятся десятки и сотник jar файлов, пройдет целая вечность. А после этого их еще надо через JIT пропустить. Один большой нативный бинарник же ерунда — маппинг в память и готово.
                                                                                                            0
                                                                                                            Большой файл-долгая линковка, тоже удлиняет цикл разработки.
                                                                                                            Нет, потому что для си-шной линковки нужно прочитать большой блоб .lib-файл, нарезать его на кусочки, сшить эти кусочки заново в маленький файл, поправив ссылки (не говоря об обязательной для такого действия оптимизации «link-time code generation», когда после сшивания в другом порядке неплохо бы заново код перегенерить). А для го-шной линковки один большой блоб, уже хорошо оптимизированный, сшить с кодом программы и поправить ссылки только в программе на блоб.
                                                                                                              0
                                                                                                              щас. го использует gnu-toolchain, а там чудес не завезли
                                                                                                                0
                                                                                                                Тогда почему линкуется неиспольщуемый код?
                                                                                                                  0
                                                                                                                  Не использует, у него свой компилятор и линкер. Тулчейн нужен только для cgo, что совершенно отдельная хрень сбоку.
                                                                                                                0
                                                                                                                у программ длительный запуск может быть вызван следующими причинами:
                                                                                                                1) нужно кучу страниц загрузить в оперативу. Т.е. пока не загрузятся картиночки для отрисовки кастомной кнопочки — приложение будет грузиться.
                                                                                                                2) инициализация переменных. Причем всех и сразу, даже в принципе неиспользуемых
                                                                                                                3) различные проверки. Вышла новая версия? У пользователя активирована лицензия?
                                                                                                                4) Дергать реестр. Либо INI-файлы. Хорошо, если там десяток параметров
                                                                                                                5) п.4 расширенный — подгрузить последнюю пользовательскую сессию
                                                                                                                6) проверить совместимость системы (встречались и такие программы)

                                                                                                                Это некоторые причины. Но программисты не стоят на месте, поэтому ожидайте (а где-то уже появилось):
                                                                                                                — телеметрия
                                                                                                                — интеграция с другими приложения, которые надо тоже тут же запустить
                                                                                                                — 100500 сервисов/микросервисов (у видеокарты NVidia драйвер притащил около десятка программ, в том числе «стримминг», «3д навороты, недоступные на обычном мониторе, но всегда автивные» и прочее.)
                                                                                                                — синхронизация с облаком. Если инет затупит, то и приложения тоже замедлится
                                                                                                                — высококачественные текстуры 4к для отрисовки курсора мышки
                                                                                                                и т.д.
                                                                                                                  0
                                                                                                                  а не надо додумывать и теоретизировать

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

                                                                                                                там же и время сборки можно посмотреть.
                                                                                                                вроде на хабре было
                                                                                                                  0
                                                                                                                  Время сборки занимает считанные секунды.
                                                                                                                  –1
                                                                                                                  Небольшое — это в 200 раз для «Hello, world»? Не нужны эти инженеры с таким программированием.
                                                                                                                    +1
                                                                                                                    А часто ли вы запускаете «Hello, world» на проде? Для более крупных программ относительное увеличение размеров будет куда меньше.
                                                                                                                      0

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

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

                                                                                                                          Мне трудно представить, какие преимущества даёт подход, при котором в бинарник линкуется вся стандартная библиотека когда вам нужна только функция print. В Java, кстати, с этим уже борятся, а гоферы, оказывается, находят тут какие-то преимущества.

                                                                                                                            +1
                                                                                                                            Мне трудно представить, какие преимущества
                                                                                                                            А какие недостатки? Но не абстрактные «большой файл получается», а реальные, из-за которых бизнес несёт убытки.
                                                                                                          +14
                                                                                                          в то время как проверенные альтернативы, такие как Rust, Swift,

                                                                                                          Это шутка такая?

                                                                                                            +1
                                                                                                            2 июня 2014 года на конференции WWDC Swift был официально представлен (википедия)

                                                                                                            После нескольких лет активной разработки первая стабильная версия (1.0) вышла 15 мая 2015 года (википедия)

                                                                                                            Проверенные альтернативы — это «мы целый месяц тестили, все ок». А также намек на то, что до 2014 года у пользователей не должно быть этих самых браузеров, потому как «проверенный временем» язык программирования еще даже не родился
                                                                                                            +20

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

                                                                                                              0
                                                                                                              Да не.
                                                                                                              0
                                                                                                              переходим на китайский, там соцкап уже готов
                                                                                                                +1

                                                                                                                французскому же.

                                                                                                                  0
                                                                                                                  Судя по иронии, вы не согласны с поднятым вопросом?
                                                                                                                  +1
                                                                                                                  «Проверенные альтернативы вроде Rust» — ну это вообще смех. При всем уважении к хайпу вокруг Rust'а, у него еще молоко на губах не обсохло, а на C++ люди писали задолго до рождения Алекса Гейнора. И если уж вообще по-честному, большая часть «memory safety» Rust'a спокойно реализуется в C++, а к моменту его рождения уже подъезжала в стандарт.
                                                                                                                    +7
                                                                                                                    Любую фичу любого языка можно добавить в любой другой язык, было бы желание. Только вот их нет и не видно. Исправить С++ уже невозможно. Во-первых, никто в него не добавит ничего подобного расту, потому что обратная совместимость. Во-вторых, никуда не исчезнут все небезопасные конструкции из языка, потому что, опять же, обратная совместимость.

                                                                                                                    А Rust действительно проверен. Он безопасен по-определению, т.к. все перечисленные проблемы в нем конкретно решены в самом языке. Не имеет никакого значения, сколько он пробыл на рынке.
                                                                                                                      0
                                                                                                                      А Rust действительно проверен. Он безопасен по-определению, т.к. все перечисленные проблемы в нем конкретно решены в самом языке.

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

                                                                                                                      К примеру, если (предположим) писать веб-сайты на Rust, он никак не спасёт ни от SQL injection, ни от кучи других проблем имеющих отношение к Web Application Security, равно как и вообще любых проблем которые выходят за рамки безопасных указателей и безопасной работы с памятью.

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

                                                                                                                        +2
                                                                                                                        не решает более серьезные проблемы — валидации [внешних] данных
                                                                                                                        Но ведь он навязывает создание типов и трейтов на каждую мелочь. Чужие трейты нельзя реализовать для чужих типов, таким образом, если хотите пользоваться чужим кодом (я имею ввиду, не данные, а зависимости), необходимо создавать свои типы, а это уже намекает на валидацию, хотя и не обязывает, это да.
                                                                                                                        посчитайте долю уязвимостей связанных с неправильной работы с памятью, и долю всех остальных
                                                                                                                        А вот Гейнор насчитал более половины.
                                                                                                                          +9
                                                                                                                          Да сколько можно. Автор говорит о конкретных уязвимостях связанных с памятью. При чем здесь SQL инъекции? Да, давайте все бросим, плюнем на все предосторожности, ведь если мы не можем предотвратить вообще все уязвимости, то надо не пытаться это сделать даже для некоторых особо опасных и страшных. Или все, или ничего. Это глупый подход, надеюсь это не надо объяснять. Автор агитирует к отказу от этих языков, чтобы исключить отдельный класс очень опасных уязвимостей. Да, есть другие проблемы, только вот данные конкретные вызваны именно языками, их очень сложно найти, очень легко допустить, и это надо как-то решать. SQL инъекции более очевидны, но тоже решаются, только другими методами — более качественными библиотеками. И аргумент будет тот же самый — долой устаревшие способы работы с SQL, биндинг параметров в массы. Вот такой подход и нужен — каждой проблеме свое решение. Небезопасная работа с памятью должна уйти в прошлое и остаться там, где это действительно нужно. Там, где используется С++, это не нужно от слова совсем. Даже ядро ОС и то спокойно пишется на полностью безопасном языке, т.к. мизерное количество кода напрямую работает с памятью. Если уж на Go смогли, то и на Rust тем более смогут, заодно еще не в ущерб скорости.
                                                                                                                            –1
                                                                                                                            Даже ядро ОС и то спокойно пишется на полностью безопасном языке, т.к. мизерное количество кода напрямую работает с памятью.

                                                                                                                            Рискну предположить, что в этом случае ядро будет очень сильно тормозить. Как пример — безопасный язык просто обязан проверять соответствие индекса размерам массива, это несколько лишних операций, больно бьет по кэшу и т.п. — а в ядре ОС таких операций немало, причём в довольно критичных местах.

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

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

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

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

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

                                                                                                                            С другой стороны, возьмём софт который работает в борткомпах каждого современного автомобиля, самолёта etc — часто там обнаруживают уязвимости? А удаленные? Да хотя бы просто баги, такие, которые не позволяют нормально пользоваться техникой — часто? А ведь он чуть меньше чем полностью писан на C, а то и ассемблере. Автомобили сами не тормозят и не ускоряются (только давайте не будем про Tesla & co), не мигают фарами, самолёты не меняют высоту, и т.п. Отдельные фейлы случаются, но это исключительно редкий случай. Дело же просто в том, что как раз баги и уязвимости в таком софте приводят к реальной ответственности — поэтому их там почти нет, по крайней мере не такие какие были бы заметны обычным пользователям.

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

                                                                                                                              Не знаю как насчёт автомобилей, но для самолётов пишут чаще на Ada или SCADE.

                                                                                                                                +5
                                                                                                                                Если законодательно ввести штраф за каждую обнаруженную уязвимость, т.е. ответственность разработчика за качество кода, вот тогда проблемы начнут решаться

                                                                                                                                … тогда проблемы начнут решаться при помощи счёт и абаков. Потому что софт будет стоить не просто не дорого, а очень дорого. И идти только в виде узкоспециализированной железки. Вот вам отдельный опечатанный ноутбук с вордом, вот вам отдельный опечатанный ноутбук с экселем, ну и да — вот вам dvd плеер для дисков с порнухой.
                                                                                                                                  0
                                                                                                                                  Лучше опечатанный ноутбук с вордом, но при этом уверенность в том что никакой левый файл, открытый в этом ворде, не сможет натворить дел, а также уверенность в том что он не угробит работу нескольких дней при попытке сохранения (такое тоже бывало, очень много лет назад).

                                                                                                                                  Да, написание качественного софта стоит денег и времени, но вы посчитайте все убытки связанные с уязвимостями и критичными багами — во многих случаях они явно превышают затраты на разработчиков, которые потребовались бы для написания софта без таких багов, которые приводят к этим самым убыткам.
                                                                                                                                    0
                                                                                                                                    Лучше опечатанный ноутбук с вордом, но при этом уверенность в том что никакой левый файл, открытый в этом ворде, не сможет натворить дел
                                                                                                                                    В чём проблема? Заказывайте себе такой ноутбук с вордом за пару миллиардов долларов, заключайте договор со всеми штрафами и санкциями за ошибки. Но зачем остальным это навязывать?
                                                                                                                                      0
                                                                                                                                      Ответ на вопрос «зачем» очень прост — если кто-то берет деньги за свой продукт, он обязан нести за это ответственность, или, как минимум, заранее огласить весь список возможных проблем.

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

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

                                                                                                                                            0
                                                                                                                                            В этом-то и проблема. В случае осязаемых продуктов (техника, лекарства etc) есть и другие обязанности, которые невозможно исключить никаким договором (гарантия, например, или ответственность за причинение вреда).
                                                                                                                                              0
                                                                                                                                              А вот тут я с вами несогласен. То есть, да, это проблема, но в случае осязаемых продуктов.

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

                                                                                                                                        Например, тогда тебя не возьмут на работу или вообще не допустят к клавиатуре, если ты не сдал экзамен и не имеешь сертификата «Уверенный пользователь Word со знанием VBA»…

                                                                                                                                        Это еще не говоря даже про программирование, где программу придется сдавать госкомиссии. За свой счет.

                                                                                                                                        Точно этого хочешь?
                                                                                                                                          0
                                                                                                                                          В строительстве у нас уже не обязательно, это ведь не такое серьёзное дело как предоставление телематических услуг, например.
                                                                                                                                      +3
                                                                                                                                      > Если законодательно ввести штраф за каждую обнаруженную уязвимость
                                                                                                                                      то все коммиты в компании начнет совершать «программист» нанятый из дворников, а все люди пишущие код вдруг станут консультантами.
                                                                                                                                        0
                                                                                                                                        Неважно кто будет совершать коммиты — штраф получит компания, и пусть сама разбирается со своими сотрудниками. Несколько крупных штрафов — и политика найма дворников сойдёт на нет. Или хитрая компания сойдёт на нет.

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

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

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

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

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

                                                                                                                                                Когда вы покупаете автомобиль или дом, вы заключаете специальный договор? Сомневаюсь. Но производитель всё равно несет ответственность если откажут тормоза, или если дом рухнет потому что плохо построен или спроектирован.
                                                                                                                                                  0
                                                                                                                                                  В принципе, если это убьёт платную разработку ПО, я был бы не против (за бесплатное ПО вроде как по-вашему не надо нести ответственность). Я вообще не люблю всю эту копирастию. Заодно можно избавиться от исключительных прав на аудио-визуальную продукцию и литературу, а то ждать почти 100 лет до истечения прав слишком долго.
                                                                                                                                                    0
                                                                                                                                                    Просто вся разработка будет в виде «задонатьте мне 200.000 и я, может быть, напишу вам ещё одну фичу в своё бесплатное ПО».
                                                                                                                                                      0
                                                                                                                                                      Посмотрите на sqlite — он вообще public domain, фичи регулярно добавляются, баги фиксятся, да и код вылизан покруче чем у большинства.

                                                                                                                                                      Да, сейчас у него много донатов, но вначале было не так — тем не менее на качество это не влияло.

                                                                                                                                                      Можно и ещё найти примеры, но их можно на пальцах пересчитать, хотя сам факт их наличия (при отсутствии у авторов кучи денег) говорит о том что для качественного кода совсем не нужны миллиарды и сотни лет разработки.
                                                                                                                                                        0
                                                                                                                                                        Не понимаю, к чему вы клоните. Есть крутые разработчики, типа вышеупонянутых. А есть криворукие, которые тоже пишут бесплатный slack, whats up или того хуже, facebook.

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

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

                                                                                                                                                          А для хобби, за бесплатно — пусть себе пишут без лицензии, так уж и быть :)
                                                                                                                                                            0
                                                                                                                                                            Лицензии что обозначают? Что кодеры вызубрили теоретический материал и кое-как сдали. Но это совершенно не значит, что они будут писать хороший код. Можно и писателям-поэтам-журналистам тоже ввести проф. экзамен, но улучшится ли качество литературы от этого?

                                                                                                                                                            Кроме того, вы хотите со всех сторон индустрию зажать: компании штрафовать за недоработки их продуктов, программистов экзаменовать, или уже от первой идеи отказались?
                                                                                                                                                              0
                                                                                                                                                              Лицензии можно выдавать компаниям, ЧП и фрилансерам.

                                                                                                                                                              В Германии есть хороший пример в этом плане (в других областях), называется Meisterbrief. Это сертификат, выдаваемый профессионалу (с необходимостью доказать свои знания в теории и практики), и дающий ему право на осуществление соответствующей деятельности и открытие фирмы по профилю. Он может нанять «подмастерьев» и вообще кого угодно для выполнения работы, с образованием или без, но отвечать за работу будет лично он. Для ряда профессий наличие этого сертификата является обязательным условием для оказания услуг на коммерческой основе (и даже «просто так» — для врачей и юристов, например).

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

                                                                                                                                                              А теперь представьте, что система таки реализована. Вы — владелец лицензии, и вам нужно нанять программистов. Зная, что за их ошибки с вас могут снять либо голову либо много денег, вы примете все меры чтобы они были очень крутыми, либо сами будете перепроверять их работу по десять раз, пока не убедитесь что они не накосячили. Тяжко? Тяжко, зато на выходе будет качественный продукт. Ну или придётся заняться чем-то ещё, чтобы с голоду не умереть.

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

                                                                                                                                                                Нужна бухгалтерия? Вот вам услуга — бухгалтер-фрилансер, который будет использовать наш софт и наш хард и никогда на нас не подаст в суд за ошибки в этом софте, потому что он оформлен как соавтор программы. Наёмный бухгалтер будет отвечать за итоговый результат работы (вы ведь ради этого всё затевали), но точно так же и сейчас бухгалтер отвечает за результаты бух. программы, а программисты снова типа не при чём.
                                                                                                                                                                  0
                                                                                                                                                                  С бухгалтерией и похожими вещами я ещё могу представить такую схему, но как быть с ОС, смартфонами, играми, текстовыми редакторами, СУБД, браузерами и IoT? Хотя в случае с IoT это уже потихоньку начали регулировать, по крайней мере в ЕС (и это хорошо).

                                                                                                                                                                  Фрилансер-оператор ОС, выполняющий распоряжения пользователя для работы с ней, при этом не могущий подать в суд на разработчика ОС, поскольку является её соавтором — вы примерно так себе это представляете?
                                                                                                                                                                    0
                                                                                                                                                                    С бухгалтерией и похожими вещами я ещё могу представить такую схему, но как быть с ОС, смартфонами, играми, текстовыми редакторами, СУБД, броузерами и IoT?
                                                                                                                                                                    Всё очень просто. Весь мир останется на продуктах больших корпораций, а страна, которая дошла до такого маразма, останется отрезанной от мирового ИТ. В белую будет вынуждена использовать открытое ПО (от ОС до браузеров и офисов) — и тут некому будет предъявить за косяки, т.е. ваша цель не достигнута, а в серую продукты корпораций, естественно тоже без права предъявить претензии.
                                                                                                                                                                      0
                                                                                                                                                                      Это для программ общего назначения, которые можно взять открытые или спиратить. А если специализированный софт, заточенный под заказчика — то через посредников-операторов.
                                                                                                                                                                      0
                                                                                                                                                                      Есть ещё вариант, наплевать на законы, и работать в серую по старой схеме. То есть, платить умеренные деньги разработчикам (проводить по любой статье расходов, хоть как менеджерам по продажам), а они пилят софт, предприятие использует софт без претензий.

                                                                                                                                                                      Либо как вариант контора разрабатывает бесплатный софт (но не открытый), предприятие является безвозмездным спонсо