Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

Post reply on HN
Print view View original

241–250 of 333 posts

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

#241

Post by physPop »

keithnz wrote: post #8

just as true today as 2015 when the article was written, except C# got even better. While I like the F# language, I don't like the (understandably) abandonware of the small community. I've ported most of my F# stuff to C#, and it's not that much different in that you can program in a functional style in C#. Probably the nicest thing in F# that C# doesn't have is computation expressions.

Passing functions in C# is the worst experience though, and not having partial application really forces you into DI hell, which is the worse part of large software in C# IMO. Dependency Injection frameworks are soul killing

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

#242

Post by runevault »

keithnz wrote: post #61
runevault wrote: post #26

Earlier quoted context omitted.

On top of your answer and the other, I still think Discriminated Unions are still a big hole in c#. I know they are supposedly working on it, but until they officially release it I'm not believing them.

It's easy enough to do DUs, they are working on it, but they are just syntactic sugar for abstract class/subclass for instance, as an example for this https://fsharpforfunandprofit.com/posts/designing-for-correc... where a C# solution is suggested and done with DUs in F#, I wrote the equivalent DU solution in C#... https://gist.github.com/keithn/ceeeed5f7eb567e1b2333747065d1... Only thing you don't have is exhaustive…

Exhaustive checking and locking down the base type if you don't want anyone else to extend it beyond your choices of subtypes, unless there's a way I don't know about to lock down extending to inside your binary while letting others ask for any types that references it.

There's a secondary benefit though if they allow DUs of Structs where you can have it be on the stack as a single value based on the size of the largest subtype that could be incredibly useful when you are worried about performance. Inheritance does not do that.

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

#243

Post by runevault »

ericsink wrote: post #73
runevault wrote: post #26

Earlier quoted context omitted.

On top of your answer and the other, I still think Discriminated Unions are still a big hole in c#. I know they are supposedly working on it, but until they officially release it I'm not believing them.

I too miss discriminated unions in C#. But even more often, I find myself wishing C# blocks were expressions. In F#, I could do this: let x = let z = whatever ... value and z is inside a local scope. So in C#, I want to do: var x = { var z = whatever; ... value }; Maybe it's just me.

Nah it isn't just you. I probably use this more in my Rust experience then F# but when I remember it is there it is incredibly valuable.

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

#244

Post by pjmlp »

lostmsu wrote: post #226
pjmlp wrote: post #172

Earlier quoted context omitted.

Good luck having the whole .NET Windows ecosystem rewritten in Rust.

Eh. It is vast, but the tide is shifting. Non-UI components were never that good. WPF is in maintenance mode. And there is a growing need for deep learning which is currently a total lackluster in .NET

Still, more likely to be Python and C++ than Rust.

See ONYX, DirectML and ML.NET announcements at BUILD.

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

#245

Post by bazoom42 »

chowells wrote: post #97
waffletower wrote: post #85

Earlier quoted context omitted.

Using a static language to manipulate complex types, particularly those sourced from a different type system (say complex nested Avro, SQL, or even complex JSON) is much more awkward when the types cannot be normalized into the language automatically as can be done with dynamic languages. Static languages require more a priori knowledge of data types, and are very awkward at handling collections with diverse type mem…

You realize every single thing that dynamically-typed languages can do with data types, statically-typed languages can do too? Except when it matters, they can also choose to do things dynamically-typed languages can't. Lots of people assume static typing means creating domain types for the semantics of every single thing, and then complain that those types contain far more information than they need. Well, stop doin…

You can’t do monkeypatching or dynamically modify the inheritance chain of an object in a statically typed language.

But yes, you can have a JsonNode type, which is still better than having every type being “object”.

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

#246

Post by rapind »

pc86 wrote: post #222
sph wrote: post #204

Earlier quoted context omitted.

I agree on the underrated part. My theory as an outsider: F# is strongly tied to the Windows world, the corporate world, where a conservative approach is always preferable, on your tech stack and if you need to hire peons coding all day. The corporate world isn't leaving OOP anytime soon, because it's what 95% of engineers focus on, the silent majority which do not frequent HN or play with functional languages in the…

I am admittedly biased, because although I started programming recreationally in the LAMP-stack world of mid-aughts fame, a huge portion of my professional career has been in C# and the .NET stack. I think you are grossly overestimating the degree to which the programming language you choose to use to solve a business problem constitutes "betting your business on." How would your business fundamentally change if your…

dotnet compiles in general are slow AF on macs, and F# really stood out as the slowest last time I give it a kick.

F# looks wonderful, but unless you’re already in the MS ecosystem, dotnet just feels bad and out of place. And I guess if you are already in the MS ecosystem you’re using C#.

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

#247

Post by FrustratedMonky »

waffletower wrote: post #81
EdwardDiego wrote: post #30

Earlier quoted context omitted.

How messy is the JSON exactly? Type providers are awesome when the schema is consistent. But tbh, from what little I know, I'd be expecting you to expect me to solve the issue from first principles. So using a "and then magic" technique might be something interviewees shy from.

Hahaha, "when the schema is consistent". The strong typing herd keeps thinking it can smash reality into a square hole.

This sentiment is surprising. Doesn't Python crash a lot at run-time, specifically because some 'dynamic types' clash. They become a real type at some point, at compile time or at run time. Why wait for the crash to figure it out?

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

#248

Post by pjmlp »

smcl wrote: post #192
pjmlp wrote: post #158

Earlier quoted context omitted.

They keep trying to kill .NET, just check how much WinDev keeps doubling on COM and pushing subpar frameworks like C++/WinRT. One would expect that by now, out-of-process COM would be supported across all OS extension points, instead it is still pretty much in-process COM, with the related .NET restrictions. Then there is the whole issue that since Longhorn, most OS APIs are based on COM (or WinRT), not always with .…

Doesn't look to me like they're trying to kill .NET at all. Maybe F# in particular isn't getting the love and attention it deserves but they'd have to be mental to be actively trying to kill off something as popular as .NET

Kill in the sense that from WinDev point of view, the less .NET ships on Windows the better.

In case you aren't aware, WinRT basically marks the turning point started with Longhorn ideas being rewriten into COM.

With WinRT, they basically went back to the drawing board of Ext-VOS, a COM based runtime for all Microsoft languages, hence why .NET on WinRT/UWP isn't quite the same as classical .NET and is AOT compiled, with classes being mapped into WinRT types (which is basically COM, with IInspectable in addition to IUnknown and .NET metadata instead of COM type libraries).

Mostly driven by Steven Sinofsky and his point of view on managed code.

This didn't turned out as expected, but still the idea going forward is to make WinRT additions to classical COM usable in Win32 outside UWP application identity model.

"Turning to the past to power Windows’ future: An in-depth look at WinRT"

https://arstechnica.com/features/2012/10/windows-8-and-winrt...

Naturally since DevDiv also has something to say, .NET isn't going anywhere.

And since nowadays "Azure OS" matters more than Windows, WinDev point of view is mostly relevant for Windows Server and Hyper-V workloads.

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

#249

Post by vladvasiliu »

pc86 wrote: post #222
sph wrote: post #204

Earlier quoted context omitted.

I agree on the underrated part. My theory as an outsider: F# is strongly tied to the Windows world, the corporate world, where a conservative approach is always preferable, on your tech stack and if you need to hire peons coding all day. The corporate world isn't leaving OOP anytime soon, because it's what 95% of engineers focus on, the silent majority which do not frequent HN or play with functional languages in the…

I am admittedly biased, because although I started programming recreationally in the LAMP-stack world of mid-aughts fame, a huge portion of my professional career has been in C# and the .NET stack. I think you are grossly overestimating the degree to which the programming language you choose to use to solve a business problem constitutes "betting your business on." How would your business fundamentally change if your…

Aside from the EEE quip, I didn't catch any "M$ bad" vide in GP's post.

I think the situation is clear-cut: until recently, you couldn't really run .net on anything else than Windows, so the only people using it were those already invested in the ecosystem.

Among the people invested in the windows ecosystem, many (most ?) are large "non-tech" companies who hire people who mostly see their jobs as a meal ticket. These people don't have the inclination (for lack of curiosity, or time, or whatever reason, doesn't matter) to look into "interesting" things. They mostly handle whatever tickets they have and call it a day. Fiddling with some language that has a different paradigm wouldn't be seen as a good use of their time on the clock by corporate, or during their time off work by themselves, since they'd rather spend that time some other way.

Hence, F# never really got any traction.

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

#250

Post by FrustratedMonky »

nick__m wrote: post #16
gemstones wrote: post #11

Earlier quoted context omitted.

Parsing realistic (messy) JSON, usually. I would have expected F# to shine at that due to type providers, so it was doubly surprising to me. The F# candidates I've seen spend most of the interview manipulating the data.

Those F# candidates would have been be better to use C# to do the adhoc data wrangling and F# for algorithmic part of the program.

Isn't ad-hoc data wrangling the feature of F#? Why are so many people here against F# for reading/manipulating ad-hoc data, that's what it is good for.
Post reply on HN