Bedste svar
Absolut “Nej” til Swift 1, 2, 3. Men måske ja til Swift 4 Under alle omstændigheder er jeg stadig ikke særlig positiv.
Jeg antager, at Rusts målmarked er C / C ++ programmører.
Rustets nøglefunktion er ekstrem sikkerhed uden overhead . Indtil nu fejler Swift her. Swift involverer altid en slags overhead i både rum og tid, når du bruger ref-typer. Dette er obligatorisk og uundgåelig.
Overhead er vigtigt, fordi bare “sikkerhed” allerede leveres af mange sprog. For eksempel C #. Hvilket er den virkelige sande konkurrent til Swift efter min mening. C # leverer allerede et vist sikkerhedsniveau. Og det er allerede med succes blevet erstattet C / C ++ i et eller andet markedssegment, men ikke helt, fordi det introducerer en række overhead. I både rum og tid. Selvom Swift-kompilator kan redde noget af RC-omkostninger, men det afhænger af held på optimering. I en eller anden uheldig situation bliver omkostningerne enorme.
Og sikkerhedsniveauet er også anderledes. Det er det samme, at begge sprog ikke kan garantere nogen dinglende markør i sikker sammenhæng. Men det er alt, hvad Swift kan tilbyde, og dette er en meget svag garanti sammenlignet med, hvad Rust giver. På ressourceniveau kan Swift ref-typer lækker når som helst og har altid brug for menneskelig pleje. Compileren kan ikke registrere cykliske refs. Swift tillader også ubegrænset deling af foranderlig hukommelse mellem tråde (på grund af manglende sproglig indfødt samtidighed), hvilket ikke betyder nogen sikkerhed ved dataløb.
Derimod giver Rust unikt ejerskab fuldstændig statisk garanti for ingen ressourceudslip. Intet dataløb er også garanteret statisk.
Hvad jeg følte, mens jeg brugte Swift i de sidste par år, er sproget ikke rigtig sikkert, når det kommer til ressourcestyring og dataløb. Og obligatorisk RC-overhead er virkelig et stort problem i ydeevnskritisk kode. Swift annoncerer præstation for værdityper, men faktisk skal du altid bruge nogle ref-typer i den til at allokere i bunke sikkert. Swift annoncerer kompilatorens smarte RC elision, men det er baseret på held, så uforlignelig garanteret nul pris på Rust.
Hvorfor betyder sikkerhed noget? Fordi du ikke kan være produktiv i et minefelt. For at være produktiv skal du reducere, hvad du skal bekymre dig om. I Swift skal du altid passe cyklusser og dataløb og overhead for ikke at blive dræbt, fordi ingen bryr sig om dem for dig. I Rust kan kompilatoren passe på dette for dig. Du glemmer bare (mange af) sikkerheden og følger kompilatoren uanset hvad den klager, så er du sikker. Ligesom GC-sprogbrugere er ligeglade med dinglende henvisninger.
Også determinisme betyder noget. Sporing af objektets levetid er sjældent påkrævet, men nogle gange meget vigtigt. Swift RC giver deinit timing, men da det er delt ejerskab, er dødstidspunktet normalt meget vagt. Sådan timing i unikt ejerskab er relativt langt klarere end RC.
Unikt ejerskab hjælper også vedligeholdelse ved at kommentere den ansvarlige ejer. Efter min mening er det meget nemmere at administrere unik ejer end at administrere flere ejere. Faktisk er det, jeg altid gør i Swift, bare at specificere implicit unik ejer og spore dem manuelt ved hjælp af en konvention. Ville det ikke være rart, hvis kompilatoren gjorde dette for dig?
Swift 4 planlægger at introducere flere nye funktioner som unikt ejerskab, flyt semantik, skuespillermodel og C ++ inter-op support. Men jeg er ikke sikker på, hvordan de kan garantere Rust-sikkerhedsniveau med funktionerne på det nuværende sprogsemantik. Så jeg er stadig ikke særlig positiv til sikkerhedsniveauet for Swift. C ++ inter-op kan være et stort salgssted. Under alle omstændigheder er dette næsten den eneste grund til, at jeg tror, at Swift 4 kan være en potentiel konkurrent til Rust til C / C ++ -markedet.
Swift har også fordele. Som fornuftigere (efter min mening) navngivningskonvention og klar syntaks (efter min mening), dedikeret IDE, garanteret udvikling og bæredygtighed af verdens rigeste tilhænger (men dette introducerer også politisk spørgsmål om understøttet platform). Samlet set har den bedre UI / UX, men jeg bliver stadig mere tiltrukket af Rusts sikkerhed og konceptuelle skønhed …
P.S. Faktisk var det muligt at lave en dinglende pointer i den tidlige version af Swift 2.x med kun sikker konstruktion som deinit og svag-ref. Men jeg er ikke sikker på nu og i fremtiden.
P.S. 2. Det ser ud til, at de lappede smuthullet. I Swift 3 får du en runtime-undtagelse, hvis du prøver at lave en svag reference i `deinit`.
Svar
Jeg havde for nylig læst om swift-3.x, men jeg Jeg har været Rust-fanboy i nogen god tid, og jeg * ønsker virkelig, at Rust skal få succes som systemsprog.
Svaret på dit spørgsmål vil være et betinget ja, hvorfor? Dette skyldes, at hurtig overlapper et betydeligt rum med rust med hensyn til native applikationsprogrammering.Der er en skarp kontrast mellem sprogene med hensyn til designfilosofi og brugssager i systemprogrammering (og nogle realtidsbrugssager)
Rust er designet til C ++ – filosofierne for de fleste dele, hvilket gør muligt at lave meget højtydende computing og sindssygt optimerbare compilers (en niche, som jeg ikke har set mange moderne sprog konkurrere mod)
- “Nul omkostningsabstraktion”
- Dette er især vigtig, mens du skriver kerner eller kerneværktøjer, fordi de skal optimeres til det maksimale mulige antal for at få den sidste bit ydeevne ud.
- I hurtig kan du måske udføre de fleste optimeringer, men ikke alle, der er en sprogbarriere for den optimeringsmængde, der kan opnås (for eksempel gætter jeg på, at vi med sikkerhed kunne antage, at de fleste referencetællinger er atomare i hurtig, men i rust kan du vælge mellem Rc & Arc-typer, så betal ikke for hvad du ikke bruger).
- “Rust-pointermodellen”
- Rust-program s er designet til at fjerne de fleste kilder til nedbrud fra din kode gennem ejerskab, låntagning og flytning af semantik, og det bekræfter derfor statisk, at enhver ressource kun har en unik ejer på et givet tidspunkt. Dette gør det også let for to af nedenstående brugssager.
- Sådan isoleres dele, der er i stand til at gå ned, (usikre)
- Sådan har du en sikker samtidighed, når du skriver kode
- Swift ligner meget mere C ++ i denne henseende, da det blot udsætter de stærke (shared\_ptr), svage (weak\_ptr) og ikke-ejede markører (påtrængende\_ptr) for programmøren og giver dem kontrol til (ab) at bruge dem i deres kode, så bestemt bedre kontrol end Java, men bestemt mindre sikkerhed
- “Optællinger”
- Rust har rige enums, der ligner ADTer i Haskell (omend ikke så kraftige), men alligevel aktiver smukt design af Finite State Machines (FSM), hvis du tænker på C, som har meget dårlig understøttelse af at skrive FSM.
- Swift har også smukke opregninger, der ligner Java, som jeg synes er meget kraftigere, da vi kan definere adfærd for enums.
- “Lukninger” – Dette er den eneste funktion, der adskiller ethvert moderne sprog fra de arkaiske. Både Rust og Swift understøtter lukninger, men rustmodellen giver dig mulighed for at begrunde ejerskabet af variablerne “lukket over” og derved sikre sikkerhed. På den anden side kunne Swift-lukninger fremkalde nogle få overraskelser på selv erfarne programmører.
- Problemer med rust
- Meget enkle datastrukturer som dobbeltkoblede lister kan ikke eksistere i rust, bare fordi af ejerskabssemantikken (vi er tvunget til at bruge Rc / Arc til denne enkle datastruktur) irriterer dette nogle mennesker.
- I henhold til programmeringserfaring, når der er en funktion på et populært sprog, vil folk have tendens til at misbruge dem, i Rust er de usikre blokke bestemt misbrugt for de mennesker, der ikke er villige til at kæmpe mod lånekontrollen, som desværre udgør en stor procentdel
- Overtrædelser af uforanderlighed i standardbiblioteket, hvis ikke trivial kode skal skrives i Rust, vi skal have datatyper som Cell / RefCell teknisk set kunne bruges som bagdøre mod den stærke sikkerhed, som sproget ser ud til at give. Når det er sagt, giver biblioteket en hel del sikkerhedsprimitiver, mens vi bruger disse datatyper, så vi ikke skyder os selv i foden.
- Endelig ser Rust ud til at indrømme, at selvom det er mere sikkert end C ++, synes nogle af de hadede C ++ – funktioner skal også inkorporeres, så vi kan tillade adoption og gøre det muligt for folk at skrive ikke-triviel kode. Dette er trist, men desværre også sandheden.
- Problemer med Swift
- Den gennemgribende brug af ARC overalt – hvilket er en krænkelse af “du betaler ikke for det, du ikke gør brug ”filosofi i C ++ (kan adresseres i hurtig 5.x (se [swift-evolution] RFC: Prevention Retain Cycles (Memory Ownership Model) )
- Mangel på meget brugervenlige asynkrone primitiver lever async / afventer / coroutines (som er salgsargumentet for sprog som go), kan være hurtig 5.x vil adressere det
- Nogle gange “klasse ”Erklæringer kan unødigt tvinge dig til at bruge referencetyper, hvor du faktisk foretrækker en værditype (struct)
- Egenskaber i Rust er teknisk set (i de fleste tilfælde) en bedre løsning til 3 forskellige hurtige enheder (udvidelser, protokoller & arv)
Så jeg antager, at der bestemt er en niche for hurtig at besætte, folk, der er gode C ++ – programmører, kan hurtigt komme til Swift / Rust. Men jeg tror, Swift vil få mere trækkraft med applikationsudviklere og Rust med systemprogrammerere. Deres respektive nicher vil fortsat eksistere på trods af betydelig overlapning.