LINUX.ORG.RU

История изменений

Исправление kirk_johnson, (текущая версия) :

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

Питон относительно C тормозит так, что мама не горюй. А Rust – нет.

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

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

а почему тесты нужны, если компилятор дает все интересующие нас гарантии?

Логику работы программы компилятор за тебя не проверит. Interoperability с библиотеками и другим софтом тоже не проверит. Перформанс не проверит.

потому что из низкоуровневых конструкций ЯП мы создаем высокоуровневые конструкции, заточенные на специфику задачи. другими словами, конструируем некий DSL, спецификация которого содержит присущие ему граничные условия, defined и undefined behavior. и никто пока еще не родил методологию программирования, которая избавляла бы от необходимости проверки граничных условий и поведения. другое дело, что наличие твердых гарантий на уровне ЯП, механизмов типа GC и прочая и прочая, снижает издержки, уменьшает time to market, etc. но вот насчет того, что кто-то-там отлил таки серебряную пулю есть обоснованные сомнения.

Причем тут серебряная пуля? Речь о том, что UB в C не является технически обоснованным решением (e.g. без этого просто невозможно писать быстрый код), а является наследием (что показывает Rust, где писать быстрый код без UB вполне себе можно).

Исправление kirk_johnson, :

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

Питон относительно C тормозит так, что мама не горюй. А Rust – нет.

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

Пока что и обычные дрочерские бенчмарки, и реальный софт показывают либо паритет между Rust и C, либо незначительный выигрыш то в одну, то в другую сторону. А это значит, что в общем случае можно без UB и пердолинга писать на Rust то, что раньше писали на C. А это, в свою очередь, означает, что UB это не какой-то краеугольный камень, без которого все тормозит и не работает, а просто пережит прошлого.

а почему тесты нужны, если компилятор дает все интересующие нас гарантии?

Логику работы программы компилятор за тебя не проверит. Interoperability с библиотеками и другим софтом тоже не проверит. Перформанс не проверит.

потому что из низкоуровневых конструкций ЯП мы создаем высокоуровневые конструкции, заточенные на специфику задачи. другими словами, конструируем некий DSL, спецификация которого содержит присущие ему граничные условия, defined и undefined behavior. и никто пока еще не родил методологию программирования, которая избавляла бы от необходимости проверки граничных условий и поведения. другое дело, что наличие твердых гарантий на уровне ЯП, механизмов типа GC и прочая и прочая, снижает издержки, уменьшает time to market, etc. но вот насчет того, что кто-то-там отлил таки серебряную пулю есть обоснованные сомнения.

Причем тут серебряная пуля? Речь о том, что UB в C не является технически обоснованным решением (e.g. без этого просто невозможно писать быстрый код), а является наследием (что показывает Rust, где писать быстрый код без UB вполне себе можно).

Исходная версия kirk_johnson, :

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

Питон относительно C тормозит так, что мама не горюй. А Rust – нет.

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

Пока что и обычные дрочерские бенчмарки, и реальный софт показывают либо паритет между Rust и C, либо незначительный выигрыш то в одну, то в другую сторону. А это значит, что в общем случае можно без UB и пердолинга писать на Rust то, что раньше писали на C. А это, в свою очередь, означает, что UB это какой-то краеугольный камень, без которого все тормозит и не работает, а просто пережит прошлого.

а почему тесты нужны, если компилятор дает все интересующие нас гарантии?

Логику работы программы компилятор за тебя не проверит. Interoperability с библиотеками и другим софтом тоже не проверит. Перформанс не проверит.

потому что из низкоуровневых конструкций ЯП мы создаем высокоуровневые конструкции, заточенные на специфику задачи. другими словами, конструируем некий DSL, спецификация которого содержит присущие ему граничные условия, defined и undefined behavior. и никто пока еще не родил методологию программирования, которая избавляла бы от необходимости проверки граничных условий и поведения. другое дело, что наличие твердых гарантий на уровне ЯП, механизмов типа GC и прочая и прочая, снижает издержки, уменьшает time to market, etc. но вот насчет того, что кто-то-там отлил таки серебряную пулю есть обоснованные сомнения.

Причем тут серебряная пуля? Речь о том, что UB в C не является технически обоснованным решением (e.g. без этого просто невозможно писать быстрый код), а является наследием (что показывает Rust, где писать быстрый код без UB вполне себе можно).