The Economic of Programming Languages
And why I insist on developing Goby
The costs of transferring to new language
The main cost of transferring from
A language to
B language for a developer is time. The longer a developer spends on learning the new language, the higher it costs. So normally a new language seeks to avoid excessive syntax or characteristic, to lower the learning cost.
Rebuilding the ecosystem of language is also figured in the cost. In general, the number of early adopters for a new language erupting is not many, and learning resources or libraries for the new adopters are insufficient in most cases. For example, just assume a Rails developer wants to use Goby for his next project. Even if the cost of transferring from
Ruby to Goby is not high, he or she still needs to give up Rails or other powerful libraries, and this will be a big concern for him or her.
The attraction of transferring to new language
But there still are many new languages being created constantly. And many developers also choose to use them despite the costs, why?
The major reason is that the features and the platforms developers using are constantly changing as the technology evolves. Like the invention of smart phone provides new a platform for developers, or the growing web traffic increases the need of highly concurrent programming languages.
Under this condition, new languages can be optimized for certain usage or platform. However, most conventional languages are too big and can’t effort breaking changes, so it’s nearly impossible or will take a lot of time for those languages to fulfill the needs. But developers still need to finish their tasks under time pressure, so they have no choice but to use newer languages to finish the job, or even completely migrate to newer languages.
What about Goby?
The above assumptions are the main reason I keep developing Goby. Choosing Ruby’s syntax and Object system is to reduce the entry cost; using Go as host language is for better concurrency support. So if Goby can bring sufficient improvements in performance (especially for microservices) and won’t cost them too much time to adapt it, it would be easy to attract them transferring to use Goby, just like
Goby’s another opportunity is that there are still no mature frameworks for developing microservice. And due to the language’s design, there’re very few people use Ruby to write microservices. So when it comes to develop microservices, Ruby developers usually need to choose other languages, like
Go. And since Goby is more easier to learn and provides higher efficiency in development than
Go, it should have certain attractions for those them.
At this moment, Goby can already call/use functions or datas in
Go Plugin like:
# p is a plugin object
p = import "./plugins/plugin.go"
# we can call plugin's top level function directly
bar, err = p.send("NewBar", "xyz")
# we can also call Go object/pointer's method
# the 'Add' method's type is 'func(int, int64) int64' so type transition is necessary (but easy to do)
r = bar.send("Add", 10, 100.to_int64)
puts(r) #=> 110
This means in the future Goby developer can use
Go to write their extensions (I think it should be far more easier than writing C), and call those
Go code directly using Goby's friendly syntax. Meanwhile, they can also use Go's libraries in those extensions, which would be very helpful.