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

171–180 of 424 posts

Re: Why F#?

#171

Post by Foofoobar12345 »

rockyj wrote: post #29

I did try F#, but I was new to .NET ecosystem. For 1 "hello world" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off. I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code? Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have…

F# is quite usable with AI. All AI models are perfectly capable of generating idiomatic F# code. In fact, because it has a nice type system, if you ask the AI to model the problem well with types before implementing, hallucinated bugs are also easier caught.

Re: Why F#?

#172

Post by innocentoldguy »

johnnyjeans wrote: post #102
pdimitar wrote: post #36

People will do anything except actually try Elixir. :D ...I mean: pipes, immutability, transparent mega-parallelism... helloooo? I tried F# some years ago (after I was fired from a shop that decided they will go all-in on Java and F# and dropping everything else overnight) and I was not impressed. I mean the language is really nice but the C# baggage and runtime was just a bit much. And I was not left convinced that…

> Elixir For me, it's Erlang. I just really like its horn clause syntax, it's so clean and readable. I know a common complaint is lack of piping (and even though you can implement it trivially, the order of arguments for some functions makes it of dubious use) but it's a small price to pay. > I mean the language is really nice but the C# baggage and runtime was just a bit much This was my experience with F#. Frankly,…

I can't remember which version of Erlang was the most current when I started learning Elixir, but I do know that it was years before OTP 20, which fixed its string issues. Prior to that, Erlang didn't have very good string support for internationalization (I do a lot of Japanese language programming). Elixir, on the other hand, did. Otherwise, I may have gone with Erlang back then.

I like Erlang a lot, too. Both are great languages.

Re: Why F#?

#173

Post by johnisgood »

vlovich123 wrote: post #127
homebrewer wrote: post #106

Earlier quoted context omitted.

It is extremely niche outside of this bubble.

F# will likely remain niche forever. It’s likely that Rust will not given its growing and accelerating adoption by Microsoft, Google and the Linux Kernel. It just takes time to defeat the 40+ years of c and c++ dominance.

Personally I will always prefer C's simplicity to Rust's complexity. Could be just me.

Re: Why F#?

#174

Post by shortrounddev2 »

sparkie wrote: post #147
shortrounddev2 wrote: post #132

Earlier quoted context omitted.

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.

`await` can only be used in an `async` function. How is that so different from `let!` only being available in a computation expression?

because an async function doesn't require you to change syntaxes to get them to work

Re: Why F#?

#175

Post by neonsunset »

cjbgkagh wrote: post #169
shortrounddev2 wrote: post #101

Earlier quoted context omitted.

I like F#'s syntax when all you're doing is pure logic. But when you have to interface with any IO like a database or REST call or something, you have to abandon the elegance of ML syntax and use these ugly computation blocks. In C# you can do something like this: var post = await _postService.getById(id); in F# the equivalent is basically let getPostById id = async { let! post = blogPostService.getPostById id return…

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.

Re: Why F#?

#176

Post by int_19h »

psychoslave wrote: post #156
pjc50 wrote: post #22

Earlier quoted context omitted.

The funny thing is that you can write very similar code in C#, so maybe you don't need to switch which language you're using as a CLR frontend. using System.Linq; using System; var names = new string[] {"Peter", "Julia", "Xi" }; names.Select(name => $"Hello, {name}").ToList().ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#")); LINQ is such a good library that I miss it in other languages. The Java s…

As far as fluency goes, that’s not very impressive. %w{Peter Julia Xi}.map{"Hello, #{it}"}.each{puts "#{it}! Enjoy your Ruby"} That’s of course trivial examples. And while Ruby now have RBS and Sorbet, it’s yet another tradeoff compared to a syntax that has upfront static analysis as first class citizen in mind. That is, each language will have its strong and weak points, but so far on "fluency" I’m not aware of anyt…

Ruby is dynamically typed, which makes "fluent" API design that much easier at the cost of maintainability elsewhere. If you want to compare apples to apples, you need to compare F# to other statically typed languages.

Re: Why F#?

#177

Post by int_19h »

bob1029 wrote: post #43
pjc50 wrote: post #22

Earlier quoted context omitted.

The funny thing is that you can write very similar code in C#, so maybe you don't need to switch which language you're using as a CLR frontend. using System.Linq; using System; var names = new string[] {"Peter", "Julia", "Xi" }; names.Select(name => $"Hello, {name}").ToList().ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#")); LINQ is such a good library that I miss it in other languages. The Java s…

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.

I wouldn't say "all" - C# doesn't have discriminated unions yet, which is kind of a big one, especially when you're also looking at pattern matching. A

Re: Why F#?

#178

Post by Foofoobar12345 »

pimbrouwers wrote: post #46

Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable. There are a few drawbacks, depending on your perspective: - compilation is slow…

Hiring devs is perfectly fine if you don't look for F# skills - just hire generally smart people, and allow them 1-2 weeks to get comfortable with F#. Make them just solve problems from project euler or something.

For those who have already done functional programming, they wont take more than 2 days to start getting productive. For those who have written a lot of code, it will take them ~2 weeks to pick up functional thinking.

Anyone who is still uncomfortable with F# after 1 month - well that's a strong signal that the dev isn't a fast learner.

Additionally, I've never had anyone reject our job offer because we do F#. I'm sure a whole bunch of people might only be looking for python or javascript jobs, but that's fine because I'm not looking for them. I always have more people who I want to hire but I can't due to budget constraints.

Source: direct experience - I run a pure F# company with a team size of ~80.

Re: Why F#?

#179

Post by MrMcCall »

munchler wrote: post #170
MrMcCall wrote: post #158

Earlier quoted context omitted.

I don't doubt it, but I don't run Microsoft software any more. I've seen enough embrace, extend, and extinguish in my lifetime to not depend on them for my code's execution environment. My current work needs nothing the .NET environment provides that I can't use python's standard libraries to get done, or bash and C if I need to. But I'm lucky to no longer be in a corporate environment, so I don't need to consume com…

FWIW, F# is an open source project controlled by the F# Software Foundation, the .NET Foundation, and Microsoft.

> controlled by the F# Software Foundation, the .NET Foundation, and Microsoft.

It is controlled by Microsoft. It's not going on my Linux or BSD boxes.

I know how they work, and I want nothing to do with them.

Re: Why F#?

#180

Post by frakt0x90 »

raphinou wrote: post #144
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'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!

I agree with you. I tried Scala for weeks and found it far too complex. Every line I wrote, I felt there were 5 different ways of doing it and I didn't know if I was choosing the right one. Scala tries to be too many things at once imo.
Post reply on HN