Comment by JaggerJo | Hacker News Reader

Comment by JaggerJo | Hacker News Reader

I think you should give F# a shot instead.

1. No standard and easy way of implementing interfaces

No problem in F#, you have interfaces, abstract classed, ...

2. Bad standard library

In F# you have access to the full .NET standard library and ecosystem. There are also quite a lot of libraries that are especially designed to take advantage of F# (SQL libs for example).

3. Syntax problems

3.1 OCaml doesn’t have a single-line comment syntax.

It's `//` for single line and `(* comment *)` for n line comments in F#.

3.2 It has for and while, but no break and continue. So you use exceptions with a try inside the loop for continue, and outside for break.

Same in F#, use recursion.

Generally F# solves some of the issues but definitely not all of them. Some are just in the nature of the Standard ML syntax I guess.

4. Rest of the package is also not that good

- NuGet is a decent/good package manager. - Easy to install a complete dev env. - sane build system (MSBuild) - Great out of the box support in JetBrains Rider/ Visual Studio (for Mac/ Windows) or via a VS Code plugin (Ionide).

I use F# at work. Really love the language but the connection to the dotnet ecosystem is a curse as much as a blessing. Having to operate in a world of nulls and exceptions can reduce/nullify the amazing benefits of discriminated unions. Often you are back to relying on the due dilligence of other developers as a result.

I use a lot of rust in my spare time. The runtime guarantees it offers make other languages feel like a house of cards in comparison, including F#. I coincidentally picked up an ocaml book yesterday seeking a more 'robust' alternative to F#. Unfortunately it seems as though ocaml is even more niche than F# (I doubt I'll be working for jane street any time soon)

> Having to operate in a world of nulls and exceptions can reduce/nullify the amazing benefits of discriminated unions.

I've been saying this about Kotlin on the JVM for ages. Using a Java dependency is an absolute last resort for me for those same reasons you mention about .NET from F#.

The C# compiler got a ton of new smarts around reference type nullability and almost all of the BCL (.NET standard library) got annotated for it. I don't know when F# will finally pick up all the new compile-time smarts for Nullable Reference Types, but it has been proposed and prototyped, at least [1].

[1] https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-10...

F# is such a great language.

The fact Microsoft seems to pretend it doesn't exist is bewildering. Surely the .Net ecosystem can have two languages being promoted.

Before F# came into VS 2010, we already had C#, VB, C++/CLI (nee Managed C++), IronPython, IronRuby, and all the third parties targeting the CLR.

It is really not having a clue what purpose they want for F#, I bet they have repented to ship it on VS2010.

First it was for libraries only, then during the VS Express days it was for Web development, now they are trying to pivot it into data analysis and ML, while DevDiv manages to bring Guido out of retirement and finally manages to pursuade CPython core team about improving its performance.

F# was originally just kind of a passion project that MS insisted get productized to continue development. It's still very much an internal favorite within Microsoft Research and the Bing team, from my understanding.

Nowadays most of those folks are no longer at MSR, Don Syme has moved into Github and I doubt they are into F#.

Don is still working on F#. The F# team at MS now is bigger than is was years ago. People from different companies and the community are collaborating on compiler and language features.

F# is beyond microsoft, a lot of early adopters are still there.

Stand corrected on that one.

What are the fruits of that increased team on the VS, VS4Mac and VSCode tooling, and .NET SDKs?

> F# is such a great language.

I very much feel this, I found it productive, but it feels like a complete ghost town. I'm considering swapping to Go over using .NET for tooling/scripting.

Really? Were you active in the slack/discord channels?

I was poking around https://forums.fsharp.org/ and https://www.reddit.com/r/fsharp/

Wanted to add my experience here: after writing C# code most of my professional life, F# is a breath of fresh air. The type system makes so many issues and annoyances I've lived with in C# just disappear. Much like Rust, the compiler is capable of providing so much more value when the type system is so expressive. You can bang out a lot of code quite quickly and be pretty darn sure it will work just because it compiles.

I really wish to like F# but the line noise kills me every time. I would kill for a "visual basic" f# where the absurd terseness is replaced with a little less noise. E.g. instead of seq use sequence, instead of abstract one letter symbols use words.

what noise?

I get your example of ‘seq { 1; 2; 3; }’ but list, array are not even shortened.

Sorry, I literally forgot them. A lookup here refreshed my memory: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

This is my exact issue with many "modern" languages. The code is not meant to be read later.

Perhaps you mean mix a little more noise into the dense signal? There's very little noise in F#, it's almost entirely dense signal.

One good thing is the ability to bind new operators, so if you don't care to learn to read <> you could make it something else. Or you could have a local binding for Sequence so you don't have to use just Seq.

It's also possible to avoid almost all operators if you don't like them. There's nothing wrong with using a limited pool as long as you can get done the job!

I also prefer to name variables, functions, and parameters with nice clear names, and I've not found F# to get in the way of that.

> NuGet is a decent/good package manager

I remember F# designed its own package manager (paket) because of NuGet's deficiencies. I haven't been on that ecosystem for a while now. Have things changed? (My memory is that paket added friction and I eventually dropped it for nuget on my personal projects).

F# has largely moved back to PackageReference, since package versions can now be managed centrally across projects, and F# scripts can now reference NuGet dependencies directly.

I don't want to trust anything made by the Embrace, Extend, Extinguish company.

Reply on news.ycombinator.com