OberonCore https://forum.oberoncore.ru/ |
|
Критика Golang https://forum.oberoncore.ru/viewtopic.php?f=61&t=6350 |
Страница 2 из 3 |
Автор: | PSV100 [ Понедельник, 11 Февраль, 2019 20:05 ] |
Заголовок сообщения: | Re: Критика Golang |
budden писал(а): Поэтому я не соглашусь, что defer это плохо. И, на мой взгляд, в обероне подобной конструкции не хватает. Для Оберон-ов есть предложение на базе метаданных: Zero-Overhead Exception Handling Using Metaprogramming Однако, этот механизм (лишь для обработки exception) на основе "устных соглашений", вне контракта системы типов или без явных управляющих языковых конструкций. Может быть, каким-то способом через compiletime-макросы можно сделать механизм и с явными декларациями, в том числе и эмуляцию finally-секций или RAII (т.е. исполнение обработчиков и при "обычном" выходе из процедур), и может быть с иной стоимостью runtime-обработки метаданных (или вообще без интроспекции). А в целом, вопрос в целесообразности. В самом Go defer-а не достаточно, раз уже имеются неструктурные прыжки, то тогда уж и обработку ошибок возникает желание делать не только "структурными if-ами", из-за чего собираются добавить и check с handle: Обработка ошибок в Go 2 Откровенно говоря, механизм scope в D выглядит, хотя бы по крайней мере, однородно на фоне Go-экспериментов: https://dlang.org/articles/exception-safe.html Однако, в случае существенного разнообразия видов всех этих "defer-ов" уже под вопросом понятность алгоритмов. Причём, согласно статейке выше про exception в Оберон-ах, эти "defer-ы" покрывают лишь т.н. terminate-семантику (в вариантах success, failure или же в целом finally), и нет resume- и retry-семантики. В Rust-е, к слову, когда-то предлагали и эмуляцию лисповых "conditions and restarts" (resume-семантику), в дополнение к прочим макросам для обработки ошибок: https://static.rust-lang.org/doc/0.8/tutorial-conditions.html#conditions |
Автор: | PSV100 [ Понедельник, 11 Февраль, 2019 20:11 ] |
Заголовок сообщения: | Re: Критика Golang |
budden писал(а): Мне кажется, что хорошего подхода к обработке ошибок пока не придумано. По крайней мере, есть ещё "автоматные" подходы -- иерархические "состояния" или автоматы с "вытеснением" внутренних состояний/автоматов. Идеи "реактивного программирования" из 80-х в мейнстрим притянули лишь частично и в искажённом представлении (точнее, современные игры в "реактивность" совсем иные на фоне истоков). Ниже примерчик из С-подобного экспериментального языка SHIM (для верификации систем), где exception-ы построены по некоторым мотивам из Esterel: Scheduling-Independent Threads and Exceptions in SHIM Exception-ы в статейке, как минимум, имеют несколько иную, отличную от привычной семантику. Этот конкретный вариант механизма несколько усложнён и спорный в ряде моментов, и это всего лишь пример. А в целом, exception-ы выше это замаскированные некоторые "сигналы" (в более привычной форме как объекты Exception и в виде операторов try/catch) из древней автоматной школы (здесь на форуме про Esterel/Lustre и производные есть отдельная темка). И гипотетически в языке возможен единый способ выражения структур данных и процессов над ними, включая параллельные (истинно параллельные и корутины), что по сути, на фоне Go, есть альтернатива не только отдельным механизмам обработки ошибок и RAII (с поддержкой всех вариантов семантики), но и Go-рутинам с оператором select и пр. Но это отдельная и непростая тема. |
Автор: | Ярослав Романченко [ Вторник, 30 Апрель, 2019 15:07 ] |
Заголовок сообщения: | Re: Критика Golang |
budden писал(а): Оказалось - в голанге сериализация есть, не знаю насчёт десериализации обратно из текста. Многие другие вещи как раз прямо являются воплощением моих планов и завершением моих экспериментов. Сериализация, говорите, в голанге есть. Это больше похоже на её отсутствие...В частности, попробовал сделать парсинг CSV аналогично, как делал на Object Pascal. Скорость парсинга, в приципе, получил соизмеримую. Но! Хвалёная сериализация встроенная в Go (GOB) это просто какой-то сплошной дикий тормоз. Наверное в A2 в XML-ки гораздо быстрее сериализуется! В Object Pascal встроенная сериализация работает просто молниеносно быстро. Ip2Location база пишется/читается за 2 мс. В Go чтение/запись GOB такие же по скорости как парсинг CSV. Это ж просто бред какой-то, а не сериализация! Зачем она такая нужна??? И в Object Pascal бинарники (сериализованные данные) в 6 раз компактнее! Вот, подобное с 12-го года висит Parsing gob is significantly slower than parsing JSON И подобных тем и бенчмарков целая куча. Не понял ещё, правда, кто же победитель по скорости... |
Автор: | Ярослав Романченко [ Вторник, 30 Апрель, 2019 15:15 ] |
Заголовок сообщения: | Re: Критика Golang |
budden писал(а): defer В Active Oberon есть близкий аналог - FINALLY
|
Автор: | Kemet [ Вторник, 30 Апрель, 2019 16:53 ] |
Заголовок сообщения: | Re: Критика Golang |
Ярослав Романченко писал(а): делал на Object Pascal Нет варианта с отображением файла в память ))
|
Автор: | Ярослав Романченко [ Вторник, 30 Апрель, 2019 19:32 ] |
Заголовок сообщения: | Re: Критика Golang |
Kemet писал(а): Ярослав Романченко писал(а): делал на Object Pascal Нет варианта с отображением файла в память )) |
Автор: | Kemet [ Среда, 01 Май, 2019 13:47 ] |
Заголовок сообщения: | Re: Критика Golang |
Ярослав Романченко писал(а): Сериализация в Object Pascal, это практически отображение из памяти / в память, очень эффективная реализация. Да вроде, обычное чтение из потока было, или что-то в этом плане изменилось и они стали мапить файлы?
|
Автор: | budden [ Суббота, 04 Январь, 2020 01:54 ] |
Заголовок сообщения: | Re: Критика Golang |
Ярослав Романченко писал(а): Kemet писал(а): Ярослав Романченко писал(а): делал на Object Pascal Нет варианта с отображением файла в память ))Не очень понял, о чём речь. Но допустим, отображение в память. Можно ли сломать систему, подсунув ObjectPascal определённым образом подготовленный файлик? |
Автор: | Ярослав Романченко [ Суббота, 04 Январь, 2020 18:19 ] |
Заголовок сообщения: | Re: Критика Golang |
budden писал(а): Не очень понял, о чём речь. Как минимум, очень медленно как-то всё работает, сериализация массивов, в частности. Но хорошо, что можно подсунуть свою реализацию, и всё сразу работает быстрее на порядок.budden писал(а): Но допустим, отображение в память. Можно ли сломать систему, подсунув ObjectPascal определённым образом подготовленный файлик? При желании всё можно сломать.
|
Автор: | Rifat [ Суббота, 04 Январь, 2020 18:31 ] |
Заголовок сообщения: | Re: Критика Golang |
Мне кажется, что есть две разные цели: быстрота реализации, тогда она будет небезопасной, или же безопасность, тогда она будет медленной. |
Автор: | Ярослав Романченко [ Суббота, 04 Январь, 2020 23:00 ] |
Заголовок сообщения: | Re: Критика Golang |
Rifat писал(а): Мне кажется, что есть две разные цели: быстрота реализации, тогда она будет небезопасной, или же безопасность, тогда она будет медленной. В чём небезопасность, конкретно? Вариант, что существующая стандартная реализация просто не эффективна, не рассматривается?
|
Автор: | budden [ Воскресенье, 05 Январь, 2020 01:34 ] |
Заголовок сообщения: | Re: Критика Golang |
Цитата: При желании всё можно сломать. Тут вопрос такой: если данный вид файла может прийти по сети, замапить поинтер и выполнить произвольный код, то это неприемлемо и нужен другой формат, защищённый от таких штук. Если он создаётся только локально, то тогда другой разговор - байтики на локальном жёстком диске всегда можно как-нибудь подменить, поэтому защищаться от такого варианта локально нет смысла. |
Автор: | Sergej Durmanov [ Воскресенье, 05 Январь, 2020 06:43 ] |
Заголовок сообщения: | Re: Критика Golang |
Это же просто ресурс, там нечего выполнять. В windows-версии он вообще хранится в исполняемом файле программы |
Автор: | budden [ Воскресенье, 05 Январь, 2020 14:17 ] |
Заголовок сообщения: | Re: Критика Golang |
Насколько я понимаю отображение файла на память, то в самом "мощном" случае мы получаем в памяти некий граф структур с указателями на некие области памяти, которые определяют связи между этими структурами. Если эти указатели подменить, то мы начинаем читать какую-то левоту, например, пароль, хранящийся в памяти. Если же при обработке данной информации происходит и запись в структуры, то мы можем записать в стек адрес своего кода, который при очередном return исполнится. Если в этом файле нет ничего похожего на указатели, а речь идёт лишь о способе ввода-вывода байт, которые мы потом как-то интерпретируем и проверяем, то опасности нет, но и ускорению большому я не вижу откуда взяться. |
Автор: | budden [ Воскресенье, 05 Январь, 2020 14:18 ] |
Заголовок сообщения: | Re: Критика Golang |
Т.е., чтобы не говорить об этих указателях, нужно разобраться, а за счёт чего же именно это отображение файла в память даёт такой быстрый разбор? |
Автор: | Ярослав Романченко [ Понедельник, 06 Январь, 2020 08:58 ] |
Заголовок сообщения: | Re: Критика Golang |
budden писал(а): Т.е., чтобы не говорить об этих указателях, нужно разобраться, а за счёт чего же именно это отображение файла в память даёт такой быстрый разбор? Из-за того, что не надо парсить значения (в случае бинарного представления).
|
Автор: | budden [ Понедельник, 06 Январь, 2020 14:29 ] |
Заголовок сообщения: | Re: Критика Golang |
В общем-то, наверое, глупость я написал. В файле не может быть указателей, максимум там могут быть смещения, которые нужно "перелинковать" после загрузки файла в память. А если отличие в скорости за счёт бинарного формата, то тогда дело вообще в другом и с т.з. безопасности разницы особо нет. Хотя парсить нужно и бинарный формат, просто парсер может быть экстремально простым и поэтому быстрым. |
Автор: | Sergej Durmanov [ Понедельник, 06 Январь, 2020 14:54 ] |
Заголовок сообщения: | Re: Критика Golang |
Так при отображении файла в память мы не используем файловые операции, а обращаемся напрямую к памяти. Поэтому нет тормозов в работе |
Автор: | budden [ Понедельник, 06 Январь, 2020 15:03 ] |
Заголовок сообщения: | Re: Критика Golang |
Т.е. у наc уже две версии |
Автор: | Sergej Durmanov [ Понедельник, 06 Январь, 2020 15:11 ] |
Заголовок сообщения: | Re: Критика Golang |
budden писал(а): Т.е. у наc уже две версии какие версии? Достаточно посмотреть значение термина Отображение файла в память
|
Страница 2 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |