grandimam

Thank you for your kind words!

Fonts were added in the last minute, I'll add the link for the fonts as well. That's a good suggestion.

What is more ambitious than a programming language I built, just for working on my side projects - https://github.com/grandimam/faz

This feels more like we are moving towards a Bun-like model where tooling becomes a unified runtime experience, handling everything from dependency management, package, linting, type checking and finally execution. To me, merging uv, ruff, and ty seems like a natural organizational step.

My heuristics is that the first 100 users are almost always a distribution problem. If you do not have 100 users using your product extensively, and you see a retention drop there is no way you can conclude anything else.

The reason why I take this approach is that - I have had personal experience building tools that didn't go anywhere, and same tools built by people with some online following gaining good traction. It could simply be a case of anecdotal experience, but distribution has always been harder for the tools I have built.

I had created something along the same lines - a platform for devs to understand Python deeply, and was trying to see if there was a market for such content. The thing that I realised is that even with AI, there has to be distribution available for things like this to gain traction.

> each thread has non-trivial overhead.

Agreed. But I am not proposing a thread-per request model. The model will most likely be a fixed pool of workers, potentially combined with multiple processes, an M x N model.

I also agree that co-routines are cheaper than OS threads if the application itself is mostly waiting for network I/O. My question is what happens the moment the workload isn't purely I/O bound.

Right now, the solution seems to be an escape hatch where CPU-bound work is executed behind a thread-pool - see FastAPI or Starlette for example.

With free-threaded Python, I am interested in whether a framework can instead own that complexity: application code remains synchronous or async-partially (at the main thread).

> Removing GIL has nothing to do with that

It doesn't make network I/O faster, agreed. But, the more interesting consequence of removing the GIL is that with threads we can actually parallelise for CPU-bound Python code which earlier required multi-processor.

> How is it different from Flask or Django

This is probably the most important question. It's still in beta, so a lot of things can change. But simply put that Flask/Django lets one write sync code but do not provide the execution model I am describing. Concurrency is supplied at the server layer - gunicorn workers, etc.

The thesis that I am proposing is a framework runtime where concurrency and parallelism are first-class primitives. Now, that free-threaded makes threads capable of CPU parallelism can the framework own the concurrency and parallelism while application code stays async.

Suki - https://github.com/grandimam/suki

It's something that i built for myself. I am interested in the topic of building expertise, and spend a lot of time reading books. After a certain I realised that I needed resources that was very specific to my use case and current skill level rather than something that was static.

Suki allows me to build that curriculum, and probes progressively to help me build a real mental model.

Thank you. I updated the title. Apologies, it was something I didn't realise.

Why not build it on free-threaded python?

Is there an opensource version of such a tool. I would really like a desktop app and use different models instead of a CLI.

> But you can get the most benefit by structuring your code in a way that forces its correctness to be validated at compile-time

Can you elaborate this more?

Interesting! I wonder how much of this improvement is actually due to Rust. I suspect implementing the same approach in C would produce similar results. The speedup seems hardware-level optimizations than the language itself.

The rewrite itself is amazing, but I don't think folks realise the actual conditions that made it possible. It's not as simple as a company spending ~$160K on tokens.

This was done by someone who has essentially already rewritten Node once. Bun itself is a reimplementation of Node, so the author was walking in knowing exactly what the correct behavior is. And an exhaustive amount of test suite to verifiy the changes?. On top of that, there is a reference from Node and V8 to validate more throughly. So the $160K is simply the price of translating knowledge that already lived in one engineer's head in a newer syntax.

I have always found similarities between programming and filmmaking.

Programmer being the director and the LLM being the entire apparatus upon which the film/software is built. This became evident to me while doing spec-driven development for a few of my projects where I specify the constraints upon which the software should be build, but have limited control over the performance similar to how a director has limited control over an actor's performance.

Nice writeup. If I am reading it right, the core bug was that two independent paths each generated the per-invocation namespace, and the fix was to generate it once and propagate it to the workers. That reads more like an implementation slip than a design failure. The multi-level naming scheme is sound, it just has to be computed in exactly one place.

The part I would actually love more detail on is the agent side. How are you orchestrating agents to fan out the test runs?

I agree with some of reasonings in the article especially around agents write behaviors. However, a large portion of this is a consequence of poorly-defined agent roles, and moving away from building deterministic systems.

> An agent working on a customer analytics task might issue a join across five tables that has never been issued before, hold the connection while it thinks about the result, then issue a completely different follow-up.

Aren't agents simply automated human persona's? Like, why would an Agent make a join across five tables given that its reasoning is grounded on human-aligned decisions. For eg.

If the agent knows the schema, and is aware of the indexes defined. Then, shouldn't it only work its way through those 'known paths'. Why would you allow the agents to deviate known paths?

This is good. Its well positioned for software engineers to understand DL stuff beyond the frameworks.

> Then came the pricing. The last quote I got for one of the tools on the market was $6,000/year for a team of 16 people in a use-it-or-loose-it way. For a tool we use maybe 2–3 times per sprint.

What tool was this?

Would you recommend using these large models for parsing sensitive data - probably say bank statements etc?

I could be wrong, but the idea of ending backend and front end reactivity (or sync) is not a good idea. As far as I understand FE reactivity occurs when there is an action but the backend reactivity doesn’t require an action there could be backend jobs that sync state between two components.

Can you elaborate more on the data-parallel computing part?

No, I am not personally aware of anyone using it prod.

I enjoy building frameworks and libraries for fun, so kudos to you for that. At first glance, BlackSheep seems to combine the aspects of Flask, Django, and FastAPI. However, I’m a bit skeptical about its ability to coexist alongside them. The one feature I believe could drive the success of the next Python framework is the ability to operate in nogil mode.

I hope you find it useful. Please do let me know your suggestions or feedback.

Yes, that annoys me as well. Will take note of your app related suggestion. Thanks a lot.

is the company still active?

How is the no-gil performance compared to other languages like - javascript (nodejs), go, rust, and even java? If it's bearable then I believe there is enormous value that could be generated instead of spending time porting to other languages.

Interesting! I was wondering why the author choose Python + Django on the server-side when they could have just used TS + React + NextJS across the stack? On reason is that the author is relying on Celery for background jobs, but is there any performance reasoning for having a completely different backend stack.