Comment by lacampbell | Hacker News Reader

Comment by lacampbell | Hacker News Reader

I love F#, but using F# instead of (type|java)script would add a lot of complexity to my 'full stack'. Let's see I replaced my node.js backend with an F# one, the following issues would arise:

1. I now have two different languages for client and server, and can't share e.g. validation code.

2. Dealing with 2nd class linux support (no REPL)

3. No library that combines the maturity and simplicity of express.js. Yes I am aware of ASP.NET Web API and no I do not think that compares.

So as much as I love pipes and partial application and concise syntax, F# would create an explosion of complexity, not fight it.

EDIT: This also follows the common trend I see of starry eyed functional programmers who - to put it bluntly - don't seem to know what they are criticizing.

Of course some things from here we can do in C#. We can create CardNumber class which will throw ValidationException in there too.

A Result datatype with all the bells and whistles is what, a few hundred lines in C#? I agree that it sucks that there isn't one built in, but if you like them and you're stuck in C#, code one up and forget about the 'issue' ever again.

But that trick with CardAccountInfo can't be done in C# in easy way

That example looks trivially translatable to an abstract class with two concrete sub-classes to me.

EDIT 2:

The F# docs are awful. Struggling to find the API for the Result module. There's a guide on how to use it, but when you look at the core namespace it's missing.

I really don't think it adds complexity. Sure, it's going to be different, so there's a mental hurdle to clear in learning how a new stack works. That doesn't mean it's going to be more complex.

> 1. I now have two different languages for client and server, and can't share e.g. validation code.

You could use Fable to transpile F# to Javascript, keeping a single language

> 2. Dealing with 2nd class linux support (no REPL)

FSI is available under Linux, but I admit it's got some hairs on it. (FWIW, FSI on Windows needs a lot more TLC too).

> 3. No library that combines the maturity and simplicity of express.js. Yes I am aware of ASP.NET Web API and no I do not think that compares.

This is purely a matter of taste. While express.js is very accessible, I don't think it's any more so than Giraffe (a wrapper around ASP.NET Core).

I'm all-in on F# now - once you're over the (mild) initial learning curve, you see huge dividends from the smaller codebase, static typing, fewer null-checks and drastically less testing required.

> You could use Fable to transpile F# to Javascript, keeping a single language

That would only solve your runtime issues. You would still need to write the same code twice.

How do you figure?

Hi, thanks for the open minded response. It's an issue I enjoy discussing.

You could use Fable to transpile F# to Javascript, keeping a single language

That seems like another explosion of complexity. Source maps, mapping F# to a JS constructs when debugging, niche tooling, wrapping other JS libraries in a nicely typed F# package... IME it's best to avoid transpiling anything more exotic than typescript.

FSI is available under Linux, but I admit it's got some hairs on it. (FWIW, FSI on Windows needs a lot more TLC too).

I appear to be mistaken - I remember I was excited when the dotnet tool came out, but then they took away the REPL. FSI is mono only, right?

This is purely a matter of taste. While express.js is very accessible, I don't think it's any more so than Giraffe (a wrapper around ASP.NET Core).

Yes it's very subjective, we can agree to disagree here.

I'm all-in on F# now - once you're over the (mild) initial learning curve, you see huge dividends from the smaller codebase, static typing, fewer null-checks and drastically less testing required.

I love F#, I used it professionally and it was a great experience. And you are right, the conciseness is hard to beat. But the static typing/fewer null checks thing is easily solved in JS land with the typescript compiler.

I think these usually end up with two people agreeing to disagree :)

Yes, you do lose source maps by transpiling, but in my (albeit fairly limited experience), the type checking means I have drastically less debugging to do in the first place. You're right, though, the tooling leaves a lot to be desired (and this is also on the assumption you have TS definitions for third party libraries - I agree it becomes a lot more difficult if you don't).

FSI is available in both Mono and .NET Core 3 (which is still in preview).

I'm able to use FSI with the core-sdk 2.2.300, but I believe FSI is still in preview regardless of which SDK you're using.

What would the concrete implementation of the at class that represents the deactivated credit card look like?

It would be an abstract class with an abstract processPayment method. Then two concrete classes that implement it, each with their own implementation of processPayment.

https://en.wikipedia.org/wiki/Expression_problem

Reply on news.ycombinator.com