写服务器端程序(业务)的同学或多或少都接触不止一门编程语言，大体上分为编译型和解释型，直观感受上来讲，解释型往往注重语言本身的表达力，一方面减少代码量，另一方面提高代码的可读性。举个例子，ruby 有个著名的用于测试的库叫 rspec，示例代码：
class HelloWorld
def say_hello
'Hello World!'
end
end
describe HelloWorld do
context 'When testing the HelloWorld class' do
it "should say 'Hello World' when we call the say_hello method" do
hw = HelloWorld.new
message = hw.say_hello
expect(message).to eq "Hello World!"
end
end
end
我们可以看到 describe, context, it, expect, to, eq 作为方法名，在语言层面的支持(ruby支持方法调用不加括号)下，将代码的可读性大大提高，单看这句 expect(message).to eq "Hello World!"，就是不懂程序的人，也能猜到它想要表达是：期望 message 是 "Hello World!"。再来看看Go语言版本的测试库，示例如下：
var _ = Describe("Book", func() {
var (
longBook Book
shortBook Book
)
BeforeEach(func() {
longBook = Book{
Title: "Les Miserables",
Author: "Victor Hugo",
Pages: 1488,
}
shortBook = Book{
Title: "Fox In Socks",
Author: "Dr. Seuss",
Pages: 24,
}
})
Describe("Categorizing book length", func() {
Context("With more than 300 pages", func() {
It("should be a novel", func() {
Expect(longBook.CategoryByLength()).To(Equal("NOVEL"))
})
})
Context("With fewer than 300 pages", func() {
It("should be a short story", func() {
Expect(shortBook.CategoryByLength()).To(Equal("SHORT STORY"))
})
})
})
})
对比明显，由于Go语言本身的表现力不足(当然也叫极简)，比 rspec 的版本多了很多括号和 func 关键字，虽然仔细看其实差不都，但可读性真是不在一个数量级上。
说完表现力，我们再来谈谈性能。解释型语言绝大部分情况下在性能方面要落后编译型语言很多，当然这么比本身太过钻牛角尖，解释性语言由于设计之初就是要方便程序员表达大脑中的逻辑，同时提供语言运行时的便捷API，有得必有失，必然要舍弃一部分性能。而编译型语言由于对编译速度和硬件掌控度有更高的要求，所以需要舍弃很多语法糖，甚至还要提供更靠近硬件的接口以方便程序做针对性性能优化。
看来，“世界上本来就没有完美的事情” 这道理也适用在这里。那么我们该如何选择呢？这就是一个平衡的问题(假设对不同语言的熟悉程度相同)：
需要快速迭代的新项目可以选择解释性语言，一方面代码量少，另一方面相关的框架(PHP/Laravel Ruby/Rails Python/Django)在项目前期可以帮我们省很多时间。
对于已经梳理清晰业务的新项目，在时间比较宽裕条件下，那我们完全可以用编译型语言，虽然写起来更繁琐一些，但是项目复杂到一定程度，你会发现代码的可读性与代码的魔法程度成反比，换句话说多少代码是要猜的。
如果业务有比较多的计算，无疑用编译型语言做针对性优化更为合适。
如果业务变化非常频繁或者业务逻辑本身就是不断变化的，那么用编译型语言就会显得比较笨拙，而且你会发现你的时间都用在编译上了。时间充裕的话完全可以做一个简单的DSL，rspec 就是个很好的例子。
