Almost Same Concept, Just Different Implemenations

It’s always interesting to connect the dots. Let me give you some tech examples where the “concept” is the same but the “implemenation” is different

For example, same programming language, but different runtimes and compilers for it. For example, JavaScript on the backend has multiple runtimes now - there’s Node.js , there’s Deno , there’s Bun. For JavaScript on the frontend too there are mutliple runtimes now - there’s SpiderMonkey (popular in Mozilla browsers), there’s V8 (popular in Chrome/Chromium browsers), there’s WebKit (popular in Safari browsers). Same / similar / mostly similar features, but different implementations. Mind you, these are very complex softwares we are talking about. No one has to rewrite them unless they simply want to or they are just so interested in it or maybe they have a very strong reason to and that they think they can do better or do something differently - maybe for different use cases etc

Another example I would like to bring up is - LSP - Language Server Protocol - where someone got this idea to make it a standard on how someone integrates language plugins into editors and IDEs - they said, we will have one language server for one language - which serves all the needs of language plugins in different editors and IDEs. The user will have to run the language server and then any client that understands language server protocol and understands the language can use the language server and provide features in an IDE. So, people just have to build basic language server protocol client(s) for different editors and IDEs and that’s it - they don’t have to reimplement the logic of different features of a language server into each of the plugins - for each language and editor/IDE combination - that would be a lot of implemenations and also hard to maintain. Some examples of language server features could be - find definition of keyword, find references of keyword etc, where keyword can be a variable, function, method, type etc. So, they pulled the language features required for editors and IDEs out of process - out of the plugin’s process and used network and common protocol and pushed the features to a server. This is similar to how HTTP is so ubiquitous - HTTP server written in one language and HTTP clients written in so many languages. It’s useful when different languages are needed. For example, in the case of editors and IDEs, each editor and IDE will have it’s own way of doing things and having plugins and how plugins are built, installed and used - maybe each editor and IDE defines their own programming language for the plugin, unless they decide to get the plugin as a binary and define an API for interacting with the plugin. For example, Terraform Custom Providers, basically plugins that plug into Terraform, are all binaries and can be written in any language - so that’s a big win! Now, why do I bring up LSP? Well, similar to LSP concept, there’s MCP - Model Context Protocol, but it’s in a different context and hence a different implementation, where there are MCP servers to mediate between AI models and tools/services, similar to how LSP and Language servers are there to mediate between a editor or IDE plugin and a language. This is so that not everyone has to write a new custom code on both sides (the AI and the tool/service) to integrate them. MCP makes things easier and standardizes things :)

Another popular example of same concept different implemenations - package managers. There are so many package managers for JavaScript. Popular one was npm, then came yarn, then came more! Same for Golang - so many package managers / dependency management tools - there was glide and what not, now, Golang has an official one, but yeah, one can still choose to write and create their own package manager if they want. Now, python also has more than one package manager. It’s not just the official one which is pip, now there’s uv which is a different implementation but with the same features! Interesting, isn’t it? :D

And then there’s the API. HTTP API, or even custom TCP APIs, like Redis API, S3 API etc. And there are many different implementations. So many implementations for Redis Servers by implementing Redis features and also the Redis protocol. Same is true for S3 - there’s minio. Same is true for some softwares that want to replace other popular softwares - either drop in replacement, or be as close and similar to them as possible. For example, there’s Kafka and Redpanda. There’s Redis and there’s Valkey, the fork. There’s Redis and Dragonfly. There’s S3 and Minio

At this point, the conversation has generalized to - one need - but many providers for that need. But, you get the point. What’s the best thing about these? You can learn from all of them. You get to learn from all the different implementations - especially because in many cases the code is all open source, and even otherwise, you get to use them, try them out, read their documentation to understand what they do differently, what are they trying to do and why they made another thing that does the same thing

In a world that says “It’s already done”, “It’s an old idea” etc, you can learn to learn to still create new things that do the same old thing, but a bit differently or in the same way - just because you wanted to :)