davesnx

is very alive, released with OCaml 5.4 support and improving bit by bit

OCaml / Reason (Melange)

that's what' melange is lol

this is a good naval-style tweet, well done

Curious to know more, do you think can make a long-form of "why" and a detailed experience? If you have some time, would be massive to compare it with what's the same experience today

Shame on me; I have a few draft posts that never got the chance to publish. My non-native english doesn't fully help ^^

Expect some of them to be published at the end of the year or early january!

There are a few missleadings in your message:

ReScript isnt a fork of Reason, jsoo focuses only on compiling all OCaml and allows JS interop

Reason with Melange is a viable option for JS/TS devs.

I always loved hazel, probably a great tool to teach. What has been build with it?

OCaml

Biased answer:

The biggest differences between Elm and ReScript/ReasonML as language features are bindings, JSX and purity. Bindings in Elm are cumbersome and limited (on purpose) while in ReScript/ReasonML are easy, more feature complete and a little more fragile. JSX is exactly as React, while Elm doesn't have it; some people prefer it, some people don't. I love it. Purity in general terms makes Elm more strict while ReasonML/ReScript allow impurity when needed, still most APIs enforce functional style, immutability and proper data structures.

Regarding community, there's drama everywhere not sure If I can do a good job here. Maybe community size Elm is much bigger than others, but they need to reinvent most of tooling that is done in JS and ReScript/Reason takes advantage.

I encourage to not rely on anyones opinion about what's better, because you listed 5 languages with opposite directions.

Try it out yourself and decide based on users/team needs. Cheers.

It's a good idea to read "A bit of history" under Melange docs: https://melange.re/v1.0.0/rationale/#a-bit-of-history

With Melange ReasonML has a small comeback, since Melange and dune supports it out-of-the-box.

There has been a bit of activity on fixing bugs on refmt and polish the experience, no plans for big features so far but we will keep working on it.

We will update documentation from either reason-react and reason to highlight the integration with Melange soon.

Hi, I worked on rendering React in OCaml and cross-compiling it to JavaScript and wrote a blog post about it.

I'm happy to share it here <3

versus other than JavaScript stuff: Java, C++, OCaml or Go

Hey, thanks! This tries to solve exactly that, let me know if there's anything else that feels that needs an intro to OCaml community.

Mi bad english played me bad here. I meant to write "Picks python... blabla"

Looked to me like a "Python isn't than bad for perf" article.

The author: Selecting a programming language can be a form of premature optimization

Also the author: Pick python no matter the problem, the team, the libraries, the deployment targets, etc.

This is a great explanation about concurrency and parallelism and where multicore fits, FYI https://discuss.ocaml.org/t/multicore-ocaml-vs-thread/5838/1...

That's a project that we all wished was in a perfect shape in order to make Reason more approchable with jsoo.

That's very doable, but tedious to make and it's probably on of the selling points for Reason. Writting React code with OCaml is very tedious.

I tried to explain it on the Performance section and on the report

https://github.com/davesnx/query-json#performance https://github.com/davesnx/query-json/blob/master/benchmarks...

But all explanations aren't based by any evidence, just asumptions.

Yep, kind of.

The comma operations means that the "filters" are duplicated, so instead of one json state you would pass two if there's one coma; and ofcourse any number of commas are allowed.

I trend to use jq with a file all the time, I prefer to curl first and later operate on top. /slug

Thanks, next time if you paste the list somewhere else you can add query-json :P

+1

Yes, jq is written in C. Where LISP comes from?

Exactly I didn't claim to be faster in all the cases, since there's no feature parity and I won't make it that way.

For the set of operations that I implement it it's faster, that's true.

Exactly! I wanted to contact him

I hope so!

There are a few good asumtions about why is faster, there are just speculations since I didn't profile jq or query-json.

The feature that I think penalizes a lot jq is "def functions", the capacity of define any function that can be available during run-time.

This creates a few layers, one of the difference is the interpreter and the linker, the responsible for getting all the builtin functions and compile them have them ready to use at runtime.

The other pain point is the architecture of the operations on top of jq, since it's a stack based. In query-json it's a piped recursive operations.

Aside from the code, the OCaml stack, menhir has been proved to be really fast when creating those kind of compilers.

I will dig more into performance and try to profile both tools in order to improve mine.

Thanks