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

81–90 of 181 posts

Re: F# is gaining independence from .NET

#81

Post by pjmlp »

chrisseaton wrote: post #79
pjmlp wrote: post #74

Earlier quoted context omitted.

Without the Visual Studio tools for GUI and database modeling, so it ends up being just usable for writing general purpose libraries. So, we just carry on using VB.NET, C# and C++ instead.

Isn't 'writing general purpose libraries' most programming? I think GUIs and database modelling are pretty niche.

Code isn't written in isolation unless we are speaking about programming interviews.

Libraries spring to life as reusable parts from large scale projects.

So the ROI of context switching to F# in the middle of a project, isn't that much if the language is reduced to expressing algorithms.

Re: F# is gaining independence from .NET

#82

Post by Zababa »

JaggerJo wrote: post #39

Complaining about bad docs isn’t really fair IMHO. Compared to Swift F# has excellent documentation. Would be interesting to know what F# is compared with in this case. Is there a language thats known for excellent docs ? One thing you can’t pass on when talking about fsharp in the community. If you have a question just ask on twitter or slack. You’ll get an answer in minutes.

> Is there a language thats known for excellent docs ?

In my experience the Rust docs are great, there's a good mix of types as documentation, high level explanations and examples, with easy access to the source code. Here's an example with the HashMap [1]. There's also the Rust Book [2], which is great because it provides beginners with somewhere to start (F# seems to currently lack this).

The situation is pretty much the same with Elixir, great docs [3] and something to get people started [4].

[1]: https://doc.rust-lang.org/std/collections/struct.HashMap.htm...

[2]: https://doc.rust-lang.org/book/

[3]: https://hexdocs.pm/elixir/List.html

[4]: https://elixir-lang.org/getting-started/introduction.html

Re: F# is gaining independence from .NET

#83

Post by sbelskie »

DanielBMarkham wrote: post #60
pydry wrote: post #57

Earlier quoted context omitted.

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

Symbol/Semantic leakage. In imperative/OO, I'm organizing as I go using well-established and understood paradigms. In functional programming, you're making these paradigms as you go along, or at least you should be. If you come in with an "I'm going to kick some ass by making these classes to solve my problem" attitude, you're already headed down the OO track whether you realize it or not. Then, sure as night follows…

How are these points specific to OO vs. FP, instead of just paradigm I know vs. paradigm I don’t?

F# code, from my somewhat limited experience, seems to almost always be organized logically (top to bottom, types separated from functions) using well-established patterns. Obviously if you decide to write a bunch of classes and mutating code in F# when more idiomatic approaches would work, it’s going to get hairy.

I feel like I’m missing your point.

Re: F# is gaining independence from .NET

#84

Post by KurtMueller »

DanielBMarkham wrote: post #60
pydry wrote: post #57

Earlier quoted context omitted.

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

Symbol/Semantic leakage. In imperative/OO, I'm organizing as I go using well-established and understood paradigms. In functional programming, you're making these paradigms as you go along, or at least you should be. If you come in with an "I'm going to kick some ass by making these classes to solve my problem" attitude, you're already headed down the OO track whether you realize it or not. Then, sure as night follows…

There are plenty of well-known functional language paradigms that have been discussed (and satirized) for decades.

Re: F# is gaining independence from .NET

#85

Post by Smaug123 »

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…

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

Re: F# is gaining independence from .NET

#86

Post by whb07 »

dfgdghdf wrote: post #67
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.

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 interesting part was I did write some bindings calling for a console print via CFFI that did then allow me to compile the F# app and run fine.

Re: F# is gaining independence from .NET

#87

Post by dnautics »

JaggerJo wrote: post #39

Complaining about bad docs isn’t really fair IMHO. Compared to Swift F# has excellent documentation. Would be interesting to know what F# is compared with in this case. Is there a language thats known for excellent docs ? One thing you can’t pass on when talking about fsharp in the community. If you have a question just ask on twitter or slack. You’ll get an answer in minutes.

Is there a language thats known for excellent docs ?

Elixir.

Main docs: https://hexdocs.pm/elixir/Kernel.html

Here's a (3rd party) library's docs. I recommend also checking out "guides" in the upper left corner: https://hexdocs.pm/oban/Oban.html

Re: F# is gaining independence from .NET

#88

Post by KurtMueller »

ipiz0618 wrote: 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 C#, VBA, and one other language (I think it might be C) but no examples in F#.

Re: F# is gaining independence from .NET

#89

Post by [deleted] »

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?

[deleted]

Re: F# is gaining independence from .NET

#90

Post by DanielBMarkham »

sbelskie wrote: post #83
DanielBMarkham wrote: post #60

Earlier quoted context omitted.

Symbol/Semantic leakage. In imperative/OO, I'm organizing as I go using well-established and understood paradigms. In functional programming, you're making these paradigms as you go along, or at least you should be. If you come in with an "I'm going to kick some ass by making these classes to solve my problem" attitude, you're already headed down the OO track whether you realize it or not. Then, sure as night follows…

How are these points specific to OO vs. FP, instead of just paradigm I know vs. paradigm I don’t? F# code, from my somewhat limited experience, seems to almost always be organized logically (top to bottom, types separated from functions) using well-established patterns. Obviously if you decide to write a bunch of classes and mutating code in F# when more idiomatic approaches would work, it’s going to get hairy. I fee…

Happy to talk about it. Ping me. I've already been misunderstood a couple of times in this thread and I fear it's not going to get any better. After all, this is really more of a conversation than a point-counterpoint situation.
Post reply on HN