Hacker News Reader

Comment by breatheoften | Hacker News Reader

F# looks like a great language... A friend of mine who is a non-programmer DBA just reached out to me and asked about recommendations for learning .NET ...

I've not seen anything as elegant looking as F# in the .net world before ... What do people think ... -- is F# a good language for a beginner to learn which is also sufficiently well-supported that they could find themselves building useful script-like database (MSSQL) oriented utilities as early project ...?

View on HN

F# has tended to lag far behind C# in Microsoft's ecosystem. I haven't kept up with in a few years, so I don't know how far behind it still is. It is a fun language for sure.

If your friend is looking into getting into .net for professional purposes, I would steer them towards C# first. That's likely to be much more useful in the long term. Especially since it can be a stepping stone to other C/C++ like languages.

With F# I would bet that they hit some limitation sooner or later where something that could be easily done in C# will take more work in F#. Which could be fine if they have the time/inclination to rough it. I just would not advise F# as a resume builder.

While I fully agree with F# being the step child of C#, an easy way to see what’s better is how many features get copied from which language to the other (hint: C# is like China copying tech from F#).

Start with F#. Learn the basics well.

Parent - Checkout

https://fsharpforfunandprofit.com/

https://docs.microsoft.com/en-us/dotnet/fsharp/introduction-...

>With F# I would bet that they hit some limitation sooner or later where something that could be easily done in C# will take more work in F#.

From my experience of working with both C# and F# for a few years, it's more likely to be the other way around.

F# lacks the Visual Studio tooling support that VB.NET, C# and even C++ enjoy.

It is also not officially supported on UWP, and needs some hacks to the generated MSIL (as .NET Native doesn't cover 100% of all MSIL).

Most of the F# community seems to be using Ionide on VS Code. This works very well, but if Visual Studio is your preferred editor this can be annoying.

IDE support is much more than just editing text.

For example, try to generate EF 6 Database First code for F#, or use Blend alongside Visual Studio with F#.

Ionide gives you IDE features like type annotations and auto-complete.

Completely ignored my use cases.

I was responding to:

> IDE support is much more than just editing text.

In case anyone reading this thread comes away thinking that VS Code + Ionide is only a text editor.

The support for F# in VS leaves a lot to desire, indeed. However, in my experience, I've found that the developer productivity gains from F# outweigh the inconvenience.

Only if what you are doing is directly supported by F#.

If you attempt to do GUI development, then you are forced to look for community projects like Fabulous, use the XAML type provider with a dummy C#,VB.NET,C++/CLI project for the XAML generation, or actually use one of those languages for the UI, with F# used only for the logic.

So even though I am a big fan of ML language family, at the end of the day, the other .NET languages get the green light from most customers and team.

I don't recall having too much difficulty getting the VS WPF XAML Designer to basically function with F#. Some features just don't light up like event connecting/code-behind, but that's fine and what I wanted anyway (taking an MVVM-ish approach).

There's a hope that with F#'s upcoming move to the "shared project system" that a lot of the pains will go away in hopefully the near future.

(That said, Fabulous has piqued my interest and I'm debating rewriting my big F# GUI in it, at least in an exploratory branch.)

Meh - recently worked on a huge corporate solution where some enthusiastic person included F# projects for tests- soon the project readme included : To get VS intellisense working disable the F# projects as it would randomly cause intellisense to break in the entire solution.

There was an issue with the C# tooling about 3 years ago that led to this, but it was fixed in the subsequent VS update.

Had this problem one year ago using VS 2017 and up-to-date software (along with the rest of the team, VS 2019 wasn't stable yet don't know if it's fixed there).

First I'd recommend upgrading to VS 2019, because you're currently missing ~1.5 years' worth of improvements in C# and F# tooling (core development for VS 2017 stopped well before the VS 15.9 release to stabilize it). If it still reproduces, then please use the Report a Problem tool to file an issue. The team who builds C# tooling would be interested in fixing that kind of problem.

Oh for sure - I'm not using .NET/VS anymore different clients and all, and I think the team stripped out the F# tests out of the solution - just saying it couldn't have been the thing fixed 3 years ago.

No, just point them at C# so they will actually be able to find answers to problems they run into with Google/StackOverflow.

C# is actually a pretty good language. It has functional features, even if not as extensive as F#, and has an OO system that is much more well thought out than Java.

If functional is what is needed, and C# is your only option, then this will help [1]

Disclaimer: I'm the author

[1] https://github.com/louthy/language-ext/

Given that C# and Java have copied features from each other throughout the years, and as someone that uses both stacks since their introduction, I wonder what well thought OO features does C# have that Java lacks.

It’s just cleaner and less verbose; eg interfaces can be implemented privately outside of the class namespace, generics are reified, etc... But then there are things like Extension methods, for example, which are incredibly useful.

Generics being reified are a CLR feature available to any .NET language (which Java in the form of J# could take advantage of [0]), don't have anything to do with C# OOP model per se, and were an impediment to properly implement Scala.NET.

This will be fixed on Java side, with value specializations as per Valhala roadmap.

Extension methods are also a way to create lots of spaghetti code, trying to track down where the method is actually implemented.

Swift and Kotlin codebases are good examples on how one can go a bit too far with extension methods.

Java's solution is to offer default interface methods as an approach to traits, which was copied by C# 8.

Regarding interfaces, if you mean explicit interface implementations, besides forcing casts everywhere I don't see what is so well thought out about them.

[0] - https://docs.microsoft.com/en-us/archive/blogs/gauravseth/cu...

Generics being reified in the CLR are entirely biased to C# (and vice versa), which is exactly why they impeded scala.net. They were simply designed for each other.

Extensions methods are great, tracking down the methods that you are calling is super easy in an IDE. The ability to abstract over generic type parameters as well as class subtype is very useful.

Default interface implementations have no connection to extension methods, they solve different problems.

Explicit method implementations are great at avoiding name collisions as well as accidental ones. The coercions needed are not hard casts, though C# could do be improved with a soft cast operator.

CLR is called Common Language Runtime and not C# Language Runtime.

In fact, C++/CLI is the only Microsoft language that has full access to all CLR features, not C#.

A language that has a much more expressive OO model than either Java or C#, and requires reiffed generics.

IDEs don't work in code review workflows.

For all intensive purposes, the CLR evolves with C# in lockstep. Multi language might have been a goal at one time, but isn’t really anymore. No one really uses C++ CLI.

> IDEs don't work in code review workflows.

Use or make better tools.

You should come out from your Ivory tower.

Thousands of developers use F#, VB.NET, Powershell, C++/CLI every day, and to lesser extent Cobol and Fortran compilers for .NET.

C++/CLI support was a must have requirement for .NET Core adoption, not only because of externals, because all .NET UI Frameworks make use of C++/CLI.

So much for no one really uses.

We use the tools our customers are willing to pay for.

Care to provide a link to a code review tool with IDE like capabilities for code navigation?

Valhalla won't solve all issues with erased generics in Java. In C# "static T foo;" is a valid declaration that creates a separate "foo" for each specialized class.

Only if T is a value type, reference types share implementations.

The final semantics for specialized value types are not yet set in stone, so what Java might end up supporting is still a guessing game.

> eg interfaces can be implemented privately outside of the class namespace

Not sure what you're referring to here (you can implement interfaces of other packages in Java), but everything else you mentioned is not related to C#/Java's OO system.

A beginner could learn F# and lean on the .net libraries for any business needs.

If he wants to learn .NET, he should start with C# and then looked into the Framework and if he is particularly ambitious - the IL, etc. But I'm guessing he doesn't want to learn ".NET" but rather programming against MSSQL if he is a DBA. C# is easily the most mature language in this domain.

Also, since he is a DBA, he could be introduced to ".NET" via powershell as microsoft has been trying to make powershell the default IT/DBA shell for the windows world. It's like bash for windows but entirely object driven.

Reply on news.ycombinator.com