Hacker News Reader

Comment by cies | Hacker News Reader

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

View on HN

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

> 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

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.

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.

concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.

Ah, of course. Clerical mistake on my part

You make it almost sound like having a fractured eco system with two different incompatible async frameworks is a good thing! :P

Could you please elaborate on what you said about Elm and its author? How come?

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.

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

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.

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

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.

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.

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.

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

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

I actually find C# to be more like "the successor to C++ that I actually want" rather than "Microsoft Java" at this point. If you approach C# as if you're just programming Java you are going to be missing out on some nice features, such as structs, unsafe blocks (including pointers), and modern additions like pattern matching. On top of that, I find that I prefer certain things about C#'s implementation compared to Java - reified generics over type erasure, for instance. Apparently Project Valhalla will change some of this implementation stuff. But for a while now I've found C# to be ahead of Java.

The syntax is also way nicer. Having to type out "implements/extends" instead of ":", for example. These goes a long way to denoise a very noisy language.

Reply on news.ycombinator.com