The Economic of Programming Languages

And why I insist on developing Goby

Stan Lo
Stan Lo
Jul 30, 2017 · 3 min read

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 Elixir did.

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.

Above points are the reason I still develop Goby in full time. But I’m still wondering if developers would choose it. We can only know that after Goby’s first release and my talk at RubyKaigi.

goby-lang

This is the official blog of Goby programming language

Stan Lo

Written by

Stan Lo

Creator of Goby language(https://github.com/goby-lang/goby), also a Rails/Ruby developer. Love open source, cats and boxing.

goby-lang

goby-lang

This is the official blog of Goby programming language