The first thing I worry about reading something like this is how leaky the abstraction will be. I would love to ditch JavaScript for pretty much anything else but if I need to think about the JavaScript part anyway because of certain things that I can or cannot do I prefer to think in JavaScript from the get go.
This is a tricky one. If the abstractions were not leaky, you would not be able to interoperate with JavaScript libraries and you'd have to reimplement everything that powers the modern JS ecosystem. On the other hand, if the abstractions were too leaky, you'd lose all benefits of a nice language like F#.
I think Fable strikes the right balance. There are some leaky aspects of how it compiles to JS, but this means that you can quite well use it with existing JS libraries and for things like parsing JSON (you can just cast JSON object to F# records and it'll work).
So, you need to think about something about the JS part when you want to do JavaScript-y things, but you still get plenty of nice help from the F# compiler when writing the logic that the functional-first style makes so much easier.
In my experience with Fable, this pragmatic approach is what makes it great.
Their isn't actually much of an abstraction in one direction, valid ES6 is valid TS and the types are inter-operable.
Throw in better typing, proper classes, down compiling of async/await to ES3/ES5 (still magic to me) and the ability to progressively port from one to the other (and you can even get a lot of the TS benefits just by annotating your existing JS as a good first step to moving to TS) and for me it was a no-brainer.
I don't think TS is a pretty language but it's a fantastic approach to getting from shitty-A to less shitty-B.
Pragmatism wins for me as much as I'd love to just write everything client side in something else.
I have to agree, the pragmatic and thoughtful approach that the TS team has brought to the language makes it reasonable to write in and easy enough to reason about at any given time. Plus, being a superset means that if you want to 'drop into' JS to take advantage of some quirk or whatever at any time, you can just disable your linter and do the deed.
Coming from a C# and Python fan, TS hits the mark pretty solidly on all levels.
> Plus, being a superset means that if you want to 'drop into' JS to take advantage of some quirk or whatever at any time, you can just disable your linter and do the deed.
This is an exact example of what GP was talking about with leaky abstractions though. You don't have to just learn TS to use TS, you need to learn TS and JS.
IMO a proper, strict typed language; and plain Javascript; are both much better options than TS.
> You don't have to just learn TS to use TS, you need to learn TS and JS.
I don't understand this. TypeScript is not a different language. It's just JavaScript with some type annotations. If you had never used JavaScript before and learned TypeScript you could immediately write plain JavaScript as well.
Typescript has grown into way more than just "JavaScript with some type annotations". It's a much bigger superset with lots of language features that JS doesn't have.
TS is not a leaky abstraction; TS is no abstraction at all. It extends JavaScript, not alters or replaces it. As a result, all JS is automatically valid TS.
Well I'm perfectly fine with something what languages like C++ or Objective-C are to C since the whole C interface is still available. If I have a problem in the C layer I can touch that directly and fix it. But I don't think it's possible to mix F# and JS code in the same code file without doing really ugly stuff.
I haven't used it myself but the Ionide plugin for VSCode, which creates a full featured IDE experience for F#, is done in F# transpiled to javascript. The maintainers seems to enjoy it.
i saw somewhere an article mentioning "why don't more people write f#" (mebbe it was on h/n)? I have never had to really worry about concurrency and if you've got a good familiarity with C#, you're halfway there to being a very productive in TypeScript, so I don't see exactly where F# fits in, considering the best parts of C# are its functional bits.
The fact that the best parts of C# are its few functional bits might be a good hint that if you had a language that was designed around those good bits, it would be so much better ;-).
I don't expect to convince anyone in a HN discussion, because that's not how arguments about programming languages work, but have a look at testimonials (http://fsharp.org/testimonials). You'll see that many people who started using F#, are very happy with it because it lets them solve problems faster with fewer bugs and they enjoy it more.
Ocaml is the worst variant of ML in my opinion. Like usual, programmers always seem intent on making the worst option the biggest one (seriously, SML syntax is better than Ocaml syntax in almost every way).
> (seriously, SML syntax is better than Ocaml syntax in almost every way)
Except that for the most part, that's subjected, and even more importantly, there are plenty of reasons to prefer OCaml over SML even if you don't like the syntax.
That would require Microsoft, the F# team, and the vocal F# community members to actually want F# to be a proper first-class .NET citizen, which sadly isn't the case.
As a sometimes-user of F#, I’m quite happy not caring about a dead-end technology like UWP and .NET Native, thank you very much. I’m glad everyone else seems to agree about that, too.
All this FUD and hostility from the F# community (including the Fable devs) towards UWP, or anything that's of interest to most Windows and C# developers making the switch, is why F# will never be popular.
And for most people who need to have their code running on anything else than Windows, F# and .NET wouldn't be their first choice anyway, given that there are plenty of better alternatives around, like Haskell, Scala, ReasonML, OCaml etc.
Nothing is being moved. UWP has been here since the dawn of Windows 10, which evolved from WinRT, going back to Windows 8, and is constantly being extended with new APIs.
I've been holding of targeting UWP, until proper F# support.
I have experience with plenty of languages and technologies, including C, C++, Rust, Scala, OCaml, Haskell, Clojure, Elm, Idris, WinForms, WPF, DirectX and dabbled with Silverlight. Migrating from WPF or Silverlight towards UWP shouldn't be a problem.
F# has been my favorite language since 2008, but the hostile anti-UWP, anti-Windows community, compounded with the lack of abstraction features such as ML functors, higher-kinded types, type-classes and terrible modern Windows client support, are driving me away from it.
UWP is pretty mature now and all modern default 1st party Windows apps and critical UI components such as start menu, action center and settings rely on it, and more is being migrated towards it all the time, there is no sign of UWP going away anytime soon.
Except for Windows Phone getting killed, which was the _main_ device type for UWP. The Windows app store is the same graveyard that it was in late 2015 when the announcements around new Windows Phones piqued my curiosity. It looks like that's simply not a thing anymore. I'm betting my money on Xamarin and the browser for a client application, not UWP. There's just no point to it.
The main device type for UWP is any Windows 10 device. See the list of benefits mentioned in the link above, which extend beyond phones. I've never owned a Windows Phone, yet I always prefer UWP apps.
Also there is a big market for 2-in-1 tablets, and new small Windows on ARM devices are coming out very soon.
Not every kind of client app is suitable for the browser, especially if you care about performance and deep native platform integration. And I'd rather not deal with JS frameworks when not targeting the web.
UWP is the future of Windows APIs, in case you missed Windows Developer day earlier this month.
So if F# doesn't speak UWP, the community keeps tweeting that GNU/Linux is so much better than Windows, and that we enterprise devs just don't get it, should we bet which of those technologies will last longer on MS roadmap?
My F# code runs on Linux. My client code is migrating to the web and mobile, as is just about every enterprise in the US. Why would I watch Windows developer day?
In some scenario support is more stable, other experimental, other are not supported.
like every technology.
Because budget is not infinite, you need to prioritize.
Just to show you things happened MS tech related to F# and .NET in the last two years:
- .net core
- .net standard (is not the same as .net core)
- new project system for VS
- new .net sdk (that mean work to support these on VS)
- portable pdb
- F# 4.1
- temporary stuff like project.json, who added work and was replaced
- new .net templating
- F# in VS now use roslyn workspaces (yes, that's big)
- integration of VisualF# powertools in default VS extension
- f# bundled in .net sdk and compiler in .net core sdk
- F# on azure notebooks
- F# on azure functions
- VS 2017
- VS 2017 installer (yes, that was annoying)
And that list is just some of MS technologies, who VF# team need to support/adapt too.
NOTE the list doesnt contains things created from community itself, like Fable. and some of these were added by community
Yes, and there is too:
- UWP
- .NET Native
- Corert
but you need to prioritize and choose your (moving) targets.
So ihmo while UWP can be nice to have (ihmo), was put in a lower priority than the others.
When you choose there are lot of factors:
- time to implement
- unknown
- other things open in parallel scenarios
- support needed to complete/make it usable
Community help a lot the F# development, and also a lot the VS VF# extension, see the repo.
Because F# has lot of OSS in the dna.
But that doesnt mean we cannot complain when things need improvements, in some important scenario.
And as a note, the MS VF# project manager was awarded the `F# community Hero award`, that mean the community like and support his work (the award is indipendent and run from community voting)
To me and many early investors of F# (loyal Windows developers), the current direction is the worst thing that happened to the language.
UWP is not just a nice to have, it's the backbone of client Windows development right now and going forward.
I used to be a huge F# advocate and all the people I converted to F# over the years have left, due to the lacking Windows support. And the VF# program manager siding with anti-UWP, anti-Windows, anti-MS detractors isn't helping the situation.
We don't do Azure and .NET Core is meaningless for us, as it doesn't have GUI support and EF Core is a tiny subset of EF 6.
As consulting company we are not bound to a single language or platform. When we do UNIX projects we use programming languages that are better fit for such platforms, and that isn't .NET Core.
For us .NET only matters for Windows related development, and there F# keeps being the black swan since its early days.
No tooling support for Windows Forms, XAML, Blend, ASP.NET, EF, WCF and now not even .NET Native, because for some strange political reason F# is separated from the .NET development group, and never considered on the decisions of the .NET platform as such.
With C# and VB.NET our customers on Microsoft solutions can be 100% sure their code is safe regardless of what Microsoft thinks to do next, at maximum they would need to re-write parts of it.
I run a few things on .NET Core today and it’s great. I’ll probably runs some things in Azure soon enough. I just think UWP has no future because its primary device type (Windows phone) is dead, and it hasn’t seen any uptake in the enterprise to replace Winforms and WPF. F# seems just fine to me, and it’s supported for my app type. Perhaps you need to rethink your choices in development technologies.
I'm tempted to do my own little part, putting my money where my mouth is, by advertising, perhaps on LinkedIn, that F# is exactly what is necessary to lure me away from my current gig and on to your opportunity.
And I can go pretty far - I have one working spouse, no major commitments, and have lived in one spot long enough I would prefer that my next role be elsewhere.
Admittedly, any other comparable (or even better?) language could lure me just as readily.
Mads Torgerson (the head of the Roslyn project; C#/VB Compiler) showed once a slide, that c# devs are counted in millions, VB devs in 100k steps and F# devs in 10k steps.
F# is a wonderful thing for the ecosystem, but practically of no importance regards priorities.
IMHO: To make UWP and F# a thing, UWP need to be remodeled to a primary react like system. That however will never be a story, considering the state driven UI development MS is doing for decades.
So when they purposefully dismiss F# and say it's just useful for scientific and engineering (with a touch of finance) they find they don't get much adoption from general business developers?
F#, even if used as a better C#, is still a win. C# has improved a ton since F# appeared, but it's still clunky. Microsoft should have had a push, F# for everyone, but this is the company that had to be dragged into generics (by the F# people) so I don't know what we'd expect.
All F# needs is real committment to level tooling. Instead it's an afterthought. It's enough to give even me pause when starting a project.
Sssh. Speaking as one of the two people who know F#, I'd be very sad if others learned about it. It's my secret weapon that lets me solve problems that would otherwise take me weeks in a matter of days.
Why not show a code sample on the homepage? None of Home, Docs, or Samples have a single code snippet on the entire page, you have to click through.
Crystal and Rust are good examples of language homepages that give you an idea of what you're getting into up front. Or for a transpiled language, PureScript.
Sure, but I would still like to see how I would use this in the context of a browser. How do I interact with existing JS libraries? How would I use it with React or something else? How would I even call window.alert()?
For React, install the appropriate library[1] and then call the functions you need from the Fable.Helpers.React.* namespace. If you want to see a complete implementation of Fable + React in action, the canonical example is https://github.com/SAFE-Stack/SAFE-BookStore
For alert(), you'll find it in Fable.Import.Browser.window.alert()
(In case you're wondering, the Fable convention is that the Fable.Import.* namespace is used for pure JS bindings with no business code, while libraries with an actual translation layer are placed in the Fable.Helpers.* namespace.)
you can go to the samples... but you will quickly notice a lot of the samples are canvas orineted things, because Fable gets to be in control to do things F# like. There's a vue and react example, but the code doesn't show any real advantage. Very little examples of typical web pages.... just a link to fable-elmish..... so... you may as well use elm. This is a common problem for F# in general, it hasn't really carved a slice of a world where it dominates. It's a nice language, but hard to make it a first choice.
Though one area I think it's quite nice is parsing, I like FParsec
Hi, fable-elmish author here. Elm is great if you don't care about investing into two ecosystems or don't have a backend, or don't have a Native client in addition to Web, or don't care about what JS ecosystem has to offer.
Fable lets one use F# for both frontend and backend, and being able to share the code (models in particular, but really anything) while maintaining clear separation of tiers reduces your code base and dramatically improves quality w/o the need for elaborate tests.
Fable-elmish lets one use the same frontend code and architecture to write Native and Web apps. Again, YMMV, but at our company being able to transition an entire team between completely different types of projects avoids expertise silos and makes truly cross-functional teams possible.
We have OSSed a lot of our backend tech that helps building event-driven system in F# as well, in case anyone's interested: https://prolucid.github.io.
As Tomas said, just like Lisp in Paul Graham's "Beating the Averages" has been his secret weapon, F# is ours.
I have been watching and trying Fable for two months after I wrote a demo in ReasonML/BuckleScript, because I need a full-stack language for my side projects and Fable is much complete and stable, and the backend story is also much better than OCaml or BS bindings for Nodejs.
Can anyone point to a resource for learning F# from scratch?
I have tried a few tutorials but the syntax is so foreign to me that I've found it hard to grasp.
What would be awesome with a project like Fable would be to have a tutorial for existing JavaScript devs to learn F#. For example, have JavaScript and F# code side-by-side.
Try this course from FSharpTV: https://fsharp.tv/courses/fsharp-programming-intro/. They have a lot of other content too but this is the introductory course that's aimed towards beginners. It might be helpful.
73 comments
[ 0.21 ms ] story [ 132 ms ] threadI think Fable strikes the right balance. There are some leaky aspects of how it compiles to JS, but this means that you can quite well use it with existing JS libraries and for things like parsing JSON (you can just cast JSON object to F# records and it'll work).
So, you need to think about something about the JS part when you want to do JavaScript-y things, but you still get plenty of nice help from the F# compiler when writing the logic that the functional-first style makes so much easier.
In my experience with Fable, this pragmatic approach is what makes it great.
Isn't a "JSON object" just a string?
Their isn't actually much of an abstraction in one direction, valid ES6 is valid TS and the types are inter-operable.
Throw in better typing, proper classes, down compiling of async/await to ES3/ES5 (still magic to me) and the ability to progressively port from one to the other (and you can even get a lot of the TS benefits just by annotating your existing JS as a good first step to moving to TS) and for me it was a no-brainer.
I don't think TS is a pretty language but it's a fantastic approach to getting from shitty-A to less shitty-B.
Pragmatism wins for me as much as I'd love to just write everything client side in something else.
Coming from a C# and Python fan, TS hits the mark pretty solidly on all levels.
This is an exact example of what GP was talking about with leaky abstractions though. You don't have to just learn TS to use TS, you need to learn TS and JS.
IMO a proper, strict typed language; and plain Javascript; are both much better options than TS.
I don't understand this. TypeScript is not a different language. It's just JavaScript with some type annotations. If you had never used JavaScript before and learned TypeScript you could immediately write plain JavaScript as well.
If you want to make your own opinion, we have a really good guide here: https://medium.com/@zaid.naom/f-interop-with-javascript-in-f...
I don't expect to convince anyone in a HN discussion, because that's not how arguments about programming languages work, but have a look at testimonials (http://fsharp.org/testimonials). You'll see that many people who started using F#, are very happy with it because it lets them solve problems faster with fewer bugs and they enjoy it more.
https://news.ycombinator.com/item?id=15574409
Except that for the most part, that's subjected, and even more importantly, there are plenty of reasons to prefer OCaml over SML even if you don't like the syntax.
https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many...
https://np.reddit.com/r/csharp/comments/75mc1m/announcing_uw...
All this FUD and hostility from the F# community (including the Fable devs) towards UWP, or anything that's of interest to most Windows and C# developers making the switch, is why F# will never be popular.
And for most people who need to have their code running on anything else than Windows, F# and .NET wouldn't be their first choice anyway, given that there are plenty of better alternatives around, like Haskell, Scala, ReasonML, OCaml etc.
It's nice when you're where the cheese is currently at, that's not what I'm talking about though.
I do hope for your sake you don't wind up in the next lifeboat after the Silverlight crew, I really genuinely do. Good luck!
I have experience with plenty of languages and technologies, including C, C++, Rust, Scala, OCaml, Haskell, Clojure, Elm, Idris, WinForms, WPF, DirectX and dabbled with Silverlight. Migrating from WPF or Silverlight towards UWP shouldn't be a problem.
F# has been my favorite language since 2008, but the hostile anti-UWP, anti-Windows community, compounded with the lack of abstraction features such as ML functors, higher-kinded types, type-classes and terrible modern Windows client support, are driving me away from it.
UWP is pretty mature now and all modern default 1st party Windows apps and critical UI components such as start menu, action center and settings rely on it, and more is being migrated towards it all the time, there is no sign of UWP going away anytime soon.
Except for Windows Phone getting killed, which was the _main_ device type for UWP. The Windows app store is the same graveyard that it was in late 2015 when the announcements around new Windows Phones piqued my curiosity. It looks like that's simply not a thing anymore. I'm betting my money on Xamarin and the browser for a client application, not UWP. There's just no point to it.
Also there is a big market for 2-in-1 tablets, and new small Windows on ARM devices are coming out very soon.
http://www.zdnet.com/article/microsoft-to-pc-makers-lets-mak...
Not every kind of client app is suitable for the browser, especially if you care about performance and deep native platform integration. And I'd rather not deal with JS frameworks when not targeting the web.
So if F# doesn't speak UWP, the community keeps tweeting that GNU/Linux is so much better than Windows, and that we enterprise devs just don't get it, should we bet which of those technologies will last longer on MS roadmap?
The F# comunity has become quite strange, always bashing the products of the company that actually develops their programming language.
Not a good way to keep them motivated into supporting F#.
In some scenario support is more stable, other experimental, other are not supported. like every technology.
Because budget is not infinite, you need to prioritize.
Just to show you things happened MS tech related to F# and .NET in the last two years:
- .net core
- .net standard (is not the same as .net core)
- new project system for VS
- new .net sdk (that mean work to support these on VS)
- portable pdb
- F# 4.1
- temporary stuff like project.json, who added work and was replaced
- new .net templating
- F# in VS now use roslyn workspaces (yes, that's big)
- integration of VisualF# powertools in default VS extension
- f# bundled in .net sdk and compiler in .net core sdk
- F# on azure notebooks
- F# on azure functions
- VS 2017
- VS 2017 installer (yes, that was annoying)
And that list is just some of MS technologies, who VF# team need to support/adapt too.
NOTE the list doesnt contains things created from community itself, like Fable. and some of these were added by community
Yes, and there is too:
- UWP
- .NET Native
- Corert
but you need to prioritize and choose your (moving) targets.
So ihmo while UWP can be nice to have (ihmo), was put in a lower priority than the others.
When you choose there are lot of factors:
- time to implement
- unknown
- other things open in parallel scenarios
- support needed to complete/make it usable
Community help a lot the F# development, and also a lot the VS VF# extension, see the repo. Because F# has lot of OSS in the dna.
But that doesnt mean we cannot complain when things need improvements, in some important scenario.
And as a note, the MS VF# project manager was awarded the `F# community Hero award`, that mean the community like and support his work (the award is indipendent and run from community voting)
UWP is not just a nice to have, it's the backbone of client Windows development right now and going forward.
I used to be a huge F# advocate and all the people I converted to F# over the years have left, due to the lacking Windows support. And the VF# program manager siding with anti-UWP, anti-Windows, anti-MS detractors isn't helping the situation.
As consulting company we are not bound to a single language or platform. When we do UNIX projects we use programming languages that are better fit for such platforms, and that isn't .NET Core.
For us .NET only matters for Windows related development, and there F# keeps being the black swan since its early days.
No tooling support for Windows Forms, XAML, Blend, ASP.NET, EF, WCF and now not even .NET Native, because for some strange political reason F# is separated from the .NET development group, and never considered on the decisions of the .NET platform as such.
With C# and VB.NET our customers on Microsoft solutions can be 100% sure their code is safe regardless of what Microsoft thinks to do next, at maximum they would need to re-write parts of it.
If it comes to be, lets see how long F# survives without Microsoft support.
I run a few things on .NET Core today and it’s great. I’ll probably runs some things in Azure soon enough. I just think UWP has no future because its primary device type (Windows phone) is dead, and it hasn’t seen any uptake in the enterprise to replace Winforms and WPF. F# seems just fine to me, and it’s supported for my app type. Perhaps you need to rethink your choices in development technologies.
https://np.reddit.com/r/Windows10/comments/75lgti/announcing...
You don't seem to understand what UWP is about.
I did rethink my choices in technology, F# is not worth my time for production code anymore.
And I can go pretty far - I have one working spouse, no major commitments, and have lived in one spot long enough I would prefer that my next role be elsewhere.
Admittedly, any other comparable (or even better?) language could lure me just as readily.
F# is a wonderful thing for the ecosystem, but practically of no importance regards priorities.
IMHO: To make UWP and F# a thing, UWP need to be remodeled to a primary react like system. That however will never be a story, considering the state driven UI development MS is doing for decades.
F#, even if used as a better C#, is still a win. C# has improved a ton since F# appeared, but it's still clunky. Microsoft should have had a push, F# for everyone, but this is the company that had to be dragged into generics (by the F# people) so I don't know what we'd expect.
All F# needs is real committment to level tooling. Instead it's an afterthought. It's enough to give even me pause when starting a project.
It's all true ;) Enjoy the sharp!
Why significance does that have in javascript?
http://fable.io/repl/
http://funscript.info/
"you only pay for what you get"
Crystal and Rust are good examples of language homepages that give you an idea of what you're getting into up front. Or for a transpiled language, PureScript.
For alert(), you'll find it in Fable.Import.Browser.window.alert()
(In case you're wondering, the Fable convention is that the Fable.Import.* namespace is used for pure JS bindings with no business code, while libraries with an actual translation layer are placed in the Fable.Helpers.* namespace.)
[1] https://www.nuget.org/packages/Fable.React/
Though one area I think it's quite nice is parsing, I like FParsec
Fable lets one use F# for both frontend and backend, and being able to share the code (models in particular, but really anything) while maintaining clear separation of tiers reduces your code base and dramatically improves quality w/o the need for elaborate tests.
Fable-elmish lets one use the same frontend code and architecture to write Native and Web apps. Again, YMMV, but at our company being able to transition an entire team between completely different types of projects avoids expertise silos and makes truly cross-functional teams possible.
We have OSSed a lot of our backend tech that helps building event-driven system in F# as well, in case anyone's interested: https://prolucid.github.io.
As Tomas said, just like Lisp in Paul Graham's "Beating the Averages" has been his secret weapon, F# is ours.
We are a small team working on it, and we try to constantly improve it.
I will provide you some links here if you can find them useful:
- File explorer using electron: https://github.com/fable-compiler/samples-electron#samples
- Pixi.js samples (quite new we are working on them): https://github.com/fable-compiler/samples-pixi/
- Elmish central website: https://fable-elmish.github.io/
- Bulma wrapper for Elmish: https://mangelmaxime.github.io/Fulma/
- A demo of Fulma + Elmish
And also, a really cool place is Fable awesome: https://github.com/kunjee17/awesome-fableA Server-Client full-stack scaffold: https://github.com/SAFE-Stack/SAFE-BookStore
A React-Native scaffold: https://github.com/SAFE-Stack/SAFE-Nightwatch
I have tried a few tutorials but the syntax is so foreign to me that I've found it hard to grasp.
What would be awesome with a project like Fable would be to have a tutorial for existing JavaScript devs to learn F#. For example, have JavaScript and F# code side-by-side.
And try the https://fsharpforfunandprofit.com/ site too.