I don't have any stock in those 2 engines, so I don't care which one is better than the other. At the end as a poor chess player it won't change anything :) It's actually interesting to compare how those two software are evolving and how they got here.
Stockfish is much older. And it took it a lot of hand tuning to reach its current level. It is (or was) full of carefully tested heuristic to give a direction to the computation. It would be very difficult to build an engine like stockfish in a short span.
Leela got there very very quickly. Even if it was not able to win in October, the fact that it got competitive and forced the field to adopt drastic changes in such a short period of time is impressive. It seems to be a good example of how sometimes no using the "best" solution could still be a win. Getting good results after a few months against something that required 10 years of work.
Actually stockfish crushed leela in recent TCEC. It seems that the new neural network of stockfish had a huge effect on the performances. Something like a 130 ELO improvement.
I don’t see how there’s a biased intent. I’ve no shares in any tech. If anything I wish for rescript to be a big success given how much the company I am in relies on it. I’ve contributed to multiple bucklescript projects. And I’m not criticising the decisions of anyone.
well sorry if this isn't true, but I haven't insulted anyone. If I get those feedback and they are incorrect, I hope that you can provide my insightful ones to clear the situation.
Btw for people who want to use js_of_ocaml instead of rescript but still like react, there is https://github.com/jchavarri/jsoo-react. It's obviously not as polished. But it's interesting to see how much work it requires to bind a large lib like react.
I feel like the dev team is using "readable output" to mean both "human-readable" and "shared data types" depending on the situation. And it creates a lot of confusion.
actually bucklescript has never really been used at bloomberg. And bob left bloomberg a long time ago. So this fork is definitely not happening because of bloomberg.
To have code that you can compile to both native and js, the easiest thing is to stick to the ocaml syntax. It is supported by all the versions of the compiler (rescript or ocaml). And to also use the ocaml syntax for the tools doing code generation, such as atdgen.
from what I heard, they use typescript instead of reason for some time already. I don't know if they use react or not. I also heard that they weren't always using reasonreact even when they were using reason. So they've never been 100% on the same stack than what was advertised by the reason team.
It probably explain why fb dedicates so little resources to reason too.
> A few months ago we stopped referring to robots.txt files on U.S. government and military web sites for both crawling and displaying web pages (though we respond to removal requests sent to [email protected]). As we have moved towards broader access it has not caused problems, which we take as a good sign. We are now looking to do this more broadly.
I wonder how people working for the dragonfly project are feeling. It looks like the rest of the company hate what they are doing. But if they support censorship, they might not care what other people are thinking.
some real problems with jsoo are (non exhaustive list)
- "heavy" FFI (both in term of setup and syntax)
- the output is a big single .js file, which doesn't allow reloading of a single component and doesn't integrate well with stuff like webpack
- slower compilation time
- lacking documentation for the javascript audience