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

Why F#?

batsov.com

Post reply on HN
Print view View original

181–190 of 424 posts

Re: Why F#?

#181

Post by raphinou »

tasuki wrote: post #160
raphinou wrote: post #140

Earlier quoted context omitted.

I should have mentioned in the message, but I was looking for a strongly typed language. I was an avid-user of dynamically-typed languages, but that particular Ruby on Rails app became unmaintainable, and part of the culprit was due to the dynamic typing. I hoped that using a statically typed language would make it easier to maintain a complex app in the long term. And I must say that it totally materialised, to the…

These days there's Gleam[0], as a strongly typed alternative for the BEAM virtual machine. Of all the languages I haven't used yet, it seems to hit the safe + minimalistic + productive sweet spot the best. (Yes the C-inspired syntax is slightly off-putting, but syntax is the least important aspect of a language.) [0]: https://gleam.run/

I am also keeping an eye on gleam! I also regret that they left the ml syntax behind, but as you say it shouldn't be a blocking factor. If they adopt computation expressions and make otp a priority it would probably come beside fsharp in my toolbox!

Re: Why F#?

#182

Post by xigoi »

shortrounddev2 wrote: post #132
malakai521 wrote: post #123

Earlier quoted context omitted.

The syntax is exactly the same. You have `var x = await` in C# and `let! x =` in F# The controller handler is also the same. It will be marked with `async` keyword in C# and `task` CE in F#

It's absolutely not exactly the same; let! is only available within a computation block. If you want to return some value from the computation block and return to Functional land without having to pause the thread you need to use a continuation, which C# has built in syntactic sugar for in async/await and F# does not.

A computation block is the equivatent of an async function;

Re: Why F#?

#183

Post by int_19h »

piokoch wrote: post #9
eknkc wrote: post #3

As far as I can tell F# is one of those things where every single user is extremely happy. This happens rarely and I really am curious about the thing but never had time to get into it. I'm also pretty well versed in the .net ecosystem so it's probably gonna be easy. Any tips? What kind of workflows might benefit the most if I were to incorporate it (to learn..)?

"As far as I can tell F# is one of those things where every single user is extremely happy" Isn't it because language has rather small community of passionate people, who are devoted to their language of choice? F# popularity is somewhere between CHILL, Clipper and Raku langs, that are probably as obscure as F# for typical software dev.

I'm pretty sure that there's more production code written in F# than in all those other three combined.

Re: Why F#?

#184

Post by fire_lake »

oguz-ismail wrote: post #8

>whitespace is significant, like in Python hard pass

Static typing removes the downside of whitespace.

Oh, and every language with line comments (so most of them) has significant whitespace.

Re: Why F#?

#185

Post by bob1029 »

UK-Al05 wrote: post #87
bob1029 wrote: post #43

Earlier quoted context omitted.

You can write a vast majority of your C# codebase in a functional style if you prefer to. All the good stuff has been pirated from F# land by now: First-class functions, pattern matching, expression-bodied members, async functional composition, records, immutable collections, optional types, etc.

A language is just as much about what it can't do, then what it can do.

Can you elaborate on what you mean by this?

I assume you are implying that too many choices could confuse a junior developer, which I agree with. However, I don't think this is a concern in the bigger picture when talking about the space of all languages.

Re: Why F#?

#186

Post by cjbgkagh »

neonsunset wrote: post #175
cjbgkagh wrote: post #169

Earlier quoted context omitted.

F# is a big language, it is a ML multi paradigm language that interoperates with C# so there is a lot of necessary complexity and many ways to do the same thing. A strong benefit of this is the ability to create a working functional paradigm prototype that can iteratively be refined to a faster version of itself by hot spot optimizing the slower parts with equivalent highly mutable functions while staying within the…

It is best to just use task CE full-time unless you need specific behavior of async CEs. The author of the original comment, however, does not know this nor tried verifying whether F# actually works seamlessly with this nowadays (it does). Writing asynchronous code in F# involves less syntax noise than in C#. None of that boilerplate is required, F# should not be written that way at all.

F# is a big language so I think it is to be expected that beginners will not know these things. I don't think the fix is to simplify F# we should just understand that F# is not for everyone and that is ok.

Re: Why F#?

#187

Post by int_19h »

gwbas1c wrote: post #70
neonsunset wrote: post #62

Earlier quoted context omitted.

You have likely heard "functional core, imperative shell". This refers to having IO-heavy code that favors imperative patterns be written in C# and then have the actual domain logic core written in F# which is much better at expressing it. Because both languages are hosted on .NET, you simply achieve it by having two projects and having one reference another. It is very seamless F# and C# types are visible to each ot…

That's just like how C# and VB.Net can co-exist in the same project. Would you pick the pattern of: 1: C# Library with interfaces and/or abstract base classes 2: F# library with implementations of those interfaces and base classes 3: C# program (console, web service, GUI, ect) that specifies the implementations in Dependency Injection Or is there a simpler way for C# and F# to co-exist in the same project (dll or exe…

You don't really need to split 1 & 2, since F# can define .NET interfaces and abstract classes just fine.

For that matter, you don't even need the interfaces if you wouldn't have had them in a C#-only solution. Just define the class in F# and use it directly from C#.

You still need a separate assembly for F#, but that doesn't imply dependency injection - again, just reference it and use it.

Re: Why F#?

#188

Post by int_19h »

marcosdumay wrote: post #86
twodave wrote: post #59

In the case of F#, the use cases are diminishing with every new C# release, since C# is getting better and better at the things F# is supposed to be strong at (record types, pattern-matching, etc.). Better to write the thing in C# using modern features of the more popular and capable language.

You may start to get a point when C# gets a two-directional type inference system. As it's now, any functional-looking code requires so much boiler plate that it's shorter and less bug-prone to copy your functions code everywhere you want to use them.

Can you give an example of said boiler plate?

Re: Why F#?

#189

Post by int_19h »

malakai521 wrote: post #139
gwbas1c wrote: post #51

> Why F#? I'm kinda wondering if anyone here with decent C#/.net experience can give their version of the answer? --- The article really didn't answer its own question. It basically says "How" instead of "Why"... ...Which as someone who's spent over 20 years in C#, and tends to advocate for "functional" style, leaves me with more questions than answers!

A nicer, cleaner and simpler syntax, superior pattern matching, active patterns, discriminated unions and computation expressions

C# has the equivalent of active patterns these days.

Re: Why F#?

#190

Post by dkarl »

innocentoldguy wrote: post #148
breadwinner wrote: post #130

Earlier quoted context omitted.

Apache Spark, Delta Lake are written Scala. Being JVM based, it has a large ecosystem. Scala seems like a better choice than F#.

I think Clojure is the better option if you want to do FP using the JVM ecosystem. The problem (for me, anyway) I've run into with Scala is that it supports both functional programming and object-oriented programming. Every code base I've worked on in Scala has ended up being a hodgepodge of both, which I find annoying. However, the best functional programming language is, of course, Elixir. :D

> Every code base I've worked on in Scala has ended up being a hodgepodge of both

Is there something about that that has bothered you? Working in Scala codebases, I've found the best ones to work in are the ones that embrace Scala's multiparadigm nature. When programmers try to solve every problem with OO, they end up adding more and more layers to get the job done. When programmers try to solve every problem with FP, they end up resorting to sophisticated techniques that are unapproachable for other engineers. I think the simple parts of OO and the simple parts of FP go much, much further together than simple OO or simple FP can go by themselves. Have you seen something different?

Post reply on HN