"Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)!"
That's truly amazing.
Interesting how Elm is inspiring other frameworks and languages. First Redux and now Reason's error messages.
I had similar experience with Elm. I didn't have app like Messenger, but it takes a little longer to start, but it is rock solid and refactoring is a breeze.
It also shows how deeply "it compiles and runs without bugs, it's awesome" is ingrained into software developers.
I could write a 100-page essay on all the ways the web-version of messenger fails in subtle and not so-subtle ways, and how it cannot keep the pace of development with the mobile version.
The dev team hasn't received bug reports though. Must be nice.
We (objectively) haven't received (many) bug reports (on the Reason section, on the web, where Reason is). See my comment right above. We do receive a ton on the rest, plus for the server side.
Bug reports are a way to measure how well the behavior is approaching correct. You seem to not be satisfied with messenger.com's experience; valid, it seems. It's a large app with bugs. But your point is obscured by the fact that you seem to be poo-pooing one of the few ways that the development team can get feedback on what users actually experience on a day-to-day basis.
chenglou is doing a bit of massaging of the numbers; the claim that there's "only been 10 bugs" isn't quite true. Their code base is 50% ReasonML and 50% JS, and in the ReasonML portion, they've only had 10 bugs - a signification reduction! But they haven't commented on how many bugs are reported in the JS side; we can probably infer that there is many more (since the implication is that there were many more bugs in the old JS code they replaced).
You seem to be frustrated that the messenger.com experience is not up to par and have latched on to the idea that, since the team says they're seeing improvements since introducing ReasonML, that they think they're perfect now. I guarantee you that's not the case.
It sounds like you have some very valid complaints, though, and as a daily user I bet they'd love to hear your feedback. So maybe fill out a bug report with what you just wrote? :)
Just want to say I'm really excited about Bucklescript and the collaboration with Reason.
I started using the Reason syntax, but soon ended up migrating my project to vanilla OCaml as I found the syntax less JavaScript-like and easier to follow when thinking functionally vs imperatively. Also, there are many more tutorials out there (currently) for OCaml than there are for the Reason syntax.
As I understand it the two syntaxes are pretty much interchangeable, both use the same underlying AST, the same compile-to-JS backend (Bucklescript) and can even be auto-converted using `refmt`.
Also, if it's important to you, only the Reason project seems to still be encumbered by Facebook's patent grant, while the Bucklescript project was originally started by Bloomberg and now seems to be an independent project without the additional patent clause.
Both projects are really exciting as a practical way to bring type safety into the browser, with ridiculously fast compile times and tiny bundles.
Why oh why the brackets? Obfuscates currying too much.
let make ::message ::extraGreeting=? _children => ...
let make = (~message, ~extraGreeting=?, _children) => ...
Plain OCaml:
let make ~message ?extraGreeting _children = ...
Fortunately bucklescript is a completely separate project. After this change I might ditch Reason and just write OCaml. There were some little improvements with Reason vs OCaml but now OCaml appears to be a clear winner!
BuckleScript's author and I collaborate on a daily basis, btw. So you're definitely welcome to use _just_ BuckleScript. I'm not too sure your reaction is genuine happiness for vanilla OCaml, but if it really is, then our mission's accomplished (https://reasonml.github.io/guide/what-and-why#why-reason). If not, sorry about that.
Has someone done a comparision of Reason+Bucklescript with Fable[1] ?
F# has embraced the OCaml syntax while at the same time cleaning out many of the warts (+., do end etc.). It also now has good tooling available on all platforms.
Despite being a full time javascript/typescript developer I find F# syntax much more appealing and easy to grok than Reason's js inspired syntax.
> F# has embraced the OCaml syntax while at the same time cleaning out many of the warts (+., do end etc.). It also now has good tooling available on all platforms.
Unfortunately, it also drops my favorite thing about OCaml, which is the module system.
I also like that there are different operators for ints and floats. It makes it very clear when you've accidentally mixed the two.
It's typed, but the types can be fully inferred. If you didn't specify the types of your function, it could end up being inferred as float -> float -> float instead of int -> int -> int.
The different operators are a concise way to tell the type-checker that you're working with floats.
No it won't be inferred as float->float->float if there is an int literal or whatever base type you pass to the function. Check typeclasses for how this works.
Would it not have been much more pragmatic for FB to have collaborated with MS instead on F# support in dotnet core? That seems more practical given the context that F# can directly benefit from things like concurrency support in dotnet core.
Of course, F# has not always been the favorite lovechild of MS, but the OCaml ecosystem does not seem to be in a particularly stellar state either.
We already use ocaml to write Hack, Flow and Infer, so just from a corporate standpoint, this move to incrementally adopt more of a language that's had many success stories internally makes sense.
From an individual standpoint, there are some unique aspects of OCaml that we like a lot. The properties of BuckleScript for example (tiny output, great js interop, fast simple compilation).
No doubt that the ecosystem could be improved, but that's what we're here for and what we're willing to do.
> Of course, F# has not always been the favorite lovechild of MS, but the OCaml ecosystem does not seem to be in a particularly stellar state either.
I'm not entirely sure what you're referring to, but OCaml has been around and used for real work for much longer than F#. I'm not sure it's so clear cut.
It's good to see languages like these showing up. Would love to code something complicated before I have a detailed opinion. With my experience in Typescript (another typed language claiming to make code better with some heavy React, Angular 4 projects); more than occasionally you have to escape into JS world (the dreaded <any> cast); thing that could have been done simpler with modern ES6 syntax needs some heavy lifting and rope jumping.
Since it's all JS under the hood, the type system is an illusion that language plays tricks on you. This makes it hard for people to understand how JS works or functions; without prior knowledge. Just to quote example one of my team mate had an interface in Typescript, and he was not able to understand why cant he do `x instanceof Foo`. Long story short is you can't have good "Typescript" programmer without being good JS developer. Which I believe will be the case here too. Yes it makes auto-complete better and documents really well; but improves code is debatable.
Don't get me wrong; I am not against it. All I am mentioning is the flip side that nobody will mention. OCaml is really powerful and cool kids are going to experience it with this effort, may be bring in new features/inspiration for next ES. But IMHO just a transpiled language can give you better constructs to express code; but it can't prevent a dumb programmer from making errors. I will for sure give this a shot and blog about it.
Hmm, I'd argue that since any language is effectively compiled to zeroes and ones under the hood, by that logic no type system can protect you. A good type system is there to guide you, and verify that your code is going to be ok even once types are erased.
Transpiled/compiled/whatever you want to call it, the type system can prevent dumb and smart programmers from making a whole class of errors. In my experience OCaml has prevented so many errors I would have made in JavaScript, including but not limited to:
- Non-exhaustive select/case statements - missing one of the possibilities causes undefined behaviour. It might not even be a case of carelessness or forgetting - just that a new option gets added by someone unfamiliar with the codebase and doesn't realize they need to update a bunch of select statements.
- Changing the name of a field on an object across the codebase, and forgetting to update every single instance. OCaml won't even compile until you've fixed them all.
- Null and undefined weirdness. Just search any large JS github repo for "null"/"undefined" and see how many issues are related. With OCaml, you'll almost never see them because you're forced the deal with the possibility before your code will even compile.
I believe that a type checker isn't necessary until you can no longer hold the entire codebase in your head. For me, that means once my program goes over about 150 LOC, I need the compiler to help me out.
The problems you mention aren't related
to transpilation or even JavaScript. They're due to TypeScript being a backwards-compatible superset of JS.
TS is, among other things, JS plus type annotations, but it also relies on the same underlying type system as JS, and TS types, as I understand it, are completely erased at runtime. For example, interfaces don't exist in JS, and classes are prototype-based. So it inherits those flaws, and doesn't patch over them with some kind of runtime, and you end up with a leaky abstraction.
I don't know anything about Reason's JS interaction to say if it's similarly leaky.
Reason is not transpiled language, it’s frontend replacement to ocaml compiler pipeline. Bucklescript, a different project, is backend replacement that emits Javascript instead of binaries. They can be used together, but don’t have to.
It should be possible to implement the instanceof operator for arbitrary types using essentially the same logic as the type checker. (Caveat: I don't know whether any TypeScript-specific properties make this impossible, since I have never used it.)
For each object, there is some function that takes no input and returns that object, by simply constructing the recursion-free parts of the object graph and then filling in any cycles. (TypeScript allows mutation, right?)
Then the question of `x instanceof Foo` becomes "is the function returning x typeable as () -> Foo". Of course that check is going to be much much more expensive than the simple comparison of the class tag other languages use, so I can understand why it's not part of the language.
The type checker has access to the source code (and any type annotations). That information isn't available at runtime, so I'm not sure how you'd be able to run the type checker at runtime.
You don't need the original source code, any code producing the object you want to check will do. If the object has a field "field" with value "value", then the code
function () { return {field: "value"}; }
produces a value of type Foo precisely when the original object was of type Foo, even if the code producing it was much more complex.
I don't see why that wouldn't work. If you have a specific example where that approach fails, I'd like to know about it.
But I don't know where you'd get that source code from at runtime though? I'm sure there are languages that contain enough runtime information, but, as an pertinent example, there isn't a way to tell that you have an object with certain fields in OCaml at runtime. It's just a block at runtime. All of the names are gone, as they were only used at compile time.
I was assuming the TypeScript/JavaScript scenario, where TypeScript objects are implemented as JavaScript objects and their structure is available at runtime. Of course it does not work if you do not have that reflection capability.
Both the blog post and the release notes remark that the change to function definition and application syntax would get a lot of attention, but neither of them even hint at a reason for such a significant change. The PRs implementing the change don't seem to provide a rationale, either. Does anyone have more background as to why this change was made?
Does anyone know why the React/Reason creators switched from SML to OCaml?
Reason's creator also created ReactJS, whose first prototypes were written in SML,
a distant cousin of OCaml. We've transcribed ReactML into ReactJS for wide adoption.[0]
Hi, I’m the original inventor of React and I really like SML, however SML just didn’t have a few of the escape hatches or advanced features that were needed to implement a very usable, extensible, and type safe React interface or implementation, so I eventually explored the OCaml type system and I found that it has many of those missing links. One surprise was that when showing it to fellow UI developers, I would constantly be met with confused looks and after digging into people’s feedback, I found that most developers weren’t seeing the same thing that I was seeing on the screen so they weren’t able to see the ideas expressed in the code. The syntax was very commonly cited as a major point of friction. I don’t see anything wrong with OCaml’s syntax but my opinion alone doesn’t matter because a major goal of software is to collaborate with other people - who matter.
To fix the problem, a couple people from various parts of Facebook got together and started building/testing Reason together, and eventually we shipped what is likely the largest (in terms of machines (billions)) OCaml deployment ever via Reason React.
There’s still many pieces of OCaml beyond syntax that should be improved and we would like to continue fixing all the blockers to adoption that we can. Thankfully the rest of the OCaml community has the same goal and are doing great things at deeper parts of the toolchain and compiler. Our story started from the UI use case so our work and messaging so far has centered around it.
> The syntax was very commonly cited as a major point of friction. I don’t see anything wrong with OCaml’s syntax but my opinion alone doesn’t matter because a major goal of software is to collaborate with other people - who matter.
This is a perspective I wish was more prevalent in the programming community.
Yes! When first saw Reason I was horrified by the syntax (I really like the ML family syntax). But then I though about it, and here's my take now: if syntax is all we're giving up in order for OCaml to reach a far wider audience, then we're still coming out way ahead of what we had before.
I think that's the idea. Look at ELixir for example; they added Ruby syntax and macros onto Erlang and it's bringing tons of folks to the ecosystem. Sometime syou need to meet people where they are, if you want them to join your community.
It is becoming more prevalent when you think about Python PEP 8, gofmt, etc... No more personal preferences, syntax ears etc... One standard and tools to implement it. It makes working on other people code much easier.
I've tried picking up ocaml and reason a couple times, but found the build systems and standard library (and documentation) lacking. I say this in the spirit of constructive feedback. That said, reason's syntax improvements are welcome, and I'm excited to see it maturing!
Noted and thank you for the constructive feedback. Various people in the OCaml community are working on some of these and we might contribute to some of these missing pieces as well.
i'll second these remarks... also i'm on windows so the experience was not very good :( Seems weird that the goal is to make syntax to inspire the masses but then windows support is so pitiful
Can't speak for the creator, but generally speaking OCaml is much more widely adopted than SML (although still tiny market share overall). A few corporate players like Facebook and Jane Street have started adopting OCaml, and subsequently the libraries available for OCaml are far superior to SML. As far as I know, SML only remains in use today in academic circles.
It's hard to imagine that OCaml's libraries/tooling would be the game changers (drop in the bucket by comparison to the vast JS ecosystem). Would be nice if SMLtoJs compiler got the corporate backing though.
OCaml has pretty good and modern tools (opam, meriln, oasis) and basically all the libraries you would expect, compared to SML which has no editor support, a very minimal stdlib, no package manager, no build system, very few and hard to find libraries, etc.
1) It is not compatible with advanced optimizations in Google Closure's compilation process.
2) I've been burned by less than ideal implementations of immutable data structures for functional programming in the past, particularly in Elm. I haven't done enough with Immutable-Re to know if it has similar issues, but all functional data structures are not created the same. I'm spoiled by ClojureScript's implementation which has never thrown a stack overflow error for me, unlike Elm. In Elm, if you have a list that gets too large, you have to manually break it up into different lists and do weird concatenation stuff that is quite clunky because somehow it's not doing structural sharing quite right to ensure these things are transparent under the hood. Experienced Elm users helped explain this to me, and it's not something I like to think about when writing in a functional style.
So I've been a bit hesitant to embrace just any functional programming language for serious enterprise work. But I'm very intrigued by Reason and Bucklescript and am keeping a very close eye on them. I probably won't do more than toy projects in them any time soon, but it would be great to someday.
> In Elm, if you have a list that gets too large, you have to manually break it up into different lists
To clarify, for anyone who comes across this later: there was a bug in the Elm 0.18 compiler that was triggered by enormous list literals. (Hence the workaround of concatenating smaller literals.) Nothing to do with the data structure itself.
After all, it's a singly linked list; there's not a whole lot of variation in how those are implemented. ;)
Is Elm using a particular library for its persistent structures, or are they custom for Elm?
I've read that it has both List and Array, yet neither appears to be ideal for proper functional programming; List, as you say, is a linked list, yet it is recommended [0] over Array for functional operations like map, fold, etc -- but you wouldn't normally want linked lists for that sort of thing, esp. if your maps and folds were part of a larger data transformation of composed functions. Does Elm offer anything similar to the structure of ClojureScript's persistent vector?
I have learned that FP without the guts of serious persistent structures is not so good in practice.
I saw an issue or thread somewhere about the technical problems of supporting Closure Advanced in Bucklescript. I'm surprised they were solved at one point then regressed. What would be the reason for removing it, unless maybe it was easier to implement new features by no longer supporting it?
Closure Advanced has many benefits so it's really nice to support it, especially if you're writing a whole site app of decent size all in one codebase.
IMHO "functional scripters" with a penchant for fewer parens, braces etc and a tendency towards ML-style should seriously embrace PureScript, it's such a terrific project, just gets way too little hype. That's not to rain on ReasonML of course here, which I observed for a while as a very cool transpilation project and kudos to the devs! I'd take a reason project over JS/TS/Ecma any day still
I really like PureScript. The one thing that kept me from deep diving into it was that it lacked efficient immutable data structures, unless I'm mistaken. It basically is immutable by doing full copies with variations, no?
Some truth to this possibly. This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. I mean PS arrays/records map to JS arrays/objects as far as passing/return them, but for those few cases where you really need to mutate inside-a-(no-longer-pure)-func, it's JS-FFI-hackery or (more likely often) a readily-available 3rd-party package offering the persistent or mutable data structure to serve the need at hand. Might not want to write your WebGL 3D game's game loop or a very mathy 2/3/x-dimensional "big array" re-calculation entirely in PS perhaps, sure enough. Depends on what apps you have in mind I guess. Typically in JS what's become more common recently is to map over the structure, extract the small sub-set you actually want to process (reduce/filter) and in the end these copies often turn out small and not so scary. But as always, "it depends". Truly the PureScript/Haskell/Elm family makes mutation harder than all other languages --- with the flip-side that they make immutable purely-functional expression vastly more ergonomic IMHO =)
> This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone.
The JS world has this in Immutable.js, which provides a set of persistent data structures that are excellent by any measure. However, since it's not the default data structures provided by the language, practically no third party library actually consumes/emits them as input/output directly.
What this means in practice is that most of the performance benefits of structural sharing through Immutable.js ends up being outright negated many-times fold by the necessity to recursively convert to and from JS native collections at the edges of your system that inevitably needs to call out to/consume data from third party libraries. Not to mention that the developer ergonomics of working with Immutable.js pales in comparison with that of native JS collections, since you're limited to the traversal and manipulation APIs provided by the library, and have to forgo excellent functional utility libraries like Ramda [1], and handy language features like destructuring and spread.
This is why even in systems that embrace immutability like Redux, the prospect of using Immutable.js comes with a huge list of caveats that are well documented [2], driving most developers to end up choosing JS native collections and doing naive copy-on-write without structural sharing across the board.
I thought that Reason implicitly used Immutable-Re and Bucklescript implicity used Immutable, similar to how Clojurescript implicitly uses its own library from these structures. That is, if you write wholly within the language, you get the benefits of these structures without thinking about it. Is that not true?
GP was talking about PureScript, not Reason. To be honest, I have very little experience with either, but I just wanted to chime in re: the persistent data structures as a library topic with an anecdote from the JS side.
I guess I'm thinking more along the lines of Clojure(Script) which has efficient immutable lists, vectors, and maps. It doesn't do a full copy every time you do a cons or assoc. It seems to me that PureScript would really benefit from having something similar baked in.
It does have efficient maps (purescript-maps) and listss (purescript-lists). Couldn't find any package which provides a Vector type that is not optimised specifically for math operations which always operate on the whole vector (multiply, add, dot product etc).
Ah. Right. My impression was that most PureScript code just uses plain JS objects / arrays, though. Is that not correct? If the ecosystem isn't built around the efficient immutable data types, much of the advantage disappears.
I don't understand why Bower is such a sticking point for people. It works perfectly fine for PureScript and (as the article explains) was the right tool for the job.
Any word of when this will be supported/promoted officially? Just got this response from one of my former JS colleagues: https://twitter.com/keirasaid/status/924169973878046721 - it's pretty hard to convince JS developers to use something that is still recommends using Bower for package management. :/
"Officially" isn't really a thing here, I feel. I mean the `purs` (formerly `psc`) compiler just gets given a list of .purs files from your build setup (pulp, custom make files, a little custom program, whatever) and recompiles what changed to the given output paths. I think they just converged on bower by accident (whatever it professes to offer, the sub-set of features required here for PS apparenty just-worked sufficiently well) but really anyone can manage their packages however they like.
psc-package does* very much look like it's going to be the "sanctioned/endorses/semi-official" tooling for pkg-mgmt one way or the other.
But the syntax adds a layer of obfuscation over the mechanics of currying. I thought we were getting somewhere with Elm, Purescript, and Reason adopting it and making it more widely known, but then we've gone a step backward again. I kind of feel like we need better communication and education rather than just doing a band-aid fix that only helps folks in the short term. :(
Did you consider having a 'beginner mode' Reason, then flipping a switch to compare it to compare it to the non-parened version is?
I'm gonna argue beside the point, but currying has negative semantics and type system impact in a language with uncontrolled side-effects. It also prevents some optimizations and new type features.
I'm jumping into this conversation early on because too often this point is raised and turns into an uncharitable interpretation of our motivations, e.g. "look at these js programmers, not understanding the beauty of currying". Rest assured that we do (and that we're not just js programmers), and that the Merlin and BuckleScript authors know very well what they're doing. Hope this clarifies things a bit.
I'm not talking about you not knowing, I'm more worried about language designers talking down to programmers for short term gains, rather than trying to raise them up with tools that will benefit them in the long term.
Interesting about argument syntax + effects. I've mainly used currying in pure languages. Is it about accidentally calling an effectful function multiple times? Is the idea here that you are conservatively treating everything as effectful with the uncurried syntax (before algebraic effects land), then will make pure stuff curried in order to attract people to use pure functions where possible?
There's a distinction between syntax and semantics though. E.g. Go pushes bad semantics (null values, bad error handling, no generics) in the name of beginner ease, with no transition path to better semantics. Reason pushes 'bad' (JavaScript) syntax but good OCaml semantics in the name of attracting JavaScript devs, with a clear transition path to OCaml syntax should they want to.
Good points. Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term.
I still can't get my head around why it would be an optimization problem too, seeing as it would be most using the same underlying AST. Unless they actually translate the pseudo-parameter lists into actual tuples in the parser, forbidding raw, single argument passing. :/
Yes, as far as I know Reason is the first project to try to have auto-currying semantics with tupled syntax. It's definitely a bit of an experiment.
Not sure what optimisation problem you're referring to, Reason and OCaml underlying AST are exactly the same. There are no actual tuples unless the programmer is creating actual tuples.
I think what @chenglou was referring to are issues like the "value restriction" [1] and the need to wrap "uncurried" FFI functions with a function that "adapts" it to curried form, thereby adding a layer of indirection.
Reason does not solve these, they're problems inherent to the underlying language and the choices made. I think the point being made was just that currying isn't a clear step forward, but causes some problems as well.
Yeah, definitely agree that there are trade-offs with currying when mapping it to a compilation target like JS, and I am consistently impressed by Bucklescipt's ability to convert the curried versions of functions to regular JS calls. That said, I do still think that it's worth the trouble!
> Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term
Unless you introspect the output (which is actually viable to do in a compiler with clean output, such as BuckleScript), you wouldn't know that your higher-order function accidentally became pretty much 4+ calls instead of one. Now imagine quadrupling every high-order function calls or so. BucklesScript (and native OCaml) do a crazy good job of avoiding this when possible, more so than most, as shown in the snippet's first scenario; the manual even shows guaranteed uncurry if you put the right annotation. But if you want to take advantage of _that_ (and please do), there are other tradeoffs as well, but I digress. In general, the compiled code's speed is as good as you can get for JS output.
The perf point alone is not a pedantic argument as you can see. And you might start wondering about other languages' output for currying. Regarding your other comment: yes, from a typing perspective, currying indeed works out wonderfully for pure languages like Elm and PureScript. But OCaml's not a pure language; we've made other tradeoffs; and context matters.
Not sure about your comment about the AST, but I think you're saying that the situation doesn't get better/worse in the new syntax: this is true, since the syntax revamp is really just that: a syntax change. Which is why I said earlier that I was arguing beside the point. But currying seems to attract so much unbalanced attention in this context that I felt I should address it so that it doesn't overwhelm the rest of the syntax change's purpose. Looking at the rest of the threads, it still did, but I'm glad your reaction has been doubt rather than unreasoned negativity, so thanks for that.
Color me confused as well. I had used C like languages for a long time before trying out OCaml and Clojure. Surprisingly for neither of those I found the lack of parentheses a cause of annoyance. </bikeshedding>
I think that might be the first time I've ever seen "Clojure" and "lack of parenthesis" in the same sentence. Presumably you meant C-style parens. :D
I agree though. Honestly, getting worked up over such fluff as where parens go, which whitespace to use, what line curly braces go on is a minor annoyance of mine. The human brain is capable of parsing some pretty obscure stuff (see: human language) just fine.
Just gets so visually noisy when reading code though. Maybe depends subjectively on how a given individual tries to re-conceptualize high-level ideas from low-level instructions. I actually have my Sublime/VScode color schemes set up so that all "punctuation" is as grey / half-invisible as the comments and indent-guide --- really helps me scan curly code-bases whether Go, JS or all the others =)
It's funny to see people talking about how noisy parentheses/braces are when a regular ReasonML program before adopting a more Javascript-y syntax looked like a combination of random punctuation.
> looked like a combination of random punctuation. Same goes for a lot of Haskell code
"A lot", not "all": yeah indeed at least you can tweak the punctuation towards more ergonomic (aka more productive) aesthetics. What you describe is just the unfortunate result of many-perhaps-most (early) Haskellers / the std-lib authors being married to established-but-ugly academic operator symbols instead of boldly redesigning them for green-field programmers of this (then, newly from-scratch) programming language.
Once swapping out the built-in `.` for <. and `>>>` for .> and $ for <| and & for |> it all comes a breeze to read (I mean, in comparison), about on par with Elm/F#. Now I've never heard anyone complain that Elm code is unreadable, it's a good example for other MLs to follow.
The rest of what you describe is just due to these hackers being heavily into their own combinator libraries, truly if you code all day, just as there shouldn't be a need to elaborately spell out "function" and "return" and so forth all the time in imperative, they feel less need to spell out all the map/filter/reduce English words all the time. At some point, all the names describe "symbolic relations of sorts" and I wouldn't fault anyone for philosophizing: "that which is specific to my program should be named as words, but that which is 'primitive' / generalized / commonly used among all sorts of programs could just as well be just symbols" ;)
I mean I hack in Go all days right now and it's fun --- lots of parens & braces don't exactly kill me. Here, tweaking one's colour scheme easily solves this in one fell swoop and takes just under a minute tops. No need to go "ML-ish FP" just for the lack of curlies. =)
I must admit that if my compiler reported errors like this it would start to grate pretty quickly. Besides, isn't a bug exclusively something that breaks at runtime?
As a new user, it is way more useful. As an old user, you skip right past it.
Every Python exception tells you
> Traceback (most recent call last):
Which is a similar boilerplate statement. Except less useful to newcomers.
And if you doubt the need for newcomers to understand that stack traces and compiler errors are useful, then take a look at new user questions on StackOverflow - it's incredible how many of them flat out don't include that information. This kind of thing makes it way more likely the user recognises this is something useful, and better than that - makes it way more likely they can apply that information and solve their own problem.
> Besides, isn't a bug exclusively something that breaks at runtime?
I mean, it would be a bug if the type checker hadn't caught it. The runtime distinction seems completely arbitrary when we are talking about tools take take runtime errors and make them impossible.
Technically "we've found a bug" ought to be "we couldn't prove there's no bug of this sort" and it can be grating, in the same way Clippy helpfully popping up was grating, to have the latter announced as the former.
You would think so, but personally when I picked up Elm it was extremely handy, and then faded into the background. I expected it to be annoying as an experienced dev, but I actually appreciated it initially and then it wasn’t annoying or even on my radar: my brain skipped right over it.
Once you’re more experienced with the language, you’re typically using your editor to handle the error checking, so the extra “noise” is ignored in the parsing of it.
This fixes the exact problems I would often have with ReasonML . On top of that my coworker hcarty made some nontrivial contributions to it, so I'm super excited. I am a dyed in the wool C style programmer, but after exposure to reasonml, I felt (as odd as it seems) able to read regular OCaml syntax easier. As someone else mentioned, it becomes a matter of what you see in your mind more than what's on the screen. I read OCaml library docs and have no trouble putting them into reason code.
Thanks for your work folks, ReasonML is just getting started.
They're available to vanilla OCaml as well (given the constraints listed in the post). Add `"bsc-flags": ["-bs-super-errors"]` in your `bsconfig.json` to turn it on. If you use BuckleScript, that is.
We'll try to make it into a proper compiler plugin, but it's not trivial right now
I haven’t looked into it, but since Reason essentially is OCaml and you can convert between them easily, are these improvements not automatically brought to OCaml?
These 'nice errors' are available on a forked version of the OCaml compiler. The hope is to merge them back into mainline OCaml, but it will be an uphill battle, I think, to convince the OCaml maintainers to merge them, because they're very conservative about changes (which can be good) and may not appreciate the value of friendly error messages (which is not so good).
I can assure you that the OCaml maintainers do appreciate the value of friendly error messages, despite your drive-by comments about our ethos.
However, unfinished patches cannot be merged into our mainline tree, and this PR https://github.com/ocaml/ocaml/pull/102 needs some attention to rebase it to trunk, and also to get feedback from testers who may have tried the opam switch and have comments.
(associated writeup https://arxiv.org/abs/1512.01897)
Help welcome on this particular patch, and other newer ones from Reason that can be ported over to OCaml and submitted as normal feature improvements.
Sorry avsm. I looked at the patch you linked to and indeed the OCaml developers are all quite enthusiastic about improved error messages. My mistake. The only real blocker is what we both mentioned I believe, that we all want to go slow to make sure the best possible work is merged in.
By the way, the above patch is different from the one that ReasonML uses. Realistically, the work done by the Reason team is more recent and actually shipped with the BuckleScript platform, so now the blocker is, which direction does the OCaml compiler want to go in.
As an aside: How on earth have you managed to create a website where clicking a simple <a> in the menu doesn't work without cookies/localStorage enabled?
Are there any recommended reason apps on GitHub that one recommends going through? I'm interested how a medium/large app in reason is structured. Thanks!
Can anyone speak to Windows support yet? Last I looked their was work being done to get better OCaml support on Windows which seemed like the big hurdle that was required. I know there are some workarounds using Windows 10 and Bash but I'm waiting for something I can easily get my whole team to use.
it's still pretty pitiful, i'd say definitely not ready for your team.. I was exploring it for my teams at work, but like you i can't make the linuxsubsystem for windows a requirement. Merlin is something we'd need and I seem to be having most difficulty with that as well
Subjectively, I think PureScript is the better language (in terms of aesthetics and expressiveness) also it has overloads so (25) and (2.3 3.3) instead of OCaml's odd (2.3 *. 3.3).
Reason has a much faster compiler, efficient immutable operations, and is built using tried-and-true tech (OCaml).
I also really like PureScript, but the output from PureScript seems to be a lot larger than OCaml/BuckleScript and have worse performance. OCaml/BuckleScript has a really small stdlib that is lacking common functions, does not support type classes or point free style. A lot of groups end up making their own stdlib. BuckleScript is probably the more practical option at the moment.
Is there no source map support? Also: I have to set up requirejs myself to make Reason code work in the browser?
Not only that, it doesnt seem like the whole "each file is a module" system is actually codified in the output. I see no require calls that would indicate the right loading order for my generated .js files.
Generated code has weird comments in it like /* Facebook / and / Instagram */
I dont know what to tell you, I'm using the simplest possible project here. It just doesnt seem to pick up anything other than the entry.re file. I initially only had the non-webpack default compilation set up, which does compile all .re files but has the problem that the modules dont get loaded / no idea which order should be loaded.
So naturally I set up webpack but now it only watches the entry.re file for some reason.
And saying that the output js corresponds 1-1 with reason is really not true at all, especially when compiled into one big module with webpack.
I think it only watches one of your files because the other one isn't actually referenced by any code in the pathway of your entry point. If you reference some code from your other file, it will be picked up as well.
Yes, I forgot about bundling, sorry, but if you are in debug mode you're not minifying the bundle JS anyway so whatever you're looking at should still look a fair bit like the input Reason, especially because the names are only minimally mangled.
the bs-loader is definitely broken somehow, it only picks up the entry .re file and not any of the other files, I even tried the example from the bs-loader (which is still reason 2 btw)
Any update on algebraic effects for single-threaded structured concurrency? In vanilla JS we can implement structured concurrency using generators as primitives. How do we implement structured concurrency in Reason?
Since Reason compiles to native Ocaml binaries I'm assuming there would be no problems using it with MirageOS? Google doesn't bring up any answers other than an older HN comment[1] suggesting support will come soon.
Because Reason is just a syntax layer over the OCaml syntax, you should write an MirageOS unikernel with Reason. However, because MirageOS needs lot of works, lot of people of this community don't have a plan to switch to Reason - but feel free :) !
After, it's about a convenience easy way to compile your Reason code with an OCaml code. Reason is just a preprocessing, you should use the `-pp` option with /your favorite build system in OCaml/ and, I think, it's enough.
I won't be switching to Reason, it's a small greenfield project :) The security model of Mirage will really suit this small app and Reason has piqued my interest for being a little more productive with dev tools and stuff. Also being able to build a frontend in the same language is appealing.
Thanks for the answer; the other comment alluding to support being recent and the lack of information had me a bit worried. I guess the lack of information is because it just works ;)
Does this bring any interesting new language features which would help with distributed programming (like e.g. Erlang) or is this just another variation of syntax and infrastructure?
So they've changed yet another piece of core, defining OCaml syntax (the lack of C-parens everywhere) for the worse, obfuscating currying in the process. But that's just my opinion, I guess. I don't have to use it.
I do find it ironic that in their announcement, they don't even try to defend the decision, but instead say, effectively, "if you don't like this change, you're just bikeshedding", and "if you don't care about syntax, great!" Given that the entire purpose of Reason is one giant bikeshed about OCaml syntax, this reads as hypocritical.
They also say, effectively, "no complaining in public allowed, just PM us (so we don't have to have a real conversation and we can ignore you)", so you know they're great at working with their community.
If the main goal of Reason is to get a OCaml that is easy to use for JS devs, they nailed it.
I'm a JavaScript developer and I think the new version is easier to grasp.
Also, the Reason peeps are really nice and some of them are on a team of a FB product and not on the "Reason team", which gives them more insight of the day-to-day JavaScript problems, so I don't think they just do their thing and don't want any complains.
As far as I know Reason compiles to OCaml and back again, so there is probably no big barrier in using stuff written in Reason with OCaml, if you like that language more.
I even read about a few devs who started with Reason and switched to OCaml later.
FWIW I did PM @jordwalke and got a very satisfying answer: this change has dramatically increased the number of JS devs that want to use Reason when they see it. It’s not that they are just guessing, they’ve actually tested this within Facebook and found a huge difference in adoption.
This is uncharitable and needlessly mean-spirited.
If you disagree with this change, you can say that without ascribing bad intentions to open source maintainers whose contributions you apparently don't want to use anyway.
That’s a very unfair assumption. In my (admittedly short) time on the ReasonML Discord I’ve found chenglou and other members of the Reason team to be incredibly helpful and involved with the community.
I'd let it slip because it will probably move a massive amount of devs into the static reasoning mindset. You lose a bit in the process but the gain is still worth it.
Kudos for acknowledging that you don't have to use this project, but the rest of your post reads like a tantrum. Notably, public complaining wasn't forbidden, as you claim, they insinuated that they wouldn't engage public complaints. Further, you seem to fail to understand that the goal of Reason is to make OCaml more familiar to mainstream developers, not to existing OCAML developers. Unless you wanted to communicate a deep emotional attachment to OCaml's syntax, this post could be improved by simply saying what you dislike about Reason's direction and leaving it at that.
What are we supposed to be competing for? Reason is a tool that makes different trade-offs than some other tools. These trade-offs might work for you or they might not. It all depends on what YOU actually need.
Reason the music software has always been a fine argument in favor of skeuomorphic design. We did an industry-wide "ewww" away from that kind of design but when it comes back with a vengeance it will be because of software like Reason.
The problem is that skeuomorphic design can become obsolete pretty fast. The virtual version replace the real object, and the aspect of said object is forgotten, rendering copying it useless.
That was my thinking exactly, and the reason I clicked on the link. Even the initial landing page the link took me to didn't clearly explain what it was I was looking at.
Perhaps a small tagline in addition to the one (or two) word article heading to indicate what the article is talking about may assist in future...
"Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)!"
That's truly amazing.
Interesting how Elm is inspiring other frameworks and languages. First Redux and now Reason's error messages.
Was the bug reporting tool also ported to Reason? Because it could itself be faulty... /s
Sounds like an amazing accomplishment for the Messenger team.
I had similar experience with Elm. I didn't have app like Messenger, but it takes a little longer to start, but it is rock solid and refactoring is a breeze.
I'm not saying that Reason doesn't deserve some of the credit, but surely some of this must be attributable to relative maturity of Messenger. Right?
(Hey Brandon!)
The JS part of messenger.com bugs a lot more.
Elm was a big inspiration for Rust's error messages as well.
Sounds like the combination of the product being mature already and the introduction of static typing that makes maintenance much more safer.
It also shows how deeply "it compiles and runs without bugs, it's awesome" is ingrained into software developers.
I could write a 100-page essay on all the ways the web-version of messenger fails in subtle and not so-subtle ways, and how it cannot keep the pace of development with the mobile version.
The dev team hasn't received bug reports though. Must be nice.
We (objectively) haven't received (many) bug reports (on the Reason section, on the web, where Reason is). See my comment right above. We do receive a ton on the rest, plus for the server side.
See, you don’t even understand what I’m saying.
The fact that your code doesn’t break in production doesn’t mean it’s behavior is correct.
- messenger.com is a subpar experience compared to mobile
- there are multiple behavior issues:
— it fails to reconnect when connection is lost
— it randomly fails to unfurl urls which display correctly on mobile
- it may unfurl a url in one chat and not unfurl the same url in another chat
- it may lose connection and not even notify about it (mobile chat updates, web chat doesn’t, reloading helps)
- try searching. good luck discovering where “load previous” is hidden
- it may get stuck in a scroll position displaying an old message at the bottom of the chat
Shall I continue? I use messenger.com exclusively throughout the day. Your pride in “not receiving bug reports” for the Reason code doesn’t amuse me.
Bug reports are a way to measure how well the behavior is approaching correct. You seem to not be satisfied with messenger.com's experience; valid, it seems. It's a large app with bugs. But your point is obscured by the fact that you seem to be poo-pooing one of the few ways that the development team can get feedback on what users actually experience on a day-to-day basis.
chenglou is doing a bit of massaging of the numbers; the claim that there's "only been 10 bugs" isn't quite true. Their code base is 50% ReasonML and 50% JS, and in the ReasonML portion, they've only had 10 bugs - a signification reduction! But they haven't commented on how many bugs are reported in the JS side; we can probably infer that there is many more (since the implication is that there were many more bugs in the old JS code they replaced).
You seem to be frustrated that the messenger.com experience is not up to par and have latched on to the idea that, since the team says they're seeing improvements since introducing ReasonML, that they think they're perfect now. I guarantee you that's not the case.
It sounds like you have some very valid complaints, though, and as a daily user I bet they'd love to hear your feedback. So maybe fill out a bug report with what you just wrote? :)
Just want to say I'm really excited about Bucklescript and the collaboration with Reason.
I started using the Reason syntax, but soon ended up migrating my project to vanilla OCaml as I found the syntax less JavaScript-like and easier to follow when thinking functionally vs imperatively. Also, there are many more tutorials out there (currently) for OCaml than there are for the Reason syntax.
As I understand it the two syntaxes are pretty much interchangeable, both use the same underlying AST, the same compile-to-JS backend (Bucklescript) and can even be auto-converted using `refmt`.
Also, if it's important to you, only the Reason project seems to still be encumbered by Facebook's patent grant, while the Bucklescript project was originally started by Bloomberg and now seems to be an independent project without the additional patent clause.
Both projects are really exciting as a practical way to bring type safety into the browser, with ridiculously fast compile times and tiny bundles.
For learning Reason, I found this page invaluable: https://reasonml.github.io/try
You can put in Reason or OCaml and it will spit out the other. I used it to work through Real World OCaml in Reason.
Why oh why the brackets? Obfuscates currying too much.
Plain OCaml: Fortunately bucklescript is a completely separate project. After this change I might ditch Reason and just write OCaml. There were some little improvements with Reason vs OCaml but now OCaml appears to be a clear winner!I've given an answer to currying at https://news.ycombinator.com/item?id=15573956
BuckleScript's author and I collaborate on a daily basis, btw. So you're definitely welcome to use _just_ BuckleScript. I'm not too sure your reaction is genuine happiness for vanilla OCaml, but if it really is, then our mission's accomplished (https://reasonml.github.io/guide/what-and-why#why-reason). If not, sorry about that.
Has someone done a comparision of Reason+Bucklescript with Fable[1] ?
F# has embraced the OCaml syntax while at the same time cleaning out many of the warts (+., do end etc.). It also now has good tooling available on all platforms.
Despite being a full time javascript/typescript developer I find F# syntax much more appealing and easy to grok than Reason's js inspired syntax.
[1] http://fable.io
> F# has embraced the OCaml syntax while at the same time cleaning out many of the warts (+., do end etc.). It also now has good tooling available on all platforms.
Unfortunately, it also drops my favorite thing about OCaml, which is the module system.
I also like that there are different operators for ints and floats. It makes it very clear when you've accidentally mixed the two.
You can't accidentally mix floats and ints, it's a typed language.
It's typed, but the types can be fully inferred. If you didn't specify the types of your function, it could end up being inferred as float -> float -> float instead of int -> int -> int.
The different operators are a concise way to tell the type-checker that you're working with floats.
No it won't be inferred as float->float->float if there is an int literal or whatever base type you pass to the function. Check typeclasses for how this works.
Completely agree. I much prefer the ML syntax to ALGOL-like syntax.
Nice thing is, Reason converts lossless to OCaml, so all the ML fans can profit from the money FB pouring into the ecosystem.
Would it not have been much more pragmatic for FB to have collaborated with MS instead on F# support in dotnet core? That seems more practical given the context that F# can directly benefit from things like concurrency support in dotnet core.
Of course, F# has not always been the favorite lovechild of MS, but the OCaml ecosystem does not seem to be in a particularly stellar state either.
We already use ocaml to write Hack, Flow and Infer, so just from a corporate standpoint, this move to incrementally adopt more of a language that's had many success stories internally makes sense.
From an individual standpoint, there are some unique aspects of OCaml that we like a lot. The properties of BuckleScript for example (tiny output, great js interop, fast simple compilation).
No doubt that the ecosystem could be improved, but that's what we're here for and what we're willing to do.
"the OCaml ecosystem does not seem to be in a particularly stellar state"
Maybe that's a good thing for Facebook?
> Of course, F# has not always been the favorite lovechild of MS, but the OCaml ecosystem does not seem to be in a particularly stellar state either.
I'm not entirely sure what you're referring to, but OCaml has been around and used for real work for much longer than F#. I'm not sure it's so clear cut.
It's good to see languages like these showing up. Would love to code something complicated before I have a detailed opinion. With my experience in Typescript (another typed language claiming to make code better with some heavy React, Angular 4 projects); more than occasionally you have to escape into JS world (the dreaded <any> cast); thing that could have been done simpler with modern ES6 syntax needs some heavy lifting and rope jumping.
Since it's all JS under the hood, the type system is an illusion that language plays tricks on you. This makes it hard for people to understand how JS works or functions; without prior knowledge. Just to quote example one of my team mate had an interface in Typescript, and he was not able to understand why cant he do `x instanceof Foo`. Long story short is you can't have good "Typescript" programmer without being good JS developer. Which I believe will be the case here too. Yes it makes auto-complete better and documents really well; but improves code is debatable.
Don't get me wrong; I am not against it. All I am mentioning is the flip side that nobody will mention. OCaml is really powerful and cool kids are going to experience it with this effort, may be bring in new features/inspiration for next ES. But IMHO just a transpiled language can give you better constructs to express code; but it can't prevent a dumb programmer from making errors. I will for sure give this a shot and blog about it.
Hmm, I'd argue that since any language is effectively compiled to zeroes and ones under the hood, by that logic no type system can protect you. A good type system is there to guide you, and verify that your code is going to be ok even once types are erased.
Transpiled/compiled/whatever you want to call it, the type system can prevent dumb and smart programmers from making a whole class of errors. In my experience OCaml has prevented so many errors I would have made in JavaScript, including but not limited to:
- Non-exhaustive select/case statements - missing one of the possibilities causes undefined behaviour. It might not even be a case of carelessness or forgetting - just that a new option gets added by someone unfamiliar with the codebase and doesn't realize they need to update a bunch of select statements.
- Changing the name of a field on an object across the codebase, and forgetting to update every single instance. OCaml won't even compile until you've fixed them all.
- Null and undefined weirdness. Just search any large JS github repo for "null"/"undefined" and see how many issues are related. With OCaml, you'll almost never see them because you're forced the deal with the possibility before your code will even compile.
I believe that a type checker isn't necessary until you can no longer hold the entire codebase in your head. For me, that means once my program goes over about 150 LOC, I need the compiler to help me out.
The problems you mention aren't related to transpilation or even JavaScript. They're due to TypeScript being a backwards-compatible superset of JS.
TS is, among other things, JS plus type annotations, but it also relies on the same underlying type system as JS, and TS types, as I understand it, are completely erased at runtime. For example, interfaces don't exist in JS, and classes are prototype-based. So it inherits those flaws, and doesn't patch over them with some kind of runtime, and you end up with a leaky abstraction.
I don't know anything about Reason's JS interaction to say if it's similarly leaky.
Reason is not transpiled language, it’s frontend replacement to ocaml compiler pipeline. Bucklescript, a different project, is backend replacement that emits Javascript instead of binaries. They can be used together, but don’t have to.
It should be possible to implement the instanceof operator for arbitrary types using essentially the same logic as the type checker. (Caveat: I don't know whether any TypeScript-specific properties make this impossible, since I have never used it.)
For each object, there is some function that takes no input and returns that object, by simply constructing the recursion-free parts of the object graph and then filling in any cycles. (TypeScript allows mutation, right?)
Then the question of `x instanceof Foo` becomes "is the function returning x typeable as () -> Foo". Of course that check is going to be much much more expensive than the simple comparison of the class tag other languages use, so I can understand why it's not part of the language.
The type checker has access to the source code (and any type annotations). That information isn't available at runtime, so I'm not sure how you'd be able to run the type checker at runtime.
You don't need the original source code, any code producing the object you want to check will do. If the object has a field "field" with value "value", then the code
produces a value of type Foo precisely when the original object was of type Foo, even if the code producing it was much more complex.I don't see why that wouldn't work. If you have a specific example where that approach fails, I'd like to know about it.
But I don't know where you'd get that source code from at runtime though? I'm sure there are languages that contain enough runtime information, but, as an pertinent example, there isn't a way to tell that you have an object with certain fields in OCaml at runtime. It's just a block at runtime. All of the names are gone, as they were only used at compile time.
I was assuming the TypeScript/JavaScript scenario, where TypeScript objects are implemented as JavaScript objects and their structure is available at runtime. Of course it does not work if you do not have that reflection capability.
You can provide your own type guards: https://www.typescriptlang.org/docs/handbook/advanced-types....
Doing this in the general case, I assume, is probably not practical.
Both the blog post and the release notes remark that the change to function definition and application syntax would get a lot of attention, but neither of them even hint at a reason for such a significant change. The PRs implementing the change don't seem to provide a rationale, either. Does anyone have more background as to why this change was made?
https://www.reddit.com/r/reasonml/comments/6v2olv/new_syntax...
https://github.com/facebook/reason/pull/1299#issuecomment-32...
Tldr?
I believe the syntax is still a work in progress, but the long term goal seems to be replacing JavaScript/winning over JS devs with a familiar syntax.
Apparently devs don't understand what a type constructor is.
And the Reddit is some kind of cult of personality with a dude in a hat.
> Apparently devs don't understand what a type constructor is.
No, they don't. No, they don't care.
To make it look more like JavaScript.
OCaml looks rather foreign to the regular JS dev and the last versions of Reason looked more like JS, but still had a few strange parts.
Does anyone know why the React/Reason creators switched from SML to OCaml?
[0] https://reasonml.github.io/guide/what-and-why/Hi, I’m the original inventor of React and I really like SML, however SML just didn’t have a few of the escape hatches or advanced features that were needed to implement a very usable, extensible, and type safe React interface or implementation, so I eventually explored the OCaml type system and I found that it has many of those missing links. One surprise was that when showing it to fellow UI developers, I would constantly be met with confused looks and after digging into people’s feedback, I found that most developers weren’t seeing the same thing that I was seeing on the screen so they weren’t able to see the ideas expressed in the code. The syntax was very commonly cited as a major point of friction. I don’t see anything wrong with OCaml’s syntax but my opinion alone doesn’t matter because a major goal of software is to collaborate with other people - who matter.
To fix the problem, a couple people from various parts of Facebook got together and started building/testing Reason together, and eventually we shipped what is likely the largest (in terms of machines (billions)) OCaml deployment ever via Reason React.
There’s still many pieces of OCaml beyond syntax that should be improved and we would like to continue fixing all the blockers to adoption that we can. Thankfully the rest of the OCaml community has the same goal and are doing great things at deeper parts of the toolchain and compiler. Our story started from the UI use case so our work and messaging so far has centered around it.
> The syntax was very commonly cited as a major point of friction. I don’t see anything wrong with OCaml’s syntax but my opinion alone doesn’t matter because a major goal of software is to collaborate with other people - who matter.
This is a perspective I wish was more prevalent in the programming community.
Yes! When first saw Reason I was horrified by the syntax (I really like the ML family syntax). But then I though about it, and here's my take now: if syntax is all we're giving up in order for OCaml to reach a far wider audience, then we're still coming out way ahead of what we had before.
I think that's the idea. Look at ELixir for example; they added Ruby syntax and macros onto Erlang and it's bringing tons of folks to the ecosystem. Sometime syou need to meet people where they are, if you want them to join your community.
It is becoming more prevalent when you think about Python PEP 8, gofmt, etc... No more personal preferences, syntax ears etc... One standard and tools to implement it. It makes working on other people code much easier.
I've tried picking up ocaml and reason a couple times, but found the build systems and standard library (and documentation) lacking. I say this in the spirit of constructive feedback. That said, reason's syntax improvements are welcome, and I'm excited to see it maturing!
Noted and thank you for the constructive feedback. Various people in the OCaml community are working on some of these and we might contribute to some of these missing pieces as well.
i'll second these remarks... also i'm on windows so the experience was not very good :( Seems weird that the goal is to make syntax to inspire the masses but then windows support is so pitiful
Can't speak for the creator, but generally speaking OCaml is much more widely adopted than SML (although still tiny market share overall). A few corporate players like Facebook and Jane Street have started adopting OCaml, and subsequently the libraries available for OCaml are far superior to SML. As far as I know, SML only remains in use today in academic circles.
It's hard to imagine that OCaml's libraries/tooling would be the game changers (drop in the bucket by comparison to the vast JS ecosystem). Would be nice if SMLtoJs compiler got the corporate backing though.
OCaml has pretty good and modern tools (opam, meriln, oasis) and basically all the libraries you would expect, compared to SML which has no editor support, a very minimal stdlib, no package manager, no build system, very few and hard to find libraries, etc.
The two issues I have with Reason for me are:
1) It is not compatible with advanced optimizations in Google Closure's compilation process.
2) I've been burned by less than ideal implementations of immutable data structures for functional programming in the past, particularly in Elm. I haven't done enough with Immutable-Re to know if it has similar issues, but all functional data structures are not created the same. I'm spoiled by ClojureScript's implementation which has never thrown a stack overflow error for me, unlike Elm. In Elm, if you have a list that gets too large, you have to manually break it up into different lists and do weird concatenation stuff that is quite clunky because somehow it's not doing structural sharing quite right to ensure these things are transparent under the hood. Experienced Elm users helped explain this to me, and it's not something I like to think about when writing in a functional style.
So I've been a bit hesitant to embrace just any functional programming language for serious enterprise work. But I'm very intrigued by Reason and Bucklescript and am keeping a very close eye on them. I probably won't do more than toy projects in them any time soon, but it would be great to someday.
> In Elm, if you have a list that gets too large, you have to manually break it up into different lists
To clarify, for anyone who comes across this later: there was a bug in the Elm 0.18 compiler that was triggered by enormous list literals. (Hence the workaround of concatenating smaller literals.) Nothing to do with the data structure itself.
After all, it's a singly linked list; there's not a whole lot of variation in how those are implemented. ;)
Is Elm using a particular library for its persistent structures, or are they custom for Elm?
I've read that it has both List and Array, yet neither appears to be ideal for proper functional programming; List, as you say, is a linked list, yet it is recommended [0] over Array for functional operations like map, fold, etc -- but you wouldn't normally want linked lists for that sort of thing, esp. if your maps and folds were part of a larger data transformation of composed functions. Does Elm offer anything similar to the structure of ClojureScript's persistent vector?
I have learned that FP without the guts of serious persistent structures is not so good in practice.
[0] https://stackoverflow.com/questions/37707577/array-vs-list-i...
Bucklescript used to support closure output but we removed it because nobody was using it. We can get it back if enough people want it.
I saw an issue or thread somewhere about the technical problems of supporting Closure Advanced in Bucklescript. I'm surprised they were solved at one point then regressed. What would be the reason for removing it, unless maybe it was easier to implement new features by no longer supporting it?
Closure Advanced has many benefits so it's really nice to support it, especially if you're writing a whole site app of decent size all in one codebase.
Are the new parentheses optional? I love modern JS syntax but the Reason syntax sans parentheses was really growing on me.
Also I’m still hoping for an async/await équivalent. I’d love to use Reason for Node API stuff but the JS interop with promises isn’t very pretty...
IMHO "functional scripters" with a penchant for fewer parens, braces etc and a tendency towards ML-style should seriously embrace PureScript, it's such a terrific project, just gets way too little hype. That's not to rain on ReasonML of course here, which I observed for a while as a very cool transpilation project and kudos to the devs! I'd take a reason project over JS/TS/Ecma any day still
I really like PureScript. The one thing that kept me from deep diving into it was that it lacked efficient immutable data structures, unless I'm mistaken. It basically is immutable by doing full copies with variations, no?
That seems like a pretty big downside.
Some truth to this possibly. This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. I mean PS arrays/records map to JS arrays/objects as far as passing/return them, but for those few cases where you really need to mutate inside-a-(no-longer-pure)-func, it's JS-FFI-hackery or (more likely often) a readily-available 3rd-party package offering the persistent or mutable data structure to serve the need at hand. Might not want to write your WebGL 3D game's game loop or a very mathy 2/3/x-dimensional "big array" re-calculation entirely in PS perhaps, sure enough. Depends on what apps you have in mind I guess. Typically in JS what's become more common recently is to map over the structure, extract the small sub-set you actually want to process (reduce/filter) and in the end these copies often turn out small and not so scary. But as always, "it depends". Truly the PureScript/Haskell/Elm family makes mutation harder than all other languages --- with the flip-side that they make immutable purely-functional expression vastly more ergonomic IMHO =)
> This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone.
The JS world has this in Immutable.js, which provides a set of persistent data structures that are excellent by any measure. However, since it's not the default data structures provided by the language, practically no third party library actually consumes/emits them as input/output directly.
What this means in practice is that most of the performance benefits of structural sharing through Immutable.js ends up being outright negated many-times fold by the necessity to recursively convert to and from JS native collections at the edges of your system that inevitably needs to call out to/consume data from third party libraries. Not to mention that the developer ergonomics of working with Immutable.js pales in comparison with that of native JS collections, since you're limited to the traversal and manipulation APIs provided by the library, and have to forgo excellent functional utility libraries like Ramda [1], and handy language features like destructuring and spread.
This is why even in systems that embrace immutability like Redux, the prospect of using Immutable.js comes with a huge list of caveats that are well documented [2], driving most developers to end up choosing JS native collections and doing naive copy-on-write without structural sharing across the board.
[1] http://ramdajs.com/
[2] http://redux.js.org/docs/recipes/UsingImmutableJS.html
In contrast, in the ClojureScript ecosystem, everything uses the default persistent collections, and so this is never a problem.
I thought that Reason implicitly used Immutable-Re and Bucklescript implicity used Immutable, similar to how Clojurescript implicitly uses its own library from these structures. That is, if you write wholly within the language, you get the benefits of these structures without thinking about it. Is that not true?
GP was talking about PureScript, not Reason. To be honest, I have very little experience with either, but I just wanted to chime in re: the persistent data structures as a library topic with an anecdote from the JS side.
I guess I'm thinking more along the lines of Clojure(Script) which has efficient immutable lists, vectors, and maps. It doesn't do a full copy every time you do a cons or assoc. It seems to me that PureScript would really benefit from having something similar baked in.
It does have efficient maps (purescript-maps) and listss (purescript-lists). Couldn't find any package which provides a Vector type that is not optimised specifically for math operations which always operate on the whole vector (multiply, add, dot product etc).
Ah. Right. My impression was that most PureScript code just uses plain JS objects / arrays, though. Is that not correct? If the ecosystem isn't built around the efficient immutable data types, much of the advantage disappears.
When is Purescript going to get rid of the need for Bower? That's a pretty significant turn-off for most folks :(
As others have mentioned, psc-package can be used so there is no "need" for Bower.
"Why the PureScript community uses Bower" explains why Bower was chosen: http://harry.garrood.me/blog/purescript-why-bower/
I don't understand why Bower is such a sticking point for people. It works perfectly fine for PureScript and (as the article explains) was the right tool for the job.
You can use psc-package instead of Bower.
Oh, this is great: https://github.com/purescript/psc-package
Any word of when this will be supported/promoted officially? Just got this response from one of my former JS colleagues: https://twitter.com/keirasaid/status/924169973878046721 - it's pretty hard to convince JS developers to use something that is still recommends using Bower for package management. :/
"Officially" isn't really a thing here, I feel. I mean the `purs` (formerly `psc`) compiler just gets given a list of .purs files from your build setup (pulp, custom make files, a little custom program, whatever) and recompiles what changed to the given output paths. I think they just converged on bower by accident (whatever it professes to offer, the sub-set of features required here for PS apparenty just-worked sufficiently well) but really anyone can manage their packages however they like.
psc-package does* very much look like it's going to be the "sanctioned/endorses/semi-official" tooling for pkg-mgmt one way or the other.
This popped up just now in my feed reader: https://qiita.com/kimagure/items/0d9354900d7a7dbd3864
I simply don't understand why people like C style syntax so much.
I made this release, and I also don't understand, and I do mean this _very honestly_. Aside from familiarity that is.
But the thing to realize is that this syntax change isn't for folks and you and me. We'll be fine with either.
But the syntax adds a layer of obfuscation over the mechanics of currying. I thought we were getting somewhere with Elm, Purescript, and Reason adopting it and making it more widely known, but then we've gone a step backward again. I kind of feel like we need better communication and education rather than just doing a band-aid fix that only helps folks in the short term. :(
Did you consider having a 'beginner mode' Reason, then flipping a switch to compare it to compare it to the non-parened version is?
I'm gonna argue beside the point, but currying has negative semantics and type system impact in a language with uncontrolled side-effects. It also prevents some optimizations and new type features.
Don't take my words for it: https://github.com/facebook/reason/pull/1299#issuecomment-30... https://realworldocaml.org/v1/en/html/imperative-programming... https://drup.github.io/2016/08/02/difflists/ https://bucklescript.github.io/bucklescript/Manual.html#_cal...
I'm jumping into this conversation early on because too often this point is raised and turns into an uncharitable interpretation of our motivations, e.g. "look at these js programmers, not understanding the beauty of currying". Rest assured that we do (and that we're not just js programmers), and that the Merlin and BuckleScript authors know very well what they're doing. Hope this clarifies things a bit.
I'm not talking about you not knowing, I'm more worried about language designers talking down to programmers for short term gains, rather than trying to raise them up with tools that will benefit them in the long term.
Interesting about argument syntax + effects. I've mainly used currying in pure languages. Is it about accidentally calling an effectful function multiple times? Is the idea here that you are conservatively treating everything as effectful with the uncurried syntax (before algebraic effects land), then will make pure stuff curried in order to attract people to use pure functions where possible?
There's a distinction between syntax and semantics though. E.g. Go pushes bad semantics (null values, bad error handling, no generics) in the name of beginner ease, with no transition path to better semantics. Reason pushes 'bad' (JavaScript) syntax but good OCaml semantics in the name of attracting JavaScript devs, with a clear transition path to OCaml syntax should they want to.
Good points. Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term.
I still can't get my head around why it would be an optimization problem too, seeing as it would be most using the same underlying AST. Unless they actually translate the pseudo-parameter lists into actual tuples in the parser, forbidding raw, single argument passing. :/
Yes, as far as I know Reason is the first project to try to have auto-currying semantics with tupled syntax. It's definitely a bit of an experiment.
Not sure what optimisation problem you're referring to, Reason and OCaml underlying AST are exactly the same. There are no actual tuples unless the programmer is creating actual tuples.
I was referring to chenglou's comment[1] where he said "It also prevents some optimizations and new type features."
[1]: https://news.ycombinator.com/item?id=15573956
I think what @chenglou was referring to are issues like the "value restriction" [1] and the need to wrap "uncurried" FFI functions with a function that "adapts" it to curried form, thereby adding a layer of indirection.
Reason does not solve these, they're problems inherent to the underlying language and the choices made. I think the point being made was just that currying isn't a clear step forward, but causes some problems as well.
[1]: http://mlton.org/ValueRestriction
Yeah, definitely agree that there are trade-offs with currying when mapping it to a compilation target like JS, and I am consistently impressed by Bucklescipt's ability to convert the curried versions of functions to regular JS calls. That said, I do still think that it's worth the trouble!
> Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term
_This_, I do think, is a fair argument. It's indeed an accidental drawback of the syntax revamp. Though there are very realistic way to prevent the confusion: https://github.com/reasonml-community/error-message-improvem...
Regarding optimization: see the BuckleScript link on explicit uncurrying. The impact is very visible: the compiler analysis for specializing for uncurrying best-effort, and when it bails, it looks like this: https://reasonml.github.io/try/?reason=PQKgBA5g9lAmYGMCGBnAp... which calls https://github.com/BuckleScript/bucklescript/blob/2a66960b5a.... How many function calls did your curried call just turn into, in the second case?
Unless you introspect the output (which is actually viable to do in a compiler with clean output, such as BuckleScript), you wouldn't know that your higher-order function accidentally became pretty much 4+ calls instead of one. Now imagine quadrupling every high-order function calls or so. BucklesScript (and native OCaml) do a crazy good job of avoiding this when possible, more so than most, as shown in the snippet's first scenario; the manual even shows guaranteed uncurry if you put the right annotation. But if you want to take advantage of _that_ (and please do), there are other tradeoffs as well, but I digress. In general, the compiled code's speed is as good as you can get for JS output.
The perf point alone is not a pedantic argument as you can see. And you might start wondering about other languages' output for currying. Regarding your other comment: yes, from a typing perspective, currying indeed works out wonderfully for pure languages like Elm and PureScript. But OCaml's not a pure language; we've made other tradeoffs; and context matters.
Not sure about your comment about the AST, but I think you're saying that the situation doesn't get better/worse in the new syntax: this is true, since the syntax revamp is really just that: a syntax change. Which is why I said earlier that I was arguing beside the point. But currying seems to attract so much unbalanced attention in this context that I felt I should address it so that it doesn't overwhelm the rest of the syntax change's purpose. Looking at the rest of the threads, it still did, but I'm glad your reaction has been doubt rather than unreasoned negativity, so thanks for that.
> currying has negative semantics and type system impact in a language with uncontrolled side-effects.
Can you explain this? Currying and side-effects seem orthogonal to me.
Color me confused as well. I had used C like languages for a long time before trying out OCaml and Clojure. Surprisingly for neither of those I found the lack of parentheses a cause of annoyance. </bikeshedding>
I think that might be the first time I've ever seen "Clojure" and "lack of parenthesis" in the same sentence. Presumably you meant C-style parens. :D
I agree though. Honestly, getting worked up over such fluff as where parens go, which whitespace to use, what line curly braces go on is a minor annoyance of mine. The human brain is capable of parsing some pretty obscure stuff (see: human language) just fine.
Just gets so visually noisy when reading code though. Maybe depends subjectively on how a given individual tries to re-conceptualize high-level ideas from low-level instructions. I actually have my Sublime/VScode color schemes set up so that all "punctuation" is as grey / half-invisible as the comments and indent-guide --- really helps me scan curly code-bases whether Go, JS or all the others =)
It's funny to see people talking about how noisy parentheses/braces are when a regular ReasonML program before adopting a more Javascript-y syntax looked like a combination of random punctuation.
Same goes for a lot of Haskell code.
> looked like a combination of random punctuation. Same goes for a lot of Haskell code
"A lot", not "all": yeah indeed at least you can tweak the punctuation towards more ergonomic (aka more productive) aesthetics. What you describe is just the unfortunate result of many-perhaps-most (early) Haskellers / the std-lib authors being married to established-but-ugly academic operator symbols instead of boldly redesigning them for green-field programmers of this (then, newly from-scratch) programming language.
Once swapping out the built-in `.` for <. and `>>>` for .> and $ for <| and & for |> it all comes a breeze to read (I mean, in comparison), about on par with Elm/F#. Now I've never heard anyone complain that Elm code is unreadable, it's a good example for other MLs to follow.
The rest of what you describe is just due to these hackers being heavily into their own combinator libraries, truly if you code all day, just as there shouldn't be a need to elaborately spell out "function" and "return" and so forth all the time in imperative, they feel less need to spell out all the map/filter/reduce English words all the time. At some point, all the names describe "symbolic relations of sorts" and I wouldn't fault anyone for philosophizing: "that which is specific to my program should be named as words, but that which is 'primitive' / generalized / commonly used among all sorts of programs could just as well be just symbols" ;)
I mean I hack in Go all days right now and it's fun --- lots of parens & braces don't exactly kill me. Here, tweaking one's colour scheme easily solves this in one fell swoop and takes just under a minute tops. No need to go "ML-ish FP" just for the lack of curlies. =)
It's basically a struggle between "too much syntax" and "not enough syntax" :)
Lisps genuinely have fewer brackets than C-like languages. They're just more consistently in the same places.
Because if there aren't enough symbols the language looks too much like Visual Basic
> We've found a bug for you
I must admit that if my compiler reported errors like this it would start to grate pretty quickly. Besides, isn't a bug exclusively something that breaks at runtime?
E: s/big/bug/
As a new user, it is way more useful. As an old user, you skip right past it.
Every Python exception tells you
> Traceback (most recent call last):
Which is a similar boilerplate statement. Except less useful to newcomers.
And if you doubt the need for newcomers to understand that stack traces and compiler errors are useful, then take a look at new user questions on StackOverflow - it's incredible how many of them flat out don't include that information. This kind of thing makes it way more likely the user recognises this is something useful, and better than that - makes it way more likely they can apply that information and solve their own problem.
> Besides, isn't a bug exclusively something that breaks at runtime?
I mean, it would be a bug if the type checker hadn't caught it. The runtime distinction seems completely arbitrary when we are talking about tools take take runtime errors and make them impossible.
Technically "we've found a bug" ought to be "we couldn't prove there's no bug of this sort" and it can be grating, in the same way Clippy helpfully popping up was grating, to have the latter announced as the former.
Programming languages shouldn't be designed around what is best for complete newbies. They should be designed around experienced users.
Why design around a stage you're in for 15 minutes instead of the stage you're in for 15 years?
You would think so, but personally when I picked up Elm it was extremely handy, and then faded into the background. I expected it to be annoying as an experienced dev, but I actually appreciated it initially and then it wasn’t annoying or even on my radar: my brain skipped right over it.
Once you’re more experienced with the language, you’re typically using your editor to handle the error checking, so the extra “noise” is ignored in the parsing of it.
Nope, it wouldn't. People get used to useless stacktraces and incomprehnsible warnings filling the screen with rubbish, and dismiss them out of hand.
Elm's and Reason's approach let even the experienced dev get to the root of the problem immediately.
I haven't tried Reason but Merlin (whom the creator also built) looks really nice: https://github.com/ocaml/merlin
Yeah, merlin is very useful.
This fixes the exact problems I would often have with ReasonML . On top of that my coworker hcarty made some nontrivial contributions to it, so I'm super excited. I am a dyed in the wool C style programmer, but after exposure to reasonml, I felt (as odd as it seems) able to read regular OCaml syntax easier. As someone else mentioned, it becomes a matter of what you see in your mind more than what's on the screen. I read OCaml library docs and have no trouble putting them into reason code.
Thanks for your work folks, ReasonML is just getting started.
As an OCaml developer... I'm feeling just a _little_ jealous of those Reason error messages. Beautiful!
They're available to vanilla OCaml as well (given the constraints listed in the post). Add `"bsc-flags": ["-bs-super-errors"]` in your `bsconfig.json` to turn it on. If you use BuckleScript, that is.
We'll try to make it into a proper compiler plugin, but it's not trivial right now
Is JSX from ReasonReact usable directly in OCaml/BuckleScript?
Unfortunately not. It's an inseparable part of the Reason syntax. You can however use either the desugared form:
Or a preprocessor that'll give you a JSX-like syntax, but without the type checking: https://github.com/cxa/ppx_bsxI haven’t looked into it, but since Reason essentially is OCaml and you can convert between them easily, are these improvements not automatically brought to OCaml?
These 'nice errors' are available on a forked version of the OCaml compiler. The hope is to merge them back into mainline OCaml, but it will be an uphill battle, I think, to convince the OCaml maintainers to merge them, because they're very conservative about changes (which can be good) and may not appreciate the value of friendly error messages (which is not so good).
I can assure you that the OCaml maintainers do appreciate the value of friendly error messages, despite your drive-by comments about our ethos.
However, unfinished patches cannot be merged into our mainline tree, and this PR https://github.com/ocaml/ocaml/pull/102 needs some attention to rebase it to trunk, and also to get feedback from testers who may have tried the opam switch and have comments. (associated writeup https://arxiv.org/abs/1512.01897)
Help welcome on this particular patch, and other newer ones from Reason that can be ported over to OCaml and submitted as normal feature improvements.
Sorry avsm. I looked at the patch you linked to and indeed the OCaml developers are all quite enthusiastic about improved error messages. My mistake. The only real blocker is what we both mentioned I believe, that we all want to go slow to make sure the best possible work is merged in.
By the way, the above patch is different from the one that ReasonML uses. Realistically, the work done by the Reason team is more recent and actually shipped with the BuckleScript platform, so now the blocker is, which direction does the OCaml compiler want to go in.
I was actually gonna talk to Anil, but that got delayed. Let's pick up that discussion again.
"...simpler cousin of JavaScript, minus the historical crufts, plus the features of ES2030 you can use today"
Thats funny.
I love the new function syntax with parentheses! Much easier for us lowly Javascript developers to read at a glance!
The only thing I like about it is the fact that it removes the need for the `fun` keyword. Otherwise it just adds noise in my opinion.
The removal of `fun` (And unification of @@@) is directly tied to the parens change; otherwise there'd be parsing conflicts
As an aside: How on earth have you managed to create a website where clicking a simple <a> in the menu doesn't work without cookies/localStorage enabled?
It works fine without JavaScript. Why would you expect websites to work normally if you take random part of JavaScript out?
I didn't mention javascript. Why should I need to enable cookies/localStorage to navigate?
Are there any recommended reason apps on GitHub that one recommends going through? I'm interested how a medium/large app in reason is structured. Thanks!
Quick question from a newb: whats the reason for using Reason? (Ignore the pun)
Rationale here: https://reasonml.github.io/guide/what-and-why
Can anyone speak to Windows support yet? Last I looked their was work being done to get better OCaml support on Windows which seemed like the big hurdle that was required. I know there are some workarounds using Windows 10 and Bash but I'm waiting for something I can easily get my whole team to use.
Here's a big centralized thread for it: https://github.com/reasonml/reasonml.github.io/issues/195
In short, every part works, but the workflow is a bit contorted atm
it's still pretty pitiful, i'd say definitely not ready for your team.. I was exploring it for my teams at work, but like you i can't make the linuxsubsystem for windows a requirement. Merlin is something we'd need and I seem to be having most difficulty with that as well
I would love to see a comparison of the pros/cons of Reason vs Purescript by someone familiar with both.
Subjectively, I think PureScript is the better language (in terms of aesthetics and expressiveness) also it has overloads so (25) and (2.3 3.3) instead of OCaml's odd (2.3 *. 3.3).
Reason has a much faster compiler, efficient immutable operations, and is built using tried-and-true tech (OCaml).
I also really like PureScript, but the output from PureScript seems to be a lot larger than OCaml/BuckleScript and have worse performance. OCaml/BuckleScript has a really small stdlib that is lacking common functions, does not support type classes or point free style. A lot of groups end up making their own stdlib. BuckleScript is probably the more practical option at the moment.
There's an unofficial in-progress comparison here: https://github.com/glennsl/reasonml.github.io/blob/124268155...
Installation is broken with bs-platform, do this to fix it (assuming node is installed in /home/pc/node)
rm /home/pc/node/lib/node_modules/bs-platform/bin/refmt.exe
ln -s /home/pc/node/bin/refmt /home/pc/node/lib/node_modules/bs-platform/bin/refmt.exe
Is there no source map support? Also: I have to set up requirejs myself to make Reason code work in the browser? Not only that, it doesnt seem like the whole "each file is a module" system is actually codified in the output. I see no require calls that would indicate the right loading order for my generated .js files.
Generated code has weird comments in it like /* Facebook / and / Instagram */
There is no source map support because the output JS should correspond almost 1-1 with the input Reason.
Can you give an example of 'I see no require calls'? Require or import calls should be generated correctly.
I dont know what to tell you, I'm using the simplest possible project here. It just doesnt seem to pick up anything other than the entry.re file. I initially only had the non-webpack default compilation set up, which does compile all .re files but has the problem that the modules dont get loaded / no idea which order should be loaded. So naturally I set up webpack but now it only watches the entry.re file for some reason. And saying that the output js corresponds 1-1 with reason is really not true at all, especially when compiled into one big module with webpack.
https://i.imgur.com/hrxmjWl.png
I think it only watches one of your files because the other one isn't actually referenced by any code in the pathway of your entry point. If you reference some code from your other file, it will be picked up as well.
Yes, I forgot about bundling, sorry, but if you are in debug mode you're not minifying the bundle JS anyway so whatever you're looking at should still look a fair bit like the input Reason, especially because the names are only minimally mangled.
the bs-loader is definitely broken somehow, it only picks up the entry .re file and not any of the other files, I even tried the example from the bs-loader (which is still reason 2 btw)
Any update on algebraic effects for single-threaded structured concurrency? In vanilla JS we can implement structured concurrency using generators as primitives. How do we implement structured concurrency in Reason?
I'm guessing it's blocked on OCaml. I'm excited about modular implicits, but it's the same story there...
To be clear, Reason is just a lexer for OCaml. Any actual language features would happen in OCaml.
Currently: lexer, and parser, and AST printer (bidirectional parser you could say), with a few lightweight ppx macros included for UI development.
Since Reason compiles to native Ocaml binaries I'm assuming there would be no problems using it with MirageOS? Google doesn't bring up any answers other than an older HN comment[1] suggesting support will come soon.
https://news.ycombinator.com/item?id=11717213
Because Reason is just a syntax layer over the OCaml syntax, you should write an MirageOS unikernel with Reason. However, because MirageOS needs lot of works, lot of people of this community don't have a plan to switch to Reason - but feel free :) !
After, it's about a convenience easy way to compile your Reason code with an OCaml code. Reason is just a preprocessing, you should use the `-pp` option with /your favorite build system in OCaml/ and, I think, it's enough.
I won't be switching to Reason, it's a small greenfield project :) The security model of Mirage will really suit this small app and Reason has piqued my interest for being a little more productive with dev tools and stuff. Also being able to build a frontend in the same language is appealing.
Thanks for the answer; the other comment alluding to support being recent and the lack of information had me a bit worried. I guess the lack of information is because it just works ;)
But Reason is already version 9?
(I know there's going to be some overlap between project naming, but Reason is a fairly well-known product...)
From some googling, I'm guessing jonathonf means https://www.propellerheads.se/en/reason a commercial music and audio editing package.
Not https://www.reasonco.com/ that appears to sell hardware.
or other 'reason' initiatives.
That was my assumption from the title haha. Reason releasing old source code or something.
I only know of ReasonML, what Reason are you referring to?
It comes down to domain knowledge. I am a musician, and whenever anyone mentions 'Reason', I instantly think of the DAW software by that name.
I have been a programmer for as long as I have been a musician, but strangely, never heard of ReasonML until now!
ReasonML is fairly new but I believe Facebook has big plans for it, so we’re likely going to hear a lot more about it in the coming months.
Does this bring any interesting new language features which would help with distributed programming (like e.g. Erlang) or is this just another variation of syntax and infrastructure?
The latter.
So they've changed yet another piece of core, defining OCaml syntax (the lack of C-parens everywhere) for the worse, obfuscating currying in the process. But that's just my opinion, I guess. I don't have to use it.
I do find it ironic that in their announcement, they don't even try to defend the decision, but instead say, effectively, "if you don't like this change, you're just bikeshedding", and "if you don't care about syntax, great!" Given that the entire purpose of Reason is one giant bikeshed about OCaml syntax, this reads as hypocritical.
They also say, effectively, "no complaining in public allowed, just PM us (so we don't have to have a real conversation and we can ignore you)", so you know they're great at working with their community.
I don't know.
If the main goal of Reason is to get a OCaml that is easy to use for JS devs, they nailed it.
I'm a JavaScript developer and I think the new version is easier to grasp.
Also, the Reason peeps are really nice and some of them are on a team of a FB product and not on the "Reason team", which gives them more insight of the day-to-day JavaScript problems, so I don't think they just do their thing and don't want any complains.
As far as I know Reason compiles to OCaml and back again, so there is probably no big barrier in using stuff written in Reason with OCaml, if you like that language more.
I even read about a few devs who started with Reason and switched to OCaml later.
FWIW I did PM @jordwalke and got a very satisfying answer: this change has dramatically increased the number of JS devs that want to use Reason when they see it. It’s not that they are just guessing, they’ve actually tested this within Facebook and found a huge difference in adoption.
This is uncharitable and needlessly mean-spirited.
If you disagree with this change, you can say that without ascribing bad intentions to open source maintainers whose contributions you apparently don't want to use anyway.
That’s a very unfair assumption. In my (admittedly short) time on the ReasonML Discord I’ve found chenglou and other members of the Reason team to be incredibly helpful and involved with the community.
I'd let it slip because it will probably move a massive amount of devs into the static reasoning mindset. You lose a bit in the process but the gain is still worth it.
I don't know. One may be forced to write this silly dialect instead of real OCaml in a couple of years "because Facebook".
I've given an answer to currying at https://news.ycombinator.com/item?id=15573956
Kudos for acknowledging that you don't have to use this project, but the rest of your post reads like a tantrum. Notably, public complaining wasn't forbidden, as you claim, they insinuated that they wouldn't engage public complaints. Further, you seem to fail to understand that the goal of Reason is to make OCaml more familiar to mainstream developers, not to existing OCAML developers. Unless you wanted to communicate a deep emotional attachment to OCaml's syntax, this post could be improved by simply saying what you dislike about Reason's direction and leaving it at that.
I don't read it as a tantrum. It is an accurate description of the attitude that prevails in SOME Silicon Valley corporations:
1) Take an existing valuable codebase and add some personal touch.
2) Promote the heck out of it.
3) Slowly, people associate all the goodness with said company and the "new" codebase.
4) Tell critics to take a hike.
What are reasons competitors?
What are we supposed to be competing for? Reason is a tool that makes different trade-offs than some other tools. These trade-offs might work for you or they might not. It all depends on what YOU actually need.
Probably Purescript, Elm, Buckle Script(sort of),and GHCJS.
Reason, for me, will always be the digital audio workstation by Propellerhead Software[1]. It was a masterpiece of user experience design.
[1]: https://en.m.wikipedia.org/wiki/Reason_(software)
Last stable version of Reason by Propellerheads came out two days ago. It's not dead!
Yeah. I kinda wish ReasonML would encourage the use of the ML appendage for this, uh, Reason.
Reason the music software has always been a fine argument in favor of skeuomorphic design. We did an industry-wide "ewww" away from that kind of design but when it comes back with a vengeance it will be because of software like Reason.
The problem is that skeuomorphic design can become obsolete pretty fast. The virtual version replace the real object, and the aspect of said object is forgotten, rendering copying it useless.
> It was a masterpiece of user experience design
No need to use the past tense. Reason 10 just came out 2 days ago and added some awesome new synths!
Trust the hubris of Facebook engineers for wanton name collision.
We do fine with names being overloaded in English. I'm sure the world will cope with ReasonML and this other Reason.
It's still pretty awesome.
And here I thought you were referring to Reason, the music production suite :/
Same, it really should be referenced as ReasonML. Reason is a major piece of software that's been around for a very long time.
Also it gets difficult to google things very quickly while trying to get up to speed.
That was my thinking exactly, and the reason I clicked on the link. Even the initial landing page the link took me to didn't clearly explain what it was I was looking at.
Perhaps a small tagline in addition to the one (or two) word article heading to indicate what the article is talking about may assist in future...
Yep. I spent way too much time trying to figure out what Reason was. Their GitHub ReadMe's don't help.
This syntax is horrible. All the elegant lambda calculus associations are gone.
Yes, the original OCaml syntax looks quirky during the first two weeks. But it makes sense after that.