So, it is an India problem, not a government problem.

In the same way that most public utilities are: train stations, railway lines, airports, garbage dumps, sewage treatment plants, military bases and a hundred other things. The negatives are concentrated to the locality and everyone else reaps the benefits.

I get it if you wish to put a 99% self-sufficiency condition (water/power etc) but everything else reeks of luddism and nimbyism.

Python has a different problem: it is slow as f---. I did a micro benchmark comparison against 5 other languages in preparation for my python replacement language. Outside of dictionary lookups, it is 50-600 times slower than C depending on the workload.

Go, Rust etc are fine. They land at 1.25-3x slower than C. But I prefer the readability of python minus its dynamic nature.

- The base is a freestanding register VM deeply tied to the Linux kernel.

- It supports a set of primitives types, array types and record types.

- Concurrency is Erlang-ish --- an M:N scheduler that can manage tens of thousands of green processes. VM uses instruction fuel to preempt processes.

- GC is Cheney for the nursery + M&S for the rest. Each process has its own GC.

- tailcall support.

- first class functions.

- Phase One will only have Vm0, which is clean (it has access to a bounded set of Linux syscalls). Will think about Vm1 that handles the libc infection later.

- JIT is not on the table in Phase One.

- The language is statically typed and borrows syntax from python extensively, but drops OOP entirely.

- OOP is faked using UFCS.

- Operator overloading is supported.

- Exceptions are the default error handling mechanism. There are two hierarchies: Fault and Error. Fault cannot be trapped without rethrowing. Fault WILL crash the VM.

- It is being developed in private right now. As I am User # 0, all the choices I make reflect my own opinions and biases. I might release the code as OSS once the core is stabilized.

- I have done very basic microbenchmarking and the VM is so much faster than python right now that it is not a fair comparison anymore. I can also create and iterate over massive primitive arrays with ease. The principal comparison should be C, and here it is consistently about 8x slower and that performance profile will probably remain constant because dispatch has a real cost that cannot be magically wished away. I will be very happy with 5/6x.

"ut" (https://github.com/s-i-e-v-e/ut) exists, but it is more of a POC for the syntax more than anything. So lexer+parser+typechecker. Did this during COVID in TypeScript but did not finish.

I cannot do slow. It is either burn the candle at both ends, or do nothing at all.

I am using LLMs this time as well, but I spent close to 400 hours over a period of 6-7 weeks on my project before I put it to the side temporarily (got bored once the thinking part was done). About 300 of those were spent on iterating over the language and VM specs and eliminating all ambiguities and needless features. The remaining 100 were used to produce the code --- the VM, the assembler and the compiler --- and to repeated rewrite it to conform to my way of doing things.

LLMs have let me become extremely choosy about which code I am willing to keep.

Even stuff like Crenshaw's Let's Build a Compiler was more useful to me than all these books that do lexical analysis using regular expressions. I have written lexers and parsers hundreds of times for all kinds of DSLs and config languages and not once have I used regular expressions to scan the text.

Very true. I have a shelf full of books on compiler development and optimization. I have read them selectively, a chapter here, a chapter there. But that shelf is useless for a vast majority of people.

You might find it useful if you are developing a production-level compiler/vm (I cannot make this statement with a straight face while Python rules the world). But a simple and sensible architecture that uses recursive-descent parsing takes you a long way.

Most hobbyist compilers (and even some production ones) are written as a heavy front-end compiling down to C or LLVM. Very few people actually write their own backend.

Syntax is a minor issue but something that people are very opinionated about. You could technically build multiple front ends that share the typechecking, CFG validation, optimization, register allocation and byte code emission phases. But it is too much work for what is presently a personal project.

The lexer/parser is never the bottleneck. In fact, you can write those two by hand over a single weekend for a largish language. With LLMs, it takes 15 minutes if you have an unambiguous spec.

The biggest time sink, and the reason you will fail for sure, is the inability to restrict the scope of the project. You start with a limited feature set and produce the entire compiler/vm toolchain. Then you get greedy and fiddle with the type system, adding features that you have never used and probably never will. And now you have to change every single phase from start to end.

I mostly give up at this stage.

My banks require physical presence for stuff like changing phone numbers and nominees. We get OTPs on our phones, so that makes perfect sense.

All these coding tools are extremely wasteful as far as resources are concerned. Almost designed to make you move to the next tier. You have to consciously restrict their scope all the time to make your plans last. Even with Kimi/MiniMax a 3-4 hour session often ends up with 50-70M cached reads. Not a small amount at all.