How to drive F# Adoption - Part 1? #798
Comments
|
My List:
|
|
UWA (ran into that again this AM - PCL doesn't cut it) |
|
|
While C# to F# interop is pretty much flawless, the opposite story has many pain points. For example:
Often when needing to make F# libraries consumable by C# code, I need to define lackluster C# wrappers that are mostly boilerplate. I think that this weakness may have contributed to some extent to the lack of success that F# libraries have had in the .NET ecosystem, which can in turn reinforce attitudes that F# is really just a toy language. Other than that, +1 tooling/debugger improvements, +10000 CoreCLR support. |
|
+1 tooling |
|
+1 on macros, compiler extensions ⭐ Perhaps the ability to compile to something other than IL? (F#->JS-AST, LLVM, ELF, MinGW) |
|
Add more value to the core language:
|
|
Tbh with the success of powertools and ionide I would vote to get the IDE There is still lots and lots to do in this repo and coreclr + .NET native + But please don't kill the OSS effort of the other projects by taking
|
|
Here are my thoughts on how to make F# more attractive to 'mainstream' developers. Oh, dear, here we go: Make F# a first-class .NET languageYou may claim that F# is already a first-class .NET language, but it's not, really. IIRC, when you install Visual Studio 2015, you have to actively select F# as one of the optional languages; if you don't select it, it's not even going to be in Visual Studio. Furthermore, look at how Microsoft talks about .NET and Roslyn: It's C# here, C# there, and then occasionally C# and Visual Basic. This tendency is clear with the new ASP.NET stack, as well as with Universal Apps. Outside of the Visual F# team, it seems like F# isn't really on the radar - not even in the rest of DevDiv, and certainly not in the rest of Microsoft. The (open source) F# community is doing a great job of tooting the F# horn via other channels, but the .NET community (if such a thing exists) as a whole is still largely taking its guidance from Microsoft. When there's no templates, no samples, no documentation, in Visual Studio, for most .NET developers it doesn't exist. What's really been puzzling me for a long time is that Microsoft doesn't realize what a gem they're sitting on. Programmers migrate towards better languages. When Java stagnated, many migrated to Scala (and Clojure). Programming languages matter. Microsoft as a whole sort of realises this: just look at the scramble towards JavaScript. F# is a unique language offering, because it's the only(?) 'industrial strength' programming language that offers a Hindley-Milner type system.
It may not be everyone's cup of tea, but if you want to be 'almost as Functional as Haskell', but can't convince your organisation to take a chance on it, F# is a great choice. Furthermore, due to the interop with .NET, it's easy to gradually introduce F# into an organisation that already runs .NET. Better toolingAll that said, better tooling is still needed. As @forki mentions, there's a lot of good to be said about F# Power Tools, but there are also areas where the Visual Studio editor seems too 'primitive' compared to the C# editor. E.g. it'd feel more modern with
I don't know if these can be built with F# Power Tools, but since it hasn't happened yet, I suspect these are some proprietary Visual Studio UIs that are locked down... Better web tooling supportWeb development is still a thing, and if the web development support is poor (e.g. lack of templates), you lose a lot of adoption right there. ASP.NET vNext isn't making it easier to get started with web development on F#. While I'm aware of alternatives such as Suave (and perhaps Freya), they aren't going to win C# developers over if it looks like it's impossible to create an F# web project in Visual Studio. Faster compilerThe F# compiler is, unfortunately, slow. Whenever I'm back in a C# project, I'm surprised at how fast I can compile a much larger code base. The slow compilation time hurts many development processes, e.g. Red/Green/Refactor, which should be faster than 10 seconds. In my experience, it's impossible to keep the cycle time under 10 seconds on a moderately-sized F# code base, because compilation alone can take 4-6 seconds. Oh, and while we're talking about compilers, I'd like to downvote 👎 @rodrigovidal's suggestion for a multi-pass compiler (sorry, nothing personal). The single-pass compiler is F#'s most precious asset. |
|
I have to agree with @lefthandedgoat marketing and evangelism is the key. I'm also interested in Elixir and the way that they are engaging Ruby devs, amongst others, shows us the way F# needs to go. |
👍 For |
|
Awesome discussion. Language
Compiler and build
Visual F# Tools:
Upstack frameworks and tools (Web, Cloud, Client, Data, Data Science, Build, Test, ...)
|
|
@ploeh Hey Mark, I really like F# single-pass compiler, I do know it's value. But I really think that it's something that harm's adoption. As far as I undestand, Kevin asked about what could drive adoption, not what I would like F# to be. (That would be lots of language features like typeclasses but it wouldn't drive adoption). F# is the only language I know that has this feature, and it's very annoying when you are a beginner. That's one of the main complaint I have been listening from C# developers over years. Maybe I'm wrong. :) |
|
I also think you need 2 strategies for 2 different types of developers. Two is probably an oversimplification. Group 1 is the current .Net and C# developer. They need MS to give blessing. Its pretty much as simple as that. Group 2 is the non MS Stack developer, data scientist, academics, and young people. For that you need awesome *nix experience. |
|
@mark I know what you mean with the Web remarks, but suave.io is working Cheers, Steffen
|
|
+1 for the single pass compiler. makes it feel like a language from the 70s. |
|
+1 on Removing the reliance on msbuild files, I hate thats stuff, its a common theme with the people I talk to as well.
|
|
By an amazing coincidence I just did a Twitter poll on exactly this.
Although my poll was a little mischievous, it does give us some almost-facts to work with. You'll note that 44% of resistance appears to be pretty much irrational. It's certainly my experience that there are groups of people out there who will actively sabotage F# projects. I think the only way this will end is if Microsoft starts making more public pronouncements in favour of F#. The open source effort for F# is utterly magnificent, but in the corporate mind this is still trumped by lack of MS buy-in. Next up we have 'seen as too hard' (34%). I have definitely encountered truly talented developers who simply can't get productive with F#. Perhaps the technical fix is for the community to make a huge effort to extend the range of quality templates. There is an immense amount of quality training material out there but more can do no harm. I do have a book idea to address this if anyone out there wants to chuck me some budget. ;-) Only a fifth of people thought that technical limitations and tooling are the main reason for resistance. So we shouldn't hope for too much here. That said, I would LOVE to see go-to-definition and find-references work between C# and F#. Every time someone asks for this it seems to fall into a political hole between the Visual F# Team, the Visual Studio Team and the Community. But solving it would make the biggest dent in that 22% in my opinion. |
|
By that same logic we should add more curly braces to the language. ;-)
|
|
+1 for evangelism Your average corporate .NET dev will adopt F# when they get paid to. Many are not enthusiasts and don't have the time or inclination to learn anything outside of the 9-5. They're not waiting for that final language or tooling feature to drop before considering it. |
|
@forki I think that's too far. :P |
|
@gsobocinski Elixir was designed to be ruby friendly. And it's stealing developers mostly from the ruby community. Which community we are aiming if any? @dsyme |
|
I know I sound like a broken record on this, and people generally disagree with me there, but from my limited perspective and in my environment, one of the biggest roadblocks for F# adoption will be something largely beyond the F# community's control - missing support in IDE tooling, primarily in widely used third-party software like ReSharper or OzCode. The reason is simple: Initial F# adoption in .NET shops will very often start with single F# projects in larger solutions dominated by C#. The everyday workflow in C# is aided greatly by the available tooling, and when there suddenly are parts of the code that tooling doesn't cover or even know, that causes friction. When someone renames a symbol as they are used to, and then find that the code doesn't compile anymore because that change didn't get into the part written in a different language that one person in the team insisted on starting to use, it's likely not going to make them view F# any more positively, because it even disrupts their work elsewhere. Yes, it's sad, because the most important thing should be the qualities of the language itself, but .NET development at large is a very tooling-centric affair, and for most people C# and the existing tooling are "good enough" and relatively low-friction, so F# will have a very hard time getting into many places without even rudimentary ReSharper support (say, at least not being blind to F# code for "find references" and renaming). As for VFPT becoming a part of VFT - yes, it would be great to have all that "out of the box" with Visual Studio, but considering the pace of of the Power Tools and the relatively long release cycles of VFT, that might keep great new features out of people's hands for longer than we are used to having to wait. |
Getting people to try at all
I find it interesting that Scala much more often is acceptable even though it, to me, is a pretty messy language. Maybe it is because Java is that much worse than C#? When they do try
|
|
@rodrigovidal Elixir took a lot from many languages. What I think they've done well is too publicise and promote real examples of using Elixir over say Ruby. What hits home for people is relating it back to something they know and have had experience with. There are lots of war stories with Ruby dev which always get addressed when comparing the two making the decision easier. If we could the same with F# and say C# that would help alot. I think what the guys at jet.com are putting out there is definitely the way to go. Real world examples with proven results. Kind of makes it hard to disagree with. |
|
Equality: when F# was first included in VS it was installed by default, it was going to be a first-class .NET language, things looked great. It's very clear now that this was never really the case. It isn't a first-class language, it's not installed by default, the tooling isn't as good, and Microsoft don't even talk about it. And it gets left out of the fun: ASP.NET vNext is all C# C# C#. Okay so I don't like MVC as a model for web programming anyway, it's a terrible fit, but if you want to lure .NET developers over you need them to be able to make an MVC project entirely in F# or they won't think it's a real language. Likewise we need to be able to make pure-F# Universal Windows Platform apps. Out of the box. Previously I would have said WPF (it always frustrated me that I couldn't do that when I was a WPF developer) but it's probably a bit late for WPF now! So we need the new build system for ASP.NET 5 to be able to handle F#, and for the tooling to support pure F# projects in this framework. Even though we know Suave is a better fit. This also applies to developer comms, blog posts about new tech etc. - some of this content should just be in F#. Make it look normal. Start writing chunks of Office in it, or whatever giant .NET projects Microsoft has internally. Tell the world that Azure Logic Apps are powered by F# (I don't know whether they are or not, but it'd be neat if they were). Talk about design patterns in functional languages. Then step beyond equality as everyone realises C# is the last gasp of the old guard before the new(yet still old) comes in. Evangelism: It's all C# and TypeScript that we hear about from Microsoft these days, yet they're sitting on a language that is better than both of them for both purposes! Interoperability: There are some dodgy points in getting C# to talk to F# libraries. If that could be smoothed out somehow it would really help get some F# code into existing C# projects. Tooling: The F# experience in Visual Studio is nothing like C#, even if you discount the influence of third-party tools like ReSharper, which is almost ubiquitous. While it's sad that ReSharper have never felt it necessary to add F# support, Microsoft could put more effort into the F# coding experience, and get it up to par with the out of the box C# experience, which is encroaching further on the classic ReSharper territory every release. Error highlighting needs to be better too - it frequently doesn't seem to be able to pinpoint the source of a problem and just splats wiggly underlines everywhere which is very unhelpful. Everyone, every single language, needs to look at Elm's error messages for the idea of what a compiler can do these days. And Elm shares heritage with F# and uses Hindley-Milner types and type inference, so surely F# could gain some of its diagnostic capabilities. Performance: Okay so obviously the compiler is working harder to compile F#, all that complicated type inference etc. is what sets F# apart from C# and also makes it slower to build. But if it could be made faster - and surely there are ways to do that - it would help a lot with developers feeling productive. Similarly, the VS tooling needs to be fast. It's too slow doing its overly broad error marking and then removing them when an expression I was halfway through writing is now complete and typechecks properly. |
|
Regarding Tooling, one possible solution would be to include the existing PowerTools as a Third-Party Product in the Visual Studio Setup, similar to the Powershell-Tools. I think for most existing .Net shops, the most likely point of introduction would be one developer liking F# and trying to integrate it into an existing product. For F# to be accepted by the other developers, you need great interop from C# to F#. Getting started with F#: One great example is here: You have some foreign looking code in F#, but even just looking at the code, it is more or less obvious if you know your math. |
|
|
@battisti it's not working with F# atm ( but will soon ), something like http://dotnet.github.io/getting-started/ is a simple experience you think it's ok? |
|
or as usually an amazing work from @7sharp9 , http://7sharpnine.com/Xebec/ |
|
@enricosada yes thanks the
workflow looks nice (also the generated files look good, assuming that it is reasonably easy and documented on how to add unit test etc.) BUT the current version terminates with a: when calling
Xebec does look amazing (like Cargo for F#)! |
|
Yes there are really good reasons to split paket.dependencies and Regarding projectscaffold. Yes the build script is large because it really Regarding fsproj files. Yes that's super annoying. Many people tried to
|
|
@forki if it's possible to fix For example development-dependencies are going to be merged soon And Bonus point, project.json give us xproj in visual studio, a common project system for both c# and f#, so less problems. {
"version": "1.0.0-*",
"dependencies": {
"Microsoft.FSharp.Core.netcore": "1.0.0-alpha-151221",
"System.Runtime": "4.0.21-beta-23428",
"System.Console": "4.0.0-beta-23428"
},
"compilerName": "fsc",
"compileFiles": [
"Helper2.fs",
"Helper.fs"
],
"frameworks": {
"dnxcore50": { }
}
}problem is always restore, source files, and compiler args. the rest is fsc al the way down |
|
@battisti just run the |
|
I know that dotnetcli is a way out, I hope they hear our feedback.
|
|
I have no idea how the new coreclr works or how the correct target gets used for the dnx stuff. The idea behind xebec is to make things easier rather than the complicated mess that exists in proj files. First support will be for vscode, atom, and emacs, and that's right after command line support for building, running and testing etc.
|
|
The quality of the Ionide plugin (version 1.2) with VS Code on OS X using Mono 4.2 stable (using the package installer, not homebrew) improved a lot. It is now usable out of the box and the debugger works (most of the time). The fsproj files are still annoying though. |
|
I don't understand the desire for templates as a way to improve things. I've never been in the habit of using any kind of project template and always see the need for them as a failing of the language, framework, or ecosystem in general. One of the things I've been appreciating about F# is how expressive yet concise code can be. An example is canopy, no real reason from what I can see to have canopy templates because the API/DSL exposed is exactly what you need to write and nothing more. My hangup has been msbuild/.fsproj baggage and the single pass compiler. I'd prefer the Node.JS experience in terms of lightweight projects that can consist of only dependencies, language/tooling constraints, and code in a nice digestible text based format (preferably code itself such as with Fake). I think these things should lower the barrier to great IDE and editor support because it doesn't not lean so heavily on an IDE support for ordering of files in a project and to add remove dependencies. On a slightly related note, I really like what Rust is doing with Cargo and was excited to see similar things coming to .NET Core but unfortunately that stuff was recently announced as something that will be retired before 1.0. At this point I'm starting to question what advantages I really have building off of the existing .NET framework, F# and .NET Core are the main things keeping me interested but I'm finding that TypeScript, Node.JS, npm is quite a reasonable alternative without the baggage. Anything that moves F# toward lightweight and flexible tooling will keep me interested and the inverse is also true. |
|
@jpierson Have a look at paket manager - particularly v3 (currently in alpha) which can generate dependency scripts to reference all nuget packages as well as all the other goodies like nuget package dependencies, github dependencies etc.. FWIW I agree that lightweight tooling with emphasis on code first is the way to go. Not sure I would want to lose built-in prevention of cyclical dependencies but getting rid of the heavyweight .fsproj yes. |
|
@jpierson just on this matter:
There are many aspects regarding this kind of concern, I also am better with lean project, empty template but in context of driving adoption within .net eco-system, anything which is available to C# and VB.NET but for some reason is not available to F# (despite, in the grand scheme it wouldn't cost so much to have it implemented), such as winforms & WPF designers, project templates for MS frameworks, all which is related to IDE tooling, etc. is a significant hinderance toward getting F# being adopted. My experience with the language is short but I faced this big time already, people tend to get iffy when they see this MS language but at the same time, the support is not as "first class" as with C# and VB.NET. Outside of .net land, I mostly agree with all you bring 😄 |
|
Closing as we have a Part 2, Part 3 and Part 4 to this discussion. |
|
The reason I don't use F#
|
|
Many of us are on github, slack, Twitter,... We do exist |
|
Yeah...heard the same argument about Jesus ;) What I mean is, if you have system written in F# and go look for a consultant or an employee to hire, would you find any? |
|
@Bartolomeus-649 you can google "f# consultancy" and you'll get some results (and even "F# Azure Consultancy" if you feel really dangerous ;-)). Seriously though, the points you make are all very common ones so you're not unusual there. In my upcoming book I discuss basically all of these issues and concerns. In short: -
|
|
@isaacabraham , none of those arguments will make me use F#. The next time my customer want something, I will need to provide a solution that is better than my competitors, else I will not be doing any coding at all. And if I would present a solution based on F#, I would not get the job. Also the cost for a C# solution would be higher than one for C# since either would I need to spend my own time learning F# or I would need to get the customer to pay for the extra time needed for me to learn enough about F# within the project. The only way to get F# of the ground is for Microsoft to present a nish use for F# where it clearly outperform other languages like C# and VB.NET. And then there need to be an F# extension for C#, so you could just do some F# stuff with C#, so people will start to understand what F# is all about without switching to F#. If possible, F# should be just merged in with the next version of C#. |
|
@Bartolomeus-649 I can only speak from my own experience. We use F# because it gives us (and our customers) a competitive advantage as we can deliver reliable, performant and maintainable solutions more quickly and cheaply than we would with other languages. YMMV. The "why not just use C#" argument goes back to my point regarding C#2 vs C#3. And you can't merge F# into C# - have a look at the C# language repo and witness all the crazy ideas of how some of that would look for a start. But more than that - F# and C# have very, very different goals and ways of doing things. If you just took the ideas of F# and put them into C#, you'd end up with a crazy, crazy language with no clear identity (not to mention many F# features would be massive breaking changes in F#). You're free to use whatever language you feel like. I'd suggest you at least have a crack at F# though - you might find it dispels some of the FUD you might've been exposed to previously. |
|
I sincerely hope my competitors stick with java/C# - and more importantly,
continue using the same mindset that keeps them there....
…On Sun, Apr 30, 2017 at 8:46 AM, Isaac Abraham ***@***.***> wrote:
@Bartolomeus-649 <https://github.com/Bartolomeus-649> I can only speak
from my own experience. We use F# because it gives us (and our customers) a
competitive advantage as we can deliver reliable, performant and
maintainable solutions more quickly and cheaply than we would with other
languages. YMMV. The "why not just use C#" argument goes back to my point
regarding C#2 vs C#3.
And you can't merge F# into C# - have a look at the C# language repo and
witness all the crazy ideas of how some of that would look for a start. But
more than that - F# and C# have very, very different goals and ways of
doing things. If you just took the ideas of F# and put them into C#, you'd
end up with a crazy, crazy language with no clear identity (not to mention
many F# features would be massive breaking changes in F#).
You're free to use whatever language you feel like. I'd suggest you at
least have a crack at F# though - you might find it dispels some of the FUD
you might've been exposed to previously.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#798 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABVH1LUCF_whJ_Oz7qS5S9p_lNm8HKxCks5r1IKsgaJpZM4G2wxq>
.
|
|
@jamessdixon So why this thread about driving F# adoption? |
|
If you are not my competitor, have at it. In fact, I am happy to help you.
:-)
…On Sun, Apr 30, 2017 at 8:52 AM, Bartolomeus-649 ***@***.***> wrote:
@jamessdixon <https://github.com/jamessdixon> So why this thread about
driving F# adoption?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#798 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABVH1IFppns3Kku6z7YtZssA7d5U2R6kks5r1IQVgaJpZM4G2wxq>
.
|
Easy, just advertise for one: http://blog.ploeh.dk/2015/12/03/the-rules-of-attraction-language |
Many people here try to present something that works and has fewer bugs and has short time to market. Sometimes that happens to be written in F#. The advantage is often there but if you think differently or want to ignore it then this is fine. I won't force you to do F#. At least as long as you are not part of my team. |
|
Locking, as the conversation is closed and has drifted far from ways to increase F# adoption. |
and others
F# is great programming language and yet it is under utilized. I would like to understand what you the enthusiast F# developer believes are the top four things we can do to drive adoption: As a developer I believe they are features, if someone has already suggested your top thing, repeat it in your list anyway.
Please keep discussion to a minimum for this exercise. We can discus the results elsewhere, later. I just want to get a feel for everyone people thinks.
The text was updated successfully, but these errors were encountered: