[fowlerpower]

F# is a beautiful language. You always want to use the right tool for the job but honestly F# is so right for so many jobs.

I know a lot of people don't want to hear this but these types of languages, functional first, are the future of our industry. (In the sense that in the 2000s Java like laguanges were the future of our industry). I might be reaching here, but in my opinion, these are the right languages for the Cloud and that's why they are getting so popular.

[staticassertion]

I would agree if I felt that the industry were moving towards "better" software - as in, as an industry, we said "Wow, we need to seriously take a step back and start writing systems more reliably, more securely, etc".

I do not think we're going in this direction, necessarily.

[grumpyprole]

Agreed. Objects for everything results in code that is riddled with hidden mutable state and side-effects (state is not encapsulated). It's impossible to reason globally about such systems, even before threads are added. Objects can be used as a reasonable module system, which is why many still advocate them, although IMHO better module systems do exist (e.g. in OCaml).

[rubber_duck]

I honestly wish this was true but I doubt it. F# is different enough to have a big curve, and yet the benefits aren't immediately tangible, it's just a bunch of small things that add up - but try selling that to someone. Meanwhile mainstream languages are picking up features from it (eg. C# will eventually have record types and pattern matching). I think languages like this will influence the mainstream but I don't see them being mainstream in the future.

[vivainio]

Huh, the benefits are immediately tangible, the biggest one being less code to do the same thing while remaining typesafe.

In the meantime, you probably need slightly, but not massively, better developers.

[rjbwork]

Sorry to keep shilling this, but it seems to keep coming up lately - exhaustive pattern matching library in pure C# https://github.com/Jagged/OneOf - https://www.nuget.org/packages/DiscU

[shados]

Facebook is betting pretty hard on ML via ReasonML (even on the client with BuckleScript), and F# is similar as an ML derivative.

We'll hear about these more and more for sure.

[pjmlp]

Sure, but the majority of companies in the world with IT department, don't have software as business, rather as a cost center for support their actual business.

Companies like Facebook aren't what the majority of us works on.

So when selling languages to management "look Facebook does it" usually doesn't help at all, what one needs are how that adoption will help those IT costs go down.

[aryehof]

Future of our industry? Such languages are popular and suited to certain types of projects and solutions certainly. Particularly for systems in computing, and information and data science.

However, for complex representational systems, including both transactional and continuous systems in business, commerce and industry, other languages and paradigms can remain better suited.

[KurtMueller]

> However, for complex representational systems, including both transactional and continuous systems in business, commerce and industry, other languages and paradigms can remain better suited.

Hello. Respectfully, what is a complex representational system? Why are other languages/paradigms better suited over a language like F#?

[willtim]

There's not enough detail here to really comment. I can say that Haskell has the best software transactional memory implementation out there, thanks to purity and controlled side-effects. Haskell's explicit handling of state also helps provenance and keeping state managed / in the database.

[twblalock]

> I know a lot of people don't want to hear this but these types of languages, functional first, are the future of our industry.

Mainstream languages will incorporate functional features and remain popular, and they will not be superseded by pure functional languages. Java and C# are already doing this.

[smoothdeveloper]

They will still remain generally more painful and more exposed to their issues and choices:

* mutable by default

* OO by default

* null by default

* structural equality a pain to implement

* immutable types a pain to implement

* verbose syntax / failing at the DRY principle

* statement based rather than expression based

* large codebase following those idioms

I don't think they'll not remain popular, but I think a more important share of people will eventually "get it" that there are alternative approaches which are sound, same or greater potential to achieve and thriving eco-system.

[smoothdeveloper]

The other thing is footprint of codebase, despite almost 15 years of using C#, after only two years, I consistently write F# which is 1/3 of equivalent C# code, writing idiomatic code that any F# developers would grasp.

There are ways a C# aficionado would take to try to not be so verbose, but those solutions won't be considered idiomatic by 99% of C# developers.

At the end of the day, codebase size matters a lot.

[cmoscoso]

I agree with functional first for backend programs. I don't see functional programming become popular on the front-end thought.

[christophilus]

I disagree. It is the frontend that made me want to learn functional programming in earnest. Redux and ImmutableJs were the catalysts.

I'm currently learning a couple of LISP variants (Closure and LFE). With ClojureScript, Elm, PureScript, BuckleScript, and even plain ole ES6, functional on the frontend is more compelling than ever.

[lucasmreis]

I disagree too. Frontend is getting more complex each day, and I find that functional programming languages help a lot with large projects. Frontend SPA's are crying for help with the exploding complexity :)