7 ms·

There's nothing about Swift that has me interested, curious or excited. That said, I haven't done much research into it. What is new and interesting about Swift

There's nothing about Swift that has me interested, curious or excited. That said, I haven't done much research into it. What is new and interesting about Swift? From looking through the swift official site, it just seems like a new C# or Java with ahead of time compilation. The only slightly unique bit I can find is that the syntax is a bit more JavaScript inspired. Am I missing something? Or that's it? It's just the C# of Apple? For example, Rust has borrow checking for zero cost memory safety. Go has concurrent sequential processes and its accompanying goroutines. Haskell is a fully pure language. Python has cool indent based syntax that looks like pseudocode. Ruby is objects all the way down and has this unique concept of blocks for passing code around to be yielded. Clojure has immutable persistent data-structures as default and software transactional memory, while also being a Lisp bringing macros and all to the JVM. Erlang has actor concurrency. Etc. So in a similar vein, what would be Swift's innovation or originality here?

jibolash 6y ago
You realize you are speaking of a 6 year old language right? For some reason, it sounds like you are referring to some newly launched shiny new language that nobody has ever done anything with.
- cblconfederate 6y ago
  that doesnt answer the question
  - djcapelis 6y ago
    I think it’s a good point actually. I think it’s reasonable to say swift isn’t intended as a language to experiment with a specific concept, it’s a six year old production language designed for a general set of usecases where it’s good at a bunch of things that the languages it is replacing weren’t as good at. There’s some interesting discussions to be had about tradeoffs it makes but a question like “what’s the one thing swift does that other languages don’t do” is not the right way to evaluate a production language. It might explain why some people don’t find it interesting but swift was built to be a better tool, not merely an interesting one. A lot of really good programming languages are “uninteresting” in this way, and that’s probably a good sign, not a bad one.
    - cblconfederate 6y ago
      the question was in the context of swift open sourcing something. if it s an apple-ecosystem-specific language , it s not much use to the general audience
    - meragrin_ 6y ago
      There was no point made other than the language is 6 years old and "someone" uses it. That's nice. I'm sure I can find other languages 6 years or older which people use and are not worth using. How long has Swift been available outside of Apple platforms? And I don't mean experimentally available either. They only posted an announcement a few days ago where Swift is deemed ready for early adopters on Windows. That certainly does not sound production quality there.
      - jshier 6y ago
        Swift has been officially available on Linux since it was open sourced in Dec. 2015.
        deleted 6y ago
        [deleted]
- meragrin_ 6y ago
  You do realize Swift has only been officially supported for early adopters on Windows less than a week now? Ubuntu was the only officially supported distribution of Linux until earlier this year. Were any of the Linux distributions creating their own Swift packages?
lisper 6y ago
> Am I missing something? Yes: Swift is now (and has been for a while) the standard language for developing iOS and MacOS apps. That makes it important completely independent of any features it may or may not have.
- biztos 6y ago
  Also, through the various *Kit libraries and now (sooner or later) SwiftUI, Apple is staking out a rapid-development territory that will be hard for the other ecosystem(s?) to match. So, if you have to choose between making your app for iOS first, or Android first, then in addition to any consideration of markets which might or might not apply to your business model, you will have a very strong incentive to choose Apple for time to production. I would love to see more serious competition on that front.
- k__ 6y ago
  While a huge boon for the poor ObjC devs, this doesn't seem like much of a thing for the rest of the world.
- didibus 6y ago
  That is my current impression. Practically speaking, this is huge off course, but it's nothing inherent to Swift. Apple could have embraced any language, no matter what it was like, good or bad, and it be on this privilege position that would undoubtedly make it successful. And up until now, I was thinking I'll try Swift the day I'm forced too, because I'm working to develop an app for Mac or iOS. But then I started seeing some comments like: "For me, Swift is currently the most interesting language". So I thought I might be overlooking something. The most innovative feature I can find is null safety, which is alright, but I guess I've had my fun with it with Kotlin already. Someone mentioned good ABI compatibility, that is interesting, and I'll need to read up on that. Others say, it's just a nice mix of modern features in a well maintained package. That's great as well, you could argue C# and Java being older have some less modern aspects lingering. But that's nothing that makes me want to jump in it and try to use it for my next project.
frogblast 6y ago
The primary feature of Swift is that it a more safe language (via many of the same mechanisms in languages you referred to above), while being extremely compatible with the extremely large API surface area of iOS/macOS (which is both in C and Objective-C), and allowing incremental adoption without having to rewrite existing application/library code. To have adopted any of those other languages requires dramatic changes to a huge amount of platform APIs, along with on-going challenges of divergence. Put another way, any other language would have basically forked the entire platform. The Swift developers definitely have ambitions beyond being a compatible with Apple's existing SDKs, but that's the fundamental thing Swift does that no other language can do.
nicoburns 6y ago
The best thing about swift is it's ML-style type system (incidentally this is also one of the best things about Rust, and one of the reasons why Rust is competitive in "higher level" application development scenarios as well as "systems programming"). For me Sum Types and pattern matching in particular are an absolutely massive improvement over languages that only have classes/structs. They make statically typed languages feel almost as expressive as dynamic ones.
- symlinkk 6y ago
  TypeScript has this too
  - IggleSniggle 6y ago
    Sort of. Although I will say that the upcoming TypeScript 4.1 with its string-template types potentially opens up TypeScript to limitless power. Imagine the expressiveness and power of tcl, but as your type system / type definitions. The weird thing about typescript is that this incredible power and expressively must be backported into the runtime environment. And because of that, the promises that the type system makes are unreliable and also lag way behind the actual language features that are implemented. I hope these criticisms are read in the proper context: I absolutely love TypeScript, and find it to be a really special unique oddball in the world of language design. I wish it had been ReasonML instead of TypeScript, but TypeScript is incrementally working it’s way there and bringing the whole js community with it, so I can’t complain. Edit: Prediction: prepare for switch statements to become popular as the typescript community gradually adopts exhaustive pattern-matching types.
    - symlinkk 6y ago
      What do you mean by “the promises that the type system makes are unreliable”?
      - jbboehr 6y ago
        The type of an underlying variable at runtime may be different than what the typescript type declares. Practically, this would probably be due to either poor, incorrect, out-of-sync, or incomplete type definitions. A poor example, but this compiles without error and crashes at runtime: let x: string = "foo"; (x as any) = 1; x.substr(0); Now, technically, you can do this sort of thing in most, if not all, languages, but this happens organically more often with typescript due to many libraries being written for plain javascript and being looser on their types, or type definitions getting out of sync with the libraries they are written for.
NobodyNada 6y ago
In my personal experience, Swift occupies the sweet spot in between Rust and something like Python for application-level programming. It's a modern and well-designed language with a Rust-like strong and expressive type system, including useful generics, powerful enums, and safe error handling. It also has fairly straightforward memory management, really straightforward polymorphism, seamless C interop, and good performance -- though it's not quite as fast as Rust because it prioritizes ease of use over zero-cost abstractions. So no, it doesn't really have a whole lot of "innovation or originality" -- but it essentially takes some of the best ideas of modern language design and wraps them into one general-purpose language for application development, and as a result I find it to be a really useful and practical language.
kitsunesoba 6y ago
In terms of syntax it's much closer to Kotlin than it is C# (though still different). It has seamless interop with Objective-C and C, and can be mixed with about any language LLVM/Clang can handle (as long as you have C headers), compiling it all down to a small, self-contained binary. For now it's mainly useful on Apple platforms, but there's interest and efforts in cross platform from both Apple and the Swift community, so there's a lot of potential for it to be a great language for the main body of application code, with individual bits of functionality written in languages that make the most sense without too many layers of adapters or wrappers.
- nsonha 6y ago
  I think the person meant in terms of identifiable trait/philosophy/focus. Swift and c# and maybe even kotlin are languages that are just a big piles of feature and does not really have an principle behind its design like stupid simple of golang or lazyness of haskel
  - TylerE 6y ago
    at a time when every language is trying to be edgy/different, it'd be nice to have an actual language that is comfortable and boring without being dumb. Seems like a viable niche to me.
    - nsonha 6y ago
      this is not a boring language, it has a lot of complexity. I prefer simple but interesting language, f# comes to mind.
      - TylerE 6y ago
        Boring in the sense of not being, well, Rust, or a lisp, or an ML derivative or...
    - nsonha 6y ago
      The people that don't like edgy PL features normally also prefer a clean and simple language with orthogonal design not the big-pile-of-features kind of language though.
oconnor663 6y ago
Swift has done some very original things around ABI stability: https://gankra.github.io/blah/swift-abi/ https://gankra.github.io/blah/swift-abi/
Someone 6y ago
Firstly, wants wrong with being “the C# of Apple”? I think they wanted a language that can coexist with objective-C libraries, and is reasonably memory-efficient (adding RAM to phones decreases battery life) that they could control, and created it. They certainly didn’t just make run-of-the mill choices for all language features. Some non-standard design choices they made (for better or for worse): - Reference counting without any automated cycle-breaking - Collections are value types (implemented somewhat efficiently by having copy-on-write collections) - the Character type is closer to what ‘normal’ people think a character is (https://developer.apple.com/documentation/swift/character https://developer.apple.com/documentation/swift/character) - consequently, string length is closer to what users who don’t know Unicode internals expect it to be. - Arrays are ‘different’ (‘inherited’ from NSArray. See https://ridiculousfish.com/blog/posts/array.html https://ridiculousfish.com/blog/posts/array.html) - protocols are a bit like interfaces, but protocol conformance can retroactively be added to classes, even to ones you didn’t write or don’t have the source code of.
- cmckn 6y ago
  > the Character type is closer to what ‘normal’ people think a character is I'm sure I'm missing some nuanced downside to this, but this sounds fantastic. I've never fully understood the difference between Unicode code points and code units[0], and would love to think less about this sort of thing in Java (for ex. when using String#toCharArray). [0] I'm just regurgitating language from the String javadoc, this sentence might not even make sense.
  - didibus 6y ago
    I could see issue if using it for splitting strings, but I guess it also depends what Swift assumes to be what normal people think a character is. Most normal people assume Unicode grapheme to be characters. That would be the set of symbols you'd consider a single letter if you were to visually count the number of symbols in the string. In Unicode though, some code points are non visible, yet are part of the string. So for example, the character at i+1 for some match against a letter might not be the next visible letter. I can see this causing issue either way. Honestly, I'd say it's best to just learn this, it you'll have some weird bugs one way or another. Basically, you have code units, those are the smallest chunk of bit that has meaning in Unicode and thus can be sent over a wire, streamed or decoded. In UTF-16 encoding, which is what JVM uses, code units are 16 bit. The history helps. In the beginning, each character in Unicode was 16bit. So you could represent all Unicode characters with 16bit only. Later, there were even more characters added, and it couldn't fit into 16bit. So UTF-16 where the 16 tells you the code units is 16 bit no longer could represent all characters in one 16 bit unit. Thus code points were invented, those are characters that span two code units 16bit + 16bit. Together they represent the new characters that didn't fit in the single 16bit range. So nowadays, it actually takes 21 bits to represent all Unicode characters. There's three encodings: UTF-8, UTF-16 and UTF-32. Their number correspond to the bit size of their code units. In UTF-8 we break each character into 8 bit units. In UTF-16 we do so in 16 bit units, and in UTF-32 into 32 bit units. Ok, now back to measuring length. We can say tell me the number of code units used to represent the string. That's what Java's string.length() does. Or we can say telle the number of bytes needed to represent the string (a byte is 8bit). That's what converting to byteArray and getting the length of the array does. Or you can say tell me the number of code points (Unicode characters) the string contains. In UTF-16 a code point can be 16bit (composed of one unit only), or it can be 32 bit (composed of two units). But not all Unicode characters are visible, so the user might be surprised to get a length that is greater than what it counts visually. So you can also get the number of grapheme in the string, which are "visual characters". In Java you can use BreakIterator to count those. That said, Unicode grapheme don't always make sense to what each speaker of each language would consider a character. That's for example some languages might consider a combo of two letters one character with one pronunciation, etc. Finally, I'll say there's another interesting length. It's the font width in terms of physical measures like pixel count. So basically, each measure might be most appropriate depending what your measuring for. I think the real issue is that we didn't adopt new terminology of Unicode yet. You should try to start referring to things as code units, code points, grapheme and font width/height. And stop using the word character or letter. And then just make yourself a little library that has string.codeUnitCount(), string.codePointCount(), string.graphemeCount() and string.pixelWidth(). And when you don't care about the difference between these, I'd argue that code unit count is the best default for length, which is why I don't actually disagree with string.length counting code units. Cause I think of string.length from the perspective of looping over the smallest units of the string.
solidsnack9000 6y ago
The really cool thing about Swift is it's lack of innovation or originality. It is ALGOL 2014. It tries to integrate a few more patterns into the structured programming paradigm.

jibolash 6y ago

You realize you are speaking of a 6 year old language right? For some reason, it sounds like you are referring to some newly launched shiny new language that nobody has ever done anything with.

cblconfederate 6y ago
that doesnt answer the question
- djcapelis 6y ago
  I think it’s a good point actually. I think it’s reasonable to say swift isn’t intended as a language to experiment with a specific concept, it’s a six year old production language designed for a general set of usecases where it’s good at a bunch of things that the languages it is replacing weren’t as good at. There’s some interesting discussions to be had about tradeoffs it makes but a question like “what’s the one thing swift does that other languages don’t do” is not the right way to evaluate a production language. It might explain why some people don’t find it interesting but swift was built to be a better tool, not merely an interesting one. A lot of really good programming languages are “uninteresting” in this way, and that’s probably a good sign, not a bad one.
  - cblconfederate 6y ago
    the question was in the context of swift open sourcing something. if it s an apple-ecosystem-specific language , it s not much use to the general audience
  - meragrin_ 6y ago
    There was no point made other than the language is 6 years old and "someone" uses it. That's nice. I'm sure I can find other languages 6 years or older which people use and are not worth using. How long has Swift been available outside of Apple platforms? And I don't mean experimentally available either. They only posted an announcement a few days ago where Swift is deemed ready for early adopters on Windows. That certainly does not sound production quality there.
    - jshier 6y ago
      Swift has been officially available on Linux since it was open sourced in Dec. 2015.
      - deleted 6y ago
        [deleted]
meragrin_ 6y ago
You do realize Swift has only been officially supported for early adopters on Windows less than a week now? Ubuntu was the only officially supported distribution of Linux until earlier this year. Were any of the Linux distributions creating their own Swift packages?

lisper 6y ago

> Am I missing something? Yes: Swift is now (and has been for a while) the standard language for developing iOS and MacOS apps. That makes it important completely independent of any features it may or may not have.

biztos 6y ago
Also, through the various *Kit libraries and now (sooner or later) SwiftUI, Apple is staking out a rapid-development territory that will be hard for the other ecosystem(s?) to match. So, if you have to choose between making your app for iOS first, or Android first, then in addition to any consideration of markets which might or might not apply to your business model, you will have a very strong incentive to choose Apple for time to production. I would love to see more serious competition on that front.
k__ 6y ago
While a huge boon for the poor ObjC devs, this doesn't seem like much of a thing for the rest of the world.
didibus 6y ago
That is my current impression. Practically speaking, this is huge off course, but it's nothing inherent to Swift. Apple could have embraced any language, no matter what it was like, good or bad, and it be on this privilege position that would undoubtedly make it successful. And up until now, I was thinking I'll try Swift the day I'm forced too, because I'm working to develop an app for Mac or iOS. But then I started seeing some comments like: "For me, Swift is currently the most interesting language". So I thought I might be overlooking something. The most innovative feature I can find is null safety, which is alright, but I guess I've had my fun with it with Kotlin already. Someone mentioned good ABI compatibility, that is interesting, and I'll need to read up on that. Others say, it's just a nice mix of modern features in a well maintained package. That's great as well, you could argue C# and Java being older have some less modern aspects lingering. But that's nothing that makes me want to jump in it and try to use it for my next project.

frogblast 6y ago

The primary feature of Swift is that it a more safe language (via many of the same mechanisms in languages you referred to above), while being extremely compatible with the extremely large API surface area of iOS/macOS (which is both in C and Objective-C), and allowing incremental adoption without having to rewrite existing application/library code. To have adopted any of those other languages requires dramatic changes to a huge amount of platform APIs, along with on-going challenges of divergence. Put another way, any other language would have basically forked the entire platform. The Swift developers definitely have ambitions beyond being a compatible with Apple's existing SDKs, but that's the fundamental thing Swift does that no other language can do.

nicoburns 6y ago

The best thing about swift is it's ML-style type system (incidentally this is also one of the best things about Rust, and one of the reasons why Rust is competitive in "higher level" application development scenarios as well as "systems programming"). For me Sum Types and pattern matching in particular are an absolutely massive improvement over languages that only have classes/structs. They make statically typed languages feel almost as expressive as dynamic ones.

symlinkk 6y ago
TypeScript has this too
- IggleSniggle 6y ago
  Sort of. Although I will say that the upcoming TypeScript 4.1 with its string-template types potentially opens up TypeScript to limitless power. Imagine the expressiveness and power of tcl, but as your type system / type definitions. The weird thing about typescript is that this incredible power and expressively must be backported into the runtime environment. And because of that, the promises that the type system makes are unreliable and also lag way behind the actual language features that are implemented. I hope these criticisms are read in the proper context: I absolutely love TypeScript, and find it to be a really special unique oddball in the world of language design. I wish it had been ReasonML instead of TypeScript, but TypeScript is incrementally working it’s way there and bringing the whole js community with it, so I can’t complain. Edit: Prediction: prepare for switch statements to become popular as the typescript community gradually adopts exhaustive pattern-matching types.
  - symlinkk 6y ago
    What do you mean by “the promises that the type system makes are unreliable”?
    - jbboehr 6y ago
      The type of an underlying variable at runtime may be different than what the typescript type declares. Practically, this would probably be due to either poor, incorrect, out-of-sync, or incomplete type definitions. A poor example, but this compiles without error and crashes at runtime: let x: string = "foo"; (x as any) = 1; x.substr(0); Now, technically, you can do this sort of thing in most, if not all, languages, but this happens organically more often with typescript due to many libraries being written for plain javascript and being looser on their types, or type definitions getting out of sync with the libraries they are written for.

NobodyNada 6y ago

In my personal experience, Swift occupies the sweet spot in between Rust and something like Python for application-level programming. It's a modern and well-designed language with a Rust-like strong and expressive type system, including useful generics, powerful enums, and safe error handling. It also has fairly straightforward memory management, really straightforward polymorphism, seamless C interop, and good performance -- though it's not quite as fast as Rust because it prioritizes ease of use over zero-cost abstractions. So no, it doesn't really have a whole lot of "innovation or originality" -- but it essentially takes some of the best ideas of modern language design and wraps them into one general-purpose language for application development, and as a result I find it to be a really useful and practical language.

kitsunesoba 6y ago

In terms of syntax it's much closer to Kotlin than it is C# (though still different). It has seamless interop with Objective-C and C, and can be mixed with about any language LLVM/Clang can handle (as long as you have C headers), compiling it all down to a small, self-contained binary. For now it's mainly useful on Apple platforms, but there's interest and efforts in cross platform from both Apple and the Swift community, so there's a lot of potential for it to be a great language for the main body of application code, with individual bits of functionality written in languages that make the most sense without too many layers of adapters or wrappers.

nsonha 6y ago
I think the person meant in terms of identifiable trait/philosophy/focus. Swift and c# and maybe even kotlin are languages that are just a big piles of feature and does not really have an principle behind its design like stupid simple of golang or lazyness of haskel
- TylerE 6y ago
  at a time when every language is trying to be edgy/different, it'd be nice to have an actual language that is comfortable and boring without being dumb. Seems like a viable niche to me.
  - nsonha 6y ago
    this is not a boring language, it has a lot of complexity. I prefer simple but interesting language, f# comes to mind.
    - TylerE 6y ago
      Boring in the sense of not being, well, Rust, or a lisp, or an ML derivative or...
  - nsonha 6y ago
    The people that don't like edgy PL features normally also prefer a clean and simple language with orthogonal design not the big-pile-of-features kind of language though.

oconnor663 6y ago

Swift has done some very original things around ABI stability: https://gankra.github.io/blah/swift-abi/ https://gankra.github.io/blah/swift-abi/

Someone 6y ago

Firstly, wants wrong with being “the C# of Apple”? I think they wanted a language that can coexist with objective-C libraries, and is reasonably memory-efficient (adding RAM to phones decreases battery life) that they could control, and created it. They certainly didn’t just make run-of-the mill choices for all language features. Some non-standard design choices they made (for better or for worse): - Reference counting without any automated cycle-breaking - Collections are value types (implemented somewhat efficiently by having copy-on-write collections) - the Character type is closer to what ‘normal’ people think a character is (https://developer.apple.com/documentation/swift/character https://developer.apple.com/documentation/swift/character) - consequently, string length is closer to what users who don’t know Unicode internals expect it to be. - Arrays are ‘different’ (‘inherited’ from NSArray. See https://ridiculousfish.com/blog/posts/array.html https://ridiculousfish.com/blog/posts/array.html) - protocols are a bit like interfaces, but protocol conformance can retroactively be added to classes, even to ones you didn’t write or don’t have the source code of.

cmckn 6y ago
> the Character type is closer to what ‘normal’ people think a character is I'm sure I'm missing some nuanced downside to this, but this sounds fantastic. I've never fully understood the difference between Unicode code points and code units[0], and would love to think less about this sort of thing in Java (for ex. when using String#toCharArray). [0] I'm just regurgitating language from the String javadoc, this sentence might not even make sense.
- didibus 6y ago
  I could see issue if using it for splitting strings, but I guess it also depends what Swift assumes to be what normal people think a character is. Most normal people assume Unicode grapheme to be characters. That would be the set of symbols you'd consider a single letter if you were to visually count the number of symbols in the string. In Unicode though, some code points are non visible, yet are part of the string. So for example, the character at i+1 for some match against a letter might not be the next visible letter. I can see this causing issue either way. Honestly, I'd say it's best to just learn this, it you'll have some weird bugs one way or another. Basically, you have code units, those are the smallest chunk of bit that has meaning in Unicode and thus can be sent over a wire, streamed or decoded. In UTF-16 encoding, which is what JVM uses, code units are 16 bit. The history helps. In the beginning, each character in Unicode was 16bit. So you could represent all Unicode characters with 16bit only. Later, there were even more characters added, and it couldn't fit into 16bit. So UTF-16 where the 16 tells you the code units is 16 bit no longer could represent all characters in one 16 bit unit. Thus code points were invented, those are characters that span two code units 16bit + 16bit. Together they represent the new characters that didn't fit in the single 16bit range. So nowadays, it actually takes 21 bits to represent all Unicode characters. There's three encodings: UTF-8, UTF-16 and UTF-32. Their number correspond to the bit size of their code units. In UTF-8 we break each character into 8 bit units. In UTF-16 we do so in 16 bit units, and in UTF-32 into 32 bit units. Ok, now back to measuring length. We can say tell me the number of code units used to represent the string. That's what Java's string.length() does. Or we can say telle the number of bytes needed to represent the string (a byte is 8bit). That's what converting to byteArray and getting the length of the array does. Or you can say tell me the number of code points (Unicode characters) the string contains. In UTF-16 a code point can be 16bit (composed of one unit only), or it can be 32 bit (composed of two units). But not all Unicode characters are visible, so the user might be surprised to get a length that is greater than what it counts visually. So you can also get the number of grapheme in the string, which are "visual characters". In Java you can use BreakIterator to count those. That said, Unicode grapheme don't always make sense to what each speaker of each language would consider a character. That's for example some languages might consider a combo of two letters one character with one pronunciation, etc. Finally, I'll say there's another interesting length. It's the font width in terms of physical measures like pixel count. So basically, each measure might be most appropriate depending what your measuring for. I think the real issue is that we didn't adopt new terminology of Unicode yet. You should try to start referring to things as code units, code points, grapheme and font width/height. And stop using the word character or letter. And then just make yourself a little library that has string.codeUnitCount(), string.codePointCount(), string.graphemeCount() and string.pixelWidth(). And when you don't care about the difference between these, I'd argue that code unit count is the best default for length, which is why I don't actually disagree with string.length counting code units. Cause I think of string.length from the perspective of looping over the smallest units of the string.

solidsnack9000 6y ago

The really cool thing about Swift is it's lack of innovation or originality. It is ALGOL 2014. It tries to integrate a few more patterns into the structured programming paradigm.