The programming language climate and how it’s rapidly changing for developers
- Date:
- Feb 17, 2026
- Length:
- 6 min read
How it used to be
Programming languages have always been a core part of any developer’s daily, productive life. But there wasn’t always much choice. The nature of computer hardware and the complexity of creating a simple application back in the 80s or 90s was inherently frictive, and because of that, developers were more focused on getting the thing to work, rather than losing sleep over the novelty of a new programming language. Everyone just used C, and that was it. It could do almost anything, and it didn’t put much distance between you and the hardware. Many saw it as the sweet spot.
How it began to change
Programming languages have come a long way since. C++ came out in the late 80s, boasting a far more abstraction-heavy featureset, but also one that required developers to learn more syntactical knowledge in order to begin building applications, to be fully capable with the language.
We then moved into the 90s, and other languages began to pop up, often influenced by C++, but we also had the functional programming side get a bit more popular, too. How we could build applications started to grow exponentially. We had to spend more time learning a multitude of languages or tools before we could make accurate decisions on what to use for a particular use case.
How’s it going
Fast forward to today, and that increase in developer choice, languages, tools, methodologies, and so on is becoming quite overwhelming. The amount of knowledge a developer needs has undoubtedly moved from that of understanding the hardware to understanding tools and design paradigms. AI is another good example of this.
This is also reflected by the huge influx of promising languages to come out lately. Languages that have taken all of the things we’ve learned, combined them into a mishmash of reused ideas, and tried to take away that need for understanding the hardware even further. Which languages? Let’s list some of them.
1. Javascript/Typescript, what we use.
JavaScript is a weird one. It’s become one of the most popular languages in existence, and yet it started as a language only used for Web browsers. If you’d told C developers that it was going to become the predominant language for both backend and frontend development, they’d have scoffed and called you crazy.
And yet, here we are. JavaScript is one of the easiest languages to learn, and yet also one of the fastest garbage-collected languages and most powerful, cohesive ecosystems in the development space. It can create desktop applications, web applications, server backends, games, or even operating systems. Windows has been found to be using JavaScript to render elements of its desktop, such as the start menu in Windows 11. It’s become as popular as C was in the 80s/90s.
It has undoubtedly reduced the amount of developer experience one needs to create an application, and with how easy the language is, it makes AI assistance even better, as AI can also understand it more easily. There are a huge number of reasons to favor Javascript. TypeScript rocketed JavaScript into the stratosphere by making the language more appealing to experienced developers who want more expressive code.
2. Rust
Another big one is Rust. It’s revolutionised the landscape exactly because it embraces this mindset. The language’s entire model focuses on making sure the developer doesn’t have to worry about the mechanisms of memory directly. There are abstractions, ways in which the language has been designed, that allow a developer to think of memory management in a more game-like way.
It’s not how memory actually works, but it creates a system that makes it more understandable and manageable. The language is also a huge mix of ideas drawn from other areas, with a tremendous amount of functional programming influence, including lots of callback handling and other features.
3. Golang
Go (called “Golang” sometimes) is a language that entirely focuses on performance and developer productivity due to simplicity over complexity. It has a lot of similarities with JavaScript in this regard.
It’s a garbage-collected language, so it will be slower than, say, Rust or C, but because of that, it doesn’t need a complex abstraction for managing memory. You just do the thing, and let the garbage collector do the hard work of cleanup.
In a more performance-intensive environment, this isn’t necessarily always the case, and you will have to have some understanding as to when the garbage collection is triggered during the runtime of your application to ensure that you don’t have unwanted pauses in your application (you can read up on a case of this here - https://discord.com/blog/why-discord-is-switching-from-go-to-rust), but it’s one of the easiest languages to code in.
Having such a fast language but still being able to code with so little friction makes Go a good example of this movement into the future, where we abstract away the hardware-specific implementations more and more.
4. Mojo
Mojo is seen as a spiritual successor to Python, which, in itself, has already simplified and revolutionised programming. Mojo is also trying to champion the AI space like Python has, with the hope of simplifying and improving the ease with which we can program a GPU for use with AI.
But Mojo is also going the Rust route in terms of how it’s creating a simplified abstraction for use with managing memory. No longer do you think of memory as something that requires explicit cleanup or allocation. You just put a little character next to the variable, and now, you have a pointer, or resource that you can access but not mutate, or whatever it may be.
No more worrying about memory in a chore-like way. Languages like Rust and Mojo are invariably an indication of things to come. A way to find a good combination of performance and developer productivity. A way to add some distance between the developer and the hardware, so that they can focus on getting things done, rather than focus on superfluous implementation details.
There are negatives to this, though, so don’t think I’m entirely in either camp, the two camps being performant programming versus efficient/high velocity programming.
Conclusion
I don’t claim to know whether this trajectory is a good one, but it’s exciting to watch how programming languages are heading into a new era of sorts. C will slowly become more of a hardware-focused developer’s field, and other developers will use more abstracted languages to build things more quickly or to have more expressive code.
This can result in a great increase in energy expenditure due to not using faster, more optimised, hardware-aware languages or tools, but with such a demand for apps and Websites these days, there’s no doubt that it’s unavoidable.
What this results in, who knows? But I’m loving it.
Why? Maybe we’ll cover that in the next part.