Nejlepší odpověď
Rozhodně „Ne“ pro Swift 1, 2, 3. Ale možná ano pro Swift 4 . Každopádně stále nejsem příliš pozitivní.
Předpokládám, že cílovým trhem Rustu jsou programátoři C / C ++.
Klíčovou vlastností Rustu je extrémní bezpečnost bez režijních nákladů . Až dosud zde Swift selhává. Swift při použití typů ref vždy zahrnuje určitý druh režie v prostoru i čase. Toto je povinné a nevyhnutelné.
Režijní náklady jsou důležité, protože mnoho jazyků již poskytuje „bezpečnost“. Například C #. Což je podle mého názoru skutečný skutečný konkurent společnosti Swift. C # již poskytuje určitou úroveň bezpečnosti. A již byl v některém segmentu trhu úspěšně nahrazen C / C ++, ale ne úplně, protože přináší spoustu režijních nákladů. V prostoru i čase. Přestože kompilátor Swift může uniknout některým z režijních nákladů RC, ale záleží na štěstí při optimalizaci. V nějaké nešťastné situaci je režie obrovská.
A úroveň bezpečnosti je také odlišná. Je to stejné, že oba jazyky nemohou zaručit žádný visící ukazatel v bezpečném kontextu. Ale to je vše, co může Swift poskytnout, a to je velmi slabá záruka ve srovnání s tím, co poskytuje Rust. Na úrovni zdrojů mohou typy reflektorů Swift kdykoli uniknout a vždy potřebují lidskou péči. Kompilátor nemůže detekovat cyklické odkazy. Swift také umožňuje neomezené sdílení proměnlivé paměti mezi vlákny (kvůli nedostatku nativní jazykové souběžnosti), což znamená žádnou bezpečnost datového závodu.
Naproti tomu jedinečné vlastnictví Rust poskytuje plně statickou záruku, že nedojde k úniku prostředků. Žádný datový závod není také staticky zaručen.
To, co jsem cítil při používání Swiftu posledních pár let, je, že jazyk není opravdu bezpečný, pokud jde o správu zdrojů a datový závod. A povinná režie RC je opravdu velkým problémem v kódu kritickém pro výkon. Swift inzeruje výkon typů hodnot, ale ve skutečnosti vždy musíte použít některé typy ref, abyste mohli bezpečně přidělit hromadu. Společnost Swift inzeruje inteligentní RC kompilátor kompilátoru, ale je založen na štěstí, takže neporovnatelná zaručená nulová cena Rustu.
Proč záleží na bezpečnosti? Protože v minovém poli nemůžete být produktivní. Chcete-li být produktivní, musíte omezit, na co vám záleží. Ve Swiftu musíte vždy pečovat o cykly a datové rasy a režijní náklady, abyste nebyli zabiti, protože se o vás nikdo nestará. V Rustu to může kompilátor udělat a postarat se o vás. Prostě zapomenete na (mnoho) bezpečnosti a budete sledovat kompilátor, ať si stěžuje, pak jste v bezpečí. Stejně jako uživatelům jazyka GC nezáleží na houpajících se ukazatelích.
Také záleží na determinismu. Sledování životnosti objektu je zřídka nutné, ale někdy velmi důležité. Swift RC poskytuje načasování `deinit`, ale jelikož se jedná o sdílené vlastnictví, načasování smrti je obvykle velmi vágní. Takové načasování jedinečného vlastnictví je relativně jasnější než RC.
Jedinečné vlastnictví také pomáhá údržbě anotací odpovědného vlastníka. Podle mého názoru je správa jedinečného vlastníka mnohem jednodušší než správa více vlastníků. Vlastně to, co ve Swiftu vždy dělám, je jen specifikování implicitního jedinečného vlastníka a jejich ruční sledování pomocí nějaké konvence. Nebylo by hezké, kdyby to kompilátor udělal za vás?
Swift 4 plánuje představit několik nových funkcí, jako je jedinečné vlastnictví, sémantika přesunu, model herce a podpora spolupráce C ++. Ale nejsem si jistý, jak mohou zaručit úroveň bezpečnosti Rust s funkcemi současné sémantiky jazyka. Takže stále nejsem příliš pozitivní ohledně úrovně bezpečnosti Swiftu. C ++ inter-op může být velkým prodejním místem. To je každopádně téměř jediný důvod, proč si myslím, že Swift 4 může být potenciálním konkurentem Rustu pro trh C / C ++.
Swift má také klady. Jako je saner (podle mého názoru) pojmenování a jasná syntaxe (podle mého názoru), vyhrazené IDE, zaručený rozvoj a udržitelnost nejbohatším zastáncem světa (ale to také zavádí politickou otázku podporované platformy). Celkově má lepší UI / UX, ale stále mě více přitahuje Rustova bezpečnost a konceptuální krása …
P.S. Ve skutečnosti bylo možné udělat visící ukazatel v rané verzi Swift 2.x pouze s bezpečným konstruktem, jako je `deinit` a slabý ref. Ale nejsem si jistý pro budoucnost.
P.S. 2. Zdá se, že opravili mezeru. Ve Swift 3 získáte runtime výjimku, pokud se pokusíte vytvořit slabý odkaz v `deinit`.
Odpověď
Nedávno jsem četl o swift-3.x, ale já Už nějakou dobu jsem fanouškem Rustu a opravdu chci, aby Rust uspěl jako systémový jazyk.
Odpověď na vaši otázku bude podmíněná ano, proč? Je to proto, že swift překrývá významný prostor s rezem, pokud jde o nativní programování aplikací.Mezi jazyky existuje výrazný kontrast, pokud jde o filozofii designu a případy použití v programování systémů (a některé případy použití v reálném čase).
Rust je pro většinu částí navržen na filozofii C ++, což činí je možné provádět velmi vysoce výkonné výpočty a šíleně optimalizovatelné kompilátory (výklenek, proti kterému jsem neviděl mnoho moderních jazyků)
- „Abstrakce nulových nákladů“
- Toto je zvláště důležité, když píšete jádra nebo základní obslužné programy, protože je třeba je optimalizovat na maximální možnou míru, abyste dostali poslední kousek výkonu.
- V rychlé verzi můžete provést většinu optimalizací, ale ne všechny, tam je jazyková bariéra pro množství optimalizace, které lze dosáhnout (například hádám, že bychom mohli bezpečně předpokládat, že většina počítání referencí je rychlá atomická, ale v rezu si můžete vybrat mezi typy Rc a Arc, takže neplatíte za co nepoužíváte).
- „The Rust pointer model“
- Rust program s jsou navrženy tak, aby eliminovaly většinu zdrojů selhání z vašeho kódu prostřednictvím sémantiky vlastnictví, výpůjčky a přesunu, a proto staticky ověřuje, že jakýkoli zdroj má v daném okamžiku pouze jednoho jedinečného vlastníka. To také usnadňuje práci s dvěma z níže uvedených případů použití.
- Jak izolovat části programu, které jsou schopné havarovat (nebezpečné)
- Jak zajistit bezpečnou souběžnost při psaní kódu
- Swift je v tomto ohledu mnohem podobnější C ++, protože programátorovi vystavuje pouze silné (shared\_ptr), slabé (slabé\_ptr) a neznámé ukazatele (intrusive\_ptr) a dává jim kontrolu, aby je (ab) použil v jejich kód, takže rozhodně lepší kontrola než Java, ale určitě menší bezpečnost
- „Enumerations“
- Rust má bohaté výčty, které jsou podobné ADT v Haskellu (i když ne tak silné), ale přesto povolte krásný design Finite State Machines (FSM), pokud si myslíte o C, které má velmi špatnou podporu pro psaní FSM.
- Swift má také krásné výčty podobné Javě, což je podle mě mnohem silnější, protože můžeme definovat chování pro výčty.
- „Uzávěry“ – toto je jediná vlastnost, která odlišuje jakýkoli moderní jazyk od těch archaických. Rust i Swift podporují uzávěry, ale model rez vám umožňuje uvažovat o vlastnictví proměnných „closed over“, a tím zajišťuje bezpečnost. Na druhé straně by uzávěry Swift mohly přinést několik překvapení i zkušeným programátorům.
- Problémy s Rust
- Velmi jednoduché datové struktury, jako jsou Doubly linked lists, v rzi nemohou existovat, jen proto, že sémantiky vlastnictví (pro tuto jednoduchou datovou strukturu jsme nuceni používat Rc / Arc) to některé lidi rozzuří.
- Podle zkušeností s programováním, když existuje funkce v populárním jazyce, budou mít lidé tendenci zneužít je, v Rustu jsou nebezpečné bloky rozhodně náchylné ke zneužívání pro lidi, kteří nejsou ochotni bojovat proti vypůjčovateli, což bohužel představuje velké procento
- Porušení neměnnosti ve standardní knihovně, pokud triviální kód musí být napsán v Rustu, musíme mít datové typy, jako je Cell / RefCell, které lze technicky použít jako zadní vrátka proti silné bezpečnosti, kterou jazyk zjevně poskytuje. Řekl jsem, že knihovna poskytuje velké množství bezpečnostních primitiv při používání těchto datových typů, abychom se nestříleli do nohy.
- Nakonec se zdá, že Rust připouští, že i když je bezpečnější než C ++, některé z nenáviděné funkce C ++ je také třeba začlenit, abychom mohli povolit přijetí a umožnit lidem psát netriviální kód. To je smutné, ale bohužel také pravda.
- Problémy se Swift
- všudypřítomné používání ARC všude – což je porušení „neplatíte za to, co neplatíte použijte filozofii ”v C ++ (lze ji vyřešit v swift 5.x (viz [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model) )
- Nedostatek velmi snadno použitelných asynchronních primitiv live live async / await / coroutines (což je prodejní místo pro jazyky jako go), může být rychlý 5.x to bude řešit
- Někdy „třída ”Deklarace vás mohou zbytečně donutit k používání referenčních typů, kde byste mohli skutečně upřednostňovat hodnotový typ (strukturu)
- Vlastnosti v Rustu je technicky (pro většinu případů) lepším řešením pro 3 různé rychlé entity (rozšíření, protokoly & inheritance)
Takže si myslím, že pro swift určitě existuje mezera, aby se lidé, kteří jsou dobří programátoři v C ++, mohli rychle dostat na Swift / Rust. Ale myslím, že Swift bude mít stále větší trakci s vývojáři aplikací a programátoři Rust with System. Jejich příslušné mezery budou i nadále existovat i přes značné překrývání.