La mejor respuesta
Definitivamente «No» para Swift 1, 2, 3. Pero tal vez sí para Swift 4 . De todos modos, todavía no soy muy positivo.
Supongo que el mercado objetivo de Rust son los programadores C / C ++.
La característica clave de Rust es seguridad extrema sin gastos generales . Hasta ahora, Swift falla aquí. Swift siempre implica una especie de sobrecarga tanto en el espacio como en el tiempo cuando usa ref-types. Esto es obligatorio e inevitable.
La sobrecarga es importante porque muchos idiomas ya ofrecen solo «seguridad». Por ejemplo, C #. Que es el verdadero competidor de Swift en mi opinión. C # ya ofrece cierto nivel de seguridad. Y ya ha sido reemplazado con éxito C / C ++ en algún segmento del mercado, pero no del todo porque introduce muchos gastos generales. Tanto en el espacio como en el tiempo. Aunque el compilador Swift puede eludir parte de la sobrecarga de RC, depende de la suerte en la optimización. En alguna situación desafortunada, los gastos generales se vuelven enormes.
Y el nivel de seguridad también es diferente. Es lo mismo que ambos idiomas pueden garantizar que no haya punteros colgando en un contexto seguro. Pero eso es todo lo que Swift puede proporcionar, y esta es una garantía muy débil en comparación con lo que ofrece Rust. A nivel de recursos, los tipos de referencia Swift pueden filtrarse en cualquier momento y siempre necesitan atención humana. El compilador no puede detectar referencias cíclicas. Swift también permite el intercambio ilimitado de memoria mutable entre subprocesos (debido a la falta de concurrencia nativa del lenguaje), lo que significa que no hay seguridad en la carrera de datos.
Por el contrario, la propiedad exclusiva de Rust proporciona una garantía totalmente estática de que no se pierden recursos. Sin carrera de datos también está garantizada estáticamente.
Lo que sentí al usar Swift durante los últimos años es que el lenguaje no es realmente seguro cuando se trata de administración de recursos y carrera de datos. Y la sobrecarga de RC obligatoria es realmente una gran preocupación en el código de rendimiento crítico. Swift anuncia el rendimiento de los tipos de valor, pero, de hecho, siempre debe usar algunos tipos de referencia para asignar en el montón de forma segura. Swift anuncia la elisión inteligente de RC del compilador, pero se basa en la suerte, por lo que el costo cero garantizado incomparable de Rust.
¿Por qué es importante la seguridad? Porque no puedes ser productivo en un campo minado. Para ser productivo, tienes que reducir lo que te importa. En Swift siempre tienes que cuidar los ciclos y la carrera de datos y los gastos generales para no morir porque nadie se preocupa por ti. En Rust, el compilador puede cuidar esto por ti. Simplemente olvídese de (muchos de) la seguridad y siga al compilador lo que sea que se queja, entonces está seguro. Al igual que a los usuarios del lenguaje GC no les importan los punteros colgantes.
Además, el determinismo sí importa. El seguimiento de la vida útil del objeto rara vez se requiere, pero a veces es muy importante. Swift RC proporciona una sincronización «deinit», pero como es propiedad compartida, la sincronización de la muerte suele ser muy vaga. Este momento en la propiedad única es relativamente más claro que RC.
La propiedad única también ayuda al mantenimiento al anotar al propietario responsable. En mi opinión, administrar un propietario único es mucho más fácil que administrar varios propietarios. En realidad, lo que siempre hago en Swift es especificar un propietario único implícito y rastrearlo manualmente mediante alguna convención. ¿No sería bueno si el compilador hiciera esto por usted?
Swift 4 planea introducir varias características nuevas como propiedad única, semántica de movimientos, modelo de actor y soporte inter-op de C ++. Pero no estoy seguro de cómo pueden garantizar el nivel de seguridad de Rust con las características de la semántica del lenguaje actual. Así que todavía no soy muy positivo sobre el nivel de seguridad de Swift. La interfaz C ++ podría ser un gran punto de venta. De todos modos, esta es casi la única razón por la que creo que Swift 4 puede ser un competidor potencial de Rust para el mercado C / C ++.
Swift también tiene ventajas. Tales como una convención de nomenclatura más sana (en mi opinión) y una sintaxis clara (en mi opinión), IDE dedicado, desarrollo garantizado y sostenibilidad por parte del partidario más rico del mundo (pero esto también introduce un problema político de la plataforma compatible). En general, tiene una mejor interfaz de usuario / UX, pero todavía me atrae más la seguridad y la belleza conceptual de Rust …
P.D. En realidad, era posible hacer un puntero colgante en la versión anterior de Swift 2.x solo con construcciones seguras como `deinit` y débil-ref. Pero no estoy seguro ni ahora ni en el futuro.
P.D. 2. Parece que arreglaron la laguna. En Swift 3, obtendrás una excepción de tiempo de ejecución si intentas hacer una referencia débil en `deinit`.
Respuesta
Recientemente leí sobre swift-3.x pero no He sido un fanático de Rust durante bastante tiempo, y * realmente * quiero que Rust tenga éxito como lenguaje de sistemas.
La respuesta a tu pregunta será un sí condicional, ¿por qué? Esto se debe a que Swift superpone un espacio significativo con rust en términos de programación de aplicaciones nativas.Existe un marcado contraste entre los lenguajes en términos de la filosofía de diseño y los casos de uso en la programación de sistemas (y algunos casos de uso en tiempo real)
Rust está diseñado sobre la base de las filosofías C ++ para la mayoría de las partes, lo que hace posible hacer computación de muy alto rendimiento y compiladores increíblemente optimizables (un nicho con el que no he visto competir a muchos lenguajes modernos)
- «Abstracciones de costo cero»
- Esto es especialmente importante mientras escribe kernels o utilidades principales porque deben optimizarse al máximo posible para obtener el último rendimiento.
- En rápido, quizás pueda hacer la mayoría de las optimizaciones, pero no todas, es una barrera del idioma para la cantidad de optimización que se puede lograr (por ejemplo, supongo que podríamos asumir con seguridad que la mayoría de los recuentos de referencias son atómicos en rápido, pero en rust puede elegir entre los tipos Rc y Arc, así que no pague por lo que no usa).
- «El modelo de puntero de Rust»
- Programa de Rust Los s están diseñados para eliminar la mayoría de las fuentes de fallas de su código a través de la propiedad, el préstamo y la semántica de movimiento, por lo tanto, verifica estáticamente que cualquier recurso tiene un solo propietario único en un momento dado. Esto también facilita las cosas para dos de los siguientes casos de uso.
- Cómo aislar partes del programa que pueden bloquearse (inseguras)
- Cómo tener una simultaneidad segura al escribir código
- Swift es mucho más similar a C ++ en este aspecto, ya que solo expone los punteros fuerte (shared\_ptr), débil (débil\_ptr) y sin dueño (intrusive\_ptr) al programador y les da el control para (ab) usarlos su código, definitivamente mejor control que Java pero ciertamente menos seguridad
- «Enumeraciones»
- Rust tiene ricas enumeraciones que son similares a los ADT en Haskell (aunque no tan poderosas), pero sin embargo habilite un hermoso diseño de Finite State Machines (FSM) si piensa en C, que tiene un soporte muy deficiente para escribir FSM.
- Swift también tiene hermosas enumeraciones similares a Java, que creo que es mucho más poderoso ya que podemos definir comportamiento para enumeraciones.
- «Cierres»: esta es la característica única que distingue cualquier lenguaje moderno de los arcaicos. Tanto Rust como Swift admiten cierres, pero el modelo Rust le permite razonar sobre la propiedad de las variables «cerradas» y, por lo tanto, garantiza la seguridad. Por otro lado, los cierres de Swift pueden dar algunas sorpresas incluso a programadores experimentados.
- Los problemas con Rust
- Las estructuras de datos muy simples como las listas doblemente enlazadas no pueden existir en rust, solo porque de la semántica de propiedad (estamos obligados a usar Rc / Arc para esta estructura de datos simple) esto molesta a algunas personas.
- Según la experiencia de programación, cuando hay una característica en un lenguaje popular, la gente tiende a abusar de ellos, en Rust los bloques inseguros son definitivamente propensos al abuso para las personas que no están dispuestas a luchar contra el verificador de préstamos, que lamentablemente constituye un gran porcentaje
- Violaciones de inmutabilidad en la biblioteca estándar, si no El código trivial debe escribirse en Rust, necesitamos tener tipos de datos como Cell / RefCell que técnicamente se puedan usar como puertas traseras contra la fuerte seguridad que el lenguaje parece proporcionar. Habiendo dicho que la biblioteca proporciona una gran cantidad de primitivas de seguridad al usar estos tipos de datos para que no nos disparemos en el pie.
- Finalmente, Rust parece admitir que, aunque es más seguro que C ++, algunos de Las odiadas características de C ++ también deben incorporarse para que podamos permitir la adopción y permitir que las personas escriban código no trivial. Esto es triste, pero lamentablemente también es la verdad.
- Los problemas con Swift
- El uso generalizado de ARC en todas partes, que es una violación de “no paga por lo que no paga use ”filosofía en C ++ (se puede abordar en swift 5.x (consulte [swift-evolution] RFC: Prevención de ciclos de retención (modelo de propiedad de memoria) )
- La falta de primitivas asincrónicas muy fáciles de usar live async / await / coroutines (que es el punto de venta para lenguajes como go), puede ser rápido 5.x abordará eso
- A veces, «class «Las declaraciones pueden forzarlo innecesariamente a usar tipos de referencia donde en realidad podría preferir un tipo de valor (estructura)
- Traits in Rust es técnicamente (para la mayoría de los casos) una mejor solución para 3 entidades rápidas diferentes (extensiones, protocolos & herencia)
Así que creo que definitivamente hay un nicho para que lo ocupe Swift, las personas que son buenos programadores de C ++ pueden llegar a Swift / Rust rápidamente. Pero creo que Swift obtendrá más tracción con desarrolladores de aplicaciones y programadores de Rust with System. Sus respectivos nichos seguirán existiendo a pesar de una superposición significativa.