7 ms·

I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross plat

by dcow 4y ago

I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. And that's coming from a Rust fan. It will be interesting to see how effective this rewrite is.

kitsunesoba 4y ago
I would love to be able to write cross-platform desktops apps in Swift. The language isn't perfect of course but I enjoy it a lot more than the alternatives I've tried. That possibility is still a ways down the road of course but Foundation getting a cross platform rewrite is a nice step in that direction.
- rattray 4y ago
  If you or others on this thread are interested in working on a Swift compiler for Windows, please reach out to me :) a good friend is hiring a team to make this happen.
  - Someone 4y ago
    How will that be different from Apple’s Swift toolchain for Windows (https://www.swift.org/blog/swift-on-windows/ https://www.swift.org/blog/swift-on-windows/)?
    - rattray 4y ago
      https://youtu.be/bOMQiMxh5Bc?t=430 https://youtu.be/bOMQiMxh5Bc?t=430 relevant listen is about 2min long
      - Someone 4y ago
        To me, that sounds as if most of the work would not be on the compiler but on improving the development experience (IDE, debugging support). On the other hand, your comment said ”working on _a_ Swift compiler for Windows”. To me, that sounded like a new compiler, not adding missing features to the existing one. Which of the two is it?
theLiminator 4y ago
Afaik Swift is pretty close to using Rc and Arc everywhere. Does swift do some more escape analysis than Rust?
- janef0421 4y ago
  Swift only uses reference counting when working with objects; Structs are optimised using copy-on-write. There's currently work on implementing move and ownership semantics, similar to Rust, but opt-in rather than by default.
  - meindnoch 4y ago
    Ummm… No. Swift structs are just like C structs (from a memory perspective). The copy-on-write thing is implemented manually by storing a private refcounted object in your struct. See the implementation of Array for example: https://github.com/apple/swift/blob/main/stdlib/public/core/Array.swift https://github.com/apple/swift/blob/main/stdlib/public/core/... There’s no magical copy-on-write mechanism at the language level.
    - jshier 4y ago
      I don't know why this is downvoted, it's true. There is no automatic copy on write optimization in Swift. It's a manual optimization that expensive types like Array implement manually.
      - meindnoch 4y ago
        >I don't know why this is downvoted, it's true. I know, right? Some people are pretty insecure…
- manmal 4y ago
  I haven’t read that much on Rust, but that should be pretty much it. Swift has an emphasis on value types, which often are stored on the stack, but only up to a certain size. Copy-on-write makes this feasible - often, those value types are passed by reference until a write actually occurs, but that’s opaque to the dev. Value types can have pointers to reference-counted types - if a value type is passed/copied, any pointer it owns is retained (weirdly enough, they claim that value types have no „lifetime“, but at some point those refs have to be released - we just have to trust the compiler in this).
deleted 4y ago
[deleted]
etse 4y ago
How would you compare Swift with Kotlin in terms of being a good stand-in for high-level Rust? I've not paid attention to Kotlin in a while, but it seems like there's more progress at supporting Kotlin across more platforms (Kotlin native, web?, etc). I'm curious if people feel that the language features and design are at about parity, or if one is significantly stronger/weaker.
- eatonphil 4y ago
  Swift has the distinction (for better and worse) of not being tied to the JVM.
  - dcow 4y ago
    Kotlin-native is an effort to compile directly to your target non-jvm machine.
- dcow 4y ago
  I haven't seriously used Kotlin in 4-5 years. I too was excited about it supporting native compiles and web assembly but I have no firsthand experience with how far those efforts got.
- manmal 4y ago
  Last time I toyed with Kotlin Multiplattform (bit less than a year ago) it provided only really weird Objective-C bindings for use in iOS/macOS. Like, a statically defined List turned into an Obj-C iterator. Enum and sealed classes were quite problematic either - I honestly would not consider using KMM for anything but a PoC. BTW, JetBrains recently sunsetted AppCode, so they are bleeding their Swift talent now. I suspect that doesn’t bode so well for Kotlin‘s Swift interop.
- neonsunset 4y ago
  Another scenario where an often missed and underrated choice would be C#. Nowadays it runs everywhere and supports a variety of deployment targets (relying on local runtime, packaging it together into a single somewhat compact binary, natively compiling the code (NativeAOT, it's good but has some limitations) or mixing and matching all of the above). It is also one of the best high-level languages to write performance-oriented code with, especially so with .NET 7 which allows writing cross-platform SIMD code in a similar fashion to Rust's 'portable-simd' crate.
rattray 4y ago
Interesting. Asking as someone who's never programmed with Swift or Rust, but is familiar with the syntax/ideas of each, I'm curious why you say that?
- dcow 4y ago
  If you don't care about performance and "zero cost abstractions" and are more interested in Rust for its memory safety, then most of your Rust programs end up with a lot of syntactic and library bloat to add those "costly" (but convenient) abstractions back in, like explicitly cloning or wrapping types in Rc and Arc or just always taking ownership of borrowed data by constructing owned types with it. And then there are lifetimes which can be and are elided in almost all uses cases so they're ultimately just confusing whenever you actually have to deal with them. C.f. Swift, where the default is in my experience what "higher level" rust programs end up looking like, but with much nicer and cleaner syntax. And Swift has a very nice rather memory safe API for calling into C or otherwise just generally accessing scoped pointers when needed. This same api can actually be used to expose more performant apis to underlying data etc. when needed. It's kinda the reverse of Rust. It feels like Rust is two languages in one: a high performance zero cost abstraction language that tracks pointer ownership, and a package rich and hyper explicit application language build atop all the guts. That's why I say high-level application use cases, because most high-level applications are not concerned with raw performance but rather with functionality and user experience. The parts that are concerned with throughput can be implemented using tooling where those knobs are available. I have enjoyed writing a cli and api server and various libraries in Rust. But every so often I am left wondering when Swift might be able to replace it for my higher level concerns. Alternatively, it would be neat to see some effort put behind a "convenient rust" type of compile mode for modules where you could compile with things like implied clones, unified owned vs reference types, auto-arc/box, etc.
  - rattray 4y ago
    Makes sense, thank you for explaining! Personally I'd love to see a forked flavor of TypeScript with static compilation and multithreading (which implies a lot more immutability, etc). Maybe I should give Swift a try…
ChubbyGlasses 4y ago
Swift and Carbon both seem like very strong contenders in this space. Swift is already a really strong language albeit a little too tied to Apple’s ecosystem. This along with the ownership manifesto slated for Swift 6 (and C++ interop) should make it easier to use it everywhere. In particular, I see a lot of value for tooling (eg JS code bundlers and such) that are rewritten in “thinner” languages for performance needs without sacrificing developer productivity.
pkulak 4y ago
I don't know if you can write high-throughput systems with 100% reference counted GC. Swift is targeted at UI work pretty hard.
- dcow 4y ago
  Well that's why I said high level application use cases and not systems. Ideally I'd love to see a compile mode for modules where certain conveniences were enabled like: auto-clone, unified reference/owned types, disabled lifetimes and instead borrows become auto-wrapped-arcs, etc. That way you could care about that stuff in modules where it matters, and ignore it in areas where you prefer convenience over zero-cost abstractions and raw performance.
- georgelyon 4y ago
  You could take a look a swift-nio (https://github.com/apple/swift-nio https://github.com/apple/swift-nio) which is a pretty high-throughput system. swift-nio does this using some reference-counted GC where it simplifies the code and doesn't affect performance. Otherwise, value-types are used which incur no GC overhead (unless they are copy-on-write, and backed by something that requires reference counting).
- deleted 4y ago
  [deleted]
- kevinossia 4y ago
  Sure you can. C++ has reference-counted garbage collection with its smart pointers and RAII, just like Swift. People certainly write high-throughput systems in C++. Swift is slower than C++, yes, but not because of its memory management scheme.
  - pkulak 4y ago
    Unless you go absolutely ham with smart pointers (which everyone knows not to do if you care about performance), C++ isn’t really a reference counting language. I wouldn’t call RAII “reference counting”. I mean, I guess, but it’s the programmer or the compiler doing it. I’m talking about runtime reference counting.
FlyingSnake 4y ago
If the foundation is rewritten in Swift, it will become a very potent alternative to Rust for this use case. Swift+LSP has good enough IDE support and the developer experience and debugging capabilities should make possible.
seanalltogether 4y ago
I think the fact that Rust won't provide inheritance based OOP workflows means that something like swift will always be valuable, especially for application development.
- Gigachad 4y ago
  What is the value provided by inheritance? It was my understanding that this was deliberately excluded from Rust as it's now seen as a bit of an anti pattern mostly inferior to traits.
  - sacnoradhq 4y ago
    None. It's code organizational syntactic sugar and abstraction that incurs a runtime penalty (vtables). Go ditched OO for similar reasons. Haskell, Erlang, and more get along fine without OO. (OO crested with Smalltalk, Java, Ruby, Python, and JS (more prototypal though). Let's not talk about C++98)
    - metaltyphoon 4y ago
      Don’t trait objects work the same way as vtables (fat pointer)?
      - Gigachad 4y ago
        Monomorphisation solves this. The compiler duplicates functions for every type you use them with in the finished binary.
  - seanalltogether 4y ago
    Inheritance is about providing business logic in all downstream inheritors through a super() chain. If you want shared logic in Rust between several implementors of a trait you will probably end up with duplicate code. There are drawbacks to both.
    - 4y ago
lmm 4y ago
> I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. Sure, or really OCaml or any other language with ML-family features (other replies have already mentioned Kotlin or C#). But the fact that it took Rust to get adoption and not OCaml suggests that it's not language functionality that drives adoption; Rust has something that those languages don't. (My theory is that it succeeds by being the first decent language that can match C's performance-on-silly-microbenchmark numbers)

by dcow 4y ago

kitsunesoba 4y ago

I would love to be able to write cross-platform desktops apps in Swift. The language isn't perfect of course but I enjoy it a lot more than the alternatives I've tried. That possibility is still a ways down the road of course but Foundation getting a cross platform rewrite is a nice step in that direction.

rattray 4y ago
If you or others on this thread are interested in working on a Swift compiler for Windows, please reach out to me :) a good friend is hiring a team to make this happen.
- Someone 4y ago
  How will that be different from Apple’s Swift toolchain for Windows (https://www.swift.org/blog/swift-on-windows/ https://www.swift.org/blog/swift-on-windows/)?
  - rattray 4y ago
    https://youtu.be/bOMQiMxh5Bc?t=430 https://youtu.be/bOMQiMxh5Bc?t=430 relevant listen is about 2min long
    - Someone 4y ago
      To me, that sounds as if most of the work would not be on the compiler but on improving the development experience (IDE, debugging support). On the other hand, your comment said ”working on _a_ Swift compiler for Windows”. To me, that sounded like a new compiler, not adding missing features to the existing one. Which of the two is it?

theLiminator 4y ago

Afaik Swift is pretty close to using Rc and Arc everywhere. Does swift do some more escape analysis than Rust?

janef0421 4y ago
Swift only uses reference counting when working with objects; Structs are optimised using copy-on-write. There's currently work on implementing move and ownership semantics, similar to Rust, but opt-in rather than by default.
- meindnoch 4y ago
  Ummm… No. Swift structs are just like C structs (from a memory perspective). The copy-on-write thing is implemented manually by storing a private refcounted object in your struct. See the implementation of Array for example: https://github.com/apple/swift/blob/main/stdlib/public/core/Array.swift https://github.com/apple/swift/blob/main/stdlib/public/core/... There’s no magical copy-on-write mechanism at the language level.
  - jshier 4y ago
    I don't know why this is downvoted, it's true. There is no automatic copy on write optimization in Swift. It's a manual optimization that expensive types like Array implement manually.
    - meindnoch 4y ago
      >I don't know why this is downvoted, it's true. I know, right? Some people are pretty insecure…
manmal 4y ago
I haven’t read that much on Rust, but that should be pretty much it. Swift has an emphasis on value types, which often are stored on the stack, but only up to a certain size. Copy-on-write makes this feasible - often, those value types are passed by reference until a write actually occurs, but that’s opaque to the dev. Value types can have pointers to reference-counted types - if a value type is passed/copied, any pointer it owns is retained (weirdly enough, they claim that value types have no „lifetime“, but at some point those refs have to be released - we just have to trust the compiler in this).

deleted 4y ago

[deleted]

etse 4y ago

How would you compare Swift with Kotlin in terms of being a good stand-in for high-level Rust? I've not paid attention to Kotlin in a while, but it seems like there's more progress at supporting Kotlin across more platforms (Kotlin native, web?, etc). I'm curious if people feel that the language features and design are at about parity, or if one is significantly stronger/weaker.

eatonphil 4y ago
Swift has the distinction (for better and worse) of not being tied to the JVM.
- dcow 4y ago
  Kotlin-native is an effort to compile directly to your target non-jvm machine.
dcow 4y ago
I haven't seriously used Kotlin in 4-5 years. I too was excited about it supporting native compiles and web assembly but I have no firsthand experience with how far those efforts got.
manmal 4y ago
Last time I toyed with Kotlin Multiplattform (bit less than a year ago) it provided only really weird Objective-C bindings for use in iOS/macOS. Like, a statically defined List turned into an Obj-C iterator. Enum and sealed classes were quite problematic either - I honestly would not consider using KMM for anything but a PoC. BTW, JetBrains recently sunsetted AppCode, so they are bleeding their Swift talent now. I suspect that doesn’t bode so well for Kotlin‘s Swift interop.
neonsunset 4y ago
Another scenario where an often missed and underrated choice would be C#. Nowadays it runs everywhere and supports a variety of deployment targets (relying on local runtime, packaging it together into a single somewhat compact binary, natively compiling the code (NativeAOT, it's good but has some limitations) or mixing and matching all of the above). It is also one of the best high-level languages to write performance-oriented code with, especially so with .NET 7 which allows writing cross-platform SIMD code in a similar fashion to Rust's 'portable-simd' crate.

rattray 4y ago

Interesting. Asking as someone who's never programmed with Swift or Rust, but is familiar with the syntax/ideas of each, I'm curious why you say that?

dcow 4y ago
If you don't care about performance and "zero cost abstractions" and are more interested in Rust for its memory safety, then most of your Rust programs end up with a lot of syntactic and library bloat to add those "costly" (but convenient) abstractions back in, like explicitly cloning or wrapping types in Rc and Arc or just always taking ownership of borrowed data by constructing owned types with it. And then there are lifetimes which can be and are elided in almost all uses cases so they're ultimately just confusing whenever you actually have to deal with them. C.f. Swift, where the default is in my experience what "higher level" rust programs end up looking like, but with much nicer and cleaner syntax. And Swift has a very nice rather memory safe API for calling into C or otherwise just generally accessing scoped pointers when needed. This same api can actually be used to expose more performant apis to underlying data etc. when needed. It's kinda the reverse of Rust. It feels like Rust is two languages in one: a high performance zero cost abstraction language that tracks pointer ownership, and a package rich and hyper explicit application language build atop all the guts. That's why I say high-level application use cases, because most high-level applications are not concerned with raw performance but rather with functionality and user experience. The parts that are concerned with throughput can be implemented using tooling where those knobs are available. I have enjoyed writing a cli and api server and various libraries in Rust. But every so often I am left wondering when Swift might be able to replace it for my higher level concerns. Alternatively, it would be neat to see some effort put behind a "convenient rust" type of compile mode for modules where you could compile with things like implied clones, unified owned vs reference types, auto-arc/box, etc.
- rattray 4y ago
  Makes sense, thank you for explaining! Personally I'd love to see a forked flavor of TypeScript with static compilation and multithreading (which implies a lot more immutability, etc). Maybe I should give Swift a try…

ChubbyGlasses 4y ago

Swift and Carbon both seem like very strong contenders in this space. Swift is already a really strong language albeit a little too tied to Apple’s ecosystem. This along with the ownership manifesto slated for Swift 6 (and C++ interop) should make it easier to use it everywhere. In particular, I see a lot of value for tooling (eg JS code bundlers and such) that are rewritten in “thinner” languages for performance needs without sacrificing developer productivity.

pkulak 4y ago

I don't know if you can write high-throughput systems with 100% reference counted GC. Swift is targeted at UI work pretty hard.

dcow 4y ago
Well that's why I said high level application use cases and not systems. Ideally I'd love to see a compile mode for modules where certain conveniences were enabled like: auto-clone, unified reference/owned types, disabled lifetimes and instead borrows become auto-wrapped-arcs, etc. That way you could care about that stuff in modules where it matters, and ignore it in areas where you prefer convenience over zero-cost abstractions and raw performance.
georgelyon 4y ago
You could take a look a swift-nio (https://github.com/apple/swift-nio https://github.com/apple/swift-nio) which is a pretty high-throughput system. swift-nio does this using some reference-counted GC where it simplifies the code and doesn't affect performance. Otherwise, value-types are used which incur no GC overhead (unless they are copy-on-write, and backed by something that requires reference counting).
deleted 4y ago
[deleted]
kevinossia 4y ago
Sure you can. C++ has reference-counted garbage collection with its smart pointers and RAII, just like Swift. People certainly write high-throughput systems in C++. Swift is slower than C++, yes, but not because of its memory management scheme.
- pkulak 4y ago
  Unless you go absolutely ham with smart pointers (which everyone knows not to do if you care about performance), C++ isn’t really a reference counting language. I wouldn’t call RAII “reference counting”. I mean, I guess, but it’s the programmer or the compiler doing it. I’m talking about runtime reference counting.

FlyingSnake 4y ago

If the foundation is rewritten in Swift, it will become a very potent alternative to Rust for this use case. Swift+LSP has good enough IDE support and the developer experience and debugging capabilities should make possible.

seanalltogether 4y ago

I think the fact that Rust won't provide inheritance based OOP workflows means that something like swift will always be valuable, especially for application development.

Gigachad 4y ago
What is the value provided by inheritance? It was my understanding that this was deliberately excluded from Rust as it's now seen as a bit of an anti pattern mostly inferior to traits.
- sacnoradhq 4y ago
  None. It's code organizational syntactic sugar and abstraction that incurs a runtime penalty (vtables). Go ditched OO for similar reasons. Haskell, Erlang, and more get along fine without OO. (OO crested with Smalltalk, Java, Ruby, Python, and JS (more prototypal though). Let's not talk about C++98)
  - metaltyphoon 4y ago
    Don’t trait objects work the same way as vtables (fat pointer)?
    - Gigachad 4y ago
      Monomorphisation solves this. The compiler duplicates functions for every type you use them with in the finished binary.
- seanalltogether 4y ago
  Inheritance is about providing business logic in all downstream inheritors through a super() chain. If you want shared logic in Rust between several implementors of a trait you will probably end up with duplicate code. There are drawbacks to both.
  - 4y ago

lmm 4y ago

> I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. Sure, or really OCaml or any other language with ML-family features (other replies have already mentioned Kotlin or C#). But the fact that it took Rust to get adoption and not OCaml suggests that it's not language functionality that drives adoption; Rust has something that those languages don't. (My theory is that it succeeds by being the first decent language that can match C's performance-on-silly-microbenchmark numbers)