4 ms·

> Rust aims to be extremely reliable and efficient. Fair point, Swift will never be as predictable or efficient as Rust (not a negative perse, just different g

> Rust aims to be extremely reliable and efficient. Fair point, Swift will never be as predictable or efficient as Rust (not a negative perse, just different goals). But I disagree on the complexity re: Go. What about Swift gives you the impression of extreme complexity? Go is definitely comparatively simpler but I do not think it is so much so as to put it in a different league.

novok 6y ago
The type errors you start running into with generics with all of their weird limitations in swift can make things complicated fast. That and RxSwift. Also swift as a language doesn't scale well. There are a lot of bottlenecks in the build process that doesn't let you scale simply amongst many cores like you can with C++, Obj-C & C and probably many other languages too. You're also effectively limited to xcode & apple desktops, so you can't go rent out a 100 core build server on AWS for builds like you can for every other platform out there, not that is matters much yet with swift's build scaling issues. Also stuff like basic debugging often just... dies. The more I work with a badly scaling language the more I appreciate a design decision like go made with building fast. I hope with generics in go v2 the boilerplate should reduce a lot.
- jshier 6y ago
  When was the last time you compiled Swift code? Xcode's new(er) build system has solved many of the scaling issues that affected the previous system, to the point where it scales linearly (on large enough projects) even on a 28/56 Mac Pro, and my 10/20 iMac. Additionally, with cmake's native Swift support in 3.18(?), the scaling should be more solved across platform as well. There's certainly nothing in the language itself that prevents scaling builds, only the compiler and build systems. The debugger is still rough, true, but improving. Apple just isn't spending the resources needed to bring lldb up to a great experience in a timely fashion.
  - novok 6y ago
    Yesterday! Swifts build system can split off enough threads to consume all of your CPU cores, and batch mode did improve things, but it's not actually doing so efficiently. There is a trade off between total compute time used and number of threads used. In compute time consumed, swift is the most efficient when it's single threaded in WMO mode, but this means you can only compile in parallel with separate modules that don't depend on each other. And even then it's not a very fast compiling language itself, multithreading issues notwithstanding Maybe something has changed recently, but as far as Xcode 12 goes, I haven't noticed much of a difference. I last checked deeply with swift 4. More details here: https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md https://github.com/apple/swift/blob/master/docs/CompilerPerf...
- vips7L 6y ago
  RxAnything makes any language unreadable. RxJava is the bane of my existence.
  - myko 6y ago
    I find Rx to be super clear usually. What problems have you run into? Combine (Apple's Rx framework) is pretty understandable/usable as well.
    - vips7L 6y ago
      In my opinion it's just easy to do wrong. Most uses I've seen (at least in java land) are attempts at non-blocking io which ends up turning the whole application into observables from bottom up. Which in turn makes your app hard to debug and reason about. When done right, when you actually need the observer pattern, and use it as an event queue I'm sure it's probably amazing though.
      - nsonha 6y ago
        this is the problem with async programming in general not just rx. Relevant read: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
        vips7L 6y ago
        Yes I know about colored functions. I'm looking forward to loom and virtual threads on the jvm to solve that. BUT it doesn't change the fact that Rx is hard to implement correctly and is often misused when you don't need the observer pattern.
      - myko 6y ago
        Those are good points but I agree with the other commenter that these are just difficulties with asynchronous programming generally. I like that Rx makes reasoning about those issues more straight forward and something you must handle instead of something that will bite you later if you didn't think through it.
- viktorcode 6y ago
  > You're also effectively limited to xcode & apple desktops Swift supports LSP now, so you can use VS Code if that's your thing.
  - deleted 6y ago
    [deleted]
  - novok 6y ago
    But what is going to build your iOS/macOS application, the application of %99.9 of swift code? It's only going to build on macOS unless you are willing to illegally virtualize macOS on non-apple hardware.

novok 6y ago

The type errors you start running into with generics with all of their weird limitations in swift can make things complicated fast. That and RxSwift. Also swift as a language doesn't scale well. There are a lot of bottlenecks in the build process that doesn't let you scale simply amongst many cores like you can with C++, Obj-C & C and probably many other languages too. You're also effectively limited to xcode & apple desktops, so you can't go rent out a 100 core build server on AWS for builds like you can for every other platform out there, not that is matters much yet with swift's build scaling issues. Also stuff like basic debugging often just... dies. The more I work with a badly scaling language the more I appreciate a design decision like go made with building fast. I hope with generics in go v2 the boilerplate should reduce a lot.

jshier 6y ago
When was the last time you compiled Swift code? Xcode's new(er) build system has solved many of the scaling issues that affected the previous system, to the point where it scales linearly (on large enough projects) even on a 28/56 Mac Pro, and my 10/20 iMac. Additionally, with cmake's native Swift support in 3.18(?), the scaling should be more solved across platform as well. There's certainly nothing in the language itself that prevents scaling builds, only the compiler and build systems. The debugger is still rough, true, but improving. Apple just isn't spending the resources needed to bring lldb up to a great experience in a timely fashion.
- novok 6y ago
  Yesterday! Swifts build system can split off enough threads to consume all of your CPU cores, and batch mode did improve things, but it's not actually doing so efficiently. There is a trade off between total compute time used and number of threads used. In compute time consumed, swift is the most efficient when it's single threaded in WMO mode, but this means you can only compile in parallel with separate modules that don't depend on each other. And even then it's not a very fast compiling language itself, multithreading issues notwithstanding Maybe something has changed recently, but as far as Xcode 12 goes, I haven't noticed much of a difference. I last checked deeply with swift 4. More details here: https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md https://github.com/apple/swift/blob/master/docs/CompilerPerf...
vips7L 6y ago
RxAnything makes any language unreadable. RxJava is the bane of my existence.
- myko 6y ago
  I find Rx to be super clear usually. What problems have you run into? Combine (Apple's Rx framework) is pretty understandable/usable as well.
  - vips7L 6y ago
    In my opinion it's just easy to do wrong. Most uses I've seen (at least in java land) are attempts at non-blocking io which ends up turning the whole application into observables from bottom up. Which in turn makes your app hard to debug and reason about. When done right, when you actually need the observer pattern, and use it as an event queue I'm sure it's probably amazing though.
    - nsonha 6y ago
      this is the problem with async programming in general not just rx. Relevant read: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
      - vips7L 6y ago
        Yes I know about colored functions. I'm looking forward to loom and virtual threads on the jvm to solve that. BUT it doesn't change the fact that Rx is hard to implement correctly and is often misused when you don't need the observer pattern.
    - myko 6y ago
      Those are good points but I agree with the other commenter that these are just difficulties with asynchronous programming generally. I like that Rx makes reasoning about those issues more straight forward and something you must handle instead of something that will bite you later if you didn't think through it.
viktorcode 6y ago
> You're also effectively limited to xcode & apple desktops Swift supports LSP now, so you can use VS Code if that's your thing.
- deleted 6y ago
  [deleted]
- novok 6y ago
  But what is going to build your iOS/macOS application, the application of %99.9 of swift code? It's only going to build on macOS unless you are willing to illegally virtualize macOS on non-apple hardware.