4 ms·

The need for reliable and extensible libraries is a huge one, and that is largely why I am a huge fan of F#. Not that .NET is some silver bullet to solve all y

The need for reliable and extensible libraries is a huge one, and that is largely why I am a huge fan of F#. Not that .NET is some silver bullet to solve all your problems, but one could use F# to develop a $100,000,000 system largely because it shares the same framework C# does.

to3m 12y ago
If the target will run it, .NET would probably prove pretty good. You've got a good selection of languages, and even the de facto standard of C# is actually pretty decent (well, I think so anyway - has all the things I liked about Java, and mostly fixes most of the things I didn't). And if you need to write bits in C/C++, that's not a big problem, because the FFI is very easy to use. (MS's long-term plans for .NET always seem a bit of a mystery, though, and Mono never seemed to get much mindshare. Probably nothing that a bit of your $100,000,000 budget couldn't help with...)
jeremyjh 12y ago
I don't know why people always say that. How many full-stack web frameworks are there that use idiomatic F#? Haskell has at least three that were mature three years ago and still under active development. In general the .NET open-source ecosystem is weak; enterprise just waits for Microsoft to reveal the One True Way or spends thousands per seat on clunky tool-kits. That same enterprise will use hundreds of open-source Java libraries. Maybe its changed in the last few years and certainly there is enough there to work with, but I don't think it can rival Python or the JVM and I don't think F# has any edge over Haskell at all when it comes to libraries and community. You get a large, solid core to start with which is more coherent than the de facto Haskell standards but as soon as you start looking for nice idiomatic test frameworks, distributed application frameworks, embedded databases, FRP libraries or many other examples Haskell really leaves it far behind.
- pjmlp 12y ago
  Which Haskell libraries interoperate with classical enterprise stacks, alongside existing code?
  - codygman 12y ago
    It depends on how you define interoperate. The way you phrase this it sounds like the only answer is the JVM. In which case: https://hackage.haskell.org/package/java-bridge https://hackage.haskell.org/package/java-bridge However in the case where there is a lot of prior Java code, it might be easier to look at Scala or even Clojure.
  - jeremyjh 12y ago
    There are lots of libraries for building and consuming web services or using messaging products, which is the same as how any heterogeneous environment is integrated. Big companies integrate .NET, Python and Java like this all the time. There ARE also tools and libraries [1] for generating all the JNI code necessary to call directly into JVM libraries but I don't think it has seen much adoption. I'm not really arguing that Haskell is suitable for enterprise applications - it is not. For greenfield SAAS product companies though I think its as viable as F#. [1] http://hackage.haskell.org/package/java-bridge http://hackage.haskell.org/package/java-bridge
- edgyswingset 12y ago
  Well, you're not tied into using strictly F#. The C# MVC framework, or really any web framework, will play nice. The majority of an application like the one the article suggests will sit on a server, anyways. Once you're in server-land, things like web frameworks matter less because .NET already takes care of what you need. F# already has well-supported testing frameworks which integrate into Visual Studio, distributed computing frameworks, database interactivity, graphics libraries, and a slew of others. You can find plenty of testimonails of using F# for large-scale and enterprise systems. F# and C# are really just your tooling for .NET, which is sufficient for a massive-scale project. Whether or not .NET is appropriate for the project is a different story altogether - I wouldn't use it for anything that's close to the metal, for example.

to3m 12y ago

If the target will run it, .NET would probably prove pretty good. You've got a good selection of languages, and even the de facto standard of C# is actually pretty decent (well, I think so anyway - has all the things I liked about Java, and mostly fixes most of the things I didn't). And if you need to write bits in C/C++, that's not a big problem, because the FFI is very easy to use. (MS's long-term plans for .NET always seem a bit of a mystery, though, and Mono never seemed to get much mindshare. Probably nothing that a bit of your $100,000,000 budget couldn't help with...)

jeremyjh 12y ago

I don't know why people always say that. How many full-stack web frameworks are there that use idiomatic F#? Haskell has at least three that were mature three years ago and still under active development. In general the .NET open-source ecosystem is weak; enterprise just waits for Microsoft to reveal the One True Way or spends thousands per seat on clunky tool-kits. That same enterprise will use hundreds of open-source Java libraries. Maybe its changed in the last few years and certainly there is enough there to work with, but I don't think it can rival Python or the JVM and I don't think F# has any edge over Haskell at all when it comes to libraries and community. You get a large, solid core to start with which is more coherent than the de facto Haskell standards but as soon as you start looking for nice idiomatic test frameworks, distributed application frameworks, embedded databases, FRP libraries or many other examples Haskell really leaves it far behind.

pjmlp 12y ago
Which Haskell libraries interoperate with classical enterprise stacks, alongside existing code?
- codygman 12y ago
  It depends on how you define interoperate. The way you phrase this it sounds like the only answer is the JVM. In which case: https://hackage.haskell.org/package/java-bridge https://hackage.haskell.org/package/java-bridge However in the case where there is a lot of prior Java code, it might be easier to look at Scala or even Clojure.
- jeremyjh 12y ago
  There are lots of libraries for building and consuming web services or using messaging products, which is the same as how any heterogeneous environment is integrated. Big companies integrate .NET, Python and Java like this all the time. There ARE also tools and libraries [1] for generating all the JNI code necessary to call directly into JVM libraries but I don't think it has seen much adoption. I'm not really arguing that Haskell is suitable for enterprise applications - it is not. For greenfield SAAS product companies though I think its as viable as F#. [1] http://hackage.haskell.org/package/java-bridge http://hackage.haskell.org/package/java-bridge
edgyswingset 12y ago
Well, you're not tied into using strictly F#. The C# MVC framework, or really any web framework, will play nice. The majority of an application like the one the article suggests will sit on a server, anyways. Once you're in server-land, things like web frameworks matter less because .NET already takes care of what you need. F# already has well-supported testing frameworks which integrate into Visual Studio, distributed computing frameworks, database interactivity, graphics libraries, and a slew of others. You can find plenty of testimonails of using F# for large-scale and enterprise systems. F# and C# are really just your tooling for .NET, which is sufficient for a massive-scale project. Whether or not .NET is appropriate for the project is a different story altogether - I wouldn't use it for anything that's close to the metal, for example.