Live data from Hacker News

Why F#?

batsov.com

281–290 of 424 posts

Re: Why F#?

#281

Earlier quoted context omitted.

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

Do you make sure to run a linux kernel with all the MS stuff patched out also?

No, but if it came in the standard install there's nothing I can do about it save spending hours and hours auditing my install. I don't do that kind of thing nowadays.

Separately installed software? Not a bit of it.

Re: Why F#?

#282
post #242

Earlier quoted context omitted.

I've identified a possible use case for F# in a preexisting product; I'm looking for the simplest way to integrate F#.

F# excels in writing domain logic where main domain entities are defined as records and discriminated unions and logic is written in pure functions. Given that product is preexisting and domain entities must already be defined, I wonder what use case do you have in mind?

Realtime control logic for infrastructure.

The basic decision making logic needs to be very simple and easy to follow by scientists and people who aren't day-to-day software engineers: Basically, input some data, such as sensor readings, run it through an algorithm that makes decisions, and then output the decisions.

Re: Why F#?

#283
post #6

I learned F# in 2013 and had a lot of fun with it, some of that code remains on Github (e.g. a 2D platformer game for windows https://github.com/lihaoyi/FSharpMetro/tree/master/Applicati... ). My experience was that it was a surprisingly nice language with a surprisingly warty user experience: papercuts ranging from naming conventions and function call styles (`|> List.map` vs `.Select`), basic syntax (`foo.[0]` to l…

[deleted]

Re: Why F#?

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

I find F# easy to use with AI, mainly because it's statically typed (which results in compiler errors when the LLM generates non-working code) and it's very expressive, which allow me to more easily comprehend what the LLM is trying to do.

Re: Why F#?

#286
post #22
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..)?

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…

That could be shortened to

names.ForEach(name=>Console.WriteLine($"Hello, {name}! Enjoy your C#"));

Re: Why F#?

#287
post #124

Earlier quoted context omitted.

Curious since you don't expand on it on the blog: in what way did Haskell's purity make it difficult to you? Having used Haskell in production for a bit now, I don't even notice its purity. Most functions are in some kind of I/O context making it similar as other languages, except with the option of running without I/O capabilities for functions that shouldn't need it.

You gotta remember people are often picking languages based on what they can easily find out about it and extrapolating/guessing about what problems they'll run into with their expected use. A few years ago on here I had an interesting conversation with someone who wasn't going to use rescript for something because they didn't like how it handled object types. I can't remember ever using an object type in rescript; w…

> You gotta remember people are often picking languages based on what they can easily find out about it and extrapolating/guessing about what problems they'll run into with their expected use.

This is a good observation.

As someone who writes a lot of Lisp, I'm inclined to agree as the amount of people that have never written any Lisp yet immediately reject it over syntax over fears that it somehow hampers development is a (to me) surprisingly large number of people.

If I recall correctly, one of the motivating factors for Rescript was to reduce the perceived/real distance between Reason and JS in order to attract more JS devs, as Reason was so heavily associated with OCaml.

Re: Why F#?

#288

Two nice things about F# are that you can introduce it into an organisation using the dotnet ecosystem and that you can use all libraries in dotnet, which is a huge advantage over OCaml. Otherwise, I am happy with OCaml, but F# has also a place in this world.

You can use adapters via Foreign Function Interface and interact with C++ code. The deal breaker is that memory is separated, C++ code has its own heap and Ocaml too. Quiet different to F# in which operating with C# is seamless and the runtime is the same.

Re: Why F#?

#289

Earlier quoted context omitted.

There was a large group of folks that left Ruby on Rails for Elixir (even has a similar looking syntax), yet it wasn't on your list of languages to consider. Just curious, was there a particular reason?

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…

Hey, thank you for sharing your app's source code. I'll definitely check it out, I was really looking for such apps on F# open source projects!

Re: Why F#?

#290

Earlier quoted context omitted.

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

It's actually sort of the other way round. C# has hardcoded syntax for async/await. F#'s syntax for async/await is a fully-general user-accessible mechanism.

They're not so different in that regard. C# `await` can be adapted by making an awaitable and awaiter type[1], which isn't to dissimilar to how a computation expression in F# needs to implement methods `Bind`, `Return`, `Yield`, etc.

In both languages these patterns make up for the absence of typeclasses to express things like a functor, applicative, monad, comonad, etc.

[1]https://ecma-international.org/wp-content/uploads/ECMA-334_7...

Post reply on HN