Здравствуйте, sergii.p, Вы писали:
SP>Классика. В одном потоке читаешь из контейнера обычным foreach, а во втором добавляешь/удаляешь элемент. Ловить проблему можно долго. Мьютексы ставить на каждый чих жаба давит. В 99,9% случаев всё работает. SP>Но это только с нубами случается конечно, не стоит переживать.
Здравствуйте, T4r4sB, Вы писали:
TB>Это та же мантра, что и у школьных кулхацкеров — они считают себя настолько скиловыми, что никогда не делают идиотских ошибок.
боясь словить data race или порчу памяти в общих для потоков объектах.
Это не идиотская ошибка.
Это показатель того, что автор не понимает, что вообще делает.
Здравствуйте, ArtDenis, Вы писали:
AD>Это не всегда получается когда нужен быстрый MVP. Уже потом в процессе написания продукта, архитектура будет постепенно улучшаться, а "дикая" многопоточка превратиться в обычную. Но на старте мне важно чтобы была возможность писать так, чтобы 1) писалось быстро без продумывания архитектуры, 2) работало как ожидается и 3) не падало на любой чих.
Любая "дикая" многопоточка в итоге приводит к одному из двух:
1. Провал проекта
2. Замене на многопоточку "нормальную"
Поскольку нормальная многопоточка — это почти всегда один из двух-трех стандартных паттернов разработки, нет никакой причины изобретать велосипед. Быстрее и дешевле сразу писать нормально.
S>Лучше ли одно действие чем два? S>Если нам нужно выполнить два действия вместо одного, то можно ли забыть второе? S>Можно ли между первым и вторым действиями со временем вставить что-то, что приведет к преждевременному return-у?
+100500
Самое главное, про что забывают, это то, что на скольно-нибудь живом проекте этот defer рано или поздно будет похерен при ручном мерже или просто в результате экспериментов. Не "может быть похерен", а именно будет, с вероятностью в 100%. С прохождением всех тестов и ревью.
И приведет к трудноотлваливаемому багу, который выстрелит через 20 релизов и который будут искать всем отделом несколько недель подряд, с перерывами только на туалет.
Здравствуйте, landerhigh, Вы писали:
L>И приведет к трудноотлваливаемому багу, который выстрелит через 20 релизов и который будут искать всем отделом несколько недель подряд, с перерывами только на туалет.
Здравствуйте, rameel, Вы писали:
L>>И приведет к трудноотлваливаемому багу, который выстрелит через 20 релизов и который будут искать всем отделом несколько недель подряд, с перерывами только на туалет. R>Это больше про C++
Вы ниасилили в плюсы?
Сочуствую. Там уже 30 лет как RAII есть.
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Константин Б., Вы писали:
КБ>>Конечно смогу КБ>>
КБ>>new std::ifstream("file.txt");
КБ>>
TB>И как ты сможешь это сделать случайно? TB>Ни один крестовик с хоть каким-то опытом не будет делать new для временного стекового объекта, это не требует внимательности.
Не один зиговик с хоть каким-то опытом не будет создавать временный стековый объект без defer на следующей строчке. 🤷🏿
Здравствуйте, Константин Б., Вы писали:
КБ>Не один зиговик с хоть каким-то опытом не будет создавать временный стековый объект без defer на следующей строчке. 🤷🏿
Я правильно понимаю, что необходимость явно деинициализировать временный стековый объект в 2023 году — это вот прямо офигеть какая инновация?
Здравствуйте, landerhigh, Вы писали:
L>Вы ниасилили в плюсы? L>Сочуствую. Там уже 30 лет как RAII есть.
Забавно, но с колупанием с неделю я почему-то все время наблюдаю обратную ситуацию, что бы там не говорили про RAII (фича классная не спорю), но в C++ до сих пор расстрелы и лики вещь не редкая, и наведенные ошибки с этим связанные, которые как ты выразился ищут неделями при чем без перерыва на туалет, в отличие от.
И не надо рассказывать про неосиляторов, когда под боком решают даже не заморачиваться с памятью и связанными с ними ошибками, ибо дорого, долго и нудно и не всегда успешно https://rsdn.org/forum/flame.comp/8596614.1
Если не ошибаюсь, разработчики PVS-Studio про свой анализатор рассказывали, что они такой подход эксплуатируют: мол, на анализ файла стартует новый процесс, в этом процессе память не освобождается, т.к. при работе это не нужно (да и сложно анализ реализовывать, т.к. при освобождении памяти висячие ссылки и протухшие указатели могут появится), а после работы вся память будет освобождена после завершения процесса.
Но конечно, это мы просто плюсы не осилили, у тебя таких проблем нет, ну а как иначе, профессионал ведь
Здравствуйте, rameel, Вы писали:
R>И не надо рассказывать про неосиляторов, когда под боком решают даже не заморачиваться с памятью и связанными с ними ошибками, ибо дорого, долго и нудно и не всегда успешно https://rsdn.org/forum/flame.comp/8596614.1
Вообще-то говоря, такая отсылка -- это аргумент из категории Рабинович напел.
Если ссылаться именно на опыт PVS-Studio, то тогда уже на первоисточник: https://pvs-studio.ru/ru/blog/posts/cpp/0916/
При этом Андрей Карпов несколько лет назад выкладывал в публичный доступ свои соображения о том, как следует программировать на С++. И, помнится, согласиться там можно было далеко не со всем (деталей, к сожалению, уже не помню).
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, Константин Б., Вы писали:
КБ>>Не один зиговик с хоть каким-то опытом не будет создавать временный стековый объект без defer на следующей строчке. 🤷🏿
L>Я правильно понимаю, что необходимость явно деинициализировать временный стековый объект в 2023 году — это вот прямо офигеть какая инновация?
Здравствуйте, Константин Б., Вы писали:
L>>Я правильно понимаю, что необходимость явно деинициализировать временный стековый объект в 2023 году — это вот прямо офигеть какая инновация? КБ>Нет, не правильно.
Тогда выходит, что имеем язык с принудительным закатом солнца вручную.
Здравствуйте, Разраб, Вы писали:
Р>https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo
Р>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++. Р>Все же работа с памятью создает большую когнитивную нагрузку. Р>Возможно после этого можно переехать проще на ziglang. Он в чем то похож. Р>и к тому же позволяет интегрироваться с си(++). Р>но раст реально просто. не так ли?
Нету исключений.
Я не понимаю как писать на языках без исключений. Приходится на каждом уровне забоититься о пробросе ошибок наверх.
По моему это какой то бред.
Исключения же дают возможность писать в стиле "happy path" не заморачиваясь об ошибках — обработчики ставятся на верхних уровнях.
Rust же предлагает вручную тащить это наверх самому. соответсвенно надо мержить эти ошибки вручную если на уровне отдаются разнотипные ошибки от разных API и вот это вот все.
Соответвенно разработчику предоставляется выбор — либо заниматься этим гемором с ошибками, либо вообще забивать иногда типа "я знаю здесь никогда не стрельнет"
Здравствуйте, iHateBrightVictories, Вы писали:
HBV>Здравствуйте, Разраб, Вы писали:
Р>>https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo
Р>>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++. Р>>Все же работа с памятью создает большую когнитивную нагрузку. Р>>Возможно после этого можно переехать проще на ziglang. Он в чем то похож. Р>>и к тому же позволяет интегрироваться с си(++). Р>>но раст реально просто. не так ли?
HBV>Нету исключений.
Есть panic, как исключения, только без раскрутки стека.
HBV>Я не понимаю как писать на языках без исключений. Приходится на каждом уровне забоититься о пробросе ошибок наверх. HBV>По моему это какой то бред.
В расте это делается одним символом в конце выражения.
HBV>Исключения же дают возможность писать в стиле "happy path" не заморачиваясь об ошибках — обработчики ставятся на верхних уровнях.
Именно так и работает panic handler
HBV>Rust же предлагает вручную тащить это наверх самому.
"Тащить" это громко сказано. Синтаксический оверхэед от "тащить" меньше чем от асинхронных вызовов. А вот мерж ошибок конечно доставляет.
HBV>соответсвенно надо мержить эти ошибки вручную если на уровне отдаются разнотипные ошибки от разных API и вот это вот все.
Для этого уже давно есть готовые либы, вроде anyhow
HBV>Соответвенно разработчику предоставляется выбор — либо заниматься этим гемором с ошибками, либо вообще забивать иногда типа "я знаю здесь никогда не стрельнет"
ИМХО проблема преувеличена. Это в Go с ошибками прям совсем все плохо, а в rust геморроя очень мало. В zig его изначально нет, так как есть anyerror изначально.
Современные языки способны делать нормальную обработку ошибок без исключений.
Здравствуйте, gandjustas, Вы писали:
G>А вот мерж ошибок конечно доставляет.
В большинстве случаев удаётся агрегировать низкоуровневые ошибки в высокоуровневые через крейт thiserror. Там всё это делается автоматом. А если не удаётся, я просто использую .map_err(...)
Здравствуйте, Константин, Вы писали:
К>Его изобрели для одной задачи — пилить web browser, и для этой задачи оно как раз уникально подходит.
Не уверен, что это соответствует действительности. Изначально язык появился как хобби-проект одного чувака и даже после того как Мозилла подключилась, язык претерпевал значительные изменения. Не похоже, что разработчики изначально чётко знали, что делали.
К>Для браузеров, безопасность кода — цель номер один.
Если бы это было так, то браузеры писали бы чём-то вроде Coq или Agda.
К> Плевать на usability, время компиляции, синтаксис из фильмов про пришельцев, время разработки
Это смотря с чем мы сравниваем. Языки с GC действительно много прячут под капот и это упрощает написание бизнес-логики, но заменять растом джаву как-то странновато. А если сравнить с С++, то по этим параметрам можно поспорить.
Здравствуйте, iHateBrightVictories, Вы писали:
HBV>Здравствуйте, Разраб, Вы писали:
Р>>https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo
Р>>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++. Р>>Все же работа с памятью создает большую когнитивную нагрузку. Р>>Возможно после этого можно переехать проще на ziglang. Он в чем то похож. Р>>и к тому же позволяет интегрироваться с си(++). Р>>но раст реально просто. не так ли?
HBV>Нету исключений. HBV>Я не понимаю как писать на языках без исключений. Приходится на каждом уровне забоититься о пробросе ошибок наверх. HBV>По моему это какой то бред. HBV>Исключения же дают возможность писать в стиле "happy path" не заморачиваясь об ошибках — обработчики ставятся на верхних уровнях.
HBV>Rust же предлагает вручную тащить это наверх самому. соответсвенно надо мержить эти ошибки вручную если на уровне отдаются разнотипные ошибки от разных API и вот это вот все. HBV>Соответвенно разработчику предоставляется выбор — либо заниматься этим гемором с ошибками, либо вообще забивать иногда типа "я знаю здесь никогда не стрельнет"
В зиге вроде и ошибки и перехват в одном флаконе. https://ziglang.org/documentation/0.8.0/#Errors
Но конечно самое крутое это в коммон лисп. там не только исключения но и сигналы и перезапуски. полнейший хаос.
Здравствуйте, DarkEld3r, Вы писали:
DE>язык появился как хобби-проект одного чувака
Этот чувак в тот момент работал в Mozilla Research, и рисёрчил там, как лучше пилить веб браузеры.
DE>Если бы это было так, то браузеры писали бы чём-то вроде Coq или Agda.
Обе этих штуки какой-то bullshit для математиков.
Браузеры не имеют отношения к математике или доказательству теорем.
Зато им необходимы практически все API операционных систем, которые в них вообще есть: многопоточность, стек TCP/IP, 3D GPU, Bluetooth, потоковое видео и аудио и кодеки для них, захват экрана, криптография, и много остального.
Интересно, что-то из перечисленного легко использовать из Coq или Agda?
BTW, одно лишь обилие ввода/вывода в браузерах делает FP языки плохо подходящими для такого.
DE>Языки с GC действительно много прячут под капот и это упрощает написание бизнес-логики, но заменять растом джаву как-то странновато. А если сравнить с С++, то по этим параметрам можно поспорить.
Следует учесть, что каких-то 25 лет назад на C++ делали вообще всё: веб приложения, мобильные приложения, десктопные приложения, бизнес-логику, и всё остальное тоже.
Поскольку разработка сложного ПО очень дорогое удовольствие, довольно много людей до сих пор используют С++ по инерции, несмотря на то что в современном мире более высокоуровневые языки подходят для такого лучше.
https://rsdn.org/forum/flame.comp/8596614.1
