I’m a Rubyist, and just started writing Go several months ago. And at the beginning of learning Go, the most uncomfortable thing for me is that for most of the time, there is only one way to get things done.

For example, if you want to go through each elements in an array, you can only do it using the for keyword:

for _, elem := range elements {
    // Do something
}

In contrast, you can do this using several approaches in Ruby

elements.each do |elem|
  # Do something
end

i = 0

while i < elements.length do
  elem = elements[i]
  # Do something
  i += 1
end

for elem in elements do
  # Do something
end

And I think most Rubyists will agree that using the first approach is the best practice for going through each elements in an array.

So here comes the keyword: best practice.

This means instead of just knowing how to do the task, the programmer should also know how to do it in a right way. But why do we provide so many approaches for doing one job to language users, but tell them to learn and use only one of the them?

If you give programmers too much options to do one thing, they need to learn all those options and remember the best one, which in a sense is increasing the learning cost of the language. Also, the community might spend time arguing about what is the best practice.

Conclusion

So from my perspective, a language should only provide the best practice to its users. Which means there will be no best practice, because there will only be one practice.

This can be done by reducing the types of statements, providing less builtin methods or having an official linter…etc. And this is why we don’t have the for statement in Goby. Because we can, and should only just use Array#each or Range#each if we want to do the task.

No More Best Practices was originally published in goby-lang on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most compilers should remove (or force you to remove) unused expressions, like the i in:

5.times do |i|
  i <- This should be removed
  puts(i)
end

Because if we allow it being pushed on the stack, there’s no way we can remove it from the stack. For example, after the above program finishes, the stack would be like:

  <- Stack pointer
4
3
2
1
0

So it’s just a matter of time the stack would be filled with those unused values.

The solutions

There are two solutions for this issue:

• Ignore those expressions in code generator
• Pop each statement’s return value

Ignore those expressions in code generator

This is the ideal approach for this issue, just skip the generation of those expressions.

But it’s actually more complicated to than that. Some expressions like string literal or boolean literal can be skipped without any hesitation. However, when the expression is an identifier, things get more complicated. If the identifier represents a local variable you should skip it, but if it's a method call you still need to generate the instructions and pop it's return value if needed.

Also, the assign expression and if expression are tricky to handle, too. Their instructions should always be generated, but the result can be different according to whether we need the return value or not. For example, the instructions of:

if a > b
  foo
end

should be:

0 getlocal 0 0
1 getlocal 0 1
2 send > 1
3 branchunless 7 # Jump to leave if it’s false
4 putself
5 send foo 0     # If it’s true we call the method
6 pop            # And pop the return value of method foo
7 leave

But if we assign it to a variable like:

c = if a > b
  foo
end

the instructions would be:

0 getlocal 0 0
1 getlocal 0 1
2 send > 1
3 branchunless 7 # Returns nil if false
4 putself
5 send foo 0     # Call foo but not popping its return value
6 jump 8         # Skip the nil value
7 putnil         
8 setlocal 0 2
9 leave

For setting local c, we need to make the if statement change to if expression. To do this we need to the result of foo method call and put an extra nil and the corresponding jump for false case.

So even though this solution is the better one but implementing it can be time consuming.

Pop statement’s return value

This is a relatively naive approach. We should prevent those value being push on the stack at first place instead of pushing them and then popping them.

But this is what Goby currently using because it’s easier to implement. We just need to literally pop every statement’s return value by default, and mark a few exceptions like the last statement in method body or the last statement in block argument to keep their value.

Make sure the stack is clean

Since keeping the stack clean is so important, we check the SP’s value (which should always be 1)after every test program’s execution. Currently our naive approach works quite well.

Note: The SP should be 1 instead of is0 because the stack should keep the last value of execution for comparing the result. This only happens when parser and code generator is in Test mode.

Keep the stack clean was originally published in goby-lang on Medium, where people are continuing the conversation by highlighting and responding to this story.

Statements are declarations that can make up a line (or multiple lines). And expressions are operations which will return values. So expressions are also a kind of statements.

Commonly seen statements are:

• variable assignment
• return statement
• flow control keywords like break, continue
• for loop
• switch statement
• while loop
• if statement

And common expressions are:

• built in data types 1, "foo", true, null, [1, 2, 3]
• objects
• function call like add(1, 2)
• variable like foo
• arithmetic operation like 1 + 1 * 2
• comparison like a == b, a > c
• self keyword in some languages
• yield in Ruby

So how do they compose a program? Let’s see an example:

i = 0
while i < 10 do
  i = i + 1
end
i

And it’s structure is

Statement(assign statement) { i = Expression(integer literal expression) [0] }

Statement(while loop statement) { 
  while Expression(comparison expression) [i < 10]  do
    Statement(assign statement) { i = Expression(arithmetic expression) [i + 0]
    }
  end
}

Statement(assign statement) { Expression(variable expression) [i] }

But in Ruby, things get more trickier

In Ruby, sometimes statements can also be expressions under certain conditions, for example:

assignment statement

In a = a = b, the first assignment a = b is an expression and returns value of b. But a = a = b itself it's a statement, not an expression.

if statement

a = if b > c
      10
    end
puts(a) #=> 10

Whether these statements would change into expressions are determined by one thing: where are they placed.

Let’s take assign statement as example, it’s structure looks like this:

Variable = EXPRESSION

On the lefthand side of = is the variable we are assigning value to. And the righthand side of = must be an expression so we can have a value to assign.

Under this condition whatever statement you put in the righthand side would be an expression and returns a value. No matter it’s an assignment statement, if statement or even a class statement.

a = class Foo; end
puts(a) #=> nil

b = a = 10
puts(b) #=> 10

c = if true
      100
    end
puts(c) #=> 100

Similar condition happens when the statement is treated as a function argument:

puts(d = 1000) #=> 1000

What about Goby?

Since Goby is trying to make users feel like they are using Ruby, so we’re trying to port this behavior to Goby. But we only support this kind of Statement -> Expression transition for If Statement and Assign Statement. Because we don’t usually need other statements’ return value. And actually those two statements are considered as expressions by default in Goby.

The Implementation

We do this by using a state machine in parser. When parser start parsing an assignment or a function call, it’ll enter a special state. Under this state the Assign Statement or If Statement would be treat like expression and we can get their return value.

Statements vs Expressions in Ruby was originally published in goby-lang on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

The Economics of Programming Languages was originally published in goby-lang on Medium, where people are continuing the conversation by highlighting and responding to this story.