흥미로움. 나는 jq의 문법이 직관적이라 느끼며, 쉘 파이프라인처럼 점, 파이프, 대괄호만 쓰는 게 익숙함
주로 일회성 필터를 작성하기 때문에 읽는 시간보다 쓰는 시간이 많음
아마 내 사용 사례가 단순하거나 jq가 내 사고방식에 잘 맞는 듯함
모든 CLI 도구가 JSON을 입출력하고 jq로 연결되는 세상을 꿈꾸지만, 그건 당신에게는 악몽일 듯함
jq는 자주 쓰지 않아서 ‘배움의 골짜기’ 에 머무는 도구임
쓸 때마다 새로 배워야 해서 직관적이지 않음
sed도 Turing 완전함에도 불구하고 대부분은 정규식 치환 정도만 씀
내가 만든 celq를 추천함
jq를 좋아하지만, 예전에 내가 쓴 쿼리를 이해 못할 때가 있었음
celq는 더 익숙한 CEL 언어를 사용함
나도 비슷한 이유로 dq라는 도구를 직접 만듦
단순히 JavaScript로 JSON을 다루는 방식인데, 놀랍게도 jq보다 빠름 $ cat package.json | dq 'Object.keys(data).slice(0, 5)' 같은 식으로 사용함
JSON 자체가 불필요한 구문적 잡음이 많아서 귀찮음
나는 Clojure를 배운 덕분에 이제는 JSON 대신 EDN을 씀
더 간결하고 읽기 쉬우며 구조적으로 다루기 쉬움
요즘은 borkdude/jet이나 babashka로 데이터를 다루고, djblue/portal로 시각화함
jq의 복잡한 연산자를 고집하는 이유를 이해 못하겠음
성능을 중요하게 생각하지만, 나노초 단위의 비교는 과시적 퍼포먼스처럼 느껴짐
대부분의 경우 지금 쓰는 도구로 충분함
예를 들어, 나는 큰 파일에서만 grep 대신 rg를 씀
이런 생각이 들면 “나는 타깃 사용자가 아니다”라고 생각하면 됨
2ms와 0.2ms의 차이는 사소해 보여도, TB 단위의 스트림을 처리하는 사람에게는 중요함
하지만 모두가 그렇게 생각하면 결국 작은 비효율이 누적되어 전체가 느려짐
하드웨어는 빨라졌는데 소프트웨어는 오히려 느려지는 현실임
jq가 차별화되려면 직관적인 문법과 실전 예시가 더 많아야 함
“충분히 빠르다”는 말이 늘 마음에 걸림
최적화를 거부하는 건 게으름과 상상력 부족처럼 느껴짐
네트워크 지연보다 빠르다는 이유로 안심하는 건 변명처럼 들림
나도 속도보다 사용성과 기능을 더 중요하게 생각함
만약 JSON이 너무 크다면, JSON 대신 이진 포맷을 써야 함
CLI에서 복잡한 파이프라인을 짜야 한다면, 차라리 프로그램을 작성하는 게 낫다고 봄
많은 새로운 CLI 도구들이 “더 빠르다”를 내세우지만, 실제로 jq가 느리다고 느낀 적은 거의 없음
나는 TB 단위의 ndjson 파일을 다룸
jq로 필드 이름만 바꾸는 단순 작업도 너무 느려서 Node나 Rust 스크립트로 직접 처리함
초대형 로그 파일을 다루는 경우 jq가 느리게 느껴질 수 있음
하이퍼스케일러 환경에서는 수 TB의 로그를 직접 내려받아 분석함
우리는 수천 개의 노드에서 JSON 응답을 파싱함
모니터링 해상도에 따라 성능 차이가 체감될 수 있음
새로운 도구가 나올 때마다 “Rust로 다시 만든 더 빠른 버전” 패턴이 반복됨
기능 일부만 구현하고 벤치마크로 승리를 주장하는 식임
이번 프로젝트도 그런 ‘부분집합이 더 빠르다’ 트렌드의 일환으로 보임
어떤 도구가 느리다는 건 실제로 느려지는 순간에만 깨닫게 됨
그때부터는 모든 게 느리게 느껴짐
ripgrep처럼 한 번 빠른 도구를 쓰면 다시 돌아가기 어려움
jq와 yq를 모두 써봤지만, yq는 훨씬 느림에도 불만이 없었음
jq보다 빠른 도구가 있다면 멋지지만, 그건 특정 사용자층에게만 필요함
그래도 최적화를 사랑하는 사람으로서 존경을 표함
어떤 yq를 말하는지 궁금함 — Go 버전인지 Python 버전인지?
서버 통합 환경에서는 성능이 중요하지만, CLI에서는 대부분 충분히 빠름
나는 ArcGIS에서 내보낸 GeoJSON 수 GB를 jq로 처리함
ETL 단계에서 시간이 꽤 걸림
모든 사람이 같은 방식으로 도구를 쓰는 건 아님
페이지를 처음 열었을 때 라이트 모드 색상 깨짐이 있었음
다크 모드로 전환했다가 돌아오면 해결됨
Hacker News 의견들
jq의 문법이 너무 난해해서 매번 단순한 JSON 값 하나를 가져오려 해도 검색해봐야 함
주로 일회성 필터를 작성하기 때문에 읽는 시간보다 쓰는 시간이 많음
아마 내 사용 사례가 단순하거나 jq가 내 사고방식에 잘 맞는 듯함
모든 CLI 도구가 JSON을 입출력하고 jq로 연결되는 세상을 꿈꾸지만, 그건 당신에게는 악몽일 듯함
쓸 때마다 새로 배워야 해서 직관적이지 않음
sed도 Turing 완전함에도 불구하고 대부분은 정규식 치환 정도만 씀
jq를 좋아하지만, 예전에 내가 쓴 쿼리를 이해 못할 때가 있었음
celq는 더 익숙한 CEL 언어를 사용함
단순히 JavaScript로 JSON을 다루는 방식인데, 놀랍게도 jq보다 빠름
$ cat package.json | dq 'Object.keys(data).slice(0, 5)'같은 식으로 사용함나는 Clojure를 배운 덕분에 이제는 JSON 대신 EDN을 씀
더 간결하고 읽기 쉬우며 구조적으로 다루기 쉬움
요즘은 borkdude/jet이나 babashka로 데이터를 다루고, djblue/portal로 시각화함
jq의 복잡한 연산자를 고집하는 이유를 이해 못하겠음
성능을 중요하게 생각하지만, 나노초 단위의 비교는 과시적 퍼포먼스처럼 느껴짐
대부분의 경우 지금 쓰는 도구로 충분함
예를 들어, 나는 큰 파일에서만 grep 대신 rg를 씀
2ms와 0.2ms의 차이는 사소해 보여도, TB 단위의 스트림을 처리하는 사람에게는 중요함
하드웨어는 빨라졌는데 소프트웨어는 오히려 느려지는 현실임
최적화를 거부하는 건 게으름과 상상력 부족처럼 느껴짐
네트워크 지연보다 빠르다는 이유로 안심하는 건 변명처럼 들림
만약 JSON이 너무 크다면, JSON 대신 이진 포맷을 써야 함
CLI에서 복잡한 파이프라인을 짜야 한다면, 차라리 프로그램을 작성하는 게 낫다고 봄
많은 새로운 CLI 도구들이 “더 빠르다”를 내세우지만, 실제로 jq가 느리다고 느낀 적은 거의 없음
jq로 필드 이름만 바꾸는 단순 작업도 너무 느려서 Node나 Rust 스크립트로 직접 처리함
하이퍼스케일러 환경에서는 수 TB의 로그를 직접 내려받아 분석함
모니터링 해상도에 따라 성능 차이가 체감될 수 있음
기능 일부만 구현하고 벤치마크로 승리를 주장하는 식임
이번 프로젝트도 그런 ‘부분집합이 더 빠르다’ 트렌드의 일환으로 보임
그때부터는 모든 게 느리게 느껴짐
ripgrep처럼 한 번 빠른 도구를 쓰면 다시 돌아가기 어려움
jq와 yq를 모두 써봤지만, yq는 훨씬 느림에도 불만이 없었음
jq보다 빠른 도구가 있다면 멋지지만, 그건 특정 사용자층에게만 필요함
그래도 최적화를 사랑하는 사람으로서 존경을 표함
ETL 단계에서 시간이 꽤 걸림
페이지를 처음 열었을 때 라이트 모드 색상 깨짐이 있었음
다크 모드로 전환했다가 돌아오면 해결됨
나는 정확성 때문에 Jaq으로 갈아탐
성능도 jq보다 낫다고 함
jq의 느리다는 평판은 배포 패키징 문제 때문으로 보임
나는 업무상 newline-delimited JSON(jsonl) 을 자주 다룸
각 줄이 완전한 JSON 객체인데, 주요 CLI 도구들이 이 포맷을 지원하는지 궁금함
jq, mlr, htmlq, xsv, yq 등 여러 데이터 처리 CLI 도구를 써봤지만,
Nushell을 발견한 뒤로는 전부 대체됨
하나의 문법으로 모든 포맷을 다룰 수 있어 신선한 경험이었음
동료들과 협업할 때만 jq, yq, mlr을 병행함
자동완성 설정과 명령어 검색성에 약간의 불편이 있지만, oh-my-zsh보다 훨씬 낫음
타입 주석 강제, 정적 바이너리 컴파일, TUI 라이브러리까지 생기면 소규모 앱 작성에도 쓸 듯함
멋진 도구임! 다만 벤치마크 시각화가 조금 아쉬움
모든 도구가 같은 색이라 jsongrep이 어디 있는지 찾기 어려움
jq 자체도 그래프에 없어서 혼란스러웠음
xLarge 파일이 190MiB라 작은 편인데, 나는 400MiB~1GiB JSON을 자주 다룸
더 큰 공개 JSON 문서가 있다면 알려주면 좋겠음
벤치마크 시각화가 거칠게 느껴짐
색상이나 형태를 활용해 더 많은 차원을 표현하면 좋겠음
파일 경로를 직접 읽어야 결과를 이해할 수 있는 건 불편함