17 ms·

C# as a language is better than Java, but not as good as Scala.

by eloisant 12y ago

nathas 12y ago
Can you explain why you think so?
- lmm 12y ago
  Most of the selling points on scala-lang.org still apply over C# - type inference, pattern matching, case classes (C# makes these less bad than Java, but the field/property distinction can still bite you), an inheritance model that supports the good parts of multiple inheritance without the problems, covariance/contravariance, for/yield syntax that's generic and user-controlled, higher-kinded types. It takes a while for your code to get big enough for the last part to matter, but it's huge when it does - you can handle any kind of "context" in a generic way, e.g. async calls, error handling, audit logging, software transactional memory, or custom things for e.g. database access. F# has a number of these specific implementations but they're kind of "hard-coded" in the language rather than fully extensible. So I guess the pitch is: imagine C# async/await could be "just a library", and other contexts that you wanted to handle similarly could also be a library, and the resulting functions are first-class citizens in the type system (no awkward choices of whether a particular function is async or not, you can handle that generically).
  - Locke1689 12y ago
    So I guess the pitch is: imagine C# async/await could be "just a library", and other contexts that you wanted to handle similarly could also be a library, and the resulting functions are first-class citizens in the type system (no awkward choices of whether a particular function is async or not, you can handle that generically). That's true in F# -- async is just a library in a computation expression.
  - yohanatan 12y ago
    > F# has a number of these specific implementations but they're kind of "hard-coded" in the language rather than fully extensible. That's not true. You can extend the language yourself with "computation expressions" (and that's in fact how the 'async', 'let!' et al keywords are implemented).
    - lmm 12y ago
      True, but what you can't do is abstract over them; you can't write a function that operates on "some generic computation expression" (you can't even write that type). So you can't write "sequence" or "traverseM" or more complicated/specific things you build on top of these.
      - yohanatan 12y ago
        There is an encoding supporting that level of abstraction (perhaps though not as straightforward as you'd prefer); namely using interfaces (which are first-class) to encode module signatures. See: https://gist.github.com/t0yv0/192353 https://gist.github.com/t0yv0/192353
eranation 12y ago
I don't know why you are being down voted. Erik Meijer, a huge .NET contributor who worked at Microsoft (on C# among other things), and was behind the reactive .NET extensions (and also a big Haskell contributor) - he was saying exactly the same thing about Scala vs C# - http://www.infoq.com/presentations/covariance-contravariance-joy-of-coding-2014 http://www.infoq.com/presentations/covariance-contravariance... I can also testify as someone who uses Scala on a day to day basis and used C# at work as well - I completely understand your statement, although it's very subjective.
- Vektorweg 12y ago
  Peyton Jones and some other nice people work at Microsoft to improve Haskell, which is IMHO the right tool.
- jbooth 12y ago
  Probably because, A), it was an uncalled-for digression into language wars, and B), now that we're here anyways, a lot of us think the majority of features in scala and Haskell for that matter are fundamentally misguided. My goal is not to write elegant code, but to write the least complex code with the lowest cognitive overhead. TCO, 10x the man-hours in maintenance and all that. If the choice is between having to write null-checks or having to understand category theory to read my code, I'll take the null-checks.
  - psibi 12y ago
    > majority of features in scala and Haskell for that matter are fundamentally misguided I'm interested in the Haskell part. What features do you think are fundamentally misguided ?
    - jbooth 12y ago
      I'm much less experienced with Haskell than with Scala, so I might be unfairly painting it with the same brush here. But, for example, https://www.haskell.org/tutorial/io.html https://www.haskell.org/tutorial/io.html. At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. I shouldn't have to care what a monad is, and side effects? The whole point of I/O is side effects. It could be a no-op, idle process or CPU-burning busy loop if I didn't care about side effects. From that doc: " So, in the end, has Haskell simply re-invented the imperative wheel? In some sense, yes. The I/O monad constitutes a small imperative sub-language inside Haskell, and thus the I/O component of a program may appear similar to ordinary imperative code. But there is one important difference: There is no special semantics that the user needs to deal with. In particular, equational reasoning in Haskell is not compromised. The imperative feel of the monadic code in a program does not detract from the functional aspect of Haskell. An experienced functional programmer should be able to minimize the imperative component of the program, only using the I/O monad for a minimal amount of top-level sequencing. The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds." So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere). And that's fine, they can knock themselves out and I hope it's fulfilling for them. It's not for me.
joslin01 12y ago
+1 as a Scala fanatic :) It's all about what works for you though.
moonchrome 12y ago
F# is more of a .NET analogue to Scala.
- edgyswingset 12y ago
  I'd say it's the .NET analogue to Scala with added elegance.
  - karavelov 12y ago
    And removed flexibility that make it awkward - see for example the lack of higher kinds
brodo 12y ago
In Scala, there are just too many ways to do things. It's optimized for flexibility and easy writability. C# on the other hand may be a little more verbose, but at least everyone can read everyone elses code.
- saosebastiao 12y ago
  Funny, I find c# much harder to read. Its almost as if it is easy to understand code for languages you know well, and harder to understand code for languages you don't.
  - jbooth 12y ago
    You find C# harder than this? trait SeqLike[+A, +Repr] extends Any with IterableLike[A, Repr] with GenSeqLike[A, Repr] with Parallelizable[A, ParSeq[A]] { self => or def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That
    - deleted 12y ago
      [deleted]
    - saosebastiao 12y ago
      You intentionally chose code that is hard to read...I could easily do the same with C#. It isn't representative of the vast majority of the code that I use nor write. That being said, when you understand the nuances of type annotations, that code is quite readable in the mathematical notation sense. It is concise and takes more time per byte to understand, but it tells me enough about the code that I rarely have to read the actual implementation to know exactly what it does.
      - jbooth 12y ago
        It's from the standard collections library, the most-used code in any language. It is in fact representative of the vast majority of code you use. The fact that it wasn't immediately clear to you that a lot of your code DOES use this code is probably the strongest argument I could make.
HeavyStorm 12y ago
Apples and Oranges, my friend.
garrettheaver 12y ago
As someone who has written applications in C#, Java and Scala (amongst others). I'd be curious as what makes you think Scala is a winner relative to C#?
- asdf1234 12y ago
  I'd happily switch from Scala to F# but I would miss higher kinds and using implicits for typeclasses.
- eloisant 12y ago
  One big thing: Immutability by default. That's possible in C#, but it's hard to be sure everything is immutable => http://stackoverflow.com/questions/5097287/how-to-create-immutable-objects-in-c http://stackoverflow.com/questions/5097287/how-to-create-imm... A lot of interesting aspects of Scala are possible only because of immutability. And a lot of smaller things: * Typeclasses. In Scala you can implement them with implicit parameters, I have no idea how you would do it * Case classes. Again in C# you can implement something that kinda looks one with readonly and just a getter, but it's not as good as you won't get stuff like equality and copy, you'll have to write the boilerplate * Pattern matching, in particular with case classes * Option. You can create your own, or use the Option from FSharp, but all the lib you will use will be returning null all the time. * And more... Additionally there are aspects that are more of a personal preference, like how the "map" function is called "Select" and "filter" is called "Where", and so on. All functional languages use the same names, the SQL-like naming for manipulating collections is just confusing for me. At the end of the day, Microsoft tried to build a better Java when they designed C#. And it is indeed better than Java, especially because they moved fast in their versions while Sun/Oracle was terribly slow (why did we have to wait that much for lambdas??). But C# mostly sticks with the same concepts as Java (OOP) while Scala truly embraces both FP and OOP.
- deleted 12y ago
  [deleted]
jkrems 12y ago
Yes, that's why you would use F# in .NET if you want something like Scala. And then I heard many people say that .NET wins again.
- lmm 12y ago
  F# is elegant but ultimately held back by its lack of higher kinded types.
  - kvb 12y ago
    Held back from what? I mean, I'd love it even more if it had higher kinded types, but it's a pretty great language as is.
    - jakevn 12y ago
      It's simply less expressive. Just as Go is fine without generics, F# is fine without HKTs. It's a sad realization for those coming from a language that does support HKTs. Still a great language.
  - seanmcdirmid 12y ago
    I can't tell if you are serious or joking :). it is definitely a trade off to be made, the power offered by higher kinded typing doesnt come for free.
- bad_user 12y ago
  Meh, F# is pretty good, but Scala has a better type-system. You cannot model type-classes in F# for example and there's some ugliness in it, in a true Ocaml fashion - for example I don't like how you've got to deal with 2 types of generics or the prevalence of "static" methods, static methods that are complete hacks that go back to C++ at least (Scala has no such thing as static methods btw). In many ways Scala is a very elegant language, too bad that many people are scared by these myths that are flying around. That said, people are missing the forest from the trees. This isn't about the language, but rather about the runtime and the standard library. That's the true value of the JVM, that's the true value in .NET. There wouldn't be any problem for porting Scala to .NET. Sure, it would be difficult as .NET's reified generics are maybe too limited for Scala's type-system, but I'm sure somebody could make it work, at least partially. And there was a Scala for .NET, but it lacked interest so it died. But hey, you can still run stuff built in Scala on top of .NET by means of IKVM ;-) Has poor performance compared to a JVM, but then again, people are willing to build stuff in Scala for Android. Also Clojure.NET is doing pretty good from what I've heard. As a Scala developer that loves Scala and the JVM, I personally find this announcement very exciting. As finally, the JVM has true competition ;-)
sixothree 12y ago
Doesn't Scala run on the JVM, and isn't this announcement about porting the .Net runtime? And you're really drawing this comparison?
seanmcdirmid 12y ago
I went from scala to C# 7 years ago, and after some feature withdrawal, I began to like C# for its simplicity. It was not very elegant, I often had to settle for ugly solutions, but this was actually a step up from scala where I would obsess to find the most elegant solution for my code. In C#, the best way is more obvious even if not that good, and you settle more quickly. As the language is considered holistically with tooling, the error messages are always good and they don't make dubious decisions (getting rid of semi colons) that are theoretically sound but screw up tooling.
- frowaway001 12y ago
  > they don't make dubious decisions (getting rid of semi colons) that are theoretically sound but screw up tooling Wait WUT? I'm not sure you know what you are talking about ... that just doesn't make any sense. Scala 7 years ago is fundamentally different from today's Scala, so I'm not seeing how your experience is relevant anymore.
  - seanmcdirmid 12y ago
    Taking out semi colons reduced the amount of redundant information needed for error recovery in the parser, leading to poorer error messages and reducing the quality of interactive IDE feedback. I know this because I was working in the IDE when martin made the decision. Maybe it was the right decision, but there were definitely costs! There is a very good reason they will never eliminate semi colons from C#, the visual studio team would never let them...C# is developed in a completely different style from Scala. I'm sure you are right: scala today is probably a much more simple language with great IDE support...7 years ago, it was a bunch of advanced features and building a decent IDE for it was a struggle.
addicted44 12y ago
Why would you compare C# (although they keep adding functional programming concepts to it) to Scala, instead of comparing F# (which can commingle with C# wherever you need it) with Scala? I haven't looked into F# or Scala too much, but I bet F# comes out looking far better, because it was so deeply inspired by Haskell (but made practical).
- frowaway001 12y ago
  > I bet F# comes out looking far better, because it was so deeply inspired by Haskell (but made practical) Eh what? Scala is a lot closer to Haskell than F#/OCaml, and can express roughly the same things, while F# is a lot less expressive.
pjmlp 12y ago
> C# as a language is better than Java, but not as good as Scala. However Scala is not a first class citzen in the JVM, but C# is the systems language of the CLR, already a huge difference.

C# as a language is better than Java, but not as good as Scala.

nathas 12y ago

Can you explain why you think so?

lmm 12y ago
Most of the selling points on scala-lang.org still apply over C# - type inference, pattern matching, case classes (C# makes these less bad than Java, but the field/property distinction can still bite you), an inheritance model that supports the good parts of multiple inheritance without the problems, covariance/contravariance, for/yield syntax that's generic and user-controlled, higher-kinded types. It takes a while for your code to get big enough for the last part to matter, but it's huge when it does - you can handle any kind of "context" in a generic way, e.g. async calls, error handling, audit logging, software transactional memory, or custom things for e.g. database access. F# has a number of these specific implementations but they're kind of "hard-coded" in the language rather than fully extensible. So I guess the pitch is: imagine C# async/await could be "just a library", and other contexts that you wanted to handle similarly could also be a library, and the resulting functions are first-class citizens in the type system (no awkward choices of whether a particular function is async or not, you can handle that generically).
- Locke1689 12y ago
  So I guess the pitch is: imagine C# async/await could be "just a library", and other contexts that you wanted to handle similarly could also be a library, and the resulting functions are first-class citizens in the type system (no awkward choices of whether a particular function is async or not, you can handle that generically). That's true in F# -- async is just a library in a computation expression.
- yohanatan 12y ago
  > F# has a number of these specific implementations but they're kind of "hard-coded" in the language rather than fully extensible. That's not true. You can extend the language yourself with "computation expressions" (and that's in fact how the 'async', 'let!' et al keywords are implemented).
  - lmm 12y ago
    True, but what you can't do is abstract over them; you can't write a function that operates on "some generic computation expression" (you can't even write that type). So you can't write "sequence" or "traverseM" or more complicated/specific things you build on top of these.
    - yohanatan 12y ago
      There is an encoding supporting that level of abstraction (perhaps though not as straightforward as you'd prefer); namely using interfaces (which are first-class) to encode module signatures. See: https://gist.github.com/t0yv0/192353 https://gist.github.com/t0yv0/192353

eranation 12y ago

I don't know why you are being down voted. Erik Meijer, a huge .NET contributor who worked at Microsoft (on C# among other things), and was behind the reactive .NET extensions (and also a big Haskell contributor) - he was saying exactly the same thing about Scala vs C# - http://www.infoq.com/presentations/covariance-contravariance-joy-of-coding-2014 http://www.infoq.com/presentations/covariance-contravariance... I can also testify as someone who uses Scala on a day to day basis and used C# at work as well - I completely understand your statement, although it's very subjective.

Vektorweg 12y ago
Peyton Jones and some other nice people work at Microsoft to improve Haskell, which is IMHO the right tool.
jbooth 12y ago
Probably because, A), it was an uncalled-for digression into language wars, and B), now that we're here anyways, a lot of us think the majority of features in scala and Haskell for that matter are fundamentally misguided. My goal is not to write elegant code, but to write the least complex code with the lowest cognitive overhead. TCO, 10x the man-hours in maintenance and all that. If the choice is between having to write null-checks or having to understand category theory to read my code, I'll take the null-checks.
- psibi 12y ago
  > majority of features in scala and Haskell for that matter are fundamentally misguided I'm interested in the Haskell part. What features do you think are fundamentally misguided ?
  - jbooth 12y ago
    I'm much less experienced with Haskell than with Scala, so I might be unfairly painting it with the same brush here. But, for example, https://www.haskell.org/tutorial/io.html https://www.haskell.org/tutorial/io.html. At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. I shouldn't have to care what a monad is, and side effects? The whole point of I/O is side effects. It could be a no-op, idle process or CPU-burning busy loop if I didn't care about side effects. From that doc: " So, in the end, has Haskell simply re-invented the imperative wheel? In some sense, yes. The I/O monad constitutes a small imperative sub-language inside Haskell, and thus the I/O component of a program may appear similar to ordinary imperative code. But there is one important difference: There is no special semantics that the user needs to deal with. In particular, equational reasoning in Haskell is not compromised. The imperative feel of the monadic code in a program does not detract from the functional aspect of Haskell. An experienced functional programmer should be able to minimize the imperative component of the program, only using the I/O monad for a minimal amount of top-level sequencing. The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds." So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere). And that's fine, they can knock themselves out and I hope it's fulfilling for them. It's not for me.

joslin01 12y ago

+1 as a Scala fanatic :) It's all about what works for you though.

moonchrome 12y ago

F# is more of a .NET analogue to Scala.

edgyswingset 12y ago
I'd say it's the .NET analogue to Scala with added elegance.
- karavelov 12y ago
  And removed flexibility that make it awkward - see for example the lack of higher kinds

brodo 12y ago

In Scala, there are just too many ways to do things. It's optimized for flexibility and easy writability. C# on the other hand may be a little more verbose, but at least everyone can read everyone elses code.

saosebastiao 12y ago
Funny, I find c# much harder to read. Its almost as if it is easy to understand code for languages you know well, and harder to understand code for languages you don't.
- jbooth 12y ago
  You find C# harder than this? trait SeqLike[+A, +Repr] extends Any with IterableLike[A, Repr] with GenSeqLike[A, Repr] with Parallelizable[A, ParSeq[A]] { self => or def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That
  - deleted 12y ago
    [deleted]
  - saosebastiao 12y ago
    You intentionally chose code that is hard to read...I could easily do the same with C#. It isn't representative of the vast majority of the code that I use nor write. That being said, when you understand the nuances of type annotations, that code is quite readable in the mathematical notation sense. It is concise and takes more time per byte to understand, but it tells me enough about the code that I rarely have to read the actual implementation to know exactly what it does.
    - jbooth 12y ago
      It's from the standard collections library, the most-used code in any language. It is in fact representative of the vast majority of code you use. The fact that it wasn't immediately clear to you that a lot of your code DOES use this code is probably the strongest argument I could make.

HeavyStorm 12y ago

Apples and Oranges, my friend.

garrettheaver 12y ago

As someone who has written applications in C#, Java and Scala (amongst others). I'd be curious as what makes you think Scala is a winner relative to C#?

asdf1234 12y ago
I'd happily switch from Scala to F# but I would miss higher kinds and using implicits for typeclasses.
eloisant 12y ago
One big thing: Immutability by default. That's possible in C#, but it's hard to be sure everything is immutable => http://stackoverflow.com/questions/5097287/how-to-create-immutable-objects-in-c http://stackoverflow.com/questions/5097287/how-to-create-imm... A lot of interesting aspects of Scala are possible only because of immutability. And a lot of smaller things: * Typeclasses. In Scala you can implement them with implicit parameters, I have no idea how you would do it * Case classes. Again in C# you can implement something that kinda looks one with readonly and just a getter, but it's not as good as you won't get stuff like equality and copy, you'll have to write the boilerplate * Pattern matching, in particular with case classes * Option. You can create your own, or use the Option from FSharp, but all the lib you will use will be returning null all the time. * And more... Additionally there are aspects that are more of a personal preference, like how the "map" function is called "Select" and "filter" is called "Where", and so on. All functional languages use the same names, the SQL-like naming for manipulating collections is just confusing for me. At the end of the day, Microsoft tried to build a better Java when they designed C#. And it is indeed better than Java, especially because they moved fast in their versions while Sun/Oracle was terribly slow (why did we have to wait that much for lambdas??). But C# mostly sticks with the same concepts as Java (OOP) while Scala truly embraces both FP and OOP.
deleted 12y ago
[deleted]

jkrems 12y ago

Yes, that's why you would use F# in .NET if you want something like Scala. And then I heard many people say that .NET wins again.

lmm 12y ago
F# is elegant but ultimately held back by its lack of higher kinded types.
- kvb 12y ago
  Held back from what? I mean, I'd love it even more if it had higher kinded types, but it's a pretty great language as is.
  - jakevn 12y ago
    It's simply less expressive. Just as Go is fine without generics, F# is fine without HKTs. It's a sad realization for those coming from a language that does support HKTs. Still a great language.
- seanmcdirmid 12y ago
  I can't tell if you are serious or joking :). it is definitely a trade off to be made, the power offered by higher kinded typing doesnt come for free.
bad_user 12y ago
Meh, F# is pretty good, but Scala has a better type-system. You cannot model type-classes in F# for example and there's some ugliness in it, in a true Ocaml fashion - for example I don't like how you've got to deal with 2 types of generics or the prevalence of "static" methods, static methods that are complete hacks that go back to C++ at least (Scala has no such thing as static methods btw). In many ways Scala is a very elegant language, too bad that many people are scared by these myths that are flying around. That said, people are missing the forest from the trees. This isn't about the language, but rather about the runtime and the standard library. That's the true value of the JVM, that's the true value in .NET. There wouldn't be any problem for porting Scala to .NET. Sure, it would be difficult as .NET's reified generics are maybe too limited for Scala's type-system, but I'm sure somebody could make it work, at least partially. And there was a Scala for .NET, but it lacked interest so it died. But hey, you can still run stuff built in Scala on top of .NET by means of IKVM ;-) Has poor performance compared to a JVM, but then again, people are willing to build stuff in Scala for Android. Also Clojure.NET is doing pretty good from what I've heard. As a Scala developer that loves Scala and the JVM, I personally find this announcement very exciting. As finally, the JVM has true competition ;-)

sixothree 12y ago

Doesn't Scala run on the JVM, and isn't this announcement about porting the .Net runtime? And you're really drawing this comparison?

seanmcdirmid 12y ago

I went from scala to C# 7 years ago, and after some feature withdrawal, I began to like C# for its simplicity. It was not very elegant, I often had to settle for ugly solutions, but this was actually a step up from scala where I would obsess to find the most elegant solution for my code. In C#, the best way is more obvious even if not that good, and you settle more quickly. As the language is considered holistically with tooling, the error messages are always good and they don't make dubious decisions (getting rid of semi colons) that are theoretically sound but screw up tooling.

frowaway001 12y ago
> they don't make dubious decisions (getting rid of semi colons) that are theoretically sound but screw up tooling Wait WUT? I'm not sure you know what you are talking about ... that just doesn't make any sense. Scala 7 years ago is fundamentally different from today's Scala, so I'm not seeing how your experience is relevant anymore.
- seanmcdirmid 12y ago
  Taking out semi colons reduced the amount of redundant information needed for error recovery in the parser, leading to poorer error messages and reducing the quality of interactive IDE feedback. I know this because I was working in the IDE when martin made the decision. Maybe it was the right decision, but there were definitely costs! There is a very good reason they will never eliminate semi colons from C#, the visual studio team would never let them...C# is developed in a completely different style from Scala. I'm sure you are right: scala today is probably a much more simple language with great IDE support...7 years ago, it was a bunch of advanced features and building a decent IDE for it was a struggle.

addicted44 12y ago

Why would you compare C# (although they keep adding functional programming concepts to it) to Scala, instead of comparing F# (which can commingle with C# wherever you need it) with Scala? I haven't looked into F# or Scala too much, but I bet F# comes out looking far better, because it was so deeply inspired by Haskell (but made practical).

frowaway001 12y ago
> I bet F# comes out looking far better, because it was so deeply inspired by Haskell (but made practical) Eh what? Scala is a lot closer to Haskell than F#/OCaml, and can express roughly the same things, while F# is a lot less expressive.

pjmlp 12y ago

> C# as a language is better than Java, but not as good as Scala. However Scala is not a first class citzen in the JVM, but C# is the systems language of the CLR, already a huge difference.