5 ms·

...I know that HN people are mostly *NIX oriented or dislike Microsoft technologies ...but how about F#? ...wouldn't it provide most of the advantages of a ML f

by nnq 14y ago

...I know that HN people are mostly *NIX oriented or dislike Microsoft technologies ...but how about F#? ...wouldn't it provide most of the advantages of a ML family language but coupled with the "smoothness" of VS tooling and .Net integration that could take some of the deployment pains away and provide the "accelerated liftoff" needed by startups? (It's a question, not suggestion... I must admit I've never had the balls to use ML of Lisp like languages in production so far...)

ryanpers 14y ago
well, you got it in the first paragraph - because Windows isnt Unix, and people dont use it for production. F# is in theory nice, but devops'ing windows, I just dunno man.
- nnq 14y ago
  I've heard there's also good F# support via Mono now (but then again, I dunno about devops'ing with Mono... I wish someone had the balls try this and post about the experience...)
  - MichaelGG 14y ago
    I've been deploying F# into production for a couple years, on to both Windows and Linux. They're rather simple daemons that talk to databases, message queues and filesystems, and do telecom logic (routing/billing). Overall, Mono has been incredibly smooth. I prefer to compile from source as RedHat doesn't come with packages for mono. That takes time, but isn't a big deal. F# support seems lacking when it comes to some of the tooling (compiling, interactive). mono-service, the service daemon to act like a Windows Service host (allowing same code as on Windows, and ~5 lines to a minimal daemon) sometimes has acted weird, but it's been due to how it handles it's runfiles and lockfiles, and once you know that it's easy enough to make sure they're ok. (As in, if one user ran it, the perms are wrong so another user can't even check it, and the error messages aren't there/clear.) F# performance is on par for .NET. If a certain high-level feature is not generating great code, there's always the option to drop down or approach another way. F#'s much more flexible than C# when it comes to performance. F#'s why I stay on the MS stack. .NET is pretty compelling with it's base library and great tool/developer support. But after seeing powerful languages, I just get so annoyed with the verbosity of things like C#.
    - mattmanser 14y ago
      Verbosity in C# practically disappeared with 3.0, released with .Net 3.5. There are a couple of things left that annoy me, but mostly it's gone.
      - Associat0r 14y ago
        C# verbosity is far from gone. http://trelford.com/blog/post/LighterCSharp.aspx http://trelford.com/blog/post/LighterCSharp.aspx http://trelford.com/blog/post/Boiler.aspx http://trelford.com/blog/post/Boiler.aspx http://lorgonblog.wordpress.com/2009/10/25/overview-of-type-inference-in-f/ http://lorgonblog.wordpress.com/2009/10/25/overview-of-type-... http://www.njgeeks.org/presentations/FS-Patterns-Long/#18 http://www.njgeeks.org/presentations/FS-Patterns-Long/#18
      - MichaelGG 14y ago
        It got _better_, way better, much nicer than Java. It's not even remotely gone. Type inference is crap in C#, and they even admitted in some cases, it was due to compiler design problems, not language design[1]. Even local vars can't be type inferred if they're functions, because of C#'s confusing decision to use the same syntax for lambdas and quoted code. The ASP.NET MVC team resorted to using reflection on anonymous types, because there was no lightweight way to pass in a set of options at runtime. With a more expressive syntax, that'd be needless. C# has statements that aren't expressions, which really bulks up code and adds flow for no reason. In F#, even "if" and "try" blocks are expressions which again keeps slimming things down, and more importantly, keeps the code simpler. In one direct "line-by-line" translation (C#->F#), F# reduced the number type annotations I needed by 95% (1/20th). No pattern matching (and thus no active patterns!), little type inference, no syntax for tuples, no lightweight function syntax, no code nesting, no workflows, (and a weird hardcoded one just for async), no top-level functions, no custom operators, and C# is flat-out downright clunky when compared to F#. It may be one of those "you don't know what you'll miss until it's gone" kind of deals. I've used C# now and then, even last month on an entire project, and it just feels tiring. 1: http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-n...
- koide 14y ago
  It can be done. Ask StackExchange. And it has grown much MUCH better/easier from 2k8 R2 onwards. Don't mistake me for a Windows fan, just pointing out that Windows's gotten a lot better than it used to be.
hamidr 14y ago
There are also clojure and scala with java integration which are cross platform.
- nnq 14y ago
  yes, they are functional, but they are not "Haskell relatives" at all... Clojure is a Lisp (and I still have some reluctance imagining it being effectively used in a team of more than 3 programmers with more than 10 points IQ difference between them...) ...and Scala is a "weird beast" - I dunno, but the "businessy" side of my mind tells me it's far from a silver bullet and may end up being too "complicated" for the problems I need to solve, and I don't like it when the tools I'm using are more complex than the problems I'm solving...
  - ebiester 14y ago
    In practice, I'm not seeing it as a problem. It's a bit like C++ in that you can safely ignore all but a subset of the functionality. The problem is that everyone picks a different subset. :) I'd say the compiler speed is still the biggest problem, and they're working on it.
    - mietek 14y ago
      You joke, but Scala's complexity is a very real problem. Specifically, abuse of implicits can make trying to understand Other People's Code quite the nightmare. Even reading the function type specifications in the official Scala docs is a chore.
      - ebiester 14y ago
        Okay, I'll agree about implicit abuse. I feel like reading the function types is something I will eventually feel more comfortable with, as if it's my fault for picking a language with both the power and static typing. And I haven't figured out a better way to do it myself.
        14y ago
scott_w 14y ago
I think one of the issues with using Microsoft tools is licensing. The perception around Microsoft is that things can stay cheap (or even free), but at a certain point you're going to be expected to shell out the big bucks. From our own experience, we find that Microsoft software sort-of works with other Microsoft software. However, when you want something that isn't MS to work, you're immediately into serious financial outlay. For a start-up, this simply isn't feasible. Even a well-funded start-up has better things to spend their money on than sending it straight to Microsoft's bank account.
batgaijin 14y ago
I think a better thing to mention is Jocaml; I think that is the true successor of *ML as much as Microsoft doesn't want to admit.

by nnq 14y ago

ryanpers 14y ago

well, you got it in the first paragraph - because Windows isnt Unix, and people dont use it for production. F# is in theory nice, but devops'ing windows, I just dunno man.

nnq 14y ago
I've heard there's also good F# support via Mono now (but then again, I dunno about devops'ing with Mono... I wish someone had the balls try this and post about the experience...)
- MichaelGG 14y ago
  I've been deploying F# into production for a couple years, on to both Windows and Linux. They're rather simple daemons that talk to databases, message queues and filesystems, and do telecom logic (routing/billing). Overall, Mono has been incredibly smooth. I prefer to compile from source as RedHat doesn't come with packages for mono. That takes time, but isn't a big deal. F# support seems lacking when it comes to some of the tooling (compiling, interactive). mono-service, the service daemon to act like a Windows Service host (allowing same code as on Windows, and ~5 lines to a minimal daemon) sometimes has acted weird, but it's been due to how it handles it's runfiles and lockfiles, and once you know that it's easy enough to make sure they're ok. (As in, if one user ran it, the perms are wrong so another user can't even check it, and the error messages aren't there/clear.) F# performance is on par for .NET. If a certain high-level feature is not generating great code, there's always the option to drop down or approach another way. F#'s much more flexible than C# when it comes to performance. F#'s why I stay on the MS stack. .NET is pretty compelling with it's base library and great tool/developer support. But after seeing powerful languages, I just get so annoyed with the verbosity of things like C#.
  - mattmanser 14y ago
    Verbosity in C# practically disappeared with 3.0, released with .Net 3.5. There are a couple of things left that annoy me, but mostly it's gone.
    - Associat0r 14y ago
      C# verbosity is far from gone. http://trelford.com/blog/post/LighterCSharp.aspx http://trelford.com/blog/post/LighterCSharp.aspx http://trelford.com/blog/post/Boiler.aspx http://trelford.com/blog/post/Boiler.aspx http://lorgonblog.wordpress.com/2009/10/25/overview-of-type-inference-in-f/ http://lorgonblog.wordpress.com/2009/10/25/overview-of-type-... http://www.njgeeks.org/presentations/FS-Patterns-Long/#18 http://www.njgeeks.org/presentations/FS-Patterns-Long/#18
    - MichaelGG 14y ago
      It got _better_, way better, much nicer than Java. It's not even remotely gone. Type inference is crap in C#, and they even admitted in some cases, it was due to compiler design problems, not language design[1]. Even local vars can't be type inferred if they're functions, because of C#'s confusing decision to use the same syntax for lambdas and quoted code. The ASP.NET MVC team resorted to using reflection on anonymous types, because there was no lightweight way to pass in a set of options at runtime. With a more expressive syntax, that'd be needless. C# has statements that aren't expressions, which really bulks up code and adds flow for no reason. In F#, even "if" and "try" blocks are expressions which again keeps slimming things down, and more importantly, keeps the code simpler. In one direct "line-by-line" translation (C#->F#), F# reduced the number type annotations I needed by 95% (1/20th). No pattern matching (and thus no active patterns!), little type inference, no syntax for tuples, no lightweight function syntax, no code nesting, no workflows, (and a weird hardcoded one just for async), no top-level functions, no custom operators, and C# is flat-out downright clunky when compared to F#. It may be one of those "you don't know what you'll miss until it's gone" kind of deals. I've used C# now and then, even last month on an entire project, and it just feels tiring. 1: http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-n...
koide 14y ago
It can be done. Ask StackExchange. And it has grown much MUCH better/easier from 2k8 R2 onwards. Don't mistake me for a Windows fan, just pointing out that Windows's gotten a lot better than it used to be.

hamidr 14y ago

There are also clojure and scala with java integration which are cross platform.

nnq 14y ago
yes, they are functional, but they are not "Haskell relatives" at all... Clojure is a Lisp (and I still have some reluctance imagining it being effectively used in a team of more than 3 programmers with more than 10 points IQ difference between them...) ...and Scala is a "weird beast" - I dunno, but the "businessy" side of my mind tells me it's far from a silver bullet and may end up being too "complicated" for the problems I need to solve, and I don't like it when the tools I'm using are more complex than the problems I'm solving...
- ebiester 14y ago
  In practice, I'm not seeing it as a problem. It's a bit like C++ in that you can safely ignore all but a subset of the functionality. The problem is that everyone picks a different subset. :) I'd say the compiler speed is still the biggest problem, and they're working on it.
  - mietek 14y ago
    You joke, but Scala's complexity is a very real problem. Specifically, abuse of implicits can make trying to understand Other People's Code quite the nightmare. Even reading the function type specifications in the official Scala docs is a chore.
    - ebiester 14y ago
      Okay, I'll agree about implicit abuse. I feel like reading the function types is something I will eventually feel more comfortable with, as if it's my fault for picking a language with both the power and static typing. And I haven't figured out a better way to do it myself.
      - 14y ago

scott_w 14y ago

I think one of the issues with using Microsoft tools is licensing. The perception around Microsoft is that things can stay cheap (or even free), but at a certain point you're going to be expected to shell out the big bucks. From our own experience, we find that Microsoft software sort-of works with other Microsoft software. However, when you want something that isn't MS to work, you're immediately into serious financial outlay. For a start-up, this simply isn't feasible. Even a well-funded start-up has better things to spend their money on than sending it straight to Microsoft's bank account.

batgaijin 14y ago

I think a better thing to mention is Jocaml; I think that is the true successor of *ML as much as Microsoft doesn't want to admit.