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

231–240 of 424 posts

Re: Why F#?

#231

Post by Smaug123 »

speed_spread wrote: post #75
munchler wrote: post #20

Earlier quoted context omitted.

F# is up to version 9 now, and has only improved over time, IMHO. Type providers are a very small part of the story and can be avoided entirely if you want.

Why would type providers be avoided? It seemed to me like a nice metaprogramming feature, akin to what Zig does with comptime types (except runtime?)

Yeah, they're terrifying. It's often not that hard to generate the code (e.g. https://github.com/Smaug123/WoofWare.Myriad/ is where I pump out these things) for a bunch of what you would want to do with a type provider, and that's much less existentially terrifying if it's possible.

Re: Why F#?

#232

Post by _7acn »

protonbob wrote: post #12

> which is quite odd for what is supposed to be the flagship editor for F# The flagship editor is Visual Studio, not vs code.

The flagship editor is Rider

Re: Why F#?

#233

Post by Smaug123 »

jcmontx wrote: post #68
GiorgioG wrote: post #47

As a 20+ year C# developer I’ve tried several times to learn/use F#. Despite being interested in FP, my brain is having trouble figuring out how to structure my code in F#. In C# I’d either build a service (or use the mediator pattern) for the domain and a repository for data access. With F# it’s functions all the way down and it feels unnatural (as silly as that may sound).

The secret is currying. Replace your DI for currying and you'll start to see somewhat similar patterns

By the way, I consider https://www.bartoszsypytkowski.com/dealing-with-complex-depe... to be the canonically correct way to do DI when you want to inject more than like two dependencies.

Re: Why F#?

#234

Post by ecshafer »

flakiness wrote: post #165
raphinou wrote: post #144

Earlier quoted context omitted.

I'm sure it can be the better choice, but for me it was not. It seems there was some incompatibility between me and Scala. I find it such a complex language and I never managed to wrap my head around it. As I said F# was my last choice at the start of my evaluation, and Scala was high on the list due to the Java ecosystem. But in the end it didn't work out for me. F# on the JVM would be great though!

Is F# easier to learn than Scala? (I know a bit of Scala (in the old 2.x days) but have no knowledge of F#.)

I have done a bit of both Scala and F#, I think F# is a good bit easier to learn. Scala I think mixes OOP concepts and mutability in a bit less gracefully.

Re: Why F#?

#236

Post by mrkeen »

lysecret wrote: post #162

I worked a lot in F# and loved it. I love that it has a lot of great functional ideas without being too pedantic about being 100% functional all the time. (You can have mutating state or just call arbitrary C#.) I took a lot of its insights into my daily python code too. I especially love match.

There's no need to be functional 100% of the time, and it's not pedantry.

You mark your functions and non-functions as such, so the compiler can get your back.

Re: Why F#?

#237

Post by fire_lake »

AnimalMuppet wrote: post #211
fire_lake wrote: post #184

Earlier quoted context omitted.

Static typing removes the downside of whitespace. Oh, and every language with line comments (so most of them) has significant whitespace.

> Static typing removes the downside of whitespace. How so? > Oh, and every language with line comments (so most of them) has significant whitespace. Technically true, but that's not what people mean by "significant whitespace" in this context. So you're being pedantic rather than saying anything meaningful. But you made me think. The ultimate nightmare would be significant trailing whitespace - the spaces and/or tab…

> How so?

Well I don’t know what issue you have with whitespace, but the usual complaint is that programs with small typos are syntactically valid but logically incorrect. This is why CoffeeScript became so disliked. A static type checker makes this scenario much less likely since it won’t compile.

I would also add that F# has some indentation rules (“offside rules”) and tabs are disallowed, further shrinking the input space.

Re: Why F#?

#238

Post by Lanayx »

amelius wrote: post #11

I have a few questions. Can it do GUIs well? How about mobile? And how does it compare to e.g. Scala?

For web UI we have Fable and it's integration with well-known js frameworks, also WebSharper (although it's less well-known) and Bolero (on top of Blazor)

For mobile we have FuncUI (on top of Avalonia) and Fabulous (on top of Avalonia, Xamarin and Maui). Most of these frameworks use Elm architecture, but some do not. For example I use Oxpecker.Solid which has reactive architecture.

Can't help with Scala comparison, but at least DeepSeek V3 prefers F# for UI https://whatisbetter.ai/result/F%23-vs-Scala-9eaede00c7e4485...

Re: Why F#?

#239

Post by 110bpm »

phplovesong wrote: post #56

Last time i tried F# i got bit by the weird concurrency story. There was async/task and somwhow they did not play well together. Also the dev tooling (for vim) was subpar, compared to ocaml (lsp). Compile times also was on the slower side.

`async` is F#'s original implementation of async programming. It is the precursor to C#'s await/async.

`task` targets the .NET TPL instead, which is also what C#'s await/async and all of .NET *Async methods use.

While the `async` implementation still offers some benefits over `task` (cold vs. hot starts [0]), my advice is - if you're doing backend code on .NET, you should use task. The tigher integration with the .NET ecosystem & runtime results in better exception stack traces, easier debugging and faster performance.

[0] https://github.com/TheAngryByrd/IcedTasks?tab=readme-ov-file...

Re: Why F#?

#240

Post by bob1029 »

klysm wrote: post #224
bob1029 wrote: post #214

Earlier quoted context omitted.

> There’s no reason to do ToList there In this case, I would move it to the very end if we are concerned about the underlying data shifting when the collection is actually enumerated. Forgetting to materialize LINQ results can cause a lot of trouble, oftentimes in ways that happily evade detection while a debugger is attached.

> if we are concerned about the underlying data shifting when the collection is actually enumerated I’m not sure what you mean by this. You can fulfill the IEnumerable contract without allowing multiple enumerations, but that doesn’t really have to do with the data shifting around. Doing ToList can be an expensive and unnecessary allocation

Imagine a live SQL query you are subsequently filtering with LINQ.
Post reply on HN