3 ms·

Personally, the first thing I look at when I look into a new server side language is how it does in benchmarks conpared to other similar languages (such as the

Personally, the first thing I look at when I look into a new server side language is how it does in benchmarks conpared to other similar languages (such as the TechEmpower benchmarks). I know that those types of benchmarks are flawed in a lot of ways, but performance is probably the only objective way to evaluate a language, and I’m much more likely to learn about a language if it looks like it’s fast. From what I’ve seen for Jester/Nim, it’s not really benchmarked a lot, and it doesn’t seem particularly fast where it is benchmarked. This could perhaps be fixed by better implementations for the benchmarks or some optimization in Jester itself. I think a strong story for performance would go a long way towards improving awareness of Nim. Crystal does very well in such tests, and I think that is one of the most appealing parts of the language. In fact, I evaluated both Nim and Crystal for server side development a while back, and quickly dismissed Nim because it didn’t seem to be all that fast. I eventually dismissed Crystal too because of the compile times and syntax, but I put a lot more time into it.

dom96 8y ago
I would say that you should look at the language's theoretical performance as much as its actual performance. A lot of these benchmarks are just a result of someone putting in a lot of time tweaking things until they are perfectly suited to the specific benchmark, in real-life you will get nowhere near that. Additionally, you won't actually need to get anywhere near it. If you do, then you will have the time to tweak things and get to know the language inside out. In that case, all that will matter is the theoretical performance of that language. So what do I mean by theoretical performance? Well, Nim is a statically typed and compiled language, it stands to reason that these attributes make it very performant indeed. Even if certain aspects of the language are not efficient right now, you can bet that it will be fairly trivial to improve their performance. For languages like Python, Ruby, etc. you are heavily limited by the dynamic typing (which restricts the amount of information you have about the code) and the fact that they are primarily interpreted languages. You will need to put far more effort into optimising them than compiled languages. As a side note, I do intend to improve the performance of Jester as well. But I'm not the only one doing this, the mofuw framework is #24 on the TechEmpower benchmarks right now.[1] 1 - https://twitter.com/nim_lang/status/1004849910699712513 https://twitter.com/nim_lang/status/1004849910699712513
- brokencode 8y ago
  It’s not enough to have good “theoretical” performance when other languages already have measurably good performance today. I’m not trying to say that Nim is bad or slow, but when there are a dozen similar static, compiled languages to choose from, it’s easy to dismiss one based purely on the benchmarks alone. I understand that it’s sort of an optimization game with these benchmarks, but it’s at least a form of marketing, which is something that Nim can benefit from.
nimmer 8y ago
> I know that those types of benchmarks are flawed in a lot of ways If the speed of an HTTP framework impacts your application you have an architecture problem. Nim CPU, memory and compile time performance are excellent in most benchmark.

dom96 8y ago

I would say that you should look at the language's theoretical performance as much as its actual performance. A lot of these benchmarks are just a result of someone putting in a lot of time tweaking things until they are perfectly suited to the specific benchmark, in real-life you will get nowhere near that. Additionally, you won't actually need to get anywhere near it. If you do, then you will have the time to tweak things and get to know the language inside out. In that case, all that will matter is the theoretical performance of that language. So what do I mean by theoretical performance? Well, Nim is a statically typed and compiled language, it stands to reason that these attributes make it very performant indeed. Even if certain aspects of the language are not efficient right now, you can bet that it will be fairly trivial to improve their performance. For languages like Python, Ruby, etc. you are heavily limited by the dynamic typing (which restricts the amount of information you have about the code) and the fact that they are primarily interpreted languages. You will need to put far more effort into optimising them than compiled languages. As a side note, I do intend to improve the performance of Jester as well. But I'm not the only one doing this, the mofuw framework is #24 on the TechEmpower benchmarks right now.[1] 1 - https://twitter.com/nim_lang/status/1004849910699712513 https://twitter.com/nim_lang/status/1004849910699712513

brokencode 8y ago
It’s not enough to have good “theoretical” performance when other languages already have measurably good performance today. I’m not trying to say that Nim is bad or slow, but when there are a dozen similar static, compiled languages to choose from, it’s easy to dismiss one based purely on the benchmarks alone. I understand that it’s sort of an optimization game with these benchmarks, but it’s at least a form of marketing, which is something that Nim can benefit from.

nimmer 8y ago

> I know that those types of benchmarks are flawed in a lot of ways If the speed of an HTTP framework impacts your application you have an architecture problem. Nim CPU, memory and compile time performance are excellent in most benchmark.