Forem: Mainak Bhattacharjee

Why not Language Specific SLMs as coding agents

Mainak Bhattacharjee — Sun, 10 May 2026 06:28:28 +0000

Coding should be free, private, secure, and accessible offline — no exceptions. It has always been one of humanity's greatest equalizers, a skill that anyone with a cheap laptop and curiosity could pick up and use to build something real. Putting it behind a paywall doesn't just create inconvenience — it creates inequality. It turns a democratic craft into a privilege, and that is a direction we should actively resist.

There is a better path. Instead of chasing ever-larger general-purpose models that only run on expensive infrastructure, we should be building Language Specific Small Language Models — compact, focused models that are genuine experts in a single programming language.

The Core Logic is Sound:

A general coding SLM still carries baggage — it knows 50+ languages, frameworks, paradigms. But most developers work in 1 or 2 languages most of their career. So why should their local model waste capacity on the rest?

A Python-only SLM doesn't need to know:

Rust's borrow checker
Java's verbose OOP patterns
C++ memory management
Ruby's metaprogramming

Strip all that out and suddenly your model can be dramatically smaller while being dramatically better at the one thing it does.

What Language-Specific SLMs Could Look Like:

PyroLM (Python) — 500M params, knows Python, pip, and common libs, runs on 2GB RAM

WebLM (JS/TS) — 500M params, knows JS, TS, Node, and the npm ecosystem, runs on 2GB RAM

QueryLM (SQL) — 300M params, knows SQL dialects and query optimization, runs on 1GB RAM

ShellLM (Bash) — 200M params, knows shell scripting and Linux tools, runs on 512MB RAM

RustLM — 600M params, knows Rust, Cargo, and the ownership model, runs on 2GB RAM

These could genuinely run on very low-end hardware — even phones.

The Deeper Advantages Nobody Talks About:

Deeper ecosystem knowledge A Python-only model can deeply learn not just the language but the entire ecosystem — NumPy, Pandas, FastAPI, Django, pytest patterns, Pythonic idioms, PEP standards. A general model skims all of this. A specialist model lives in it.
Better error understanding Python errors are different from JS errors. A Python-specific model trained heavily on debugging patterns, stack traces, and common mistakes would catch errors a general model misses.
Version awareness Python 3.12 is different from 3.8. A language-specific model can be trained to be deeply aware of version differences, deprecations, and migration paths — something general models handle poorly.
Smaller = faster = better UX A 300MB model responds almost instantly even on weak hardware. That responsiveness changes how people use it — quick inline suggestions, real-time checks, not waiting 10 seconds for a response.
Easier to update and maintain When Python 3.14 comes out, you retrain or fine-tune just the Python model. You don't have to touch anything else. Much more maintainable long term.

What Training Data Would Look Like:

This is where language-specific models have a massive advantage:

Curated, verified repositories in that language only
Official documentation deeply embedded
Common error → fix pairs scraped from Stack Overflow
Code review comments teaching idiomatic patterns
Test suites teaching what "correct" looks like
Changelogs and migration guides for version awareness
Quality over quantity. 10GB of excellent Python code beats 1TB of random multilingual code for this purpose.

The Honest Challenges:

Context still matters Real projects mix things. A Python backend developer still writes YAML configs, SQL queries, Bash scripts, Dockerfiles. A pure Python model is blind to all of that. You'd either need multiple models running together or accept that limitation.
The switching friction Developers would need to switch models when switching languages. That's a workflow problem that needs good tooling to solve.
Who builds and maintains it Language communities themselves are the natural answer — the Python Software Foundation, the Rust Foundation, the JS community. But these organizations have historically focused on the language, not AI tooling. That culture would need to shift.

The Most Exciting Possibility:

Imagine this stack:

Your laptop (4GB RAM)
├── Router model (tiny) → detects what language you're writing
├── PyroLM → activates when you're in .py files
├── QueryLM → activates when you're writing SQL
├── ShellLM → activates in terminal
└── All offline. All free. All fast. Forever

A smart VS Code extension could handle the routing invisibly. You'd never think about which model is running — it just works, privately, for free, on any machine.

But Academic prestige in AI research goes to bigger, more general models. Publishing "we made a 500M parameter Python-only model" doesn't win the same attention as "we made a 70B model that beats GPT-4." The research community's incentives push toward general and large, not specific and small.

This idea deserves to be built. It's practical, technically sound, and solves a real access problem. The open source community — especially individual language communities — are the ones who could actually make this happen. Someone just needs to start.

What do you think?

From Regex Rampage to Lazy Bliss: My rjq Performance Adventure

Mainak Bhattacharjee — Sat, 12 Oct 2024 16:19:08 +0000

Hey there, fellow Rustaceans 🦀!

I've been building a JSON filter tool called rjq, inspired by the awesome jq. But things took a turn for the worse when I hit a performance wall during lexing. The culprit? Compiling regular expressions in a hot loop . It turns out, regexes are like hungry hippos – they chomp up performance if you're not careful!
Here's the story of how I tamed the regex beast and saved my program from a slow, sluggish fate:

The Regex Rampage 🦖:

At first, I naively compiled the regex patterns within the lexing loop. This meant every iteration involved creating a brand new regex object. Think of it like baking a whole new pizza for every bite – inefficient, right? This constant creation caused a major performance bottleneck i.e. ~80% execution time was consumed by this.

The Lazylock Solution 🧙‍♂️:

Thankfully, the Rust gods (and some helpful folks on the r/Rust subreddit) pointed me towards lazy_static and a technique called lazy initialization. This magic combo allowed me to compile the regex only once and store it in a thread-safe location using a LazyLock. Now, it's like having a box of pizza ready with a fresh slices whenever you need it – much more efficient!

The Lazy Bliss ✨:

The impact was phenomenal! Performance soared, and my lexing code became as smooth as butter . No more regex rampage, just happy filtering .
Want to See the Code?
Curious about the details? Head over to my GitHub repo for rjq: https://github.com/mainak55512/rjq

Lessons Learned 📚:

Regex compilation can be expensive, avoid hot loops!
Embrace lazy initialization for performance gains.
There's always a better way to do things in Rust (and life!)

So, the next time you encounter a performance bottleneck, remember – there might be a lazy solution waiting to be discovered!

P.S. If you have any other tips or tricks for optimizing JSON filtering in Rust, leave a comment below!

But wait, there's more!

Let's dive deeper into the technical aspects of this adventure.
Understanding lazy_static and LazyLock

lazy_static: This macro provides a way to declare static variables that are initialized only once, even in a multi-threaded environment.
LazyLock: This is a type provided by the lazy_static crate that ensures thread-safety during initialization.

Here's a simplified example of how I used these to optimize the regex compilation in rjq:

Outside the hot loop:

static MATCH_NUMBER: LazyLock<Regex> = LazyLock::new(|| Regex::new(r"^\d+\.?\d+").unwrap());

...and so on

Inside the hot loop:

    if MATCH_NUMBER.is_match(&source_string[cursor..]) {
        match MATCH_NUMBER
            .find(&source_string[cursor..])
            .map(|x| x.as_str())
        {
            Some(val) => {
                cursor += val.len();
                token_array.push_back(token(TokenType::NUMBER, val.to_string()));
            }
            None => (),
        }
    } else if ... so on

As you can see, the MATCH_NUMBER variable is declared using LazyLock, and it's initialized only once when the code is first executed. The LazyLock within the code ensures that the initialization is thread-safe.

Additional Performance Tips

Profiling: Use tools like perf or cargo-flamegraph to identify other performance bottlenecks in your code.
Data Structures: Choose appropriate data structures for your use case. For example, consider using HashMap for efficient lookups.
Algorithms: Optimize algorithms to reduce computational complexity.
Memory Management: Be mindful of memory allocations and deallocations.

By following these tips and leveraging techniques like lazy initialization, you can significantly improve the performance of your Rust applications.

Happy coding 🎉!

Introducing rjq: A Fast and Lightweight CLI JSON Filtering Tool

Mainak Bhattacharjee — Fri, 11 Oct 2024 06:05:31 +0000

In the world of data manipulation, JSON has become a ubiquitous format, but filtering and querying JSON data can be cumbersome without the right tools. Enter rjq, a command-line JSON filtering tool developed in Rust🦀, designed to be a performant and lightweight alternative to the popular jq tool.

The Motivation Behind rjq

rjq began as a hobby project, driven by a desire to create a tool that prioritizes performance and simplicity. With a keen focus on providing a robust alternative to jq, rjq is compatible with both Linux and Windows, making it accessible to a wider audience.
Key Features

Performance:

rjq has been optimized for speed, running nearly 2x faster than jq when tested on a Linux machine with 4GB RAM and an Intel i3 6th Gen processor. This performance boost can significantly enhance workflows, especially for users dealing with large datasets.

Simplicity:

The query structure of rjq is designed to be intuitive. Writing queries feels akin to crafting simple conditional statements in any programming language, which lowers the barrier to entry for new users.

Lightweight:

With a minimalistic approach, rjq ensures that users can quickly load and filter JSON data without unnecessary overhead.

How to Use rjq

Using rjq is straightforward. You can load JSON data from a file using the --load flag, or you can pipe input directly into the tool. Here are some usage examples:


rjq --load="test.json" --query="<query string>" --params="<comma separated parameter list>"

Alternatively, you can pipe JSON output from other commands:


stto --json cpython | rjq --query="<query string>" --params="<comma separated parameter list>"

The Development Journey

The development of rjq has been a valuable learning experience, particularly in mastering the intricacies of Rust. The support from the Reddit community was instrumental in overcoming challenges. You can check out some of the discussions and insights from fellow developers in this Reddit post.

Future Plans

Looking ahead, the goal for rjq is to become the go-to choice for JSON filtering on both Linux and Windows. rjq is still in early development stages and there are plans to incorporate new features and enhance the tool's capabilities to meet the needs of users day-to-day usage. Any contribution, stars ⭐ and fork 🔗 to the rjq repo is greatly appreciated 👍.

Who Can Benefit from rjq?

rjq is tailored for:

Developers:

Those working with JSON data who need a reliable filtering tool.

Data Analysts:

Professionals seeking efficient data extraction methods.

DevOps Teams:

Teams automating data processing tasks in their workflows.

Installation

Getting started with rjq is easy. Binaries for both Linux and Windows are available in the releases section of the GitHub repository, allowing users to install the tool without hassle.

Conclusion

Whether you’re a developer, data analyst, or part of a DevOps team, rjq offers a fast, lightweight solution for filtering JSON data. With its performance, simplicity, and growing feature set, rjq is poised to become an essential tool in your data processing arsenal. Check out the GitHub repository to learn more and get started today!