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...
Why F# evangelism isn't working (2015)
231–240 of 333 posts
Re: Why F# evangelism isn't working (2015)
#232Re: Why F# evangelism isn't working (2015)
#233(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…
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.
Re: Why F# evangelism isn't working (2015)
#235Earlier 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.
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.
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)
#237I 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.
Re: Why F# evangelism isn't working (2015)
#238Earlier 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.
Re: Why F# evangelism isn't working (2015)
#239Earlier 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…
Re: Why F# evangelism isn't working (2015)
#240I 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.