25 ms·
Reason: A new interface to OCaml
- e_d_g_a_r 10y agoI for one welcome the syntax. I run the OCaml meetup in Silicon Valley and syntax is definitely an issue for newcomers. This makes it easier for other programmers to instantly just jump into OCaml/ML rather than ask about what is `in` or what is `let foo = function`, etc etc. EDIT: Hosting a Meetup this friday at 6pm in San Francisco about Reason and how to instantly start using it, http://www.meetup.com/sv-ocaml/events/231198788/ http://www.meetup.com/sv-ocaml/events/231198788/
- weberc2 10y agoThis definitely makes me feel more warmly toward OCaml. Syntax has kept me away in the past. It's silly, but it's really hard to evaluate a language if you can't read the examples.
- e_d_g_a_r 10y agoPeople like to say that syntax doesn't matter and over the long term maybe it doesn't but anything that detracts from learning a language does matter and sometimes syntax is exactly that needless barrier.
- hk__2 10y agoIMHO `let in` has more to do with semantics than syntax. `let a = b;` doesn’t mean the same as `let a = b in …`. It’s like `def` vs. `let` in Clojure. Outside of this specific case I agree OCaml doesn’t have an easy syntax; I have to re-learn some parts of it every time I need to write in that language.
- tom_mellior 10y ago> It's silly, but it's really hard to evaluate a language if you can't read the examples. No, this is not a silly notion. But I don't think the difference Reason makes is as big as you think. I mean, I don't really believe that you can read this: let foo = if (cond) { x } else { y }; foo + 1 but not this: let foo = if cond then x else y in foo + 1
- ngrilly 10y agoThe 'in' is what makes it difficult to understand for someone not familiar with OCaml syntax and semantics. Reason makes it easier.
- tom_mellior 10y agoI've heard that said, but I don't see how it's a big deal. OK, the very first example introducing let bindings would have to come with a sentence like "the 'in' part of 'let ... in' means 'in' just like in English: 'let' the binding be valid 'in' what follows". You don't have to define a whole new syntax where a single sentence in a language tutorial might be enough. But I admit that I probably can't fully appreciate whether this is really difficult for someone used to JavaScript.
- ngrilly 10y agoOf course, once you know what 'in' means, it's easy to read, but you have to learn it, and get used to it. I've teached programming to students in finance, and this learnt me how much I underestimated the impact small things like that can have on the learning curve (and the motivation).
- jordwalke 10y agoExcept when you're in the top level - in which case you don't use `in`. Oh, and don't forget all the nuance of interleaving imperative commands. I'm an experienced OCaml dev and this trips me up (the "ml compared" section of the docs lists some common pitfalls that Reason resolves).
- tom_mellior 10y agoAh, but here you seem to be talking about when to write 'in'. Reading it is much simpler: Just ignore that it's there, and voilà, you're set. (I'm an experienced OCaml dev and := versus <- trips me up from time to time when choosing which one to write, but not when reading code.)
- 10y ago
- mseri 10y agoWill you stream or record the session?
- e_d_g_a_r 10y agoProbably not, sorry.
- dankohn1 10y agoI presume your phrasing is referencing http://knowyourmeme.com/memes/i-for-one-welcome-our-new-insect-overlords http://knowyourmeme.com/memes/i-for-one-welcome-our-new-inse... except that you actually do welcome the syntax, right?
- jameshart 10y agoWonder if this project has anything to do with Eric Lippert's move to Facebook (https://ericlippert.com/2016/02/08/facebook/ https://ericlippert.com/2016/02/08/facebook/ - Eric has also been producing a series of blog posts implementing a Z-Machine interpreter in OCaml to run mini-Zork on, starting here: https://ericlippert.com/2016/02/01/west-of-house/ https://ericlippert.com/2016/02/01/west-of-house/). Eric was on the C# compiler team at Microsoft and previously worked on JScript.
- kristianp 10y agoHis moving to facebook explains why he didn't do the zork interpreter in F#. Not sure why the Reason syntax isn't more like F# though.
- zem 10y agodamn, i recently started writing a z machine interpreter in ocaml, and now i both really want to read those posts and really don't want to be influenced by lippert's design decisions before i've at least gotten my own project solidly underway.
- lmm 10y agoIt's always better to know about the design decisions others have taken. If they faced the same choices you did, you can know their view on the tradeoffs (and experiences with their choice) and choose the same way as they did or choose differently, but either way you make your choice with a little more knowledge. If they come up with an idea you didn't even think of, surely you want to know about it, even if you aren't actually going to use it.
- zem 10y agoif i were doing it as something intended for serious use, i'd definitely want to see how lippert did it. but the point of doing this (other than the whole rite-of-passage aspect of writing a z machine :)) is the challenge of designing and implementing it from scratch, and hopefully as cleanly and compactly as possible. if i read lippert's blog and he came up with an idea i didn't think of after i had already solved it some other, potentially worse way, i'd be delighted to see that it could be done better. if i see his solution to some piece that i haven't even implemented yet it would just tempt me to simply adopt his solution.
- avsm 10y agoThere's a screencast fresh off the presses on the info page at https://ocaml.io/w/Blog:News/A_new_Reason_for_OCaml https://ocaml.io/w/Blog:News/A_new_Reason_for_OCaml I'm finally going to switch away from my ancient nvi setup and use Atom instead! MirageOS recently moved all our libraries over to using the new PPX extension point mechanism in OCaml instead of the Camlp4 extensible grammar. This means that MirageOS libraries should be compatible with Reason out of the box -- so it'll be possible to build unikernels from a slick editor interface quite soon hopefully!
- testcross 10y agoIs nuclide good enough? A few weeks ago, a lof of merlin features were still missing. As was the auto-indentation.
- jordwalke 10y agoThe Atom Reason plugin uses Nuclide's system for error rendering (in the diagnostics bar), and type hints. But the actual logic for integrating with Merlin has been completely rewritten in Reason itself, and compiled from Reason into JS to run as an Atom plugin. So there are still merlin features missing because the Atom plugin is relatively young, but if you want to help us implement the missing features, it can be a fun way to try Reason itself (compiling to JS).
- hellodevnull 10y agoSite doesn't load in Firefox. Works in Chrome.
- kruhft 10y agoI was curious why it doesn't scroll. Barely works but gives a CPU spike and just jumps around between pages...
- jordwalke 10y agoChrome and Safari both worked for me. Common reports about Firefox, so I disabled the gif. Can you let me know if it works now?
- jodah 10y agoIncredible, but you are correct. Pegs 1 CPU in FF and while it loads, it barely scrolls.
- giancarlostoro 10y agoHaving the same issue, it loads very weirdly.
- jordwalke 10y agoPretty sure it was the gif. I've disabled it. Could you try again?
- Paul_S 10y agoWebsite fries the CPU (FF).
- freshbob 10y agoSame here. What a piece of shit the internet has become.
- SilasX 10y agoMan, I wish someone would release tools for building fast, safe systems so we could follow that model!
- thefastlane 10y agoglad i'm not the only one thinking this.
- deminature 10y agoNo problems here - Chrome, Mac.
- jordwalke 10y agoSounds like FF can't handle gifs, but Chrome/Safari do a good job. I've disabled the gif on the main page just to be friendly to FF while I figure out a better approach. Thanks for the report.
- deleted 10y ago[deleted]
- Paul_S 10y agoI can run the Unreal engine, use google maps but not view your website. I'm not convinced Firefox is at fault here. Is there any interactive functionality that your website offers that would justify extraordinary demands or does it simply display some text and images?
- dmm 10y ago
- TY 10y agoOk, it might be the end of the day for me and I'm denser than usual, but I can't understand what is this? Ocaml to JS transpiler? Checked this out, but the reason still eludes me: https://ocaml.io/w/Blog:News/A_new_Reason_for_OCaml https://ocaml.io/w/Blog:News/A_new_Reason_for_OCaml (pun intended)
- emerongi 10y agoI feel like FB needed it and also released it to the public, but outside of FB, there's little Reason to use it.
- deleted 10y ago[deleted]
- zem 10y agoit's a really well-thought-out set of improvements to the ocaml syntax, done by people who actually seem to appreciate MLish syntax for the most part (rather than trying to get it to look more like C for its own sake, a la mythryl)
- GemG 10y agoThought it was mostly summed up in the first paragraph... "Reason is a new approachable interface to the OCaml language, with the long-term goal of improving the developer experience by providing a functional syntax and toolchain for writing, building and sharing code quickly and easily."
- bcherny 10y agoI think the question was, what's the relationship between Reason and JavaScript?
- justincormack 10y agoIt is a new syntax for OCaml but OCaml can compile to JS really well so Reason can too.
- civilian 10y agoI know that it's common to have namespace collisions, but their logo is so similar to Reason magazine's. https://reason.com/ https://reason.com/
- kaushiks 10y agoThere's also a DAW called Reason: https://en.wikipedia.org/wiki/Reason_%28software%29 https://en.wikipedia.org/wiki/Reason_%28software%29
- inopinatus 10y ago... and the Neal Stephenson fan in me was just a smidgen disappointed that this was not the introduction of a hypervelocity flechette gatling railgun.
- ebbv 10y agoSimilar to the point that I'm sure it is a subconscious plagiarism. In other words, the person who created the logo had seen Reason magazine's and unintentionally channeled it when creating the new one.
- chc 10y agoIt's also about as similar to the common representation of ruthenium on the periodic table.
- udkl 10y agoYou mean 'un-reasonably' similar ?
- grhmc 10y agoI'm seeing "BUILD SYSTEMS RAPIDL" over here on Linux.
- jordwalke 10y agoThanks there's some strange font rendering issues. Will fix! edit: now fixed.
- aerovistae 10y agoBUILD SYSTEMS RAPID
- ipsum2 10y agoLooking at http://facebook.github.io/reason/mlCompared.html http://facebook.github.io/reason/mlCompared.html it looks like regular OCaml, with a sprinkling of JS syntax.
- jordwalke 10y agoFor now, that's somewhat accurate. If you check out the JS comparison page, you might say it looks like JS with OCaml's influence. The point of the syntax toolchain is actually not to get it right on the first try but to make something viable that is easier to learn/read, avoid bike-shedding, and put all the right tooling in place so that we can very seamlessly upgrade after taking in feedback. It's pretty liberating to know you have that ability to move forward rapidly and automate all of the upgrades.
- partiallypro 10y agoDoes anyone Else's Firefox absolutely slow to a crawl on this page? Edit: just doesn't load at all on Edge. Does load in Chrome/Opera and surprisingly IE 12 but doesn't load the logo's font.
- ulber 10y agoThis page is completely unusable due to lag. From the other comments it seems this is FF specific. One would think FB would have the resources to test new pages at least on common browsers before publishing. Edit: The fix came quickly though.
- Polarity 10y agoyea, open page, lag, close page. kthxbye
- jboles 10y agoyea, open page, lag, see that it is facebook's usual bloat, task manager, kill firefox.exe process.
- animex 10y agoWhile not cool, that's a pleasant surprise to see something made-first for FF! Glad to see people still fighting against browser mono-culture. Disclaimer: This post was written in Chrome.
- jonesetc 10y agoThe bug is only in FF, not the page only works in FF.
- larsiusprime 10y agoThe lag is firefox specific, he means.
- ht85 10y agononetheless it's nice to see something made for FF-only
- jordwalke 10y agoThanks, we're looking into how to fix the perf in FF. Meanwhile, it works on my tiny mobile cell phone.
- andrew_wc_brown 10y agoEverything reads like double talk. Not sure what I would want to use this for.
- ClosureChain 10y agoI wonder if the people at Propellerheads will sue Facebook for using the name of their software https://www.propellerheads.se/reason https://www.propellerheads.se/reason
- Cyph0n 10y agoThis looks very interesting. I've always had OCaml in mind but never actually got around to using it in a project. Facebook could have done a better job describing what exactly this is, but they do provide a good overview at the end of the page (strangely!) [1]. In summary, Reason [2] is a new language (correction: interface to OCaml) that shares a part of the OCaml compiler toolchain and runtime. I don't know of any language that uses a similar approach, that is, plugging into an existing compiler toolchain. I guess a reasonable yet inaccurate analogy would be Reason -> OCaml is like Elixir -> Erlang or Clojure -> Java. I hope Reason can provide OCaml with the extra push needed to bring it into the mainstream PL space and more widespread adoption. [1]: http://facebook.github.io/reason/#how-reason-works http://facebook.github.io/reason/#how-reason-works [2]: https://github.com/facebook/reason https://github.com/facebook/reason
- jordwalke 10y agoThanks 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.
- cpeterso 10y agoI 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.
- jordwalke 10y agoFacebook has many projects that are already written in OCaml, and Reason provides a path forward for seamlessly, and incrementally moving projects over to the new syntax/style. Feel free to take a look at some Reason in the wild, used inside of the Infer project at Facebook: https://github.com/facebook/infer/tree/master/infer/src/IR https://github.com/facebook/infer/tree/master/infer/src/IR Apart from that, although syntax is the "user interface" to a language, and user interfaces are very important, there really is so much to a language beyond the syntax. I see Reason's syntax as a way to make the really good parts of OCaml exposed to a wider audience, while making existing OCaml developers more productive in their editors. Some things you might appreciate about OCaml's core language (which Reason provides a new interface to): - World class pattern matching. - Excellent type inference. - Bare metal compilation without a VM, but alternatively the ability to compile into JS. - Great predictable performance, even without a ton of performance optimizations (because the runtime is so simple), but take a look at 4.03 which includes a new F-lambda optimization pass. Even without F-lambda the perf is competitive with other systems languages, and F-lambda buys you another good 10-30% reduction in CPU or so. - Multicore support is progressing. Here's a PR from today to add multicore support to the native backend (https://github.com/ocamllabs/ocaml-multicore/pull/47 https://github.com/ocamllabs/ocaml-multicore/pull/47)
- incepted 10y agoInteresting but since they are designing a revised syntax, I wish they had got rid of Ocaml's semi colon. These stand out in 2016.
- jordwalke 10y agoSee the FAQ, as this is a fairly anticipated question. There's some benefits to having some token to separate let bindings and statements, so that the grammar is unambiguous, and it doesn't matter too much which token is used (monkey emoji anyone?) However, I think it may be possible to eliminate delimiters altogether eventually. Because we have the `refmt` program which can convert and beautify between two arbitrary versions of the syntax, we'll be able to automatically upgrade your code if we do find a way to eliminate delimiters unambiguously. Stay tuned.
- evincarofautumn 10y agoIt would be good to look at the F# spec for a description of their existing indentation & semicolon elision rules. In practice I’ve found them nice to work with, although they sometimes require excessive indentation.
- jordwalke 10y agoThanks evincarofautumn! I'll take a look.
- mseri 10y agoWhy? It has more benefits that downsides. I think the only complains we can do at the moment are the switch from '<-' to '=' for mutable records and from '->' to '=>' for functions. But we will see how it will evolve
- stuartaxelowen 10y agoCan we please keep using parens for function invocation? Leaving them out hurts readability.
- bjz_ 10y agoThe difference between curried langs like OCaml and Haskell and languages like Ruby and Elixir are that the leaving out of parens actually means something, ie. all functions take one argument. If you wanted parens whilst maintaining the same semantics, you would end up having to do write: `add(2)(3)`
- stuartaxelowen 10y agoIndeed, but leaving out the parens makes more work for humans. What does `a b c` mean? `a(b)(c)`? `a(b(c))`? If the only thing that is gained by leaving out the parens is brevity, I don't think its worth it.
- reycharles 10y agoIt would be `(a(b))(c)`. Interestingly, you're already leaving out parens for brevity.
- deno 10y agoBut it’s not `a b c`. Rather it’s something like `verb noun noun`. Which is much less ambiguous. In a language with currying semantics [(((a(b))(c))(d)] the only logical explicit syntax sugar would be LISP-like, so (v n n), (v (v2 n)). That’s imo way worse — you end up with lots of useless junk)))))))) in anything non-trivial.
- stuartaxelowen 10y agoWhat about `verb noun verb noun`? Is the second verb a parameter or is it being invoked on the noun?
- 10y ago
- mseri 10y agoI love OCaml, but that's a really nice reshape of OCaml syntax! And apparently things will be interoperable. I am really curious to see where it goes. EDIT: and they want to use and maintain compatibility with ppx. Great news
- jordwalke 10y agoInterop with OCaml is perfect and should remain so. ppx should work (modulo issues that we're not aware of). You can even upgrade your existing OCaml source code to be in the Reason style by using the versatile `refmt` program that is included.
- mseri 10y agoThanks. I am definitely going to play with it!
- intrasight 10y agoPretty disappointed that they'd release something that butchers Firefox.
- greyhat 10y agoThe slowness in Firefox appears to be solely due to this: @media (min-width: 1180px) { body:not(.no-literate) .content-root { background-color: #fdfcfc; -webkit-box-shadow: inset 780px 0 #fff, inset 781px 0 #e7e7e7, inset 790px 0 3px -10px rgba(0,0,0,0.05); box-shadow: inset 780px 0 #fff, inset 781px 0 #e7e7e7, inset 790px 0 3px -10px rgba(0,0,0,0.05); } } Removing it in the Firefox style editor restores normal performance. Edit: And they have commented out the box-shadow! Hah.
- KaoruAoiShiho 10y agoI've been dealing with this lag in firefox for the past 6 or 7 years. It's hilarious to me that they still haven't fixed it. Just one of the reasons I've been extremely negative on firefox.
- querulous 10y agoif this had come out five years ago i'd probably be all over it, but i think i'd rather just use rust at this point. different syntax but better safety and it's not like the ocaml ecosystem has a lot to offer
- deleted 10y ago[deleted]
- molotok 10y agoFry Firefox RAPID.
- konschubert 10y ago> A new, developer experience for rapidly building fast, safe systems. The comma placement suggests that developer is an adjective for experience.
- jordwalke 10y agoFixed, thank you @konschubert.
- bjz_ 10y agoWould be nice to see modular implicits like those that are being proposed for OCaml. It's a shame to not have any form of ad-hoc polymorphism.
- chenglou 10y agoReason will have modular implicit. It's really just OCaml under the hood.
- jordwalke 10y agoWhat cheng said, but we could also make sure that the syntax for modular implicits plays very nicely with the rest of the grammar. With Reason we can rethink the grammar holistically instead of having to find room in it for new features. The hard part is in the actualy implementation of Modular Implicits, but that's currently being handled by skilled professionals and Reason will be able to use them.
- bjz_ 10y agoAh, woops - didn't realise that Reason was such a thin syntactic layer over the semantics of OCaml. That approach makes sense then.
- jordwalke 10y agoYes, I'd describe it as being "non-invasive". It means we get the benefit of literally every feature implemented in the core of the language (multicore, F-lambda, modular implicits, ppx attributes), but can decouple the process of deliberating over how this is presented to the user, and (not to beat a dead horse) but we don't even have to worry about getting it right on the first try! Now that I've embraced this as the new "normal" way, I couldn't imagine having to design a syntax and stress over having to determining the exact permanent concrete syntax that needs to live virtually forever without knowing which other language features will be added later.
- zem 10y agoi noticed this in the examples: | List p (List p2 (List p3 rest)) => false /* 3+ */ has the regular list destructuring in pattern match syntax been removed? that's pretty sad, if so - lists are the default data structure in ocaml, and it's worth retaining some special syntax for cons especially in pattern matches.
- chenglou 10y agoNo, the sugar's still there.
- ufo 10y agoFor me the odd bit is that they called the constructor List instead of Cons.
- jordwalke 10y agoThanks for the feedback. We can change it to `Cons`, but I was assuming that anyone who knew what `Cons` was, would know what `List` meant, but not everyone who understood what `List` meant, would know/recall what `Cons` meant.
- MichaelGG 10y agoI started off a bit skeptical with the <- renaming to =. Mutability should be rare enough that <- makes things stand out. But apart from that I think I rather like this syntax, on the whole. Not a fan of semicolons. It also makes me appreciate F#'s #light syntax (now its default). Using whitespace really clarifies stuff, and there's always in and ; for fallback. 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.)
- kcsrk 10y agoMulticore support is progressing nicely. Only earlier today I made a PR for adding nativecode compilation for multicore: https://github.com/ocamllabs/ocaml-multicore/pull/47 https://github.com/ocamllabs/ocaml-multicore/pull/47. A lot more information about the multicore OCaml project can be found here: https://ocaml.io/w/Multicore https://ocaml.io/w/Multicore
- jordwalke 10y agoI 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.
- ufo 10y agoMaybe 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.
- int_19h 10y ago
- swuecho 10y agoDo it provide a usable standard lib? If so, I may try to use it in side project.
- __float 10y agoJane Street's Core is probably what you're looking for.
- programLyrique 10y agoBatteries Included is another solution (which is more compatible with the thin included standard library): http://ocaml-batteries-team.github.io/batteries-included/hdoc2/ http://ocaml-batteries-team.github.io/batteries-included/hdo...
- kcsrk 10y agoThere is the small standard library that ships with the compiler. And then there are more extensive ones such as Batteries and Core. It is easy to generate docs in Reason syntax from OCaml projects using `redoc` tool. Here is Reason docs for: - OCaml compiler's stdlib: http://kcsrk.info/reason_stdlib_docs/index.html http://kcsrk.info/reason_stdlib_docs/index.html - Batteries: http://kcsrk.info/reason_batteries_docs/index.html http://kcsrk.info/reason_batteries_docs/index.html
- oblio 10y agoHas anyone here built something say, over 10k lines in Ocaml? How is the development experience? IDEs, debuggers, linters, deployment, etc.
- testcross 10y agoThere 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.
- Drup 10y agoWell, we have an excellent linter, it's called "The OCaml type checker". It even has customizable warnings for your coding style. ;)
- joneil 10y agoI know the Haxe compiler is written in Ocaml, and that's a decent size open source project. I believe Facebook uses it for a number of their programming language related tools too. It seems to gave a sweet spot for writing language parsers and compilers.
- nv-vn 10y agoI haven't done anything ≥10k lines yet, but I do have a few projects between 1k and 5k lines that I've been working on and I've easily written 50k+ lines of OCaml in the past year. The development experience I've had is probably the best I've dealt with so far. There isn't a ton of infrastructure around the language, but everything that exists feels very high quality.There's no standard IDE really (although I did recently find OCamlEditor, which seems very nice and even runs on Windows!), but Merlin basically turns any compatible text editor into a full-fledged OCaml IDE (with features like quick-checking code, auto completion, linting, and automatic indentation/formatting). Honestly, debugging isn't something I've had to think of very often. The type system does a really good job of rejecting buggy programs, so whenever I write code it usually works as intended immediately (or I've made a small mistake that I'll notice pretty quickly).
- robohamburger 10y agoI took ocaml for a spin a couple months ago and compared to more recently created languages it seems a bit crufty. If they can simplify the build system to be on par with something like cargo that would be swell. Also: having rust style traits or haskell classes would be amazing. Also macros that aren't obscure and hard to use compiler plugins please :) Hopefully it ends up being more than just questionable sugar around ocaml and actually adds some sorely needed language features.
- wtetzner 10y agoI agree on the build system and macros. As for traits/type classes, there's work being done on implicit modules to fill that role. [1] [1] http://www.lpw25.net/ml2014.pdf http://www.lpw25.net/ml2014.pdf
- nv-vn 10y agoTry out the OASIS build system. It's very similar to Cargo/Cabal (although it's separate from the package manager) in that you basically declare what you're working with and it does all the building for you. It's super simple to use and is good enough for 95% of use cases. As for traits/type classes, this is in development with the modular-implicits (experimental) fork of the compiler. It's highly likely that some form of this will make it into the language soon, but for now you can already start playing around with it if you want. It's super cool because it uses the module system to express type classes/traits rather than adding more parts to the language.
- pathsjs 10y agoI tried it. I found no easy way to have dependencies isolated per project. Any suggestions?
- cwyers 10y agoI really wish they'd taken the pipeline (|>) operator from F#, if they were going to rework OCaml.
- chenglou 10y agoThe pipe operator's still there.
- cwyers 10y agoI've never written OCaml, just SML and F#, but I thought that OCaml didn't have the |> operator.
- cvik 10y agoOCaml, like SML, have the syntax for defining their own operators. |> is defined, to my knowledge, both in the standard prelude and in core.
- gaius 10y agoSince Ocaml 4 if I remember correctly
- LeonidasXIV 10y ago4.01 to be exact. Along with @@, which is kinda comparable to $ in Haskell.
- thedufer 10y agoAs others have noted, the pipeline operator already exists in OCaml. And even if it didn't, you can define it pretty easily: let (|>) x f = f x
- LeonidasXIV 10y agoCan be shortened to let (|>) x f = "%apply" which utilises some language magic and is probably faster.
- honua 10y agoWhat problems would be well solved by Reason/OCaml?
- jordwalke 10y agoFor 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 of Merlin with support for Reason - I cannot overstate how important Merlin is to my daily development. Soon: - Having conventions for forming namespaces within packages. - Making it easier to share and connect many small packages into a a larger application, and develop those packages locally. - Having "just works" support for the REPL, so that it's one fast command to start the REPL with all your dependencies loaded and autocomplete would just work. - Having a "just works" debugger loader that maps all of your source files and compiled artifacts so you can instantly start debugging your app.
- e12e 10y agoInteresting 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 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 <- to = (there are more programming languages, and more programmers now, than ever before, and whatever the merits of using = for comparison, almost all other languages in common use now have it as an assignment operator (even if it is still a source of bugs a la: "if(a=0) ...")). 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).
- yegle 10y agoThis is the new low of search engine unfriendly :-(
- eru 10y agoJust look for "Reason OCaml".
- akhilcacharya 10y agoDo want to learn this - does anybody know any interesting projects that can take advantage of the OCaml ecosystem and functional aspects?
- kcsrk 10y agoHow about building functional operating systems and unikernels: https://mirage.io/ https://mirage.io/. Since Reason is fully compatible with OCaml, you can build your own Reason unikernels on top of MirageOS libraries. Here is a list of mirage OS pioneer projects: https://github.com/mirage/mirage-www/wiki/Pioneer-Projects https://github.com/mirage/mirage-www/wiki/Pioneer-Projects
- chenglou 10y agoI've worked on the Atom plugin for this, itself written in Reason and compiled to JS using js_of_ocaml: https://github.com/facebook/reason/tree/7f3b09a75cacf828dd6be23c89a53a8a85d89912/editorSupport/atom-reason https://github.com/facebook/reason/tree/7f3b09a75cacf828dd6b.... Having worked with Reason, JavaScript, and the bridge between the two, most of my errors seem to fall on the JavaScript side. So I guess the type system's indeed working =).
- carapace 10y agoAnother site that is useless with JS disabled. Nice work.
- devit 10y agoIt 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 using Rust. It would be nice if they explained this in the FAQ. I guess it might be useful if you have an OCaml codebase to interface with but don't already know OCaml, but given the relative obscurity of OCaml that seems a pretty narrow use (and also Facebook isn't known to make extensive use of it, afaik).
- Jare 10y agoThey describe using OCaml significantly, and wanting a migration path to a language with nicer syntax but same power/features.
- TheMagicHorsey 10y agoRust lacks a REPL right? REPL is quite nice for programmer productivity.
- steveklabnik 10y agoThere is rusti, but it is limited.
- deleted 10y ago[deleted]
- ufo 10y agoSome people consider the garbage collector to be a feature :)
- andrewchambers 10y agoBoth garbage collected languages and rust offer memory safety, rust just trades better performance for a more complicated borrow system. Use rust when you need the performance. Use a GC'd language like reason when you want less things to reason about.
- zump 10y agoFacebook just won't let OCaml die.
- nikolay 10y agoNice, but I always wonder why function is abbreviated as the longer unambigous fun and not just fn?!
- jordwalke 10y agoJordan 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!
- nikolay 10y agoNot a good enough reason, sorry! With syntax coloring, it's less irrelevant as well.
- jordwalke 10y agoWhen we start talking about syntax coloring, you know we're just one step closer to actually debating the color of a literal bike-shed! Jokes aside, what would your highlighting do in this case?
- nikolay 10y agoIt would make the function name stand out from the parameters. Again, to pick one unintuitive abbrevation, just because it's a 3-letter one like let, it's just not serious! Make all be 3: type -> typ switch -> swi if -> iff else -> els in -> inn downto -> dow module -> mod Call you language 3-letter reason. You see how it ridiculous it gets? You can't make all keywords be 3-letter and if people care about alignment, they can further align, but most don't care as much as you think!
- 10y ago
- mhd 10y agoI hope this doesn't sound like trolling, but JavaScript's syntax is now a selling point? I kinda-sorta get the reason why people want an actual JavaScript stack on the backend, but I never heard that syntax/semantics brought people from e.g. Rails to Node. Sure, OCaml isn't even the nicest syntax in the ML family, but I'm not sure whether that's worth it, especially considering that almost any "X-like" language often turns out to be an Uncanny Valley for "X" programmers -- close enough to make some frustrating errors.
- jordwalke 10y agoJordan here (I work on Reason) I've mentioned elsewhere that the primary goal for now was to get the tooling automated as much as possible, so that when we receive common feedback, we can adapt to that feedback and trivially migrate people's code forward. I don't think JavaScript's syntax is a selling point and I am someone with a lot of JavaScript experience. I also don't think that OCaml's syntax today is a selling point, and I have a bit of OCaml experience. Both of these syntaxes have evolved over time, working within that limited precious syntactic real estate, trying so very hard to maintain compatibility with decisions made decades ago. Reason's approach is totally different in that it knows we won't get it right on the first shot so it puts into place the tooling for upgrading and beautifying as we learn lessons and take feedback from the community. It places the syntax closer to the user, even if only conceptually. That being said, the current syntax is not intended to be a JavaScript clone by any means. It actually started in the opposite manner - by taking the top 15 complaints about OCaml's syntax, by experienced OCaml programmers (not JS programmers) and fixing them. There were a couple of things that didn't really matter (such as how you express comments) that were just changed to be more familiar because, well.. simply they don't matter, and even experienced OCaml developers want the largest possible set of people to be able to read their code as long as that comes with little other tradeoffs.
- kangar00 10y ago> I don't think JavaScript's syntax is a selling point Under "Why OCaml?" on the Reason page, it states, "OCaml has a very mature (and still growing) ecosystem for targeting browser and JavaScript environments with a focus on language interoperability and integration with existing JavaScript code," and "Reason‘s non-invasive approach to the OCaml compiler allows Reason code to take advantage of all of the existing OCaml compiler optimizations/backends such as ... and even JavaScript compilation." It seems like what's being said is that one of the main goals for Reason is to integrate with JavaScript, and it would seem to make sense instead of changing between language syntaxes, you'd want more in common between them, so it makes sense why they are similar. I'm confused as to why you seem to be trying to distance Reason and OCaml from JavaScript, when it definitely seems like the similarity with and integration with JavaScript would be a driving factor in Reason's development now, even if maybe it wasn't in the beginning. Reason seems really cool, btw.
- fixxer 10y agoWhy rtop?
- thedufer 10y agoIt's just OCaml's repl with the parser replaced. OCaml's repl is called utop. It stands for Universal TOPlevel.
- breatheoften 10y agoIs Facebook using mirage or similar ocaml unikernel tool chain? Is part of the goal of reason to make a more approachable syntax available for authoring code that will run inside next-generation containers?
- nv-vn 10y agoFrom what I can gather, it should work independently from the Mirage toolchain, but will remain compatible with all current OCaml tooling, so using Mirage tools will work as well.
- ubertaco 10y agoAs excited as I was to see a big new thing in OCaml-land, I have to say my excitement died down as I read on. I don't really see most of the changes as improvements. Having a different, explicitly-noticeable syntax for mutable updates is nice, because it calls out mutability (which should be used sparingly). I don't see extra braces as necessarily an improvement, given that OCaml's local scopes are already quite unambiguous thanks to "let ... in". On that note, Removing "in" and just going with semicolons removes another "smelly-code-callout" by making it less obvious what's imperative and what's functional. I actually don't like ambiguity between type annotation and value assignment in my records. It's clear in current OCaml that {a: int} is a type declaration and {a = 1} is a value declaration/assignment. Moving to colons-for-record-values is at best a bikesheddy, backwards-incompatible change for change's sake, and at worst a breaking-change way of code less clear. Speaking of making code less clear, how is "int list list" not clear? It's an int-list list. As in, a list of int-lists. So of course it should parse as "(int list) list". Why change to backwards annotations? Just to prevent existing code from working as-is, and making people used to reading ML spend extra brain cycles on remembering that your types read the opposite way? And they make a huge deal out of their type for tuples being "(a, b)" instead of "(a * b)". Yeah, okay, I get it. It's not that big a deal, since people are used to reading product types as, well, products. The other thing that seems weird to me is the need to change to a "fat arrow" instead of a "skinny arrow", again for no real reason. In fact, it just makes it more likely that you'll confuse it with a comparison operator. Nobody tries to type ">-", but people try to type ">=" all the time. You're just switching for the sake of switching, and it's not an improvement. Their example code of their replacement for match...with is especially egregious. If you showed me the OCaml snippet and the Reason snippet unlabelled, I would think that the OCaml snippet is the new-and-improved version, since it's much more compact, much less noisy, and reads more like what it's trying to do ("match my_variable with either SomeValue x or SomeOtherValue y"). Another thing they make a lot of noise about is requiring fewer parens in some places. But then, they also require more parens in other places. So...okay? I guess? Not really a win. And why rename equality operators? Are you really going to tell me that people prefer that their languages have "==="?
- wtetzner 10y agoYeah, I kinda feel like this whole project is pointless. As many warts as OCaml's syntax has, for the most part I actually like it. It seems like Reason is solving a non-problem. When I first went to the webpage, and saw "Build Systems Rapidly", I thought maybe it was a new build system for OCaml. I was hoping it would be a Cargo-style build system/package manager for OCaml.
- SwellJoe 10y agoSo, I know OCaml is impressively fast. And, I know OCaml is impressively terse ("concise" may be a more positive term). But, I wonder what would make one choose OCaml (or a variant of it like this) over some of the other new or old languages that exhibit some excellent characteristics for modern systems. In particular, a convincing concurrency story seems mandatory. I don't know enough to know if OCaml (or this variant) has a convincing concurrency story, and nothing on the front page of website tells me. So, why do I want to learn this, rather than, say, Go or Elixir?
- rixed 10y agoBecause ocaml type system is state of the art unlike go or elixir. Also, what's a convincing concurrency story? Does multiprogramming count?
- ngrilly 10y agoA convincing concurrency story is the one offered by the two languages you mentioned: Go (with memory sharing, which is an advantage or a drawback depending on your goals), and Elixir (no memory sharing between lightweight processes). A version of OCaml offering a similar "concurrency story" would have a lot of appeal.
- rixed 10y agoThose are just techniques, other techniques achieve the same goal, such as multiprogramming, which I think is better that's why I asked. But if you want POSIX threads and lightweight threads for the sake of it, then there are several lightweight threads libraries for ocaml (LWT being the most common one). POSIX threads you have to do from C though.
- morenoh149 10y agoThe ML family of languages have https://en.m.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system https://en.m.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_... which provide many benefits
- 10y ago
- salamanca 10y agoThe scroll event listener is causing a redraw.
- cm3 10y agoI miss dead code elimination the most, especially when building code that uses Core.
- mseri 10y agoIt's coming with flambda. Am I wrong?
- cm3 10y agoNot that I'm aware of. Edit: flambda has been released in 4.03 and I'm using it but utop is 17MB, so I doubt proper dead code elimination is part of flambda.
- mseri 10y agoSorry, what I meant is that I remember having read somewhere that dead code elimination, or some sort of, will be one of the optimization coming in the future due to the introduction of flambda. When I go back home I will try to find a reference, I might recall wrongly
- cm3 10y agoYou're probably right that it was mentioned on Jane Street's blog that flambda will enable such optimizations. I recall one of the ocamlc devs saying that real dead code elimination is planned but not available yet.
- alex_muscar 10y agoNice to see that OCaml is getting so much love at facebook. Unfortunately, adding a new syntax that's almost OCaml, but not quite, doesn't seem like such a great idea. While it might make the language accessible to more people, it runs the risk of fragmenting the community. I know syntax is subjective, but some of the choices seem a bit odd. For example, declaring variants and using their constructors looks like Haskell, but the semantics is still OCaml. In Haskell, constructors are first order so they can be passed as functions, and partially applied. It makes sense that their declaration and use looks like function declaration and function calls. In OCaml they are not first class, that is, you can't pass the as arguments, or partially apply them. That's why it makes sense for the declaration to look like a tuple, and the use to look like a function applied to a tuple--well, somewhat, you can still argue that it's still confusing because you might expect to be able to apply the constructor to a tuple variable, but well, such is life :). Unless constructors are first class in Reason--it doesn't look like it from a quick scan through the docs--this particular syntactic difference is of dubious value, and, worse, it can be misleading to newcomers. Also, changing `match` to `switch` seems gratuitous as well, and it also loses some of the meaning of the original. i.e. "I want to match this value against this set of patterns". Finally, I know that using `begin` and `end` for blocks is verbose and Pascal-ish--which people seem to hate for some reason--but using { } for scopes looks out of place, and leads to awkward cases like this: try { ... } { | Exn => ... }; I don't mean for this to sound ranty, or like I'm picking on Reason. I think it's good that facebook is tryiog to spice things up in the OCaml community.
- jordwalke 10y ago> In OCaml they are not first class, that is, you can't pass the as arguments, or partially apply them. That's why it makes sense for the declaration to look like a tuple, and the use to look like a function applied to a tuple--well, somewhat, you can still argue that it's still confusing because you might expect to be able to apply the constructor to a tuple variable, but well, such is life If I understand what you're saying, you provided a reason why variant arguments should not look like function application (because they have different semantics than function application), and then in the same paragraph suggested that variant arguments should have tuple syntax, while admitting that they don't actually have tuple semantics either. The truth is that variant arguments in `Reason` actually do not have function application syntax - note the distinguishing, leading capitalized letter on the variant. Sure, they share the fact that arguments are specified via a space separated list, but function application doesn't have a monopoly on the syntactic pattern of things separated by spaces. The argument quickly breaks down.
- haches 10y agoIf you'd like to play with Reason you can do it online here: https://codeboard.io/projects/17520?view=2.1 https://codeboard.io/projects/17520?view=2.1 Of course, you can also create your own Reason projects.
- johnhenry 10y agoWondering how, or even if, this compares to elm? http://elm-lang.org/ http://elm-lang.org/
- mark_l_watson 10y agoReason looks interesting. I have had a 5 year run of alternating between really liking Haskell, and sometime thinking that my own development process was too slow using Haskell. I am putting Reason on my try-it list. Documentation suggestion: add examples for string manipulation.
- xvilka 10y agoIt would be nice if they'll make it work on Windows platforms. There is already an issue for that[1]. It also depends from the Windows support in OCaml itself and opam[2]. [1] https://github.com/facebook/reason/issues/470 https://github.com/facebook/reason/issues/470 [2] https://github.com/ocaml/opam/issues/2191 https://github.com/ocaml/opam/issues/2191
- xvilka 10y agoThere is some work is done for opam https://github.com/dra27/opam/commits/windows https://github.com/dra27/opam/commits/windows
- elcapitan 10y agoIs there an overview in which regard this differs from "classical" Ocaml?