Live data from Hacker News

F# is gaining independence from .NET

onurgumus.github.io

101–110 of 181 posts

Re: F# is gaining independence from .NET

#101
post #55
post #32

Earlier quoted context omitted.

In an F# project file (and thus also in all editor support), the referenced F# source files have an order. Files can only see types, values etc defined in files above them (and the same within files, with some caveats). This sounds really weird and annoying but turns out to have some surprising benefits (because it limits the mental/real search space for definitions as well). In practice it's just something that is s…

That is pretty nice for testing, since it removes the need for depency injection, or am i mistaken?

All DI libraries can be ripped out and replaced with a bog standard main method, and it doesn't even require much skill. Most of what it's doing for you is stuff like "foo = new Foo(); bar = new Bar(foo, 33);" So there's no strict "need" for them, they help with (and enable) complexity.

What F#'s aversion to cyclic dependencies does forces you to break cycles of types referring to types referring to types. The way you do that is by writing a generic function that avoids referring to a concrete type. Because it's generic, such a function is inherently easier to test by means of a simple stub value.

Re: F# is gaining independence from .NET

#102
post #55
post #32

Earlier quoted context omitted.

In an F# project file (and thus also in all editor support), the referenced F# source files have an order. Files can only see types, values etc defined in files above them (and the same within files, with some caveats). This sounds really weird and annoying but turns out to have some surprising benefits (because it limits the mental/real search space for definitions as well). In practice it's just something that is s…

That is pretty nice for testing, since it removes the need for depency injection, or am i mistaken?

Not really. There are various DI patterns you can use in F# [1], but the combination of no cyclic dependencies + type inference does mean you can just do the simplest thing - pass dependencies manually as specific arguments - and it will stay manageable for much longer than in java/c#.

Evil dangerous code using global variables:

   let mail = // .. create email service
   let db = // .. create database service

   let receiveThing thing = async {
      let query = // .. compose update query
      do! saveToDb db query
      let emailText = // .. compose email
      do! sendMail mail emailText
   }

   while readInput() do receiveThing (getThing())
Beautiful pure code using dependency injection:

   let mail = // .. create email service
   let db = // .. create database service

   let receiveThing db mail thing = async {
      let query = // .. compose update query
      do! saveToDb db query
      let emailText = // .. compose email
      do! sendMail mail emailText
   }

   while readInput() do receiveThing db mail (getThing())

[1] https://fsharpforfunandprofit.com/posts/dependencies/

Re: F# is gaining independence from .NET

#103
post #44

If F# ever got something akin to Scala Native, or Kotlin Native, I think it'd do really well. In my limited understanding of the F# ecosystem, I don't believe there are a lot of voices calling towards a multiplatform future beyond the NET world. Fable is cool, but native is a must-have for a lot of people, myself included. The docs are bad but not inexcusably so, it's a nice project within MS, I get it. The underlyin…

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).

In the same way that Objective-C is just C++ for Macs. They share a common lineage, but do so many things so differently that you really can't consider them to be all that similar. And the difference starts with having completely different object systems.

Beyond different OOP mechanisms, some things OCaml has that F# doesn't:

  - Functors
  - Polymorphic variants
  - camlp4
And some things F# has that OCaml doesn't:

  - Computation expressions
  - Type providers
  - Quotations (as a built-in)
  - Units of measure
  - Active patterns

Re: F# is gaining independence from .NET

#104
post #86

Earlier quoted context omitted.

.NET has native ahead-of-time compile options that are getting better all the time. F# actually works better with these tools than other .NET languages because it is less reliant on reflection etc. to build its abstractions. You can write C bindings for F# libraries compiled this way.

I've toyed around on a weekend or two looking at the different ways to AOT stuffs for F#. Here is what I found: Same hello-world console app from C# runs alright with AOT. The F# does not as it relies on heavier reflection stuffs (at least thats what it seems like). The F# version did compile but just crashed on run. The suspect appears to be the way to console print seems to call a different non AOT function. The in…

That is a well known issue, also what prevented F# to be properly used in .NET Native.

https://github.com/dotnet/corert/issues/5780#issuecomment-40...

Re: F# is gaining independence from .NET

#105
post #100

Earlier quoted context omitted.

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.

C# also keeps copying Java stuff to this day like default interface methods.

In fact, having had spent most of my focus across Java, .NET and C++ since their early days, it is quite interesting to follow how certain features keep being copied across them.

Re: F# is gaining independence from .NET

#106
post #56

Are there any startups or companies using F# in production?

Jet did, but they're now dead...or do they still live on inside of the greater Walmart (Labs?) organization?

Their F# projects under github.com/jet are still active at least. The main contributor/s appear to just have 'Walmart Labs' in their profile now.

Re: F# is gaining independence from .NET

#107
post #12

Earlier quoted context omitted.

It's a real shame, but not unexpected. The vast majority of programmers I meet in the wild simply do not have training in FP and by the time they decide to learn it (if they do), it's hard to unlearn "traditional" thinking. If we want to steer programming in that direction, we should teach functional programming before "traditional" programming. However, even if we manage to do that I'm not convinced that it will mak…

I'm a long-time Emacs user, Scheme fan, functional programming advocate ... Who uses C# in his day job. For quite a long time F# simply wasn't ready, and by the time it was C# had already become an industry behemoth. But more critically, it's not a language that's officially supported by Unity. That's enough for it not to be a wise choice to be betting a project on it where there are dozens of jobs on the line, and f…

Sitecore, SharePoint, all the GUI designers for Forms, WPF, UWP, WinUI, EF (Core), WCF, gRPC, upcoming Code Generators.

Re: F# is gaining independence from .NET

#108
post #3

The love for F# is justified because it's really a clean language with a well-defined core library. The one bad thing about it is that the documentation is really insufficient and confusing to people who don't already know .NET. If this improves it will definitely be welcome be more devs and companies.

I've spent the past 3 months or so working with F# with zero .net experience - I love the language alot but yeah, you will eventually end up learning C# (not that that's a bad thing) if you want to use its extensive and powerful ecosystem. If you look at the MS documentation for .net, none of the examples are in F#. I guess that's okay since it probably wouldn't be idiomatic F#... but still, the docs have examples in…

Similar experience with Clojure, as well, one needs to know java to be reasonably productive with it.

Re: F# is gaining independence from .NET

#109

> 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.

I guess they don't. It's my mistake and I have just fixed it.

Re: F# is gaining independence from .NET

#110
post #75

>"You have to embrace functional programming as a paradigm." Why would I embrace/commit to any particular paradigms? I would use whatever I believe is best suitable for particular task. All those are just tools like a screwdriver. They're here to work for us, not the other way around.

Sure, but functional programming requires some discipline and restrictions for a greater good. It's certainly a choice though.
Post reply on HN