Hacker News new | past | comments | ask | show | jobs | submit login
Fable 3: F# to JavaScript compiler (fable.io)
243 points by adamnemecek on Dec 4, 2020 | hide | past | favorite | 127 comments

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.

For those interested, I believe you're referring to Fable.Remoting https://zaid-ajaj.github.io/Fable.Remoting/src/basics.html

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.

Nice site. I liked the game, I was embarrassingly slow though

Yeah, a really nice site. It's not slow at all from what I'm seeing!

The site was fast, I was slow solving the puzzles

Ohhh, sorry - it must be my new glasses! :)

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.

> it's hard to give up the high quality tooling of VS Code + TypeScript + almost any NPM package w/ proper types.

This is my gripe exactly. If you gave me Svelte# and we'd be talking (my TS is pretty functional otherwise).

Was trying to use F# at work for a backend service and got shut down.

Ended up using Typescript instead and it doesn't feel as clean.

TypeScript is nowhere near as clean as any FP language I’ve used. But it’s hard to deny that TypeScript has better tooling and 1st class library support.

I have been intrigued by the SAFE stack lately https://safe-stack.github.io/. Does anyone have direct experience with it?

Not SAFE, but there's a new web framework for f# at https://www.falcoframework.com/. It's in functional first approach and built on top of asp .net

I have only done some toy projects on it so far, but am really digging it.


We’re using F# React on the front-end, Giraffe on the back-end.

DustyTables for Data Access.

It’s great - can recommend.

Is the market for F# picking up now in 2020? At my current job we're not using F# but I'd like to eventually move to a place that does. I am learning on my own at the moment and am wondering how open the potential hiring companies would be with novices in F# who otherwise have good experience in other languages.

From my experience it’s still not easy to find an F# Job.

It’s a niche, but it exists and is growing.

If you want one and are willing to take a few compromises you’ll find one.

I see a decent number of openings in the City of London quite regularly for finance and insurance positions. Also OCaml and sometimes Haskell. Even Rust has started popping up recently.

I find this a bit intriguing because the library support for linear algebra, probability and statistics is pretty slim both in .NET and OCaml. The latter has OWL, which is very cool, but it's mostly a 1-person project.

Do they develop all this support in house? For example, in insurance you may need things like Gumbel or Fréchet maximum likelihood estimators. That's not so easy to implement on your own, especially not without some linear algebra and optimization primitives available.

On the other hand, I love these languages, and I wish there was a strongly typed contender to Python, R or Julia. Whenever I develop a data-oriented application, it feels like I need to prototype in one language and in order to scale or develop the whole infrastructure, I need to switch to another language.

Julia has solved some of these problems, but I don't see a team implementing tons of business logic in a medium sized application using Julia.

Usually on the .NET ecosystem such stuff just gets bought.


F# is your strongly typed contender to Python.

Sure, it's a lovely language. But I find the lack of some basic linear algebra, probability and statistics libraries frustrating. As pjmlp said in a parent thread, those are closed source and usually bought.

I guess a lot of the .NET ecosystem is like that. It's a shame, because MS has some open-source jewels like Z3 or Infer.NET.

MS is making a conscious effort to push into the ML space with libraries such as ML.NET https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotn... . IMO, the combination of a strongly-typed language with features such as type inference, data providers and discriminated unions/pattern matching make F# a perfect fit for this space. It's just unfortunate that they had to go through the .NET Framework -> .NET Core journey before focusing on the ML ecosystem...

But, the F# PM has recently given talks recognizing that they want to go into the space that Python is dominating, so it's a clear goal of the F# team (https://www.youtube.com/watch?v=_QnbV6CAWXc). I hope they're successful!

On the other hand, they just hired Guido, have first class support for Python across VS and VSCode, and are in the process of creating a Python projection for UWP (which still doesn't support F#).

From the outside it always looks like an uphill battle for F#.

It would be great if F# finally gets its place across the .NET stack.

Odd. I've been using F# for a UWP app since 2018.

Odd indeed, given that .NET Native doesn't support it without a couple of hacks.



As per those links - the workarounds found in 2018 allow you to submit to Windows Store.

But even still - my app is sideloaded and never needed to care about .NET Native at all.

Workarounds are not official support and won't fly for many customers deciding what to place in production when picking technology stacks, so the choice ends up being C#, VB, C++, Rust, JavaScript and Python.

The official set of programming languages getting UWP support as part of Project Reunion.

WinUI / Project Reunion is just a continuation of the UAP (Universal App Platform) libraries. The support for C# works for F# - just like basically any other C# library can be used from F#. I figure the reason they don't mention F# is because it is obvious and/or implied but perhaps at the same time don't want to infer there is some kind of F#/FP-style syntax.

I wouldn't confuse Project Reunion and the arbitrary Windows Store requirement that apps be compiled with .NET Native. A requirement that, frankly, is on borrowed time anyway and I can't envisage it surviving much longer. Once .NET 6 delivers Mono-style AOT support - .NET Native's sole remaining purpose will cease to exist. Not that modern hardware ever needed it. It was intended for Windows Phones.

If the choice facing us was a simple as you describe then, for example, we wouldn't have ended up building a UWP app in F# back in 2018, would we? Not everything is black and white nor zero sum.

Good luck with that reasoning when Windows 10X comes out next year.

UWP is still the future of Windows API, Reunion is only lifting it from the Windows kernel, and exposing the respective COM infrastructure on the Win32 side as well.

When I create applications for customers I don't select technologies that require me to place workarounds that might make them repent for having me there in first place.

Hence why as much as I like F#, it is never going to be an option for me, until it has a seat at the table of the official languages.

Apparently that isn't an issue in your case, so good luck with the endeavours.

There is nothing concerning Windows 10X that undermines anything I have said.

UWP is the future of Windows - correct.

I'm not sure any significant part of UWP has ever been in the kernel per se.

It sounds like you're a consultant where taking risks on behalf of your customers, no matter how small or logical the risk, is obviously not part of your job description.

Your offerings of good luck appear to be disingenuous.

We've been running F# in production since 2014 - almost 7 years. It is quite shocking to hear anyone imply that F# is not ready for production use - that it is just "cool" tech. (when has F# ever been cool in the minds of the masses?)

I suspect you'll say "7 years is nothing" and maybe it is nothing. But it is still something. It is long enough that we made a couple bad framework/library dependency choices early on and to have learnt lessons from such mistakes.

By far the biggest technical challenge we've faced in that time is the .NET 5 migration - but even that might turn out to be a lot easier than I currently envisage.

On the context of Windows GUI frameworks and UWP, no it isn't ready.

Still no VS or Blend tooling support, no project templates and .NET Native requires workarounds with stuff that most corporate enterprise developers don't care to learn.

Picking F# over official supported languages has zero value on the sales of customers, that is what they care about, not cool software stacks.

So if their IT goes down and the reason is that a risky loving consultant used unofficial workarounds, I rather not get unnecessary phone calls.

As for the wishing luck, I was being honest, take it as you wish.

Hopefully F# gets big enough that people will write those libraries - I think people deserve a better Python.

Interesting in the ML space is https://diffsharp.github.io/ which is heavily developed by Don Syme at the moment.

this is part of the greater lament of FP languages in industry. You might have to be satisfied with a kind of FP flavored C#, which in newer versions of the language isn't all that bad The thinking is that there's a million C# devs, a hundred thousand VB devs, and ten thousand F# devs.

If you want to work in F# come up with your own OSS projects or champion it at work.

what about efcore does it work in f#? or is it bad practice to use mutable code/objects in f#? i do not want to go back to plain sql...

It’s a .Net library so it works (or should work) with F#.

What sometimes leads to problems is F#’s record and discriminated union types.

Not sure how they are handled by EF Core.

Going back to plain SQL is just great. You know exactly what SQL gets executed. No Magic.

With DustyTables it’s also not too much boilerplate.

Design-time support is still via a non-released package. So you'll write models/etc in C# and use EF from F#. There are ways to get design-time constructs working in F#, but it's not plug-and-play like from the C# side.

You can write models in F# (with CLIMutables everywhere), but then you need to put models in a separate project, then add a C# project for migrations, and finally reference both projects from your ASP.NET app.

Apparently C# 7 can match discriminated unions quite well[1], with the caveats being:

1. you need a dummy type[2] for empty parts of the union.

2. it still can't enforce exhaustive matching.

[1]: https://stu.dev/pattern-matching-fsharp-union-types-in-cshar...

[2]: Maybe () would work?

I am not using SAFE, but something similar:

* Suave


* Fable

* React

SAFR? It's great, but missing a snazzy acronym.

For those too lazy to hunt, SAFE stands for


Azure App Service



Slightly off topic but it’s good to see that F# is finally getting some proper web love.

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 (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).

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.

Yes :) That moment when it simply clicks, it's not something that goes away. It has certainly made my day-to-day programming work a lot sweeter, hence I can't shut up talking about it. And it's not like I write some esoteric ML or data science code, a lot of these are boring line-of-business applications, yet it is so satisfying designing those in F#.

Does interop with c# get easier?

Trying to figure out how to map to an overloaded C# callback (maybe hidden in an *.extension doc!) has wasted hours of my time.

F# (the ml family in general) is my favorite language right now but, man, the .net APIs are rough.

Lacking the same UX I’m used to in Node, Ruby, and Elixir.

Interop is janky. It works, but there are some gotchas that need to be worked around. It works in 95% of the cases without much mucking around, but it's not pretty, so you're better off tucking that away in some dark corner.

Can you explain the interop a bit more? I’ve been looking into an F# job. Having a functional background, the language looks nice, but I’m wondering about the ecosystem. Can you not use .Net libraries as easily as you can from C#?

Yes. Typically interop is very straightforward. You look in the api docs and copy paste.

Example here is the String doc[1]. Way down you see all the methods. Some of the methods have overloads (multiple variants). Pretty straightforward here. (E.g. `"mystring".Contains("ring")`)

Where it gets more verbose and finicky is when the API takes a C# callback. Even more complex is if it’s asynchronous so it takes a C# callback as a Task.

An example being the `.Use` method for defining server middleware.[2]

To see how it’s done, here’s a gist I found.[3] Notice how the function for requestHandler is verbosely annotated with Func<> and RequestDelegate, etc.

Luckily this isn’t the norm, most APIs are less complicated. Even so, you write a wrapper (abstraction) around that complexity and only look at your wrapper. Which is why someone in this thread said to leave them in a dark corner.

[1]: https://docs.microsoft.com/en-us/dotnet/api/system.string?vi...

[2]: https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnet...

[3]: https://gist.github.com/kspeakman/7870a75283f6942dd96ff34a03...

I think it will get better in F# 5.1, which adds native C# Task support... https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-...

In the meantime, you can use the fantastic TaskBuilder.fs for C# Task support and interop.

https://www.nuget.org/packages/TaskBuilder.fs/ https://github.com/rspeele/TaskBuilder.fs

Thanks. I appreciate the explanation.

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!

I find the same thing. Getting the experience can only happen in time I direct. I have scope to use F# at work but still fear that choice is not the best for the company I work for. Yes I will love the tooling and right now I'm there but it won't always be that way. They won't be able to find contractors to make changes in the future. I have to give them solutions they can run with in the future or they will be forever regretting me once I'm gone.

If you're on a .NET stack, F# is a secret sauce; its just not many have bothered to look :) Maybe discuss with your CTO and make a collective decision to invest in it by understanding what it brings to the table, and don't worry too much about the future, like having to hire F# devs. As I described above, guiding existing devs to learn F# is the equivalent of training them to think better (as PG/Eric Raymond quote, it will "make you a better programmer for the rest of your days"). If a small handful of you within the company develop expertise, you can guide others. And what's more; if you do pick up F#, many skills are transferable to other FP jobs (like Scala). There's a leap-of-faith element involved, but it has been paying us dividends.

Also, I really like this post: https://fsharpforfunandprofit.com/posts/low-risk-ways-to-use...

How's your experience with Fable, especially when using third party JS libraries?

I'm really having fun experimenting with F# for my API server, but I hesitate to use it on the front end.

Please can you sure more about this?

> 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).

Here's is a simplistic example of a state machine:

  let transition (state: State) (action: Action) : State option =
     match (state, action) with
     | (StateA, ActionA) -> Some StateB
     | (StateA, ActionB) -> Some StateC
     | (StateB, ActionA) -> Some StateB
     | _ -> None
If you get the quoted representation of the transition function, it can be visualized as a tree data structure (like code-as-data in LISP). You can analyze that tree to understand that if current state is StateB, only ActionA can be applied on it.

Couple this with another realization: "Any sufficiently complicated model class contains an ad hoc, informally specified, bug-ridden, slow implementation of half of a state machine." (not sure where I read this quote).

This means all the entity framework/ORM crap work that we do can actually be neatly represented as transforms on a F# state machine, which suddenly makes the application more powerful if you give it this structure.

We use this technique to auto-generate admin panels.

> "Any sufficiently complicated model class contains an ad hoc, informally specified, bug-ridden, slow implementation of half of a state machine." (not sure where I read this quote).

Can’t tell you where you read it, of course, but believe it originates from Braithwaite/raganwald:


Do you blog any of this or do any sort of writing on the topic. I think I could learn a lot from the way you are doing things.

Not yet, it has been on my list for a long time. Meanwhile I recommend this blog that collates all good F# content from around the web weekly:


Take a look at F#'s type solver code especially wrt to Extension Typing: https://github.com/dotnet/fsharp/blob/main/src/fsharp/Extens...

You can do similar things with other Ocaml or Lispy Langs, depending on how you want to do it. All you need is a function that returns possibleTypeTransitions for givenType(type, enclosedLexeme, type.validTransitions). A gradually typed lang sitting in top of a prototype-based blob also makes this easy to do (see typescript) in-codo.

See also MacKay (RIP)'s classic book: http://www.inference.org.uk/itprnn/book.pdf

That's a good pitch!

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).

.NET Core on Linux is actually the best experience I had in a while. Microsoft provides packages for all the major versions of the SDK and you can install them side-by-side with your distro package manager. Then you pick which version of the SDK you want to use for each solution and everything works.

We've been using it in production for a web service for over a year now, it's been a pleasant experience. dotnet core and ASP.NET are great platforms/ecosystems and F# has no trouble piggybacking off all that success.

I used it years ago in a Linux shop using Mono. It was perfectly fine. I gather these days with the new .NET Core running natively on Linux it's even better.

At my previous company I developed on Ubuntu/macOS and deployed to Linux on AWS. Never experienced any issues, never had code running on Windows.

I've been writing code with f# and dotnet core 5.0 on MacOS. Works great!

I do a lot of F# these days. I haven’t owned a windows machine in a decade.

Using F# on Ubuntu for two years, it’s lovely!

How does Fable 3 stack up against ReScript or Scala.js?

Is the only difference the ecosystem around the toolchains?

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.

I think you are missing the biggest advantage of F#: computation expressions.

Computation expressions are like do-notation and list comprehensions in one feature. Now that I have tried them, I don't want to go back to a language without!

Oh yes! These are amazing. Took me a while to understand what they do, but now the simplest way I think of it is that they're powerful enough to let you build your own async/await (though you don't need to - async await computation expressions are already included)

This is just monadic bind, every functional language has this

F# computation expressions go well beyond notation for monadic bind, see the section in https://fsharp.org/history or other technical descriptions.

Computation expressions seem like one of F#'s unique features. I assume there are corollaries in other languages - but damn do they make code readable.

Interesting. But is it true that that is nothing like that in other languages?

They are a bit like do-notation in Haskell, but with a few extra things. They are also like a more restricted / opinionated version of Clojure macros.

What's really cool is that things like ```async function *``` from JS can be implemented as libraries in F#.

A better question is about ReasonML/ReScript.

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.

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.

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 wonder how elm and clojurescript are doing?

See also: https://github.com/elm/compiler/issues/1773#issuecomment-418...

Dismissive maintainers indeed!

we use CLJS in production

Still ready for production.

Elm is definitely not ready for production, hostile compiler maintainers.

Written elm daily in huge production apps for years now. I read about the drama on HN, but it doesn't really reflect how elm is to use. Everything works and been stable for a long time now.

Would I recommend others to throw away React or similar to use it? Maybe not, but it's mostly painless to use day-to-day.

I use it in production and I recognize your username because you always appear when the topic of Elm comes up on HN so you can write the same exact comment.

https://news.ycombinator.com/item?id=22237578 (I wrote this exact comment about you 10 months ago on another F# + JS submission)

If this is going to be your hobby horse, why not put some effort into it beyond "lol sux"?

Nah, it's totally fine in production. Now I'm not working at a company using it [in prod] I'll likely never touch it again, but it works and works very well.

Can anyone with experience with Fable -

- 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?

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)


The one true way (his book is also very good)

Bought the book as well and would recommend it. Also have a look at Scott's talks (links are on the website or search his name in youtube)

Here is a brand new F# course on Udemy. Highly recommended! https://www.udemy.com/course/fsharp-from-the-ground-up/

Stylish F# is a good book to go with all of Scott’s works https://www.apress.com/gp/book/9781484239995

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.

here's a 3d bin packer written in Fable: http://bindrake.com/ and source: https://github.com/OnurGumus/BinDrake

Is concurrency supported?

what exactly do you mean by ‘concurrency’ ?

F#’s async workflows are supported.

Not sure how this is implemented behind the covers - I guess it get’s compiled to JS promises.

> what exactly do you mean by ‘concurrency’ ?

Good point. I guess I meant parallelism instead.


As already mentioned, you can use web workers. Feliz (a React library for F#) provides a nice way to use them [0].

[0] https://zaid-ajaj.github.io/Feliz/#/Hooks/UseWorker

Not supported IIRC as it’s not supported by JavaScript.

I think it can still be archived with web workers.

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.

Thank you for the part in round brackets, I wish more submissions were formed in this way.

Wouldn't have even clicked if not for the brackets. My mind jumped to the crappy game https://en.wikipedia.org/wiki/Fable_III

Huh, today I learned "parenthesis" are called "round brackets" in UK

I have never ever heard anyone call them that in the UK, they're either brackets or parenthesis to anyone I've ever spoken to - from scientists, to builders, my grandparents all said brackets (Including the one is almost illiterate)

I'm sure someone must use it but it's not at all common

I picked up "round brackets", "square brackets", "curly brackets" somewhere during my (Lancashire) youth though generally I only use them now when I encounter somebody confused by parens/brackets/braces as terminology.

I say square and curly, but not round - I'm from Devon, but I'm only 19, so I haven't got the accent.

Coincidentally the Dutch word(s) for "brackets" translates to "square parenthesis".

In Turkish, brackets are called "parentheses with corners".

Is the term "parenthetical" not common in the UK?

The alternative would be bracketed, I suppose, so it is common.

Wouldn't it just be "in brackets"?

I used to hear that quite often - not so much in recent years, if I think about it, but that may be by chance. I think it is what I would say.

Crappy is your subjective opinion. Others, including review sites, gave it above average views.

We inlined that bit in the title above.

Is there any note on if F# will gain concepts/type classes?

I don’t know, but I think this GitHub issue will probably give you the current status and background on this point https://github.com/fsharp/fslang-suggestions/issues/243

Update: the issue is tagged await-csharp-alignment, which is probably the relevant status.

Ah thanks!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact