6 ms·

Swift seems like a really nice language that's held back by it's association with Apple. Seems to hit a sweet spot of a fast/compiled (compared to Javascript)

Swift seems like a really nice language that's held back by it's association with Apple. Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust). Doesn't seem like there's any maintained bindings for Qt though, although there are some interesting ones for GTK (e.g. https://git.aparoksha.dev/aparoksha/adwaita-swift https://git.aparoksha.dev/aparoksha/adwaita-swift)

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.
bobajeff 1y ago
My view is that languages don't matter only libraries and engines. If you want to make an iOS app then Swift is for you. If you want to make an Unreal Engine game then C++. If you want to make a website then JavaScript. If you want to play with Bevy or Servo libraries then Rust. If you want to play with Blender or do anything with AI then Python.
- mdhb 1y ago
  I think that argument is on increasingly shaky ground these days as the barriers are starting to come down in a lot of ways. First in the sense of hand crafted interop solutions that modern languages provide. Take Dart for example as something that has a (by comparison) very small package ecosystem. However it has support for interop across: JavaScript, Java, Objective C, C, C++, Rust, Swift, Kotlin and Go I believe off the top of my head. Then you also have efforts like WebAssembly and specifically the in-development component model which seeks to totally break down that language specific package ecosystem and make importing and working with another language as easy as it is when importing a package from your own language ecosystem. So with those things in mind, however true that might be today, I don’t think it’s a strong argument moving forward.
  - mk89 1y ago
    I am not sure but your comment seems to make the point of the person you're answering to. Dart is used probably and exclusively in one context (= library): Flutter. Nobody would dream of writing anything else with it and put it in production. Why? Because despite the interop, all the libs are still in the original language and they shine in the language they were written with. And Dart has no ecosystem comparable to the top 5-10 most used languages. Try to build bindings for QT in Dart. That alone would require a company just to make that happen. You'd have to pay developers just to make that interop work - that's what Riverbank did with pyqt. No other companies did that, as far as I know (until Nokia developed pySide). And what for? So I somehow agree with the previous comment, unless someone writes really good bindings. That's rare, though, and from my experience it's mostly to put something in legacy mode.
hocuspocus 1y ago
I don't think anyone cares about Apple here. Swift solved a problem that people outside iOS/macOS didn't have. Then it took ~10 years to make Swift more seriously general purpose and multi-platform, it's simply too late to be compelling when other languages have progressed too. Re: easy to write, I'm not sure, Swift's recent explosion in complexity makes it a hard sell vs Rust, even if the learning curve might be slightly less steep. At the end of the day, Rust's DX wins in almost every dimension, people are willing to learn slightly more complex semantics if it saves times everywhere else: tooling, libraries, build tool and package manager, ... I believe even compilation speeds don't compare favorably.
- mort96 1y ago
  Meh, I could've been curious about playing with Swift if it wasn't so Apple-centric. Just like I could've been curious about playing with C# if it wasn't so Microsoft-centric.
  - mproud 1y ago
    Is it that Apple made it and puts resources into it that makes it Apple-centric? If so, is that truly important?
    - mort96 1y ago
      It's not that Apple puts resources into it. It's that, yes, Apple made it, and its only raison d'etre is to replace Objective-C for Apple platforms.
    - xeonmc 1y ago
      I wonder why LLVM isn’t also considered Apple-centric by the same thought process.
      - miffy900 1y ago
        To be fair, LLVM wasn't an Apple-initiated project, but one Apple noticed and decided to adopt later on (they hired Chris Latner in 2005; LLVM began in 2000, and had its first public stable release in 2003). Unlike Swift, there was never a period of time where LLVM only worked exclusively on Apples own OS's or hardware. From the get go, you could run early versions of LLVM on Windows. In Swift's case, Linux support came in 2016, 1.5 years after Swift's initial release in 2014, then Windows support came 6 years later in v5 (2020). If Apple didn't want to let Swift suffer the reputation of being an Apple-only language they should've invested more into cross platform support much earlier on. Yes, today Apple and everyone else can say, 'Swift is cross-platform', but dig deeper into the history of Swift and its clear that from the get go, Apple treated non-Apple OS support as an afterthought.
ChrisMarshallNY 1y ago
> Swift seems like a really nice language that's held back by it's association with Apple. Or empowered by its association with Apple. That's a pretty big pond. I like Swift, and I write software for Apple devices. I don't really care, whether or not it supports other platforms. For my backend work, I tend to use PHP, because there's a very broad base of servers that support it, it's good enough, fast enough, and, doggone it, people like it... Another comment mentions that languages aren't really the issue, platforms are, and enumerates a number of application contexts, and the languages that are used to develop in those contexts. If you want to write native Apple software, then you need to either use ObjC, or Swift. You can use C or C++, and JavaScript, if you don't mind gluing them on, but native is Swift/ObjC, and Apple doesn't really do much to support ObjC (but they have to, anyway, because I guarantee that some of the biggest apps out there, still run with ObjC -including some Apple ones). I use Swift. I write both UIKit and SwiftUI, but find that UIKit is what I use to deliver a great user experience. I have to use SwiftUI, for a few applications (like Watch apps), and am constantly slamming into its limitations.
- esseph 1y ago
  Given this comment, the next one that starts with something like "I don't think anybody cares about Apple here" made me giggle.
  - ChrisMarshallNY 1y ago
    Eh. That's why I run showdead = no. That comment obviously got nuked. It's really fun, knowing that some folks hate me, just because I write software for Apple platforms. I don't hate them back. That kind of hatred isn't very good for you. It's Commissioner Dreyfus-level obsession. But this also shows what a tiny, tiny minority of people are represented here. Apple's a three-trillion-dollar company, because most folks aren't like us.
    - johannes1234321 1y ago
      I don't believe that is the point of the thread. The thread was about "Swift would be a good language, but all the attention and focus is on the Apple ecosystem and everybody using it for something else is an outlier and if you don't want to deal with apple it's a hard game"
cosmic_cheese 1y ago
Very few languages have quality Qt bindings because Qt is a pain to bind to, so that might not be a particularly good benchmark. In addition to the Adwaita bindings listed, there’s also autogenerated plain GTK bindings (https://github.com/rhx/SwiftGtk https://github.com/rhx/SwiftGtk).
- Narew 1y ago
  I'll interpret a bit. But I think the remark is more did we have a cross platform and complete gui library for swift.
dagmx 1y ago
Qt have announced they’re doing Swift bindings recently https://www.qt.io/blog/about-the-new-qt-bridging-technology https://www.qt.io/blog/about-the-new-qt-bridging-technology Afaik someone on this site shared a repo url that has the early bindings using Swift C++ interop.
- cosmic_cheese 1y ago
  Looks like it’s only for Quick and not Widgets, which I’m sure is still useful but kind of a bummer.
teleforce 1y ago
>Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust). What you've enumerated are also applicable to Dlang with potential of even faster compile and execution time than C++ or even the venerable Fortran [1]. [1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
90s_dev 1y ago
When I write code, I always start with the platform, which drives and limits the language choices. I don't say I want to write in C++, I say I want to write for web, or for iOS, or Windows, or whatever. If I'm writing for web, I'll reach for TypeScript. If iOS, then ObjC. If Windows, maybe C# if I'm being threatened. Using Rust to build a web app is like pulling teeth. If many people think the same way, then yeah, there's no good reason to reach for Swift unless you're writing an iOS or Mac app and don't want it to be cross platform for some reason that I almost can't imagine in 2025.
no_time 1y ago
>Swift seems like a really nice language that's held back by it's association with Apple. >Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust). Replace Apple with MS and Swift with C# and all of this is still true but makes my heart ache even more.
dzonga 1y ago
or embracing complexity as C++. It used to be very simple and pragmatic language. that stopped with Swift 3. Remember Protocol based Swift - better than OOP - but now it seems a bastard child of C++. Swift at one point could've been Golang with better C++ interop. A better Rust since it's memory safe without the gymnastics.

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.

bobajeff 1y ago

My view is that languages don't matter only libraries and engines. If you want to make an iOS app then Swift is for you. If you want to make an Unreal Engine game then C++. If you want to make a website then JavaScript. If you want to play with Bevy or Servo libraries then Rust. If you want to play with Blender or do anything with AI then Python.

mdhb 1y ago
I think that argument is on increasingly shaky ground these days as the barriers are starting to come down in a lot of ways. First in the sense of hand crafted interop solutions that modern languages provide. Take Dart for example as something that has a (by comparison) very small package ecosystem. However it has support for interop across: JavaScript, Java, Objective C, C, C++, Rust, Swift, Kotlin and Go I believe off the top of my head. Then you also have efforts like WebAssembly and specifically the in-development component model which seeks to totally break down that language specific package ecosystem and make importing and working with another language as easy as it is when importing a package from your own language ecosystem. So with those things in mind, however true that might be today, I don’t think it’s a strong argument moving forward.
- mk89 1y ago
  I am not sure but your comment seems to make the point of the person you're answering to. Dart is used probably and exclusively in one context (= library): Flutter. Nobody would dream of writing anything else with it and put it in production. Why? Because despite the interop, all the libs are still in the original language and they shine in the language they were written with. And Dart has no ecosystem comparable to the top 5-10 most used languages. Try to build bindings for QT in Dart. That alone would require a company just to make that happen. You'd have to pay developers just to make that interop work - that's what Riverbank did with pyqt. No other companies did that, as far as I know (until Nokia developed pySide). And what for? So I somehow agree with the previous comment, unless someone writes really good bindings. That's rare, though, and from my experience it's mostly to put something in legacy mode.

hocuspocus 1y ago

I don't think anyone cares about Apple here. Swift solved a problem that people outside iOS/macOS didn't have. Then it took ~10 years to make Swift more seriously general purpose and multi-platform, it's simply too late to be compelling when other languages have progressed too. Re: easy to write, I'm not sure, Swift's recent explosion in complexity makes it a hard sell vs Rust, even if the learning curve might be slightly less steep. At the end of the day, Rust's DX wins in almost every dimension, people are willing to learn slightly more complex semantics if it saves times everywhere else: tooling, libraries, build tool and package manager, ... I believe even compilation speeds don't compare favorably.

mort96 1y ago
Meh, I could've been curious about playing with Swift if it wasn't so Apple-centric. Just like I could've been curious about playing with C# if it wasn't so Microsoft-centric.
- mproud 1y ago
  Is it that Apple made it and puts resources into it that makes it Apple-centric? If so, is that truly important?
  - mort96 1y ago
    It's not that Apple puts resources into it. It's that, yes, Apple made it, and its only raison d'etre is to replace Objective-C for Apple platforms.
  - xeonmc 1y ago
    I wonder why LLVM isn’t also considered Apple-centric by the same thought process.
    - miffy900 1y ago
      To be fair, LLVM wasn't an Apple-initiated project, but one Apple noticed and decided to adopt later on (they hired Chris Latner in 2005; LLVM began in 2000, and had its first public stable release in 2003). Unlike Swift, there was never a period of time where LLVM only worked exclusively on Apples own OS's or hardware. From the get go, you could run early versions of LLVM on Windows. In Swift's case, Linux support came in 2016, 1.5 years after Swift's initial release in 2014, then Windows support came 6 years later in v5 (2020). If Apple didn't want to let Swift suffer the reputation of being an Apple-only language they should've invested more into cross platform support much earlier on. Yes, today Apple and everyone else can say, 'Swift is cross-platform', but dig deeper into the history of Swift and its clear that from the get go, Apple treated non-Apple OS support as an afterthought.

ChrisMarshallNY 1y ago

> Swift seems like a really nice language that's held back by it's association with Apple. Or empowered by its association with Apple. That's a pretty big pond. I like Swift, and I write software for Apple devices. I don't really care, whether or not it supports other platforms. For my backend work, I tend to use PHP, because there's a very broad base of servers that support it, it's good enough, fast enough, and, doggone it, people like it... Another comment mentions that languages aren't really the issue, platforms are, and enumerates a number of application contexts, and the languages that are used to develop in those contexts. If you want to write native Apple software, then you need to either use ObjC, or Swift. You can use C or C++, and JavaScript, if you don't mind gluing them on, but native is Swift/ObjC, and Apple doesn't really do much to support ObjC (but they have to, anyway, because I guarantee that some of the biggest apps out there, still run with ObjC -including some Apple ones). I use Swift. I write both UIKit and SwiftUI, but find that UIKit is what I use to deliver a great user experience. I have to use SwiftUI, for a few applications (like Watch apps), and am constantly slamming into its limitations.

esseph 1y ago
Given this comment, the next one that starts with something like "I don't think anybody cares about Apple here" made me giggle.
- ChrisMarshallNY 1y ago
  Eh. That's why I run showdead = no. That comment obviously got nuked. It's really fun, knowing that some folks hate me, just because I write software for Apple platforms. I don't hate them back. That kind of hatred isn't very good for you. It's Commissioner Dreyfus-level obsession. But this also shows what a tiny, tiny minority of people are represented here. Apple's a three-trillion-dollar company, because most folks aren't like us.
  - johannes1234321 1y ago
    I don't believe that is the point of the thread. The thread was about "Swift would be a good language, but all the attention and focus is on the Apple ecosystem and everybody using it for something else is an outlier and if you don't want to deal with apple it's a hard game"

cosmic_cheese 1y ago

Very few languages have quality Qt bindings because Qt is a pain to bind to, so that might not be a particularly good benchmark. In addition to the Adwaita bindings listed, there’s also autogenerated plain GTK bindings (https://github.com/rhx/SwiftGtk https://github.com/rhx/SwiftGtk).

Narew 1y ago
I'll interpret a bit. But I think the remark is more did we have a cross platform and complete gui library for swift.

dagmx 1y ago

Qt have announced they’re doing Swift bindings recently https://www.qt.io/blog/about-the-new-qt-bridging-technology https://www.qt.io/blog/about-the-new-qt-bridging-technology Afaik someone on this site shared a repo url that has the early bindings using Swift C++ interop.

cosmic_cheese 1y ago
Looks like it’s only for Quick and not Widgets, which I’m sure is still useful but kind of a bummer.

teleforce 1y ago

>Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust). What you've enumerated are also applicable to Dlang with potential of even faster compile and execution time than C++ or even the venerable Fortran [1]. [1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

90s_dev 1y ago

When I write code, I always start with the platform, which drives and limits the language choices. I don't say I want to write in C++, I say I want to write for web, or for iOS, or Windows, or whatever. If I'm writing for web, I'll reach for TypeScript. If iOS, then ObjC. If Windows, maybe C# if I'm being threatened. Using Rust to build a web app is like pulling teeth. If many people think the same way, then yeah, there's no good reason to reach for Swift unless you're writing an iOS or Mac app and don't want it to be cross platform for some reason that I almost can't imagine in 2025.

no_time 1y ago

>Swift seems like a really nice language that's held back by it's association with Apple. >Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust). Replace Apple with MS and Swift with C# and all of this is still true but makes my heart ache even more.

dzonga 1y ago

or embracing complexity as C++. It used to be very simple and pragmatic language. that stopped with Swift 3. Remember Protocol based Swift - better than OOP - but now it seems a bastard child of C++. Swift at one point could've been Golang with better C++ interop. A better Rust since it's memory safe without the gymnastics.