Messenger.com Now 50% Converted to Reason
reasonml.github.io
reasonml.github.io
I wish they go one step further and say, if you sue or threaten to sue anyone (not just FB) over patents, then the grant terminates automatically.
It's better not to use software to force people to change their behavior. It's open source software. That means something. Or used to, at least. We've come from the ideals of the GPL down to defensive/active countermeasures of corporation vs corporation conflict.
Which is fine, I get it. There's nothing wrong with it. I'm just lamenting that Software Matters Now. At this point it's less about having an open culture of sharing and more "We own this."
GPL forces people to respect the wishes of whatever software they depend on, they're free to not use it.
Still, folks more knowledgeable than me on this topic say it's not a big deal: https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...
So yes, any use of a software patent offensively is malicious.
If you are a criminal and want to use software patents to attack innocents, I couldn't care less if Facebook throws some lawyers to hunt you.
No you don't. You lose the right to use any patents Facebook might (or much more likely, doesn't) have on React.
What patent? Patents are a matter of public record; tell me what patent you think I'd be violating.
1) Anyone could apply for a patent on anything. IBM could apply for a patent on some core tech used in your own 100% home rolled web stack. I mean, I have no reason to think they will, but if we're just pulling stuff out of the air that might happen, that seems just as likely.
2) ...actually, more likely. Because a patent application must be filed within 1 year of public disclosure or its barred, and React has been out for years. So...
> Facebook might apply for a React-related patent in the future
No, that would be illegal.
> No, that would be illegal.
How come? So there couldn't be a new version of React with some patented technology? See i.e. [1].
1 - https://www.google.com/patents/US20170221242?dq=facebook+use...
They can deny you the right to use their patents...if any exist.
Without a patent grant you’re in the same situation.
You’d still be covered by the (less powerful) implicit grant in the license anyhow as the license doesn’t get revoked.
You can’t have it both ways: both with and without the grant can’t be bad.
An explicit grant gives you much more power generally. Their ability to revoke is limited to specific situations and that's a reasonable tradeoff. It's still more rights than you have without the patent grant.
Basically this whole topic is FUD (the Apache situation most people don’t actually under and just repeat incorrect information around).
Let’s say you remove the patents license, as most people here seem to want, what do you have?
The exact same situation as if you sued FB over patents and they revoked it that so many ppl are complaining about.
The license without the grant has an implicit grant anyhow. This is less strong than what they added: an explicit grant.
The hullabaloo over this is just silly.
What I said was, if you sue Facebook for infringing on your patents then, by my reading, you lose the React software license. I didn't say that you lose the license if React contains patented works.
I saw the whole Linux v SCO thing so I hate FUD as much as the next guy, but I am literally going by the words in that document. I'm not adding or embellishing. Maybe my interpretation is wrong--I'm not a lawyer--but this is what I see when I read it.
> Let’s say you remove the patents license ... if you sued FB over patents and they revoked it that so many ppl are complaining about.
As I explained, my reading is that if Facebook removes the patent grant and you were to sue them, they could not revoke the React software license, which is what I believe they can do now.
Again, I know my reading may be wrong. But I am going by the exact wording of the patent grant.
Your reading is wrong: https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...
I urge you to reread the Patent Grant: no-where does it even come close to saying that.
Remember that copyright and patent law are separate things. If there are no actual patents, then Facebook's BSD + Patents grant just becomes a normal BSD license.
IMHO, Typescript exists and is of similar quality, far higher community mindshare, and moving from TS ->ES6 is much more easier (in an emergency).
If you write in Reason, the ultimate risk is if you think you will ever be acquired by Google, Microsoft, etc
I also find it interesting that Microsoft is still maintaining React-related projects, despite the license issues.
Now, people will still use React - because its javascript and at the end of the day, you can rewrite your web stack faster.
Imagine if you have a React Native app already distributed, a Caffe2 ai pipeline in production... or if your logic is in Bucklescript. Much harder to move away if your acquiring company is in a dispute.
...if Facebook has any patents. Which, in this case, it seems very likely they do not.
Incorrect. Your license to their patents gets revoked. Hence why the React license "issue" is basically a paper tiger. (See, eg, https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...)
That's not my reading. From the patent grant:
> Facebook ... grants to each recipient of the Software ... license under any Necessary Claims, to make, have made, use, sell, offer to sell, import, and otherwise transfer the Software.
This doesn't say that they're granting you a license to their patents, just their software. In fact, about patents they go beyond to say:
> ... no license is granted under Facebook’s rights in any patent claims that are infringed by (i) modifications to the Software made by you or any third party or (ii) the Software in combination with any software or other technology.
IMO that's pretty clearly saying you don't actually have any license to their patents. Regarding the termination clause:
> The license granted hereunder will terminate....
It seems pretty clear the only license granted hereunder is the one to use the software; in other words if you sue FB for patent infringement you lose the right to use React/Reason.
> Does termination of the additional patent grant in the Facebook BSD+Patents license cause the copyright license to also terminate?
> No.
People lie. It happens. Facebook is not exactly the most noble company in the world.
Literally every lawyer who has looked at that license agrees that your interpretation is wrong.
Also, licenses like this have standard language; if you're even slightly familiar with how such language is interpreted, you'd realise that this represents two independent licenses to two different things, which terminate in different cases.
Also, Facebook has publically explained what the language means to them, and yes, that would be legally binding on them.
Plus:
> IMO that's pretty clearly saying you don't actually have any license to their patents.
Right, a document titled "additional grant of patent rights" that "grants to each recipient of the Software [...] a perpetual, worldwide, royalty-free, non-exclusive, irrevocable (subject to the termination provision below) license under any [claim of a patent owned by Facebook that is necessarily infringed by the Software standing alone], isn't a grant of patent rights?
I'm sorry, but literally everything you've said is wrong. I highly suggest you read the analysis of an actual lawyer, such as the one I linked in the comment you're replying to, because you appear to have no clue what you're talking about.
And it shows, because it has become quite unresponsive versus the previous Java/Objective-C/C++ version.
Now I always postpone my Skype conversations to a PC near me.
People were compiling OCaml to Javascript long before it was fashionable. js_of_ocaml is 7 years old and the project that comes from is older still.
Very narrow and specific implementation details might be patented but compiler technology itself is as old as the hills.
I mean Reason seems to be part of BuckleScript which doesn't belong to FB
Wondering if Reason will take off and what it will mean for languages like Elm or ClojureScript.
Jordan transcribed the prototype into JS for adoption; the SML version of React, however great it might be, would have died in obscurity. The Reason project's biggest goal is to show that OCaml is actually a viable, incremental and familiar-looking choice. We've been promoting this a lot but I guess one blog post and testimonial helps way more.
There's inevitably gonna be a bit of doubt at the viability of Reason at first; but to make an argument from authority: Jordan and the team made ReactJS take off even though everyone hated it at first (browse the first HN/Reddit threads; they weren't rosy). I was there to witness it too. I'd like to say we're rather experienced at handling the social aspect required to make such project take off potentially, at least. Technically speaking, deferring to OCaml is a safe bet.
What it means for Elm/ClojureScript: https://reasonml.github.io/guide/what-and-why#dont-like-reas...
We've explicitly listed Elm & ClojureScript on our Why page as good alternatives to check. I've personally used both. The world is big enough for more of such languages.
Can't speak for Jordan but I'm guessing that the answer is "it just felt right". So you can consider ReactJS as a manual program extraction from SML.
I'm not sure whether the original one was ever fully finished. I think there was a blocker from the React reconciler that SML couldn't solve in its type system? It needed GADT and existential, which is why he moved onto OCaml. Related: https://drup.github.io/2016/08/02/difflists/
So in a sense, we knew for a while now that ML would work out, somewhat demonstrated by the real-world usage of React. The technical merits are there; the social ones, definitely not. Thus Reason, which you can view as ReactJS finally going back to its root through ReasonReact, and with the social aspect properly being worked on.
I would be really interested in hearing what you guys do in that regard. I think a lot of worthy open-source projects fail not on their merits, but for their execution of the social aspect.
This is usually my bell weather than something’s going to be massively popular, btw.
HN/Reddit communities both have massive blinkers on and hate change. Pretty much every major advance in spaces I follow has been loathed by both.
It needs to be powerful and flexible enough to allow things like React or other frameworks to be built in it. Elm has only the Elm way, nothing more.
I like languages that are readable. This is starting to look like codegolf. https://github.com/reasonml-community/reason-react-hacker-ne...
EDIT:
Sorry, I just don't like when people share shallow and negative thoughts about projects that take away from meaningful discussion.
Why is the OP comment shallow? Because obviously _some_ people find it readable which would suggest that it is familiarity that is the problem -- not some universal quality of the language.
You're not constrained to use one-letter names for type variables, or to drop names of argument variables, but it turns out to be very handy, and it only takes reading a couple of hundred lines of code to get comfortable with this notation.
It scales easier to settle the debate by just fulfilling the demand rather than encountering each such argument and spend literally years debating about them.
Are you more like a dev-advocat or something?
Anyways, since I'm basically doing Reason 24/7 I kinda consider myself to be on the team.
My guess in this case is that get_internal is a function that receives two parameters (a map with keys of type `a` and values of type `b`, and a key of type `a`) and returns a value of type `b` or `undefined`, if the key is missing. The return is wrapped in an option type so you don't mix the `b`s with the `undefined`s.
That said, this is a very weird example to pick because the actual implementation of the function is not in this file. Assuming that in Reason the @@ means the same as in Ocaml, that `@@` is placeholder that tells the code preprocessor where to insert the actual code for the implementation of `get`. The actual logic for the get function would be in the preprocessor.
Where's the documentation for this? I'm only familiar with `@@` as a low-precedence no-op operator which helps to cut down on parentheses.
https://whitequark.org/blog/2014/04/16/a-guide-to-extension-... https://blog.janestreet.com/extension-points-or-how-ocaml-is...
These can be used to do the sort of metaprogramming that people used to do with camlp4. If you want to search more, the other keyword for googling would be "ppx".
I think you'll find that any code that deals with foreign function interfaces and interop with the host environment is ugly in any language.
from https://github.com/reasonml-community/Mareo/blob/master/src/...
ignore, in OCaml, allows to "cast the expression to void"
val ignore : 'a -> unit
"@@" is a low-binding application operator, similar to Haskell's "$", it's used to avoid parenthesising.
* "external" is an FFI declaration
* "get_internal" is the local symbol name
* ":" introduces the type signature, so "get_internal" is a function from a "map 'a 'b" (aka Map<A, B> in more C-style generics) and an 'a to a Js.undefined 'b
* followed by the external symbol ("get")
* and the stuff between brackets is a compiler instruction (an "extension point": https://whitequark.org/blog/2014/04/16/a-guide-to-extension-...)
These are exciting times.
* Having a different syntax isn't without cost for the existing OCaml community, but so far most have been very supportive
It's funny, seeing awesome FP assignments in SML and OCaml is one of the few things that makes me really want to go back and do a computer science degree. Alas, it seems like functional languages are disappearing from universities one by one these days, only to be replaced by Python or Java.
From what I know, there are at least three classes in some universities (forgot the names) whose professors/TAs told me they were teaching Reason to decent success. Reason's also used in this users study: https://arxiv.org/pdf/1708.07583.pdf. Reason removes the unfamiliarity part in order for them to get to the core of the research, which is still done in OCaml.
Don't lose hope! =)
I come from a heavy haskell background, and don't have a lot of ML experience so gave been betting on Purescript recently. But reason seems really nice. Good luck with the port! A success for Functional Programming
Btw, for more justification on the syntax change, I've written a short answer here: https://www.reddit.com/r/reasonml/comments/6v2olv/new_syntax...
This could well be completely unrelated, but it has been one of the driving factors to me moving more to WhatsApp's web interface.
Could it be all the separate CSS files they're linking?
Not sure how much I can say, but the leak is somewhere in the subscriptions, which isn't in Reason. Ironically the goal is to convert that section to Reason so that refactoring can finally be done (I've left that part out of the blog post just in case). Messenger produced the grandfather of Flux; it's not the easiest thing to refactor.
It's a native desktop client for Skype, Slack, Facebook, WhatsApp and many others. It's only 4 MB, it has minimal CPU usage, and it can handle hundreds of thousands of messages without lag.
Facebook support is coming tomorrow, WhatsApp is going to be supported next week.
Do these services care that your app lets the user side-step their apps?
Incredible how it has a seemingly from-scratch cross-platform UI without framework bloat; but it doesn't seem to work...
If you still get nothing after 10 seconds, could you please submit a bug report via the built-in '?' form? If it's a public team, please include the URL.
Thanks
2) Nothing. I'm drawing everything directly with OpenGL/ANGLE.
3) Yes, hopefully this year.
5) Do you plan to support the Matrix protocol?
6) Do you plan to made income on it? If so, by donation or else (cost, ads, etc.)?
5) Absolutely!
6) Yes, still not certain about that either.
Are you the author? It's hard to trust company logins to a binary blob, coming from a page with no information at all (no about/contact, empty github profile). Looks very fishy at the moment.
Like the home page says, the binaries are going to be signed after September 15. My docs are being verified right now.
Thanks for creating this :)
Is it used only for authethication? Can a native web view used anyhow (electrino)?
I dislike Slack/etc because they are non-native which means they are slow, and behave incorrectly. Eul will address the speed, but without the native controls it's unlikely to behave correctly.
Behaviour I'd be looking for to match system controls: text field editing, including shortcut keys, accessibility of controls using system accessibility attributes (which can be used for screenreaders, productivity apps and OS scripting), pervasive drag and drop support, proxy icons, copy/paste (with rich-text formatting where necessary).
There's a lot to do, much of which comes "for free" or at least "discounted" when using system controls. I really hope you prove me wrong and I wish you all the best with this. I may well end up using Eul anyway because of the speed, but I thought I'd try and provide my motivation for why using system controls is such a key part of my dislike for Electron apps.
Windows 10
> Powerful, safe type inference means you rarely have to annotate types, but everything gets checked for you.
Why did they create a new language? Isn't this what they made Flow for? Or does Flow rely heavily on annotations? I did not follow up the development of Facebook's projects recently. This is the first time I have heard of that.
With that kind of exposure comes some pretty negative snarks & unrelated criticisms that are hard to counter in a post/tweet. I've left a few replies on this thread but I'll still try my best to answer the questions here =) (but before that, please do give https://reasonml.github.io/guide/what-and-why a look).
Is this because Microsoft has TypeScript, Apple has Swift, and so now Facebook has Reason to keep all your application in your more/less proprietary format?
Further, if you already have React, then why not write everything in React and then just extend it with the features you've built into Reason?
Pardon if these aren't clever questions, but I'd love to understand the big selling points here. Thanks!
OCaml has some nice features - algebraic datatypes, complete type coverage, and pattern matching - that would be clunky to retrofit into JavaScript, hence this project.
Reason's open-source, as well as ReasonReact(https://github.com/reasonml/reason-react). Using BuckleScript the OCaml-to-JS compiler, we compile to normal JS code with minimal runtime.
Here's why we made it: https://reasonml.github.io/guide/what-and-why
I'm a PureScript fan myself, but I like what reason is doing. There are a _lot_ of JS projects out there that would benefit from being converted to a language with a real type system, and it's good there are people approaching this problem from all sides.
EDIT: If anyone reading this hasn't tried a language with an OCaml or Haskell-based type system, consider giving it a shot. If you're just familiar with static type systems from languages like Java I promise you this will be a totally different experience.
Reason sounds interesting and something I'd like to stay up to date on until the time comes that I want to experiment with something and want to think of Reason, but without a feed to subscribe to I'm going to forget about it ;)
Error:%s:%d:%d-%d: incompatible type: expected %s, found %s
Seeing that you'd usually focus on a single error rather than trying to get an overview of all errors
IMHO these are not good changes --- chances are that many errors have a common cause which may be far away, and fixing that will make them all disappear. This encourages "code tunnel-vision", making small patches to "fix" each error ("the compiler says the error is here, so I must try to fix it here somehow"), which in the long term can cause massive duplication and decrease the overall quality.
Then again, I don't use JS so maybe the culture is very different, but the "gradual increase of verboseness" seems to be a common trend among other languages, that I strongly disagree with. Writing in six words ("We've found a bug for you!") what could be expressed in one ("Error") does not help anyone except possibly the most noobish of programmers, which one should hope to learn and thereby advance from their level anyway; unless you treat your developers as incapable of learning and disposable, it is counterproductive --- or perhaps I should say un-Reason-able(!) --- to optimise for the extreme beginner at the expense of the experienced.
/rant
Happy to discuss that other blog post somewhere else (discord.gg/reasonml)
Highly recommend
Time boxing my FB usage at least stops the "scroll forever" behavior I used to have
I have noticed fairly recently that searching chat histories is much faster and more reliable than it used to be, so that's a plus.
On topic, ML is a neat language family but I just couldn't get into it when I tried F# back in the day. I'm a Clojure fanatic through and through but the more projects using functional languages the better, even if it does use static types!
So much for mission of connecting the entire world, Zuck.
https://www.theverge.com/2017/5/18/15659414/facebook-messeng... https://play.google.com/store/apps/details?id=com.facebook.m...
The progress for front end looks very promising, however as someone that likes the look of Reason but isn't interested in front end I found getting into Reason with the native toolchain was no easier than OCaml.
I meant more as the webdev community, everyone seems to love to throw a ridiculous amount of time and money away by switching to a completely new stack—for apparently no reason—every 6 months.
About 80% of the devs I know spend hours on tooling and force users to download a ridiculous amount of JavaScript to use React with projects where the dashboard is a list of messages sent via a contact form, where the only functionality is to mark as read.
I React cool? Sure, and I use it. Do I have to use the same tech as the biggest site in the world for my super-small projects—like most people do because that's what you do? Probably not.
Am I stuck in the 90s and force a page refresh every time? Nope, but I spend days learning something—and of course part of my job is learning new things—but not 80% of the time, and it's not cool to make existing projects obsolete after 6 months.
I just think the whole thing is getting a little big ridiculous.
It was probably more ranting than not about your project, I apologize :-)
BTW, if you work at Facebook, can you explain why creating Yarn vs. improving NPM..? They seem to do the same exact thing in the same exact way from the user point of view, with Yarn being a lot faster and with better command naming.