71–80 of 107 posts
I would find it hard to believe that c++ can be that much faster for many websites since the bottleneck would be the I/O subsystem. I don't understand how they are getting this 40x speed up. I wonder what the benchmark looks like.
I wonder why the choice of language is framed as being between C++ and Ruby/Python? Yes, C++ is known for being fast while suffering from a shortage of easy libraries and being more verbose to write and intellectually challenging to write in, while the mainstream dynamic languages are known for being not so fast but having a vast array of handy, easy to integrate libraries and being fast to develop in. But I think th…
Go isn't billed as a language that is designed to do that. It's faster than Ruby and Python, for sure, but it made many runtime performance sacrifices in the name of ease of use and compilation speed.
It's sad that you need to justify using one of the most established and longest serving languages/platforms ever.
Indeed, the given strawman alternative languages (Ruby and Python) are far, far worse for productivity. Python changes are totally unreviewable since one cannot in any way reason about the correctness of a function call without reading the definition of the function itself, and all the functions to which it passes the arguments, all the way down, which of course takes forever. At least with C++ you can reason that if…
And with Python you can reason that if code parses it isn't going to have undefined behavior (for example, segfaults randomly thousands of lines away from the actual problem due to heap corruption, or exploitable use-after-free vulnerabilities).
Type safety only has the benefits you describe if the language is actually type safe.
Atomic reference counting does not have minuscule costs. See, for example, http://www.hboehm.info/gc/nonmoving/html/slide_11.html
In particular, note that if you use shared_ptr everywhere you will be end up with much slower code than you would have if you had a good GC. In other words, you end up slower than Java, with less safety and more verbosity.
Browser engines have used custom non-thread-safe reference counted pointers where possible extensively for this reason.
Furthermore, I always have to say it: shared_ptr is not memory safe.
Earlier quoted context omitted.
Indeed, the given strawman alternative languages (Ruby and Python) are far, far worse for productivity. Python changes are totally unreviewable since one cannot in any way reason about the correctness of a function call without reading the definition of the function itself, and all the functions to which it passes the arguments, all the way down, which of course takes forever. At least with C++ you can reason that if…
Ummm, unit tests? The compiler offers a false sense of security. Type safety is not correctness.
I'm more curious as to the decision not to stick with Rust. Sounds like there was a prototype. I'm guessing there were some libraries missing. Would be cool to know more about that.
auto start = std::chrono::system_clock::now();
// benchmark something here
auto end = std::chrono::system_clock::now();
start, end = benchmark do
# benchmark something here
end
Earlier quoted context omitted.
Ummm, unit tests? The compiler offers a false sense of security. Type safety is not correctness.
Not to dredge up this debate for the umpteenth time, but the same can be said of unit tests: they are not a proof of correctness, and they often give you a false sense of security.
I would like to see one other aspect discussed though: quickness to market. At my job, we are rewriting some pretty terrible vb5 code. It's easy to just WTF a lot, and complain that there are truly insane things inside of it. The flipside of that, is that this code was quickly built and quickly allowed for a revenue stream. The author mentioned that thrown away python code provides no value, but I'm not convinced of…
Earlier quoted context omitted.
Because copying the entire in-memory database you're using on every function call is kind of expensive?
Most often you can pass stack values to and from functions without copying. This is because of move constructors, and named return value optimization. Often its slower to use pointers (the indirection). For instance this does not do any expensive copies: std::string getStr() { auto huge_str = getDatabaseDump(); return huge_str; } void readStr(const std::string& str ){ //read str.. } int main() { auto str = getStr();…
The problem with copy elision is that it's an optional compiler optimization and you have to check if the compiler applies it to you particular piece of code. That doesn't scale for large code bases (nor for small ones imho).