Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

231–240 of 333 posts

Re: Why F# evangelism isn't working (2015)

#231

Earlier quoted context omitted.

I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

> Just look at building a simple HTTP endpoint in C# compared to Node or even F#! It's... basically the same? Include library, create server object, tell server object what request to handle and what to return, start server object. https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...

By "used to write", I'm guessing maybe they worked in the .NET Framework/IIS era, which did have a cognitive cliff to climb. You could get used to the ceremony though and then your brain started to ignore it and focus on the stuff that mattered. These days it's much easier though.

Re: Why F# evangelism isn't working (2015)

#233
post #84

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling O…

No, Functor, Monad is OOP concept.

Re: Why F# evangelism isn't working (2015)

#234

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

I think another problem was that Microsoft downplayed F#. They didn't support it in SSIS packages, or fully support it in MVC projects. Those were the main things I did back then. I really wanted to use F# and had the freedom to do so, but had to conclude I'd be faster sticking with C# than switching back and forth.

Re: Why F# evangelism isn't working (2015)

#235
post #82
post #78

Earlier quoted context omitted.

You could have out of order function declarations.

Forcing linear dependence of files and definitions is considered a feature of F#. In codebases that allow out of order definitions, things get wild real quick.

> In codebases that allow out of order definitions, things get wild real quick.

Not an issue in C# at all. Get wild in what way?

Re: Why F# evangelism isn't working (2015)

#236

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

> F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

That's right. I mostly switched to writing "dumb records + service classes" code in C#, and while F# is terser, there's just not enough pain to cause me to switch. When DU's come to C#, the gap will get even narrower.

Re: Why F# evangelism isn't working (2015)

#237

I think it shows in the community management that F# originated in a closed-source environment. For example, it is required to be a member of the F# Software Foundation to get access to F# Slack. Putting such a roadblock early in the discovery of the community is a sure way to limit your growth.

you sign up with any random email address and you get an invite.. its not closed at all

Re: Why F# evangelism isn't working (2015)

#238
post #49

Earlier quoted context omitted.

> JavaScript/TypeScript and Python will become even more popular, to the detriment of everything but Go, C++, and Rust. Why do you see the popularity of C# waning?

Rust might take its place if the tooling would be on par. Personally I'd jump.

Rust and C# do very different things

Re: Why F# evangelism isn't working (2015)

#239
post #77

Earlier quoted context omitted.

I'm a data engineer, it's a fairly new role so it's not well defined yet, but most data engineers write data pipelines to ingest data into a data warehouse and then transform it for the business to use. I'm not sure why using a static language would make translating data types difficult, but I add as many typehints as possible to my Python so I rarely do anything with dynamic types. I guess they're saying for small t…

A major problem with doing data transformation in statically typed languages is that its easy to introduce issues during serialization and deserialization. If you have an object [{ name:”ex obj” value:”a sample value” extraProperty:”I’m important” }] And the code class myDTO{ string name; string value; } var myObjs= DerserializeFromFile (filepath) SerializeToFile(myObjs, filePath2) filepath2 would end up with without…

Even with a Dynamic Type, it becomes real static type at some point when running, so why wait for the crash to happen at runtime?

Re: Why F# evangelism isn't working (2015)

#240
post #42
post #37

I love F#, I use it professionally. But I agree with everything written in this post. I hate that F# is not a safe choice yet. I wish that it were but it doesn't have the critical mass. That means hiring others is not going to be as easy as finding an existing F# developer. Functional programing is different. I don't think it's hard but it's not what most developers have spent years practicing. So there is a learning…

> Functional programing is different. I think the problem with this line of thinking is that some people insist on using functional tactics EVERYWHERE, even when it doesn't make sense. I get that its ugly to mix functional and imperative code, and maybe some languages dont even allow that. but they should. thats why I like Go, because sometimes a simple for/while loop IS the correct answer.

Thats exactly why f# is so nice, not forced into functional everywhere
Post reply on HN