Есть разные варианты каждый случай индивидуален.
Если мы смотрим crash dump, то в простейшем случае call stack нам покажет именно то место где упало. Примерно так же можно поступить если дамп записан по тригеру «зависание».
Если мы пишем дамп по тригеру загрузки процессора, да ещё и пишем эти дампы серией (после срабатывания тригера пишем n дампов, через каждые x секунд), то можно посмотреть какая нить в каком месте застряла.
Аналогично можно поступить с тригером потребления памяти.
Описанные способы конечно не 100% работают, но шанс есть (и иногда за него хватаешься как за соломинку).
А ещё из дампа можно извлечь специфичную для приложения/фреймворка информацию, например если мы отлаживаем дамп рабочего процесса iis, то можно посмотреть (например) какие запросы выполнялись в момент снятия дампа и как долго.
Несколько вариантов:
1) Можно использовать подход Xamarin`а: пишем общую логику на Rust, а GUI реализуем нативно.
2) Если нам не нужно поддерживать старые платформы, то можно использовать гибридный подход: использовать для отрисовки стандартную для платформы WebView, а код отрисовки и логику напишем на Rust.
3) А что собственно не так с Qt, на мой взгляд этот тот самый «нормальный кроссплатформенный GUI фреймворк»
А мне наоборот кажется что на данный момент windows это стабильная качественная платформа для большого спектра, намного лучше чем была лет 10-15 назад. И те причины что подталкивали людей раньше искать альтернативу, сейчас во многом не актуальны.
иногда бывает что код который компилировался нормально в прежней версии ts, в новой не компилируется. Но обычно для исправления нужно обновить несколько строк в кодовой базе. В целом breaking changes бывают, но команда старается их избегать или как-то минимизировать проблемы с ними (советы, ключи компилятора...).
>> Большинство разработчиков используют MacOS или Linux.
Очень спорное утверждение, я, мои коллеги и почти все разработчики с которыми я знаком используют windows. А разработкой ПО я занимаюсь около 13-ти лет.
До сих пор мы, работая с JS-функциями, ожидали, что они, будучи вызванными, просто выполняются от начала до конца
Ну и что? А теперь появился новый вид функции. Если чего-то раньше не было, значит никогда это не использовать?
Ссылки на async/await на мой взгляд притянуты за уши. Да когда не было async/await можно было писать aync/await-образный код при помощи генераторов, но вообще они не об этом.
Генератор это вещь которая может вернуть коллекцию чего-то без предварительного выделения памяти под коллекцию, в том числе коллекция может быть бесконечной.
В других языках подобные конструкции есть давным давно, используются например для получения информации из БД.
Другой пример при помощи генератора можно создавать интерфейс для итерации по нескольким существующим коллекциям.
Я проблем не заметил. Люди говорят тимлид и прóдукт в реальной жизни.А вы предлагаете писать «лидер команды» и «товар», чтоб формально было грамотно, но никто ничего не понял?
из-за таких намерений появляются книги «Исскуство автономного тестирования» (вместо искусство unit тестирования).
И, по моему скромному мнению главная проблема async/await — это try/catch hell с бесконечными unhandled promise rejection, который может возникнуть, например, если разработчики не договорились на каком уровне эти ошибки обрабатывать.
Ну если разработчики не договорятся на каком уровне обрабатывать ошибки, то в синхронном коде у них будет такая же проблема, так что это не проблема async/await.
Вот оже самое хотел написать, статья абсолютно бестолковая. «Беда await ждёт пока завершится асинхронный вызов, не даёт перейти к следующей строке», так в этом этом его суть! Он так и должен работать. Если у кого-то с этим проблемы, то нужно учить его читать спецификацию, а не писать бестолковые жёлтые статьи.
Ну во первых, зато нам доступен finnaly.
А во вторых вообще претензия не понятно, try catch стандартная конструкция js, которая десятки лет используется для синхронного кода. Если она плоха, то претензия к синтаксису js, более старому чем async/await.
Но вообще-то всё было сложнее. Мы писали на си, где шаг влево, шаг в право это расстрел и всё что ты видишь это «segmentation fault». И у нас не было resharper`а который исправит твои мелкие ошибки в синтаксисе, автоматически подключит недостающие билиотеки. Компилятор, текстовый редактор и развлекайся как хочешь.
Но вообще задач с файлами полно, особенно их много в университетских лабораторных. Про работу с файлами всегда пишут в книгах "<язык программирования> для начинающих".
Так что если человек понятия не имеет как работать с файлами то не понятно что он читал и что делал в университете.
В конце концов если он не помнит конкретных методов, то пусть продемонстрирует как их найти.
Мне очень нравится как вы меня постепенно посвящаете в контекст вашего кода, то masters вдруг Set, то функция часто вызывается, да ещё и рекурсивно… Я блин откуда это знаю!?
Я ставил перед собой задачу написать более читаемый код, который делает тоже самое. Оптимизация это отдельная задача выполняемая по необходимости.
Вы бы вообще над дизайном класса подумали, почему например метод .value() меняет поля чужого класса? Может ему лучше возвращать данные и плевать исключения в случае ошибки, тогда вопросов как написать красивый код будет меньше?
Мотать глазами не надо, спокойно можно читать сверху вниз. (даже после фикса проверки поля status, const self = this;… self.staus === «checked» )
Кстати конвертацию Set`а в массив наверняка js движок оптимизирует и лишняя память не будет выделена. Вызов метода наверное заинлайнится, так что стек не вырастит.
Если мы смотрим crash dump, то в простейшем случае call stack нам покажет именно то место где упало. Примерно так же можно поступить если дамп записан по тригеру «зависание».
Если мы пишем дамп по тригеру загрузки процессора, да ещё и пишем эти дампы серией (после срабатывания тригера пишем n дампов, через каждые x секунд), то можно посмотреть какая нить в каком месте застряла.
Аналогично можно поступить с тригером потребления памяти.
Описанные способы конечно не 100% работают, но шанс есть (и иногда за него хватаешься как за соломинку).
А ещё из дампа можно извлечь специфичную для приложения/фреймворка информацию, например если мы отлаживаем дамп рабочего процесса iis, то можно посмотреть (например) какие запросы выполнялись в момент снятия дампа и как долго.
1) Можно использовать подход Xamarin`а: пишем общую логику на Rust, а GUI реализуем нативно.
2) Если нам не нужно поддерживать старые платформы, то можно использовать гибридный подход: использовать для отрисовки стандартную для платформы WebView, а код отрисовки и логику напишем на Rust.
3) А что собственно не так с Qt, на мой взгляд этот тот самый «нормальный кроссплатформенный GUI фреймворк»
Бюрократия постепенно начнётся при количестве сотрудников > 15-25 человек и чем больше, тем бюрократистее.
Нона одной из первых работ разработка велась в window, под linux.
Очень спорное утверждение, я, мои коллеги и почти все разработчики с которыми я знаком используют windows. А разработкой ПО я занимаюсь около 13-ти лет.
Ну и что? А теперь появился новый вид функции. Если чего-то раньше не было, значит никогда это не использовать?
Ссылки на async/await на мой взгляд притянуты за уши. Да когда не было async/await можно было писать aync/await-образный код при помощи генераторов, но вообще они не об этом.
Генератор это вещь которая может вернуть коллекцию чего-то без предварительного выделения памяти под коллекцию, в том числе коллекция может быть бесконечной.
В других языках подобные конструкции есть давным давно, используются например для получения информации из БД.
Другой пример при помощи генератора можно создавать интерфейс для итерации по нескольким существующим коллекциям.
из-за таких намерений появляются книги «Исскуство автономного тестирования» (вместо искусство unit тестирования).
Ну если разработчики не договорятся на каком уровне обрабатывать ошибки, то в синхронном коде у них будет такая же проблема, так что это не проблема async/await.
А во вторых вообще претензия не понятно, try catch стандартная конструкция js, которая десятки лет используется для синхронного кода. Если она плоха, то претензия к синтаксису js, более старому чем async/await.
Так что если человек понятия не имеет как работать с файлами то не понятно что он читал и что делал в университете.
В конце концов если он не помнит конкретных методов, то пусть продемонстрирует как их найти.
Я ставил перед собой задачу написать более читаемый код, который делает тоже самое. Оптимизация это отдельная задача выполняемая по необходимости.
Вы бы вообще над дизайном класса подумали, почему например метод .value() меняет поля чужого класса? Может ему лучше возвращать данные и плевать исключения в случае ошибки, тогда вопросов как написать красивый код будет меньше?
Мотать глазами не надо, спокойно можно читать сверху вниз. (даже после фикса проверки поля status, const self = this;… self.staus === «checked» )
Кстати конвертацию Set`а в массив наверняка js движок оптимизирует и лишняя память не будет выделена. Вызов метода наверное заинлайнится, так что стек не вырастит.