Rust и двусвязный список

При прочих равных

опять нет

Ну давай свою капустку.

приблизительно вот так:

1. дополнительный код для реализации дополнительных фич — это естественно

2. дополнительные спецификации кода (поверх предоставляемых системой типов языка) — это естественно (а может и обязательно)

3. дополнительные доказательства корректности (поверх предоставляемых системой типов языка) — это терпимо, но непродуктивно; выводом доказательств должны заниматься специализированные программы

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

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

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

В частности, если бы С++ был бы достоин познания и решал бы все нужные задачи, то не было бы ни Java, ни Go, ни Rust.

Если следовать этой логике, то джаве не нужна ведь есть C#, Go и прочие. И лисп, наверное, не нужен - ведь придумали кучу более «модных» языков?..

Да, желательно что-то большее, чем hello world. Пока что в основном под Rust пишут школьные поделки и просто обертки к сишным либам.

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

Ссылочками на что?

На параллелизм DRAM. Больше всего интересует на каком уровне он достигается.

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

дико

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

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

а так-то мне только дай тэгированную память! я тогда о-го-го!!!

существуют (например, если они формально верифицированы);

Не-не-не, а сам верификатор верифицирован? А при доказательстве точно не срезали углы?

Если что, я не собираюсь спорить о пользе формальных доказательств, поэтому всерьёз можно не отвечать. Это была просто ирония над изначальным утверждением. Так-то когда условный джава программист пишет код, он не боится сегфолтов, хотя где-то в JVM и будет код на С. Но это не принимается во внимание в 99% случаев.

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

Рассуждения об этике заиграли новыми красками.

В случае памяти DRAM всё же еще и параллелизм. ЕМНИП, на 2 каналах DDR4 мы имеем 32 банка. Я недавно делал у себя тесты LMDB в ioarena. На 32 потоках +50% к случайному чтению по сравнению с 16 потоками на R9 5950X, и это не учитывая Turbo Boost. Т.е., с нормированием по частоте, прирост, который дает SMT будет еще больше, под 60-70%. Вот этот параллелизм по памяти и хочется задействовать в рамках OoOE для однопоточного кода.

Хэш-таблицы нельзя сделать функциональными и сохранить при этом быструю вставку. Там на каждое обновление будет копироваться весь хэш-массив. Только деревья, причем без parent links, что усложняет итераторы.

На параллелизм DRAM. Больше всего интересует на каком уровне он достигается.

Погугли DDR4 bank/rank parallelism. https://my.eng.utah.edu/~cs7810/pres/11-7810-12.pdf

2. дополнительные спецификации кода (поверх предоставляемых системой типов языка) — это естественно (а может и обязательно)

Значит, надёжный код станет больше «обычного», что и требовалось доказать.

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

Тут весь вопрос в том, насколько полезны гарантии Раста, какую долю проблем они исправят. Вот тут https://zen.yandex.ru/video/watch/62a8edba86dde05b87360677?t=1180

я показываю долю уязвимостей ядра Линукса, вызванную дефектами языка Си. Притом, сообщество вполне может выкатывать новую версию ядра линукса раз в квартал, а вот сделать линукс, в котором не было бы дыр - далеко за пределами возможности сообщества. Если на этой картинке переход на Раст позволит закрыть те самые 40% дыр, но трудоёмкость увеличится в 10 раз, но при этом количество дыр других типов не возрастёт, то переход на Раст оправдан. Поскольку трудоёмкость «безопасного линукса» от трудоёмкости «реального линукса» пока что отличается в бесконечное количество раз - никто не осилил сделать безопасный линукс.

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

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

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

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

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

Напомню и я, что byko3y С++ толком не знает, а про раст ему вообще Рабинович напел

Ну что значит «толком не знает»? Я просто пишу на той части C++, которая приятна и на которой можно написать работоспособный софт. Полжизни тратить на то, чтобы «толком» знать хотя бы большую часть бессмысленных и беспощадных комбинаций фич крестов, я не собираюсь. А учить C++ можно бесконечно, чего стоят только одни категории выражений:
https://en.cppreference.com/w/cpp/language/value_category
Эта дичь родилась еще в Си, в котором по случайным правилам выражения были поделены на rvalue и lvalue, но до абсурда это было доведено только в C++11 — не забываем про шаблоны, которые эту сложность умножают.

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

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

Я сам не пытаюсь делать, потому что не вижу совсем никакой перспективы. Очень много кто понимает, что проблема есть, и даже отдельные люди что-то делают, но индустрия все равно будет идти по инерции. C++ — это и есть квинтэссенция инертности и импотентности индустрии (ни один участник не рискнет убрать говно, которое лежит 50 лет), как язык, который до сих пор несет какую-то долю совместимости с ассемблером 60-х годов, при том, что последний стандарт языка выпущен в 2020. Просто переписать C++, выкинув из него лишний мусор и UB в особенности, сделает язык на порядок лучше — но этого почему-то никто не может сделать. Это сложно? Для этого нужно быть дофига экспертом-архитектором?

Rust лучше C/C++ для повседневной разработки уже тем, что в первом в безопасном подмножеств почти нет UB, что снижает соответствующую нагрузку на программиста и ревьюера. В остальном, Rust более безопасный, чем C/C++, но менее — чем Java.

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

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

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

Согласен. Потому не нужно совать вывод типов туда, где он не нужно. Но он нужен там, где он нужен. Например, когда ты пишешь a = b + c + d, то даже сишка здесь выводит тип — но кто-то почему-то решил, что полиморфность должна обрезаться строго по прототипу функции — это наследие асма 60-х годов. Хотя, в том же фортране и алголе-60 функции были полиморфными.

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

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

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

если недостатки найдены — значит язык плохой, примерно так; так что ЛЮБАЯ критика уместна, даже, до определенной степени, критика вида «мне было трудно его изучать»

ну и задача проектирования приличного языка в такой постановке, мягко говоря скажем, совсем-совсем не рядовая по сложности — и мешает это, а не менеджеры

Я имел в виду, безопасность по памяти. В Rust в общем случае нельзя писать без unsafe, а в Java — можно (и нужно).

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

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

Rust лучше C/C++ для повседневной разработки уже тем, что в первом в безопасном подмножеств почти нет UB, что снижает соответствующую нагрузку на программиста и ревьюера

«В безопасном подмножестве»... Тиресная формулировка. Я полностью согласен, что читать растовую лапшу все-таки как-то проще, чем крестовую лапшу. Правда, я бы предпочел не писать слишком сложного софта ни на Rust, ни на C, ни на C++. А когда ты сделал unsafe системщину и DSL или биндинги поверх этого, то как-то уже толком и нечего ревьюить. Короче говоря — не пишите прикладнуху на системных ЯП. Это намного сильнее снижает нагрузку, чем применение Rust.

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

Именно. Проблема в том, что Rust форсят использовать именно в прикладухе. Что частично обосновано там, где нужна максимальная производительность (в том числе на ватт) и мы готовы платить за это усложнением разработки.

Тут существенным становится вопрос, в какой нише Rust — C или C++. Rust развивается, но раньше я его рассматривал как конкурент С, но никак не C++.

В Rust в общем случае нельзя писать без unsafe, а в Java — можно (и нужно)

Возражение! Это причина всех проблем с производительностью и жоркостью памяти. В C# эту проблему не повторили, задействовав натив, то есть unsafe, за счет чего бегает он намного шустрее и жрет намного меньше.

В частности, Rust и Golang, последний есть все основания сравнивать с Java

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

Оператор «ойвсё»

есть у меня на примете хороший, годный оператор «ойвсё» для выхода из цикла для программирования в стиле icon

Это причина всех проблем с производительностью и жоркостью памяти.

Ну разумеется! Я уже говорил выше, что GC в общем случае не масштабируется. Ну не подходит Java для DBMS. Пишем микросервисы без состояния, которое храним в БД и будет нам счастье (и маленькие кучи).

В C# эту проблему не повторили, задействовав натив, то есть unsafe, за счет чего бегает он намного шустрее и жрет намного меньше.

Педантизма ради, в Java тоже. В Java 17 появился, наконец, Project Panama, там много чего интересного и вкусного можно делать. Java исправляется в плане CPU-производительности. Так что его прям сбрасывать со счетов сейчас не стоит. Единственная моя печаль — это что Project Loom (стековые файберы как в Go) не имеем шанса увидеть свет в обозримом будущем. В этом аспекте у Golang пока нет альтернативы.

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

Legacy, сэр!

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

Значит, надёжный код станет больше «обычного», что и требовалось доказать.

я не согласен с тем, что спецификации кода ты считаешь тоже кодом

спецификации кода:

1. могут быть внешними, то есть по сути ТЗ

2. могут быть очевидны программисту и не приходя в сознание выписываться на приличном языке для спецификаций либо выводиться какой-то inference engine; это сильно отличается от «продумайте систему владения указателей для узлов графа и...»

3. да и вообще: предикаты — это не код

правда, я уже сильно потерял нить разговора

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

Я выше по треду писал, что на самом деле это происходит потому, что в GUI 90% всех функций выполняются в одном потоке. Там, где нужна именно производительность, пишут на сишке. Rust попадает в очень узкую нишу, которая вроде высокоуровневая и кодовая база большая, но нужны низкоуровневые оптимизации в огромном количестве, поскольку главный поток один и межпоточное взаимодействие минимально, и при этом удаленное выполнение кода недопустимо.

Какой еще софт ты можешь придумать под эти требования? СУБД? В них массово применяются потоки, разделяемая оперативная и персистентная память, а это сплошной unsafe в Rust-е. Микросервисы? Да туда что угодно пойдет. Я видел интересное применение Rust для написания кастомных функций для СУБД — как высокопроизводительная замена всяких там хранимок и внутрисерверных скриптов. Правда, это применение едва ли задействует половину фич Rust, это больше похоже на простой DSL — кому-то было лень писать свой транслятор в LLVM IR, так что не засчитывается. GUI? Они сейчас массово пишутся на Electron-е, хотя всегда есть Qt — мало кого волнует удаленное выполнение кода, поскольку обычно GUI софт не рисует в себе сложное произвольное содержимое с недоверенного хоста.

Я уже несколько раз высказывал этот тезис, но я до сих пор не вижу возражений. Да, кто-то выше упоминал крипту — но это изначально упоротая сфера, где наркомания зашкаливает и потому применение Rust или Haskell не вызывает удивления, если вспомнить, что эти же люди собрались делать вебсайты на блокчейне. На мой взгляд, Rust-у в блокчейне нечего ловить: да, производительность нужна, но входные выходные данные очень ограничены в разнообразии, потому корректную их обработку можно сделать на любом ЯП, причем, если будет ошибка расчетов, то по панике могут завалиться все узлы в сети, ровно как Rust не спасет от уязвимости в самом методе криптографии. Если считать что-то на GPGPU, то там вообще свой мир и свои трудности, которые никак не пересекаются не то что с Rust, но даже с C++, даже несмотря на то, что Nvidia хочет убедить людей, что писать ядра на C++ — хорошая идея. Для GPGPU важна каждая инструкция, неявный код может чудовищно затормозить всё ядро, потому нужен строго низкоуровневый язык без неявного поведения.

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

не факт что я прямо уж согласен (хотя конечно граф на яве пишется легко и не приходя в сознание), но это интересная тема на подумать

Я уже говорил выше, что GC в общем случае не масштабируется. Ну не подходит Java для DBMS. Пишем микросервисы без состояния, которое храним в БД и будет нам счастье (и маленькие кучи)

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

Просто переписать C++, выкинув из него лишний мусор и UB в особенности, сделает язык на порядок лучше — но этого почему-то никто не может сделать. Это сложно? Для этого нужно быть дофига экспертом-архитектором?

тут еще такая проблема: не ясно как срубить с этого бабла

тут еще такая проблема: не ясно как срубить с этого бабла

И это тоже. Устройство западного общества вот такое волшебное: больше всех зарабатывает тот, кто делает людей более всего несчастными. Это называется «маркетинг».

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

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

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

все в рамках рыночка, который тебе так не нравится

Я видел интересное применение Rust для написания кастомных функций для СУБД — как высокопроизводительная замена всяких там хранимок и внутрисерверных скриптов. Правда, это применение едва ли задействует половину фич Rust, это больше похоже на простой DSL — кому-то было лень писать свой транслятор в LLVM IR, так что не засчитывается.

кинь ссылку на это

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

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

отнюдь не всегда это нужно

допустим, у нас есть внешний сервис, который принимает json и валидирует его конечным автоматом; он (и сервис, и автомат) имеет право ничего не запоминать и просто сказать «валид/инвалид» без малейших попыток диагностики (для диагностики да, надо че-то запоминать)

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

Истина заключается в том, что все критерии лучше-хуже выдуманы. А смысл жизни заключается в самой жизни, нет никакой планки, подпрыгнув до которой, например, ты становишься бессмертным или «level complete», идет статистика, и потом ты переходишь на новый уровень с новыми боссами. Когда человек перестает голодать, то он начинает плодиться, когда он достаточно размножился, то идет отрывать голову соседу — вот тебе и весь «смысл жизни».

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

Рынок ВСЕГДА подразумевает силовые методы, вопрос только в том, кто их применяет. Если применяет единственный монополист силы, задающий безальтернативные правила, то это «цивилизованный рыночек». Если сил несколько и они соревнуются — это «дикари».

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

кстати, у корпоративных потребителей данный навык (искать «какой товар на самом деле лучше») лучше развит, чем у домохозяев(-ек)

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

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

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

Вот она, но оказывается, что они не использовали раст, а сделали именно так, как я написал — скриптовый DSL, компилируемый в LLVM IR:
https://hyper-db.de/
То есть, раст в пролёте и в этой нише — он слишком низкоуровневый для БД.

(на момент написания читанной мной книжки про многие ЯП).

что за книжка?

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

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

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

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

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

допустим, у нас есть внешний сервис, который принимает json и валидирует его конечным автоматом; он (и сервис, и автомат) имеет право ничего не запоминать и просто сказать «валид/инвалид» без малейших попыток диагностики (для диагностики да, надо че-то запоминать)

Зачем тут конечный автомат? Он очень медленно парсит JSON — быстрее всего это делают парсеры, которые поэтапно параллельно преобразуют одно представление в другое каким-нибудь SIMD-ом. Если тебе нужно парсить какой-то жирный протокол или большой объем данных, то тебе опять же нужно ставить парсинг на паузу и обрабатывать какие-то другие задачи, вроде «прочитать очередную порцию» или «показать прогресс».

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

нет, странно что ты это увидел

я говорю лишь о том, что проблема «говноедство» может быть частично решена вне рф (а еще более частично может даже и внутри рф, но это под вопросом) несиловыми методами (и кстати интересно, можно ли ее решить силовыми методами?)

нет, не парсер, а именно валидатор

да, SIMD тут может быть game changer, но я начинал с того, что голые goto — это все же необходимость, а не прихоть и не атавизм

на SIMD да, стейт может и не получится хранить в IP

я говорю лишь о том, что проблема «говноедство» может быть решена вне рф (а частично может даже и внутри рф, но это под вопросом) несиловыми методами (и кстати интересно, можно ли ее решить силовыми методами?)

Образовать коммуну неговноедов? Где? В штатах за такими официально ведется охота. Сейчас глобализм, потому западный режим насаждается повсюдю. Где не западный — там китайским. И остается только антарктида, дальная сибирь, и африка. Чтобы выжить, этой коммуне нужно быть неформальной, не иметь руководителя и конкретного места обитания. Грубо говоря — тусовка по интересам. Примерно 1% населения планеты в принципе могут жить в таком духе (остальным нужен барский сапог в жопе), но далеко не все из этого процента захотят участвовать в тусовочке. Если соберешь хотя бы пару десятков людей — я буду рад присоединиться.

да, SIMD тут может быть game changer, но я начинал с того, что голые goto — это все же необходимость, а не прихоть и не атавизм

А я уже ответил, что goto прекрасно эмулируется через switch.

Образовать коммуну неговноедов? Где? В штатах за такими официально ведется охота.

1. давай факты охоты

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

Если соберешь хотя бы пару десятков людей — я буду рад присоединиться.

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

лично мне интересно любое недовольство квалифицированных незашоренных программистов (и с большими оговорками даже и неквалифицированных)

1. давай факты охоты

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

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

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

http://thefreethoughtproject.com/11-alternative-heath-doctors-dead-3-months/ - 2015, начало
https://envirowatchrangitikei.wordpress.com/2017/11/18/77th-holistic-doctor-s... - 2017, конец

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

Я этим занимался когда-то на LOR-е, давай на минуту представим, что занимаюсь до сих пор, итак: я готов реализовать твою идею, но почему я должен тратить на нее свое время?

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

неееееет, совсем не так; я предлагаю тебе систематизировать ТВОИ недовольства, хотелки, и затем даже идеи

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

про мои идеи — разговор отдельный

Я этим занимался когда-то на LOR-е

меня тут лет 5 не было; ты о чем говоришь?

я тебе предлагаю для начала собрать и систематизировать все твое недовольство во всем стеке от железа до софта
лично мне интересно любое недовольство квалифицированных незашоренных программистов (и с большими оговорками даже и неквалифицированных)

Ох, недовольств у меня дофига, целые склады в текстовых файликах записаны — они просто толком никому не нужны. Как я уже писал на LOR-е (но не в этом треде): на то воля божья, чтобы мартыха бегала с менее опасной гранатой, и нельзя давать ей более функциональную гранату, пока мартыха не станет более разумной, потому что убьется. Возьми ту же историю с Pascal/Algol 67: индустрия стояла в одном шаге от получения лучшего языка для того времени, что дало бы портируемый и надежный софт, который можно было бы запускать компиляцией прямо из сорцов, как команды на баше, потому что компилировать сорцы так же быстро, как загружать бинарь с диска. Но что-то случилось, приняли Алгол-76 таким, как приняли, Вирт многие годы пытался в одно рыло сделать свой ЯП, пока наконец второй чел не сделал компилятор, который позже выкупила Borland и не монополизировала весь паскаль к чертям собачьим, похоронив его в пользу C/C++, которые по поводу гарантий надежности софта гарантируют только отсутствие этой надежности.