Beste antwoord
Absoluut “Nee” voor Swift 1, 2, 3. Maar misschien wel voor Swift 4 Hoe dan ook, ik ben nog steeds niet erg positief.
Ik neem aan dat Rusts doelmarkt C / C ++ programmeurs is.
Het belangrijkste kenmerk van Rust is extreme veiligheid zonder overhead . Tot nu toe faalt Swift hier. Swift brengt altijd een soort overhead met zich mee in zowel ruimte als tijd als je ref-types gebruikt. Dit is verplicht en onvermijdelijk.
Overheadkosten zijn belangrijk omdat alleen al door veel talen wordt gezorgd voor “veiligheid”. Bijvoorbeeld C #. Dat is naar mijn mening een echte concurrent van Swift. C # biedt al een bepaald veiligheidsniveau. En het is al met succes vervangen door C / C ++ in een bepaald segment van de markt, maar niet helemaal omdat het een hoop overhead introduceert. Zowel in ruimte als in tijd. Hoewel de Swift-compiler een deel van de RC-overhead kan wegnemen, hangt het van geluk af van optimalisatie. In sommige ongelukkige situaties wordt de overhead enorm.
En het veiligheidsniveau is ook anders. Het is hetzelfde dat beide talen geen loshangende aanwijzer in een veilige context kunnen garanderen. Maar dat is alles wat Swift kan bieden, en dit is een zeer zwakke garantie in vergelijking met wat Rust biedt. Op resourceniveau kunnen Swift-ref-types op elk moment lekken en hebben ze altijd menselijke zorg nodig. Compiler kan geen cyclische refs detecteren. Swift staat ook het onbeperkt delen van veranderlijk geheugen tussen threads toe (vanwege een gebrek aan gelijktijdige taalgebruik), wat betekent dat er geen veiligheid is in de gegevensrace.
Daarentegen biedt Rust uniek eigendom een volledig statische garantie dat er geen bronnen lekken. Geen enkele datarace is ook statisch gegarandeerd.
Wat ik de afgelopen jaren voelde tijdens het gebruik van Swift, is dat de taal niet echt veilig is als het gaat om resourcebeheer en datarace. En verplichte RC-overhead is echt een grote zorg in prestatie-kritische code. Swift maakt reclame voor de prestaties van waardetypes, maar in feite moet je er altijd een aantal ref-types in gebruiken om veilig in heap toe te wijzen. Swift adverteert met de slimme RC-elision van de compiler, maar het is gebaseerd op geluk, dus onvergelijkbaar gegarandeerd nulkosten van Rust.
Waarom is veiligheid belangrijk? Omdat je niet productief kunt zijn in een mijnenveld. Om productief te zijn, moet u verminderen waar u om geeft. In Swift moet je altijd zorgen voor cycli en gegevensrace en overhead, gewoon om niet te worden gedood omdat niemand om je geeft. In Rust kan de compiler dit voor u verzorgen. Je vergeet gewoon (veel van) safty, en volgt de compiler wat het ook klaagt, dan ben je veilig. Net als GC-taalgebruikers geven niet om hangende aanwijzingen.
Ook doet determinisme er toe. Het volgen van de levensduur van een object is zelden vereist, maar soms erg belangrijk. Swift RC biedt deinit-timing, maar omdat het gedeeld eigendom is, is de timing van overlijden meestal erg vaag. Een dergelijke timing bij uniek eigendom is relatief veel duidelijker dan bij RC.
Uniek eigendom helpt ook bij het onderhoud door de verantwoordelijke eigenaar te annoteren. Naar mijn mening is het beheren van een unieke eigenaar veel eenvoudiger dan het beheren van meerdere eigenaren. Wat ik eigenlijk altijd doe in Swift, is gewoon de impliciete unieke eigenaar specificeren en deze handmatig volgen volgens een bepaalde conventie. Zou het niet fijn zijn als de compiler dit voor je doet?
Swift 4 is van plan verschillende nieuwe functies te introduceren, zoals uniek eigendom, verplaatsingssemantiek, actormodel en C ++ inter-op-ondersteuning. Maar ik weet niet zeker hoe ze het Rust-veiligheidsniveau kunnen garanderen met de kenmerken van de huidige taalsemantiek. Dus ik ben nog steeds niet erg positief over het veiligheidsniveau van Swift. C ++ inter-op zou een groot verkooppunt kunnen zijn. Hoe dan ook, dit is bijna de enige reden waarom ik denk dat Swift 4 een potentiële concurrent van Rust kan zijn voor de C / C ++ -markt.
Swift heeft ook voordelen. Zoals een gezondere (naar mijn mening) naamgevingsconventie en duidelijke syntaxis (naar mijn mening), toegewijde IDE, gegarandeerde ontwikkeling en duurzaamheid door s werelds rijkste supporter (maar dit introduceert ook een politieke kwestie van ondersteund platform). Over het algemeen heeft het een betere UI / UX, maar ik voel me nog steeds meer aangetrokken tot Rusts veiligheid en conceptuele schoonheid …
P.S. Eigenlijk was het mogelijk om in de vroege versie van Swift 2.x een bungelende aanwijzer te maken met alleen een veilige constructie zoals deinit en zwakke ref. Maar ik weet het niet zeker voor nu en in de toekomst.
P.S. 2. Het lijkt erop dat ze de maas in de wet hebben hersteld. In Swift 3 krijg je een runtime-uitzondering als je probeert een zwakke referentie te maken in `deinit`.
Antwoord
Ik had onlangs gelezen over swift-3.x maar ik ben al geruime tijd een Rust fanboy, en ik wil * echt * dat Rust slaagt als systeemtaal.
Het antwoord op je vraag zal een voorwaardelijk ja zijn, waarom? Dit komt doordat swift een aanzienlijke ruimte overlapt met roest in termen van native applicatieprogrammering.Er is een schril contrast tussen de talen in termen van de ontwerpfilosofie en use cases in systeemprogrammering (en enkele real-time use-cases)
Rust is voor de meeste onderdelen ontworpen volgens de C ++ filosofieën, wat maakt mogelijk om zeer krachtige computers en waanzinnig optimaliseerbare compilers te doen (een niche waar ik niet veel moderne talen tegen heb zien concurreren)
- “Kosteloze abstracties”
- Dit is vooral belangrijk tijdens het schrijven van kernels of kernhulpprogrammas, omdat ze zo veel mogelijk moeten worden geoptimaliseerd om het laatste stukje prestatie eruit te halen.
- In snel tempo kun je misschien de meeste optimalisaties uitvoeren, maar niet alle, daar is een taalbarrière voor de hoeveelheid optimalisatie die kan worden bereikt (ik vermoed bijvoorbeeld dat we veilig kunnen aannemen dat de meeste referentietellingen atomair in snel zijn, maar in roest kun je kiezen tussen Rc- en Arc-typen, dus betaal niet voor wat je niet gebruikt).
- “Het Rust pointer model”
- Rust programma s zijn ontworpen om de meeste bronnen van crashes uit uw code te verwijderen door middel van eigendom, lenen en semantiek verplaatsen, vandaar dat het statisch verifieert dat een bron op een bepaald moment slechts één unieke eigenaar heeft. Dit maakt het ook gemakkelijk voor twee van de onderstaande use-cases.
- Hoe crashbare delen van het programma te isoleren (onveilig)
- Hoe veilige gelijktijdigheid te hebben bij het schrijven van code
- Swift lijkt in dit opzicht veel meer op C ++, omdat het alleen de sterke (shared\_ptr), zwakke (zwakke\_ptr) en niet-eigen verwijzingen (intrusive\_ptr) aan de programmeur blootstelt en hen de controle geeft om (ab) ze te gebruiken in hun code, dus absoluut betere controle dan Java, maar zeker minder veiligheid
- “Enumeraties”
- Rust heeft rijke enums die vergelijkbaar zijn met ADTs in Haskell (hoewel niet zo krachtig), maar toch maak een prachtig ontwerp van Finite State Machines (FSM) mogelijk als je denkt aan C, dat zeer slechte ondersteuning biedt voor het schrijven van FSM.
- Swift heeft ook prachtige opsommingen die lijken op Java, waarvan ik denk dat het veel krachtiger is omdat we gedrag voor enums.
- “Afsluitingen” – Dit is de enige eigenschap die elke moderne taal onderscheidt van de archaïsche taal. Zowel Rust als Swift ondersteunen sluitingen, maar het roestmodel stelt je in staat te redeneren over het eigendom van de “gesloten over” variabelen en daarmee de veiligheid te waarborgen. Aan de andere kant kunnen Swift-sluitingen zelfs voor ervaren programmeurs een paar verrassingen opleveren.
- De problemen met Rust
- Zeer eenvoudige gegevensstructuren zoals dubbel gelinkte lijsten kunnen niet bestaan in rust, alleen omdat van de eigendomssemantiek (we zijn gedwongen om Rc / Arc te gebruiken voor deze eenvoudige gegevensstructuur) dit irriteert sommige mensen.
- Volgens programmeerervaring zullen mensen, wanneer er een functie in een populaire taal is, geneigd zijn om misbruik ze, in Rust zijn de onveilige blokken zeker vatbaar voor misbruik voor de mensen die niet bereid zijn om tegen de leenchecker te vechten, wat helaas een groot percentage vormt
- Schendingen van onveranderlijkheid in de standaardbibliotheek, indien niet- triviale code moet in Rust worden geschreven, we hebben datatypes nodig zoals Cell / RefCell die technisch gezien kunnen worden gebruikt als achterdeurtjes tegen de sterke veiligheid die de taal lijkt te bieden. Dat gezegd hebbende, biedt de bibliotheek veel veiligheidsprimitieven tijdens het gebruik van deze gegevenstypen, zodat we onszelf niet in de voet schieten.
- Ten slotte lijkt Rust toe te geven dat, hoewel ze veiliger zijn dan C ++, sommige van de gehate C ++ -functies moeten ook worden opgenomen, zodat we acceptatie kunnen toestaan en mensen in staat stellen niet-triviale code te schrijven. Dit is triest, maar helaas ook de waarheid.
- De problemen met Swift
- Het alomtegenwoordige gebruik van ARC overal – wat een schending is van “je betaalt niet voor wat je niet betaalt use ”filosofie in C ++ (kan worden behandeld in swift 5.x (zie [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model) )
- Gebrek aan zeer eenvoudig te gebruiken asynchrone primitieven live async / await / coroutines (wat het verkoopargument is voor talen zoals go), kan snel zijn. 5.x zal dat aanpakken
- Soms zal class “Declaraties kunnen u onnodig dwingen referentietypes te gebruiken waar u eigenlijk de voorkeur zou kunnen geven aan een waardetype (struct)
- Traits in Rust is technisch gezien (in de meeste gevallen) een betere oplossing voor 3 verschillende snelle entiteiten (extensies, protocollen & overerving)
Dus ik denk dat er zeker een niche is voor Swift om te bezetten, mensen die goede C ++ programmeurs zijn, kunnen snel bij Swift / Rust komen. Maar ik denk dat Swift meer grip zal krijgen met applicatieontwikkelaars en Rust met systeemprogrammeurs. Hun respectieve niches zullen blijven bestaan ondanks aanzienlijke overlap.