6 ms·

Great addition to a great language. We've been building a very technical product in F# + Rust for the last three years or so (think R lang + R Studio or Replit

by obeavs 3y ago

Great addition to a great language. We've been building a very technical product in F# + Rust for the last three years or so (think R lang + R Studio or Replit but for DSLs we built for finance and contracts). While most folks tend to see F# as a .NET-oriented/back-end kind of language, they'd be missing some incredibly unique web technologies such as the Fable compiler (F# -> JS, Python, Dart, etc) and Elmish (Elm, but for F# with a JS target via Fable). It boggles my mind that more of the web dev community haven't discovered these tools. These "communities" fall completely outside of MSFT's umbrella, but are transformative for how you think about architecting applications: Elm as an architecture (rather than as a language) enables a large amount of optionality in terms of what technologies one might use as a "reactivity layer" (e.g. can swap out React for SolidJS or even non-JS targets like Avalonia quite easily if it made sense to). Our bet is that it enables us to future proof things in a number of unique ways as better WASM-based solutions come online as well that hopefully won't require shipping the whole .NET runtime (e.g. Bolero). The approach is also v helpful in managing state across an otherwise very complex application.

DarkNova6 3y ago
this sounds exciting, but I wonder. How closely linked is Elmish to Elm? In theory Elm is just such a fascinating project... if it was not held back by the people developing it.
- arrow7000 3y ago
  It's not linked at all, it just uses "The Elm Architecture" as inspiration to recreate the same architecture in F#
- carapace 3y ago
  Please PLEASE enough with the character assassination of the Elm guy. He wants to run his own project his own way. There's a small but dedicated residue of people who just can't stand being told "no" and go around crapping on the kid whenever they get a chance. I get it. You don't like Evan's project management style. Move on already. - - - - The fact of the matter is that he's a person who took his thesis, made it into a product, and got traction in the real world. People have used Elm to make things. Things that go. How many of us can say the same? And that's before you get to all the fascinating and as yet still-too-obscure things that the OP talks about. Things that are in part a little more widely known and understood thanks to Elm project.
  - _svoh 3y ago
    Eh, it doesn't seem like character assassination. Dude chose his management style. That makes his project unfit for purpose for certain people. Those people are allowed to make that determination and state as such. I remember when the Elm team first decided to lock down the Elm compiler, so that only the team in charge had special privileged access to modify it. I thought, "wow, this looks like a bunch of people who don't want to collaborate, who want to take their ball and tell others how to play with it, really putting the 'dictator' in BDFL." and you know what? that's fine. I don't harbor anything against them as people. But that left a permanently bad taste in my mouth and I'm unlikely to ever trust that group or a project they're managing.
    - carapace 3y ago
      FWIW my comment was along the lines of allergic reaction. I'm not an Elm fanatic, I'm just sick of seeing people snipe on the dude. You're entitled to your opinion, of course, and you articulated it well. But again I see it as another example of someone not liking being told "no", no?
      - ObscureScience 3y ago
        My understanding of this is that he managed to hype the language with certain killer features. A lot of people were enthusiastic and invested alot of time in learning and building in it. Evan than "suddenly" said they wanted to take the language in another direction and dropped some of the core features and pricipals that drew people in. While perhaps a mischaracterization, it comes a cross as a kind of "bait and switch" or at least undependable.
      - _svoh 3y ago
        That's really reductive and biased against us, the potential user base of Elm that decided not to engage. Why is it that we don't like being told "no," as opposed to the Elm leadership and Elm community not liking being told "this isn't a 100% solution for me so I'd like to modify it"? Obviously Elm is his passion project, that's fine. But nobody who locks down their compiler on a supposedly "open source" project can actually seriously expect others to engage with that in good faith. Furthermore, the absolute state of just trying to modify Elm to be more fit for purpose is horrendous. Every time I see a parallel implementation or a fork, the author has to bend over backward with platitudes to placate the Elm masses and ensure them that this project isn't trying to "split the community," which is a nonsense idea to start with imo. It feels cultish, on top of a project that is actively hostile to people who want to use it any way other than how the BDFL has mandated its usage. If you want to say the problem is with the users, that's fine, but that's exactly the attitude keeping me from ever engaging. I personally think the problem is with the people who want such fine control over their technology and community, as opposed to understanding that they can really only shepherd their implementation. That's about as far as their reach rightfully extends. EDIT: also, the fact that they aggressively lock down their compiler and have such hostility to anyone working in parallel is imo the definition of "holding it back"
- obeavs 3y ago
  Some references if helpful: * Elmish (F#) repo - https://github.com/elmish/elmish https://github.com/elmish/elmish * The Elmish Book (... remarkably good) - https://zaid-ajaj.github.io/the-elmish-book/#/ https://zaid-ajaj.github.io/the-elmish-book/#/ * Fable compiler - https://fable.io/ https://fable.io/ The F# community is very friendly (sub-communities as well), and there are plenty of good opportunities to contribute OSS work across any skill level. Phosphor isn't hiring right now, but we will begin a search for FE/interface engineers soon. oliver@phosphor.co for anyone interested.
- aranchelk 3y ago
  > In theory Elm is just such a fascinating project... if it was not held back by the people developing it. PureScript may be worth a look, it’s got several features that were rejected by Elm devs: typeclasses, ability to publish modules that use FFI to JS, runs server-side, etc.
Capricorn2481 3y ago
I looked at Fable and the resulting code just looked way more complicated than anything Javascript could write. I'm interested in F# still on the backend, but I don't think people "haven't discovered" Fable, it's just not a great alternative.
- obeavs 3y ago
  Yeah, I suppose it depends on what you're building. Three years of building with it (plus constant re-evaluation of that decision) has supports our conclusion that it is far more concise and easier to manage (esp for less technical folks who need to sign off on the business logic/domain) than anything we'd have done in JS. With that said, we're building a product that requires much more interactivity than most, and we're performing a lot of typical "back-end" logic in the client - that might color our evaluation. To be sure, it hasn't been without tradeoffs, but we haven't found those tradeoffs to be at the language level.
- durable_queue 3y ago
  The generated JS is only somewhat readable, but you're not supposed to be reading the F#.
  - Capricorn2481 3y ago
    I'm not supposed to read the F#?? Someone should tell the Fable guys
- catlover76 3y ago
  Is it really appreciably different from "transpilation" with TypeScript? Like, I have seen a little of both (I've used a lot of TypeScript, but who actually looks at the output JS lol), and while I agree the JS output from Fable seemed surprisingly verbose, I'm not sure I see how it practically matters unless one is worried about bundle size or something.
  - Capricorn2481 3y ago
    I'm not talking about that JS output, I mean the F# itself. While I'm not the most familiar with F#, I've enjoyed other languages that transpile to JS a lot more. For whatever reason, F# to me looks surprisingly verbose in Fable, which is odd because it's pretty terse on the backend.
gemstones 3y ago
I'm familiar with Fable, it's a very conscious choice not to use it in any web applications. Debugging its JS output is not fun.
deleted 3y ago
[deleted]
depr 3y ago
Do you integrate Rust and F# in any way or do they just talk via an HTTP or similar API?

by obeavs 3y ago

DarkNova6 3y ago

this sounds exciting, but I wonder. How closely linked is Elmish to Elm? In theory Elm is just such a fascinating project... if it was not held back by the people developing it.

arrow7000 3y ago
It's not linked at all, it just uses "The Elm Architecture" as inspiration to recreate the same architecture in F#
carapace 3y ago
Please PLEASE enough with the character assassination of the Elm guy. He wants to run his own project his own way. There's a small but dedicated residue of people who just can't stand being told "no" and go around crapping on the kid whenever they get a chance. I get it. You don't like Evan's project management style. Move on already. - - - - The fact of the matter is that he's a person who took his thesis, made it into a product, and got traction in the real world. People have used Elm to make things. Things that go. How many of us can say the same? And that's before you get to all the fascinating and as yet still-too-obscure things that the OP talks about. Things that are in part a little more widely known and understood thanks to Elm project.
- _svoh 3y ago
  Eh, it doesn't seem like character assassination. Dude chose his management style. That makes his project unfit for purpose for certain people. Those people are allowed to make that determination and state as such. I remember when the Elm team first decided to lock down the Elm compiler, so that only the team in charge had special privileged access to modify it. I thought, "wow, this looks like a bunch of people who don't want to collaborate, who want to take their ball and tell others how to play with it, really putting the 'dictator' in BDFL." and you know what? that's fine. I don't harbor anything against them as people. But that left a permanently bad taste in my mouth and I'm unlikely to ever trust that group or a project they're managing.
  - carapace 3y ago
    FWIW my comment was along the lines of allergic reaction. I'm not an Elm fanatic, I'm just sick of seeing people snipe on the dude. You're entitled to your opinion, of course, and you articulated it well. But again I see it as another example of someone not liking being told "no", no?
    - ObscureScience 3y ago
      My understanding of this is that he managed to hype the language with certain killer features. A lot of people were enthusiastic and invested alot of time in learning and building in it. Evan than "suddenly" said they wanted to take the language in another direction and dropped some of the core features and pricipals that drew people in. While perhaps a mischaracterization, it comes a cross as a kind of "bait and switch" or at least undependable.
    - _svoh 3y ago
      That's really reductive and biased against us, the potential user base of Elm that decided not to engage. Why is it that we don't like being told "no," as opposed to the Elm leadership and Elm community not liking being told "this isn't a 100% solution for me so I'd like to modify it"? Obviously Elm is his passion project, that's fine. But nobody who locks down their compiler on a supposedly "open source" project can actually seriously expect others to engage with that in good faith. Furthermore, the absolute state of just trying to modify Elm to be more fit for purpose is horrendous. Every time I see a parallel implementation or a fork, the author has to bend over backward with platitudes to placate the Elm masses and ensure them that this project isn't trying to "split the community," which is a nonsense idea to start with imo. It feels cultish, on top of a project that is actively hostile to people who want to use it any way other than how the BDFL has mandated its usage. If you want to say the problem is with the users, that's fine, but that's exactly the attitude keeping me from ever engaging. I personally think the problem is with the people who want such fine control over their technology and community, as opposed to understanding that they can really only shepherd their implementation. That's about as far as their reach rightfully extends. EDIT: also, the fact that they aggressively lock down their compiler and have such hostility to anyone working in parallel is imo the definition of "holding it back"
obeavs 3y ago
Some references if helpful: * Elmish (F#) repo - https://github.com/elmish/elmish https://github.com/elmish/elmish * The Elmish Book (... remarkably good) - https://zaid-ajaj.github.io/the-elmish-book/#/ https://zaid-ajaj.github.io/the-elmish-book/#/ * Fable compiler - https://fable.io/ https://fable.io/ The F# community is very friendly (sub-communities as well), and there are plenty of good opportunities to contribute OSS work across any skill level. Phosphor isn't hiring right now, but we will begin a search for FE/interface engineers soon. oliver@phosphor.co for anyone interested.
aranchelk 3y ago
> In theory Elm is just such a fascinating project... if it was not held back by the people developing it. PureScript may be worth a look, it’s got several features that were rejected by Elm devs: typeclasses, ability to publish modules that use FFI to JS, runs server-side, etc.

Capricorn2481 3y ago

I looked at Fable and the resulting code just looked way more complicated than anything Javascript could write. I'm interested in F# still on the backend, but I don't think people "haven't discovered" Fable, it's just not a great alternative.

obeavs 3y ago
Yeah, I suppose it depends on what you're building. Three years of building with it (plus constant re-evaluation of that decision) has supports our conclusion that it is far more concise and easier to manage (esp for less technical folks who need to sign off on the business logic/domain) than anything we'd have done in JS. With that said, we're building a product that requires much more interactivity than most, and we're performing a lot of typical "back-end" logic in the client - that might color our evaluation. To be sure, it hasn't been without tradeoffs, but we haven't found those tradeoffs to be at the language level.
durable_queue 3y ago
The generated JS is only somewhat readable, but you're not supposed to be reading the F#.
- Capricorn2481 3y ago
  I'm not supposed to read the F#?? Someone should tell the Fable guys
catlover76 3y ago
Is it really appreciably different from "transpilation" with TypeScript? Like, I have seen a little of both (I've used a lot of TypeScript, but who actually looks at the output JS lol), and while I agree the JS output from Fable seemed surprisingly verbose, I'm not sure I see how it practically matters unless one is worried about bundle size or something.
- Capricorn2481 3y ago
  I'm not talking about that JS output, I mean the F# itself. While I'm not the most familiar with F#, I've enjoyed other languages that transpile to JS a lot more. For whatever reason, F# to me looks surprisingly verbose in Fable, which is odd because it's pretty terse on the backend.

gemstones 3y ago

I'm familiar with Fable, it's a very conscious choice not to use it in any web applications. Debugging its JS output is not fun.

deleted 3y ago

[deleted]

depr 3y ago

Do you integrate Rust and F# in any way or do they just talk via an HTTP or similar API?