Live data from Hacker News

Why F#?

batsov.com

211–220 of 424 posts

Re: Why F#?

#211

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

> 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 tabs after all the visible characters change the meaning of the line.

Re: Why F#?

#212
F# is a wonderful language, one that I write as my daily for the second time during my carrier. It _baffles_ me how it isn't more popular than it is because it truly is very very good. And I say this as an experienced and avid functional programmer.

We even do the frontend in it using Fable and Elmish, which is to say: we basically write our frontends in Elm, but the platform is .NET.

Re: Why F#?

#213

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!

It runs on .NET, for god's sake. This is not a small platform.

Re: Why F#?

#214
post #90
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…

This isn’t a great example of what linq is good at. There’s no reason to do ToList there, and the ForEach isn’t particularly idiomatic

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

Re: Why F#?

#215

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…

For reference, F# slack is already dead, community has moved to Discord https://discord.com/invite/fsharp-196693847965696000

Re: Why F#?

#216

Earlier quoted context omitted.

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.

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'm never confident like that with C until I've run it a few hundred times without crashing.

(Yes, I'm familiar with the rich ecosystem around helping devs not write crummy C. I worked at Coverity at one point. If anything, that gave me enormous fear and respect of the hoops you have to jump through to be reasonably sure C code isn't completely broken.)

Re: Why F#?

#217

Earlier quoted context omitted.

It exists in several similar languages such as elixir, and was even a proposal for ecmascript, but never really got traction.

It made it to Stage 2, which is some traction: https://github.com/tc39/proposal-pipeline-operator It has been "stuck" at Stage 2 for a while, though.

Thanks for that link! Now I want pipe operators...

Re: Why F#?

#218
post #70

Earlier quoted context omitted.

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.

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

Re: Why F#?

#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 build system.

It baffles me that there are languages with non-profit foundations and are financially backed by multiple corporations which still have bad build systems. It is the most important investment you can make into a programming language.

Re: Why F#?

#220

Because you love using Microsoft's shitty technologies, but also want to be completely unemployable?

I'm sure Microsoft has developed a lot of bad tech, but by and large their languages have been great. msvc c++ compiler as a possible exception, but f# in particular is excellent.
Post reply on HN