Hacker News Reader

Comment by stiray | Hacker News Reader

I love it!!!

It is a great parody on latest trends in "my favorite xy language is faster than 'c/c++", each time I see one of those, it sends shivers down my spine.

Your language, that was made in c/c++, can hardly be faster than the language it was written in. Whatever optimizations it has, you can still make them in c/c++ with enough knowlidge, but probably you can optimize it some more (staring at c++ template metaprogramming) or use __asm or execute opcodes directly (cheating :D) The only question here is how good can the "compiler" be in making optimal cpu instructions from "your" language.

Stop this evangelist wars, your language can be great due to some other features (ease of use, knowlidge needed to be proficient in it, forgiveness of mistakes,..), you dont need to compare it to c/c++. It just doesnt make any sense.

View on HN

"Your language, that was made in c/c++..."

What's funny is that C was initially written in B, and C smoked the living hell out of that language. As it turns out, the speed of compiled code and the running time performance of compilation is two drastically different things.

If C++ was a runtime language it would be slower than a checkout line at Walmart filled with grandma's trying to get in the last bit of Christmas shopping after all of them had just found out their kids are finally going to come out and bring their grand babies to visit for the first time after all these years.

In other words, the way you measure speed and the way I measure speed are to different things. If you had to account for the time it took to grow food back in the old days when accounting for how long it takes you to make dinner, you could say that standing behind a line of grandmas is way quicker.

But both realities are not only mutually exclusive but if you were to ask me; one of those two situations is more gratifying and the other is absolutely aggravating.

Waiting on C++ to compile feels like waiting on a line of grandmas at walmart just so I can get something to eat.

> Your language, that was made in c/c++, can hardly be faster than the language it was written in

What if the language you wrote includes a run-time that does JIT?

and the JIT is written in...

I am bemused by C and C++ fanatics who simply do not and apparently can not see beyond C and C++. Like it is impossible for society to surpass those languages, and that everyone will use them a million years from now...

We will obviously still have them for a while, but anyone that thinks we have reached maturity in an industry that is around 50 years old is just not thinking objectively.

The JIT compiler is written in C.

Its output is assembly code.

That assembly code can outperform code written in C, because it has access to dynamic run time information that your C compiler does not.

This would be "equivalent" but as jit has to process it first (overhead) and code here is just executing binary code, it will be faster. I am not talking here about readability, how much knowlidge is behind etc.

#include <unistd.h> char code[] = "\x01\xb8\x00\x00\xbb\x00\x00\x2a\x00\x00\x80\xcd\x00";

int main(int argc, char argv) { int (func)(); func = (int ()()) code; (int)(*func)();

return 0; }

This whole sharade of how fast the language is a nonsense. There are other metrics that are more important TODAY, the industry needs languages that are maintainable, can be used by cheap workforce that is simple to find anywhere and dont need to know much about computers, memory,... but rather about a problem. Why picking on c/c++ which is not solving any of those problems is such a trendy topic today, is beyond my understanding.

> code here is just executing binary code, it will be faster

No it won't. JIT-ed code can take into account dynamic information, and therefore outperform even the best general static compiler.

I have written the (bogus) code in assembler and executed it using C, there is nothing compiled about it. Without any dynamic information as there is nothing dynamic about it. There is nothing to outperform/optimize it will run at max speed on specific architecture. Compiler is only involved to do a 'call'. Same as with JIT. But hand optimized.

Let me repeat it, stop this stupid evangelist wars. They are nonsense. Who cares about C speed when the lasagna with spaghetti frameworks are run on daily bases. Speed is irelevant today for almost all cases as no one is prepared to pay for it. And nobody cares about those left.

> Your language, that was made in c/c++, can hardly be faster than the language it was written in.

It doesn't work that way.

> Stop this evangelist wars, your language can be great due to some other features (ease of use, knowlidge needed to be proficient in it, forgiveness of mistakes,..), you dont need to compare it to c/c++. It just doesnt make any sense.

What if the purpose of the language is exactly to be faster than reasonably written C? Then a comparison makes sense.

Also, I have written a language that is "faster than C" in a certain naive sense, and it was not written in C. It does generate C, but not the kind of C sane humans like to write.

That does not mean those wc comparisons are indicative of real performance, though. They are just meant as provocative ways to get attention.

>Your language, that was made in c/c++, can hardly be faster than the language it was written in.

You're making the mistake of associating the performance of a program to be purely be a product of the language. It is not difficult to write inefficient code in any language.

> The only question here is how good can the "compiler" be in making optimal cpu instructions from "your" language.

> Stop this evangelist wars.

I think if there is any need for a war at all, then it should be between compilers not languages.

Reply on news.ycombinator.com