Cel mai bun răspuns
Cu siguranță „Nu” pentru Swift 1, 2, 3. Dar poate da pentru Swift 4 . Oricum, încă nu sunt foarte pozitiv.
Presupun că piața țintă a Rust este programatorii C / C ++.
Caracteristica cheie a Rust este siguranță extremă fără cheltuieli generale . Până acum, Swift eșuează aici. Swift implică întotdeauna un fel de cheltuieli generale atât în spațiu cât și în timp atunci când utilizați tipuri de ref. Acest lucru este obligatoriu și inevitabil.
Cheltuielile generale sunt importante deoarece doar „siguranța” este oferită deja de multe limbi. De exemplu, C #. Care este adevăratul concurent al Swift în opinia mea. C # oferă deja un anumit nivel de siguranță. Și a fost deja înlocuit cu succes C / C ++ într-un anumit segment al pieței, dar nu complet, deoarece introduce o grămadă de cheltuieli generale. Atât în spațiu cât și în timp. Deși compilatorul Swift poate elimina o parte din RC, dar depinde de noroc de optimizare. În unele situații nefericite, cheltuielile generale devin imense.
Și nivelul de siguranță este, de asemenea, diferit. Același lucru este că ambele limbi nu pot garanta niciun indicator care atârnă într-un context sigur. Dar asta este tot ceea ce Swift poate oferi și aceasta este o garanție foarte slabă în comparație cu ceea ce oferă Rust. La nivel de resurse, tipurile de referință Swift se pot scurge în orice moment și au întotdeauna nevoie de îngrijire umană. Compilatorul nu poate detecta referințele ciclice. Swift permite, de asemenea, partajarea nelimitată a memoriei mutabile între fire (datorită lipsei de concurență nativă în limbă), ceea ce înseamnă că nu există siguranță pe cursa de date.
În schimb, proprietatea unică Rust oferă o garanție complet statică a scurgerii de resurse. Nici o cursă de date nu este garantată static.
Ceea ce am simțit în timp ce foloseam Swift în ultimii ani este că limbajul nu este foarte sigur atunci când vine vorba de gestionarea resurselor și cursa de date. Și cheltuielile cu RC obligatorii reprezintă într-adevăr o mare preocupare în codul critic de performanță. Swift face publicitate performanței tipurilor de valoare, dar, de fapt, trebuie să folosiți întotdeauna unele tipuri de referință pentru a le aloca în grămadă în siguranță. Swift face publicitate eliziunii RC inteligente a compilatorului, dar se bazează pe noroc, deci incomparabil garantat costul zero al ruginii.
De ce contează sigur? Pentru că nu poți fi productiv într-un câmp minat. Pentru a fi productiv, trebuie să reduceți de ce vă pasă. În Swift trebuie întotdeauna să îți pese de ciclurile și de cursele de date și de cheltuieli generale doar să nu fii ucis, deoarece nimănui nu le pasă de tine. În Rust, compilatorul vă poate îngriji acest lucru. Pur și simplu uitați de (multe dintre) sigure și urmați compilatorul oricât se plânge, atunci sunteți în siguranță. La fel cum utilizatorii de limbă GC nu le pasă de indicii care atârnă.
De asemenea, determinismul contează. Urmărirea duratei de viață a obiectelor este rareori necesară, dar uneori foarte importantă. Swift RC oferă un timp „deinit”, dar, deoarece este proprietate comună, momentul morții este de obicei foarte vag. O astfel de sincronizare a proprietății unice este relativ mai clară decât RC.
Proprietatea unică ajută și la întreținere prin adnotarea proprietarului responsabil. În opinia mea, gestionarea proprietarului unic este mult mai ușoară decât gestionarea mai multor proprietari. De fapt, ceea ce fac întotdeauna în Swift este doar specificarea proprietarului unic implicit și urmărirea lor manuală prin anumite convenții. Nu ar fi frumos dacă compilatorul va face acest lucru pentru dvs.?
Swift 4 intenționează să introducă mai multe funcții noi, cum ar fi proprietatea unică, semantica de mișcare, modelul actorului și suportul interoperativ C ++. Dar nu sunt sigur cum pot garanta nivelul de siguranță Rust cu caracteristicile semanticii lingvistice actuale. Deci, încă nu sunt foarte pozitiv cu privire la nivelul de siguranță al Swift. C ++ inter-op ar putea fi un mare punct de vânzare. Oricum, acesta este aproape singurul motiv pentru care cred că Swift 4 poate fi un potențial concurent al pieței Rust pentru C / C ++.
Swift are și profesioniști. Cum ar fi convenția de numire saner (în opinia mea) și sintaxa clară (în opinia mea), IDE dedicat, dezvoltarea garantată și sustenabilitatea de către cel mai bogat susținător din lume (dar acest lucru introduce și problema politică a platformei acceptate). În general, are o interfață UI / UX mai bună, dar totuși mă atrag mai mult siguranța și frumusețea conceptuală a lui Rust …
P.S. De fapt, a fost posibil să se creeze un pointer care atârnă în versiunea anterioară a Swift 2.x doar cu o construcție sigură, cum ar fi `deinit` și slab-ref. Dar nu sunt sigur pentru moment și viitor.
P.S. 2. Se pare că au reparat lacuna. În Swift 3, veți obține o excepție de rulare dacă încercați să faceți o referință slabă în „deinit”.
Răspuns
Am citit recent despre swift-3.x, dar am Am fost un fan al Rust de o perioadă bună de timp și chiar vreau ca Rust să aibă succes ca limbaj de sistem.
Răspunsul la întrebarea dvs. va fi un da condiționat, de ce? Acest lucru se datorează faptului că suprapunerea rapidă a unui spațiu semnificativ cu rugina în ceea ce privește programarea aplicației native.Există un contrast puternic între limbaje în ceea ce privește filozofia de proiectare și cazurile de utilizare în programarea sistemelor (și unele cazuri de utilizare în timp real)
Rust este conceput pe filozofiile C ++ pentru majoritatea părților, ceea ce face ca este posibil să faceți calculatoare de înaltă performanță și compilatoare neobișnuit de optimizate (o nișă cu care nu am văzut multe limbi moderne concurând)
- „Abstracții cu costuri zero”
- Acesta este deosebit de semnificativ în timp ce scrieți nuclee sau utilitare de bază, deoarece acestea trebuie să fie optimizate la maximum posibil pentru a obține ultimul bit de performanță.
- În rapid puteți face cele mai multe optimizări, dar nu toate, acolo este o barieră lingvistică în calea optimizării care poate fi realizată (de exemplu, presupun că am putea presupune în siguranță că cea mai mare numărare a referințelor este atomică rapid, dar în rugină puteți alege între tipurile de Rc și Arc, deci nu plătiți pentru ce nu utilizați).
- „Modelul indicatorului Rust”
- Programul Rust S sunt concepute pentru a elimina majoritatea surselor de blocări din codul dvs. prin proprietate, împrumut și mutare semantică, prin urmare, verifică static că orice resursă are un singur proprietar unic la un moment dat în timp. Acest lucru ușurează, de asemenea, lucrurile pentru două dintre cazurile de utilizare de mai jos.
- Cum se izolează părți ale programului care nu se pot defecta (nesigur)
- Cum să existe o concurență sigură la scrierea codului
- Swift este mult mai asemănător cu C ++ în această privință, deoarece expune doar programatorilor puternici (shared\_ptr), slab (slab\_ptr) și indisponibil (intruziv\_ptr) și le oferă controlul pentru (ab) să le folosească în codul lor, deci cu siguranță un control mai bun decât Java, dar cu siguranță o siguranță mai redusă
- „Enumerații”
- Rust are enumerări bogate, care sunt similare cu ADT-urile din Haskell (deși nu atât de puternice), dar totuși activați proiectarea frumoasă a mașinilor de stat finit (FSM) dacă vă gândiți la C, care are un suport foarte slab pentru scrierea FSM.
- Swift are, de asemenea, enumerări frumoase asemănătoare cu Java, care cred că este mult mai puternică, deoarece putem defini comportament pentru enumere.
- „Închideri” – Aceasta este singura caracteristică care distinge orice limbaj modern de cele arhaice. Atât Rust, cât și Swift acceptă închideri, dar modelul de rugină vă permite să argumentați cu privire la proprietatea variabilelor „închise” și astfel vă asigură siguranța. Pe de altă parte, în cazul în care închiderile Swift pot apărea câteva surprize chiar și pentru programatorii cu experiență.
- Problemele legate de Rust
- Structuri de date foarte simple, cum ar fi listele cu legături duble, nu pot exista în rugină, doar pentru că din semantica proprietății (suntem forțați să folosim Rc / Arc pentru această structură simplă de date), asta îi enervează pe unii oameni.
- Conform experienței de programare, când există o caracteristică într-un limbaj popular, oamenii vor tinde să Abuzați-le, în Rust, blocurile nesigure sunt cu siguranță predispuse la abuzuri pentru persoanele care nu sunt dispuse să lupte împotriva verificatorului de împrumut, care din păcate constituie un procent mare
- Încălcări ale imuabilității în biblioteca standard, dacă nu codul banal trebuie să fie scris în Rust, trebuie să avem tipuri de date, cum ar fi Cell / RefCell, care ar putea fi utilizate din punct de vedere tehnic ca portiere din spate împotriva siguranței puternice pe care limbajul pare să le ofere. După ce am spus că biblioteca oferă o mulțime de primitive de siguranță în timp ce utilizăm aceste tipuri de date, astfel încât să nu ne împușcăm în picior.
- În cele din urmă, Rust pare să admită că, deși este mai sigur decât C ++, unele dintre caracteristicile urâte C ++ trebuie, de asemenea, să fie încorporate, astfel încât să putem permite adoptarea și să permitem oamenilor să scrie cod non-banal. Acest lucru este trist, dar, din păcate, și adevărul.
- Problemele cu Swift
- Utilizarea omniprezentă a ARC peste tot – ceea ce reprezintă o încălcare a „nu plătești pentru ceea ce nu faci folosiți ”filozofia în C ++ (poate fi abordată în rapid 5.x (consultați [swift-evolution] RFC: Prevenirea ciclurilor de păstrare (model de proprietate a memoriei) )
- Lipsa primitivelor asincrone foarte ușor de utilizat live async / await / coroutines (care este punctul de vânzare pentru limbi precum go), poate fi rapidă 5.x va aborda acea
- Uneori „clasa ”Declarațiile vă pot forța inutil să utilizați tipuri de referință în care ați putea prefera un tip de valoare (struct)
- Trăsăturile din Rust reprezintă tehnic (pentru majoritatea cazurilor) o soluție mai bună pentru 3 entități rapide diferite (extensii, protocoale și moștenire)
Deci, cred că există cu siguranță o nișă pentru ocuparea rapidă, oamenii care sunt buni programatori C ++ pot ajunge rapid la Swift / Rust. Dar cred că Swift va primi mai multă tracțiune cu dezvoltatori de aplicații și programatori Rust with System. Nișele lor respective vor continua să existe în ciuda suprapunerii semnificative.