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

361–370 of 424 posts

Re: Why F#?

#361

Post by ninetyninenine »

kqr wrote: post #124
raphinou wrote: post #107

F# was for me the best functional language when I looked at rewriting a Ruby on Rails app. I wanted to go with a functional language, as it seems to better fit my thinking and reasoning, and I looked at Haskell, Ocaml, Scala, F#. Being a stranger to Microsoft technologies, F# was the least likely to be chosen, but easily became the first choice. Haskell's purity made it hard to adopt (for me), Ocaml's ecosystem is su…

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.

Haskell taught me the important differences between IO and parity and forever influenced the way I program.

Even so the complexity here and the sheer number of mind bending concepts makes me not want to use it.

Re: Why F#?

#362

Post by DeathArrow »

airstrike wrote: post #157
loxs wrote: post #97

I tried F# some years back when I was searching for a language to port my OCaml project in... It felt too much .NET-y and too much MicroSoft-y. And back then .net for linux had just been released and was somewhat unpolished. It seemed that I had to learn C# in order to use F# properly and it seemed that porting it to C# was the saner option. I went with Rust after all and it seems to have been the right choice.

This rings true to me as well. I'm not sure what I get out of F# that I can't get from Rust, unless you specifically want .NET, which I don't.

You get speed of development, productivity, lots of libraries. You get something that is easy to learn and understand.

Re: Why F#?

#363

Post by dkarl »

throwaway2037 wrote: post #311
darksaints wrote: post #219

I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. More significantly, they are being passed up in favor of Rust, which is a great language but nonetheless a bad fit for a lot of problem domains, simply because Rust has a superior build system. Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the buil…

> I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. Scala? I am not trolling here: Are you joking? Scala is part of the Java ecosystem. Sure, Maven gets lots of hate on HN, but it is very mature and has excellent integration with IDEs and CI/CD systems (TeamCity, Jenkins, etc.). In the last 10 years, many Java developers have mov…

Perl is mature, too.

Maven is awful. SBT is awful. Gradle is awful. I've used them all professionally, and the best I can say about them is that you can get the job done with them.

Newer languages and newer build systems are much better experiences, because of decades more hindsight and because language designers think about tooling from the start. Java was designed with the assumption that all software projects were built with Make, and with no ambition to improve on that. There was no Java-specific build tool until Ant was released as a standalone tool circa 2000.

> What is wrong with CMake for C++?

Granted, most of what's wrong with CMake is the problem it solves. Probably there's no solution that wouldn't be at least close to as awful as CMake. But it is objectively a hideous experience compared to any language created in the last 15 years.

Re: Why F#?

#364

Post by ninetyninenine »

dboreham wrote: post #336
kstrauser wrote: post #216

Earlier quoted context omitted.

I find Rust vastly simpler than C. If the code compiles, it's probably a valid expression of the business logic I encoded. I might've screwed up that logic, of course, and no language can prevent me from messing that up. I know! Many have tried, and I've defeated them with my ability to misrepresent my ideas! But at least with Rust, I'm reasonably confident that the code will actually do the thing I asked it to do. I…

This seems...a very contrarian sentiment. Imho while C might lead you to create slightly fragile code once in a while, Rust is something like two orders of magnitude more complex.

No I know what he’s saying. C is not “slightly fragile code once in a while”. When you up the complexity of the code and the amount of code and the people working on the code the fragility becomes pervasive.

Re: Why F#?

#365

Post by iLemming »

jxjnskkzxxhx wrote: post #128

Does anyone else find interesting that people who write blog posts saying "my favourite language is X", it's never a mainstream language..?

> people who write blog posts ... never a mainstream language

Don't you find it amusing that food critics usually write about little-known or new restaurants and never do any fast-food chain reviewing?

Re: Why F#?

#366

Post by Kwpolska »

Foofoobar12345 wrote: post #178
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 functiona…

The problem is, many recruiters don't work with this mindset. If they're hiring a Java developer, and they get a CV from someone who has 1 year of Java experience and 5 years of C# experience, they see 1 year of experience, and immediately put it on the "unqualified" pile.

Re: Why F#?

#367

Post by volemo »

baq wrote: post #298
throwaway2037 wrote: post #291

Earlier quoted context omitted.

Can you explain more about strongly typed vs statically typed?

strong typing: 2 + "2" is an error (e.g. Python vs JS) static typing: 2 + "2" does not compile/parse (e.g. Python vs mypy, Typescript vs JS) this is a very simplistic example, but should get you to feel the difference.

> static typing: 2 + "2" does not compile/parse (e.g. Python vs mypy, Typescript vs JS)

I think this example is not correct, because static typing doesn’t affect how values of different types interact. And while I don’t know of any staticly typed language where specifically `2 + “2”` is a valid expression, statically typed languages definitely can be weakly typed: the most prominent example is C where one can combine values of different types without explicitly converting them to the same type (`2 + 2.0`).

I believe strong/weak and static/dynamic are orthogonal. And my examples are:

- Strong: `2 + “2”` is a error,

- Weak: `2 + “2”` makes 4 (or something else, see the language spec),

- Static: `var x = 2; x = “2”` is an error,

- Dynamic: `var x = 2; x = “2”` is fine.

Re: Why F#?

#368

Post by hocuspocus »

DeathArrow wrote: post #303
hocuspocus wrote: post #80

Earlier quoted context omitted.

It's never been a better time to try Scala if you're interested in the FP side. It's still very much "not opinionated" but the community and ecosystem have benefited from a certain convergence and given up on the "better Java" front which is served by Kotlin more adequately. Of course you can still consume any Java library when needed but it's best to avoid it if possible. Today you can pick between several ecosystem…

So, there is a gazillion ways to do things and the community didn't settle on one? I don't find that very attractive when trying to learn a new language.

The exact same can be said about Java or Kotlin.

Re: Why F#?

#369

Post by airstrike »

DeathArrow wrote: post #362
airstrike wrote: post #157

Earlier quoted context omitted.

This rings true to me as well. I'm not sure what I get out of F# that I can't get from Rust, unless you specifically want .NET, which I don't.

You get speed of development, productivity, lots of libraries. You get something that is easy to learn and understand.

Lots of libraries if you want .NET, right? But if you don't, Rust has way more libraries

Speed of development is debatable. I think you can be pretty fast with both.

Easy to learn I concede but it gets easier with time, until it becomes very easy

Re: Why F#?

#370

Post by no_wizard »

CharlieDigital wrote: post #322
no_wizard wrote: post #226

Earlier quoted context omitted.

The appeal is the runtime model. I can’t readily verify if BEAM languages are meaningfully slower or really slower at all but let’s take the premise for the sake of argument. Even if is slower, the runtime model is incredibly resilient and it’s cheap to scale up and down, easy to hot update, and generally does asynchronous work extremely well across a lot of different processes. F# has really good async ergonomics bu…

.NET's SignalR is actually quite good. Strongly typed message hubs on the server[0]. Wide client support. Azure SignalR[1] if you don't want to own the infrastructure to scale web sockets. [0] https://learn.microsoft.com/en-us/aspnet/core/signalr/hubs?v... [1] https://azure.microsoft.com/en-us/products/signalr-service

given this is about F#, the question is how ergonomic is it to use this in F#?

In the past, I found it wonky

Post reply on HN