3 ms·

I concede that I mostly work on web applications that don't require that level of performance. You're certainly right, there IS a performance difference, and i

I concede that I mostly work on web applications that don't require that level of performance. You're certainly right, there IS a performance difference, and in high-computing workloads, such as the one this parser is used for. From a "regular" web developer perspective (ie. where you only a few servers/VPS's MAX) a lot of newcomers often worry about performance, and usually for most web development the answer with performance is "Yes language [here] is faster then Python/Javascript/Ruby/etc. But those languages/frameworks allow us to develop our application far faster, and ~10ms isn't an issue." Only after performance bottlenecks are discovered would we consider breaking out pieces into a lower level language. You're completely right though, in HPC it is totally worth worrying about every millisecond, I took the wrong perspective with the implications of the performance differences.

davismwfl 7y ago
To be fair, most people do not work on applications that need that level of performance. Most of the time, and to your point, that level of performance isn't necessary so using a language that is less likely to let you take your foot off is generally the best & most correct choice. I only resort back to C/C++ when I need the pure raw performance like this parser would, or when doing embedded work. Otherwise I reach for other tools in the tool-bag that are less likely to let me maim myself unintentionally.