7 ms·

Swift is not a competitor for Rust. It may be a competitor for Scala/Kotlin native or Go, but definitely not in the same performance league as Rust or C++. > H

Swift is not a competitor for Rust. It may be a competitor for Scala/Kotlin native or Go, but definitely not in the same performance league as Rust or C++. > Hopefully FP (functional programming) becomes more mainstream and take away all this burden of imperative languages like Rust. Pure FP is overrated. It is a nice academic model of computation, but it doesn't reflect the way how hardware works. Hardware is mutable and memory is limited. > It’s as difficult to learn as Haskell with complex syntax and semantics, but less powerful than C. This is a subjective opinion, not a fact. > as clean as Python :D :D :D

hopia 7y ago
Why would we need to limit our programming language abstractions to how the machines work underneath? Are there some stateful objects running around in the hardware? Just because the abstractions are detached from the hardware doesn't make these design patterns useless.
- yxhuvud 7y ago
  It is nice to have a connection between abstractions and hardware, because it makes it easier to reason about performance, which in turn makes it easier to achieve great performance. Now, not everybody actually need great performance, so some distance between hardware and abstraction is ok, but the amount depends on the use case.
  - hopia 7y ago
    Well, I agree, that's why we have both low and high level languages. High level languages, setting you free from the actual constraints of the underlying machine, allow you to define abstractions that can increase productivity greatly - that's their whole point of existence. I mean I don't see people complaining how you don't need to manually manage memory in SQL expressions.
    - pkolaczk 7y ago
      > I mean I don't see people complaining how you don't need to manually manage memory in SQL expressions. Well, they don't complain about not having to manually control the low-level bits of query execution, but later they frequently complain about performance problems. And then they add hints, setup buffer sizes, indexes, etc. Also, Rust (and to some degree C++) shows that you can have both very high-level, productive abstractions and low-level control. They call that zero-cost abstractions. The price to pay is a steeper learning curve, but not actual productivity or final performance. This is the most exciting part about Rust actually. I know how to write Kotlin, Scala, Java or C# code that's close in performance to C or C++. But this will be ugly, unsafe and hard to maintain, non-idiomatic code. Rust gives ability to write code that has almost Python-like expressivity but is still fast as if it were hand-optimised loops and pointers.
      - hopia 7y ago
        I'm not sure what your point is. I feel we may have a different idea of what very high level abstraction means in programming languages. Just about everything in software engineering is a compromise of sorts. Not knowing Rust or C++, I doubt they're as high level as something like Haskell or domain specific languages like SQL. Are monads first class citizens on C++? Type classes? Generalized Algebraic Data types? Parametric polymorphism & pattern matching? And so on. Would you really achieve the same amount of type level guarantees, equally concise control flow and concurrency on C++ with an equal amount of lines of code as would be possible on Haskell? If not, then there obviously is a productivity penalty. Just like on Haskell there is that performance penalty for not being able to drop down close to the metal. From what I can tell, these languages are not aiming to be very high abstraction level languages but instead solid systems level languages with some convenient abstractions and design patterns baked in from higher level languages. Sticking only to some zero-cost abstractions limits how high level abstractions it is possible to bring to the language. This in turn limits productivity.
        pkolaczk 7y ago
        Rust is very strong in its ability to build extremely powerful abstractions. With built-in compile-time procedural metaprogramming I could risk a statement that in some domains it may be actually even higher level than Haskell. Maybe its type system can't prove all the same guarantees as Haskell, but on the other hand, Haskell can't prove some guarantees that Rust can. They offer different set of abstractions with some overlap (e.g. first class type classes and ADTs). If is really hard to say which one is higher level. They are just different. Anyway, type safety is not the same as productivity. If it was, then nobody would use Python or Ruby and everybody would use Idris. I became much more productive quickly in Rust than Haskell.
- pkolaczk 7y ago
  Sure, I didn't say "useless". The post I was responding to was worded in such a way as if FP was the only suitable paradigm everybody should be using. FP is a nice and useful abstraction, but in some areas it is just too inefficient and despite all the great compiler progress of the last decade, it is still not there yet. FP languages are not in the same problem domain as system programming languages, so claiming FP should replace Rust is just ridiculous (and as a side note: Rust borrows many things from Haskell/Scala as well, so some FP is there).
dragonsh 7y ago
Swift is replacing Objective-C (a systems programming language a dialect of C). So indeed it is a direct competitor to Rust as it also provides hardware abstraction in a safe manner to replace C dialect. I will wait and watch when Rust will be used to control Apple or Android hardware as performant with similar safety guarantee like Swift or now Kotlin. It's also same as C++ used by Microsoft to provide underlying abstraction of hardware on Windows.
- pkolaczk 7y ago
  Kotlin and Swift fall short on memory management and both need runtime and GC. Currently Kotlin native is an order of magnitude slower than Rust, and Swift is also losing in benchmarks sometimes by 10x (although, not always - purely numeric Swift code is the same speed, because it is going through the same optimiser). As for hardware abstraction - not sure what is your point - Rust can use any C API.
  - pjmlp 7y ago
    It doesn't matter if improvements are still required, Apple is doing Swift, and Google is doing Kotlin on their mobile OSes, not Rust.
    - pkolaczk 7y ago
      Swift and Kotlin are used for application programming there, not systems programming. Also, Google does Rust as well. And Microsoft is slowly switching some pieces to Rust as well. These are big companies with many teams and use many different tools. Don't know how iOS, but Android does offer native APIs, so Kotlin is not the only officially supported choice there. Actually for anything that needs performance, e.g. games, Kotlin is a nogo.
      - pjmlp 7y ago
        Swift is used for systems programming on Apple platforms, as already replied on another thread. Google already mentioned a couple of times at Android Fireside Q&A sessions that it is weighting Kotlin/Native adoption on Android. And even if not, Rust isn't taking C++ and Java place on Android, specially after Project Treble changes, where drivers can even now be written in Java. Google and Microsoft are indeed adopting Rust, with some products already in production, although they are also among the major ISO C++ contributors, so it remains to be seen how much Rust love from their security teams will spread into the OS development teams. For example, I still look forward to the day that Azure Sphere actually offers something else other than C, in spite of its security sales speech.
pjmlp 7y ago
I would put it in another way, Rust is not a competitor to Swift on Apple's ecosystem. Apple is not adopting Rust to replace their C and Objective-C code, rather Swift, as they quite clear mention on the Swift documentation. > Swift is a successor to both the C and Objective-C languages. https://developer.apple.com/swift/ https://developer.apple.com/swift/

hopia 7y ago

Why would we need to limit our programming language abstractions to how the machines work underneath? Are there some stateful objects running around in the hardware? Just because the abstractions are detached from the hardware doesn't make these design patterns useless.

yxhuvud 7y ago
It is nice to have a connection between abstractions and hardware, because it makes it easier to reason about performance, which in turn makes it easier to achieve great performance. Now, not everybody actually need great performance, so some distance between hardware and abstraction is ok, but the amount depends on the use case.
- hopia 7y ago
  Well, I agree, that's why we have both low and high level languages. High level languages, setting you free from the actual constraints of the underlying machine, allow you to define abstractions that can increase productivity greatly - that's their whole point of existence. I mean I don't see people complaining how you don't need to manually manage memory in SQL expressions.
  - pkolaczk 7y ago
    > I mean I don't see people complaining how you don't need to manually manage memory in SQL expressions. Well, they don't complain about not having to manually control the low-level bits of query execution, but later they frequently complain about performance problems. And then they add hints, setup buffer sizes, indexes, etc. Also, Rust (and to some degree C++) shows that you can have both very high-level, productive abstractions and low-level control. They call that zero-cost abstractions. The price to pay is a steeper learning curve, but not actual productivity or final performance. This is the most exciting part about Rust actually. I know how to write Kotlin, Scala, Java or C# code that's close in performance to C or C++. But this will be ugly, unsafe and hard to maintain, non-idiomatic code. Rust gives ability to write code that has almost Python-like expressivity but is still fast as if it were hand-optimised loops and pointers.
    - hopia 7y ago
      I'm not sure what your point is. I feel we may have a different idea of what very high level abstraction means in programming languages. Just about everything in software engineering is a compromise of sorts. Not knowing Rust or C++, I doubt they're as high level as something like Haskell or domain specific languages like SQL. Are monads first class citizens on C++? Type classes? Generalized Algebraic Data types? Parametric polymorphism & pattern matching? And so on. Would you really achieve the same amount of type level guarantees, equally concise control flow and concurrency on C++ with an equal amount of lines of code as would be possible on Haskell? If not, then there obviously is a productivity penalty. Just like on Haskell there is that performance penalty for not being able to drop down close to the metal. From what I can tell, these languages are not aiming to be very high abstraction level languages but instead solid systems level languages with some convenient abstractions and design patterns baked in from higher level languages. Sticking only to some zero-cost abstractions limits how high level abstractions it is possible to bring to the language. This in turn limits productivity.
      - pkolaczk 7y ago
        Rust is very strong in its ability to build extremely powerful abstractions. With built-in compile-time procedural metaprogramming I could risk a statement that in some domains it may be actually even higher level than Haskell. Maybe its type system can't prove all the same guarantees as Haskell, but on the other hand, Haskell can't prove some guarantees that Rust can. They offer different set of abstractions with some overlap (e.g. first class type classes and ADTs). If is really hard to say which one is higher level. They are just different. Anyway, type safety is not the same as productivity. If it was, then nobody would use Python or Ruby and everybody would use Idris. I became much more productive quickly in Rust than Haskell.
pkolaczk 7y ago
Sure, I didn't say "useless". The post I was responding to was worded in such a way as if FP was the only suitable paradigm everybody should be using. FP is a nice and useful abstraction, but in some areas it is just too inefficient and despite all the great compiler progress of the last decade, it is still not there yet. FP languages are not in the same problem domain as system programming languages, so claiming FP should replace Rust is just ridiculous (and as a side note: Rust borrows many things from Haskell/Scala as well, so some FP is there).

dragonsh 7y ago

Swift is replacing Objective-C (a systems programming language a dialect of C). So indeed it is a direct competitor to Rust as it also provides hardware abstraction in a safe manner to replace C dialect. I will wait and watch when Rust will be used to control Apple or Android hardware as performant with similar safety guarantee like Swift or now Kotlin. It's also same as C++ used by Microsoft to provide underlying abstraction of hardware on Windows.

pkolaczk 7y ago
Kotlin and Swift fall short on memory management and both need runtime and GC. Currently Kotlin native is an order of magnitude slower than Rust, and Swift is also losing in benchmarks sometimes by 10x (although, not always - purely numeric Swift code is the same speed, because it is going through the same optimiser). As for hardware abstraction - not sure what is your point - Rust can use any C API.
- pjmlp 7y ago
  It doesn't matter if improvements are still required, Apple is doing Swift, and Google is doing Kotlin on their mobile OSes, not Rust.
  - pkolaczk 7y ago
    Swift and Kotlin are used for application programming there, not systems programming. Also, Google does Rust as well. And Microsoft is slowly switching some pieces to Rust as well. These are big companies with many teams and use many different tools. Don't know how iOS, but Android does offer native APIs, so Kotlin is not the only officially supported choice there. Actually for anything that needs performance, e.g. games, Kotlin is a nogo.
    - pjmlp 7y ago
      Swift is used for systems programming on Apple platforms, as already replied on another thread. Google already mentioned a couple of times at Android Fireside Q&A sessions that it is weighting Kotlin/Native adoption on Android. And even if not, Rust isn't taking C++ and Java place on Android, specially after Project Treble changes, where drivers can even now be written in Java. Google and Microsoft are indeed adopting Rust, with some products already in production, although they are also among the major ISO C++ contributors, so it remains to be seen how much Rust love from their security teams will spread into the OS development teams. For example, I still look forward to the day that Azure Sphere actually offers something else other than C, in spite of its security sales speech.

pjmlp 7y ago

I would put it in another way, Rust is not a competitor to Swift on Apple's ecosystem. Apple is not adopting Rust to replace their C and Objective-C code, rather Swift, as they quite clear mention on the Swift documentation. > Swift is a successor to both the C and Objective-C languages. https://developer.apple.com/swift/ https://developer.apple.com/swift/