6 ms·

Just use F# instead and you will have Rust, typescript, Javascript, dart, python all at once https://twitter.com/FableCompiler/status/1550429007443017729?s=20&t

Just use F# instead and you will have Rust, typescript, Javascript, dart, python all at once https://twitter.com/FableCompiler/status/1550429007443017729?s=20&t=XwBoT5kiWwJGy7-9VCghbw https://twitter.com/FableCompiler/status/1550429007443017729...

pjmlp 4y ago
Unfortunely not with same tooling level as C# and VB enjoy.
- owenm 4y ago
  I used to use Visual Studio and VSMac for my F# experimentation. Over the past couple of years, Ionide has got so much better that I've switched completely over to it from VS for all my F# work. The new 7.0 release a couple of days ago looks to have continued this trend.
  - pjmlp 4y ago
    Try to do a GUI or EF data model design in Ionide, hot code reload while changing a GUI design, or using annotations from code generators.
    - throw868788 4y ago
      My view: F#, or to be honest a cross-platform IDE like VS Code isn't probably appropriate for many of these apps or rather the dev workflow that Microsoft promote in those frameworks feels like old .NET to me. The frameworks themselves weren't designed for a minimal IDE, and language first development initially often assuming dev is in full Visual Studio with GUI XAML editors, EF designers, etc. To be bluntly honest with my opinion it isn't a dev workflow that would fly/got started in other more open languages including F# which should be develop-able and maintainable with a lot less tooling support. F# feels like a different dev workflow than C#, which IMO is a very good thing in F#'s favor. It feels more like coding JS, Go, etc to me with static typing and richer features. I also think EF, as it is designed, doesn't lean to the FP approach that well. I personally don't like EF - I'm happy with something in .NET like DbUp for migrations and straight SQL. Normally I get better performance anyway doing this and in the age of microservices I feel this pattern actually makes it easier to change DB's if you need to (but I still assert you probably never will without a rewrite most of the time) - just use the different query language and port your data access layer. Move to Redis? Just port your F# module that queries the DB in SQL to Redis code. In F# it also allows a richer data modelling experience doing it this way (e.g use of DU's for modelling cases in your domain) since db logic is decoupled from your domain types. I never believed my domain model had to look similar to my DB table design which is what EF typically encourages. Especially with the modern features of DB's like Postgres you are leaving more and more performance on the table. In the apps I've written doing that leads to lower DB performance than otherwise, sometimes for some quite trivial apps. TL;DR: Tooling like Resharper, designers, etc is nice but often is there IMO because the language itself is bloated and not expressive enough to just state your original intent there succinctly. If the code is enough then F# can express pretty much what C# can.
      - pjmlp 4y ago
        Languages alone are worthless what matters is the whole development experience. When F# came out in 2010, it appeared it would be made to share the podium with C#, VB and C++/CLI (even that black swan has better tooling on VS). Instead what we have witness is that management doesn't really know where to F#, and naturally they cannot take it from the box. More recently they are positioning to go against Python in data science, when .NET lacks the library ecosystem (ML.NET is still half way there and favours C# anyway), and the Microsoft was able to convince Guido come out of his early requirement with the purpose to improve CPython's performance on the top of the already existing ecosystem. Meanwhile Intel and NVidia are also on the race to improve Python for GPU compute. So in the end that leaves F# as a nicer ML derived language that happens to have access to the .NET libraries, with a community that kind of re-invents what .NET already offers, and a master that to this way is wondering what to do with it, other than a laboratory for C# features.
- exyi 4y ago
  Rider has pretty decent F# support. Maybe not that many refactorings available, but it's IMHO worth it for the better language ;)
  - pjmlp 4y ago
    Only if we consider the language in itself, without the .NET ecosystem for GUI, databases, code generators,... Where it is pretty much DYI.
    - runevault 4y ago
      Depending on what code generation you are doing you have alternatives. Biggest one being Type Providers which are arguably better than anything I've seen from source generators so far (which I found incredibly buggy when I used them, and at one point I had to reinstall visual studio it bugged out my environment so much when messing with writing my own). And see above for database, Type Providers are great at least for SQL server, I think the sql one also works for PostGres but I never used it so not certain. GUI is a mess last I knew though I agree.
      - pjmlp 4y ago
        You mean the traditional World Data Bank example that we got to see at each F# conference with little relevance for .NET shops? What I care about are the code generation libraries that get served alongside NuGet packages with attributes, e.g. the ones used by MVVM, MAUI or Blazor.
        throw868788 4y ago
        Just use a mixed solution then i.e. why not both? You're picking one thing that F# isn't great at - generated code tooling which IMO isn't in the spirit of many modern languages anyway. I don't get why some C# devs tend to be antagonistic to F#. Not suited to what you use? That's fine but that doesn't mean it isn't good for others. I've seen dev's coming from other languages to F# and thinking its brilliant that would of never approached C#. I agree that each language has its sweet spot. Looking at their feature sets I think: - Domain modelling, algorithm, business logic, etc is easier with F# in general. C# is getting better than this, but F# is there and has been there for a long time. - Integrating with build tooling and generation tends to be C# because these tools were designed for that target (i.e not the language itself). The value is in the tooling and the engineering in that - C# just happens to be the target. Personally with the above I've found most of the logic tends to be in F# with some C# projects for where the packages needs that build tooling support (i.e. not the language or syntax, but for the tooling or other features of Roslyn). An example would be Grpc.Tools. Most of the time these projects can use generated code anyway so the writing of C# can be kept to a minimum - i.e. not one single C# file in the C# project. Besides I think the learning curve/barrier for a language isn't really syntax, or language features - its the libraries to use, the patterns, the ecosystem, package manager, CI/CD settings, etc. Using F# isn't a large cost once you've learnt all those things that are shared which is way more than isn't.
thrownaway561 4y ago
and you'll be in a nitch market as NO ONE uses F#

pjmlp 4y ago

Unfortunely not with same tooling level as C# and VB enjoy.

owenm 4y ago
I used to use Visual Studio and VSMac for my F# experimentation. Over the past couple of years, Ionide has got so much better that I've switched completely over to it from VS for all my F# work. The new 7.0 release a couple of days ago looks to have continued this trend.
- pjmlp 4y ago
  Try to do a GUI or EF data model design in Ionide, hot code reload while changing a GUI design, or using annotations from code generators.
  - throw868788 4y ago
    My view: F#, or to be honest a cross-platform IDE like VS Code isn't probably appropriate for many of these apps or rather the dev workflow that Microsoft promote in those frameworks feels like old .NET to me. The frameworks themselves weren't designed for a minimal IDE, and language first development initially often assuming dev is in full Visual Studio with GUI XAML editors, EF designers, etc. To be bluntly honest with my opinion it isn't a dev workflow that would fly/got started in other more open languages including F# which should be develop-able and maintainable with a lot less tooling support. F# feels like a different dev workflow than C#, which IMO is a very good thing in F#'s favor. It feels more like coding JS, Go, etc to me with static typing and richer features. I also think EF, as it is designed, doesn't lean to the FP approach that well. I personally don't like EF - I'm happy with something in .NET like DbUp for migrations and straight SQL. Normally I get better performance anyway doing this and in the age of microservices I feel this pattern actually makes it easier to change DB's if you need to (but I still assert you probably never will without a rewrite most of the time) - just use the different query language and port your data access layer. Move to Redis? Just port your F# module that queries the DB in SQL to Redis code. In F# it also allows a richer data modelling experience doing it this way (e.g use of DU's for modelling cases in your domain) since db logic is decoupled from your domain types. I never believed my domain model had to look similar to my DB table design which is what EF typically encourages. Especially with the modern features of DB's like Postgres you are leaving more and more performance on the table. In the apps I've written doing that leads to lower DB performance than otherwise, sometimes for some quite trivial apps. TL;DR: Tooling like Resharper, designers, etc is nice but often is there IMO because the language itself is bloated and not expressive enough to just state your original intent there succinctly. If the code is enough then F# can express pretty much what C# can.
    - pjmlp 4y ago
      Languages alone are worthless what matters is the whole development experience. When F# came out in 2010, it appeared it would be made to share the podium with C#, VB and C++/CLI (even that black swan has better tooling on VS). Instead what we have witness is that management doesn't really know where to F#, and naturally they cannot take it from the box. More recently they are positioning to go against Python in data science, when .NET lacks the library ecosystem (ML.NET is still half way there and favours C# anyway), and the Microsoft was able to convince Guido come out of his early requirement with the purpose to improve CPython's performance on the top of the already existing ecosystem. Meanwhile Intel and NVidia are also on the race to improve Python for GPU compute. So in the end that leaves F# as a nicer ML derived language that happens to have access to the .NET libraries, with a community that kind of re-invents what .NET already offers, and a master that to this way is wondering what to do with it, other than a laboratory for C# features.
exyi 4y ago
Rider has pretty decent F# support. Maybe not that many refactorings available, but it's IMHO worth it for the better language ;)
- pjmlp 4y ago
  Only if we consider the language in itself, without the .NET ecosystem for GUI, databases, code generators,... Where it is pretty much DYI.
  - runevault 4y ago
    Depending on what code generation you are doing you have alternatives. Biggest one being Type Providers which are arguably better than anything I've seen from source generators so far (which I found incredibly buggy when I used them, and at one point I had to reinstall visual studio it bugged out my environment so much when messing with writing my own). And see above for database, Type Providers are great at least for SQL server, I think the sql one also works for PostGres but I never used it so not certain. GUI is a mess last I knew though I agree.
    - pjmlp 4y ago
      You mean the traditional World Data Bank example that we got to see at each F# conference with little relevance for .NET shops? What I care about are the code generation libraries that get served alongside NuGet packages with attributes, e.g. the ones used by MVVM, MAUI or Blazor.
      - throw868788 4y ago
        Just use a mixed solution then i.e. why not both? You're picking one thing that F# isn't great at - generated code tooling which IMO isn't in the spirit of many modern languages anyway. I don't get why some C# devs tend to be antagonistic to F#. Not suited to what you use? That's fine but that doesn't mean it isn't good for others. I've seen dev's coming from other languages to F# and thinking its brilliant that would of never approached C#. I agree that each language has its sweet spot. Looking at their feature sets I think: - Domain modelling, algorithm, business logic, etc is easier with F# in general. C# is getting better than this, but F# is there and has been there for a long time. - Integrating with build tooling and generation tends to be C# because these tools were designed for that target (i.e not the language itself). The value is in the tooling and the engineering in that - C# just happens to be the target. Personally with the above I've found most of the logic tends to be in F# with some C# projects for where the packages needs that build tooling support (i.e. not the language or syntax, but for the tooling or other features of Roslyn). An example would be Grpc.Tools. Most of the time these projects can use generated code anyway so the writing of C# can be kept to a minimum - i.e. not one single C# file in the C# project. Besides I think the learning curve/barrier for a language isn't really syntax, or language features - its the libraries to use, the patterns, the ecosystem, package manager, CI/CD settings, etc. Using F# isn't a large cost once you've learnt all those things that are shared which is way more than isn't.

thrownaway561 4y ago

and you'll be in a nitch market as NO ONE uses F#