Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fable 3: F# to JavaScript compiler

fable.io

Post reply on HN
Print view View original

41–50 of 131 posts

Re: Fable 3: F# to JavaScript compiler

#41

Post by nextos »

JaggerJo wrote: post #12
tartoran wrote: post #10

Earlier quoted context omitted.

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.

Re: Fable 3: F# to JavaScript compiler

#43

Post by matsemann »

vmchale wrote: post #39
mjaniczek wrote: post #38

Earlier quoted context omitted.

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.

Re: Fable 3: F# to JavaScript compiler

#44

Post by christophilus »

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.

Re: Fable 3: F# to JavaScript compiler

#45

Post by smt1 »

sp33der89 wrote: post #16

How does Fable 3 stack up against ReScript or Scala.js? Is the only difference the ecosystem around the toolchains?

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.

Re: Fable 3: F# to JavaScript compiler

#46

Post by RobertKerans »

vmchale wrote: post #39
mjaniczek wrote: post #38

Earlier quoted context omitted.

Still ready for production.

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

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.

Re: Fable 3: F# to JavaScript compiler

#47

Post by drannex »

anonytrary wrote: post #42

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.

Re: Fable 3: F# to JavaScript compiler

#48

Post by tejasv »

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

Re: Fable 3: F# to JavaScript compiler

#49

Post by jordwest »

sp33der89 wrote: post #16

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.

Re: Fable 3: F# to JavaScript compiler

#50

Post by pjmlp »

nextos wrote: post #41
JaggerJo wrote: post #12

Earlier quoted context omitted.

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…

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

https://www.quantconnect.com/blog/top-numerical-libraries-fo...

Post reply on HN