Ти да видиш ... TyupeScript => Go
Native Type Script
Хах, плача на Rust програмистите е музика за ушите ми. :)
Иначе, никога не съм писал на Typescript, но Go ми е пръв избор за почти всичко. Все пак, писан е от хората, създали C :)
Както typescript така и go ще спечелят от колаборацията. Повече typescript програмери и по-добра поддръжка на go.
Абе тоя native GC ме кара да съм силно скептичен, че ще е по добра комбинация от чисто C и node.js - първото за всичко с какви да е ограничения за памет или цикли, второто за всичко останало. Т.е. все още не виждам смисъл от тази сглобка поне за моето ползване - за чий да обързявам това което не ме бърка дали е бързо или не.
Андерс (да се свети името Му) го е хванала старческата деменция :(
За целта на написване на компилатор GC буквално няма недостатъци
Тц. Walter Bright има една много хубава концепция за управлението на памет за компилатори. Проблема с банята е решен - баня няма да има. Компилатора е много кратък процес и операционната система се оправя без проблем да зачисти след като приключи, памет бол, просто си алокирай колкото ти трябва и не освобождавай нищо, никога. Покъртително решение. Пълни ми душата.
Те тука един стар линк по темата:
https://news.ycombinator.com/item?id=6103883
За съжаление оригиналната статия е изчезнала, но коментарите на автора и цитатите в хакернюз дават представа за идеята и аргументите и.
Това което цитираш (и аз съм го гледал това на Walter Bright) е аргумент в полза на GC не против него. Просто сменяш имплементацията на GC да не прави нищо и готово. Алокаторите на езици с GC традиционно са по-бързи от тези на езици без GC ама то може да смениш и имплементацията на алокатора де. Разбира се тука и двамата малко грешим, съвременният компилатор е и language server дето захранва IDE-то, така че в някакъв смисъл е процес дето работи дълго време и има user facing част, но някак си се оправят и със C# и с JS до този момент та явно има начин и с GC. От друга страна в C# вкараха супер много неща доста подобни на Rust с цел да не алокираш и вероятно ги ползват в компилатора та може би все пак е проблем... бе знам ли, да се оправят, аз без това почти не пипам TS, ако ми направят такова нещо със C# компилатора ще съм много ядосан, но там се случи обратното - пренаписаха го от C++ на C# и стана по-бърз
Бе не знам що те бърка колко е бърз компилатора . Аз съм ОК да не е. Стимулира правенето на по малко тъпи грешки от страна на програмиста. По важното ми е да оптимизира като хората кода за микроконтролери, че да не пиша на асемблер.
"проблема с паметта" е силно преекспониран проблем и дори когато е реален е просто симптом
Тайпскрипта винаги ми е смърдял на Subversion, само дето по-лошо :)
Езиците с възможности за мета левъл програмиране които ползват различен от основния език (например C++, C#, Rust) смучат, C е някъв неземно специален случай, макросите са някво безумно недоиздялкано дърво и въпреки това C смуче най-малко.
Разбира се езиците с възможности за мета левъл програмиране които ползват същия като основния език (например Ruby, JavaScript) си имат проблемите които хич не са малко но поне не са стъпка в грешна посока на ниво философия. Тайпскрипт е език с възможности за мета левъл програмиране който ползва различен от основния език за това, фунтаментално сбъркана постановка
О, ти да видиш в nim какво мета програмиране има - направо му бараш AST-то по време на компилация и си правиш квото си искаш.
Един приятел се опитва да си прави език и му разправям да го направи точно така ама не слуша. А е толкова елементарно. Пишеш си парсер до AST и VM/интерпретатор на това AST. И си пишеш на твоя си език докато не успееш да пренапишеш всичко т.е. да bootstrap-неш.
Навремето като бачкахме за един образ да му правим разни електро кад чекии много ни обичаше понеже нашия софт нямаше динамик мемори бъгове и крашове които толкова го тормозеха с предните дето беше наемал. То само бъгове и чистене и крашове и дебъгване, ужас някъв
А при нас просто нямаше. Нямаше бе, невероятно ама нямаше.
Но това не беше защото бяхме големите разбирачи на динамик мемори, точно обратното - НЕ ПОЛЗВАХМЕ динамик мемори :)
Трика беше че неговите проблеми имаха определена сложност и можеха да се композират от парчета - та просто шибвахме макса дето беше практичен тогава за отделно парче и сичко беше ток и жица. Като скачаха възможностите на комповете - упдейт на константа в хедър и прекомпилация - НУЛА бъгове от недоклатено ползване на реаллок :)
Забавно е как дивелъперчитата се хвърлят на алокатори и колектори и патърни и стратегии без даже да направят груба сметка на салфетка на коляно за кво аджеба става въпрос :)
Досега най-доброто са C и JavaScript - най-недоклатените полуабортирани щърби чавета :)
Сичко друго дето е МИСЛЕНО е с повече недостатъци отколкото предимства, Мада Нейча е присмехулна кучка :)
Преди 15 години се чудех с какво да заменя .net и стигнах до същия извод. И не съм съжалил нито веднъж. Няма по добре възвращаемост на инвестицията от тези два както и ти казваш най калпави езика. Може би защото и давата са проектирани от работещи програмисти а не от учени, професори или аматьори.
fasm също може много. Такъв препроцесор няма другаде.
препроцесора на С смуче много, особено ако човек е писал на някакъв асемблер с истински препроцесор преди това. но всъщност все тая, ако човек спре да се напъва се оказва че кой знае какъв препроцесор не ти трябва.
О, щот не знаеш в Zephyr какви извращения са направили. Като работи, работи. Ама като не работи няма такава мъка, стл грешките на ц++ преди 20 години ряпа да ядат в сравнение с това безумие. Макросите и препроцесора де.