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.
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.
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).
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?
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.
Speaking descriptively, not normatively, it just seems the industry is moving towards easier, not safer. yes, including PHP, but also python and ruby.
I think the trade-off is that safer requires more upfront design, and is more viscous (harder to change). Whereas industry seems to get better end-results, with less design and faster iteration (i.e. so-called extreme programming). What's the point goes the argument of getting the wrong thing perfectly correct?. Added to this is the relative unpopularity of safer languages like SML etc.
Statically typed languages (Java etc) are mainly popular more because of performance, not safety.
So... I predict easier will continue to beat safer... in terms of popularity.
> Statically typed languages (Java etc) are mainly popular more because of performance, not safety.
No. The whole reason to have types is for safety, type safety. Where more errors/bugs can be found and found a whole lot earlier. That's the basis of the argument of dynamic vs statically-typed languages. If performance was all that matters, we'd all be writing C and C++.
> 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've been working in Go for the last three months and I've come to see most of these as false. Concurrency and improved performance are arguable, but simplicity of use and ease coming from a dynamic background have not been my experience. I feel like I'm writing in Pascal again. Code that would be trivial for me to parameterize and isolate into a function in a dynamic language (or heck, in Java) becomes an exercise in frustration, usually ending in copy-paste. The official stance of the language appears to be PRY (Please Repeat Yourself) rather than DRY, boilerplate is on the order of writing Java.
And as far as performance/concurrency go, it's not particularly competitive with other languages that've made focused efforts on either/both.
I'll say that I've found the built-in package management nice (cross my fingers, haven't hit any of the rumored version conflict issues yet), but I can't think of much else nice to say.
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)
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...
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.”
Well, it's worth pointing out that Scala pre-dates most of the new comers you mention by several years.
Kotlin, for example, their raison d'etre seems to be, "we're Scala without the complexity"[1].
As for the syntatic similarities between Swift and Scala, well, they're not identical (and the whole `var` bit on the Scala side should be chucked out as that is far from idiomatic Scala). At most you can say that Swift is more similar to Scala than any other language, which is to say the language designers probably saw some nice-to-haves in Scala and acted accordingly.
For me Swift seems like a kind of hybrid ML Coffeescript a la Scala with a Swist ;-)
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.
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.
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.
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?
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.
Swift enums and Scala case classes both attempt to emulate ML/Haskell Algebraic Data Types. In the design goal there they both are identical.
Swift's enums are a more faithful translation than Scala's case classes (since case classes are more ambitiously/granularly typed, and this leads to some weakness [0]). Right now they're a little broken, though, since recursive enums lead to compiler bugs (here's are a few of my attempts to fight this: [1], [2]).
Not sure what weakness you're referring to in that SO post; the OP is actually saying otherwise:
> I have always considered the Scala variation to be on the advantageous side [relative to Haskell].
Daniel Spiewak does provide an answer that points out a weakness with scala collections when used with ADTs, but (G)ADTs of and in themselves are pretty damn elegant in Scala, arguably rivaling Haskell equivalent (provided we set aside Scala's slightly more verbose implementation).
Daniel's answer is not specific to Scala's collections library but instead any generic type unless it's set to be invariant. That ultimately leads to a tradeoff between soundness and convenience (as mentioned in comment toward Scalaz's Monad impl).
Ultimately, both of his points come from the idea that you genuinely want a mechanism for deferring information to runtime and case classes almost give that to you if it weren't for their default to greater typing granularity and covering it up with subtyping relations.
The point I made in the comments is that this throws away syntax directness almost everywhere and that tosses out a lot of inference.
Ultimately, Haskell's GADTs give you the same power as Scala's case classes, but they require you to actually ask for that level of type specificity and then provide an explicit and delimited family so that inference doesn't get as mucked up.
So, I think Scala is certainly workable... but in general disallows precision of desired expression, ironically, by defaulting to greater precision of actual "type".
(There's finally a totally pedantic argument to be had that "Inl and Inr aren't types" in some foundational sense. Of course you can consider them types and model a perfectly reasonable type system off of that consideration. That said, they're something a little different from your standard MLTT/BiCCC/TypeTheory/Logic types, fwtw)
Thanks, Scala collections in particular are unfortunately capable of wreaking havoc (Paul Phillips' infamous List(1,2,3).contains("your mom")) in surprising ways.
I'm not saying that Scala's approach to G(ADT)s is flawless (by any means), but it is powerful, and to cast a strength as a weakness is a bit disengenious, particularly when the SO user is in fact saying, what's the deal, Scala is superior to Haskell in this area.
Then again, Scala's terribly unpopular in the Haskell community and here on HN, so casting the language in a bad light is of no surprise.
FWIW, I really enjoyed that Twitter Bird pic tweeting out Haskell's logo in this language usage breakdown[1]. Heh, the language that everybody is talking about...and nobody is using O_o
Saying that, Haskell by all indications seems poised to take off, so I may be eating my words in future. We shall see, next 3 to 5 years on and off the JVM are going to be interesting times indeed ;-)
I truly disagree that Scala is superior. I think it's different and made an interesting encoding of ADTs. I also don't think Daniel was suggesting anything otherwise, though the op was.
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.
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).
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).
> 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.
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.
53 comments
[ 132 ms ] story [ 2118 ms ] threadDoes that then imply that Go is a dialect of Scala?
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.
:-)
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).
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?
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.
I think the trade-off is that safer requires more upfront design, and is more viscous (harder to change). Whereas industry seems to get better end-results, with less design and faster iteration (i.e. so-called extreme programming). What's the point goes the argument of getting the wrong thing perfectly correct?. Added to this is the relative unpopularity of safer languages like SML etc.
Statically typed languages (Java etc) are mainly popular more because of performance, not safety.
So... I predict easier will continue to beat safer... in terms of popularity.
No. The whole reason to have types is for safety, type safety. Where more errors/bugs can be found and found a whole lot earlier. That's the basis of the argument of dynamic vs statically-typed languages. If performance was all that matters, we'd all be writing C and C++.
I've been working in Go for the last three months and I've come to see most of these as false. Concurrency and improved performance are arguable, but simplicity of use and ease coming from a dynamic background have not been my experience. I feel like I'm writing in Pascal again. Code that would be trivial for me to parameterize and isolate into a function in a dynamic language (or heck, in Java) becomes an exercise in frustration, usually ending in copy-paste. The official stance of the language appears to be PRY (Please Repeat Yourself) rather than DRY, boilerplate is on the order of writing Java.
And as far as performance/concurrency go, it's not particularly competitive with other languages that've made focused efforts on either/both.
I'll say that I've found the built-in package management nice (cross my fingers, haven't hit any of the rumored version conflict issues yet), but I can't think of much else nice to say.
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)
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.”
Kotlin, for example, their raison d'etre seems to be, "we're Scala without the complexity"[1].
As for the syntatic similarities between Swift and Scala, well, they're not identical (and the whole `var` bit on the Scala side should be chucked out as that is far from idiomatic Scala). At most you can say that Swift is more similar to Scala than any other language, which is to say the language designers probably saw some nice-to-haves in Scala and acted accordingly.
For me Swift seems like a kind of hybrid ML Coffeescript a la Scala with a Swist ;-)
[1] http://confluence.jetbrains.com/display/Kotlin/Comparison+to...
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.
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'.
I mean, I use Scala every day, but C# gives you so much solely on reification and Scala manifests are a real poor patch.
"Miles away" is ambiguous, but I think it's "miles behind" in this context, given its proximity to "even" and "let alone."
Swift's enums are a more faithful translation than Scala's case classes (since case classes are more ambitiously/granularly typed, and this leads to some weakness [0]). Right now they're a little broken, though, since recursive enums lead to compiler bugs (here's are a few of my attempts to fight this: [1], [2]).
[0] http://stackoverflow.com/questions/25330359/what-are-the-pro...
[1] http://tel.github.io/2014/07/30/immutable_enumeration_in_swi...
[2] http://tel.github.io/2014/07/27/calkin-wilf-in-swift/
> I have always considered the Scala variation to be on the advantageous side [relative to Haskell].
Daniel Spiewak does provide an answer that points out a weakness with scala collections when used with ADTs, but (G)ADTs of and in themselves are pretty damn elegant in Scala, arguably rivaling Haskell equivalent (provided we set aside Scala's slightly more verbose implementation).
Ultimately, both of his points come from the idea that you genuinely want a mechanism for deferring information to runtime and case classes almost give that to you if it weren't for their default to greater typing granularity and covering it up with subtyping relations.
The point I made in the comments is that this throws away syntax directness almost everywhere and that tosses out a lot of inference.
Ultimately, Haskell's GADTs give you the same power as Scala's case classes, but they require you to actually ask for that level of type specificity and then provide an explicit and delimited family so that inference doesn't get as mucked up.
So, I think Scala is certainly workable... but in general disallows precision of desired expression, ironically, by defaulting to greater precision of actual "type".
(There's finally a totally pedantic argument to be had that "Inl and Inr aren't types" in some foundational sense. Of course you can consider them types and model a perfectly reasonable type system off of that consideration. That said, they're something a little different from your standard MLTT/BiCCC/TypeTheory/Logic types, fwtw)
I'm not saying that Scala's approach to G(ADT)s is flawless (by any means), but it is powerful, and to cast a strength as a weakness is a bit disengenious, particularly when the SO user is in fact saying, what's the deal, Scala is superior to Haskell in this area.
Then again, Scala's terribly unpopular in the Haskell community and here on HN, so casting the language in a bad light is of no surprise.
FWIW, I really enjoyed that Twitter Bird pic tweeting out Haskell's logo in this language usage breakdown[1]. Heh, the language that everybody is talking about...and nobody is using O_o
Saying that, Haskell by all indications seems poised to take off, so I may be eating my words in future. We shall see, next 3 to 5 years on and off the JVM are going to be interesting times indeed ;-)
https://github.com/Dobiasd/programming-language-subreddits-a...
* 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)
let emptyArray = String[]()
That's actually old, and no longer valid. The current syntax is
let emptyArray = [String]()
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).
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).
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.
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.