Hacker News Reader

Comment by runT1ME | Hacker News Reader

I can make the same comment about C#/F# guys when I show them Scala. Scala is a better, more powerful language. I quite like C# and do it for my main contract I have, but I am always missing features that Scala has, while I never have the inverse.

It's nice that F# has better type inference, but I feel like it really isn't that different than C#. If C# got rid of boilerplate, made brackets optional, and fixed type inference, what does F# buy you?

View on HN

Workflows. Tuples. Immutable types. Inline functions. First-class functions. Definable operators. Pattern matching. Active patterns. Type providers (although full hygienic macros would be even better). Everything-as-an-expression. Lack of nulls. Nested functions. Discriminated unions. Quotations (expression trees are a weak hack just for LINQ-to-SQL). Object expressions. Concise function definition and application syntax (which naturally creates the illusion called partial application).

I make the inverse argument: At a minimum, you can use F# as C# but with better syntax. So what does C# buy you, if you're not using some of the VS designers?

Good comment. Didn't realize F# let you have inline functions, everything as an expression and partial application. Forgot about pattern matching too!

I don't really see a need for workflows, I can do everything I need to use workflows for with custom LINQ.

I'll reconsider pushing F# for some of the c# work I do. However, if someone isn't bound to the CLR, i'll ask what F# gives you over Scala :-)

Without workflows, you can't achieve e.g. async without building it into the compiler. You can abuse the LINQ syntax to simulate part of it, but you don't get proper exception handling, and it reads terrible as well.

Versus Scala, F# seems far more concise. Scala seems to be very Java/OO oriented, and comparatively verbose. I understand the type system is more advanced in Scala. But I've not written anything in Scala so this is sorta speculation. I'd be surprised to find that the tooling for Scala surpasses F#'s though.

You mean apart from discriminated unions, pattern matching, computation expressions, units of measure, partial function application, immutability by default and general lack of null reference exceptions?

I wish Scala for CLR has not been abandoned :(. Imagine a nice modern language that targets both CLR and JVM! A man can dream...

Well hold on to your hat: Clojure targets both AND JavaScript!

Hmm, interesting. Is CLR a second-class citizen for it? How actively is the language developing?

Very actively. We just released core.async, and Clojure 1.6 should be out by the end of the year (1.5 was released at the start of the year).

And yes, the CLR is a bit of a second-class citizen.

Could you point out a few features? Would be interested to know.

Higher kinds are quite nice.

1. In scala you could write

   class MyClass[A[_]](a: A)

and it can only take a 'container' (List/Future/Option).

in C#/F# this is invalid:

    class MyClass<A<?>> {
            public MyClass(A a) {
             } 
    }

You could make a plain ol' generic that took a concrete type List<Int> but not just on the type.

2. Implicit Conversion: In C#/F# you get extension methods, but it doesn't help you take an existing class and ad-hoc make it implement an interface.

So in scala I could do this:

   trait XMLSerializable { 
      def toXML(): XMLNode
   }

and then let's say I want to make existing classes in the standard library implement this interface:

   implicit def toXMLSerializable(li: List[_]): XMLSerializable = 
   new XMLSerializable {
      def toXML = {
         transformListToXML(li)
      }
   }

I can now do:

    val genericXmlSerializable: XMLSerializable = List[Int](1,2,3,4)

Reply on news.ycombinator.com