#clojure

Why this year’s Clojure/Conj matters beyond the conference

Clojure/Conj 2026 diễn ra từ 30/9 đến 2/10 tại Charlotte, North Carolina và được phát trực tuyến miễn phí, giúp các lập trình viên toàn thế giới tiếp cận mà không cần chi phí đi lại. Nubank, một công ty sử dụng Clojure lâu năm, đã nhấn mạnh sự hỗ trợ của mình cho hội nghị và tài trợ nguồn mở cho các nhà bảo trì hệ sinh thái Clojure. Họ cho rằng việc chia sẻ kiến thức tiếp cận là yếu tố sống còn để xây dựng cộng đồng kỹ thuật lành mạnh. Hội nghị này quan trọng vì nó không chỉ là sự kiện học tập mà còn là minh chứng cho sự gắn kết giữa doanh nghiệp và cộng đồng mã nguồn mở.

Clojure/Conj 2026 mở rộng tiếp cận cộng đồng lập trình viên toàn cầu mà không giới hạn địa lý hay chi phí, đồng thời khẳng định vai trò thiết yếu của chia sẻ kiến thức trong hệ sinh thái kỹ thuật.

Why this year’s Clojure/Conj matters beyond the conference itself

Clojure/Conj 2026, taking place September 30 to October 2 in Charlotte, North Carolina, will be streamed online free of charge, removing travel and cost barriers to participation. Nubank, a long-time user and sponsor of the Clojure ecosystem, explains why it supports the conference and highlights its ongoing investment in open source Clojure maintainers via GitHub Sponsors.

Clojurists Together Update: July and August 2026

Clojurists Together đã tài trợ cho việc duy trì nREPL, CIDER và các dự án liên quan trong tháng 7 và 8 năm 2026. Sau khi phát hành CIDER 2.0, tác giả đã tận dụng động lượng để cải thiện toàn bộ hệ sinh thái nREPL/CIDER. Nhiều dự án bị bỏ qu đã được phát hành phiên bản mới đúng hạn, trong khi nREPL có thêm hai triển khai mới bằng các ngôn ngữ lập trình khác. Bài viết này cung cấp cái nhìn chi tiết về tiến độ công việc và thành đạt của hệ sinh thái Clojure trong giai đoạn này.

Bài cập nhật này cung cấp cái nhìn toàn diện về những tiến bộ đáng kể trong hệ sinh thái nREPL/CIDER và các dự án liên quan trong Clojure.

jank reimagines C++ errors and gets an official native package repo

jank, một Clojure dialect được triển khai trên C++ và LLVM, đã cải thiện báo lỗi với stack trace chính xác cho ngoại lệ runtime và trang lỗi riêng cho mỗi lỗi compiler. Dự án cũng tái thiết kế lỗi compiler C++ bằng cách trình bày các ứng viên overload mơ hồ trong bảng dễ đọc hơn Clang hay GCC, hỗ trợ automatic trait conversions của jank. jank giờ có hệ thống build giống Cargo trên Clojars và kho package chính thức jank commons cho các bindings native library. Những cải tiến khác gồm REPL client với syntax highlighting, macro expansion được tối ưu và native value throwing.

Lập trình viên nên đọc bài này để khám phá cách jank cải tiến báo lỗi C++ và tạo hệ sinh thái gói gốc với thông tin hữu ích.

simple is not small

Bài viết chỉ ra rằng nhiều nhà phát triển thường nhầm lẽ cho rằng kích thước nhỏ của một chương trình đồng nghĩa với sự đơn giản. Tuy nhiên, khi chương trình được viết ngắn gọn, các phụ thuộc giữa các module thường được ẩn đi dưới dạng coupling chặt chẽ mà không dễ dàng nhận ra. Nguyên nhân kỹ thuật nằm ở việc sử dụng các hàm toàn cục, biến trạng thái chung hoặc gọi trực tiếp giữa các thành phần mà không có lớp trừu tượng hay interface rõ ràng. Hệ quả là khi cần thay đổi hoặc mở rộng, một sửa đổi nhỏ có thể gây ra tác động lan rộng, làm tăng nguy cơ lỗi và làm giảm tốc độ phát triển. Bài học đáng rút ra là cần đánh giá mức độ coupling và độ cohésion thay vì chỉ dựa vào kích thước mã nguồn, và áp dụng các nguyên tắc thiết kế như Dependency Injection hoặc module boundaries ngay cả trong các dự án nhỏ.

Bài viết giúp lập trình viên hiểu rằng sự đơn giản trong code không đồng nghĩa với quy mô nhỏ, mà là tránh được các kết nối ẩn gây khó khăn khi bảo trì.

Wrapping GTK4 in 800 lines of Clojure with Jolt

Bối cảnh của bài viết là việc tích hợp GUI GTK4 vào Clojure qua thư viện Jolt, giúp lập trình viên Clojure tiếp cận native UI development. Nguyên nhân kỹ thuật chính là giải quyết vấn đề binding native GTK4 API bằng FFI (Foreign Function Interface) trong môi trường JVM. Hệ quả thành công là tạo ra một wrapper chỉ 800 lines of code, đủ để xây dựng ứng dụng desktop với GTK4 từ Clojure. Điều đáng học là cách tiếp cận minimalistic khi binding native libraries, giữ cho dự án gọn nhẹ mà vẫn đầy đủ tính năng cho UI development.

Bài viết này cho thấy cách tạo binding GTK4 bằng Clojure một cách hiệu quả và tối giản với Jolt.

Smarter Form Targeting Is Not Coming to CIDER

Bài viết trước của tác giả đã anunciar rằng tính năng smarter form targeting sẽ được đưa vào CIDER. Tuy nhiên, sau khi đặt câu hỏi về quy tắc giải quyết và bất ngờ còn tồn tại, tác giả nhận được phản hồi từ cộng đồng. Phản hồi cho thấy CIDER phiên bản 2.1 sẽ giữ nguyên hành vi cổ điển thay vì áp dụng cách tiếp cận mới. Điều này có nghĩa là các quy tắc chọn form hiện tại không thay đổi, và các nhà phát triển không cần lo về sự khác biệt trong việc xử lý form. Bài học là trước khi công bố thay đổi, cần xác nhận kỹ các quy tắc giải quyết và lắng nghe phản hồi thực tế để tránh thông tin sai lệch.

Bài này giúp lập trình viên hiểu rõ quyết định ngừng triển khai smarter form targeting trong CIDER và giữ nguyên hành vi classic.

Smarter Form Targeting Is Coming to CIDER

Bài viết mô tả tình trạng thường gặp trên kênh Slack #cider khi người dùng nhấn C-x C-e và nhận được kết quả đánh giá không như mong đợi. Nguyên nhân là do CIDER dựa vào vị trí con trỏ mà nó dự đoán, thường không trùng với nơi con trỏ thực sự đứng. Trong bản phát hành CIDER 2.1 sắp tới, các lệnh đánh giá được cải tiến để tự động xác định form mục tiêu dựa trên vị trí thực tế của con trỏ. Thay đổi này loại bỏ nhu cầu phải di chuyển con trỏ thủ công trước khi đánh giá, giảm thiểu lỗi và tăng tốc độ làm việc. Điều đáng học là việc thiết kế công cụ chỉnh sửa cần dựa vào ngữ cảnh thực tế của người dùng thay vì giả định vị trí cố định, từ đó cải thiện trải nghiệm lập trình.

Cải tiến nhắm mục tiêu thông minh trong CIDER 2.1 giúp bạn đánh giá code chính xác hơn bằng cách tự động xác định biểu thức cần thực thi dựa trên vị trí con trỏ thực tế.

Elixir, Clojure, or Python for LLM Agents? Our Experience with All Three

Bài viết so sánh kinh nghiệm xây dựng LLM Agents bằng Python, Clojure và Elixir, tập trung vào cách mỗi ngôn ngữ quản lý tools, state, vòng lặp ReAct, xử lý song song, fault tolerance, phân phối, hệ sinh thái, testing và tài liệu. Kết luận: Python phù hợp phát triển nhanh và thư viện AI phong phú, Clojure cho state có thể kiểm tra/replay trên JVM, còn Elixir lý tưởng cho hệ thống high-concurrency nhờ OTP supervision.

Lập trình viên muốn xây dựng các hệ thống LLM agent hiệu quả và linh hoạt nên đọc bài này để so sánh các ưu nhược điểm của Python, Clojure và Elixir trong việc tối ưu hóa tốc độ phát triển, quản lý trạng thái và khả năng chịu lỗi cho ứng dụng AI phức tạp.