La migliore risposta
Sicuramente “No” per Swift 1, 2, 3. Ma forse sì per Swift 4 Comunque, non sono ancora molto positivo.
Presumo che il mercato di riferimento di Rust sia i programmatori C / C ++.
La caratteristica chiave di Rust è estrema sicurezza senza overhead . Fino ad ora, Swift fallisce qui. Swift comporta sempre una sorta di sovraccarico sia nello spazio che nel tempo quando usi i ref-type. Questo è obbligatorio e inevitabile.
Il sovraccarico è importante perché in molte lingue viene già fornita solo la “sicurezza”. Ad esempio, C #. Che è il vero vero concorrente di Swift secondo me. C # fornisce già un certo livello di sicurezza. Ed è già stato sostituito con successo C / C ++ in alcuni segmenti del mercato, ma non completamente perché introduce un sacco di overhead. Sia nello spazio che nel tempo. Sebbene il compilatore Swift possa elidere un po di overhead RC, ma dipende dalla fortuna dallottimizzazione. In qualche situazione sfortunata, loverhead diventa enorme.
E anche il livello di sicurezza è diverso. È lo stesso che entrambe le lingue non possono garantire alcun puntatore penzolante in un contesto sicuro. Ma questo è tutto ciò che Swift può fornire, e questa è una garanzia molto debole rispetto a ciò che fornisce Rust. A livello di risorse, i ref-type Swift possono fuoriuscire in qualsiasi momento e hanno sempre bisogno di cure umane. Il compilatore non è in grado di rilevare i riferimenti ciclici. Swift consente anche la condivisione illimitata della memoria mutabile tra i thread (a causa della mancanza di concorrenza nativa del linguaggio), il che significa nessuna sicurezza sulla corsa ai dati.
Al contrario, la proprietà unica di Rust fornisce una garanzia completamente statica di nessuna perdita di risorse. Nessuna gara di dati garantita anche staticamente.
Quello che ho sentito durante lutilizzo di Swift negli ultimi anni è che il linguaggio non è veramente sicuro quando si tratta di gestione delle risorse e corsa ai dati. E il sovraccarico RC obbligatorio è davvero una grande preoccupazione nel codice critico per le prestazioni. Swift pubblicizza le prestazioni dei tipi di valore, ma in realtà devi sempre utilizzare alcuni tipi di riferimento per allocare in modo sicuro nellheap. Swift pubblicizza lelisione RC intelligente del compilatore, ma si basa sulla fortuna, un costo zero garantito così incomparabile di Rust.
Perché la sicurezza è importante? Perché non puoi essere produttivo in un campo minato. Per essere produttivo, devi ridurre ciò di cui preoccuparti. In Swift devi sempre preoccuparti dei cicli e della corsa dei dati e delle spese generali solo per non essere ucciso perché nessuno si prende cura di loro per te. In Rust, il compilatore può farlo e si prende cura di te. Ti dimentichi solo di (molti di) sicurezza e segui il compilatore qualunque cosa si lamenti, allora sei al sicuro. Proprio come gli utenti del linguaggio GC non si preoccupano dei puntatori penzolanti.
Inoltre, il determinismo è importante. Il monitoraggio della durata delloggetto è raramente richiesto, ma a volte è molto importante. Swift RC fornisce la tempistica “deinit”, ma poiché è proprietà condivisa, la tempistica della morte di solito è molto vaga. Tale tempistica nella proprietà unica è relativamente molto più chiara di RC.
La proprietà unica aiuta anche la manutenzione annotando il proprietario responsabile. A mio parere, gestire un proprietario unico è molto più semplice che gestire più proprietari. In realtà quello che faccio sempre in Swift è solo specificare il proprietario univoco implicito e tracciarlo manualmente secondo una convenzione. Non sarebbe bello se il compilatore lo facesse per te?
Swift 4 ha in programma di introdurre diverse nuove funzionalità come proprietà unica, semantica di spostamento, modello attore e supporto interoperativo C ++. Ma non sono sicuro di come possano garantire il livello di sicurezza di Rust con le funzionalità della semantica del linguaggio corrente. Quindi non sono ancora molto positivo sul livello di sicurezza di Swift. Linteroperabilità C ++ potrebbe essere un grande punto di vendita. Ad ogni modo, questa è quasi lunica ragione per cui penso che Swift 4 possa essere un potenziale concorrente di Rust per il mercato C / C ++.
Swift ha anche dei professionisti. Come una convenzione di denominazione più sana (a mio parere) e una sintassi chiara (a mio parere), IDE dedicato, sviluppo e sostenibilità garantiti dal sostenitore più ricco del mondo (ma questo introduce anche una questione politica della piattaforma supportata). Nel complesso, ha uninterfaccia utente / UX migliore, ma sono ancora attratto dalla sicurezza e dalla bellezza concettuale di Rust …
P.S. In realtà era possibile creare un puntatore penzolante nella prima versione di Swift 2.x con solo costrutti sicuri come `deinit` e weak-ref. Ma non sono sicuro per ora e per il futuro.
P.S. 2. Sembra che abbiano riparato la scappatoia. In Swift 3, otterrai uneccezione di runtime se provi a fare un riferimento debole in `deinit`.
Risposta
Avevo letto di recente di swift-3.x ma ho Sono stato un fan di Rust per un bel po di tempo, e * davvero * voglio che Rust abbia successo come linguaggio di sistema.
La risposta alla tua domanda sarà un condizionale sì, perché? Questo perché swift sovrappone uno spazio significativo con la ruggine in termini di programmazione dellapplicazione nativa.Esiste un netto contrasto tra i linguaggi in termini di filosofia di progettazione e casi duso nella programmazione dei sistemi (e alcuni casi duso in tempo reale)
Rust è progettato sulla filosofia C ++ per la maggior parte delle parti, il che rende possibile fare calcoli ad altissime prestazioni e compilatori follemente ottimizzabili (una nicchia contro la quale non ho visto competere molti linguaggi moderni)
- “Astrazioni a costo zero”
- Questo è particolarmente significativo durante la scrittura di kernel o utilità principali perché devono essere ottimizzati al massimo possibile per ottenere lultimo bit di prestazioni.
- In swift puoi forse fare la maggior parte delle ottimizzazioni ma non tutte, lì è una barriera linguistica alla quantità di ottimizzazione che può essere raggiunta (per esempio immagino che potremmo tranquillamente presumere che la maggior parte del conteggio dei riferimenti sia atomica in rapida, ma in ruggine puoi scegliere tra i tipi Rc e Arc, quindi non pagare per quello che non usi).
- “Il modello di puntatore Rust”
- Il programma Rust sono progettati per eliminare la maggior parte delle fonti di arresti anomali dal codice attraverso la proprietà, il prestito e lo spostamento della semantica, quindi verifica staticamente che ogni risorsa abbia un solo proprietario univoco in un dato momento. Ciò semplifica anche le cose per due dei seguenti casi duso.
- Come isolare parti del programma in grado di bloccarsi (non sicure)
- Come avere una concorrenza sicura durante la scrittura del codice
- Swift è molto più simile a C ++ in questo senso poiché espone solo i puntatori forte (shared\_ptr), debole (weak\_ptr) e non proprietario (intrusive\_ptr) al programmatore e dà loro il controllo per (ab) usarli in il loro codice, quindi un controllo decisamente migliore di Java ma sicuramente minore sicurezza
- “Enumerazioni”
- Rust ha enumerazioni ricche che sono simili agli ADT in Haskell (anche se non così potenti), ma comunque abilitare un bel design di Finite State Machines (FSM) se si pensa a C che ha un supporto molto scarso per la scrittura di FSM.
- Swift ha anche bellissime enumerazioni simili a Java che penso sia molto più potente poiché possiamo definire comportamento per enumerazioni.
- “Chiusure” – Questa è lunica caratteristica che distingue qualsiasi linguaggio moderno da quelli arcaici. Sia Rust che Swift supportano le chiusure, ma il modello ruggine consente di ragionare sulla proprietà delle variabili “chiuse” e quindi garantisce la sicurezza. Dallaltro, le chiusure di Swift possono far sorgere alcune sorprese anche per programmatori esperti.
- I problemi con Rust
- Strutture di dati molto semplici come le liste a doppia connessione non possono esistere in Rust, solo perché della semantica della proprietà (siamo costretti a usare Rc / Arc per questa semplice struttura dati) questo irrita alcune persone.
- Secondo lesperienza di programmazione quando cè una caratteristica in un linguaggio popolare, le persone tenderanno a abusare di loro, in Rust i blocchi non sicuri sono sicuramente soggetti ad abusi per le persone che non sono disposte a combattere contro il controllo dei prestiti, che purtroppo costituisce una grande percentuale
- Violazioni dellimmutabilità nella libreria standard, se non- il codice banale deve essere scritto in Rust, dobbiamo avere tipi di dati come Cell / RefCell che potrebbero tecnicamente essere usati come backdoor contro la forte sicurezza che il linguaggio sembra fornire. Detto questo, la libreria fornisce una grande quantità di primitive di sicurezza durante lutilizzo di questi tipi di dati, quindi non ci spariamo sui piedi.
- Infine Rust sembra ammettere che, pur essendo più sicuro del C ++, alcuni dei anche le odiate funzionalità del C ++ devono essere incorporate in modo da consentire ladozione e consentire alle persone di scrivere codice non banale. Questo è triste, ma purtroppo anche la verità.
- I problemi con Swift
- Luso pervasivo di ARC ovunque – che è una violazione del “non paghi per ciò che non fai use ”filosofia in C ++ (può essere affrontata in swift 5.x (vedere [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model) )
- Mancanza di primitive asincrone molto facili da usare live async / await / coroutines (che è il punto di forza di linguaggi come go), potrebbe essere rapido 5.x risolverà questo problema
- A volte “class “Le dichiarazioni possono costringerti a usare inutilmente tipi di riferimento dove potresti effettivamente preferire un tipo di valore (struct)
- Traits in Rust è tecnicamente (per la maggior parte dei casi) una soluzione migliore per 3 diverse entità swift (estensioni, protocolli & inheritance)
Quindi immagino che ci sia sicuramente una nicchia da occupare per swift, le persone che sono bravi programmatori C ++ possono arrivare a Swift / Rust rapidamente. Ma penso che Swift otterrà più trazione con sviluppatori di applicazioni e Rust con programmatori di sistema. Le rispettive nicchie continueranno a esistere nonostante la significativa sovrapposizione.