Виждам, че ви липсва темата за ръст :)
Rust
Като видя едно ей такова лайно - https://github.com/OpenVisualCloud/SVT-HEVC/blob/master/Source/App/EbAppConfig.c и се чудя защо не се пише вече на ръст вместо на С, така или иначе нищо не се печели.
защото майстор торвалдс така е решил, той знае най-добре
реално Цто трябва само ако комуникираш с хардуер, тъй като single ownership модела на ръст очевидно няма как да работи в този случай, всъщност, тогава ползваш unsafe и пишеш Ц на ръст
Тоя подход усилено се ползва от писачите на фърмуер. Кодът е четим. От кво се оплакваш? Ръст може ли да билдва за чип дето е Tiny AVR и имаш 2 килобайта флаш и 256 БАЙТА RAM? Щото аз чак съм се чудил как са успели да направят толкоз съвършен компилатор. Един от най-големите инженерни шедьоври, невидими и непризнати от простолюдието. WinAVR ако тряя съм конкретен, само че ползва GCC за ядро, не помна коя точно вариация.
Кво му е убавото на Ръст и кой пише на това? Питам щот не знам, а не щот се заяждам.
Rabin Кво му е убавото на Ръст и кой пише на това? Питам щот не знам, а не щот се заяждам.
Какво му е хубавото не мога да ти кажа, но който пише на него си личи от името му: rust = ru руснаци + st жители на Сао Томе и Принсипи.
Ръст решава проблема с memory safety-то. Според Меките и Гуглите едно 70+% отвсички бъгове са memory бъгове. Това е основния фиичър на езика. От друга страна има автоматично управлени ена паметта, ноняма GC, което го прави подходящ за low latency сценарии и където stop the world не е ОК. Друго много яко нещо е, че е от самата типова система става ясно, кой обект може да се ползва безопасно от няколко нишки и кой не и съответно компилатора не ти позволява да правиш код с race conditions.
Elim Garak Според Меките и Гуглите едно 70+% отвсички бъгове са memory бъгове.
това е защото няма как крашване да го пишеш феатур, реално има много повече бъгове на които просто не се обръща внимание.
Elim Garak Ръст решава проблема с memory safety-то. Според Меките и Гуглите едно 70+% отвсички бъгове са memory бъгове. Това е основния фиичър на езика. От друга страна има автоматично управлени ена паметта, ноняма GC, което го прави подходящ за low latency сценарии и където stop the world не е ОК. Друго много яко нещо е, че е от самата типова система става ясно, кой обект може да се ползва безопасно от няколко нишки и кой не и съответно компилатора не ти позволява да правиш код с race conditions.
Кой и за какво пише на Ръст? Автомобилните пишат на С и малко Java. Самолетите ги пишат на Ада. Туй дето го каза ми прилича на рекламен слоган. Много е лесно на теория да бичиш яки приказки.
Мавенжийницата примерно е много убава дори за средно големи проекти. За реалния живот почва да става основен препъни камък у проекта. Инак на теория и стартъпи е цветя и рози.
Rabin Тоя подход усилено се ползва от писачите на фърмуер. Кодът е четим. От кво се оплакваш? Ръст може ли да билдва за чип дето е Tiny AVR и имаш 2 килобайта флаш и 256 БАЙТА RAM? Щото аз чак съм се чудил как са успели да направят толкоз съвършен компилатор. Един от най-големите инженерни шедьоври, невидими и непризнати от простолюдието. WinAVR ако тряя съм конкретен, само че ползва GCC за ядро, не помна коя точно вариация.
Кво му е убавото на Ръст и кой пише на това? Питам щот не знам, а не щот се заяждам.
Аз специално пуснах линк, защото това е video encoder, който работи на сървърната част, в общият случай x86. Разбирам да беше написан на С++14/17, но чисто С в този случай няма предимства.
Resolution Minimum Footprint (GB) 8k 64 4k 16
bvbfan Аз специално пуснах линк, защото това е video encoder, който работи на сървърната част, в общият случай x86. Разбирам да беше написан на С++14/17, но чисто С в този случай няма предимства.
С++ плаши дори корави и брадати програмисти, плаши и мен. Някога се мъчих да уча MFC за Windows. Когато още не беше SpyOS. Oще ми държи влага туй занятие. Предпочитам С.
Това, че Линус не ще Ц+- в ядрото ясно показва, че не става
Rabin С++ плаши дори корави и брадати програмисти, плаши и мен. Някога се мъчих да уча MFC за Windows. Когато още не беше SpyOS.
C++ отдавна е изплашил M$, започнал си с най-лошият пример.
Elim Garak Това, че Линус не ще Ц+- в ядрото ясно показва, че не става
ама и ръст не ще, начи и той не става
Дон Реба Elim Garak Според Меките и Гуглите едно 70+% отвсички бъгове са memory бъгове.
това е защото няма как крашване да го пишеш феатур, реално има много повече бъгове на които просто не се обръща внимание.
100% съгласен! При това, никой не отчита, че мемори бъговете се оправят на порядъци по-лесно от сложните бъгове базирани на взаимодействията между слоевете абстракции.
И това го казвам именно от опита си с писане на асемблер. Ето AsmBB в момента няма нито един проблем с паметта. Примерно този форум колко време вече работи и няма нито един краш на енджина.
Защо? Ами защото проблемите с паметта са винаги видими, откриват се лесно и се оправят бързо.
Elim Garak Това, че Линус не ще Ц+- в ядрото ясно показва, че не става
Kernel-ът се изписва на С диалект, който има специфични keywords, които са несъвместими със С++. Както и да е, всичко извън него може да е написано на С++.
johnfound При това, никой не отчита, че мемори бъговете се оправят на порядъци по-лесно от сложните бъгове базирани на взаимодействията между слоевете абстракции.
Абсолютно, дори съм виждал такива глупости, все едно бобър със затворени очи го е писал.
Дон Реба ама и ръст не ще, начи и той не става
Иска, скоро ще дебютира дори.
johnfound 100% съгласен! При това, никой не отчита, че мемори бъговете се оправят на порядъци по-лесно от сложните бъгове базирани на взаимодействията между слоевете абстракции.
И това го казвам именно от опита си с писане на асемблер. Ето AsmBB в момента няма нито един проблем с паметта. Примерно този форум колко време вече работи и няма нито един краш на енджина.
Защо? Ами защото проблемите с паметта са винаги видими, откриват се лесно и се оправят бързо.
Да не би да направи 100 000 регнати юзверга, да бачка на клъстер, да имаш горещ резерв? Тъй си и знаех. Тия виртуални машини не са измислени от хубаво.