OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 21:47

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Понедельник, 11 Февраль, 2019 20:05 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Понедельник, 11 Февраль, 2019 20:11 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
budden писал(а):
Мне кажется, что хорошего подхода к обработке ошибок пока не придумано.

По крайней мере, есть ещё "автоматные" подходы -- иерархические "состояния" или автоматы с "вытеснением" внутренних состояний/автоматов. Идеи "реактивного программирования" из 80-х в мейнстрим притянули лишь частично и в искажённом представлении (точнее, современные игры в "реактивность" совсем иные на фоне истоков).
Ниже примерчик из С-подобного экспериментального языка SHIM (для верификации систем), где exception-ы построены по некоторым мотивам из Esterel:
Scheduling-Independent Threads and Exceptions in SHIM

Exception-ы в статейке, как минимум, имеют несколько иную, отличную от привычной семантику. Этот конкретный вариант механизма несколько усложнён и спорный в ряде моментов, и это всего лишь пример. А в целом, exception-ы выше это замаскированные некоторые "сигналы" (в более привычной форме как объекты Exception и в виде операторов try/catch) из древней автоматной школы (здесь на форуме про Esterel/Lustre и производные есть отдельная темка). И гипотетически в языке возможен единый способ выражения структур данных и процессов над ними, включая параллельные (истинно параллельные и корутины), что по сути, на фоне Go, есть альтернатива не только отдельным механизмам обработки ошибок и RAII (с поддержкой всех вариантов семантики), но и Go-рутинам с оператором select и пр. Но это отдельная и непростая тема.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Вторник, 30 Апрель, 2019 15:07 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
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:28, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Вторник, 30 Апрель, 2019 15:15 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
budden писал(а):
defer
В Active Oberon есть близкий аналог - FINALLY


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Вторник, 30 Апрель, 2019 16:53 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Ярослав Романченко писал(а):
делал на Object Pascal
Нет варианта с отображением файла в память ))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Вторник, 30 Апрель, 2019 19:32 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
Kemet писал(а):
Ярослав Романченко писал(а):
делал на Object Pascal
Нет варианта с отображением файла в память ))
Сериализация в Object Pascal, это практически отображение из памяти / в память, очень эффективная реализация. Смотрю теперь на то как сделано в Go как на "Цырк на дроти" (Цирк на проводе). Как можно было такое убожество выкатывать в массы?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Среда, 01 Май, 2019 13:47 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Ярослав Романченко писал(а):
Сериализация в Object Pascal, это практически отображение из памяти / в память, очень эффективная реализация.
Да вроде, обычное чтение из потока было, или что-то в этом плане изменилось и они стали мапить файлы?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Суббота, 04 Январь, 2020 01:54 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Ярослав Романченко писал(а):
Kemet писал(а):
Ярослав Романченко писал(а):
делал на Object Pascal
Нет варианта с отображением файла в память ))
Сериализация в Object Pascal, это практически отображение из памяти / в память, очень эффективная реализация. Смотрю теперь на то как сделано в Go как на "Цырк на дроти" (Цирк на проводе). Как можно было такое убожество выкатывать в массы?

Не очень понял, о чём речь. Но допустим, отображение в память. Можно ли сломать систему, подсунув ObjectPascal определённым образом подготовленный файлик?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Суббота, 04 Январь, 2020 18:19 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
budden писал(а):
Не очень понял, о чём речь.
Как минимум, очень медленно как-то всё работает, сериализация массивов, в частности. Но хорошо, что можно подсунуть свою реализацию, и всё сразу работает быстрее на порядок.
budden писал(а):
Но допустим, отображение в память. Можно ли сломать систему, подсунув ObjectPascal определённым образом подготовленный файлик?
При желании всё можно сломать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Суббота, 04 Январь, 2020 18:31 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Мне кажется, что есть две разные цели: быстрота реализации, тогда она будет небезопасной, или же безопасность, тогда она будет медленной.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Суббота, 04 Январь, 2020 23:00 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
Rifat писал(а):
Мне кажется, что есть две разные цели: быстрота реализации, тогда она будет небезопасной, или же безопасность, тогда она будет медленной.
В чём небезопасность, конкретно? Вариант, что существующая стандартная реализация просто не эффективна, не рассматривается?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Воскресенье, 05 Январь, 2020 01:34 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Цитата:
При желании всё можно сломать.

Тут вопрос такой: если данный вид файла может прийти по сети, замапить поинтер и выполнить произвольный код, то это неприемлемо и нужен другой формат, защищённый от таких штук. Если он создаётся только локально, то тогда другой разговор - байтики на локальном жёстком диске всегда можно как-нибудь подменить, поэтому защищаться от такого варианта локально нет смысла.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Воскресенье, 05 Январь, 2020 06:43 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
Это же просто ресурс, там нечего выполнять. В windows-версии он вообще хранится в исполняемом файле программы


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Воскресенье, 05 Январь, 2020 14:17 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Насколько я понимаю отображение файла на память, то в самом "мощном" случае мы получаем в памяти некий граф структур с указателями на некие области памяти, которые определяют связи между этими структурами. Если эти указатели подменить, то мы начинаем читать какую-то левоту, например, пароль, хранящийся в памяти. Если же при обработке данной информации происходит и запись в структуры, то мы можем записать в стек адрес своего кода, который при очередном return исполнится.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Воскресенье, 05 Январь, 2020 14:18 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Т.е., чтобы не говорить об этих указателях, нужно разобраться, а за счёт чего же именно это отображение файла в память даёт такой быстрый разбор?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Понедельник, 06 Январь, 2020 08:58 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
budden писал(а):
Т.е., чтобы не говорить об этих указателях, нужно разобраться, а за счёт чего же именно это отображение файла в память даёт такой быстрый разбор?
Из-за того, что не надо парсить значения (в случае бинарного представления).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Понедельник, 06 Январь, 2020 14:29 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
В общем-то, наверое, глупость я написал. В файле не может быть указателей, максимум там могут быть смещения, которые нужно "перелинковать" после загрузки файла в память. А если отличие в скорости за счёт бинарного формата, то тогда дело вообще в другом и с т.з. безопасности разницы особо нет. Хотя парсить нужно и бинарный формат, просто парсер может быть экстремально простым и поэтому быстрым.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Понедельник, 06 Январь, 2020 14:54 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
Так при отображении файла в память мы не используем файловые операции, а обращаемся напрямую к памяти. Поэтому нет тормозов в работе


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Понедельник, 06 Январь, 2020 15:03 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Т.е. у наc уже две версии :lol:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика Golang
СообщениеДобавлено: Понедельник, 06 Январь, 2020 15:11 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
budden писал(а):
Т.е. у наc уже две версии :lol:
какие версии? Достаточно посмотреть значение термина Отображение файла в память


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB