Live data from Hacker News

F# is gaining independence from .NET

onurgumus.github.io

91–100 of 181 posts

Re: F# is gaining independence from .NET

#91
post #9
post #6

I'm learning F# now. The language is nice but pulling dependencies into the interactive shell is proving difficult. After a few attempts I found I could use #r to pull in dependencies. Then I found where the NuGet packages were hiding in my home dir. Finally I could reference the Fsharp.Data.dll! Then XML type provider not found.... Frustrating when I just want to play around.

Cough : https://docs.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-... Should be a bit easier!

I've been using F# 5.0's new features with dotnet interactive notebooks and the experience, when working correctly, is pretty nice. Dotnet interactive notebooks still has some rough edges to smooth out (and it's currently only available to VS Code Insiders) but, eventually, I think the new syntax coupled with dotnet interactive notebooks will make it a lot easier for people to try out F# and work through some problems/examples.

Re: F# is gaining independence from .NET

#92
post #26

Earlier quoted context omitted.

It's.. not as nice. LINQ gets halfway, but, you end up getting back to procedural modeling soon. With sufficient discipline and structure, and liberal use of LINQ and lambdas, you can mostly get there, but it lacks the purity of pure functional.

But F# isn't a pure functional language, is it? https://www.google.com/search?q=is+f%23+a+pure+functional+la...

[deleted]

Re: F# is gaining independence from .NET

#93
post #61
post #57

Earlier quoted context omitted.

>functional messes are an order-of-magnitude worse than imperative/OO ones Why so?

IMHO it's tooling. The industry has spend decades to help you to deal with the kind of mess OO tends to produce. The tooling isn't anywhere close when you have to deal with a mess of functions returning functions that return functions.

> a mess of functions returning functions that return functions.

That is just a curried function with three arguments. The bigger problem is that programmers still have to understand how Hindley-Milner type inference works to figure out type errors. This gets worse when you add in type classes, dependent types and (Yog-Sothoth help you) lenses.

Your point is still true. For any language, it is important to have an IDE ecosystem in place. The tooling must enable developers to move beyond fighting the unruly or boring parts of the language and instead leverage it to work on the domain.

Re: F# is gaining independence from .NET

#95
post #78
post #76

Earlier quoted context omitted.

> Fable is cool Fable is a game changer and is arguably a better Typescript in terms of jacking into the javascript ecosystem. Ruby had Rails, Python had Django + Pandas..... F# has Fable

how is fable better than ts, could you elaborate?

Firstly you can share code with .net and JS side. Secondly, you can do proper functional programming with F#. Third I find type system typescript as cryptic.

Re: F# is gaining independence from .NET

#96
post #58

Earlier quoted context omitted.

> Even one of the best known and oldest F# library FParsec has it's high-performance parts in C# - that's telling. To be more specific, it has a C# library so it can use _unsafe {}_ blocks to perform manual memory management. This is one key performance-oriented feature that F# lacks. Other than that, you _can_ write F# that's about as fast as non-unsafe C#, although it means giving up most of the nicer and safer fea…

F# does a good job with tail-recursion, though - you can make the for/while loop safer this way. https://www.gresearch.co.uk/article/in-favour-of-recursive-f...

But it adds .tail prefix before every callvirt instruction and this breaks some JIT optimizations. E.g. generic type specialization 'if(typeof(T) == typeof(...))' breaks, I had to dig into compiler source code to find out that it doesn't add .tail before ctors, used a struct wrapper and called a method in the struct ctor to avoid .tail prefix, but it adds its own overhead.

Also, most simple tail calls are rewritten by a compiler to a loop, but if you look at the generated IL, there are multiple temp variables, locals, needless assignments. Maybe JIT is able to eliminate those, or maybe not... In C# I could get IL that reflects what I write, without surprises.

Re: F# is gaining independence from .NET

#98

Earlier quoted context omitted.

I think he means you have to write down a list of files in your project somewhere, but each file can only depend on files that come before it in the list. So the files with the fewest dependencies (e.g. utility type stuff) come first, and `main.fs` (or whatever) comes last.

You do it in the .fsproj. I wish Microsoft would add a warning to explain that, instead of just saying the modules can't be found. Really confused me for a good few hours.

My general feeling is that, if you can generate a warning that tells you the right thing to do, then the compiler should just do the right thing.

Re: F# is gaining independence from .NET

#99
> As you can see FSF offers mentorship programs

That made me blink.

And then I found out they meant the F# software foundation, not the Free software foundation.

It seems like a very obvious misunderstanding to make, and IMO they should avoid causing it by using another abbreviation than this one which is already very well established in programming circles.

Re: F# is gaining independence from .NET

#100
post #44

Earlier quoted context omitted.

Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks). For frontend dev't I really like Elm lately. (the article makes many refs to Elmish, the Elm-on-F# project).

similarly to how C# is very much java.net ??

This is a bit inappropriate since for a long time now Java was busy catching up to C#. When Project Valhalla merges, Java's type system will become very close to what C# is now: reified generics and first-class value types. Algebraic data types will also come to town. But only after Project Loom merges, Java will be firmly ahead again with a fresh take on all matters async.
Post reply on HN