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

Reason: A new interface to OCaml

facebook.github.io

Post reply on HN
Print view View original

161–170 of 294 posts

Re: Reason: A new interface to OCaml

#161

Post by Drup »

testcross wrote: post #111
oblio wrote: post #109

Has anyone here built something say, over 10k lines in Ocaml? How is the development experience? IDEs, debuggers, linters, deployment, etc.

There is no IDE. But you can use merlin, which is amazing. Debuggers are not very developed, neither are linters. For me, the development experience is pretty good. But it takes some time to get used to this new world. Conventions are not the same.

Well, we have an excellent linter, it's called "The OCaml type checker". It even has customizable warnings for your coding style. ;)

Re: Reason: A new interface to OCaml

#162

Post by jordwalke »

nikolay wrote: post #145

Nice, but I always wonder why function is abbreviated as the longer unambigous fun and not just fn?!

Jordan here (I work on Reason):

I agree with you but one benefit of `fun` is that it aligns better with multiples of two spaces. It's important when lists end up wrapping:

    /* Nice multiple of two spaces */
    fun myFun
        xyz
        abc => {
      doSomeThings(xyz, abc);
    };

    /* yikes, only one horizontal space between
     * doSomething and abc on the line above */
    fn myFun
       xyz
       abc => {
      doSomeThings(xyz, abc);
    };
I'm obviously no stranger to bike-shedding!

Re: Reason: A new interface to OCaml

#164

Post by avsm »

cpeterso wrote: post #102
jordwalke wrote: post #63

Earlier quoted context omitted.

Thanks for the thoughts. I would definitely not call Reason a new language, but rather a new interface to an existing language that is already great. Not all languages make it easy to provide such an interface, but OCaml did, and the timing made sense.

I like the syntax cleanups. What's the advantage of using the existing OCaml toolchain over using an LLVM backend? Expediency and interop with Facebook's other OCaml libraries? From what I have read, the OCaml compiler only does basic optimizations and the runtime has poor multithreading support.

It's important to realise that an LLVM backend is not a panacea -- the OCaml native code generator is highly optimised for the calling conventions and OCaml GC already. LLVM's IR doesn't quite track values at the same abstraction level as OCaml so some features such as exceptions become very expensive if mapped onto LLVM without changes to the IR.

Another major recent advance in OCaml 4.03 (released last month) is the flambda middle layer -- basically an epic inlining and allocation elision pass. See https://blogs.janestreet.com/flambda/ for more on it, but it's already giving 10-20% performance improvement on real world code.

Multicore is also coming soon -- see https://ocaml.io/w/Multicore for a summary of activity there.

Re: Reason: A new interface to OCaml

#165

Post by jordwalke »

MichaelGG wrote: post #100

I started off a bit skeptical with the What's OCaml's status with multithreading? Are there any proposals for more flexible operators, so there doesn't need to be different operators for different numerics? (F# solves this by allowing inlined functions.)

I suspect the syntax of `<-` (or lack thereof) will be a common topic of discussion. Let's see how various audiences respond to this change and then discuss if we'd like to restore `<-` for mutation. Personally, I don't use a ton of mutations in my code so I have less at stake and if there's anything we can do to appeal to a wider audience, I'm inclined to give it a shot.

Re: Reason: A new interface to OCaml

#166

Post by jordwalke »

stuartaxelowen wrote: post #110
jordwalke wrote: post #98

Earlier quoted context omitted.

Please take a look at the FAQ which describes the best way to move forward with evolving the syntax. It helps to know your personal technical background and where you're coming from, as well. I do like your idea, but you can currently use parens - it's just that they aren't required by the parser when the argument is clearly one item (like an integer constant etc). Then at that point, it's just a matter of configurin…

My background is in Python, Scala, Java, C, and Ruby. My reaction is based on the monstrous DSLs I've seen in Scala and Ruby (because the language lets them), where the clever syntax actually hid the important features of the interface. Every time you get to "wait what is this actually doing" and you have to learn another tiny language instead of just writing functions that return a `Future[HttpResponse]` and be done…

Thanks stuartaxelowen, the feedback is actually really valuable one way or another.

Re: Reason: A new interface to OCaml

#167

Post by e12e »

jordwalke wrote: post #138
honua wrote: post #119

What problems would be well solved by Reason/OCaml?

For now: - Teaching new programmers how to use ML, and OCaml in particular. - Keeping consistent formatting rules among a large team or project and automating that within your editor. - Benefiting from the comprehensive pattern matching checks provided by the OCaml compiler. - Benefiting from faster compile times of `ocamlc`, or faster native execution time of `ocamlopt`. - Benefiting from Merlin, and the new version…

Interesting project. Ever since being exposed to a bit of Standard ML (which never had much of a "real-world" standard library, as far as I could figure out), I always wanted to like OCaml, but couldn't quite get over the odd syntax.

It's been a while, but taking a look at this comparison of SML and OCaml again:

http://www.mpi-sws.org/~rossberg/sml-vs-ocaml.html

It feels a bit like you've landed in some strange neither-or space for Reason? I'm not sure if it would make sense to bend OCaml into being a subset of SML or not (I know there are some differences, just not sure how much those require different syntax, or if they do) - but did you consider moving more toward SML?

I can see the reasoning between going from to != and It's exiting times with Elixir and Lisp Flavoured Erlang for Erlang, and now Reason for OCaml (and to some extent various dialects, languages and DSLs for Javascript, like typescript, coffee script and JSX for React).

Re: Reason: A new interface to OCaml

#168

Post by ufo »

jordwalke wrote: post #165
MichaelGG wrote: post #100

I started off a bit skeptical with the What's OCaml's status with multithreading? Are there any proposals for more flexible operators, so there doesn't need to be different operators for different numerics? (F# solves this by allowing inlined functions.)

I suspect the syntax of `<-` (or lack thereof) will be a common topic of discussion. Let's see how various audiences respond to this change and then discuss if we'd like to restore `<-` for mutation. Personally, I don't use a ton of mutations in my code so I have less at stake and if there's anything we can do to appeal to a wider audience, I'm inclined to give it a shot.

Maybe I'm too used to Ocaml to comment but I think using `=` for mutation is a bit misleading because it might make it appear that `x.mutablefield = bla` and `let x = bla` are the same thing, which is the case for typical imperative languages (but definitely not for Ocaml).

BTW, one thing that I do find awkward about Ocaml's syntax is the difference between := and <-. Dunno if its possible to unify them in a sane manner though.

Re: Reason: A new interface to OCaml

#169

Post by ufo »

devit wrote: post #143

It seems to me that Rust would be pretty much strictly better than this. In particular Rust has similar syntax, seems to have all Reason's features plus the linear types and regions/borrowing that allow memory and concurrency safety while still being able to mutate memory and not being forced to use GC. They are aware of Rust since they cite it in their page, so I wonder why they decided to create this instead of usi…

Some people consider the garbage collector to be a feature :)
Post reply on HN