Member-only story
Its Time for a New Programming Language
Today, when compared to any other point in programming history, we find ourselves spoiled for choice when it comes to programming languages. Advancements in language design, toolkits like LLVM, the democratization of programming via the internet, and a load of other factors have led to a Golden Area of new languages. Each week we see the popularization of a new language like Zig, Deno, Nim, Rust, Flutter, Kotlin, Go, Crystal, Carbon, and many, many others. And yet, when surveying the landscape of what languages are actually used, the list is almost always populated with the Usual Suspects: JavaScript, TypeScript, Python, Java, Ruby, PHP, etc. The reason for this, I think, is that while new languages are always popping up, some with novel design decisions or built-in features, very few of them are “serious” in the sense that they’re designed for serious, production-level workloads and architectures. I don’t want to call them Toy Languages, but I also don’t think we’ll be seeing any serious production services running on Deno or Crystal any time soon.
“But what’s wrong with the Usual Suspects?” you might ask.
And that would be a very good question. Honestly, I don’t think the argument is about what is wrong with them less than it is more about how they fit into today’s architectures and ecosystems and the kinds of work they’re being asked to take on.
JavaScript, TypeScript, NodeJS, CoffeeScript, etc.
JavaScript is the Three Raccoons in a Trenchcoat Pretending to be Human of programming languages. It was never designed to do nearly most of what its doing today and everything that’s been added to it since its inception in 1995 feels like an afterthought. There’s usually three to eight different ways to do anything in JS and all of them have unique side effects and footguns that you don’t know unless you’re a dyed-in-the-wool JS developer. This kabbalah of ancient Deep Magic makes writing effective and performant JavaScript incredibly hard for those not baptized in the waters of the V8 engine. While the idea of using the same language for frontend and backend work sounds like a good idea, in practice the only thing front and back-end have in common is basic syntax and a love for unnecessary 3rd-party NPM packages.
