12 ms·

The move function is not move semantics (though the latter is being discussed by the community). The main purpose of the move function is to explicitly document

The move function is not move semantics (though the latter is being discussed by the community). The main purpose of the move function is to explicitly document where performance sensitive code depends on a specific type of compiler optimization and providing diagnostics if those conditions change in a subsequent revision of the code. Swift’s focus on progressive disclosure means most Swift users won’t need to worry about this.

tambourine_man 4y ago
Swift’s focus continues to be “how do we make the compiler happy to help it emit faster code” IMO. Very much in line with Lattner's, a compiler guy par excellence, original vision. Unfortunately for me, it's not aligned with my preferences. I like small languages and frameworks that I can master and build upon. Tough luck for me, of course, who cares. But I'm not convinced Swift is also aligned with what should be the language's main purpose: build great iOS and Mac apps.
- tambourine_man 4y ago
  Lattner wanted it all: a language great at system programming, scripting and web framework and building apps. It's very ambitious and unheard of, but so was LLVM, so who knows, maybe he was onto something. 8 years later, it's safe to say it's not the language of choice for the new kernel or driver code, not the one for the hot new web framework and it's not replacing Python. The only thing it's got going for it is that it's the only officially supported choice for making iOS apps going forward. Ultimately, no one uses Swift voluntarily, and that's a bad sign. I write all of this with sorrow, I was cheering with joy when Swift was released.
  - vips7L 4y ago
    > a language great at system programming, scripting and web framework and building apps. Sounds like D.
  - ezfe 4y ago
    > Ultimately, no one uses Swift voluntarily, and that's a bad sign. Not true for me, I've used it successfully for server side work. Being able to use the same language is nice since I can pull in the same routines/data structures and not re-implement them.
    - t00 4y ago
      Voluntarily can be relative: being pushed to use Swift as a recommended language for new iOS development can influence decisions to use it "voluntarily" for backend.
  - jamil7 4y ago
    > Ultimately, no one uses Swift voluntarily I would use it in more places if I could, it's a language I feel extremely productive in. Apple however has shown zero interest in helping popularise it anywhere outside of their ecosystem and left it up to the community.
    - skohan 4y ago
      You could even say they're basically hostile to it.
  - pjmlp 4y ago
    Apple stated at WWDC that is now being used on system level on Ventura. They also dedicated some time on the state of the frameworks session, to put it clearly out there that Objective-C is done and it is time to move on. It took about 20 years for C++ to take over some key areas to C, and even there it wasn't a success in POSIX and embedded, where C still rules. 8 years isn't nothing.
    - mariodiana 4y ago
      > They also dedicated some time on the state of the frameworks session, to put it clearly out there that Objective-C is done and it is time to move on. Is that the "Platforms State of the Union" session from the first day of WWDC 2022? I'm looking in the Developer app right now and can't find the "frameworks" one you're talking about.
      - pjmlp 4y ago
        Yes, that is it, sorry about the wrong naming. Around 4 minutes into it.
        mariodiana 4y ago
        I believe I found the part you're referring to, in Apple's transcript of the talk, and I'm afraid I have to agree with your assessment. What I've found starts like this: > But designs evolve, hardware advances, and what was once cutting edge becomes the expected baseline. The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. https://developer.apple.com/videos/play/wwdc2022/102/ https://developer.apple.com/videos/play/wwdc2022/102/ It gets worse from there, for Objective-C. The speaker goes on to basically say that the new triumvirate of "integrated language, frameworks, and tools" is Swift, SwiftUI, and Xcode Previews, and that these will be evolving together, and influencing one another's evolution, as Objective-C, the "kits," and IB once did for one another. I love coding in Objective-C, and did so for work for almost 5 years. (I've within the last year switched to a front-end developer job.) Swift, to me, whatever its upside, feels like it was written by someone who hates Objective-C. That makes me sad. But, putting aside my editorializing, I read what Apple is saying as basically this. Objective-C, etc., is all but deprecated. At long last, it's being left behind. You may get away writing CRUD apps for a good while longer, but all the new stuff will be Swift-only, and at some point any UI written in Objective-C is going to start to look dated, once the inevitable innovations come.
  - wwalexander 4y ago
    I personally love Swift and find it a joy to use. To be fair, I’m ultimately doing {i,mac}OS dev with it [1] but the parts that actually touch SwiftUI/UIKit/AppKit are just a small part, and I usually start by writing packages with all the business logic/model data. I write Go for work and my all-time favorite language is probably still Rust, but I find that a ton of really thoughtful and smart choices have gone into Swift-the-language as well as how it’s used to build apps. Happy to expand more on what I like about using Swift if you’re curious. [1] which you can now write as the same codebase using SwiftUI
    - tambourine_man 4y ago
      > {i,mac}OS dev I like that. I'm stealing it :) > Happy to expand more on what I like about using Swift if you’re curious. Please! I was very excited with it at the beginning, but the few times I dipped my toe it was frustrating and slow.
      - wwalexander 4y ago
        >I like that. I'm stealing it :) You led me to finally track down the name of this feature in Bash: "brace expansion"! I often wish my non-techie friends recognized this syntax, along with sed replacement syntax for fixing typos. > I was very excited with it at the beginning, but the few times I dipped my toe it was frustrating and slow. Okay, it definitely can be slow to compile, especially with large blocks of type-inferencing ResultBuilder DSLs like SwiftUI or RegexBuilder. I find this mostly occurs when there's a type error within the DSL, and it often takes forever for the compiler to stop trying to do inference and give up with "Type of expression is ambiguous without more context" or simply "The compiler is unable to type-check this expression in reasonable time". But in practice I rarely run into this issue unless I'm creating a massive hierarchy that should be split into smaller components anyway. And I haven't really run into issues with runtime performance yet, though I haven't made anything too performance-critical with it. In any case, Swift makes it decently easy to call out to C/C++/Objective-C if you had a performance-critical routine. What I like about the language: It gives me the satisfaction of languages like Rust that let me express types and logic in a way that feels "correct". I rarely feel like I'm hacking stuff in due to deficiencies in the language. Swift encourages a standard approach of record types with polymorphism but still supports legacy NSObject-based stuff in a logical way, so I never feel like I have to jump through too many hoops if I need to touch dusty old frameworks. I like the type inference, even if it's not perfect category-theoretic Hindley-Milner magic and gets stuck sometimes as mentioned previously. I like the `guard` statement as someone who's done a lot of Go programming and always instinctively used early returns even when my CS professors told me it was a bad practice ;) SwiftUI is really nice to use and is the only UI framework that I've ever enjoyed using (and am hoping to write it for my job soon)--it sometimes feels more like a UI prototyping tool to me because it's so straightforward, except that at some point while prototyping, you realize you've already made the finished UI without writing a dreadful mountain of glue code and interface files! I really like the syntax in general, though I also appreciate Rust's terse symbol-based approach, I think the English-like labels actually work really well despite being a bit verbose. It definitely benefits from an editor with autocompletion, but I wouldn't say it's strictly necessary. I appreciate the strict Unicode-correctness of the language that makes it harder to do bad stuff with strings. I think the ARC-based approach to memory management is a good balance between Go's GC and Rust's borrow checker that makes Swift feel like a very pragmatic choice for lots of different problems (though UI was obviously first in mind). I really like the ArgumentParser and RegexBuilder frameworks, and I think they're the best implementations of each in any language I've used. In general, Swift just feels good to write and easy to read while being extremely powerful in what you can create with it, and coupled with the ease of use and fast feedback of SwiftUI, feels like a very complete approach to creating many different sorts of software, for my own use or to sell.
  - mojuba 4y ago
    > Ultimately, no one uses Swift voluntarily, and that's a bad sign. Sorry but this can't be more wrong. I love Swift so much that I can tolerate and forgive its compiler's sluggishness. Swift is now available on Linux (has been for a while) and there's Apple's server framework called SwiftNIO. It's designed for fast and efficient multithreaded server-side code. I voluntarily picked it for my next backend project and am very happy so far.
    - SimDeBeau 4y ago
      Would you speak more about swift for things other than Mac apps? Last I heard swift was limited to Ubuntu on Linux, and Windows was experimental. Which is too bad because it seems like a really nice language, and I like the ARC garbage collection. But I’m hoping the cross platform story has improved since I last heard.
      - mojuba 4y ago
        According to this page [1] it's Ubuntu, CentOS and Amazon Linux at the moment, and Fedora is underway. I don't know much about Windows because am not considering Windows as a backend OS and I can imagine it would be problematic to support. Swift grew in the UNIX environment and it usually requires some serious effort to port UNIX stuff to Windows. And then I don't even think it will ever be as reliable. On the Linux front, there's Apple's SwiftNIO which is a generic lower-level framework that itself is not an out-of-the-box web or API framework. You need another extra layer above it, which is for example this community-driven project called Vapor [2] You can, in principle, build a e.g. JSON API based on barebones SwiftNIO and you will save a lot of 3rd party dependencies in this case, but this path is a bit masochistic, you really need to know what you are doing in this case. Vapor is much easier to jumpstart any kind of server project with. [1] https://www.swift.org/blog/additional-linux-distros/ https://www.swift.org/blog/additional-linux-distros/ [2] https://vapor.codes https://vapor.codes
    - Tainnor 4y ago
      Swift on Linux / on the server exists, but it's far from a pleasant experience. I admit that I last worked with it in early 2020, but at the time there were numerous annoying open bugs with the Swift compiler on Linux (such as the installer messing with the Python path), and then there was the issue of divergence between Foundation (which is closed-source) and its Linux replacement. Meanwhile, the stack size for secondary threads was ridiculously low and there was no good story for fault recovery (because you don't want to crash your server if you accidentally access an invalid array index). Maybe things have improved, but I'm doubtful.
  - saghm 4y ago
    Honestly, it seems like the association with iOS (or more precisely, the requirement for smooth interop with Objective-C) is what held back Swift from those other goals. I admit that I don't really have any Swift experience personally, but from my conversations with people who have tried to use it for non-iOS purposes, a lot of the pain seems to come from that fact that Swift kind of has this mix of fresh new ideas along with some unfortunate compromises for compatibility. There's a lot of support for more functional paradigms, and yet there's still OO/inheritance, presumably for interop with Objective-C; there are more modern string types, and yet sometimes you have to deal with NSString; there are ways of dealing with errors and optionals functionally, and yet there's still nil and exceptions. I recognize that a lot of people prefer OO and exceptions, but I think having to support both more traditional paradigms and more current popular trends watered down the language a bit and added friction to learning what otherwise could have been a much more streamlined alternative to C++. That said, it's also possible that no first-class support for Linux due to a lot of the innovative stuff going on in the language being tied to the Apple ecosystem could have been enough to stop it from mass adoption, but I can't imagine that it would have had to care so much about Objective-C interop without the Apple ecosystem tie-in, so it's hard for me to reason about whether having the dual paradigm stuff without the Apple tie-in would have been enough to hamper it.
  - hota_mazi 4y ago
    > 8 years later, it's safe to say it's not the language of choice for the new kernel or driver code, not the one for the hot new web framework and it's not replacing Python Rust has become all that, and for a change, I am happy to observe that we're stuck with a pretty good language.
    - tambourine_man 4y ago
      Not quite a Python replacement, but yeah, Rust hits a really interesting spot on the language spectrum. I sense a lot of Rust envy among Swift people. Just my impression, of course. They have much in common, but I think Rust has more merits on its own, particularly in memory management.
      - hota_mazi 4y ago
        Your remark is particularly timely since a Swift proposal to add a move() function just came out. Basically, a timid but interesting step to get Swift to move toward ownership semantics, on top of its current Arc based memory management.
  - janef0421 4y ago
    I think the low adoption of swift outside development for apple platforms is because of the immaturity of the necessary tooling and libraries, not because of issues with the language. There's a sizeable community of people who are passionate about the language and work on that tooling and library support, myself included, but there's not much institutional support outside of apple, so progress is slow.
  - bobbylarrybobby 4y ago
    I was also really rooting for Swift -- it seemed like a cousin of Rust's geared more towards developer experience and ergonomics and less towards performance. Unfortunately I think they squandered their impressive start by being a macOS-only language for the first several years and only becoming cross platform relatively recently.
- skohan 4y ago
  I actually see it in the exactly opposite way. A couple years ago, Swift was a nicely designed language, with a manageable number of composable features which could be used to do just about anything. With the features which were released alongside SwiftUI, it seems like that went out the window, and Swift pivoted towards being a DSL for iPhone apps.
  - kaba0 4y ago
    I honestly don’t understand what were they thinking. Choose a random language’s random feature and swift has it. That’s hardly a good thing for a programming language, and it shows — there are some very nasty interactions between different features.
    - skohan 4y ago
      I still think there's a lot to like about Swift, and actually programming in some subset of Swift is some of the most fun and expressive programming I can think of, but it has undoubtedly become kind of a mess. A lot of magic happening, and not in a good way.
      - kaba0 4y ago
        I agree, I was very enthusiastic at the beginning of learning it. And if nothing else, it is a great refresher of Pl features. I’m just afraid that the language can’t be properly maintained from the insane matrix of all these features (I once got a type inference timed out error..)
        Tainnor 4y ago
        > I once got a type inference timed out error.. I used to work on a large Swift program. "Type inference timed out" was an incredibly common error that we would encounter (we used a lot of operator overloading and generics and that had something to do with it). I have never encountered any other language where this was such a regular problem.
  - 4y ago
- TheTon 4y ago
  I had hoped ObjCs successor for app development would be something like FScript. Something that removed the footguns and unnecessary ceremony from ObjC but that had good interop with existing code. Instead we got Swift, which ironically, given its uptake by external devs, I think was aimed at complaints from internal Apple users. Internal users at Apple were frustrated by how easy it was for external devs to introspect and modify private ObjC framework code. They also wanted performance features like value types and method inlining. I don’t think many external app devs cared about those things, or to the extent they did C++ was an attractive option because a stable ABI doesn’t really matter internal to application code. I continue to use ObjC for Mac and iOS dev because it’s a much simpler language than Swift, the system APIs I interact with are still implemented in ObjC, and C++ interop is easier via ObjC++. I suppose the day will come where I need something that is only accessible from Swift, and I’ll write Swift then, but for now Swift doesn’t solve any problems that I have.
  - thealistra 4y ago
    I was very happy when swift was introduced and it solved many classes of bugs that were very popular in Obj-C. It was very much a big help for external developers. Swift apps are not crashing randomly, you don't have nils running rampant because of type safety. You can create types that nicely convey reality using rich enums and you don't have to define objects with 18 fields that are mostly always nil, but when propertyA == 16, then this field has some value. Swift also is not an official superset of C, like Objective-C, so you don't have all the footguns of C language, like integer promotions and assignment being an expression. You just have so much improvements over objective-C if you want to ship an app to hundreds of thousands of users and be sure that it works correctly and that unhandled edge cases won't blow up. Maybe it is more complex to write a compilable piece of swift, that a compilable piece of Objective-C, but I am happy that this is the case, because it means that the compiler has my back and finds bugs and issues for me.
    - tl 4y ago
      I agree with the premise "you don't have nils running rampant because of type safety" but the reality "Swift apps are not crashing randomly" is far from the truth. Right now, I have a research project using Swift Charts and it definately "crashes randomly" partially because Charts expects a subset of type-safe values and does not communicate which subset except by chucking EXC_BAD_ACCESS with no usable error. Sure, that's example of a beta framework. However, SwiftUI is the proposed Swift-y replacement to Objective-C's UIKit and is loaded with examples of "the type system we moved to should catch this but can't" followed by the even more common "the type system will catch this error in 11,000 years when it's finished failing to compile code on an M1".
- pjmlp 4y ago
  The language main purpose was always to be a replacement for C, C++ and Objective-C. It has been on Swift documentation from day one.
  - tambourine_man 4y ago
    Officially stated goal, sure. But read/listen to what Lattner says and you get a different take.
    - pjmlp 4y ago
      I do and he says exactly the same thing. >...the goal was really to build something that you could write firmware in or that you could do scripting in, that you could write mobile apps or server apps or low-level systems code, and have it be great at all of those, not just some terrible compromise. Taken from https://oleb.net/2019/chris-lattner-swift-origins/ https://oleb.net/2019/chris-lattner-swift-origins/ to save listing to the whole interview Feel free to actually listen to the episode as well, and also read/listen the sections on how Swift is a complete Objective-C replacement without the bad C parts.
      - tambourine_man 4y ago
        I misread your first post, sorry. Yeah, it's one heck of a goal.
- liuliu 4y ago
  I wish this is true. But from all the things Swift has supported. It doesn't make compiler or compiler authors happy. I wish there are more languages that focused on happiness of the compiler authors so that they can write efficient and small compilers with well-thought language features that intentionally limits how much they need to write in the compiler. Today we have such a huge compiler maintenance burden and as a result, you saw inconsistencies everywhere with these languages, and it is after many hundreds of person-year spent. (Yeah, Go is probably one of the language that focused on compiler authors' happiness)
xbar 4y ago
This is a helpful clarification.

tambourine_man 4y ago

Swift’s focus continues to be “how do we make the compiler happy to help it emit faster code” IMO. Very much in line with Lattner's, a compiler guy par excellence, original vision. Unfortunately for me, it's not aligned with my preferences. I like small languages and frameworks that I can master and build upon. Tough luck for me, of course, who cares. But I'm not convinced Swift is also aligned with what should be the language's main purpose: build great iOS and Mac apps.

tambourine_man 4y ago
Lattner wanted it all: a language great at system programming, scripting and web framework and building apps. It's very ambitious and unheard of, but so was LLVM, so who knows, maybe he was onto something. 8 years later, it's safe to say it's not the language of choice for the new kernel or driver code, not the one for the hot new web framework and it's not replacing Python. The only thing it's got going for it is that it's the only officially supported choice for making iOS apps going forward. Ultimately, no one uses Swift voluntarily, and that's a bad sign. I write all of this with sorrow, I was cheering with joy when Swift was released.
- vips7L 4y ago
  > a language great at system programming, scripting and web framework and building apps. Sounds like D.
- ezfe 4y ago
  > Ultimately, no one uses Swift voluntarily, and that's a bad sign. Not true for me, I've used it successfully for server side work. Being able to use the same language is nice since I can pull in the same routines/data structures and not re-implement them.
  - t00 4y ago
    Voluntarily can be relative: being pushed to use Swift as a recommended language for new iOS development can influence decisions to use it "voluntarily" for backend.
- jamil7 4y ago
  > Ultimately, no one uses Swift voluntarily I would use it in more places if I could, it's a language I feel extremely productive in. Apple however has shown zero interest in helping popularise it anywhere outside of their ecosystem and left it up to the community.
  - skohan 4y ago
    You could even say they're basically hostile to it.
- pjmlp 4y ago
  Apple stated at WWDC that is now being used on system level on Ventura. They also dedicated some time on the state of the frameworks session, to put it clearly out there that Objective-C is done and it is time to move on. It took about 20 years for C++ to take over some key areas to C, and even there it wasn't a success in POSIX and embedded, where C still rules. 8 years isn't nothing.
  - mariodiana 4y ago
    > They also dedicated some time on the state of the frameworks session, to put it clearly out there that Objective-C is done and it is time to move on. Is that the "Platforms State of the Union" session from the first day of WWDC 2022? I'm looking in the Developer app right now and can't find the "frameworks" one you're talking about.
    - pjmlp 4y ago
      Yes, that is it, sorry about the wrong naming. Around 4 minutes into it.
      - mariodiana 4y ago
        I believe I found the part you're referring to, in Apple's transcript of the talk, and I'm afraid I have to agree with your assessment. What I've found starts like this: > But designs evolve, hardware advances, and what was once cutting edge becomes the expected baseline. The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. https://developer.apple.com/videos/play/wwdc2022/102/ https://developer.apple.com/videos/play/wwdc2022/102/ It gets worse from there, for Objective-C. The speaker goes on to basically say that the new triumvirate of "integrated language, frameworks, and tools" is Swift, SwiftUI, and Xcode Previews, and that these will be evolving together, and influencing one another's evolution, as Objective-C, the "kits," and IB once did for one another. I love coding in Objective-C, and did so for work for almost 5 years. (I've within the last year switched to a front-end developer job.) Swift, to me, whatever its upside, feels like it was written by someone who hates Objective-C. That makes me sad. But, putting aside my editorializing, I read what Apple is saying as basically this. Objective-C, etc., is all but deprecated. At long last, it's being left behind. You may get away writing CRUD apps for a good while longer, but all the new stuff will be Swift-only, and at some point any UI written in Objective-C is going to start to look dated, once the inevitable innovations come.
- wwalexander 4y ago
  I personally love Swift and find it a joy to use. To be fair, I’m ultimately doing {i,mac}OS dev with it [1] but the parts that actually touch SwiftUI/UIKit/AppKit are just a small part, and I usually start by writing packages with all the business logic/model data. I write Go for work and my all-time favorite language is probably still Rust, but I find that a ton of really thoughtful and smart choices have gone into Swift-the-language as well as how it’s used to build apps. Happy to expand more on what I like about using Swift if you’re curious. [1] which you can now write as the same codebase using SwiftUI
  - tambourine_man 4y ago
    > {i,mac}OS dev I like that. I'm stealing it :) > Happy to expand more on what I like about using Swift if you’re curious. Please! I was very excited with it at the beginning, but the few times I dipped my toe it was frustrating and slow.
    - wwalexander 4y ago
      >I like that. I'm stealing it :) You led me to finally track down the name of this feature in Bash: "brace expansion"! I often wish my non-techie friends recognized this syntax, along with sed replacement syntax for fixing typos. > I was very excited with it at the beginning, but the few times I dipped my toe it was frustrating and slow. Okay, it definitely can be slow to compile, especially with large blocks of type-inferencing ResultBuilder DSLs like SwiftUI or RegexBuilder. I find this mostly occurs when there's a type error within the DSL, and it often takes forever for the compiler to stop trying to do inference and give up with "Type of expression is ambiguous without more context" or simply "The compiler is unable to type-check this expression in reasonable time". But in practice I rarely run into this issue unless I'm creating a massive hierarchy that should be split into smaller components anyway. And I haven't really run into issues with runtime performance yet, though I haven't made anything too performance-critical with it. In any case, Swift makes it decently easy to call out to C/C++/Objective-C if you had a performance-critical routine. What I like about the language: It gives me the satisfaction of languages like Rust that let me express types and logic in a way that feels "correct". I rarely feel like I'm hacking stuff in due to deficiencies in the language. Swift encourages a standard approach of record types with polymorphism but still supports legacy NSObject-based stuff in a logical way, so I never feel like I have to jump through too many hoops if I need to touch dusty old frameworks. I like the type inference, even if it's not perfect category-theoretic Hindley-Milner magic and gets stuck sometimes as mentioned previously. I like the `guard` statement as someone who's done a lot of Go programming and always instinctively used early returns even when my CS professors told me it was a bad practice ;) SwiftUI is really nice to use and is the only UI framework that I've ever enjoyed using (and am hoping to write it for my job soon)--it sometimes feels more like a UI prototyping tool to me because it's so straightforward, except that at some point while prototyping, you realize you've already made the finished UI without writing a dreadful mountain of glue code and interface files! I really like the syntax in general, though I also appreciate Rust's terse symbol-based approach, I think the English-like labels actually work really well despite being a bit verbose. It definitely benefits from an editor with autocompletion, but I wouldn't say it's strictly necessary. I appreciate the strict Unicode-correctness of the language that makes it harder to do bad stuff with strings. I think the ARC-based approach to memory management is a good balance between Go's GC and Rust's borrow checker that makes Swift feel like a very pragmatic choice for lots of different problems (though UI was obviously first in mind). I really like the ArgumentParser and RegexBuilder frameworks, and I think they're the best implementations of each in any language I've used. In general, Swift just feels good to write and easy to read while being extremely powerful in what you can create with it, and coupled with the ease of use and fast feedback of SwiftUI, feels like a very complete approach to creating many different sorts of software, for my own use or to sell.
- mojuba 4y ago
  > Ultimately, no one uses Swift voluntarily, and that's a bad sign. Sorry but this can't be more wrong. I love Swift so much that I can tolerate and forgive its compiler's sluggishness. Swift is now available on Linux (has been for a while) and there's Apple's server framework called SwiftNIO. It's designed for fast and efficient multithreaded server-side code. I voluntarily picked it for my next backend project and am very happy so far.
  - SimDeBeau 4y ago
    Would you speak more about swift for things other than Mac apps? Last I heard swift was limited to Ubuntu on Linux, and Windows was experimental. Which is too bad because it seems like a really nice language, and I like the ARC garbage collection. But I’m hoping the cross platform story has improved since I last heard.
    - mojuba 4y ago
      According to this page [1] it's Ubuntu, CentOS and Amazon Linux at the moment, and Fedora is underway. I don't know much about Windows because am not considering Windows as a backend OS and I can imagine it would be problematic to support. Swift grew in the UNIX environment and it usually requires some serious effort to port UNIX stuff to Windows. And then I don't even think it will ever be as reliable. On the Linux front, there's Apple's SwiftNIO which is a generic lower-level framework that itself is not an out-of-the-box web or API framework. You need another extra layer above it, which is for example this community-driven project called Vapor [2] You can, in principle, build a e.g. JSON API based on barebones SwiftNIO and you will save a lot of 3rd party dependencies in this case, but this path is a bit masochistic, you really need to know what you are doing in this case. Vapor is much easier to jumpstart any kind of server project with. [1] https://www.swift.org/blog/additional-linux-distros/ https://www.swift.org/blog/additional-linux-distros/ [2] https://vapor.codes https://vapor.codes
  - Tainnor 4y ago
    Swift on Linux / on the server exists, but it's far from a pleasant experience. I admit that I last worked with it in early 2020, but at the time there were numerous annoying open bugs with the Swift compiler on Linux (such as the installer messing with the Python path), and then there was the issue of divergence between Foundation (which is closed-source) and its Linux replacement. Meanwhile, the stack size for secondary threads was ridiculously low and there was no good story for fault recovery (because you don't want to crash your server if you accidentally access an invalid array index). Maybe things have improved, but I'm doubtful.
- saghm 4y ago
  Honestly, it seems like the association with iOS (or more precisely, the requirement for smooth interop with Objective-C) is what held back Swift from those other goals. I admit that I don't really have any Swift experience personally, but from my conversations with people who have tried to use it for non-iOS purposes, a lot of the pain seems to come from that fact that Swift kind of has this mix of fresh new ideas along with some unfortunate compromises for compatibility. There's a lot of support for more functional paradigms, and yet there's still OO/inheritance, presumably for interop with Objective-C; there are more modern string types, and yet sometimes you have to deal with NSString; there are ways of dealing with errors and optionals functionally, and yet there's still nil and exceptions. I recognize that a lot of people prefer OO and exceptions, but I think having to support both more traditional paradigms and more current popular trends watered down the language a bit and added friction to learning what otherwise could have been a much more streamlined alternative to C++. That said, it's also possible that no first-class support for Linux due to a lot of the innovative stuff going on in the language being tied to the Apple ecosystem could have been enough to stop it from mass adoption, but I can't imagine that it would have had to care so much about Objective-C interop without the Apple ecosystem tie-in, so it's hard for me to reason about whether having the dual paradigm stuff without the Apple tie-in would have been enough to hamper it.
- hota_mazi 4y ago
  > 8 years later, it's safe to say it's not the language of choice for the new kernel or driver code, not the one for the hot new web framework and it's not replacing Python Rust has become all that, and for a change, I am happy to observe that we're stuck with a pretty good language.
  - tambourine_man 4y ago
    Not quite a Python replacement, but yeah, Rust hits a really interesting spot on the language spectrum. I sense a lot of Rust envy among Swift people. Just my impression, of course. They have much in common, but I think Rust has more merits on its own, particularly in memory management.
    - hota_mazi 4y ago
      Your remark is particularly timely since a Swift proposal to add a move() function just came out. Basically, a timid but interesting step to get Swift to move toward ownership semantics, on top of its current Arc based memory management.
- janef0421 4y ago
  I think the low adoption of swift outside development for apple platforms is because of the immaturity of the necessary tooling and libraries, not because of issues with the language. There's a sizeable community of people who are passionate about the language and work on that tooling and library support, myself included, but there's not much institutional support outside of apple, so progress is slow.
- bobbylarrybobby 4y ago
  I was also really rooting for Swift -- it seemed like a cousin of Rust's geared more towards developer experience and ergonomics and less towards performance. Unfortunately I think they squandered their impressive start by being a macOS-only language for the first several years and only becoming cross platform relatively recently.
skohan 4y ago
I actually see it in the exactly opposite way. A couple years ago, Swift was a nicely designed language, with a manageable number of composable features which could be used to do just about anything. With the features which were released alongside SwiftUI, it seems like that went out the window, and Swift pivoted towards being a DSL for iPhone apps.
- kaba0 4y ago
  I honestly don’t understand what were they thinking. Choose a random language’s random feature and swift has it. That’s hardly a good thing for a programming language, and it shows — there are some very nasty interactions between different features.
  - skohan 4y ago
    I still think there's a lot to like about Swift, and actually programming in some subset of Swift is some of the most fun and expressive programming I can think of, but it has undoubtedly become kind of a mess. A lot of magic happening, and not in a good way.
    - kaba0 4y ago
      I agree, I was very enthusiastic at the beginning of learning it. And if nothing else, it is a great refresher of Pl features. I’m just afraid that the language can’t be properly maintained from the insane matrix of all these features (I once got a type inference timed out error..)
      - Tainnor 4y ago
        > I once got a type inference timed out error.. I used to work on a large Swift program. "Type inference timed out" was an incredibly common error that we would encounter (we used a lot of operator overloading and generics and that had something to do with it). I have never encountered any other language where this was such a regular problem.
- 4y ago
TheTon 4y ago
I had hoped ObjCs successor for app development would be something like FScript. Something that removed the footguns and unnecessary ceremony from ObjC but that had good interop with existing code. Instead we got Swift, which ironically, given its uptake by external devs, I think was aimed at complaints from internal Apple users. Internal users at Apple were frustrated by how easy it was for external devs to introspect and modify private ObjC framework code. They also wanted performance features like value types and method inlining. I don’t think many external app devs cared about those things, or to the extent they did C++ was an attractive option because a stable ABI doesn’t really matter internal to application code. I continue to use ObjC for Mac and iOS dev because it’s a much simpler language than Swift, the system APIs I interact with are still implemented in ObjC, and C++ interop is easier via ObjC++. I suppose the day will come where I need something that is only accessible from Swift, and I’ll write Swift then, but for now Swift doesn’t solve any problems that I have.
- thealistra 4y ago
  I was very happy when swift was introduced and it solved many classes of bugs that were very popular in Obj-C. It was very much a big help for external developers. Swift apps are not crashing randomly, you don't have nils running rampant because of type safety. You can create types that nicely convey reality using rich enums and you don't have to define objects with 18 fields that are mostly always nil, but when propertyA == 16, then this field has some value. Swift also is not an official superset of C, like Objective-C, so you don't have all the footguns of C language, like integer promotions and assignment being an expression. You just have so much improvements over objective-C if you want to ship an app to hundreds of thousands of users and be sure that it works correctly and that unhandled edge cases won't blow up. Maybe it is more complex to write a compilable piece of swift, that a compilable piece of Objective-C, but I am happy that this is the case, because it means that the compiler has my back and finds bugs and issues for me.
  - tl 4y ago
    I agree with the premise "you don't have nils running rampant because of type safety" but the reality "Swift apps are not crashing randomly" is far from the truth. Right now, I have a research project using Swift Charts and it definately "crashes randomly" partially because Charts expects a subset of type-safe values and does not communicate which subset except by chucking EXC_BAD_ACCESS with no usable error. Sure, that's example of a beta framework. However, SwiftUI is the proposed Swift-y replacement to Objective-C's UIKit and is loaded with examples of "the type system we moved to should catch this but can't" followed by the even more common "the type system will catch this error in 11,000 years when it's finished failing to compile code on an M1".
pjmlp 4y ago
The language main purpose was always to be a replacement for C, C++ and Objective-C. It has been on Swift documentation from day one.
- tambourine_man 4y ago
  Officially stated goal, sure. But read/listen to what Lattner says and you get a different take.
  - pjmlp 4y ago
    I do and he says exactly the same thing. >...the goal was really to build something that you could write firmware in or that you could do scripting in, that you could write mobile apps or server apps or low-level systems code, and have it be great at all of those, not just some terrible compromise. Taken from https://oleb.net/2019/chris-lattner-swift-origins/ https://oleb.net/2019/chris-lattner-swift-origins/ to save listing to the whole interview Feel free to actually listen to the episode as well, and also read/listen the sections on how Swift is a complete Objective-C replacement without the bad C parts.
    - tambourine_man 4y ago
      I misread your first post, sorry. Yeah, it's one heck of a goal.
liuliu 4y ago
I wish this is true. But from all the things Swift has supported. It doesn't make compiler or compiler authors happy. I wish there are more languages that focused on happiness of the compiler authors so that they can write efficient and small compilers with well-thought language features that intentionally limits how much they need to write in the compiler. Today we have such a huge compiler maintenance burden and as a result, you saw inconsistencies everywhere with these languages, and it is after many hundreds of person-year spent. (Yeah, Go is probably one of the language that focused on compiler authors' happiness)

xbar 4y ago

This is a helpful clarification.