4 ms·

Swift also doesn't have a mark&sweep GC, and uses reference counting, which makes its memory footprint much smaller than GC-based runtimes.

by sedatk 1y ago

90s_dev 1y ago
It also means it's easy to create reference cycles that never get deallocated. Especially in callback anonymous functions.
- tbojanin 1y ago
  The tooling around finding these references cycles (Instruments) is 2nd to none imo.
  - Onavo 1y ago
    The issues it has around circular data structures is almost, though not quite, as bad as rust.
  - steeleduncan 1y ago
    True, but it only works on Apple systems, which makes Swift far less appealing on non-Apple systems. This adds weight to the point the GP comment makes about Swift being held back by its association with Apple
    - dardeaup 1y ago
      Agreed. However, if Jetbrains were to provide a Swift IDE that's free for non-commercial use...
      - ohdeargodno 1y ago
        They used to. AppCode was excellent. Fleet kind of supports Swift well enough. AppCode was abandoned because Apple is impossible to work with and never provided up to date semantics and language definitions for Swift, keeping everything under wraps and making every single Swift release a race to suddenly implement whatever new keyword they made up this week. Fleet is more of a VSCode. Probably using the LSP these days, and it's good enough if a simple text editor is what you need.
        einsteinx2 1y ago
        Swift is literally developed in the open, so I don’t think your argument makes sense. I think the reason they abandoned it was trouble keeping up with new iOS SDK features getting shadow dropped as part of new Xcode betas and iOS devs wanting to immediately prepare their apps to use those features, not anything to do with Swift language releases. Also things like having to recreate interface builder, then support auto layout in it, and then later SwiftUI previews, etc. Again all iOS platform stuff, not Swift language stuff.
- ninkendo 1y ago
  After coding in swift for ~5 years at job - 1, I can count on one hand the times I had to deal with a reference cycle, and in each instance it was obvious in context that there was going to be a cycle so I used “weak” in anticipation. Zero times did I ever accidentally forget to use a weak reference. A simple rule of thumb is that if anything has a parent/child relationship, the child should use the weak keyword (or even “unowned” if you’re certain about object lifetimes) when referring back to the parent. That and things like hand-rolled doubly linked lists, but the standard library already has that so who cares.
  - einsteinx2 1y ago
    Also for all the hate Xcode deservedly receives, it comes with some really great tooling in the Instruments package that, among other things, makes it trivial to detect leaked memory when it does happen. And from my own experience developing in Obj-C and Swift for 15 years, I agree that it’s really not the big issue that anti-reference counting people make it out to be.
- miffy900 1y ago
  Well kinda; even in a tracing GC language like C# you have things like WeakEventManager (https://learn.microsoft.com/en-us/dotnet/api/system.windows.weakeventmanager?view=windowsdesktop-9.0&viewFallbackFrom=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.windows....) to prevent memory leaks when using callbacks as event handlers. It is definitely not exclusive to ref counted languages. In C#, these aren't the exact same as a reference cycle, but the end result is the same, a memory leak: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/events/weak-event-patterns https://learn.microsoft.com/en-us/dotnet/desktop/wpf/events/...
pebal 1y ago
But that's why Swift generates slower code. Memory is cheap, also for Apple, although Apple would like to hide that fact.
- sedatk 1y ago
  Have you seen the benchmarks? Swift code is 40% faster than Java in that instance.
  - pjmlp 1y ago
    I have indeed, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
    - tgffdd 1y ago
      No wonder Swift performs unwell in this benchmark. The Swift implementation is written very poorly, done by developers obviously unexperienced in writing proper Swift :)
  - vips7L 1y ago
    I don’t think anyone actually believes that the language change is what made the difference in that post. As far as anyone can tell there were 2 things that made their rewrite better: 1. They had experience on the type of app and you tend to do things better when you do it the second time. 2. Reading between the lines they were likely running an ancient version of Java from 10+ years ago.
    - sedatk 1y ago
      > I don’t think anyone actually believes that the language change is what made the difference in that post They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage. So, not the language per se, but the runtime difference must have made a difference. Compiled native code may not be too different between the two. But, in terms of memory management, Swift's ability to keep the heap in a smaller area might contribute to better cache utilization which might implicitly contribute to performance. In the end, as you said, writing better code the second time might have made the greatest contribution of course. That doesn't necessarily mean that language change has made no difference.

Swift also doesn't have a mark&sweep GC, and uses reference counting, which makes its memory footprint much smaller than GC-based runtimes.

by sedatk 1y ago

Swift also doesn't have a mark&sweep GC, and uses reference counting, which makes its memory footprint much smaller than GC-based runtimes.

90s_dev 1y ago

It also means it's easy to create reference cycles that never get deallocated. Especially in callback anonymous functions.

tbojanin 1y ago
The tooling around finding these references cycles (Instruments) is 2nd to none imo.
- Onavo 1y ago
  The issues it has around circular data structures is almost, though not quite, as bad as rust.
- steeleduncan 1y ago
  True, but it only works on Apple systems, which makes Swift far less appealing on non-Apple systems. This adds weight to the point the GP comment makes about Swift being held back by its association with Apple
  - dardeaup 1y ago
    Agreed. However, if Jetbrains were to provide a Swift IDE that's free for non-commercial use...
    - ohdeargodno 1y ago
      They used to. AppCode was excellent. Fleet kind of supports Swift well enough. AppCode was abandoned because Apple is impossible to work with and never provided up to date semantics and language definitions for Swift, keeping everything under wraps and making every single Swift release a race to suddenly implement whatever new keyword they made up this week. Fleet is more of a VSCode. Probably using the LSP these days, and it's good enough if a simple text editor is what you need.
      - einsteinx2 1y ago
        Swift is literally developed in the open, so I don’t think your argument makes sense. I think the reason they abandoned it was trouble keeping up with new iOS SDK features getting shadow dropped as part of new Xcode betas and iOS devs wanting to immediately prepare their apps to use those features, not anything to do with Swift language releases. Also things like having to recreate interface builder, then support auto layout in it, and then later SwiftUI previews, etc. Again all iOS platform stuff, not Swift language stuff.
ninkendo 1y ago
After coding in swift for ~5 years at job - 1, I can count on one hand the times I had to deal with a reference cycle, and in each instance it was obvious in context that there was going to be a cycle so I used “weak” in anticipation. Zero times did I ever accidentally forget to use a weak reference. A simple rule of thumb is that if anything has a parent/child relationship, the child should use the weak keyword (or even “unowned” if you’re certain about object lifetimes) when referring back to the parent. That and things like hand-rolled doubly linked lists, but the standard library already has that so who cares.
- einsteinx2 1y ago
  Also for all the hate Xcode deservedly receives, it comes with some really great tooling in the Instruments package that, among other things, makes it trivial to detect leaked memory when it does happen. And from my own experience developing in Obj-C and Swift for 15 years, I agree that it’s really not the big issue that anti-reference counting people make it out to be.
miffy900 1y ago
Well kinda; even in a tracing GC language like C# you have things like WeakEventManager (https://learn.microsoft.com/en-us/dotnet/api/system.windows.weakeventmanager?view=windowsdesktop-9.0&viewFallbackFrom=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.windows....) to prevent memory leaks when using callbacks as event handlers. It is definitely not exclusive to ref counted languages. In C#, these aren't the exact same as a reference cycle, but the end result is the same, a memory leak: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/events/weak-event-patterns https://learn.microsoft.com/en-us/dotnet/desktop/wpf/events/...

pebal 1y ago

But that's why Swift generates slower code. Memory is cheap, also for Apple, although Apple would like to hide that fact.

sedatk 1y ago
Have you seen the benchmarks? Swift code is 40% faster than Java in that instance.
- pjmlp 1y ago
  I have indeed, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
  - tgffdd 1y ago
    No wonder Swift performs unwell in this benchmark. The Swift implementation is written very poorly, done by developers obviously unexperienced in writing proper Swift :)
- vips7L 1y ago
  I don’t think anyone actually believes that the language change is what made the difference in that post. As far as anyone can tell there were 2 things that made their rewrite better: 1. They had experience on the type of app and you tend to do things better when you do it the second time. 2. Reading between the lines they were likely running an ancient version of Java from 10+ years ago.
  - sedatk 1y ago
    > I don’t think anyone actually believes that the language change is what made the difference in that post They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage. So, not the language per se, but the runtime difference must have made a difference. Compiled native code may not be too different between the two. But, in terms of memory management, Swift's ability to keep the heap in a smaller area might contribute to better cache utilization which might implicitly contribute to performance. In the end, as you said, writing better code the second time might have made the greatest contribution of course. That doesn't necessarily mean that language change has made no difference.