3 ms·
I only have experience in dynamic languages. I don't get the point of the article? Is the article implying type coercion is bad because its inefficient in terms
by joshribakoff 11y ago
I only have experience in dynamic languages. I don't get the point of the article? Is the article implying type coercion is bad because its inefficient in terms of CPU cycles? In a decade of programming in dynamic languages, I've never had string comparison be a bottleneck. It is usually IO that is the bottleneck, and the trade off is that by using dynamic languages like JS it becomes easy to make your IO non blocking. If you really have some logic that needs to compare millions of strings, you could always write that algorithm in a static compiled language, and shell out to it from your dynamic language.
- dragonwriter 11y ago> I don't get the point of the article? The point -- as is often the case -- is precisely stated at the end of the article: "What this boils down to is that when we approach any of these server dynamic languages to optimize, we can't employ the same tried-and-true techniques we have used for decades (literally) in C, C++ and Java. We need creativity mixed with discipline to make a difference here." Its not making a point of bad or good. Its discussing the features of the languages that make optimizing them challenging.
- MichaelGG 11y agoWhat's so special about JS's dynamic side that makes async IO easy? Any functional language should be able to do so. And even better than JS, as they may have syntax to avoid all those nested callbacks, while still flowing the environment/error handling. In fact, JS doesn't seem to have anything that's specifically suited for async IO at all, apart from clumsy closures. Also, string handling can often be a bottleneck. Anything dealing with HTTP the protocol, for instance, will have all sorts of crazy hacks to parse that messed-up text format as fast as possible. (And this is a major reason why HTTP/2 isn't text-based.)