Remix clone Hacker News

In the case of F#, the use cases are diminishing with every new C# release, since C# is getting better and better at the things F# is supposed to be strong at (record types, pattern-matching, etc.). Better to write the thing in C# using modern features of the more popular and capable language.

▲

throw234234234 2 days ago | parent | next [-]

Not sure that C# is the more capable language - its still that F# is mostly a superset of C# although C# is catching up. I think they are on par w.r.t capability (i.e. CLR compatible). In terms of conciseness, and expression F# still wins IMO; and given some of the extra features can be more performant at times (e.g code templating/inlining vs just JIT attributes). Custom CE's (Async/TaskSeq), nested recursive seq's great for algorithm dev, DU's, etc. There's a lot of little features C# doesn't have (or don't quite fit) that when I write C# I'm forced to implement still more cruft code around.

IMO its generally more readable as well to non-dev than C# and to dev's outside the Java/C# ecosystem (e.g. Node, Go, etc). I've shown F# code back in the day to non-tech stakeholders and they typically understand it (e.g. data modelling).

▲

arwhatever 2 days ago | parent | prev | next [-]

Unions remain the killer F# feature missing from C#.

Also, basic object initialization in C# has turned into a nightmare with recent versions. You need a flowchart to select among the 18 syntax options which suite your current needs.

With F# (and other newer languages), record fields are either `T` or `T option`. No need to worry about whether the value needs to be computed in a constructor and then remain immutable, whether it needs to be initialized by an object initializer and/or a constructor or not, whether it needs to remain interior-ly mutable throughout the life of the record, and so on. (Although as I recall you do still need to consider null values assigned to non-nullable references in your F# code that consumes C#.)

	▲	twodave a day ago \| parent [-]
		There's a draft spec out there for discrete unions in C# fwiw. I wouldn't be surprised to see it in another version or two. And while I agree that I don't love some of the object initialization patterns C# allows--I respect that other people might have different style than me and don't mind ignoring that those styles exist when writing my own stuff :) My general rule goes something like: 1. Use record types for any simple data structure 2. Avoid using primary constructors (even on record types). 3. Use { get; init; } properties for everything unless there's a good reason not to. 4. For things that need to carry internal state, have different methods for mutations, emit events, etc., use a class with regular old constructors and either { get; } (for immutable) or { get; private set; } (mutable) properties as needed.

▲

marcosdumay 3 days ago | parent | prev | next [-]

You may start to get a point when C# gets a two-directional type inference system. As it's now, any functional-looking code requires so much boiler plate that it's shorter and less bug-prone to copy your functions code everywhere you want to use them.

▲

int_19h 2 days ago | parent [-]

Can you give an example of said boiler plate?

	▲	marcosdumay a day ago \| parent \| next [-]
		Just try to make any generic high order function in C#. Any one you can think of.
	▲	DeathArrow 2 days ago \| parent \| prev [-]
		Using OneOf library or something similar instead of discriminated unions / sum types. Trying to use a functional pipeline instead of DI.

▲

DeathArrow 2 days ago | parent | prev [-]

F# can be nicer to use for a functional programming style.

It's not always about the features such as keywords, built-in functionality and types. It's also how language features work together.

C# is more fit for an imperative or OOP style when F# is more fit for a functional style.