Beste Antwort
Definitiv „Nein“ für Swift 1, 2, 3. Aber vielleicht ja für Swift 4 Trotzdem bin ich immer noch nicht sehr positiv.
Ich gehe davon aus, dass Rusts Zielmarkt C / C ++ – Programmierer sind.
Das Hauptmerkmal von Rust ist extreme Sicherheit ohne Overhead . Bis jetzt scheitert Swift hier. Swift ist immer mit einer Art räumlichen und zeitlichen Overhead verbunden, wenn Sie Ref-Typen verwenden. Dies ist obligatorisch und unvermeidbar.
Gemeinkosten sind wichtig, da viele Sprachen bereits nur „Sicherheit“ bieten. Zum Beispiel C #. Welches ist meiner Meinung nach der wahre Konkurrent von Swift. C # bietet bereits ein gewisses Maß an Sicherheit. Und es wurde bereits in einigen Marktsegmenten erfolgreich durch C / C ++ ersetzt, jedoch nicht vollständig, da es eine Menge Overhead einführt. In Raum und Zeit. Der Swift-Compiler kann zwar einen Teil des RC-Overheads eliminieren, hängt jedoch vom Glück bei der Optimierung ab. In einer unglücklichen Situation wird der Overhead enorm.
Und auch das Sicherheitsniveau ist unterschiedlich. Es ist dasselbe, dass beide Sprachen keinen baumelnden Zeiger im sicheren Kontext garantieren können. Aber das ist alles, was Swift bieten kann, und dies ist eine sehr schwache Garantie im Vergleich zu dem, was Rust bietet. Auf Ressourcenebene können Swift-Ref-Typen jederzeit auslaufen und benötigen stets menschliche Pflege. Der Compiler kann keine zyklischen Refs erkennen. Swift ermöglicht auch die unbegrenzte gemeinsame Nutzung von veränderlichem Speicher zwischen Threads (aufgrund mangelnder Parallelität der Sprache), was keine Sicherheit beim Datenrennen bedeutet.
Im Gegensatz dazu bietet Rust Unique Ownership eine vollständig statische Garantie dafür, dass keine Ressourcen verloren gehen. Kein Datenrennen ist auch statisch garantiert.
Was ich bei der Verwendung von Swift in den letzten Jahren empfunden habe, ist, dass die Sprache in Bezug auf Ressourcenmanagement und Datenrennen nicht wirklich sicher ist. Und obligatorischer RC-Overhead ist wirklich ein großes Problem bei leistungskritischem Code. Swift kündigt die Leistung von Werttypen an, aber tatsächlich müssen Sie immer einige Ref-Typen verwenden, um sie sicher im Heap zuzuweisen. Swift wirbt für die intelligente RC-Elision des Compilers, aber sie basiert auf Glück und ist daher unvergleichlich und garantiert keine Kosten für Rust.
Warum ist Sicherheit wichtig? Weil man in einem Minenfeld nicht produktiv sein kann. Um produktiv zu sein, müssen Sie reduzieren, was Sie beachten müssen. In Swift müssen Sie sich immer um Zyklen, Datenrennen und Overhead kümmern, um nicht getötet zu werden, weil sich niemand um Sie kümmert. In Rust kann und kümmert sich der Compiler darum. Sie vergessen einfach (viele) Sicherheitsvorkehrungen und folgen dem Compiler, was immer er sich beschwert, dann sind Sie in Sicherheit. Genau wie Benutzer in der GC-Sprache interessieren sich Zeiger nicht für baumelnde Zeiger.
Auch Determinismus spielt eine Rolle. Die Verfolgung der Objektlebensdauer ist selten erforderlich, aber manchmal sehr wichtig. Swift RC bietet „Deinit“ -Timing, aber da es sich um eine gemeinsame Eigentümerschaft handelt, ist das Timing des Todes normalerweise sehr vage. Ein solches Timing bei einem eindeutigen Eigentümer ist relativ viel klarer als bei RC.
Eindeutiger Besitz hilft auch bei der Wartung, indem der verantwortliche Eigentümer mit Anmerkungen versehen wird. Meiner Meinung nach ist die Verwaltung eines eindeutigen Eigentümers weitaus einfacher als die Verwaltung mehrerer Eigentümer. Eigentlich mache ich in Swift immer nur implizite eindeutige Eigentümer und verfolge sie manuell nach einer Konvention. Wäre es nicht schön, wenn der Compiler dies für Sie tun würde?
Swift 4 plant die Einführung mehrerer neuer Funktionen wie eindeutige Eigentumsverhältnisse, Verschiebungssemantik, Akteurmodell und C ++ – Inter-Op-Unterstützung. Ich bin mir jedoch nicht sicher, wie sie mit den Funktionen der aktuellen Sprachsemantik das Sicherheitsniveau von Rust gewährleisten können. Daher sehe ich das Sicherheitsniveau von Swift immer noch nicht sehr positiv. C ++ Inter-Op könnte ein großes Verkaufsargument sein. Auf jeden Fall ist dies fast der einzige Grund, warum ich denke, dass Swift 4 ein potenzieller Konkurrent von Rust für den C / C ++ – Markt sein kann.
Swift hat auch Profis. Wie sanere (meiner Meinung nach) Namenskonvention und klare Syntax (meiner Meinung nach), dedizierte IDE, garantierte Entwicklung und Nachhaltigkeit durch den reichsten Unterstützer der Welt (aber dies führt auch das politische Problem der unterstützten Plattform ein). Insgesamt hat es eine bessere Benutzeroberfläche / UX, aber ich bin immer noch mehr von Rusts Sicherheit und konzeptioneller Schönheit angezogen …
P.S. Tatsächlich war es möglich, in der frühen Version von Swift 2.x einen baumelnden Zeiger mit nur einem sicheren Konstrukt wie „deinit“ und „soft-ref“ zu erstellen. Aber ich bin mir für jetzt und die Zukunft nicht sicher.
P.S. 2. Es scheint, dass sie die Lücke geflickt haben. In Swift 3 erhalten Sie eine Laufzeitausnahme, wenn Sie versuchen, eine schwache Referenz in „deinit“ zu erstellen.
Antwort
Ich hatte kürzlich über swift-3.x gelesen, aber ich Ich bin schon seit einiger Zeit ein Rust-Fan, und ich * möchte * wirklich, dass Rust als Systemsprache erfolgreich ist.
Die Antwort auf Ihre Frage lautet: Ja, warum? Dies liegt daran, dass Swift in Bezug auf die native Anwendungsprogrammierung einen signifikanten Bereich mit Rost überlappt.Es gibt einen starken Kontrast zwischen den Sprachen in Bezug auf die Entwurfsphilosophie und Anwendungsfälle in der Systemprogrammierung (und einigen Echtzeitanwendungsfällen).
Rust basiert größtenteils auf den C ++ – Philosophien, was dazu führt Es ist möglich, sehr leistungsfähige Computer und wahnsinnig optimierbare Compiler zu erstellen (eine Nische, gegen die ich nicht viele moderne Sprachen gesehen habe).
- „Zero Cost Abstractions“
- Dies ist Dies ist besonders wichtig, wenn Sie Kernel oder Kerndienstprogramme schreiben, da diese so weit wie möglich optimiert werden müssen, um die letzte Leistung zu erzielen.
- In Kürze können Sie möglicherweise die meisten Optimierungen vornehmen, aber nicht alle ist eine Sprachbarriere für das Ausmaß der Optimierung, die erreicht werden kann (ich schätze zum Beispiel, wir können davon ausgehen, dass die meisten Referenzzählungen schnell atomar sind, aber bei Rost können Sie zwischen Rc- und Arc-Typen wählen, also zahlen Sie nicht dafür was Sie nicht verwenden).
- „Das Rostzeigermodell“
- Rostprogramm s wurden entwickelt, um die meisten Absturzquellen aus Ihrem Code durch Besitz-, Ausleih- und Verschiebungssemantik zu eliminieren. Daher wird statisch überprüft, ob eine Ressource zu einem bestimmten Zeitpunkt nur einen eindeutigen Eigentümer hat. Dies erleichtert auch zwei der folgenden Anwendungsfälle.
- Isolieren absturzfähiger Teile des Programms (unsicher)
- So stellen Sie beim Schreiben von Code eine sichere Parallelität her
- Swift ist in dieser Hinsicht C ++ viel ähnlicher, da es dem Programmierer nur die starken (shared\_ptr), schwachen (schwach\_ptr) und nicht besessenen Zeiger (intrusive\_ptr) zur Verfügung stellt und ihnen die Kontrolle gibt, in (ab) sie zu verwenden Ihr Code ist also definitiv besser zu kontrollieren als Java, aber sicherlich weniger sicher.
- „Aufzählungen“
- Rust hat umfangreiche Aufzählungen, die ADTs in Haskell ähneln (wenn auch nicht so mächtig), aber dennoch Aktivieren Sie das schöne Design von Finite State Machines (FSM), wenn Sie an C denken, das das Schreiben von FSM nur sehr schlecht unterstützt.
- Swift hat auch schöne Aufzählungen ähnlich wie Java, die meiner Meinung nach viel leistungsfähiger sind, da wir sie definieren können Verhalten für Aufzählungen.
- „Verschlüsse“ – Dies ist das einzige Merkmal, das jede moderne Sprache von den archaischen unterscheidet. Sowohl Rust als auch Swift unterstützen Verschlüsse. Mit dem Rostmodell können Sie jedoch über den Besitz der Variablen „Closed Over“ nachdenken und so die Sicherheit gewährleisten. Auf der anderen Seite können Swift-Schließungen selbst erfahrenen Programmierern einige Überraschungen bereiten.
- Die Probleme mit Rust
- Sehr einfache Datenstrukturen wie doppelt verknüpfte Listen können in Rost nicht existieren, nur weil In Bezug auf die Besitzersemantik (wir sind gezwungen, Rc / Arc für diese einfache Datenstruktur zu verwenden) ärgert dies einige Leute.
- Laut Programmiererfahrung tendieren die Leute dazu, wenn es eine Funktion in einer populären Sprache gibt Missbrauch sie, in Rust sind die unsicheren Blöcke definitiv missbrauchsanfällig für die Leute, die nicht bereit sind, gegen den Leihprüfer zu kämpfen, was leider einen großen Prozentsatz ausmacht.
- Verstöße gegen die Unveränderlichkeit in der Standardbibliothek, wenn nicht trivialer Code muss in Rust geschrieben werden. Wir brauchen Datentypen wie Cell / RefCell, die technisch als Hintertüren gegen die starke Sicherheit verwendet werden können, die die Sprache zu bieten scheint. Allerdings bietet die Bibliothek bei der Verwendung dieser Datentypen viele Sicherheitsgrundelemente, damit wir uns nicht in den Fuß schießen.
- Schließlich scheint Rust zuzugeben, dass einige von ihnen sicherer sind als C ++ Die verhassten C ++ – Funktionen müssen ebenfalls integriert werden, damit wir die Übernahme ermöglichen und es den Benutzern ermöglichen können, nicht trivialen Code zu schreiben. Das ist traurig, aber leider auch die Wahrheit.
- Die Probleme mit Swift
- Die allgegenwärtige Verwendung von ARC überall – was eine Verletzung von „Sie zahlen nicht für das, was Sie nicht tun Verwenden Sie die Philosophie in C ++ (kann in Swift 5.x behandelt werden (siehe [swift-evolution] RFC: Verhindern von Aufbewahrungszyklen (Speichereigentumsmodell) )
- Das Fehlen sehr einfach zu verwendender asynchroner Grundelemente live async / await / coroutines (was das Verkaufsargument für Sprachen wie go ist), kann schnell sein. 5.x wird diese
- Manchmal “-Klasse ansprechen Deklarationen können Sie unnötig dazu zwingen, Referenztypen zu verwenden, bei denen Sie möglicherweise tatsächlich einen Werttyp (Struktur) bevorzugen.
- Merkmale in Rust sind technisch (in den meisten Fällen) eine bessere Lösung für 3 verschiedene schnelle Entitäten (Erweiterungen, Protokolle) & Vererbung)
Ich denke, es gibt definitiv eine Nische, die schnell besetzt werden kann. Leute, die gute C ++ – Programmierer sind, können schnell zu Swift / Rust gelangen. Aber ich denke, Swift wird mehr Traktion bekommen mit Anwendungsentwickler und Rust mit Systemprogrammierern. Ihre jeweiligen Nischen bleiben trotz erheblicher Überschneidungen bestehen.