Timeline for What are the biggest differences between F# and Scala?
Current License: CC BY-SA 3.0
43 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 10, 2013 at 5:43 | comment | added | missingfaktor | It's likely that you find my tone biased because you have decided to find a bias in it. :) The way I see it, what I have written here is a fairly objective comparison. | |
| Feb 10, 2013 at 5:42 | comment | added | missingfaktor | @Adam Gent, Scala has a compiler plugin for continuations, which was not created for actors. In fact I am not even sure actors implementation (except akka.dataflow) makes use of that. If you still feel Scala compiler does some special things for actors, feel free to post a question at Scala mailing list. :) | |
| Feb 10, 2013 at 0:23 | comment | added | Adam Gent | Also Futures are not closer... Promises are closer to async workflows. See stackoverflow.com/questions/5579602/… and docs.scala-lang.org/sips/pending/futures-promises.html . If Scala doesn't generate continuations aka green thread aka coroutines aka lwp .... I feel even less inclined to use it. I still think your tone is biased. | |
| Feb 10, 2013 at 0:14 | comment | added | Adam Gent | Hmm maybe your right I could have sworn that Scala generated Kilim like bytecode but maybe they haven't implemented that yet. | |
| Feb 10, 2013 at 0:08 | comment | added | Adam Gent | You might want to read up more on Scala's implementation of Actors :) If it was just a library you could just emulate it in Java but there is special byte code generation going on. The compiler most certainly does special things for Actors. They provide green threads and continuation like behavior that is not possible in Java. I'm almost certain its not just a tack on library but I can't find a reference so... maybe I'm wrong. | |
| Feb 9, 2013 at 13:30 | comment | added | missingfaktor | About actor model, it is not built into Scala the language. It's purely a library. You might want to read up more on that. Scala also has futures in its library, a concept that's closer to async workflows than actors are. | |
| Feb 9, 2013 at 13:28 | comment | added | missingfaktor | Haskell is certainly much more minimal than Scala, no doubt there. | |
| Feb 9, 2013 at 13:11 | comment | added | Adam Gent | I guess its the semantics of the word minimalism. Haskell is thus more minimal than Scala. The FP-OOP mariage I think is by definition much more complicated than say pure FP. F# has OOP mainly for compatibility with .NET. Scala embraces it. Scala's actor model is IMHO more complicated than F# async workflows. The syntax of the language by your definition maybe more "minimal" but the languages as a whole can't be compared like that. | |
| Feb 8, 2013 at 8:51 | comment | added | missingfaktor | @AdamGent, I believe minimalism is one of the key aspects of Scala's design. An example: F# has distinct concepts of classes and discriminated unions. Scala's object model handles both seamlessly together. You can find many more examples like these. | |
| Feb 7, 2013 at 16:33 | comment | added | Adam Gent | I feel like this whole answer is a little biased towards Scala. For example Scala is much more minimalistic language than F# which seems to go against his argument/later point of a more complex type system. | |
| Feb 21, 2012 at 5:23 | comment | added | henginy | As a note to the curious reader, there are 63 used keywords in F#. 97 is the sum of keyword count (63) and reserved token count (34). | |
| Jan 14, 2012 at 21:08 | comment | added | missingfaktor | @JonHarrop: Works just fine. paste.pocoo.org/show/534866 | |
| Jan 14, 2012 at 20:19 | comment | added | J D |
@missingfaktor: Does List.range(0,1000000).hashCode() work?
|
|
| Jan 14, 2012 at 20:05 | comment | added | J D |
@missingfaktor: "we haven't been hit by lack of TCO this far". That's very interesting. I've seen people bitten by TCO quite often using F# even though it has far better support for it than Scala does. In particular, nested calls to Seq.append can stack overflow upon enumeration and some calls like [1..1000000].GetHashCode() crash the whole .NET application immediately.
|
|
| Jan 14, 2012 at 16:23 | comment | added | Ingo | Looks like a good opportunity for Jon Harrop to once more tell the TCO myth. | |
| Jan 14, 2012 at 14:57 | history | edited | missingfaktor | CC BY-SA 3.0 |
added 14 characters in body
|
| Jan 14, 2012 at 14:56 | comment | added | missingfaktor | @JonHarrop: Regarding syntax, thanks for the info. I will update the answer. | |
| Jan 14, 2012 at 14:56 | comment | added | missingfaktor | @JonHarrop: When you need to extend the collection classes with new functions, you can most of the time leverage existing higher order functions. Very rarely, if ever, you may have to write a function from scratch. In such cases, if Scala's limited support for TCO (yes, it has some!) fails to work for you, go for the loops. Since the mutability in this case is local, the function is still pure, and you lose nothing. | |
| Jan 14, 2012 at 14:54 | comment | added | missingfaktor | @JonHarrop: We use Scala at production. And the code is purely functional. Not a single variable, and yet we haven't been hit by lack of TCO this far. Scala standard library has far larger number of higher order functions than F# does. See for example: scala.collection.immutable.List. These functions cover most use cases. They are internally implemented with loops, but that doesn't bother us. (contd...) | |
| Jan 14, 2012 at 14:02 | comment | added | J D | @missingfaktor: "I don't see the similarity". F#, Haskell and Python are indentation sensitive. OCaml is not. | |
| Jan 14, 2012 at 14:01 | comment | added | J D | @missingfaktor: "Show me an authoritative source that differs with this, and I'll update my answer accordingly". I've no idea but I wonder about the relative sizes of the parsers/grammars. | |
| Jan 14, 2012 at 14:01 | comment | added | J D | @missingfaktor: "The lack of TCO in JVM hasn't bothered many Scala developers". When TCO fails in F# it really bothers me. | |
| Oct 7, 2011 at 13:23 | comment | added | Landei | @missingfactor: I need new glasses 8-) | |
| Oct 6, 2011 at 11:02 | comment | added | missingfaktor | @Landei: Yes, I did mention typeclasses. :-) | |
| Oct 6, 2011 at 11:02 | comment | added | missingfaktor | @JonHarrop: I find F# syntax very close to that of OCaml's. I am familiar with Haskell and Python as well, and I don't see the similarity. Yes, the syntax (and semantics) of F# when it comes to OOP differs completely from that of OCaml's. Still IMO their syntaxes are close enough to justify my statement. | |
| Oct 6, 2011 at 10:59 | comment | added | missingfaktor | @JonHarrop: I picked the keyword count from this blog post. Show me an authoritative source that differs with this, and I'll update my answer accordingly. | |
| Oct 6, 2011 at 10:57 | comment | added | missingfaktor | @JonHarrop: The lack of TCO in JVM hasn't bothered many Scala developers. Trust me, it's not as big an issue as you seem to think. Most of the time, we are using higher order functions, instead of explicit recursion. And most higher order functions in Scala are implemented in terms of loops, and not recursion. So, lack of TCO becomes close to immaterial. | |
| Oct 6, 2011 at 10:55 | comment | added | missingfaktor |
@JonHarrop: Scala doesn't treat ADTs specially. They are treated just like regular classes. Thereofre Some(2) in Scala has type Some[Int] and not Option[Int] which is undesirable IMO. F# on other other hand has a special syntax and treatment for ADTs, and can thus correctly infer type of Some 2 as int option. So F# encoding of ADTs is better than that of Scala's (IMO, of course). I did not try to imply that it's inferior, and I am sorry if it came across that way.
|
|
| Oct 6, 2011 at 10:10 | comment | added | Landei | One additional important difference is that Scala has implicit conversions, which allows to simulate Haskell style type-classes. | |
| Oct 6, 2011 at 9:36 | history | edited | missingfaktor | CC BY-SA 3.0 |
added 9 characters in body
|
| Dec 27, 2010 at 13:54 | comment | added | J D | You say "F# syntax is completely OCaml-ish" but F# differs from OCaml syntax in many ways. The defacto-standard #light syntax in F# is completely un-OCaml and more like Python or Haskell. The syntax for objects and classes in F# is also completely different from OCaml's. Even the syntax for array access is different... | |
| Dec 27, 2010 at 13:52 | comment | added | J D | You say "Scala has 40 keywords, whereas F# has 97" but F# has only 63 keywords by my count, not that it is representative of anything. | |
| Dec 27, 2010 at 13:50 | comment | added | J D | You say "Scala tries to fuse the two paradigms into one (we call it object-functional paradigm)" but Scala lacks general tail call elimination and, consequently, any non-trivial functional code (including almost all conventional functional idioms such as continuation passing style and untying the recursive knot) are prone to stack overflows in Scala and, therefore, are practically useless. | |
| Dec 27, 2010 at 13:48 | comment | added | J D | This answer perpetuates several misconceptions. I'll enumerate each in turn. You said "algebraic data types in F# are purely functional constructs with no OO'ness in them" but algebraic datatypes in F# are just class and, in particular, they support augmentation with OO instance/static members and properties. | |
| Oct 17, 2010 at 21:59 | vote | accept | Jonas | ||
| Oct 17, 2010 at 21:59 | history | bounty ended | Jonas | ||
| Oct 16, 2010 at 2:00 | comment | added | missingfaktor | @Jared: Edited :) | |
| Oct 16, 2010 at 1:48 | history | edited | missingfaktor | CC BY-SA 2.5 |
added 51 characters in body
|
| Oct 15, 2010 at 21:47 | comment | added | Jared Updike | Good answer, but I would say the syntax of F# is OCaml-ish rather than ML-ish, in fact F# even supports OCaml-compatible syntax: ctocorner.com/fsharp/book/ch2.aspx . (Just to be pedantic OCaml is ML-family.) | |
| Oct 15, 2010 at 18:37 | history | edited | missingfaktor | CC BY-SA 2.5 |
added 4 characters in body
|
| Oct 15, 2010 at 18:34 | comment | added | Chankey Pathak | @missingfaktor: Welcome :) | |
| Oct 15, 2010 at 18:31 | comment | added | Chankey Pathak | Best answer here. +1 | |
| Oct 15, 2010 at 18:26 | history | answered | missingfaktor | CC BY-SA 2.5 |