Къде е Ръждата?!

Здравейте!

От край време си мисля, че искам да си имам open source проект. От няколко месеца съм се запалил по Ръждата, та реших, че да си припомня детските си хобита да си пиша малки game engine-чета е страхотен повод да публикувам малко код. Тази тема разбира се я отварям понеже се оказа, че няма лесен начин да force-неш Google да ти индексира repo-то, та все от някъде трябва да се scrape-не линка

TwoRS (https://github.com/vimlucid/twors) - като Three.js, но вместо 3D графики ще се ползва за render на 2D графики и вместо JavaScript ще се пише на ... RUST!

Сега то реално няма какво да се рекламира, понеже `licenses.html` в момента е 80% от проекта ... та с тая тема имам и втори пъклен план - като един истински Rust zealot съм длъжен да почукам на вратата и да питам дали имате време за нашия спасител...

Та да си питам директно - защо никой не приказва за туй прекрасно нещо?
- Скапаните exception-и са разкарани... няма да се чудя кат' ненормален отде ще ми хвърли нещо...
- Няма наследяване ... oh thank god - не че не може всичко да се abuse-не ако има желание човек, ама друго си е да не ми тръгват по default да ми couple-ват интерфейс и състояние зарад' code reuse... и да лъжат че енкапсулират, пък аз от единия край го подбутна, а от другия всичко се срине..
- Билд системата... ей като видя cmake и пуфкам... то зависи колко е усложнен де, ама що тря' се стига до там да се мисли...
- Като говорим за липса на мисъл - леле колко е яко всичкия Rust код да е еднакъв... има си едни идиоматики и изобщо не държа да се чувствам като голям човек с тоя C++ - решенията са взети и 99% от случаите вървиш със стадото - дефиницията на продуктивност
- Типовата семантика... леле с тоя език целия свят можеш да закодираш в тип... и си задължен! Ся... някой път да extract-неш нещо в отделен метод ти се свиди щото само сигнатурата може да стигне 3 реда, ама има начини да се митигира - просто истинска вяра трябва!
- Safety-то - не ви знам що всички се хвалят, че много добре си пишат на С++, а като почнат segmentation fault-овете и race condition-ите и UB дето като почнат да гърмят у продъкшън веднъж на месечина и с кристална топка немой ги излови ... по-добре веднъж на месечина да пускаш PR, ама да знаеш, че работи... а то като му свикнеш от Microsoft докладват, че Rust екипите стават най-продуктивните екипи...

Ся... има си малко тегавинка... малко процедурни макросчета да се свикнат... малко borrow checker-а да ти покаже, че е глупавичък, та да му угодиш на горкия... малко интерфейсване със С++ или нещо друго, та да кажеш здравей на cross-boundary memory management-a и бойлерплейта за байндингите... но тук вярата ще ти бъде тествана!

тука имаше и други ръст зилоти, може да намерите приказка, мене отдавна търсенето на "по-добър език" не ме вълнува и си пиша на каквото има. както каза бабоеба от другия форум "всичкия софтуер е лайно", все тая на какъв език пишеш лайното.

Леле, you made my morning... Някой не е прав в Интернет

Ъхъ, и сега пък като гламав ще трябва на всеки ред проверявам дали нещо някъде не ми е върнало грешка. Едно време и аз така мислех за изцепшъните ама на дърти години престанах да се страхувам и заобичах бомбата. Просто трябва да се помни, че изключенията са за изключителни събътия а не за връщане на различни типове резултат.

Сериозно? И как ще си направя иерархията Shape -> Circle и Shape - >Rectangle. Питам сериозно. И в С няма наследяване и ако трябва да се прави като там - не, мерси, по-добре да има наследяване. Пък и не разбирам връзката между наследяването и тръгването... Това вероятно е за модерните езици като JS, където чак в рънтайм разбираш (и то ако внимателно гледаш дебъг конзолата), че ей тука трябваше да овърайднеш ей тоз метод, ама кой да ти каже, че трябва.

Не знам с кой език сравняваш , но ако говорим за С/С++ - там *няма* билд система като част от езика. За какво ти е, нали можеш да напишеш cc a.c b.c c.c и да си получиш a.out. После са се усетили и изсраха маке и неговите табулации. Но ако не им обръщаме внимание и не ползваме интервали в имената на файловете, много си е хубав маке-а. И не на последно място, хайде пак да обсъдим въпросът след 50 години. Убеден съм, че за това време ще се намери някой, дето няма да му хареса нещо в билд системата и ще направи своя... "имаме 14 стандарта..."

Това не го разбрах, но ако ти харесват такъв тетип ограничения, Питон е твоят избор - ще са ти еднакви дори идентите.

Дори да приемем, че езика *има* тип int и ми *забранява* да го ползвам директно (т.е. да ме *кара* да си дефинирам свой тип задължително) нищо няма да ми попречи да си направя свой си тип Integer или GoliamoChislo и да си ги ползвам навсякъде.

Да чукна на дърво, аз segmentation fault не съм причинявал от години. А пък за race condition ще поискам нагледен пример, щото дори не мога да си представя как *езика* може да го следи. Всъщност мога - ако те *задължава* да ползваш всички библиотеки на като сорс и/или нещо създадено именно с този компилатор, което значи, че нямаме никакви странични библиотеки. Пък и дори при тези условия, пак не съм сигурен, че може - за да е сигурно, ще трябва да мине по всички *комбинации* от разклоненията в кода, просто ще е *ужасно* бавно. То за борбата с race condition е достатъчно да не локваш повече от един примитив наведнъж, проблемът е, че това не винаги е възможно...

Това мнение е било редактирано от dvader на 25-04-2025, 07:15

Ъхъ, и сега пък като гламав ще трябва на всеки ред проверявам дали нещо някъде не ми е върнало грешка. Едно време и аз така мислех за изцепшъните ама на дърти години престанах да се страхувам и заобичах бомбата. Просто трябва да се помни, че изключенията са за изключителни събътия а не за връщане на различни типове резултат.

Аз пиша ембедед Ц, някъде 90% от времето, за АРМ Кортекс-М. Рънтайма който се използва - Newlib nano, е компилиран без поддръжка на изцепшъни и всеки такъв в крайна сметка стига до фукция _exit(), която, ако не си я заменил е просто безкраен цикъл или място дето се рестартира МЦУ-то.

За проверка за грешки се използва прост контракт за писане на функции - връща се int който е 0 ако всичко е наред и съответен макрос за да не пишеш много.

Лошо няма, за различни use cases си има различни инструменти.
Остава само въпросът защо се налага *ти* да проверяваш за код на грешка - можеше просто функцията, която ти го връща сама да си викне exit...

В контекста на темата, това което описваш би се равнявало на "функциите не връщат резултат, ако има грешка трябва да викнеш exit()". Съгласи се, изглежда странно като изискване.

И не на последно място, защо пък макрос? Макроса има смисъл ако ще правиш return, ако ще викаш exit може да си направиш функция CHK_ERR.

Това мнение е било редактирано от dvader на 25-04-2025, 08:37

_exit е аврийна ситуация, която НЕ ТРЯБВА да възниква. Функцията връща резултат за да не се изполват "магически" стойности за да индикират грешка. Истинските резултати се записват през указтели.

Това е макроса:

защото няма такова нещо като "изключение", всички ексепшъни са нормални клонове на изпълнение и не бива да се третират като нещо необичайно. не може да се отвори файл? това е нормална част от ежедневието, не е изключение. ще кажеш ок, нека е така, но механизма на ексепшъните да се ползва за тая цел. мерси, не ща. ексепшъните "телепортират" точката на изпълнение затова са зло. аз ползвам дори още по-примитивен механизъм за контрол - не връщам кодове за грешки, а само да/не. грешките се пишат в лога като човешки текст. не проверявам на всяка функция за грешка, а само на водещите. примерно ако пиша във файл, само на първото писане или на последното, според ситуацията, остаалите майната им.

Аз ги превръщам в текстов код, иначе се предават кото int32_t


Прикачена картинка (Кликнете на картинката, за да я увеличите!)

Иначе пък в тестовете се проверява всичко:


Прикачена картинка (Кликнете на картинката, за да я увеличите!)

защото няма такова нещо като "изключение", всички ексепшъни са нормални клонове на изпълнение и не бива да се третират като нещо необичайно. не може да се отвори файл? това е нормална част от ежедневието, не е изключение. ще кажеш ок, нека е така, но механизма на ексепшъните да се ползва за тая цел. мерси, не ща. ексепшъните "телепортират" точката на изпълнение затова са зло. аз ползвам дори още по-примитивен механизъм за контрол - не връщам кодове за грешки, а само да/не. грешките се пишат в лога като човешки текст. не проверявам на всяка функция за грешка, а само на водещите. примерно ако пиша във файл, само на първото писане или на последното, според ситуацията, остаалите майната им.

Концептуалният въпрос е трябва ли всички грешки да се обработват. Твоят отговор е "не" и затова не проверяваш за грешки и не ползваш изключения. Дали дадена операция се е изпълнила успешно докрай или само частично - не знаеш. Каквото омажеш, омажеш, нали са само визуални ефекти

Ако обаче имаш код на много нива, с дълбок стек на извикванията, и същевременно искаш програмата да е стабилна и провалянето на дадена операция да те връща в дефинирано състояние и програмата да продължи да работи, писането и възможностите за грешка са много по-малко, ако използваш изключения.

Отделно от това, повечето "изключителни състояния" са програмистки грешки. Очакваш, че дадена операция ще успее, защото логиката на програмата трябва да е осигурила това да е така. Оказва се, че не е, и чрез изключение можеш да се върнеш в дефинирано състояние, независимо къде точно е грешката.

Това мнение е било редактирано от DarkOne на 25-04-2025, 13:10