smoothdeveloper

Try fsharp with interactive, with paket it is also very easy to depend on complex graph of nuget dependencies.

Try defining an instance member with var in C#

better type inference for anonymous functions, better type inference for instance members.

Another big feature is code layout being more compact and consistent than in C# codebases.

Cobra language solved this and compiles to C#, they can introduce non nil references, but yes they can't scrap the BCL which is nil ridden.

Seems to go against null propagation operator though :)

Consider contributing to a type provider for the database engine of your choice, I use SQL Server and F# is a better choice than C# in this regard anyday because of the type provider library that was created by community.

Agree with other comments, back then MS invested a lot in C# while there was then way more VB users, now it should invest a lot on F# while there are way more C# users.

C# isn't going to dwindle because F# expands, if F# expands C# wins because F# has ability to appeal to developers on non .net platforms, where C# isn't seen as appealing, and F# has ability to bring outstanding projects and idioms to .net eco-system.

Take the returns on investment made with C# all those years and invest a fair share in F#.

The main reasons F# is not picking up have been stated, and I face this situation at my work where my use of F# is put on hold because Microsoft is not investing in it much and my colleagues have the feeling C# is "good enough" which is very short sighted perspective.

Nowadays, do you use any language which is not C like?

Regarding VB, the language is used by many people whose main occupation is not software development, and even for those doing software there are many who find C# or similar looking languages aren't a panacea (I do, and have around 15 years of C# experience).

In some cases VB is also less redundant than C#, it has better type inference for example.

I'm sure plenty of pascal/delphi developers are also fine without C#.

You should understand that other languages than C/C++/C# make different syntax choices, and it is not hurting C# in anyways that such language exist and prosper.

Note that I had a lot of prejudice against VB but I came back from that perspective, and in the meantime, I feel additions to C# language push it in territory where the syntax is getting really noisy / clumsy (I've picked up F# so I use that it as a metric).

> and function chaining with unnamed intermediary results actually reduces readability significantly

For me this is the reverse, having assignment (to verbose and often redundant named identifers) interrupting the flow adds a lot of visual noise compared to an expression using chaining functions (using say |> operator in F#).

Hence I found it easier to keep all lowercase to avoid headaches.

Try paket, will save you a lot of headaches with the redirect stuff

  brew install mono
  brew cask install visual-studio-code

once you are in vscode, install ionide: http://ionide.io

You are ready to script (or more) with a great / lightweight editor.

I actually wish a keyword was also usable for the case of reference type tuples in order to be able to disambiguate those in libraries and later switch the default.

It seems the feature was implemented to answer the concern of interop with C# (which in future v7 will have shorthand syntax only for System.ValueTuple but not for System.Tuple), the language might later add better support for deconstruction without the extra keyword.

For tuples which remain local, the compiler is generally good at eliding those (but not in all cases, if it is a concern, always check the optimized compiled output).

On Windows / Visual Studio, consider using https://github.com/fsprojects/VisualFSharpPowerTools which has some abilities similar to Resharper.

Consider using https://github.com/fsprojects/FSharpLint

I'm not sure if it is integrated to ionide yet.

Some samples can be seen with any .fsx file under https://github.com/StationQ/Liquid/tree/master/Samples

Paul Blasucci had a good talk on Active Patterns (an F# language feature):

https://github.com/pblasucci/DeepDive_ActivePatterns

This feature allows to encapsulate conditional matching on arbitrary input and dispatching.

For those who know ML, it is making the concept of pattern matching extensible to any construct.

Moreover, the article doesn't even propose a "good GUI".

The GUI seems to basically expose all the command line arguments in a simple UI, which is great for a developer tool, it would be nice to also see the corresponding command line generated by the tool.

"This Is What Happens When You Let Developers Write Blog With Clickbait Titles"

Sorry, I think I misunderstood your setup.

The proper way to do it with paket would be:

* get rid of the Dependencies project (it was a side effect of trying to cope with the pain of using raw nuget)

* add a paket.dependencies at the root of your repository listing all nugets used across the solutions

* next to each project, add a paket.references file with the names of the dependencies (only top level, you don't need to list transitive ones)

running the convert-from-nuget command should practically work out of the box if you don't have far out inconsistencies (which I believe you managed by reducing amount of packages.config files), but I'd recommend to do another round of sanitization similar to what I'm describing.

I think if you give it half a day of studying / using paket on a smaller repository, you'll figure out all the things you need to accomplish migration on a large scale repository, after which you'll be recouping benefits any time you need to adjust references in projects / add or update nuget packages.

In the Stack Overflow survey :)

UK seems to have the most adoption of F#.

From all I gathered about people that story was related to, it seems the F# project was done without looking at the C# implementation, on basis of same specifications.

If you were tasked to implement a project because first implementation failed, would you even read the first implementation or just base your work on the specification?

it is 'paket.references' file next to each proj file and a single 'paket.dependencies' at the root of the repository.

You can also integrate the restore part to msbuild so it works out of box from visual studio, msbuild, teamcity, whatever.

People prefer though to have separate restore packages step, the same way people prefer to use a better tool than raw msbuild to orchestrate build tasks (tool such as FAKE http://fsharp.github.io/FAKE/).

I think the title can be alleged mostly to the misconception which is prevalent at Microsoft since F# was introduced as a commercial product (before it used to be a Microsoft Research product).

Maybe you are unaware of that?

F# is a pretty good general purpose programming language and that is what the title and article tries to promote (albeit it doesn't give enough and diversified examples).

F# is also a reasonably easy programming language which puts emphasis first on "functional programming" (which you frame as hot keyword, I doubt the language was made to fill a hot keyword).

I don't know about the for pay contents of fsharp.tv, but I gather they might be introductory and try to bring understanding of "functional programming" aspects to an audience which isn't versed in it, it is sure good for them if "functional programming" is a hot keyword and people are looking for training material to pickup that language, but I wouldn't dismiss that as being spammy.

Chill out dude :)

* reduced churn on proj files

ensure consistency of dependencies across repository (can't do that with so many packages.config files)

* easy to figure out outdated dependencies / update those with changes that are very easy to diff

* no need to battle with transitive dependencies

* several transitive dependencies resolution algorithm (max can be used to be as up-to-date as possible)

* ease support for multi platform targeting (it puts conditionals around the references, when you switch platform, it switches to correct assemblies without you having to do anything)

* will write/maintain binding redirects related to nuget packages for you (saves from many runtime errors)

* can generate include scripts for nuget packages if you do .csx or .fsx scripting

* many more things

the UI integration in VS is not as good but if you look at it, the UI is also part of the problem with Nuget (doesn't work on several solutions, doesn't really understand transitive dependencies, etc.).

You can migrate with single command line, and start improving from then on.

Small note about Nuget, you might consider upgrading to paket (works nice with C# too):

http://fsprojects.github.io/Paket/

It removes so much pain compared to raw usage of Nuget and is very easy to learn/adopt.

You could evaluate using WebSharper which is opensource and company backed project with good trackrecord at using F# on server and client with same semantics.

http://www.websharper.com/

Fable has made few choices on the semantics which make it not totally identical to F# on the server, although this shouldn't impact most of the code severely; but the mindset of Fable is different than websharper.

For F# on the server, Mono might not be lightest (if you compare to python or ruby which are already there by default) but is still the most suitable option right now until the OSS dotnet core eco system stabilizes and supports major libraries.

F# is definitely a fine functional programming language, able to blend with a tinge of OO where it makes sense while still being functional first. Relatively easy to pick-up if you have exposure to haskell or ocaml or sibblings.

I found few examples browsing in Documentation:

https://nitlanguage.org/examples/

https://nitlanguage.org/examples/circular_list.html

You can hit the other "forward" key to recover everything in a good browser and/or websites which don't do silly things (99.99% of cases).

It really feels chromium team should install telemetry:

* how many unsubmitted forms edits lost by mistake

* how many backspace keystroke to do "history-back"

They should also consider alt-gr + left as "back-history", using two hands for this could be avoided this way.

alternatives:

* alert if any form filled by user wasn't submitted (in case site doesn't do that already)

* let 99% of user who don't know what they did (they are in minority compared to number of times backspace is pressed to actually navigate back) retype their form if they don't navigate forward (which recovers their input, or should)

* add a third hand to human race so it doesn't take all the hands to navigate back from keyboard

* lure lenovo to restore the back / forward keys on thinkpads and make that implemented on most keyboards

Have you considered F#? Works well for scripting.