Здравствуйте, T4r4sB, Вы писали:
TB>А, я понял. Тогда одна из проблем снимается. Но остается "почему тут вывелся не тот тип который как мне казалось тут должен появиться". Разумеется такое бывает и в Расте и в С++, но только у тех кто злоупотребляет шаблонами.
Да, такое есть. Но в С++ это всё осложнено громоздкими построениями, т.к. доступные в других языках из коробки вещи приходится конструировать из палок и верёвок. (Кстати, почти тем же грешит и TS — там особо вывернутые конструкции тоже выдают нечитаемые ошибки, если напороть в коде).

Здравствуйте, T4r4sB, Вы писали:
TB>Я разрабатывал язык в котором по умолчанию любая функция шаблонная, которая по контексту определяет какие у неё параметры, сколько их и что она возвращает. Так вот это полный треш когда изменение в одной функции по цепочке приводило к тому, что компилятор что-то своё додумал в другом файле проекта и по итогу в лучшем случае ошибка компиляции, в худшем просто хрень выводится.
TB>А ещё малозаметные проблемы когда компилятор из-за незначительных нюансов для двух наборов параметров навыводил разные перегрузки (ну типа в одном случае он решил передавать копию потому что объект временный, а в другом ссылку), и в бинарнике появляются две почти одинаковые функции. Раздувание бинарника на пустом места.
TB>В языке был механизм явно указывать сигнатуру, который изначально был нужен лишь для экспорта функций. Но на деле оказалось что всю бизнес-логику тоже намного проще писать явными сигнатурами, потому что тогда компилятору меньше работы, и если он что-то понял не так, то он сообщает об этом максимально близко к источнику проблемы.
Кстати, есть отдельный набор вопросов, не относящихся к теме топика, про ваш язык и опыт его разработки.
1. Есть ли где-то публичное описание этого языка?
2. Поверх чего он исполняется (JVM, WASM, натив)?
3. Компилятор или интерпретатор?
4. Каким тулчейном вы пользовались при его разработке? Языки программирования, библиотеки/фреймворки для парсинга/семантического разбора?

Здравствуйте, ononim, Вы писали:

TB>>Я так понимаю, если промежуточная операция не удалась, то весь остальной код продолжает работать как ни в чём не бывало, и лишь операции с тем же FacilityID перестают выполняться? Звучит сомнительно
O>Почему сомнительно? Зачем проверять что операция не удалась на каждом ее этапе, если в принципе ничего не измениться если я это проверю только тогда, когда мне нужно определиться с ее финальным статусом? В большинстве случаев это вполне допустимо. В данном случае — ну не удалось сохранить файл, покажем юзеру мессагу он ткнет ретрай и сохраним еще раз, или отмену. Что даст осознание факта неудачи прям в тот самый момент? Даст лишь +100500 строк проверки на код ошибки если у нас сериализация здорового объекта. Такая вот крайность. Исключения — это можно сказать противоположная крайность. Истина — она всегда посередине.
Юзеру показывать классическое https://en.wikipedia.org/wiki/Abort,_Retry,_Fail%3F ? Извините, наелись ещё четверть века назад. В первую очередь исключения и обработка ошибок — это головняк программиста. А программисту нужна вся информация о проблеме, как можно больше. Поэтому чем раньше и точнее будет обнаружено место ошибки, тем лучше. Это в твоём примере 3 строчки и помедитировав, наверное, можно будет понять или случайно угадать где же оно навернулось. А в более менее реальном проекте таких строчек будет сотни, разнесённых по десяткам функций и файлов.

Здравствуйте, Sinclair, Вы писали:

S>Кстати, есть отдельный набор вопросов, не относящихся к теме топика, про ваш язык и опыт его разработки.
S>1. Есть ли где-то публичное описание этого языка?
S>2. Поверх чего он исполняется (JVM, WASM, натив)?
S>3. Компилятор или интерпретатор?
S>4. Каким тулчейном вы пользовались при его разработке? Языки программирования, библиотеки/фреймворки для парсинга/семантического разбора?

Попробую ответить на всё сразу. Нормального описания при мне не было, язык мог внезапно измениться на уровне работы базовых бильтинов, при этом мы всей командой тратили день на адаптацию кодовой базы.
При разработке использовали компилятор, написанный на нём же самом. Вернее это был транслятор в текстовый LLVM-IR. Исходники старой версии тут: https://github.com/Matway/mpl-c/tree/master
Язык стековый как Форт. То есть обратная польская запись, стек сущностей, ну и все функции описываются как операции над стеком. Поэтому у него очень маленький синтаксис и минимальный набор конструкций. Очень важно что стек есть лишь при компиляции.
Базовые сущности языка — это числа, строки, блоки кода, анонимные кортежи, именнованные кортежи, и все они могут быть положены в виртуальный стек, который существует лишь на этапе компиляции. Ещё есть слова. Всё остальное строится из них. Любое слово производит какие-то манипуляции над "стеком времени компиляции". Например, слово if со стека снимает булевую переменную и два блока кода, а кладёт результат выполнения блоков кода. При этом если компилятор не может вычислить условиe if то он считает его динамическим и требует чтобы блоки кода одинаково действовали на стек — ну иначе стек станет частью рантайма. Для циклов тоже есть аналогичное требование, что если цикл "динамический" то он должен сохранять стек.
Можно заводить переменные, само собой. Причём переменная может быть блоком кода и передана куда-то в другую функцию. И это на самом деле основной способ задания функций в языке.
Язык позволяет делать адскую метушню, например написать функцию switch, которая принимает анонимный кортеж, в котором по очереди идут блоки кода и константы (например

(1 [doSmth1] 2 [doSmth2]) condVar switch

), и прямо в процессе компиляции превращает его в лесенку ифов

condVar 1 = [
  doSmth1
] [
  condVar 2 = [
    doSmth2
  ] [
  ] if
]

которая оптимизаторов шланга превращается в честный свич

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

foo: [ a: b: ;; // снять со стека две сущности и завести локальные переменные
  a 1 = [
    c:; // снять со стека ещё сущность
  ] [] if
];

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

Так вот, если вызвать код так:

1 2 3 foo // первая переменная 1, поэтому создастся инстанс foo который жрёт 3 аргумента
2 3 foo // первая переменная на 1, поэтому создастся инстанс foo который жрёт 2 аргумента
i: 42 dynamic; // создаём переменную i в которой лежит 42 и просим компилятор не делать с ней никаких вычислений времени компиляции
i 2 3 foo // а тут компилятор пытается создать инстанс для foo у которого первый аргумент неизвестен при компиляции. Правда в данном случае это не получится, потому что внутри находится иф, у которого разные ветки по-разному действуют на стек. Так что будет ошибка компиляции

Ну и это вот слово dynamic на самом деле приходилось пихать везде, кроме того 1% кода где реально нужна метушня. Потому что мне похрен на то, что статически известное значение аргумента позволит развернуть один из внешних циклов, даже близко не влияющих на производительность. Зато компилятор будет дольше страдать компилируя нахрен не нужный инстанс, это раздует бинарник, зачем оно.
В целом язык прикольно поиграться, но для больших проектов не подходит ну ваще никак.
Причём часть проблем являются принципиальными и более лучший умный компилятор их не решит. И часть из них я называл ранее. А ещё из-за шаблонности всего-всего ни о каком нормальном автодополнении не может быть и речи. То есть после вызова другой функции ты не имеешь никакого представления что у тебя лежит на стеке, и куда дальше пойдёт выполнение и какие ветки проигнорятся. И чтобы это узнать, надо полностью проанализировать вызываемую функцию. Из-за этого крайне сложно делается рекурсия для функций у которых непонятно какой тип возвращаемого результата, потому что если функция вызывает саму себя, то для того чтобы понять, что дальше вообще лежит на стеке после вызова, надо проанализировать полностью всё тело этой функции, но мы же как раз находимся в процессе. Приходилось делать "полускомпилированные функции" у которых есть "предположительный тип результата" и на основе этого предположения компилировать функцию ещё раз и доходить до "неподвижной точки".
А с автодополнением в лучшем случае студия выдаст просто список ВСЕХ методов всех объектов видимых из этого файла.
Ну и раздельная компиляция идёт нафиг, потому что изменение тела одной функции может внезапно повлиять на компиляцию чего угодно в любом другом файле.

·>Юзеру показывать классическое https://en.wikipedia.org/wiki/Abort,_Retry,_Fail%3F ? Извините, наелись ещё четверть века назад.

Точно! Зато как хорошо стало сейчас! Выбор из двух вариантов: "Something went wrong" (сам догадайся нажать F5) или "pending" (где-то там оно ретраит, и сколько еще будет — неизвестно).

Здравствуйте, Shmj, Вы писали:

S>Ну вот рекомендации в новомодных языках: https://docs.flutter.dev/app-architecture/design-patterns/result

S>- все-таки топят за Result objects для бизнес-логики.

S>А ведь это всю цепочку поддерживать. Как-то много лишних букв добавляется.

S>Но! Exception как бы не определены в контрактах. Если ResultObject — это контракт, его понятно что нужно проверить и компилятор даже контролирует эту проверку. А Exception разве что в документации описан, которую могут не читать.

S>А ведь было же хорошее решение — т.н. проверяемые исключения в Java. Когда компилятор требовал проверки того или иного исключения, но так же была возможно обернуть в RuntimeException, если оно утратило смысл бизнес-логики или ожидаемого

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

Это все потому, что каждое новое поколение придумвает свои костыли для сетевого взаимодействия.
Сначала были всякие бинарные протоколы, потом майкрософт сделали DCOM/CORBA, там же появились всякие ESB и очереди сообщений, а потом распространение http(s) привело к тому, что все везде использует http(s) тулы и соотвественно коды возвратов ошибок.

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

Здравствуйте, Sinclair, Вы писали:

S>OOM-Killer — это следствие криворукой архитектуры линукса. Программы под винду пишутся на тех же С/С++, но при этом там нет (и не нужно) никакого OOM-Killer.

OOM-Killer это лучшее что можно сделать если кто-то пережрал памяти. Я очень сильно страдаю на домашней винде из-за того, что в винде его нет.
Тупая винда вводит в состояние комы всю систему нахрен вместо того, чтобы убить один процесс, это может быть браузер, в котором чисто случайно uBlock затупил на рекламном блоке, это может быть моя программа, в которой я неверно задал параметры модели.
В гугле по запросу "Windows OOM Killer" выводится "он там не нужен потому что там очень умная система выделения памяти". Тухлая лапша из говна, чтоб вешать лохам на уши. Я с завидной регулярностью ощущаю, как он якобы "не нужен".

Причём тупорылые дауны из микрософта до сих пор сука не догадались сделать сочетание Ctrl+Alt+Delete самым приоритетным, которое сразу останавливает нахрен всё и выводит диспетчер в максимально экономном режиме.

Здравствуйте, T4r4sB, Вы писали:
TB>OOM-Killer это лучшее что можно сделать если кто-то пережрал памяти. Я очень сильно страдаю на домашней винде из-за того, что в винде его нет.
TB>Тупая винда вводит в состояние комы всю систему нахрен вместо того, чтобы убить один процесс, это может быть браузер, в котором чисто случайно uBlock затупил на рекламном блоке, это может быть моя программа, в которой я неверно задал параметры модели.
TB>В гугле по запросу "Windows OOM Killer" выводится "он там не нужен потому что там очень умная система выделения памяти".
Всё верно написано.
TB>Тухлая лапша из говна, чтоб вешать лохам на уши. Я с завидной регулярностью ощущаю, как он якобы "не нужен".
Хм. У вас, очевидно, талант. Я на домашней винде в последний раз видел что-то подобное настолько давно, что и не помню.
Подозреваю, что вы можете улучшить ситуацию, сняв галочку "Allow system to manage page file size".
И я очень сомневаюсь, что в линуксе в аналогичной ситуации вам бы помог OOM-киллер.

TB>Причём тупорылые дауны из микрософта до сих пор сука не догадались сделать сочетание Ctrl+Alt+Delete самым приоритетным, которое сразу останавливает нахрен всё и выводит диспетчер в максимально экономном режиме.
Я обычно просто нажимаю Ctrl-Shift-Esc.

Здравствуйте, Sinclair, Вы писали:

S>Я обычно просто нажимаю Ctrl-Shift-Esc.

Да, это сочетание я тоже знаю. Но оно не работает потому что система отчаянно трещит пытаясь запихать в своп мою модель, ролик с ютубаю, менеджер полупрозрачных окошек и прочую хрень, которая уже не нужна, ведь важнее выживание системы. Но вызов диспетчера плетется где-то там в конце общей очереди. Зачем давать диспетчеру высший приоритет, пусть пользователь помучается!
Так вот нет в винде никакого умного менеджера. Есть кучка педерастов решивших что они за пользователя лучше знают что ему нужно.
А в Линуксе я регулярно ловлю смерти по OOM. Как бы ты не вылизывал код, заказчик будет скармливать ему всё большие и большие объёмы данных, это нормально. И смерть одного процесса лучше чем смерть всей системы.

Здравствуйте, T4r4sB, Вы писали:
TB>Да, это сочетание я тоже знаю. Но оно не работает потому что система отчаянно трещит пытаясь запихать в своп мою модель, ролик с ютубаю, менеджер полупрозрачных окошек и прочую хрень, которая уже не нужна, ведь важнее выживание системы. Но вызов диспетчера плетется где-то там в конце общей очереди. Зачем давать диспетчеру высший приоритет, пусть пользователь помучается!
Ну так дайте ему высший приоритет руками. Он же у разработчиков всё равно стоит в автостарте системы.

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

Ещё на всякий случай напомню, что основное, для чего нам нужна борьба с ООМ — это не десктоп (при его штатном использовании ООМ не случается примерно никогда, а когда случается — есть интерактивные способы вмешаться в события), а сервер. Где нет никакого таск менеджера и Ctrl-Shift-Esc.

Здравствуйте, SkyDance, Вы писали:

SD>·>Юзеру показывать классическое https://en.wikipedia.org/wiki/Abort,_Retry,_Fail%3F ? Извините, наелись ещё четверть века назад.

SD>Точно! Зато как хорошо стало сейчас! Выбор из двух вариантов: "Something went wrong" (сам догадайся нажать F5) или "pending" (где-то там оно ретраит, и сколько еще будет — неизвестно).
Сейчас это результат работы программистов, рисующих catch с пустым телом. А тут предлагается такое в дизайн яп и библиотек. Так что даже если захочешь сделать по-человечески, то вообще никак не сможешь.

Здравствуйте, Sinclair, Вы писали:

S>Подозреваю, что вы можете улучшить ситуацию, сняв галочку "Allow system to manage page file size".

Проверил, работает, но теперь Старкрафт не запускается
А зачем некоторые говнокодеры требуют своп даже когда оперативы хватает? Это связано с тем, что они на старте выделяют 100500 гигабайт памяти, но используют не всё? Тогда это фигня, линуксовый OOM killer срабатывает именно когда используемой памяти не хватает

А оно настраивается чтоб именно Старкрафту разрешили в своп лазать?

Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Sinclair, Вы писали:
TB>Проверил, работает, но теперь Старкрафт не запускается
TB>А зачем некоторые говнокодеры требуют своп даже когда оперативы хватает? Это связано с тем, что они на старте выделяют 100500 гигабайт памяти, но используют не всё? Тогда это фигня, линуксовый OOM killer срабатывает именно когда используемой памяти не хватает
Откуда вы знаете, что они "используют не все"? Может быть, программа в какой-то момент собирается "использовать все", просто вы не попадаете в этот сценарий.
Во-вторых — да, бывают говнопрограммы, которые запрашивают "с запасом" без веских причин.
Но разработчиков должно интересовать не это, а то, что можно иметь некоторые гарантии от ОС. Если винда выдала мне память, то у меня есть гарантия, что при необходимости я эту память реально получу. А не привет от oom killer в самый неподходящий момент (например, когда я ещё не завершил ввод/вывод.

TB>А оно настраивается чтоб именно Старкрафту разрешили в своп лазать?
Нет. И вообще, понятие "лазать в своп" не отражает реальную картину.
Более конструктивный способ думать об этом — считать память эквивалентной диску.
См. например ответ Липперта на смежный вопрос.
Если Старкрафт перестал запускаться — значит, ему нужно больше виртуальной памяти, чем вы накрутили в настройках. Просто увеличьте размер своп-файла так, чтобы ему хватало.
Если всё ещё не хватает — значит, при запуске в "неограниченном" режиме он как раз положит вашу систему на лопатки, пытаясь откусить себе ещё больше свопа.

Здравствуйте, Sinclair, Вы писали:

S>Откуда вы знаете, что они "используют не все"? Может быть, программа в какой-то момент собирается "использовать все", просто вы не попадаете в этот сценарий.

Потому что я играл в Старкрафт и примерно знаю сколько он жрёт

S>Если Старкрафт перестал запускаться — значит, ему нужно больше виртуальной памяти, чем вы накрутили в настройках.

Программа может в своём воображении иметь сколько угодно много виртуальной памяти, пока не понадобилась физическая страница для работы с ней. В Линуксе OOM Killer работает на резидентную память (я верно назвал?), а в винде — сразу на виртуальную? Чето говно какое-то неюзабельное