Bästa svaret
Definitivt ”Nej” för Swift 1, 2, 3. Men kanske ja för Swift 4 Hur som helst, jag är fortfarande inte särskilt positiv.
Jag antar att Rusts målmarknad är C / C ++ -programmerare.
Nyckelfunktionen i Rust är extrem säkerhet utan overhead . Hittills misslyckas Swift här. Swift involverar alltid ett slags overhead i både tid och rum när du använder ref-typer. Detta är obligatoriskt och oundvikligt.
Overhead är viktigt eftersom bara ”säkerhet” redan tillhandahålls av många språk. Till exempel C #. Vilket är den verkliga konkurrenten till Swift enligt min mening. C # erbjuder redan viss säkerhet. Och det har redan framgångsrikt ersatts C / C ++ i något segment av marknaden men inte helt för att det introducerar massa overhead. I både rum och tid. Även om Swift-kompilatorn kan ta del av RC-omkostnader, men det beror på lycka till optimering. I en olycklig situation blir omkostnaderna enorma.
Och säkerhetsnivån är också annorlunda. Det är samma sak att båda språken kan garantera ingen dinglande pekare i säkert sammanhang. Men det är allt vad Swift kan erbjuda, och detta är en mycket svag garanti jämfört med vad Rust ger. På resursnivå kan Swift ref-typer läcka när som helst och behöver alltid mänsklig vård. Kompilatorn kan inte upptäcka cykliska ref. Swift tillåter också obegränsad delning av muterbart minne mellan trådar (på grund av brist på språklig modersmål), vilket innebär ingen säkerhet vid datalopp.
Däremot ger Rust unikt ägande fullständigt statisk garanti för ingen resursläcka. Ingen datalopp garanteras också statiskt.
Det jag kände när jag använde Swift de senaste åren är att språket inte är riktigt säkert när det gäller resurshantering och datalopp. Och obligatorisk RC-kostnad är verkligen ett stort problem i prestandakritisk kod. Swift annonserar prestanda för värdetyper, men i själva verket måste du alltid använda några ref-typer i den för att fördela i hög säkert. Swift annonserar för kompilatorns smarta RC-elision, men den är baserad på tur, så ojämförlig garanterad noll kostnad för Rust.
Varför betyder säkerhet? För att du inte kan vara produktiv i ett minfält. För att vara produktiv måste du minska vad du bryr dig om. I Swift måste du alltid ta hand om cykler och datalopp och overhead bara för att inte bli dödad eftersom ingen bryr sig om dem för dig. I Rust kan kompilatorn ta hand om detta åt dig. Du glömmer bara bort (många av) säkerheten och följer kompilatorn vad det än klagar på, då är du säker. Precis som GC-språkanvändare bryr sig inte om att hänga pekare.
Det är också viktigt med determinism. Spårning av objektets livslängd krävs sällan, men ibland mycket viktigt. Swift RC tillhandahåller ”deinit” -timing, men eftersom det är delat ägande är tidpunkten för döden vanligtvis mycket vag. Sådan timing i unikt ägande är relativt mycket tydligare än RC.
Unikt ägande hjälper också till underhåll genom att kommentera den ansvariga ägaren. Enligt min mening är det mycket enklare att hantera unik ägare än att hantera flera ägare. Egentligen vad jag alltid gör i Swift är bara att ange implicita unika ägare och spåra dem manuellt genom någon konvention. Skulle det inte vara trevligt om kompilatorn gör detta åt dig?
Swift 4 planerar att introducera flera nya funktioner som unikt ägande, flytta semantik, skådespelarmodell och C ++ inter-op-support. Men jag är inte säker på hur de kan garantera rostsäkerhetsnivå med funktionerna i nuvarande språk semantik. Så jag är fortfarande inte särskilt positiv till Swifts säkerhetsnivå. C ++ inter-op kan vara en stor försäljningsplats. Hur som helst, detta är nästan den enda anledningen till varför jag tror att Swift 4 kan vara en potentiell konkurrent till Rust för C / C ++ -marknaden.
Swift har också proffs. Såsom saner (enligt min mening) namngivningskonvention och tydlig syntax (enligt min mening), dedikerad IDE, garanterad utveckling och hållbarhet av världens rikaste anhängare (men detta introducerar också en politisk fråga om den stödda plattformen). Sammantaget har den bättre UI / UX, men jag lockas fortfarande mer av Rusts säkerhet och konceptuella skönhet …
P.S. Egentligen var det möjligt att göra en hängande pekare i tidig version av Swift 2.x med endast säker konstruktion som `deinit` och svag-ref. Men jag är inte säker för nu och i framtiden.
P.S. 2. Det verkar som om de lappade kryphålet. I Swift 3 får du ett undantag för runtime om du försöker göra en svag referens i `deinit`.
Svar
Jag hade nyligen läst om swift-3.x men jag Jag har varit en Rust-fanboy under en god tid, och jag * vill verkligen att Rust ska lyckas som systemspråk.
Svaret på din fråga kommer att vara ett villkorligt ja, varför? Detta beror på att snabbt överlappar ett betydande utrymme med rost när det gäller inbyggd applikationsprogrammering.Det finns en skarp kontrast mellan språken när det gäller designfilosofi och användningsfall i systemprogrammering (och vissa realtidsanvändningsfall)
Rost är utformat på C ++ – filosofierna för de flesta delar, vilket gör möjligt att göra mycket högpresterande datorer och vansinnigt optimerbara kompilatorer (en nisch som jag inte har sett många moderna språk tävla mot)
- “Nollkostnadsabstraktion”
- Detta är särskilt viktigt när du skriver kärnor eller kärnverktyg eftersom de behöver optimeras så mycket som möjligt för att få ut den sista biten av prestanda.
- Snabbt kan du kanske göra de flesta optimeringar men inte alla, där är ett språkbarriär för den mängd optimering som kan uppnås (till exempel gissar jag att vi säkert skulle kunna anta att de flesta referensräkningar är atomiska i snabbhet, men i rost kan du välja mellan Rc & Arc-typer, så betal inte för vad du inte använder).
- ”Rust-pekermodellen”
- Rust-program s är utformade för att eliminera de flesta källorna till kraschar från din kod genom äganderätt, upplåning och flyttning av semantik, vilket verifierar statiskt att varje resurs bara har en unik ägare vid en given tidpunkt. Detta gör det också enkelt för två av nedanstående användningsfall.
- Hur man isolerar kraschbeständiga delar av programmet (osäkra)
- Hur man har säker samtidighet när man skriver kod
- Swift är mycket mer lik C ++ i detta avseende eftersom det bara exponerar de starka (delade\_ptr), svaga (svaga\_ptr) och oägda pekare (påträngande\_ptr) för programmeraren och ger dem kontrollen att (ab) använda dem i deras kod, så definitivt bättre kontroll än Java men säkert lägre säkerhet
- ”Uppräkningar”
- Rust har rika enum som liknar ADT i Haskell (om än inte så kraftfulla), men ändå aktivera vacker design av Finite State Machines (FSM) om du tänker på C som har mycket dåligt stöd för att skriva FSM.
- Swift har också vackra uppräkningar som liknar Java, vilket jag tycker är mycket kraftfullare eftersom vi kan definiera beteende för enums.
- ”Stängningar” – Detta är den enda funktionen som skiljer alla moderna språk från de arkaiska. Både Rust och Swift stöder stängningar, men rostmodellen gör det möjligt för dig att resonera om ägandet av variablerna ”closed over” och därigenom säkerställa säkerheten. Å andra sidan hade Swift-stängningar kan ge upphov till några överraskningar för även erfarna programmerare.
- Problemen med Rust
- Mycket enkla datastrukturer som dubbelt länkade listor kan inte existera i rost, bara för att av ägarsemantiken (vi tvingas använda Rc / Arc för den här enkla datastrukturen) detta irriterar vissa människor.
- Enligt programmeringserfarenhet när det finns en funktion på ett populärt språk, tenderar människor att missbruka dem, i Rust är de osäkra blocken definitivt utsatta för människor som inte är villiga att kämpa mot lånekontrollen, som tyvärr utgör en stor andel
- Brott mot oföränderlighet i standardbiblioteket, om det inte är trivial kod måste skrivas i Rust, vi måste ha datatyper som Cell / RefCell kan tekniskt användas som bakdörrar mot den starka säkerhet som språket verkar ge. Med detta sagt erbjuder biblioteket en hel del säkerhetsprimitiv när vi använder dessa datatyper så att vi inte skjuter oss själva i foten.
- Slutligen verkar Rust erkänna att, även om det är säkrare än C ++, en del av de hatade C ++ – funktionerna måste också införlivas så att vi kan tillåta adoption och göra det möjligt för människor att skriva icke-trivial kod. Detta är sorgligt, men tyvärr också sanningen.
- Problemen med Swift
- Den genomgripande användningen av ARC överallt – vilket är ett brott mot ”du betalar inte för det du inte gör använd ”filosofi i C ++ (kan adresseras i snabb 5.x (se [swift-evolution] RFC: Prevention Retain Cycles (Memory Ownership Model) )
- Brist på mycket lättanvända asynkrona primitiver live async / await / coroutines (vilket är försäljningsargumentet för språk som go), kan vara snabbt 5.x kommer att ta itu med det
- Ibland “klass ”Deklarationer kan i onödan tvinga dig att använda referenstyper där du faktiskt föredrar en värdetyp (struct)
- Egenskaper i Rust är tekniskt sett (för de flesta fall) en bättre lösning för 3 olika snabba enheter (tillägg, protokoll & arv)
Så jag antar att det definitivt finns en nisch för snabb att ockupera, människor som är bra C ++ – programmerare kan snabbt komma till Swift / Rust. Men jag tror att Swift kommer att få mer grepp med applikationsutvecklare och Rust med systemprogrammerare. Deras respektive nischer kommer att fortsätta att existera trots betydande överlappning.