Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

F# is gaining independence from .NET

onurgumus.github.io

Post reply on HN
Print view View original

61–70 of 181 posts

Re: F# is gaining independence from .NET

#61

Post by thomasz »

pydry wrote: post #57
DanielBMarkham wrote: post #49

"...If you are sold with F# there is one important point to highlight. Do not treat F#, just another language with different syntax especially if you are familiar with Python, Ruby, JavaScript, C#, etc. You have to embrace functional programming as a paradigm...." I want to provide a little nuance around this, because I'd give the opposite advice. Because F# is based on OCAML and an extremely popular IDE/framework, i…

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

Re: F# is gaining independence from .NET

#62

Post by Cederfjard »

adenozine wrote: post #50
cies wrote: 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).

Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.

Could you please elaborate on what you said about Elm and its author? How come?

Re: F# is gaining independence from .NET

#63

Post by sideeffffect »

lymitshn wrote: post #28
29athrowaway wrote: post #2

F# is a great language, but the .NET community never embraced it.

Yep, wish JVM had it too, and no Scala doesn't count.

Oh yes it does count. Scala can be a nice functional language, with a powerful module system.

Although I miss type providers, enforced lack of cycles and other nice things, like syntax:

https://contributors.scala-lang.org/t/scala-3-very-impressiv...

Re: F# is gaining independence from .NET

#64

Post by [deleted] »

Cederfjard wrote: post #62
adenozine wrote: post #50

Earlier quoted context omitted.

Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.

Could you please elaborate on what you said about Elm and its author? How come?

[deleted]

Re: F# is gaining independence from .NET

#65

Post by naringas »

cies wrote: post #44
adenozine wrote: post #30

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

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

Re: F# is gaining independence from .NET

#66

Post by JackMorgan »

yen223 wrote: post #56

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

I just left a team that was using F# as our language for all new code. We built shrinkwrap banking software and found it a much better alternative to C#. We were the market leaders in that space, most of the worlds big banks runs code we wrote in F#.

I think F# is an improvement to C# just like how C# was an improvement to VB.NET, which was an improvement to VB6.

However, it's not really a hill I'd die on, frankly new co-workers complaining about missing curly braces gets really old after the first day. Ultimately most programmers just don't care about using the best tools, and would still be happy using VB6 if the industry as a whole hadn't moved them along kicking and screaming into C#.

If I'm working alone, I'll choose the best tools for the job, and I tend to think F# in modern dotnet core is one of the best tools for backend servers out there. It's much more coherent then Scala, less mushy at large codebase size than Clojure, very performant, and has great libraries like aspnet core, and compiles so much faster than Haskell and has an incredible wealth of better libraries. I also prefer a more functional style than Kotlin, Go, Java, or C# provide, because for me that means fewer unit tests to get the same confidence.

There's plenty annoying with the language, but it's a great hybrid with reasonable tradeoffs.

My elevator pitch typically is: with F# I need to write fewer unit tests to get the same confidence I'd need elsewhere, and that means more time programming.

Re: F# is gaining independence from .NET

#67

Post by dfgdghdf »

adenozine wrote: post #30

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…

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

Re: F# is gaining independence from .NET

#68

Post by cies »

adenozine wrote: post #50
cies wrote: 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).

Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.

Works like a charm, and when the community tanks (what will most likely be due to the close access innovation model and the main authors behavior), then there is a project to convert Elm code to PureScript. :)

Re: F# is gaining independence from .NET

#69

Post by buybackoff »

piaste wrote: post #58
buybackoff wrote: post #48

Earlier quoted context omitted.

F# generates weird, verbose, opinionated IL code that is often JIT-unfriendly and rather focused on reference types. JIT is tailored to C# patterns and JIT is rather simple in .NET (e.g. vs JVM), so it's easy to break or miss some optimizations. Yes, it's not a fundamental limitation of the language itself. But considering the amount of hypothetical efforts required to fix all that vs investments from MSFT in F#, it…

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

> Inline functions are still fine though for writing zero-cost helpers, and I don't think C# has them (there's an attribute but IIRC it's just a hint, the compiler isn't required to actually obey).

In F#, you cannot disable inlining of small functions. It does IL source code inlining, like copy-paste, not machine code inlining. That increases generated dll/exe size a lot for generics. And sometimes you do not want to do that because it's worse for performance. There is an issue for that: https://github.com/fsharp/fslang-suggestions/issues/838

In C#, the AggressiveInlining attribute works well, in predictable manner. Non-inlineable cases are well known (`throw\switch\fixed\try..catch\calling delegates` and some more https://github.com/dotnet/runtime/blob/master/src/coreclr/ji...).

> because it supports directly inlining IL instructions intermixed with regular code

This works for very simple things only. And using InlineIL.Fody, Sigil, raw IL.Emit or just raw IL code as text is not that more difficult if you already know IL.

> you _can_ write F# that's about as fast as non-unsafe C#

I tried this several times. It always ends with fighting the compiler more than just rewriting in C#, even without the `unsafe` keyword. In most cases due to generated IL that I cannot control from F#.

Re: F# is gaining independence from .NET

#70

Post by adenozine »

Cederfjard wrote: post #62
adenozine wrote: post #50

Earlier quoted context omitted.

Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.

Could you please elaborate on what you said about Elm and its author? How come?

https://reasonablypolymorphic.com/blog/elm-is-wrong/

Here's a good starting place. Look for some discussions about typeclasses and read for yourself. Ask yourself if you'd bet on this person, and if you'd build critical tools for your org with a tool dictated by them.

I have no ill will for Elm. I'm grateful it exists and that we can all learn. I'd never invest in it though, it's too much a risk for things that could affect my ability to put food on the table quickly enough.

I'm not a frontend guy, so if some crazy frontend bug happened and crunched up my landing page or any of my forms, I'm not confident that I could debug it fast. I hate to say it, but honestly I think TS has to be the future of front end web. It's simply too solid to consider very many other options.

The one-man-running-the-show act kinda works for small things, like Tarsnap is a great example. But for languages that are powering business frontends, I can't have some goofball with a bad opinion holding up progress on something important.

Post reply on HN