5 ms·

There's no reason to use Swift outside of the Apple platform. Rust is much better option and more cross-platform. And they work hard on reducing the binary size

by xvilka 2y ago

There's no reason to use Swift outside of the Apple platform. Rust is much better option and more cross-platform. And they work hard on reducing the binary size as well.

isodev 2y ago
Also self-inflicting Apple’s “what happens not a Mac” developer experience may not be what one wants to go through during the lifetime of an app.
mannuch 2y ago
Well I for one appreciate Swift’s focus on ergonomics and progressive disclosure. I think Rust is great, but I don’t see it as a great application-level programming language. I think it’s wonderful that Swift is trying to be more cross-platform. No need to shoot down the efforts of people trying to bring a language they like to more places.
dagmx 2y ago
This is like a C++ dev saying there’s no reason to use rust. Swift offers a lot of ergonomic values over rust in ways that have made me switch over as my default choice. Things like default argument values, lazy static initializers, computed properties, optional chaining. I’ve personally also come around to ref counting by default being a sensible choice for most programs. Though the thing that won me over was the recent C++ interoperability. Rust doesn’t have a good story there yet that’s as comparable. Hours/days/months writing Rust bindings for a C++ library are often minutes in Swift. Each language has its own place and own benefits, but to say there’s “no reason to use a language” feels short sighted and defensively dismissive
- xvilka 2y ago
  I would agree with you but in the case of Swift is largely confined to the Apple ecosystem with other platforms as an afterthought, while both C++ and Rust try to cover as many targets as possible.
  - dagmx 2y ago
    But that is exactly what is changing right now. Foundation is being rewritten in Swift, Swift has moved out from under apples GitHub and is pushing more cross platform tooling for windows and Linux. It’s not as flexible in terms of targets yet as Rust, but it’s also not just locked to Apple platforms. And for a big chunk of developers, that trade off is fine.
    - bobajeff 2y ago
      It remains to be seen weather Swift will break out of being just a language for programming Apple applications. There is still no way to make gui applications outside of Apple devices. Unless you want to make your own library or generate/maintain Swift bindings for an existing UI library. Maybe, it will be okay for console only programs or servers but why use that over Java/JVM, nodejs or go?
      - dagmx 2y ago
        UI libraries are a poor reason to pick Rust over Swift, given that Rust has a very poor UI story. Doesn’t your comment apply very equally to Rust? There’s basically Slint and Tauri, and several bindings in various states of disarray. Not exactly very compelling. The Rust ecosystem has very many strengths, but UI is not one of them. Regardless, you’re incorrect about there being no way to make GUI applications Here’s a Gnome binding https://swift.org/blog/adwaita-swift/ https://swift.org/blog/adwaita-swift/ The C++ interop allows easy binding to Qt https://github.com/qt/qtdeclarative/tree/dev/tests/manual/helloswift https://github.com/qt/qtdeclarative/tree/dev/tests/manual/he... Win32 https://github.com/compnerd/swift-win32 https://github.com/compnerd/swift-win32 The fact that Swift has easier C++ interop than Rust makes the cross platform UI story much easier and more compelling than what I’ve found in Rust. Bindings are much simpler to manage and can be handled by a single module map file with a single line in it most of the time. Adding to that, many well established UI libraries depend on classes to implement them. Rusts lack of classes, while wonderful otherwise, makes binding to heavy class based libraries very onerous. Don’t get me wrong, I really enjoy rust. It’s just, it’s very ill suited for UI work today itself. I almost always write my UI side in C++ if I have to and bind over when needed instead.
- lenkite 2y ago
  Wish Swift provided a way to use custom allocators. Then it would be really terrific. A fair number of middle-ware projects work well with strategies like arena allocation which significantly improve performance and also structural ergonomics. ARC adds a fair bit of performance burden - you can see dozens of examples of people refactoring continuously to reduce ARC time in the swift forums.
- opless 2y ago
  Indeed there's no compelling reason to use C++ or Rust. It comes down to user preferences. Quite frankly if you can't track the lifetime of your own allocated memory, are you even a competent software developer?
- wredue 2y ago
  Is Linux still a fifth class citizen for swift? The last time I used it (and I admit this was a couple years ago), silly expectations like “my program will behave the same on Linux as it does on Mac” were not being met.

by xvilka 2y ago

There's no reason to use Swift outside of the Apple platform. Rust is much better option and more cross-platform. And they work hard on reducing the binary size as well.

isodev 2y ago

Also self-inflicting Apple’s “what happens not a Mac” developer experience may not be what one wants to go through during the lifetime of an app.

mannuch 2y ago

Well I for one appreciate Swift’s focus on ergonomics and progressive disclosure. I think Rust is great, but I don’t see it as a great application-level programming language. I think it’s wonderful that Swift is trying to be more cross-platform. No need to shoot down the efforts of people trying to bring a language they like to more places.

dagmx 2y ago

This is like a C++ dev saying there’s no reason to use rust. Swift offers a lot of ergonomic values over rust in ways that have made me switch over as my default choice. Things like default argument values, lazy static initializers, computed properties, optional chaining. I’ve personally also come around to ref counting by default being a sensible choice for most programs. Though the thing that won me over was the recent C++ interoperability. Rust doesn’t have a good story there yet that’s as comparable. Hours/days/months writing Rust bindings for a C++ library are often minutes in Swift. Each language has its own place and own benefits, but to say there’s “no reason to use a language” feels short sighted and defensively dismissive

xvilka 2y ago
I would agree with you but in the case of Swift is largely confined to the Apple ecosystem with other platforms as an afterthought, while both C++ and Rust try to cover as many targets as possible.
- dagmx 2y ago
  But that is exactly what is changing right now. Foundation is being rewritten in Swift, Swift has moved out from under apples GitHub and is pushing more cross platform tooling for windows and Linux. It’s not as flexible in terms of targets yet as Rust, but it’s also not just locked to Apple platforms. And for a big chunk of developers, that trade off is fine.
  - bobajeff 2y ago
    It remains to be seen weather Swift will break out of being just a language for programming Apple applications. There is still no way to make gui applications outside of Apple devices. Unless you want to make your own library or generate/maintain Swift bindings for an existing UI library. Maybe, it will be okay for console only programs or servers but why use that over Java/JVM, nodejs or go?
    - dagmx 2y ago
      UI libraries are a poor reason to pick Rust over Swift, given that Rust has a very poor UI story. Doesn’t your comment apply very equally to Rust? There’s basically Slint and Tauri, and several bindings in various states of disarray. Not exactly very compelling. The Rust ecosystem has very many strengths, but UI is not one of them. Regardless, you’re incorrect about there being no way to make GUI applications Here’s a Gnome binding https://swift.org/blog/adwaita-swift/ https://swift.org/blog/adwaita-swift/ The C++ interop allows easy binding to Qt https://github.com/qt/qtdeclarative/tree/dev/tests/manual/helloswift https://github.com/qt/qtdeclarative/tree/dev/tests/manual/he... Win32 https://github.com/compnerd/swift-win32 https://github.com/compnerd/swift-win32 The fact that Swift has easier C++ interop than Rust makes the cross platform UI story much easier and more compelling than what I’ve found in Rust. Bindings are much simpler to manage and can be handled by a single module map file with a single line in it most of the time. Adding to that, many well established UI libraries depend on classes to implement them. Rusts lack of classes, while wonderful otherwise, makes binding to heavy class based libraries very onerous. Don’t get me wrong, I really enjoy rust. It’s just, it’s very ill suited for UI work today itself. I almost always write my UI side in C++ if I have to and bind over when needed instead.
lenkite 2y ago
Wish Swift provided a way to use custom allocators. Then it would be really terrific. A fair number of middle-ware projects work well with strategies like arena allocation which significantly improve performance and also structural ergonomics. ARC adds a fair bit of performance burden - you can see dozens of examples of people refactoring continuously to reduce ARC time in the swift forums.
opless 2y ago
Indeed there's no compelling reason to use C++ or Rust. It comes down to user preferences. Quite frankly if you can't track the lifetime of your own allocated memory, are you even a competent software developer?
wredue 2y ago
Is Linux still a fifth class citizen for swift? The last time I used it (and I admit this was a couple years ago), silly expectations like “my program will behave the same on Linux as it does on Mac” were not being met.