Vim или Emacs? А LISP в 2021?

Поьзователи этого форума состоят на 90% из Windows потребителей.

И что ты хочешь сказать? Где сейчас твой SUN? Смотри на раскладку.
Так что, жрать теперь для машинки? QWERTY?

Функциональные клавиши слева не только у сана

https://www.modelfkeyboards.com/wp-content/uploads/2016/10/DSC_5710.jpg

https://www.twindata.com/images/pc122-5250-2500px.jpg

https://webwit.nl/input/ibm_japan/4773313/2.jpg

https://static.onlinetrade.ru/img/items/b/klaviatura_roccat_ryos_mk_pro_mx_blue_roc_12_861_be__1.jpg

Вот мне нравятся такие парни. Возьмут IBM клавиатуру, CGA монитор и дискеты, потом расскажут, почему это надо есть.

А ничего, что всё можно поменять? Или ты всегда ешь default?

Если будем в историю смотреть - https://upload.wikimedia.org/wikipedia/commons/thumb/4/47/Space-cadet.jpg/1920px-Space-cadet.jpg Это если мне память не изменяет, Ричард колбасил именно на этом.

Мы же сейчас колбасим на таком: https://www.youtube.com/watch?v=Y9-WdsX-xAA

Я лично не люблю сплит по полной, мне больше нравится такой фактор: https://atreus.technomancy.us/ или http://troyfletcher.net/keyboard_sales.html

Мало того, если посмотреть мои темы, то я задумался о слоях на любых клавиатурах, потратил время и создал на основе xkb 2 своих, уникальных слоя, чтобы не снимать руки с клавиатуры, выставить как МНЕ удобно модификаторы и так далее. И мои настройки работают на любых клавиатурах. Потому, что я провожу очень много времени за компьютером. Очень.

Теперь дальше. Есть 2 подхода - модификаторы и режимы. Других вариантов нет.

Мне удобнее модификаторы, так как ты совсем не отвлекаешься на режимы, скорость нажатия (Vim меня бесит тем, что не всегда отрабатывает аккорды). Плюс мы и так постоянно пользуемся модификаторами - Shift, Русский etc.

Теперь ещё дальше (и глубже). Если ты начинаешь работать, то понимаешь, что default во многом неудобен. И это везде. Он был удобен тогда, когда ты делил рабочее место. Раньше за вычислительно техникой очередь стояла, всё время было под запись. Теперь это личное, индивидуальное. Возникает только один момент - работа на удалённой машине, где конкретно начинаешь подсасывать, если накрутил (а ты их накрутил) свои уникальные настройки сочетаний.

Здесь у меня снова выигрывает Emacs, когда привыкаешь. Есть мимикрия у редактора Joe - jmacs. Подсветка, 24bit color, никаких зависимостей, миниатюрный, написан на Си, очень быстр, поддерживает файл настроек.

С Vim беда. Например, я переопределил «:» на «;», чтобы нажимать без модификатора, мне так удобнее. Всё, привыкаешь к хорошему мгновенно, а удалённо вызывает дискомфорт. Получается, надо заливать конфиг. Лишние телодвижения.

Мы же сейчас колбасим на таком: https://www.youtube.com/watch?v=Y9-WdsX-xAA

Жесть какая. Я так и не научился слепому вводу, а тут такое.

Я научился. Это того стоит. И раскладку выбрал под себя.

COLEMAK, DVORAK, DVP, WORKMAN… Какие хочешь.

Если с Vim - рекомендую DVORAK. Не знаю на счёт скорости, а вот удобство!..

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

Qwerty is the most common used keyboard layout, created in 1873. The name comes from reading the first six keys from top letter row of the keyboard.

Dvorak was created in 1930 and patented in 1936 by Dr. August Dvorak. It proponents claim this layout uses less finger motion, reduces errors and increases typing rate compared to Qwerty. 31 characters are different from Qwerty.

Colemak - (2006) layout is designed to be a practical alternative to the Qwerty and Dvorak keyboard layouts, offering a more incremental change for users already accustomed to the standard layout.

Workman - (2010) layout reduced lateral movement of the fingers and wrists, more balanced left and right hand usage. 21 characters are different from Qwerty.

Ничего не превозносится, просто VSCode и PhpStorm объективно лучше и быстрее.

Ты не понимаешь, о чем ведешь разговор – поищи в интернете, что такое IDE и чем они отличаются от текстовых редакторов.

Или по твоему в Emacs есть Ctrl+C, Ctrl+V, Ctrl+N (хотя бы настройкой)

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

нормальный современный язык как JavaScript

Неплохо шутишь, я бы даже подумал, что это жирный наброс, но на всякий случай напомню: текстовому редактору (и даже IDE) не нужны никакие языки и их средства компиляции/исполнения – только парсеры исходных/заголовочных файлов/макросов, чтобы правильно описать, отформатировать и отобразить код в области редактирования. Для емакса, как и других редакторов, есть клиенты LSP и режимы отображения JS/TS/RJSX и т.д. – остальное зависит от локально установленных инструментов, версий node/пакетов в проекте и т.д. По сути любой модульный редактор проигрывает IDE в среднем лишь в наличии/полноте существующих конфигураций для разных операций над проектом – отладки, сборки, профилирования… Их можно и нужно при возможности настраивать для работы извне IDE, чтобы 2 секунды, потраченные на конфигурацию для тебя, не превращались в ад парсинга проектного файла для всех остальных.

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

Поменять можно всё.

Дальше ты пишешь, мягко говоря, хрень. MOPKOBKA писал о том, чо в «нормальных» редакторах используется не vimscript/elisp, а ts, как язык дополнений.

В emacs всё сложнее - это среда выполнения lisp кода, к которой прикручен и редактор.

Я ещё новичок, могу ошибаться ;)

https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool

Ну и где она? Где поколения корпоративных планировщиков, выстроенных на похожих с DART революционных принципах? Я уже полчаса листаю макулатуру по теме DART, и там сплошная пафосная вода про «могучий ИИ», «агрессивно эксплуатировала информационные технологии, такие как пользовательский интерфейс, РСУБД, и сеть», в то том числе тридцать повторений одной и той же фразы про «отбила все деньги за 30 лет разработки»:

https://www.researchgate.net/publication/3281873_Demonstrating_the_Operationa...

И абсолютно ноль упоминаний того, что она была многозадачной. Она была модульной — это да. Поскольку я уже видел подобные искажения в выборе инструментов, то я совершенно уверен, что Oracle был использован не потому, что тысячи пользователей пользовались этой БД, а потому что разрабам нужно было что-то громкое, большое, и известное на рынке — хотя бы на случай если проект вдруг провалится. Ну типа «nobody gets fired for purchasing Oracle».

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

У мышевозов вставка средней кнопкой. А Alt-W, Ctrl-W не сложнее набрать, чем Ctrl-C, Ctrl-X

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

тяжело нажать Alt-W, потому что Alt закрывается кистью

Ты, как пианист, херачишь сугубо в одной позиции и руки влево-вправо не двигаешь? %)

Ты не понимаешь, о чем ведешь разговор – поищи в интернете, что такое IDE и чем они отличаются от текстовых редакторов.

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

Я тебе больше скажу – и копирование, вставка и создание файлов есть

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

нормальный современный язык как JavaScript

Неплохо шутишь

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

Для емакса, как и других редакторов, есть клиенты LSP и режимы отображения JS/TS/RJSX и т.д

А какого качества? Вопрос риторический.

Замена чистой функции, на которую нет сохранённых указателей - чистая

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

Не обрабатываешь ошибку — падаешь по выходу с общей ошибкой.

Я про твой вариант «расплющивать алгоритм и принимать решение на верхнем уровне». В питоне, конечно, можно всюду напихать yield, но необходимость цикла всюду вместо функций останется

Я вообще потерял нить повествования. При чем тут yield? Почему необходимость циклов вместо функций — это плохо?

http://xahlee.info/kbd/iold51593/Sun_Microsystems_Type_6_Keyboard_left.jpg

С радостью бы заимел такую клаву, только где ж ее взять?

Ты, как пианист, херачишь сугубо в одной позиции и руки влево-вправо не двигаешь?

Куда бы я не двигал руками — мне тяжело нажать Alt-W лежащей рукой, потому что кнопки находятся одна под другой на большом вертикальном расстоянии. Та же история с Alt-F2 — пианистской высокой постановкой рук и Alt-F2 несложно нажать, но такая высокая постановка рук адаптирована под большие клавиши, потому печатать текст так не особо удобно.

А какого качества? Вопрос риторический.

Могу сказать, что сейчас ситуация намного лучше с LSP, чем пол года назад.

тяжело нажать Alt-W лежащей рукой, потому что кнопки находятся одна под другой на большом вертикальном расстоянии

Alt большим пальцем, w указательным, лично для меня гораздо удобнее, чем C-c C-v. Вот C-y да, далековато (для одной руки).

Где поколения корпоративных планировщиков, выстроенных на похожих с DART революционных принципах?

Там же, где поколения космических кораблей на базе Спирали/Бурана/Шаттла и поколения коммерческих самолётов на базе Су-57. DART разрабатывали для военных, исходники только у них. Возможно, даже под грифом.

И абсолютно ноль упоминаний того, что она была многозадачной.

Многопользовательскую немногозадачную систему представить достаточно сложно.

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

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

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

У меня левая рука либо на краю клавиатуры (указательный-безымянный на WASD) и тогда Ctrl под мизинцем, Alt под большим, W легко нажимается средним. Либо в основной позиции, тогда хоть Ctrl-C, хоть Alt-W нажимать проще с правым Ctrl/Alt (то есть не с рукой на мышке).

Да просто поменяй раскладку. Как можно жить на QWERTY?
Читай посты выше.

На леворукий DVORAK?

нет, стандарт => DVP, custom layouts, custom keyboard, custom mouse, custom light, custom food, custom woman, etc…

Купить? На авито точно натыкался (по жизни тоже натыкался, но что теперь, дома склад держать…).

Там же, где поколения космических кораблей на базе Спирали/Бурана/Шаттла и поколения коммерческих самолётов на базе Су-57. DART разрабатывали для военных, исходники только у них. Возможно, даже под грифом

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

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

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

Многопользовательскую немногозадачную систему представить достаточно сложно

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

программа была и работала, а разработка была быстрее за счёт выбора Лиспа

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

У меня левая рука либо на краю клавиатуры (указательный-безымянный на WASD) и тогда Ctrl под мизинцем, Alt под большим, W легко нажимается средним

Я не могу положить пальца одновременно на Ctrl-Alt-W, не сгибая сильно пальцы и/или не поднимая кисти высоко. Речь же не идет о том, что это невозможно — речь о том, что это неудобно. И да, правым альтом это намного удобнее — емакс прежде всего создан для того, чтобы никогда не поддерживать мышку.

Да просто поменяй раскладку. Как можно жить на QWERTY?

Печатать быстро на qwerty очень неудобно, но я этого и не делаю — мне достаточно максимум 300 символов в минуту. Это ж мне нужно клаву специально с надписями для дворака, а где я тебе ее достану.

Забавно, своей уверенностью в собственном невежестве тебе удаётся расположить к себе других людей. Копирование/вставка - M-w/C-y (я пользуюсь evil и буфером +: "+y/p), C-x C-f - нахождение и создание файла, например. Я тебе ещё раз говорю, единую идею как в иде тут не имеет смысла искать, только читать документацию по компонентам, расширяющим редактор.

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

Это ж мне нужно клаву специально с надписями

А ты смешной.

Вам смешно, потому что Вы больше пишете, чем копипастаете.

У меня в браузере Vimium.
Клац-клац и готово.

Речь же не идет о том, что это невозможно — речь о том, что это неудобно.

Разработчики шутеров, когда вешали движение вперёд на W, а модификаторы движения на Alt и Ctrl были другого мнения. И у них как раз снимать руку с мышки при игре нереально.

Разработчики шутеров, когда вешали движение вперёд на W, а модификаторы движения на Alt и Ctrl были другого мнения. И у них как раз снимать руку с мышки при игре нереально

Кто в какой игре вешает действия на Alt? Я не помню, когда в последний раз в такую игра. Shift, Ctrl — да, потому что их легко нажимать мизинцем.

Кто в какой игре вешает действия на Alt?

Doom, CounterStrike и все на них похожие, где есть стрейф.

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

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

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

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

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

Ну и ещё раз про исключения/паники: «не одобряется» строить на них логику и то это больше к библиотекам относится, но при большой необходимости этот инструмент всё-таки доступен.

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

Так в Racket сделано. Но из-за этого есть проблема: если автор библиотеки не сделал unchecked версию, то единственная возможность — полностью её копировать и делать свой вариант библиотеки. Примерно как с GTK: людям легче отфильтровать её вывод, чем отключить все проверки типов внутри.

С учётом того, что Rust позиционируется как системный, странно.

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

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

Ну и ещё раз про исключения/паники: «не одобряется» строить на них логику и то это больше к библиотекам относится, но при большой необходимости этот инструмент всё-таки доступен.

Много кода на Rust с обработкой исключений?

а тебе для чего? emacs нужен, если ты проводишь в нем около 99% своего времени за ПК. Используя emacs, тебе захочется сувать туда все, что можно. Если просто подредачить конфиги или накалякать пару сотен строк на любимом ЯП - welcome to vim.

так не калякать, а рефакторить. И тут Vim сосёт.

Но из-за этого есть проблема: если автор библиотеки не сделал unchecked версию, то единственная возможность — полностью её копировать и делать свой вариант библиотеки.

Во первых, не единственная. Во вторых, чем это отличается от ситуации когда автор библиотеки не предусмотрел что-нибудь или даже банально ошибся? Обычная ситуация, с традиционными способами решения: отправить баг-репорт (фиче реквест), попробовать починить самому (пул реквест), использовать другую библиотеку или даже форкнуть/переписать.

С учётом того, что Rust позиционируется как системный, странно.

Раст позиционируется как «безопасный системный», так что ничего странного.

Правильные проверки должны создавать новый тип.

Это да.

Много кода на Rust с обработкой исключений?

Кода с перехватом паники? Встречается, да и самому писать такой доводилось. В качественных библиотеках (включая стандартную) заботятся о том, чтобы пользовательская паника не оставила объекты в разломанном состоянии, если она была перехвачена.

Но вообще в идеале такого кода и должно быть мало. Просто потому что в большинстве случаев апи с Option/Result удобнее пользоваться. И спрашивать стоит скорее обратное: в каких случаях приходится городить обработку паники. Я тут хотел перечислить ситуации, которые считаю оправданными: FFI, библиотеки защищающие пользователей от стрельбы в ногу, выполнение «внешнего» кода (например, плагины или смарт-контракты). Но кажется, что все они сводятся к тому, что паника происходит из-за ошибки в коде, а гарантировать их отсутствие мы не можем.

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

Тем, что ошибка локальная. А заменить по всему коду чего-то типа BLAS доступ к элементу массива на вызов функции задача глобальная. По-хорошему, это должно делаться через какой-нибудь -fno-bound-check.

использовать другую библиотеку

Много библиотек на Rust предлагают версии с выключенными проверками?

или даже форкнуть/переписать.

Это и есть то, о чём я написал, другими словами.

Раст позиционируется как «безопасный системный», так что ничего странного.

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

Я тут хотел перечислить ситуации, которые считаю оправданными: FFI, библиотеки защищающие пользователей от стрельбы в ногу, выполнение «внешнего» кода (например, плагины или смарт-контракты).

доступ к элементам массива, создание объектов в динамической памяти, …

Тем, что ошибка локальная. А заменить по всему коду чего-то типа BLAS доступ к элементу массива на вызов функции задача глобальная. По-хорошему, это должно делаться через какой-нибудь -fno-bound-check.

Погоди, мы ведь говорили о ситуации когда автор библиотеки не позаботился сделать unchecked функцию. Это тоже «локальная ошибка». А если ты негодуешь, что внутри библиотеки много кода с избыточными проверками, то это уже несколько другая проблема. Точно так же на С++ автор библиотеки может усыпать код проверками в духе if x throw Y (или даже использовать методы вроде at у вектора) и никаким флажком это тоже не выключишь. Обе ситуации решаются правильным дизайном апи: единожды проверяем внешние данные, а внутри лишних проверок не делаем. А делать флажки - это скорее вредно.

Много библиотек на Rust предлагают версии с выключенными проверками?

Не знаю. Но какой смысл ставить вопрос вот так? «Отключать проверки» имеет смысл далеко не везде. По хорошему спрашивать надо «как часто оверхед в библиотеке становится узким местом». Но тут статистики у меня тоже нет.

Это и есть то, о чём я написал, другими словами.

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

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

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

доступ к элементам массива, создание объектов в динамической памяти, …

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

Нехватка памяти - ну допустим. Но, опять же, в среднем коде (не ядре/драйверах), что ты делать будешь? Ты правда постоянно пишешь код держа в уме, что память может кончиться и тогда попрошу кусок поменьше или освобожу какой-то буфер? И не надо про системный язык говорить: я довольно долго писал на С++. Да, может быть мой опыт не показателен, но готов спорить, что и в половине плюсовых проектов нет обработки bad_alloc.

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

Смотря, что писать.

Погоди, мы ведь говорили о ситуации когда автор библиотеки не позаботился сделать unchecked функцию.

Не функцию, а версию библиотеки. Например, есть ndarray. Где найти ndarray_unchecked, который не будет проверять размерность переданных матриц при каждой операции?

Точно так же на С++ автор библиотеки может усыпать код проверками в духе if x throw Y (или даже использовать методы вроде at у вектора) и никаким флажком это тоже не выключишь.

Может. Но без дополнительных явных усилий, по умолчанию, будет быстрый код без проверок. А в Rust по умолчанию код с проверками и надо постараться, чтобы от них избавиться (unsafe блок и неочевидные методы вместо квадратных скобок). Языки в общем случае и отличаются умолчаниями: в Common Lisp по умолчанию в программе есть компилятор и отладчик, в C++ по умолчанию операции небезопасны (зато быстрые), в Haskell по умолчанию вычисления ленивые. При очень большом желании почти все их можно изменить (настоящий программист напишет программу на Фортране на любом языке).

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

единожды проверяем внешние данные, а внутри лишних проверок не делаем

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

в юзер-спейсе всё несколько иначе

Так Rust же вроде как системный. В юзер-спейсе лучше брать Java/C# или тот же Haskell. Будет гораздо надёжнее и не придётся писать unsafe где ни попадя.

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

Возвращать Option. А значение возвращать в get_unchecked.

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

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

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

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

Раст позиционируется как «безопасный системный», так что ничего странного

Позиционироваться он может как угодно, но для того, чтобы стать системным, его нужно долго и нудно дорабатывать напильником. Примерно так же мне бы не пришло в голову называть язык Go системным. По мере того, как ты приближаешься к железу, то внезапно выясняешь, что возникает куча побочных эффектов. которые никаким borrow checker-ом нельзя проверить, появляется необходимость в lock-free и cache-aware алгоритмах, и внезапно твоя «безопасность» помножается на ноль.

В качественных библиотеках (включая стандартную) заботятся о том, чтобы пользовательская паника не оставила объекты в разломанном состоянии, если она была перехвачена.
Но вообще в идеале такого кода и должно быть мало. Просто потому что в большинстве случаев апи с Option/Result удобнее пользоваться. И спрашивать стоит скорее обратное: в каких случаях приходится городить обработку паники

Гладко было на бумаге, да забыли про овраги. Варианта три: утыкать всю стандартную либу Option/Result, допускать UB, либо, как поступили разрабы раста, иногда возвращать ошибку, иногда падать с паникой. Для системного софта паника может значить только одно — полный мгновенный отказ системы. То есть, некорректный индекс в векторе — kernel panic. Чтение юникодного байта не по началу символа — kernel panic. Переполнение числа — kernel panic.

Языки в общем случае и отличаются умолчаниями:... в C++ по умолчанию операции небезопасны (зато быстрые)

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

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

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

Связаны. Через бесплатные абстракции (zero-cost abstractions). Если операция может быть с проверкой и без, по умолчанию должна быть без проверки (её проще добавить чем выковырять).

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

Идеальный компилятор для Питона будет выдавать код намного медленней чем для Си++. Потому что в языке есть динамическая типизация и переопределение операций (причём с двух сторон). Идеальный компилятор для Rust никогда не сможет выкинуть все ненужные проверки, которые предусмотрены описанием языка.

и был бы быстрый паскаль и не очень быстрый C++

Есть в gcc фронтенд к Ada. По тексту паскаль, по скорости Си++ (с pragma Suppress(All_Checks)).

Разница между крестами и Java только в том, что Java спроектирована еще хуже, потому ее не удается скомпилировать AoT.

Ну вот. А пишешь «свойством компиляторов, а не языка». Кстати, удаётся: gcj и прочие jaotc.

И, внезапно, ООП в С++ работает как не-ООП и память не жрёт.

Через бесплатные абстракции (zero-cost abstractions). Если операция может быть с проверкой и без, по умолчанию должна быть без проверки (её проще добавить чем выковырять)

Да, но в крестах не было никаких проверок и эта фича не закладывалась в язык в принципе. Да, отдельные разрабы, вроде внезапно адекватных MS, ввели в свою реализацию STL отключаемые проверки, но большинство разрабов просто забили, Особенно какие-то нибудь вахетеры из GCC, которые считают честью ввести в компилятор какое-нибудь дичайшее UB, вроде вываливания выполнения за границу функции.

Идеальный компилятор для Питона будет выдавать код намного медленней чем для Си++. Потому что в языке есть динамическая типизация и переопределение операций (причём с двух сторон). Идеальный компилятор для Rust никогда не сможет выкинуть все ненужные проверки, которые предусмотрены описанием языка

Я сомневаюсь, что так уже тяжело выкинуть все рантаймовые проверки из раста.

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

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

Проектирование ЯП задает простоту написания компилятора. Для Java можно сделать AoT компиляцию, но сделать это намного сложнее, чем для C++. Ты забыл про GraalVM, которое вполне успешно профилирует код и использует эту информацию для AoT оптимизации. Еще V8 делает то же для JS. Это сильно сложнее, чем с C++, но в конечном счете всё решают $$$.

И, внезапно, ООП в С++ работает как не-ООП и память не жрёт

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

Да, отдельные разрабы, вроде внезапно адекватных MS, ввели в свою реализацию STL отключаемые проверки, но большинство разрабов просто забили

???

В std::vector есть operator[] без проверки и метод at() с проверкой.

То есть a[x] для сишного массива и для std::vector даёт одинаковый код, а не добавляет внезапно проверку.

Я сомневаюсь, что так уже тяжело выкинуть все рантаймовые проверки из раста.

Попробуй. Сколько у тебя уйдёт времени, чтобы сделать из ndarray вариант без проверок (ndarray_unchecked)?

И лиспы оптимизируют, и Lua, и JS.

Лисп без declare type работает примерно в 10 раз медленнее, чем с declare type.

Намного большая проблема — это сборка мусора

Java, Haskell и C# работают намного быстрее любого языка с без статической типизации.

То есть сборщик мусора даёт умножение времени выполнения на 2, отсутствие статических типов ещё на 10.

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

??? Это какой сложный тип можно описать на Си и нельзя на Питоне?

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

Множественные наследования бесплатны. Рантаймовые диспетчеризации не дороже, чем аналогичный выбор по полю структуры в любом другом языке. Разделяемые указатели добавляют одну операцию на копирование объекта и один счётчик. Но, опять же, если действительно время жизни заранее не определено, то в любом языке придётся делать то же самое. А если определено, то unique_ptr бесплатен.