Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Wow, this guys knowledge is wrong.

Dynamic languages can be faster than C now, and are only improving. Implementations like pypy, and luajit2 really are rocking. JavaScript implementations are also getting real fast.

C++ doesn't need to use manual memory management, and hasn't for ages. You can use it, but it is optional. Perl was often mixed with C/C++ libraries, including mod_perl with apache - the real webserver written in C.

With WebGL there is coming a massive amount of GPU power available to apps from JavaScript. Which also has available WebWorkers, which allow multi core use. As well, as vector instructions. The speed available for processing is truly amazing.

There's just too much wrong in this article, so I'll just stop writing about it now. Usually I enjoy his articles, but this one is way off. On the other hand, maybe it is just a really good troll?



> Dynamic languages can be faster than C now, and are only improving.

You're a bit too enthusiastic here, imo. JIT compiled code can in theory outperform AOT compiled code because of dynamic recompilation of hot code paths. However, you can get some of the benefits of runtime code generation via profile-guided and link-time optimizations without any runtime overhead.

In practice, no dynamic language is faster than C (AOT compilation), and they rarely approach Java (AOT compilation to bytecode + JIT compilation to native code) where raw performance is concerned.


Yes, for many workloads C/C++ is faster, and often lots faster. However, we are now close with dynamic languages for some workloads.

Dynamically typed languages are doing AOT compilation and also starting to get very good type inference, such that code is getting similar to C++ speeds. See the 'shedskin' rpython to C++ compiler, and the latest firefox JavaScript type inference work. PyPy has shown faster than C speeds for certain workloads. Also, the luajit2 project has shown faster than C speeds for certain workloads. This comes from being able to do full program optimisations at runtime over module boundaries which is not possible in C/C++.

C/C++ compilation is still much more advanced and faster in certain areas. Especially with auto vectorising, and a vast array of research and resources put into it that is far ahead of dynamic language developments.

cheers,


That was my view yesterday. Then I benchmarked some JavaScript (CoffeeScript) code, and the same algo in C code and my world changed. I know that I could have optimized my C code better (I don't think I even turned optimization on), but I could have optimized my JavaScript better too.


That seems like a very small and somewhat flawed data point to be drawing any conclusions from.


One of the things that hampers C is its string processing. By using a nul terminator, rather than an out of band length indicator (a la Pascal, Perl, Java) many string operations become a O(n) operation, where n = length of string, rather than a O(1). When running things such as cobbling up HTML templates and prepared SQL statements or evaluating DSLs, sucky string handling really starts to matter. Some would argue that it matters more than how fast you can calculate prime numbers or fibonacci sequences.

I've ranted about this before: http://roboprogs.com/devel/2009.12.html


> One of the things that hampers C is its string processing.

That's not a language, but a library issue. String handling in C is only as sucky as the library you're using...


Kind of bound to the semantics, though.

E.g. -

memset( s, '\0', sizeof( s) );

s[ 0 ] = '\0';

You can of course create a library (e.g. https://github.com/roboprog/buzzard/blob/master/bzrt/src/bzr...) to support alternate implementations (as interpreters and VMs created in C must), but it's not really much like ANSI C anymore.


Big difference here between these two, check out a copy of "Deep C Secrets" by Peter van der Linden.

This is ok, safe, complete, reliable:

memset( s, '\0', sizeof( s) );

This yields the perception that it works, depending on what is going to make use of s later on, it could fail to do what you intended depending on how you use s:

s[ 0 ] = '\0';




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: