New Bun APIs S3 And PostgreSQL: The Future of Programming Languages
With the latest update Bun introduces API for interacting with S3 and PostgreSQL. Some people are unhappy about the update, stating that depending on a vendor specific API on the runtime level should be avoided, as it can break in the future. Another viewpoint is that S3 API is long standing and many vendors support this API and it is very unlikely to change.
Well here is my opinion from a different perspective.
Understanding Language Evolution
Programming languages are - as the name hints - languages. They are not exactly like human languages, but still.
From an information theory point of view, languages can be considered as codes carrying some kind of information. In the case of programming languages, this information is our precious programs.
Programming languages are still very young. C language has been around since 1972, that makes it 53 years old. There are people older than the C language.
Luckily, human languages are for a very long time. Studies about human languages - with a lot of data to work on - can shine light into the future of programming languages.
Human Languages Trade Off Complexity Against Efficiency
- Languages balance structural complexity against communicative efficiency
- Complex languages encode information more efficiently, meaning they need fewer symbols to convey the same message
- Languages spoken by larger populations are more complex
Side Note
These findings are contraversial to the previous beliefs about the languages, and considered modern in that aspect. Previously, it was theoritized that languages have similar complexity, and wide adoption of a language resulted in language becoming more simpler.
Assuming the findings of this research are correct, I expect to see the same patterns in programming languages, too. Which brings us to the latest Bun update.
What Does New Bun API Tell Us About Evolution of Programming Languages
According to the 2024 Stack Overflow Survey, JavaScript is the most widely used programming language amongst professional developers.
So, I would expect JavaScript to become more complex compared to other programming languages in the long run. As we mentioned before, programming languages are still very young, and we are lucky to witness some of the early days of this evolution taking progress.
The Bun API is just a single example that I've chosen as it is one of the most obvious and recent example. Evolution towards a more complex but efficient language is happening constantly in JavaScript, and even Python ecosystem.
Another recent example could be JavaScript Signals standard proposal. Or go ahead and check out all the major changes made to the Python between versions.
But What is Complexity and Efficiency
Well, if you are looking for the actual definitions in information theory, I can't give you that. I will give you what I understand.
Complexity is unpredictability of a language.
In the context of programming languages, I would highly correlate complexity with the cognitive load. So, if you need to know a lot of things before understanding what exactly a piece of code achieves, that language can be considered complex.
Take a look at this example:
import { Controller, Get } from '@nestjs/common';
@Controller('cats')
export class CatsController {
@Get()
findAll(): string {
return 'This action returns all cats';
}
}Example controller from NestJS docs
To understand the code above, you need to know how decorators and NestJS framework works. Compare that to the following Go code for the same task:
package cats
import "net/http"
type catsController struct {
}
func (c *catsController) FindAll(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
_, _ = w.Write([]byte("This action returns all cats"))
}
func NewCatsController() *http.ServeMux {
handler := http.NewServeMux()
routes := http.NewServeMux()
controller := &catsController{}
routes.HandleFunc("GET /", controller.FindAll)
/*
pre go1.22
routes.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
switch r.Method {
case "GET":
controller.FindAll(w, r)
default:
w.WriteHeader(http.StatusMethodNotAllowed)
}
})
*/
handler.Handle("/cats", http.StripPrefix("/cats", routes))
return handler
}
You couldn't even specify route method before golang 1.22! That makes Go a simpler language, compared to JavaScript.
Efficiency is the amount of code it takes to express your program. The fewer lines of codes you need to write, the more efficient a programming language is.
It is almost the inverse of complexity. The mentioned research also concludes that Complexity x Efficiency is almost the same across languages. So, human languages are not equally complex but they contain same amount of information. Again, I expect the same outcome in the programming languages.
Conclusion: The Effects of Trade-Off
Complexity X Efficiency = Total Information.
If we write the same program in two different languages, the total information is almost the same. So, one of the trade-offs programming languages face is this, complexity versus efficiency trade-off.
Similar trade-offs exist even amongst programs written in the same language.
Drawing parallels from human languages, we will see:
- Programming languages adopted by larger populations will favor more complexity and more efficient language design
- Conversely, less popular programming languages will favor less complex and less efficient language design
The effects of this trade-off from a developers perspective is this:
- More complex languages are easier to learn but harder to understand / predict ( JavaScript, Python )
- Less complex langauges are harder to learn but easier to understand / predict ( Rust, Zig )
Here the meaning of the word "complex", is a little counter-intuitive to what we are used to in a normal conversation. So, you might also consider complexity as verbosity, i.e. more complex = less verbose, less complex = more verbose.
The Future: Efficiency Wins, But Complexity Follows
The Bun team’s S3 move? A calculated step toward efficiency, banking on the API’s staying power. Whether it becomes a permanent dialect or a forgotten slang depends on how well it balances the complexity-efficiency trade-off—a dance as old as language itself.