4 ms·

Maybe I'm biased, but I'm often skeptical of the benefits of projects like this that translate a language which normally targets runtime A, into another languag

Maybe I'm biased, but I'm often skeptical of the benefits of projects like this that translate a language which normally targets runtime A, into another language that targets a wildly different runtime B (usually JS or WASM) (Disclaimer that I'm not talking about compiling runtime-less languages for different platforms) It just seems like it's going to be a very leaky abstraction, like there will be tons of corner cases where some behavior isn't exactly the same and other behavior isn't quite possible, which will cause libraries and in-house code alike to break in weird ways. I know that ClojureScript, for example, has several caveats relative to Clojure; and most of these translators are not nearly as mainstream (and so don't get nearly as much maintenance attention) as ClojureScript does. And then there's the messy question of interacting with the host system, dropping down into the host language for certain things, etc. I haven't really worked with these kinds of systems so I may be way off, but from the outside it seems like a huge increase in complexity just so you get to stay in a familiar language

kevinmgranger 5y ago
I'm only passingly familiar myself, so I might be off here-- but F# already has that sort of feel and experience, where it has some of its own ways of doing things despite integrating into the .NET runtime. In other words, the language designers and users are already used to understanding corner cases and integrations into ecosystems that are different.
- brundolf 5y ago
  Interesting point! I haven't used F# so I assumed it was pretty "native" to the .NET runtime Still- I have to wonder about things like concurrency, which is perhaps the most obvious limitation of targeting the JS runtime
  - kevinmgranger 5y ago
    There are some caveats they outline for the usual async stuff[1], but at a cursory glance, it's not that bad. Thanks to F#'s computation expressions, .NET async code and Fable.Promise code look almost identical.[2] 1: https://fable.io/docs/dotnet/compatibility.html#Caveats-II https://fable.io/docs/dotnet/compatibility.html#Caveats-II 2: https://stackoverflow.com/a/54451205/4099287 https://stackoverflow.com/a/54451205/4099287
    - pharmakom 5y ago
      My suggestion is to use async in F# code by default. Use task for certain heavy server code on .NET and promise for JS interaction, where required. Async mostly works everywhere.
      - kevinmgranger 5y ago
        Is there some sort of (for lack of a better term) Monad Transformer that lets you mix `async` and `promise` in the same computation expression?
        pharmakom 5y ago
        Computation Expressions are implemented using a class under the hood so you could probably build one with appropriate overloads. There’s a function that Fable provides to turn a promise into an async, so mix and match isn’t a huge challenge anyway.
        kevinmgranger 5y ago
        Yeah, I'm just trying to avoid having to throw the adapters on each line. Just like fable supports any thenable, it'd be cool if async/task could be treated as a thenable.
  - phillipcarter 5y ago
    F# is certainly a .NET language depending on the lens with which you view it. The object system and lots of its semantics are the way they are because that's how .NET works. However, a surprisingly large amount of this stuff is translatable and makes sense with a JS runtime instead. The fable authors have managed to thread the needle just right so that it more or less "feels right".
kervantas 5y ago
People would rather write a compiler than write js. Ridiculous.
- Smaug123 5y ago
  Er, yes? Compilers are brilliant fun.
- xvilka 5y ago
  It just shows how terrible JS as a language itself.
- robinsonrc 5y ago
  That doesn’t strike me as being ridiculous at all
- pharmakom 5y ago
  - Shared language for server and client has its advantages. - F# has some significant advantages over JavaScript (and TypeScript).
JaggerJo 5y ago
I've written quite a lot of F# code for the web over the last few years. Most of the time things just work as long as you don't use overly specific .NET BCL stuff. We had issues with Dates. Implementing a custom 'ZonedDateTime' type with native implementations for both target platforms (JS and .NET) was straight forward. Other than that there are a few gotchas when doing 'advanced' stuff: - Fable does not support 'Array2D', 'Array3D', ... - Fable allows the use of ints but you have to know that at runtime they all are floats. - Fable does not support FSharp Quotations. - Fable does not support the full reflection API. More here: https://fable.io/docs/dotnet/compatibility.html https://fable.io/docs/dotnet/compatibility.html Would definitely recommend F# for both backend and frontend. It's been a joy.
dwohnitmok 5y ago
ClojureScript is in a weird boat because of a constant background tension in goals of the Clojure community, where on the one hand Clojure proclaims that it is a "hosted language" and as such there shouldn't be an expectation of consistent semantics across different hosts, but on the other hand devs really like consistent semantics if the language doesn't change. So the Clojure community has kind of settled on cljc files as an indication of "works on all hosts in the way you would expect" even though that's not any part of the guarantee that a cljc file provides in any documentation anywhere (it gives you reader conditionals and that's it). Basically ClojureScript isn't really sure whether those "caveats" are bugs or features and neither is the Clojure community at large. More broadly they aren't sure whether causing "libraries and in-house code alike to break in weird ways" on different hosts is a bad thing (some folks would probably take issue with the word "break"). On the whole however these projects can go very well. I've seen e.g. ScalaJS and Scala backend projects work very well. They're a lot less leaky than you would think. The vast majority of code just works. In particular, there are clean lines between what is supported by the abstraction and what isn't, and the latter doesn't affect the former, so in that sense the abstraction is pretty tight and not leaky. And the major win isn't so much the familiar language part as it is the ability to share code and definitions. It's really powerful to change a line somewhere deep in your backend and have all the places you need to make a change all the way out to the frontend UI automatically laid out for you. That said the big misconception, and where the abstraction is incomplete if not leaky, is that these languages allow you to disregard the runtimes of secondary targets. No compile-to-JS language I know of has successfully done away with the need to understand the HTML/CSS/Javascript stack. And that indeed is extra complexity that should give pause to developers. But RE "cause libraries and in-house code alike to break in weird ways" generally does not seem to be the case for these compile-to-JS languages.
angio 5y ago
The reason I'm bullish on Fable (and Feliz) is that in my experience the challenge in writing a modern web application is dealing with state, especially when API calls are involved. With Fable I save a lot of time (and bugs!) in that, so I'm okay with spending more time integrating with javascript libraries. In my experience you can achieve the same functionalities with a lot less complexity in Fable + Feliz than the equivalent typescript stack.

kevinmgranger 5y ago

I'm only passingly familiar myself, so I might be off here-- but F# already has that sort of feel and experience, where it has some of its own ways of doing things despite integrating into the .NET runtime. In other words, the language designers and users are already used to understanding corner cases and integrations into ecosystems that are different.

brundolf 5y ago
Interesting point! I haven't used F# so I assumed it was pretty "native" to the .NET runtime Still- I have to wonder about things like concurrency, which is perhaps the most obvious limitation of targeting the JS runtime
- kevinmgranger 5y ago
  There are some caveats they outline for the usual async stuff[1], but at a cursory glance, it's not that bad. Thanks to F#'s computation expressions, .NET async code and Fable.Promise code look almost identical.[2] 1: https://fable.io/docs/dotnet/compatibility.html#Caveats-II https://fable.io/docs/dotnet/compatibility.html#Caveats-II 2: https://stackoverflow.com/a/54451205/4099287 https://stackoverflow.com/a/54451205/4099287
  - pharmakom 5y ago
    My suggestion is to use async in F# code by default. Use task for certain heavy server code on .NET and promise for JS interaction, where required. Async mostly works everywhere.
    - kevinmgranger 5y ago
      Is there some sort of (for lack of a better term) Monad Transformer that lets you mix `async` and `promise` in the same computation expression?
      - pharmakom 5y ago
        Computation Expressions are implemented using a class under the hood so you could probably build one with appropriate overloads. There’s a function that Fable provides to turn a promise into an async, so mix and match isn’t a huge challenge anyway.
        kevinmgranger 5y ago
        Yeah, I'm just trying to avoid having to throw the adapters on each line. Just like fable supports any thenable, it'd be cool if async/task could be treated as a thenable.
- phillipcarter 5y ago
  F# is certainly a .NET language depending on the lens with which you view it. The object system and lots of its semantics are the way they are because that's how .NET works. However, a surprisingly large amount of this stuff is translatable and makes sense with a JS runtime instead. The fable authors have managed to thread the needle just right so that it more or less "feels right".

kervantas 5y ago

People would rather write a compiler than write js. Ridiculous.

Smaug123 5y ago
Er, yes? Compilers are brilliant fun.
xvilka 5y ago
It just shows how terrible JS as a language itself.
robinsonrc 5y ago
That doesn’t strike me as being ridiculous at all
pharmakom 5y ago
- Shared language for server and client has its advantages. - F# has some significant advantages over JavaScript (and TypeScript).

JaggerJo 5y ago

I've written quite a lot of F# code for the web over the last few years. Most of the time things just work as long as you don't use overly specific .NET BCL stuff. We had issues with Dates. Implementing a custom 'ZonedDateTime' type with native implementations for both target platforms (JS and .NET) was straight forward. Other than that there are a few gotchas when doing 'advanced' stuff: - Fable does not support 'Array2D', 'Array3D', ... - Fable allows the use of ints but you have to know that at runtime they all are floats. - Fable does not support FSharp Quotations. - Fable does not support the full reflection API. More here: https://fable.io/docs/dotnet/compatibility.html https://fable.io/docs/dotnet/compatibility.html Would definitely recommend F# for both backend and frontend. It's been a joy.

dwohnitmok 5y ago

ClojureScript is in a weird boat because of a constant background tension in goals of the Clojure community, where on the one hand Clojure proclaims that it is a "hosted language" and as such there shouldn't be an expectation of consistent semantics across different hosts, but on the other hand devs really like consistent semantics if the language doesn't change. So the Clojure community has kind of settled on cljc files as an indication of "works on all hosts in the way you would expect" even though that's not any part of the guarantee that a cljc file provides in any documentation anywhere (it gives you reader conditionals and that's it). Basically ClojureScript isn't really sure whether those "caveats" are bugs or features and neither is the Clojure community at large. More broadly they aren't sure whether causing "libraries and in-house code alike to break in weird ways" on different hosts is a bad thing (some folks would probably take issue with the word "break"). On the whole however these projects can go very well. I've seen e.g. ScalaJS and Scala backend projects work very well. They're a lot less leaky than you would think. The vast majority of code just works. In particular, there are clean lines between what is supported by the abstraction and what isn't, and the latter doesn't affect the former, so in that sense the abstraction is pretty tight and not leaky. And the major win isn't so much the familiar language part as it is the ability to share code and definitions. It's really powerful to change a line somewhere deep in your backend and have all the places you need to make a change all the way out to the frontend UI automatically laid out for you. That said the big misconception, and where the abstraction is incomplete if not leaky, is that these languages allow you to disregard the runtimes of secondary targets. No compile-to-JS language I know of has successfully done away with the need to understand the HTML/CSS/Javascript stack. And that indeed is extra complexity that should give pause to developers. But RE "cause libraries and in-house code alike to break in weird ways" generally does not seem to be the case for these compile-to-JS languages.

angio 5y ago

The reason I'm bullish on Fable (and Feliz) is that in my experience the challenge in writing a modern web application is dealing with state, especially when API calls are involved. With Fable I save a lot of time (and bugs!) in that, so I'm okay with spending more time integrating with javascript libraries. In my experience you can achieve the same functionalities with a lot less complexity in Fable + Feliz than the equivalent typescript stack.