Beste svaret
Definitivt “Nei” for Swift 1, 2, 3. Men kanskje ja for Swift 4 Uansett er jeg fortsatt ikke veldig positiv.
Jeg antar at Rusts målmarked er C / C ++ programmerere.
Nøkkelfunksjonen i Rust er ekstrem sikkerhet uten overhead . Inntil nå mislykkes Swift her. Swift involverer alltid en slags overhead i både tid og rom når du bruker ref-typer. Dette er obligatorisk og uunngåelig.
Overhead er viktig fordi bare «sikkerhet» allerede er gitt av mange språk. For eksempel C #. Som er faktisk ekte konkurrent til Swift etter min mening. C # gir allerede et visst sikkerhetsnivå. Og det er allerede blitt vellykket erstattet C / C ++ i noe segment av markedet, men ikke helt fordi det introduserer haug med overhead. Både i rom og tid. Selv om Swift-kompilatoren kan ta noen av RC-kostnadene, men det avhenger av flaks på optimalisering. I noen uheldige situasjoner blir overhead enorme.
Og sikkerhetsnivået er også annerledes. Det er det samme at begge språkene ikke kan garantere noen dinglende pekere i trygg sammenheng. Men det er alt det Swift kan tilby, og dette er veldig svak garanti sammenlignet med hva Rust gir. På ressursnivå kan Swift ref-typer lekke når som helst og trenger alltid menneskelig pleie. Kompilatoren kan ikke oppdage sykliske ref. Swift tillater også ubegrenset deling av foranderlig minne mellom tråder (på grunn av manglende språklig innfødt samtidighet), noe som ikke betyr sikkerhet på dataløpet. Ingen dataløp garantert også statisk.
Det jeg følte mens jeg brukte Swift de siste årene, er språket egentlig ikke trygt når det gjelder ressursadministrasjon og dataløp. Og obligatorisk RC-overhead er virkelig en stor bekymring i ytelseskritisk kode. Swift annonserer ytelse av verdityper, men faktisk må du alltid bruke noen ref-typer i den for å fordele i haug trygt. Swift annonserer kompilatorens smarte RC elision, men den er basert på flaks, så uovertruffen garantert null kostnad for Rust.
Hvorfor betyr sikkerhet? Fordi du ikke kan være produktiv i et minefelt. For å være produktiv, må du redusere hva du skal bry deg om. I Swift må du alltid ta vare på sykluser og dataløp og overhead bare for ikke å bli drept fordi ingen bryr seg om dem for deg. I Rust kan kompilatoren ta vare på dette for deg. Du glemmer bare (mange av) safty, og følger kompilatoren uansett hva den klager, så er du trygg. Akkurat som GC-språkbrukere ikke bryr seg om dinglende pekere.
Også determinisme betyr noe. Sporing av gjenstandens levetid er sjelden nødvendig, men noen ganger veldig viktig. Swift RC gir deinit timing, men da det er delt eierskap, er tidspunktet for død vanligvis veldig vagt. Slik timing i unikt eierskap er relativt langt tydeligere enn RC.
Unikt eierskap hjelper også vedlikehold ved å kommentere den ansvarlige eieren. Etter min mening er det langt enklere å administrere unik eier enn å administrere flere eiere. Egentlig det jeg alltid gjør i Swift, er bare å spesifisere implisitt unik eier og spore dem manuelt av en eller annen konvensjon. Ville det ikke vært fint om kompilatoren gjorde dette for deg?
Swift 4 planlegger å introdusere flere nye funksjoner som unikt eierskap, flyttesemantikk, skuespillermodell og C ++ inter-op-støtte. Men jeg er ikke sikker på hvordan de kan garantere Rust-sikkerhetsnivå med funksjonene på dagens språklige semantikk. Så jeg er fortsatt ikke veldig positiv til sikkerhetsnivået til Swift. C ++ inter-op kan være et stort salgssted. Uansett er dette nesten den eneste grunnen til at jeg tror Swift 4 kan være en potensiell konkurrent til Rust for C / C ++ -markedet.
Swift har også proffer. Som fornuftigere (etter min mening) navngivningskonvensjon og tydelig syntaks (etter min mening), dedikert IDE, garantert utvikling og bærekraft av verdens rikeste supporter (men dette introduserer også politisk spørsmål om støttet plattform). Samlet sett har den bedre UI / UX, men jeg tiltrekkes fortsatt mer av Rusts sikkerhet og konseptuelle skjønnhet …
P.S. Det var faktisk mulig å lage en dinglende peker i den tidlige versjonen av Swift 2.x med bare sikker konstruksjon som `deinit` og svak-ref. Men jeg er ikke sikker på nå og i fremtiden.
P.S. 2. Det ser ut til at de lappet smutthullet. I Swift 3 vil du få et runtime-unntak hvis du prøver å gjøre en svak referanse i `deinit`.
Svar
Jeg hadde nylig lest om swift-3.x, men jeg Jeg har vært Rust-fanboy i god tid, og jeg * vil * virkelig at Rust skal lykkes som systemspråk.
Svaret på spørsmålet ditt vil være et betinget ja, hvorfor? Dette er fordi raskt overlapper et betydelig rom med rust når det gjelder opprinnelig applikasjonsprogrammering.Det er en sterk kontrast mellom språkene når det gjelder designfilosofi og brukstilfeller i systemprogrammering (og noen sanntids brukstilfeller)
Rust er designet på C ++ – filosofiene for de fleste deler, noe som gjør mulig å gjøre veldig høytytende databehandling og vanvittig optimaliserbare kompilatorer (en nisje som jeg ikke har sett mange moderne språk konkurrere mot)
- “Nullkostnadsabstraksjoner”
- Dette er spesielt viktig når du skriver kjerner eller kjerneverktøy fordi de må optimaliseres så mye som mulig for å få den siste biten av ytelse.
- I kjapphet kan du kanskje gjøre de fleste optimaliseringer, men ikke alle, der er en språkbarriere for mengden optimalisering som kan oppnås (for eksempel gjetter jeg at vi trygt kunne anta at mest referansetelling er atomisk i rask, men i rust kan du velge mellom Rc & Arc-typer, så ikke betal for hva du ikke bruker).
- “Rust-pekermodellen”
- Rust-program s er designet for å eliminere de fleste kildene til krasj fra koden din gjennom eierskap, lån og flytting av semantikk, og det verifiserer dermed statisk at enhver ressurs bare har en unik eier på et gitt tidspunkt. Dette gjør det også enkelt for to av nedenstående brukssaker.
- Slik isolerer du krasjbare deler av programmet (usikre)
- Slik har du sikker samtidighet når du skriver kode
- Swift er mye mer lik C ++ i denne forbindelse siden det bare utsetter de sterke (shared\_ptr), svake (weak\_ptr) og ikke-eiere pekere (påtrengende\_ptr) for programmereren og gir dem kontrollen til (ab) å bruke dem i koden deres, så definitivt bedre kontroll enn Java, men absolutt mindre sikkerhet
- «Enumerations»
- Rust har rike enumer som ligner ADT i Haskell (om enn ikke så kraftige), men likevel muliggjør vakker design av Finite State Machines (FSM) hvis du tenker på C som har veldig dårlig støtte for å skrive FSM.
- Swift har også vakre oppføringer som ligner på Java, som jeg synes er mye kraftigere siden vi kan definere oppførsel for enums.
- “Closures” – Dette er den eneste funksjonen som skiller ethvert moderne språk fra de arkaiske. Både Rust og Swift støtter nedleggelser, men rustmodellen gjør at du kan resonnere om eierskapet til «closed over» -variablene og derved sikre sikkerhet. På den andre siden hadde Swift-nedleggelser fått noen overraskelser til og med erfarne programmerere.
- Problemene med Rust
- Svært enkle datastrukturer som dobbeltkoblede lister kan ikke eksistere i rust, bare fordi av eierskapssemantikken (vi er tvunget til å bruke Rc / Arc for denne enkle datastrukturen) irriterer dette noen mennesker.
- I henhold til programmeringserfaring når det er en funksjon på et populært språk, vil folk ha en tendens til å misbruke dem, i Rust er de usikre blokkene definitivt misbruk av mennesker som ikke er villige til å kjempe mot lånekontrollen, som dessverre utgjør en stor prosentandel
- Brudd på uforanderlighet i standardbiblioteket, hvis ikke- triviell kode må skrives i Rust. Vi må ha datatyper som Cell / RefCell teknisk sett kan brukes som bakdører mot den sterke sikkerheten språket ser ut til å gi. Når det er sagt, gir biblioteket mange sikkerhetsprimitiver mens vi bruker disse datatypene, slik at vi ikke skyter oss selv i foten.
- Til slutt ser Rust ut til å innrømme at selv om det er mer tryggere enn C ++, de forhatte C ++ – funksjonene må også innlemmes slik at vi kan tillate adopsjon og gjøre det mulig for folk å skrive ikke-triviell kode. Dette er trist, men dessverre også sannheten.
- Problemene med Swift
- Den gjennomgripende bruken av ARC overalt – noe som er et brudd på “du betaler ikke for det du ikke gjør bruk ”filosofi i C ++ (kan adresseres i rask 5.x (se [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model) )
- Mangel på veldig brukervennlige asynkrone primitiver lever async / await / coroutines (som er salgsargumentet for språk som go), kan være raskt 5.x vil adressere det
- Noen ganger “klasse ”Erklæringer kan unødvendig tvinge deg til å bruke referansetyper der du faktisk foretrekker en verditype (struct)
- Egenskaper i Rust er teknisk (for de fleste tilfeller) en bedre løsning for 3 forskjellige raske enheter (utvidelser, protokoller & arv)
Så jeg antar at det absolutt er en nisje for rask å okkupere, folk som er gode C ++ programmerere kan komme seg raskt til Swift / Rust. Men jeg tror Swift vil få mer trekkraft med applikasjonsutviklere og Rust med System-programmerere. Deres respektive nisjer vil fortsette å eksistere til tross for betydelig overlapping.