6 ms·

Swift is a lot like Scala

62 points by javinpaul 12y ago

ghshephard 12y ago
It's interesting, given that Joel Spolsky says of Swift "It feels exactly like go", and this person is saying, "Swift is a dialect of Scala". Does that then imply that Go is a dialect of Scala?
- deleted 12y ago
  [deleted]
- wben 12y ago
  Sadly Go chose to use Garbage Collection instead of Reference Counting. I love using Python or Swift for applications that allocate (and free) real hardware resources, like OpenGL texture maps, frame buffer objects and in memory images.
  - pjmlp 12y ago
    Because they care about performance in multi-core contexts.
    - danieldk 12y ago
      Reference counting and multi-core performance are not mutually exclusive at all. In a lot of applications where you exploit parallelism, you parallelise loops (e.g. via OpenMP), usually objects go out of scope outside the parallelized loop (single threaded code), so you can use a bare pointer. In the loop you do mostly stack allocations. Of course, there are degenerate cases where there's a lot of lock contention on the reference count. However, there are degenerate cases in most garbage collectors for multi-core as well. Isn't Go still using a stop-the-world GC? Edit: I wanted to add that I am not against garbage collectors. You lose deterministic destructors, but a well-developed garbage collector like the JVM's is very performant in most situations, and in many cases indeed more performant than reference counting.
      - bjourne 12y ago
        Then what languages or virtual machines uses reference counting and is performant in a muti-core context? :-)
      - pjmlp 12y ago
        You can have deterministic destruction in GC enabled languages.
- danieldk 12y ago
  And they all feel like dialects of OCaml ;). (I am not saying 'Haskell' here, because it does not include object oriented programming.) The thing is that the current generation of languages have so many overlapping features, that they are not all that different language-wise. Just like moving between Pascal, Ada, and Modula-2 was not that hard. Also, I'd say that Go is the exception here, because in contrast to Go, Swift manages to adopt insights from the last 30 of 40 years of PL research. Go is an utterly boring language and has very little to do with Scala (or Swift).
  - themartorana 12y ago
    Aw, but what about utterly fast to develop in, utterly awesome at concurrency, utterly easy for ruby/python/dynamic-language devs to pick up and gain huge performance boosts, utterly easy to get in to the ecosystem, and utterly simple to use? I'm not a language geek mind you, but if people find it useful (and plenty of large and small companies have had huge wins with it at rapid pace) who cares if it's utterly boring?
    - danieldk 12y ago
      Aw, but what about utterly fast to develop in, utterly awesome at concurrency, utterly easy for ruby/python/dynamic-language devs to pick up and gain huge performance boosts, utterly easy to get in to the ecosystem, and utterly simple to use? Most of those characteristics are also true for PHP, which is arguably also easier to deploy, since nearly every virtual hosting provider has mod_php enabled and it is 'platform-independent'. Sure, it gets the job done. However, a lot of PL research has gone into making languages safer. Allowing you to make bugs that manifest at runtime, compile time errors. And while large bugs may not be that big a deal for the average web application, not everyone writes web applications. Billions are wasted on software bugs, from research that turns out to be invalid due to multiplication of units of measurement that cannot be multiplied, to Bitcoins that are lost due to programming errors, to deaths caused by errors in life-critical software. Go does almost nothing to solve the one of the largest challenges of software, namely to make it safer. Sure, it's more safe than C. But arguable it's even a step back from Java by its refusal to include some form of parametric polymorphism, requiring developers to revert to runtime introspection instead.
- mseepgood 12y ago
  Joel Spolsky's comment was not very well-informed.
gamesbrainiac 12y ago
I've heard a lot of people say that swift totally ripped off Kotlin, a new language that Jetbrains is working on.
skrebbel 12y ago
Any language designer that has both "modern, powerful features" and "familiar for current developers" as design goals, will end up with something not unlike other languages that have this. It is not a coincidence that Scala, modern C#, Kotlin, Xtend, Nemerle, Ceylon, Dart and Swift have a lot in common. They're all compiled languages with pretty high performance characteristics. They have support for OO stuff because of the "familiarity" goal (and, often, to interface with existing code) plus functional stuff because of the "powerful" goal. In a way, they're all Java with suck removed and cool stuff bolted on top. So can we please stop the "ripoff!" arguments and look at what you can do with it? (note, i'm referring to HN comments on threads about Swift more than to the article) C# 1 was a blatant ripoff of Java 1.2 (or something like that), with hardly anything new added, and only the biggest suck removed. Look at where C# is now. If Apple can push Swift the same way, there are good times ahead! (assuming it gets good non-Apple support, but that's another rant)
- Aqueous 12y ago
  I don't think anyone's saying Swift is a rip-off (or anyone that I know). If anything it compliments both Swift and Scala that the two are so alike.
- TazeTSchnitzel 12y ago
  I don't think anyone's complaining about the similarity. :)
- seunosewa 12y ago
  The development of C# 1 was led by the chief architect of Delphi. It probably got more features from the previous language its creator designed than from Java...
- noblethrasher 12y ago
  C# 1.0 (the spec) and especially Visual C# 1.0 (the IDE) were recapitulations of Delphi in Java skin. Now, C# is by far my favorite language (even though I think in ML), but I'm now a bit envious of the Java approach: One of the big ideas of OOP going back to Alan Kay is that OO languages should be extremely dynamic, and that you achieve performance by building better hardware (or tuning it)†. This is what Java and Objective-C do. And, this is why Java programmers can create classes and objects with reckless abandon and still get excellent performance. Meanwhile, in C#, I find myself worrying about whether something should be a class or a struct; it doesn't happen often, and I know that I ought not be thinking about it, but it's there. So, in summary, I now appreciate the value of putting the performance knobs on the machine rather than in the language, which represent the two different philosophies of Java and C#. †Said by Alan Kay, and repeated by Steve Jobs: “People who are really serious about software should make their own hardware.”
deleted 12y ago
[deleted]
resca79 12y ago
Basically both represent the new concept of how a new language should be today. Many similarity there are, but "it's fair to say that Swift is a dialect of Scala" it not true. Also, the word "dialect" should be mean a sublanguage much expressive, but in many of your examples Swift seems much "verbose" than Scala.
rtpg 12y ago
Kinda frustrating that the language comparaison is by syntax instead of features ( http://www.scribd.com/doc/227879724/Swift-vs-Scala-2-11 http://www.scribd.com/doc/227879724/Swift-vs-Scala-2-11 is what's referenced in the article). I'm fairly convinced that Swift enums and Scala case classes are only superficially the same, and based off the discussions I've heard about generics in Swift, Swift is miles aways from even C++-levels of generics, let alone Scala's. Unless someone shows me otherwise, I'm convinced that Scala and Swift only have superficial similarities.
- benvan 12y ago
  I agree - the examples given are almost infuriating. Whilst I can't comment on how idiomatic the Swift code is, the Scala code is anything but. There's little benefit to using a language like Scala if you're going to count the number of apples and oranges in a list by incrementing a mutable var for each type.
  - efnx 12y ago
    My problem with both languages is that you can count apples like that. If it can be done, it will be done.
- densh 12y ago
  Author of those slides here. They were made on the next day after the language was presented on WWDC and were based purely on the first draft of the Swift book published online by Apple. Needless to say the book was more of a tutorial than a full-blown spec at that time and many important aspects were not covered (generics were lightly documented without much details). Can you please provide details about generics in Swift and how exactly are they different from Scala's? Edit: changed 'superior' to 'different'.
  - eklavya 12y ago
    Don't bother, people will just say X is better than Scala here. They don't know the amount of research done by Odersky on generics and why Scala can not be easily beaten in this area at least.
kawa 12y ago
All those languages look like a combination of Java and ML to me. Of course they use different features and small additions here and there but overall: ML+Java.
StronglyTyped 12y ago
The difference is the rounded edges, you see.
riffraff 12y ago
The article appears to say: they both have * first class functions * single inheritance with traits/protocols * extension methods * distinction between variables and constants * a few builtin data structures (tuples, arrays, maps etc) By this, most "recent" PLs look like Scala. The omitted differences are where most actually disappear (i.e. handling of variance/generics)
seivan 12y ago
I noticed the author wrote let emptyArray = String[]() That's actually old, and no longer valid. The current syntax is let emptyArray = [String]()
xh208 12y ago
I know it's off-topic but I every time I heard 'Swift' I feel sorry for 'the other Swift' i.e. http://en.wikipedia.org/wiki/Swift_(parallel_scripting_language) http://en.wikipedia.org/wiki/Swift_(parallel_scripting_langu...
- twsted 12y ago
  Apple put this phrase on their Swift page https://developer.apple.com/swift/ https://developer.apple.com/swift/ "Looking for the Swift parallel scripting language? Please visit http://swift-lang.org" http://swift-lang.org"
zak_mc_kracken 12y ago
There are similarities, of course, as you could expect from any modern language (i.e. created in the 21st century) but if there is something noteworthy about all the recent languages that came out these past years (Kotlin, Ceylon, Swift, Fantom, Gosu), it's not how much they look like Scala but all the features from Scala that they left out. The Scala experiment produced a lot of interesting results and added a lot of clarity about what features are interesting in a modern language (property, lambda, extension methods, sum/union types, and a few others) but the complexity of Scala's type system and the uncertain shape of its code base (see Paul Phillips' talks) is demonstrating that it's often wise to support fewer features rather than be a kitchen-and-sink language. I am very excited by this trend of minimalism in languages and the willingness from language designers to say "Interesting feature but it will add too much complexity, so I'm not adding it". Best of luck to Swift, and I can't wait to see if a language will finally emerge on the JVM to supplant Java (even though this might take a solid decade).
- virtualwhys 12y ago
  The Scala experiment, as you say, seems to be kicking some serious tail, no need to speak of it in the past tense ;-) Big companies are adopting Scala (Twitter, LinkedIn, eBay, Yahoo, Sony, and so on), not surprising given Spark, Spire, Akka, Play, etc. The Scala language itself is certainly not without problems; at this point the ecosystem behind it is arguably its greatest strength. Rest assured, if there is a language that will supplant Java on the JVM (highly unlikely in the near-term), it will be Scala (or some variant [Dotty] thereof). Ceylon's got a shot but they're a bit late to the party, and Kotlin isn't even 1.0 yet (Java 8 and 9 will punish that project's adoption, IMO).
  - zak_mc_kracken 12y ago
    > Rest assured, if there is a language that will supplant Java on the JVM (highly unlikely in the near-term), it will be Scala Not sure why you're so confident since Scala has gained about 2% mind share in ten years of existence and it's still all but impossible to find Scala jobs, but hey, if you like it, good for you.
tel 12y ago
In my experiences playing with Swift it has roughly two design goals—make a modern feeling ObjC and jam it into ML/Haskell ADTs. Almost every moment of using the language feels like a tug-of-war between those two sides. I'm personally hugely excited about this in the same way I was hugely excited about this feeling in Scala. I don't think FP and OO ought to stay on their own side of the fence—I think they're mutually useful. But I think the OO in Swift goes way too far in order to have ObjC compatibility (perhaps). I think that perhaps the biggest challenge that Swift falls the furthest on is managing combining immutable and mutable code. `let` and `var` are very thin veneers and it's easy to have things "change underneath you" even while writing a lot of let-like code. I think this is mainly driven by the highly mutability-dependent ObjC bindings Swift must support in order to be useful to Apple. I also think it's a bit tragic. My hope is that this being the early days for Swift its influence will drive more immutability through these APIs as they evolve.
CCs 12y ago
82 days ago: https://news.ycombinator.com/item?id=7837108 https://news.ycombinator.com/item?id=7837108

62 points by javinpaul 12y ago

It's interesting, given that Joel Spolsky says of Swift "It feels exactly like go", and this person is saying, "Swift is a dialect of Scala". Does that then imply that Go is a dialect of Scala?

deleted 12y ago
[deleted]
wben 12y ago
Sadly Go chose to use Garbage Collection instead of Reference Counting. I love using Python or Swift for applications that allocate (and free) real hardware resources, like OpenGL texture maps, frame buffer objects and in memory images.
- pjmlp 12y ago
  Because they care about performance in multi-core contexts.
  - danieldk 12y ago
    Reference counting and multi-core performance are not mutually exclusive at all. In a lot of applications where you exploit parallelism, you parallelise loops (e.g. via OpenMP), usually objects go out of scope outside the parallelized loop (single threaded code), so you can use a bare pointer. In the loop you do mostly stack allocations. Of course, there are degenerate cases where there's a lot of lock contention on the reference count. However, there are degenerate cases in most garbage collectors for multi-core as well. Isn't Go still using a stop-the-world GC? Edit: I wanted to add that I am not against garbage collectors. You lose deterministic destructors, but a well-developed garbage collector like the JVM's is very performant in most situations, and in many cases indeed more performant than reference counting.
    - bjourne 12y ago
      Then what languages or virtual machines uses reference counting and is performant in a muti-core context? :-)
    - pjmlp 12y ago
      You can have deterministic destruction in GC enabled languages.
danieldk 12y ago
And they all feel like dialects of OCaml ;). (I am not saying 'Haskell' here, because it does not include object oriented programming.) The thing is that the current generation of languages have so many overlapping features, that they are not all that different language-wise. Just like moving between Pascal, Ada, and Modula-2 was not that hard. Also, I'd say that Go is the exception here, because in contrast to Go, Swift manages to adopt insights from the last 30 of 40 years of PL research. Go is an utterly boring language and has very little to do with Scala (or Swift).
- themartorana 12y ago
  Aw, but what about utterly fast to develop in, utterly awesome at concurrency, utterly easy for ruby/python/dynamic-language devs to pick up and gain huge performance boosts, utterly easy to get in to the ecosystem, and utterly simple to use? I'm not a language geek mind you, but if people find it useful (and plenty of large and small companies have had huge wins with it at rapid pace) who cares if it's utterly boring?
  - danieldk 12y ago
    Aw, but what about utterly fast to develop in, utterly awesome at concurrency, utterly easy for ruby/python/dynamic-language devs to pick up and gain huge performance boosts, utterly easy to get in to the ecosystem, and utterly simple to use? Most of those characteristics are also true for PHP, which is arguably also easier to deploy, since nearly every virtual hosting provider has mod_php enabled and it is 'platform-independent'. Sure, it gets the job done. However, a lot of PL research has gone into making languages safer. Allowing you to make bugs that manifest at runtime, compile time errors. And while large bugs may not be that big a deal for the average web application, not everyone writes web applications. Billions are wasted on software bugs, from research that turns out to be invalid due to multiplication of units of measurement that cannot be multiplied, to Bitcoins that are lost due to programming errors, to deaths caused by errors in life-critical software. Go does almost nothing to solve the one of the largest challenges of software, namely to make it safer. Sure, it's more safe than C. But arguable it's even a step back from Java by its refusal to include some form of parametric polymorphism, requiring developers to revert to runtime introspection instead.
mseepgood 12y ago
Joel Spolsky's comment was not very well-informed.

gamesbrainiac 12y ago

I've heard a lot of people say that swift totally ripped off Kotlin, a new language that Jetbrains is working on.

skrebbel 12y ago

Any language designer that has both "modern, powerful features" and "familiar for current developers" as design goals, will end up with something not unlike other languages that have this. It is not a coincidence that Scala, modern C#, Kotlin, Xtend, Nemerle, Ceylon, Dart and Swift have a lot in common. They're all compiled languages with pretty high performance characteristics. They have support for OO stuff because of the "familiarity" goal (and, often, to interface with existing code) plus functional stuff because of the "powerful" goal. In a way, they're all Java with suck removed and cool stuff bolted on top. So can we please stop the "ripoff!" arguments and look at what you can do with it? (note, i'm referring to HN comments on threads about Swift more than to the article) C# 1 was a blatant ripoff of Java 1.2 (or something like that), with hardly anything new added, and only the biggest suck removed. Look at where C# is now. If Apple can push Swift the same way, there are good times ahead! (assuming it gets good non-Apple support, but that's another rant)

Aqueous 12y ago
I don't think anyone's saying Swift is a rip-off (or anyone that I know). If anything it compliments both Swift and Scala that the two are so alike.
TazeTSchnitzel 12y ago
I don't think anyone's complaining about the similarity. :)
seunosewa 12y ago
The development of C# 1 was led by the chief architect of Delphi. It probably got more features from the previous language its creator designed than from Java...
noblethrasher 12y ago
C# 1.0 (the spec) and especially Visual C# 1.0 (the IDE) were recapitulations of Delphi in Java skin. Now, C# is by far my favorite language (even though I think in ML), but I'm now a bit envious of the Java approach: One of the big ideas of OOP going back to Alan Kay is that OO languages should be extremely dynamic, and that you achieve performance by building better hardware (or tuning it)†. This is what Java and Objective-C do. And, this is why Java programmers can create classes and objects with reckless abandon and still get excellent performance. Meanwhile, in C#, I find myself worrying about whether something should be a class or a struct; it doesn't happen often, and I know that I ought not be thinking about it, but it's there. So, in summary, I now appreciate the value of putting the performance knobs on the machine rather than in the language, which represent the two different philosophies of Java and C#. †Said by Alan Kay, and repeated by Steve Jobs: “People who are really serious about software should make their own hardware.”

deleted 12y ago

[deleted]

resca79 12y ago

Basically both represent the new concept of how a new language should be today. Many similarity there are, but "it's fair to say that Swift is a dialect of Scala" it not true. Also, the word "dialect" should be mean a sublanguage much expressive, but in many of your examples Swift seems much "verbose" than Scala.

rtpg 12y ago

Kinda frustrating that the language comparaison is by syntax instead of features ( http://www.scribd.com/doc/227879724/Swift-vs-Scala-2-11 http://www.scribd.com/doc/227879724/Swift-vs-Scala-2-11 is what's referenced in the article). I'm fairly convinced that Swift enums and Scala case classes are only superficially the same, and based off the discussions I've heard about generics in Swift, Swift is miles aways from even C++-levels of generics, let alone Scala's. Unless someone shows me otherwise, I'm convinced that Scala and Swift only have superficial similarities.

benvan 12y ago
I agree - the examples given are almost infuriating. Whilst I can't comment on how idiomatic the Swift code is, the Scala code is anything but. There's little benefit to using a language like Scala if you're going to count the number of apples and oranges in a list by incrementing a mutable var for each type.
- efnx 12y ago
  My problem with both languages is that you can count apples like that. If it can be done, it will be done.
densh 12y ago
Author of those slides here. They were made on the next day after the language was presented on WWDC and were based purely on the first draft of the Swift book published online by Apple. Needless to say the book was more of a tutorial than a full-blown spec at that time and many important aspects were not covered (generics were lightly documented without much details). Can you please provide details about generics in Swift and how exactly are they different from Scala's? Edit: changed 'superior' to 'different'.
- eklavya 12y ago
  Don't bother, people will just say X is better than Scala here. They don't know the amount of research done by Odersky on generics and why Scala can not be easily beaten in this area at least.

kawa 12y ago

All those languages look like a combination of Java and ML to me. Of course they use different features and small additions here and there but overall: ML+Java.

StronglyTyped 12y ago

The difference is the rounded edges, you see.

riffraff 12y ago

The article appears to say: they both have * first class functions * single inheritance with traits/protocols * extension methods * distinction between variables and constants * a few builtin data structures (tuples, arrays, maps etc) By this, most "recent" PLs look like Scala. The omitted differences are where most actually disappear (i.e. handling of variance/generics)

seivan 12y ago

I noticed the author wrote let emptyArray = String[]() That's actually old, and no longer valid. The current syntax is let emptyArray = [String]()

xh208 12y ago

I know it's off-topic but I every time I heard 'Swift' I feel sorry for 'the other Swift' i.e. http://en.wikipedia.org/wiki/Swift_(parallel_scripting_language) http://en.wikipedia.org/wiki/Swift_(parallel_scripting_langu...

twsted 12y ago
Apple put this phrase on their Swift page https://developer.apple.com/swift/ https://developer.apple.com/swift/ "Looking for the Swift parallel scripting language? Please visit http://swift-lang.org" http://swift-lang.org"

zak_mc_kracken 12y ago

There are similarities, of course, as you could expect from any modern language (i.e. created in the 21st century) but if there is something noteworthy about all the recent languages that came out these past years (Kotlin, Ceylon, Swift, Fantom, Gosu), it's not how much they look like Scala but all the features from Scala that they left out. The Scala experiment produced a lot of interesting results and added a lot of clarity about what features are interesting in a modern language (property, lambda, extension methods, sum/union types, and a few others) but the complexity of Scala's type system and the uncertain shape of its code base (see Paul Phillips' talks) is demonstrating that it's often wise to support fewer features rather than be a kitchen-and-sink language. I am very excited by this trend of minimalism in languages and the willingness from language designers to say "Interesting feature but it will add too much complexity, so I'm not adding it". Best of luck to Swift, and I can't wait to see if a language will finally emerge on the JVM to supplant Java (even though this might take a solid decade).

virtualwhys 12y ago
The Scala experiment, as you say, seems to be kicking some serious tail, no need to speak of it in the past tense ;-) Big companies are adopting Scala (Twitter, LinkedIn, eBay, Yahoo, Sony, and so on), not surprising given Spark, Spire, Akka, Play, etc. The Scala language itself is certainly not without problems; at this point the ecosystem behind it is arguably its greatest strength. Rest assured, if there is a language that will supplant Java on the JVM (highly unlikely in the near-term), it will be Scala (or some variant [Dotty] thereof). Ceylon's got a shot but they're a bit late to the party, and Kotlin isn't even 1.0 yet (Java 8 and 9 will punish that project's adoption, IMO).
- zak_mc_kracken 12y ago
  > Rest assured, if there is a language that will supplant Java on the JVM (highly unlikely in the near-term), it will be Scala Not sure why you're so confident since Scala has gained about 2% mind share in ten years of existence and it's still all but impossible to find Scala jobs, but hey, if you like it, good for you.

tel 12y ago

In my experiences playing with Swift it has roughly two design goals—make a modern feeling ObjC and jam it into ML/Haskell ADTs. Almost every moment of using the language feels like a tug-of-war between those two sides. I'm personally hugely excited about this in the same way I was hugely excited about this feeling in Scala. I don't think FP and OO ought to stay on their own side of the fence—I think they're mutually useful. But I think the OO in Swift goes way too far in order to have ObjC compatibility (perhaps). I think that perhaps the biggest challenge that Swift falls the furthest on is managing combining immutable and mutable code. `let` and `var` are very thin veneers and it's easy to have things "change underneath you" even while writing a lot of let-like code. I think this is mainly driven by the highly mutability-dependent ObjC bindings Swift must support in order to be useful to Apple. I also think it's a bit tragic. My hope is that this being the early days for Swift its influence will drive more immutability through these APIs as they evolve.

CCs 12y ago

82 days ago: https://news.ycombinator.com/item?id=7837108 https://news.ycombinator.com/item?id=7837108