davesnx

but indeed, it's a nice workaround!

query-json --kind=inline would support reading from stdin, I didn't spend time on the Cmdliner enough!

I'm happy with the critics.

Judging is free and I didn't consider stdin as something to spend time on yet. Will do, now that some people raise it.

Thanks :D

Renamed :P

Sure, it's a missing feature "," creates 2 spins of the filter.

I certantly didn't use it, but I see where it's useful, will implement it soon.

Renamed already :D

Nothing that can be fixed later?

Adding most of the jq operations shoudn't affect performance at all, in fact If I endup implementing streaming could be even faster.

I have a issue to improve performance where I can push this forward: https://github.com/davesnx/query-json/issues/7

But sure, are caveats!

There's 4 alternatives to install query-json.

Before doing any curl | bash, check what's on the install command, that's the entire point of it.

The documentation is a problem in the OCaml world and a problem with Reason Native as well. I found myself pretty lost some times, esy.sh should be a initial point in contact for most of Reason related stuff.

Menhir/sedlex and others are pretty high accessibility barrier for new commers.

One of the nice things about all of it it's the discord, it's friendly and always helpful.

Hope it helps, just let me know if there's any specific!

Will rename it to query-json. Thaaanks!

Just because jq is very well stablished doesn't mean their APIs are well designed and we shoudn't improved because will break existing scripts.

There're a lot of quirks from the usage of it and people struggling with learning such a great tool, so in the area of query-json it will try to make a better interface for users.

Right, the explanation of Reason - BuckleScript - OCaml is always nebulous.

I used Reason to compile to Native, so using OCaml's stdlib and OCaml's dependencies and compiling it with OCaml, but my source code is written in Reason syntax.

I'm not sure at which "we" do you refer.

Reimplementing a piece of software that is 12 years old which mimics their UX and improves performance and error messages it's more than welcome in my opinion. My purpose was to learn the OCaml stack of writting compilers, so I personally found that I "needed" a language already created.

Thanks for raising those concerns

Right, I found q cute... but I'm thinking to release new version with the name query-json or just change the name all-together. Any suggestion? ^^

One of the main ideas of query-json is to provide excelent errors. So, it would teach you by using the tool.

and there are a few techniques to "discover" the schema of the json file, I trend to read with '.' or 'keys' and later keep going.

I'm planning to implement a flag where each operation prints the internal state of the json, so you would see what are the "pipes".

I will pick a few of your cheatsheet to implement next in q, Thanks!

Nice!

I will try to bring it to the brenchmark, thanks for sharing

Nobody said that jq is slow.

Right, q doesn't support streaming so it will manage a 90GB JSON.

I should specify that on the performance section, Thanks!

I don't want to fight for name, q was a shortener.

Happy to rename it to qj instead, but the option of renaming the binary it's a good workaround.

Sure, I worked with Elm before and I feel like they share the basics like immutability and types. Which makes a lot of sense, since Elm got very inspired by Haskell and Reason it's a syntax and a few beauties of OCaml.

A good intro (at least for me, since I'm into videotutorials) is https://egghead.io/courses/get-started-with-reason.

https://egghead.io/courses/get-started-with-reason

There are a few differences between both, a lot of people mention the fast compilation and the type inference.

I would add that the types from Reason are much "smaller" and concise, Option type or Result type and the immutability of Records/Objects creates an environment of safety that I don't have it in TypeScript.

That's not even true. It's still very early days for Reason VSCode tooling, since you might find a few extensions that support most of the cases but lacks a few key features that you might be used to while writing JS/TS.

Thanks, let me know if you are using it!

SC and the styled API from emotion are identical syntactic-wise and performance-wise. SC used to suffer from performance and big bundle size but these last 2 versions are very balanced. The same way as the sx prop from Emotion it's the css prop from styled-components.

Just to clarify and sell a little my ppx, styled-ppx supports the css prop as well, many people prefer that over the component api.

Hey JasoonS, I might agree with you, styled-ppx isn't feature complete, would you mind explaining which edge cases aren't accounted?

I'm doing great progress on it and don't want to miss something that is crucial for you.