Hacker News Reader

Comment by bilekas | Hacker News Reader

> but i do like how nim programs consistently have few lines of code than the same program in really most other languages which seems like a good thing

Interesting take.. I could share some codeGolf languages that you might like to play with in that case!

That said there are a few fallacies in the comments also that bother me a bit. Specifically the assumption that 'once its closer to C its automatically more performant.'

Wild comments too like : `Nim runs on many more platforms than C#`

Without being specific this claim is just weird..

> beware though that usually the people who wrote the benchmarks might not be experts on Nim

So you need to be an expert to benchmark it.. Red flag.

View on HN

I didn't get why fewer lines of code is better. I don't choose rust because its "shorter", far from it, if anything I choose rust because its very verbose with its syntax, but that syntax conveys a lot of information.

Another comment in the above thread mentioned that "c-like performance is easily reachable with c2nim, or inline assembly" well then thats not really the performance of nim is it, thats the performance of assembly ...

> I didn't get why fewer lines of code is better.

There have been a few studies showing that bugs-per-line-of-code is pretty consistent from language to language. So, if you can reduce the number of lines needed, you reduce the number of bugs.

There are also surely diminishing returns

I'd bet rust is an outlier in that, a lot of languages require more code to do the same things, as a result of being simpler langs (lua). a lot of langs are very easy to shoot yourself with, more lines means more oppurtinity to shoot yourself.

In rust though, that 30 line python script probably takes 45 lines to write now. But those 15 lines aren't wasted or because of longer logic, rather those lines are used to convey type information

its not "more lines = more bugs" as it is "most languages don't put more lines to good use"

I would find it easier to believe if 1. there was a sample, 2. you claimed that the extra 15 lines are just {} indentation. Btw here is the same build script in nim https://github.com/planetis-m/raylib-game-template/blob/mast... and in python https://gist.github.com/planetis-m/a437db724185215910a59c3b3... Which is shorter/more readable?

Note I could have used f-strings for both, I just don't like how they are rendered in my editor.

Correlation is not causation.

E.g. more cells means more cancer per 100k cells, right? Incorrect. Different species have different rates of cancer.

This is a pretty dumb/blunt justification, but there is _some_ truth to it: The number of bugs in a program correlates roughly to the number of lines in that program, irrespective of language. Ergo, if some language lets you accomplish your goal in 30% fewer lines, you will have 30% fewer bugs.

The huge caveats are at a minimum that you're writing the code idiomatically (ie not putting your entire program on a single line), that it also strongly depends on developer proficiency with the language (likely lower for a newer language like nim), whether the problem you're solving is well understood, etc

There is a lot of data showing less lines of codes correlates with less bugs. I don't know if that works cross languages, like a language that requires annotations to help ensure correctness requires more lines thus does it correlate with fewer bugs than python? don't know.

but nim and C# have similar levels of safety

Not an expert, but your comparisons need to be apples-to-apples. An expert-tuned C# impl v a naive Nim impl isn't a good benchmark.

If I'm benchmarking (not perf testing) a language with some nuances I'm not too familiar with, I would stick some simple implementations of core workings. If those simple tasks are `supposed` to be done a `special` way, then I'm already not interested.

Why should I need to learn semi-workarounds just to achieve the basics.

How many algorithms don't benefit from optimisations you think?

Of course, but this is not the point of a benchmark test though - Mainly because as above you want that Apples to Apples comparison.

I think I might not have explained my position too well.

You can write fast or slow code in any language, typically people who understand the language very well are the ones who can write performant code, regardless of language. All those benchmark games out there for dozens of languages are proof of that.

Reply on news.ycombinator.com