akra

As someone who has done some dev in F# professionally I think a lot of the comments above could come from trying to use F# like C#. WPF (and in general older .NET Microsoft frameworks) is probably one of the worst cases for F# however; the framework is designed pretty much exclusively for C# usage (i.e. PropertyChangedEventHandlers, generated C# classes from XAML, etc). From a functional language perspective there's different ways of solving the above problems. While you could code WPF in F# it's clunky and doesn't pass the cost/benefit test IMO in its current state; you would be coding in C# style with just a different syntax since the framework enforces a given coding style.

Performance wise I find it depends on what your doing. I've had nicer code run faster in F# than C# with inlining and such. You can resort to mutable coding if you have to in F# as well so I don't think its truly the case. If your using immutable data structures and writing a WPF app on top without understanding them I can see why you would get the performance hit as an example.

I haven't had a problem with Intellisense, IDE niceness (e.g. Rider, VS Code), Go To Refs seem to even work in VS Code etc. All the Resharper goodies aren't there; but after awhile you find you just don't need them as much in a more leaner language.

The biggest difference in the past (i.e. industrial revolution) was that a human was still required when technology improved and the increased output only occurred from that tech when workers were skilled up to use it appropriately. Also training more workers in these new skills meant even more output and a potential edge against your competitors as that multiplier would carry to workers trained. Each worker gives you more productivity but you still need more workers to scale output. This obviously results an "arms-race" mentality from employers to train staff to fill the gap to take the lead against competitors. It also adds bargaining power to the skilled worker - if they strike instead of not producing that multiplier/leverage works against the employer as they miss out on more output than if an untrained worker strikes. They may even have to shut down their factory or whatever. Leverage and worker productivity work both ways for the employer; it's one of the big reasons cited for the rise of worker unions and arguably the rise of the middle class since then.

The first wave was all about making people more efficient (higher output multipliers for effort); the next wave may very well make people redundant in the economic production equation. If one person is all that's required to scale infinitely (O(1)) OR people aren't required once the capital is built the share of gains to workers IMO erode substantially and mainly accrue to capital holders. Particularly if those gains result in a concentration of market power to one company.

As you get used to the language some of the reasons make sense why it isn't C like. An example I've found is that (arg1, arg2) always defines a tuple wherever it is a function invocation or not. You can pass a tuple around to a tupled-arg function/method (C# style) with multiple args without unpacking it first as a example. Space orientated languages can be better with expressing in-language DSLs as well IMO allowing you to add symbols as appropriate.

SQLProvider has been ported to .NET Core - I've used it no problem when scripting/prototyping across a variety of different data sources at once. Admittedly I tend to just use straight ADO.NET anyway - its simple enough to use and with F# your not saving all that much code/if at all moving to Dapper since the language tends to be more succinct.

I'm using F# tooling in Linux and both VS Code and Jetbrains Rider's IDE's outclass most functional language IDE's at present IMO. It's greatly improved within the last year or so. If you use code most of your app in F# the null factor doesn't really bite you all too often and its not too hard to handle when it does.

I think C# creates a state machine for every async/await method that is compiles which keeps track of where it is at after every await and invokes the next piece of code based on that. Also I thought async/await came in F# first? According to wikipedia async/await came in 2010 (F# 2.0) and then was added in C# 5.0 two years later.

The developers I've encountered that use F#'s Async get confused at first mainly because they are used to C#'s Tasks being started upon creation. I personally think the F#'s model conceptually is better and I've seen more surprises with the C# one from dev's I've worked with (e.g. which SynchronizationContext is set and why does it work in my test but not in the app, why is there no trampolining and I'm deadlocking here, why do I need to pass around CancellationTokens everywhere, etc). There are benefits to the F# async model (execution) such as implicit cancellation token parsing from the root task which is much harder to implement if the Tasks are already started before you finish the root, that they are re-runnable, they can run on whatever context you want easier at the composed root level, and the fact that it uses a more generic feature in the language (which usually comes with a slight performance overhead). Both F#'s Async's and Tasks aren't the best for CPU parallelism IMO anyway - my impression is that they are for using up idle IO time across a number of threads more efficiently. An article which I think compares the two despite it being biased a little to F# rightly or wrongly: http://tomasp.net/blog/async-csharp-differences.aspx/

What aspect of performance though? Even that means a variety of different things to different people and it isn't just algorithms. I've met people who are bad at typical CS algorithms yet know their language of choice very well and write low-allocation high performance tight code that "does less". Or people that are used to handling concurrent code which sadly is still somewhat of a rare skill. Only the algorithms are touched on in typical CS courses; most aspects of performance tuning come from experience and persistence spending hours trying to get more performance and less resource usage out of an application.

The way to combat that IMO is to continue to innovate the language improving both the language and the context it runs in (tooling, ecosystem, etc) making it easier to use, more robust, minimize the costs/benefits of changing, etc. Having a great working functional language with access to a large ecosystem and decent tooling makes adoption easier and less risky. There's more to a language choice than features; it has to work for the dev's, the organization and it has to scale to the "good but not passionate" developer.

When I use F# on Linux (my main machine) I use VS Code on Linux and it seems to work fine once setup properly and it has all the minimal features (e.g rename, find usages, etc). I've heard Rider as an IDE has F# support now as well. You typically use the command line with the "dotnet" command to create projects and such. Still Microsoft technologies however they can run on Linux.

A link on the original announcement page states "Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.". If this is right the high coupling between the CLR and what really is a framework/library on top astounds me and is somewhat worrying. I'm foreseeing future deployment horrors. One of the advantages of .NET is portable IL code across anything that can interpret it similar to Java. If this is broken and I can only use .NET/ASP.NET Core CLR with certain native system dependencies installed then this big advantage of the .NET platform IMO is gone and creates some surprising non-intuitive issues.

You can see one example of this in the issue here: https://github.com/aspnet/AspNetCore/issues/3307. I install the package; then also need to install a system wide package using my package manager to back it? If I install the package I should be able to use it. It seems as if the GAC is back just for ASP.NET however? Unfortunately as I experienced recently installing the right asp net runtime doesn't necessarily fix the problem either; it just allows the app to start but then other run-time issues pop up. The only fix is self-containing the app - tough luck if your on a distro not supported. Maybe these are teething issues but the constant change between minor versions has been painful.

ASP.NET is no longer just another Nuget library it seems - it's now been promoted to be part of the CLR and this decision is the logical extension of that.

It's not criminal per se. It's all in the law - they just aren't perks available to the typical employee. The cash jobs are but they're in a business where they can get this; a typical engineer can't ask to be paid in cash from a large corporate client even if they are freelance. In Australia it isn't that hard - people often can't get tradies here and as a tradie you are spoilt with calls for work. I personally know some pretty rude tradies that constantly get work anyway despite doing bad work. Getting a tradie to travel more than 5km to do work around my house depending on the trade is hard; they have enough work within a 5 K radius not to bother. They can charge what they like and typically do. Especially for the top end of town.

In Australia which this reply chain is about trades get paid exceptionally well if you have a successful business operation (not working for someone else). There's simply an oversupply of university graduates and a very liberal visa program for IT workers. Most tradies here have their own business so any income figures are highly misleading. As an example he may earn 65k on his tax retrun but his wife does the "accounts" (65k goes there too) + the cash jobs that they don't declare on tax. A good tradie can earn 150k easy and pay less tax than the average office worker due to clever business accounting. And there's always work; and none of those "horror" stories you hear about software interviews here on HN and other sites.

I suspect there is a point of diminishing returns with this though; the extra complexity in the type system gets you less and less benefit but at a greater cost to code complexity/comprehension. It could explain why the mixed Scala/F# paradigm has more industry usage than Haskell right now. i.e. I am trading a type system that has a little more expressiveness for a large amount of libraries, ecosystem, rock-solid VM, testing, corporate buy-in, etc. In a .NET shop for example its much easier to just drop an F# DLL into your codebase (in VS create a new F# project in a few clicks); there's no need to change anything else (e.g. build machines, build tooling, testing tools) since it's all IL anyway; same goes with Scala and Java.

My experience in coding functionally has shown that mutation (especially if localized and doesn't leak outside of a function) can really help functional code become a lot faster. From what you describe C# is slowly becoming an F# clone; which may be a good thing or not. Still think that if you need these features you should move to Scala/F#/Ocaml/Haskell though since I suspect these features will be added to C# in a clumsy/compromise way given its roots (e.g Scala and F# already have exhaustive pattern matching, async streams/iterators, better type inference, etc.).

As a counter to this that may make it easier for a company to adopt and reduce the learning curve. Laziness can make it harder for some to reason about performance as an example.

> Why? Even writing micro service in C++ is dead simple these days

Apologies to the commenter then. I misread that to be a "why bother?" to the original blog post and do this instead. All tech has its pros and cons and trying other things can be good too.

How come on every thread showing an example of how to do something in Rust there's a staunch C++ defender thinking the whole world should be using their language? C++ is a complex beast that due to its age has quite a number of disadvantages and no two codebases I've seen are the same - a measure of a language is its simplicity and C++ subjectively isn't thus. If you like C++ that's fine; doesn't mean you can't do it in Rust as well.

I think it's good that other languages are evolving that are safer, make it easier to do concurrency, have an idiomatic style and still are performant whilst removing legacy cruft. It's the natural evolution of things. Every C++ team I've been on debates every feature usage (e.g. auto/lambdas/etc) where one team's good code is another's bad idea due to sheer amount of legacy features vs new ways, what language constructs are good vs completely bad ideas (everyone has completely different opinions), how should I import libraries, what build tool to use, etc.

Most of those innovations however seem to be playing "catch-up" though and there's a huge question mark as to whether most (not necessarily all) of the benefit goes to capital holders. Even the innovations that do benefit as a percentage how much do they lift living standards by compared to innovations of old? Electricity meant I had light at night; think of your local neighborhood without sewerage, etc.

They are also "costing a lot more" in terms of training and intelligence so there's a question mark of how much the average person without capital or privilege can access them. For me there's also a question of whether they are just playing catch up for increase in human population that's happened since the WW2 era - how many are not required if we just reduce population? Per capita are we really better of? There's a reason a lot of people are "nostalgic" for the period before the 1990's. There's also the negative things to consider of all this "innovation" such as environmental degradation, the massive increase in CO2 emissions, etc.

The "stagnant" economy (e.g food, land, health care) - the things most people need to survive comfortably have been increasing in cost significantly for most world economies. The innovations you state most of the world's population (who are mostly poor btw) would happily trade away for cheap more nutrient rich food, house, cheaper energy, etc.

Not saying hyperloops, blockchains and such aren't cool; I'm just questioning whether technology alone is what improves our quality of life. And all technology requires energy which is generally increasing in cost.

I agree with the first missing feature as you state; I just don't know how much value-add those features actually add in real world apps - often people use them in weird and unintitutive ways as well. F# has other features that other languages don't have as well. I find the workflow syntax eliminates some of the need for the first; and I find I can write functions that work with most numeric types at least a lot more so than C#/Java/etc. As a simple example the in-built F# library comes with functions that work on most number types (e.g SumBy works with anything that supports (+) including my own types). Sure there might be advanced examples that I wish I could do but they don't come often. I do find F# more concise, generally less "smart" and more explicit than Scala code which I think is a good thing. I've seen some funky Scala code in the past. Ease of code/learning/etc, and a maintainable codebase at least for me trumps features most of the time.

Disagree as someone who has programmed in both Scala and F#; I found F# pretty much could do the same things just in different ways. In F# I found more ways to squeeze performance than in Scala which by comparison is bloated. For the data applications ive written F# wins usually especially with ad-hoc tactical apps and in my experience was easier to teach than Scala which is not as coherent of a language.

Because IQueryable's don't always translate to working SQL. I've broken EF's IQueryable a few times in the past; NHibernate's one was really bad if I recall. The expression inside the IQueryable operator is checked for type safety but the ability to generate SQL from it isn't which happens at runtime when the LINQ is evaluated. The F# approach bypasses the expression -> SQL translation and directly checks the SQL at compile time if it valid against a database schema rather than the expression AST that C# LINQ does.

Having 10 lines of code for 10 different data sources and having a explorable Intellisense API for all of them is much nicer though than having 10 code generator + command line tools in my now required build pipeline, each one with a different syntax. Don't get me wrong - I will resort to code generation for some things if there isn't a type provider available but I always find more friction with this path and still doesn't give me all the benefits of type providers (e.g the SQL static type checking aspect). It works across different IDE's, don't need to introduce more build tooling, generated code is obvious vs a code generator, is as cross-platform as the underlying language/runtime is, etc.

Slightly more convenient for one source becomes very convenient as the amount of data your analyzing increases. It's not the be-all-end-all it was promised to be as a feature but it is easier than code generation IMO. If you can get rid of the disadvantages by keeping reference schema locally in its native form (e.g no flakiness you mention) then why not use it?

Disagree with this; because it very much depends on the program being written. From what I've seen they've become more popular with ironically the exception of the SQL ones for the reason you describe. As long as you can get the schema/example file locally on the source tree without the type provider needing to fetch it remotely it saves having to write up a lot of classes by hand. E.g with web UI calls just get the swagger Json and download it into your solution, for rest/json APIs just drop all the example documents into a folder and have the type provider reference that. Once the source data is local the flakiness mostly goes away and it just becomes a much quicker/less error prone way of expressing schema from a wide variety of sources. It's personally saved me a lot of time in development especially when interacting with many data sources at the same time - that's a lot of Dtos I would have to craft myself and I would in this case probably moved to a dynamic language a while ago for the work I do. A type provider that allows local schema would deal with your issue and then you would get type checked SQL queries at compile time without the direct db dependency and connection latency.

You can via the F# Power Tools; at least in VS2015. In VSCode just create the folder as per normal and hit "F1->F#: Add File to Project" using the Ionide plugin. Admittedly the need for folders in my experience is a lot less than in C#.

Saw a presentation on this was done awhile back. Most features are exposable to C# pretty easily - it's pretty easy to design libraries where consumers wouldn't know it was a F# type at first glance if you know how things compile down. If not directly you can always do simple things to make your types consumable in C# (e.g for my DU's I put a "match" member on them and have a Func argument for each case if exposed to C#). Or provide Func<> overloads for C# compatibility rather than the faster non-delegate FSharpFunc equivalents. One feature you can't use from C# is F#'s templated method support (SRTP) which I've used as a get-out-of-jail card when working with some pretty bad APIs due to static duck typing support. I think even the most basic features (e.g. deep structural equality) make it easier to write things especially libraries quicker in F# once you get the hang of it.

I definitely agree with you for tuples especially smaller tuples. As tuples get larger however performance can swing the other way. As someone who codes some F# for my day job it seems that while tuples should be easier in a functional language like F# for backwards compatibility struct tuples will be more awkward to use than in C# 7. I think they should of just bit the bullet for tuples up to a certain size.

For records and unions however I think the attribute is fine. Most of the time for types of more than 3 fields say structs can be worse in performance than classes anyway. Records and unions tend to be assigned more and live longer than tuples most of the time. For unions for obvious reasons structs are not recursive in nature which with unions is required somewhat (see https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110...). Definitely wouldn't want structs to be the default here.