I've had fantastic experiences with this platform as well, front- and back-end code compiled together using F#'s robust type system.
Elmish framework provided a nice MVU pattern for the U/I.
And the real icing on the cake was this Thoth.Elmish package which creates statically-typed proxy for your front-end to access your back-end API, more or less transparently. I was always certain that I would some day do something unorthodox causing its automated serialization/deserialization to fail in some difficult-to-troubleshoot way but no, that never happened and it all just worked transparently.
This was hands down the best automated-correctness-checking experience that I've ever had in any framework.
Fable isn't just for view logic. Fable is also really handy for writing puzzle solvers/generators for the browser. I used it in https://vowels.io while using regular preact/js for the views. I found that keeping the fable stuff isolated to lib code gave me less friction.
my experience was the same, although is it possible to do everything with Fable, it works better to glue frameworks with typescript and keep F# as library or some function calls in strategic points.
This looks like a great update: prettier code output plus roughly double the compilation speed. Compilation speed is one of the things that put me off Fable when I kicked the tires a while ago. That and tooling was a mess.
I really like F# as a language, but it's hard to give up the high quality tooling of VS Code + TypeScript + almost any NPM package w/ proper types.
We're an F#-first company and I'd like to share our experience here.
All our new code is in F#, we started off from a C# codebase, so that made the transition somewhat manageable, as new F# code can be directly called from C#, and vice versa (still took over 2 years). All new frontend apps are also being written in F# (using Fable), as of 6 months back, migrating away from TypeScript, this forces everyone into a "design your model first, and well" paradigm. We've written quite a bit of code to blur the lines between traditional backend and frontend development roles, so what we have now are:
- product engineers (who write application logic on both frontend and backend to serve business needs)
Platform/framework engineers try to encapsulate as much magic as possible into computation expressions (F#'s monads), so product engineers can focus simply on writing out business intent, with readability given very high priority. We also make ample use of quotations to do some cool tricks (like predict the future states some type can take, based on current state + available transitions).
Our code written in F# has an order of magnitude fewer bugs when it makes it to production, given the amount of thought we pour in modelling the problem domain accurately, and thanks to functional programming itself. They're also more amenable to business requirements changing, simply because they've been modelled well to start with. Nothing that can't be achieved in other languages, but with F#, this happens more naturally.
Almost everyone in our team has learnt F# on the job, and overall, everyone's experience has been extremely positive. There's a bit of difficulty in the first 2-3 months, as junior devs get introduced to functional thinking, but if you've generally being doing functional programming, this is just about learning new syntax, tooling and F#'s choice of operator naming (map/bind/pick/collect/choose/..). Typically, based on prior experience, we ask newcomers to spend two weeks to a month, solving the first 100 problems on Project Euler in F#, without using the mutable keyword, and we assign a mentor to point out best practices and review their code.
The hiring pool for F# devs is much smaller than the regular applicant pool, but if a candidate shows genuine interest in F#, they are usually 10x more likely get through our interview process. If they've discovered F#, it means they find something lacking with mainstream languages, so they're likely to have many years of experience under their belt, and they've found a way to grow. That said, we don't restrict our hiring to simply F# devs.
For more info about us, see chaldal.tech (YC/S15).
Amazing! I’d be interested- the problem I have in the FP space is not getting the F# or Haskell experience so you have to “keep up in your spare time” and with other commitments I have to choose what to keep up with and the rarity of FP jobs means it makes more sense to say learn Redux, Sagas, that kind of stuff etc. So I think it’s good if companies like yours would take pure enthusiasm with proven knowledge of other programming languages and desire to learn F#. But I guess it depends as you may have a queue of people wanting a FP job so you can be choosy!
> We also make ample use of quotations to do some cool tricks (like predict the future states some type can take, based on current state + available transitions).
Maybe it's my unsophisticated mind talking here, but programming in F# is pure joy.Among the languages I use only Ruby gets close to provide that feeling.
Anyone have any insight into how well the Ts2Fable tool works these days? (It translates TypeScript type definition files into F# for fable consumption.) https://github.com/fable-compiler/ts2fable
I just now dumped a 350KB JQuery.d.ts file into it, and sure enough it spit out F#, but confirming how well it works overall would take a lot longer to ascertain.
Always seemed to me like having a really robust tool for this purpose (or else, just a rich direct Fable-typing selection) would be a huge boon for the whole Fable ecosystem.
Does anybody here use F# in a Linux shop? I'm generally keen on the more functional languages, but have tended to avoid F# under the assumption that if I use F# I'll probably also end up needing to use Windows to get the most out of it (or get a job using it).
I haven't tried Fable 3 yet, but I can speak to Fable 2 (F#) vs ReScript/ReasonML (OCaml).
F# was heavily inspired by OCaml, it was originally intended as "What would OCaml look like running on .NET?" so the languages themselves share a lot of similarities.
ReasonML pros:
- ReasonML compilation times were much faster than Fable 2, but Fable compile times weren't bad. OCaml is ridiculously fast.
- OCaml has an interesting module system that's missing from F#.
- The toolchain feels a lot more lightweight than the whole .NET toolchain.
Fable pros:
- I found interop with JS and OOP stuff much easier in Fable than in ReasonML
- Fable has a tool for converting TypeScript definitions to Fable definitions - though it hasn't always worked for me for more complex type definitions
- I prefer F#'s whitespace sensitive syntax over OCaml, but that's just personal preference
- F# type providers are pretty cool
- F# has an interactive mode, and you can write standalone scripts (eg. for devops)
- If you want to write a web backend in the same language, F# on .NET is much more mature in the web space than OCaml.
Another Ocaml-ish option is of course, Rust. One thing it has additionally going for it is a complete node.js JS reimplementation (with deno.js, the runtime is mostly go inspired), a client side web browser JS/Webstack impl with bleeding edge webgpu, webasm, CSS support (servo, which was hoisted up to the Linux Foundation - https://servo.org). I think the ethos of servo is interesting since it should allow the web to more interesting dynamic web pages tailored for bandwidth, internationalization, and localization issues, thanks to the (years) of hardwork by IETF and w3c.
- compare their experience with ReasonML since they both have the same OcaML pedigree
- offer any perspectives on efficiencies of various constructs? For example, do things like seq add additional complexity or are about as efficient as for loops?
- discuss the output size .. by virtue of using .net libraries versus javascript builtins?
We’ve started adopting ReasonML on the server side (using nodejs as the end runtime). Anybody have ides on why ReScript/ReasonML on the server side isn’t more popular or targeted? Initially I considered F# and Fable but decided I wanted to adopt the same stack for the client side as well.
I see some F# praising in here. any good learning resources one can recommend to me (Ik I can "google it" or whatever. I mean something you had experience with and would recommend)
I find the name a bit funny, considering Fable 3 was by far the worst game in the Fable series. Yes, I know this has nothing to do with the video game.
I'll be honest, F3, while the most hated was the one that I had the most fun. It was the more serious of the entire franchise and I liked the change of pace and the kingdom-wide choices (and becoming the King/Queen of the entire thing? Great fun.) that could happen based on your changes was a lot more 'real' than the previous two games.
Don't even get me started on the total farce that was the Fable: The Journey was. Cool concept, poor implementation.
Yes - F# provides its own async model via an `async` computation expression. But you can also use the TPL in .NET BCL. F# 6 will have native support for TPL via a `task` computation expression.
But honestly, its own async model is great - arguably better than TPL for business systems. It sacrifices a little top-end performance/power and in return you get a supremely clean abstraction.
[+] [-] arwhatever|5 years ago|reply
Elmish framework provided a nice MVU pattern for the U/I.
And the real icing on the cake was this Thoth.Elmish package which creates statically-typed proxy for your front-end to access your back-end API, more or less transparently. I was always certain that I would some day do something unorthodox causing its automated serialization/deserialization to fail in some difficult-to-troubleshoot way but no, that never happened and it all just worked transparently.
This was hands down the best automated-correctness-checking experience that I've ever had in any framework.
[+] [-] rigoleto|5 years ago|reply
[+] [-] s369610|5 years ago|reply
[+] [-] nudpiedo|5 years ago|reply
[+] [-] cambalache|5 years ago|reply
[+] [-] christophilus|5 years ago|reply
I really like F# as a language, but it's hard to give up the high quality tooling of VS Code + TypeScript + almost any NPM package w/ proper types.
[+] [-] natchy|5 years ago|reply
Ended up using Typescript instead and it doesn't feel as clean.
[+] [-] zamalek|5 years ago|reply
This is my gripe exactly. If you gave me Svelte# and we'd be talking (my TS is pretty functional otherwise).
[+] [-] adamnemecek|5 years ago|reply
[+] [-] rishav_sharan|5 years ago|reply
I have only done some toy projects on it so far, but am really digging it.
[+] [-] JaggerJo|5 years ago|reply
We’re using F# React on the front-end, Giraffe on the back-end.
DustyTables for Data Access.
It’s great - can recommend.
[+] [-] dfgdghdf|5 years ago|reply
* Suave
* AWS
* Fable
* React
SAFR? It's great, but missing a snazzy acronym.
[+] [-] troughway|5 years ago|reply
Saturn
Azure App Service
Fable
Elmish
Slightly off topic but it’s good to see that F# is finally getting some proper web love.
[+] [-] tejasv|5 years ago|reply
All our new code is in F#, we started off from a C# codebase, so that made the transition somewhat manageable, as new F# code can be directly called from C#, and vice versa (still took over 2 years). All new frontend apps are also being written in F# (using Fable), as of 6 months back, migrating away from TypeScript, this forces everyone into a "design your model first, and well" paradigm. We've written quite a bit of code to blur the lines between traditional backend and frontend development roles, so what we have now are:
- product engineers (who write application logic on both frontend and backend to serve business needs)
- platform & framework engineers (who write the underlying persistence/serialization/versioning/frontend-backend-sync websocket/load balancing/IDE extensions/deployment etc)
- component designers who focus on visuals
Platform/framework engineers try to encapsulate as much magic as possible into computation expressions (F#'s monads), so product engineers can focus simply on writing out business intent, with readability given very high priority. We also make ample use of quotations to do some cool tricks (like predict the future states some type can take, based on current state + available transitions).
Our code written in F# has an order of magnitude fewer bugs when it makes it to production, given the amount of thought we pour in modelling the problem domain accurately, and thanks to functional programming itself. They're also more amenable to business requirements changing, simply because they've been modelled well to start with. Nothing that can't be achieved in other languages, but with F#, this happens more naturally.
Almost everyone in our team has learnt F# on the job, and overall, everyone's experience has been extremely positive. There's a bit of difficulty in the first 2-3 months, as junior devs get introduced to functional thinking, but if you've generally being doing functional programming, this is just about learning new syntax, tooling and F#'s choice of operator naming (map/bind/pick/collect/choose/..). Typically, based on prior experience, we ask newcomers to spend two weeks to a month, solving the first 100 problems on Project Euler in F#, without using the mutable keyword, and we assign a mentor to point out best practices and review their code.
The hiring pool for F# devs is much smaller than the regular applicant pool, but if a candidate shows genuine interest in F#, they are usually 10x more likely get through our interview process. If they've discovered F#, it means they find something lacking with mainstream languages, so they're likely to have many years of experience under their belt, and they've found a way to grow. That said, we don't restrict our hiring to simply F# devs.
For more info about us, see chaldal.tech (YC/S15).
[+] [-] quickthrower2|5 years ago|reply
[+] [-] dfgdghdf|5 years ago|reply
> We also make ample use of quotations to do some cool tricks (like predict the future states some type can take, based on current state + available transitions).
[+] [-] esam091|5 years ago|reply
I'm really having fun experimenting with F# for my API server, but I hesitate to use it on the front end.
[+] [-] gdsdfe|5 years ago|reply
[+] [-] cambalache|5 years ago|reply
[+] [-] threeys|5 years ago|reply
[deleted]
[+] [-] arwhatever|5 years ago|reply
I just now dumped a 350KB JQuery.d.ts file into it, and sure enough it spit out F#, but confirming how well it works overall would take a lot longer to ascertain.
Always seemed to me like having a really robust tool for this purpose (or else, just a rich direct Fable-typing selection) would be a huge boon for the whole Fable ecosystem.
[+] [-] _jsdw|5 years ago|reply
[+] [-] sp33der89|5 years ago|reply
Is the only difference the ecosystem around the toolchains?
[+] [-] jordwest|5 years ago|reply
F# was heavily inspired by OCaml, it was originally intended as "What would OCaml look like running on .NET?" so the languages themselves share a lot of similarities.
ReasonML pros:
Fable pros:[+] [-] banjomet|5 years ago|reply
[+] [-] smt1|5 years ago|reply
[+] [-] sriku|5 years ago|reply
- compare their experience with ReasonML since they both have the same OcaML pedigree
- offer any perspectives on efficiencies of various constructs? For example, do things like seq add additional complexity or are about as efficient as for loops?
- discuss the output size .. by virtue of using .net libraries versus javascript builtins?
[+] [-] dang|5 years ago|reply
2017 https://news.ycombinator.com/item?id=15578592
2016 https://news.ycombinator.com/item?id=11771266
[+] [-] chrischen|5 years ago|reply
[+] [-] Scuds|5 years ago|reply
[+] [-] frozenlettuce|5 years ago|reply
[+] [-] fnord77|5 years ago|reply
[+] [-] mjaniczek|5 years ago|reply
[+] [-] plastman|5 years ago|reply
[+] [-] rodrigoj42|5 years ago|reply
The one true way (his book is also very good)
[+] [-] reverseblade2|5 years ago|reply
https://www.udemy.com/course/functional-application-designin...
https://www.udemy.com/course/end-to-end-real-world-applicati...
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] green-mind|5 years ago|reply
[+] [-] gonesurfing|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] anonytrary|5 years ago|reply
[+] [-] drannex|5 years ago|reply
Don't even get me started on the total farce that was the Fable: The Journey was. Cool concept, poor implementation.
[+] [-] reverseblade2|5 years ago|reply
[+] [-] amelius|5 years ago|reply
[+] [-] JaggerJo|5 years ago|reply
F#’s async workflows are supported.
Not sure how this is implemented behind the covers - I guess it get’s compiled to JS promises.
[+] [-] nbevans|5 years ago|reply
But honestly, its own async model is great - arguably better than TPL for business systems. It sacrifices a little top-end performance/power and in return you get a supremely clean abstraction.
[+] [-] dvfjsdhgfv|5 years ago|reply
[+] [-] Tabzz98|5 years ago|reply
[+] [-] dang|5 years ago|reply
[+] [-] tesmar2|5 years ago|reply