5 ms·

Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks). For frontend dev't I

by cies 6y ago

Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks). For frontend dev't I really like Elm lately. (the article makes many refs to Elmish, the Elm-on-F# project).

adenozine 6y ago
Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.
- toolslive 6y ago
  concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.
  - adenozine 6y ago
    Ah, of course. Clerical mistake on my part
  - patrec 6y ago
    You make it almost sound like having a fractured eco system with two different incompatible async frameworks is a good thing! :P
- Cederfjard 6y ago
  Could you please elaborate on what you said about Elm and its author? How come?
  - deleted 6y ago
    [deleted]
  - adenozine 6y ago
    https://reasonablypolymorphic.com/blog/elm-is-wrong/ https://reasonablypolymorphic.com/blog/elm-is-wrong/ Here's a good starting place. Look for some discussions about typeclasses and read for yourself. Ask yourself if you'd bet on this person, and if you'd build critical tools for your org with a tool dictated by them. I have no ill will for Elm. I'm grateful it exists and that we can all learn. I'd never invest in it though, it's too much a risk for things that could affect my ability to put food on the table quickly enough. I'm not a frontend guy, so if some crazy frontend bug happened and crunched up my landing page or any of my forms, I'm not confident that I could debug it fast. I hate to say it, but honestly I think TS has to be the future of front end web. It's simply too solid to consider very many other options. The one-man-running-the-show act kinda works for small things, like Tarsnap is a great example. But for languages that are powering business frontends, I can't have some goofball with a bad opinion holding up progress on something important.
- cies 6y ago
  Works like a charm, and when the community tanks (what will most likely be due to the close access innovation model and the main authors behavior), then there is a project to convert Elm code to PureScript. :)
- dfgdghdf 6y ago
  The Elm architecture has been implemented in F# as "Elmish". It's quite nice! I think Fable wins over Elm, simply because F# is such a great server-side language. Even if I was writing an Elm app, I would still likely reach for F# on the back-end.
naringas 6y ago
similarly to how C# is very much java.net ??
- samus 6y ago
  This is a bit inappropriate since for a long time now Java was busy catching up to C#. When Project Valhalla merges, Java's type system will become very close to what C# is now: reified generics and first-class value types. Algebraic data types will also come to town. But only after Project Loom merges, Java will be firmly ahead again with a fresh take on all matters async.
  - pjmlp 6y ago
    C# also keeps copying Java stuff to this day like default interface methods. In fact, having had spent most of my focus across Java, .NET and C++ since their early days, it is quite interesting to follow how certain features keep being copied across them.
  - ecshafer 6y ago
    But C# was literally Microsoft's Java implementation that they forked after they were sued by Sun, was it not? So it is quite appropriate.
    - Jtsummers 6y ago
      C#'s development was motivated by their relationship with Sun, but J++ was MS's non-conforming Java implementation. They were sued for it, and basically couldn't develop it any further (with regard to maintaining Java compatibility, to the extent that they cared to at least).
    - TurkTurkleton 6y ago
      Microsoft's Java implementation that got them sued was J++. As part of the settlement, they weren't allowed to add any new features to it, and it quietly faded into obscurity, along with its CLR counterpart J#, the latter having finally left even extended support in 2017. C# was developed independently of J++ and J# (though J# was based on J++ to provide a transition path for J++ developers), and although Anders Hejlsberg (original lead architect of C#) did also work on J++, he also worked on Turbo Pascal and Delphi before coming to Microsoft, and I'd suspect that those influenced C# more (more conceptually than syntactically, of course).
mumblemumble 6y ago
In the same way that Objective-C is just C++ for Macs. They share a common lineage, but do so many things so differently that you really can't consider them to be all that similar. And the difference starts with having completely different object systems. Beyond different OOP mechanisms, some things OCaml has that F# doesn't: - Functors - Polymorphic variants - camlp4 And some things F# has that OCaml doesn't: - Computation expressions - Type providers - Quotations (as a built-in) - Units of measure - Active patterns
sideeffffect 6y ago
> Isn't F# pretty much OCaml.NET? Kinda yes, kinda no. There's a whole interesting story to it: https://dl.acm.org/doi/pdf/10.1145/3386325 https://dl.acm.org/doi/pdf/10.1145/3386325
gameswithgo 6y ago
It is, but with a syntax that most people find less odd, and a couple of very compelling features, like..the ability to leverage more than one core, active patterns, and type providers.

by cies 6y ago

adenozine 6y ago

Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.

toolslive 6y ago
concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.
- adenozine 6y ago
  Ah, of course. Clerical mistake on my part
- patrec 6y ago
  You make it almost sound like having a fractured eco system with two different incompatible async frameworks is a good thing! :P
Cederfjard 6y ago
Could you please elaborate on what you said about Elm and its author? How come?
- deleted 6y ago
  [deleted]
- adenozine 6y ago
  https://reasonablypolymorphic.com/blog/elm-is-wrong/ https://reasonablypolymorphic.com/blog/elm-is-wrong/ Here's a good starting place. Look for some discussions about typeclasses and read for yourself. Ask yourself if you'd bet on this person, and if you'd build critical tools for your org with a tool dictated by them. I have no ill will for Elm. I'm grateful it exists and that we can all learn. I'd never invest in it though, it's too much a risk for things that could affect my ability to put food on the table quickly enough. I'm not a frontend guy, so if some crazy frontend bug happened and crunched up my landing page or any of my forms, I'm not confident that I could debug it fast. I hate to say it, but honestly I think TS has to be the future of front end web. It's simply too solid to consider very many other options. The one-man-running-the-show act kinda works for small things, like Tarsnap is a great example. But for languages that are powering business frontends, I can't have some goofball with a bad opinion holding up progress on something important.
cies 6y ago
Works like a charm, and when the community tanks (what will most likely be due to the close access innovation model and the main authors behavior), then there is a project to convert Elm code to PureScript. :)
dfgdghdf 6y ago
The Elm architecture has been implemented in F# as "Elmish". It's quite nice! I think Fable wins over Elm, simply because F# is such a great server-side language. Even if I was writing an Elm app, I would still likely reach for F# on the back-end.

naringas 6y ago

similarly to how C# is very much java.net ??

samus 6y ago
This is a bit inappropriate since for a long time now Java was busy catching up to C#. When Project Valhalla merges, Java's type system will become very close to what C# is now: reified generics and first-class value types. Algebraic data types will also come to town. But only after Project Loom merges, Java will be firmly ahead again with a fresh take on all matters async.
- pjmlp 6y ago
  C# also keeps copying Java stuff to this day like default interface methods. In fact, having had spent most of my focus across Java, .NET and C++ since their early days, it is quite interesting to follow how certain features keep being copied across them.
- ecshafer 6y ago
  But C# was literally Microsoft's Java implementation that they forked after they were sued by Sun, was it not? So it is quite appropriate.
  - Jtsummers 6y ago
    C#'s development was motivated by their relationship with Sun, but J++ was MS's non-conforming Java implementation. They were sued for it, and basically couldn't develop it any further (with regard to maintaining Java compatibility, to the extent that they cared to at least).
  - TurkTurkleton 6y ago
    Microsoft's Java implementation that got them sued was J++. As part of the settlement, they weren't allowed to add any new features to it, and it quietly faded into obscurity, along with its CLR counterpart J#, the latter having finally left even extended support in 2017. C# was developed independently of J++ and J# (though J# was based on J++ to provide a transition path for J++ developers), and although Anders Hejlsberg (original lead architect of C#) did also work on J++, he also worked on Turbo Pascal and Delphi before coming to Microsoft, and I'd suspect that those influenced C# more (more conceptually than syntactically, of course).

mumblemumble 6y ago

In the same way that Objective-C is just C++ for Macs. They share a common lineage, but do so many things so differently that you really can't consider them to be all that similar. And the difference starts with having completely different object systems. Beyond different OOP mechanisms, some things OCaml has that F# doesn't: - Functors - Polymorphic variants - camlp4 And some things F# has that OCaml doesn't: - Computation expressions - Type providers - Quotations (as a built-in) - Units of measure - Active patterns

sideeffffect 6y ago

> Isn't F# pretty much OCaml.NET? Kinda yes, kinda no. There's a whole interesting story to it: https://dl.acm.org/doi/pdf/10.1145/3386325 https://dl.acm.org/doi/pdf/10.1145/3386325

gameswithgo 6y ago

It is, but with a syntax that most people find less odd, and a couple of very compelling features, like..the ability to leverage more than one core, active patterns, and type providers.