4 ms·

The bad of F# is trying to find work in F#. I have the freedom to choose F# at work but it often seems like the wrong choice. If I want a web app I'm pulling in

by xupybd 5y ago

The bad of F# is trying to find work in F#. I have the freedom to choose F# at work but it often seems like the wrong choice. If I want a web app I'm pulling in so many extra dependencies.

dsizzle 5y ago
It sounds like you did find work in F# (if you wanted it)? What language are you using?
- xupybd 5y ago
  I use a tiny bit of F# in small isolated scripts. PHP and JS in the largest project. C# in small GUIs. The gui builder saves so much time and I think they could find any reasonable developer to replace me. If I use too much F# they would have a hard time finding someone. I also use a lot of SQL I think it's fantastic for data manipulation. There are some legacy Java apps as well. I don't mind working with most languages (the only exception is Perl, I'm not a fan). I just love working with F#, so much less boilerplate and type safety. It's so much more fun. But I want everything I do to last that means reducing the number of dependencies and build tools I introduce. Fable is amazing but a SAFE stack app will bring in a huge number of extra dependencies and I'm not sure what maintenance would be like in 10 years. As it is I'm working with a stack of docker containers that compile an old version of PHP and drag in legacy libraries.
Eji1700 5y ago
The upside is you can use all the net core libraries. The downside is then you have to know how to write wrappers/helpers for them and probably don't get to use all the cool stuff that comes with F# because you're using a library written for C#. It is by and far my favorite language, but i'm also super lucky i have, relatively, low code demands (basic ETL/CRUD stuff) and the ability to choose what I use in my environment. I hope to god it gets more traction because I think it's amazing, but being second child to C# hurts it in a lot of small ways. Especially because "well we don't need that library, just use the netcore one" is such a common reaction in the community, but it's really not ideal.
- hvidgaard 5y ago
  > The downside is then you have to know how to write wrappers/helpers for them and probably don't get to use all the cool stuff that comes with F# because you're using a library written for C#. For any long term project you should own your abstraction anyway, i.e. a wrapper/interface. Not only do you need it to properly test it, you never know when that 1 hour spend creating your abstraction, gives you back in ease when an external dependency inevitably needs to be replaced.
  - ljm 5y ago
    I think there's a fundamental mistake in architecting around pluggable dependencies. I've never worked in a codebase that was improved by treating a dependency as a thing that could be replaced at any time, in fact it only made me question why dependencies were expected to change so often. Maybe you want to spend more time prototyping if even the basic foundation of your software is so volatile. You know? It's not the same as keeping your data layer and HTTP layer separate, or your local state separate from your rendering layer, and encapsulating business logic. Nor is it the same as building a modular system designed around your business's domains, so you can change or replace those as the needs of the business shift over time.
    - hvidgaard 5y ago
      It's not so much that you expect them to change, but when developing with unittests it's a necessity. And it makes it possible to have the right degree of in memory component and integration testing. It forces you to think about the interface with that dependency, and ask the right questions instead of potentially using some other domains abstraction a lot. It's not different than thinking in modular design. The added benefit is that when, not if, you have to replace some dependency it's simple.
    - piaste 5y ago
      Depends on what it is you're encapsulating. For example, we encapsulate our email sending service (Sendgrid). Sendgrid has a pretty good client library, so other than providing a slightly more idiomatic F# API, our wrapper layer doesn't do much. However, (1) sending email is a very straightforward service, so if Sendgrid ever becomes expensive, unreliable, or otherwise limited, replacing it with a different service is quite realistic. (As opposed to e.g. a database or caching layer where you would probably have to also review all the _logic_ if you switch to a different engine). And (2), we don't want to send real emails during tests (especially e.g. fuzzy or property which run en masse), so you actually want a honest-to-god mock here.
nestorD 5y ago
Funny thing, the very first job offer I received on Linkedin was for a F# job (I was still a student at the time).
aloisdg 5y ago
If you are in France, Spain or if you agree to relocate in one of this two countries, I have a company for you.
- hawk_ 5y ago
  Though not OP, would love to know that for Spain.

by xupybd 5y ago

The bad of F# is trying to find work in F#. I have the freedom to choose F# at work but it often seems like the wrong choice. If I want a web app I'm pulling in so many extra dependencies.

dsizzle 5y ago

It sounds like you did find work in F# (if you wanted it)? What language are you using?

xupybd 5y ago
I use a tiny bit of F# in small isolated scripts. PHP and JS in the largest project. C# in small GUIs. The gui builder saves so much time and I think they could find any reasonable developer to replace me. If I use too much F# they would have a hard time finding someone. I also use a lot of SQL I think it's fantastic for data manipulation. There are some legacy Java apps as well. I don't mind working with most languages (the only exception is Perl, I'm not a fan). I just love working with F#, so much less boilerplate and type safety. It's so much more fun. But I want everything I do to last that means reducing the number of dependencies and build tools I introduce. Fable is amazing but a SAFE stack app will bring in a huge number of extra dependencies and I'm not sure what maintenance would be like in 10 years. As it is I'm working with a stack of docker containers that compile an old version of PHP and drag in legacy libraries.

Eji1700 5y ago

The upside is you can use all the net core libraries. The downside is then you have to know how to write wrappers/helpers for them and probably don't get to use all the cool stuff that comes with F# because you're using a library written for C#. It is by and far my favorite language, but i'm also super lucky i have, relatively, low code demands (basic ETL/CRUD stuff) and the ability to choose what I use in my environment. I hope to god it gets more traction because I think it's amazing, but being second child to C# hurts it in a lot of small ways. Especially because "well we don't need that library, just use the netcore one" is such a common reaction in the community, but it's really not ideal.

hvidgaard 5y ago
> The downside is then you have to know how to write wrappers/helpers for them and probably don't get to use all the cool stuff that comes with F# because you're using a library written for C#. For any long term project you should own your abstraction anyway, i.e. a wrapper/interface. Not only do you need it to properly test it, you never know when that 1 hour spend creating your abstraction, gives you back in ease when an external dependency inevitably needs to be replaced.
- ljm 5y ago
  I think there's a fundamental mistake in architecting around pluggable dependencies. I've never worked in a codebase that was improved by treating a dependency as a thing that could be replaced at any time, in fact it only made me question why dependencies were expected to change so often. Maybe you want to spend more time prototyping if even the basic foundation of your software is so volatile. You know? It's not the same as keeping your data layer and HTTP layer separate, or your local state separate from your rendering layer, and encapsulating business logic. Nor is it the same as building a modular system designed around your business's domains, so you can change or replace those as the needs of the business shift over time.
  - hvidgaard 5y ago
    It's not so much that you expect them to change, but when developing with unittests it's a necessity. And it makes it possible to have the right degree of in memory component and integration testing. It forces you to think about the interface with that dependency, and ask the right questions instead of potentially using some other domains abstraction a lot. It's not different than thinking in modular design. The added benefit is that when, not if, you have to replace some dependency it's simple.
  - piaste 5y ago
    Depends on what it is you're encapsulating. For example, we encapsulate our email sending service (Sendgrid). Sendgrid has a pretty good client library, so other than providing a slightly more idiomatic F# API, our wrapper layer doesn't do much. However, (1) sending email is a very straightforward service, so if Sendgrid ever becomes expensive, unreliable, or otherwise limited, replacing it with a different service is quite realistic. (As opposed to e.g. a database or caching layer where you would probably have to also review all the _logic_ if you switch to a different engine). And (2), we don't want to send real emails during tests (especially e.g. fuzzy or property which run en masse), so you actually want a honest-to-god mock here.

nestorD 5y ago

Funny thing, the very first job offer I received on Linkedin was for a F# job (I was still a student at the time).

aloisdg 5y ago

If you are in France, Spain or if you agree to relocate in one of this two countries, I have a company for you.

hawk_ 5y ago
Though not OP, would love to know that for Spain.