What has not been mentioned at all: how C++ webapps will spell the end of XSS and SQL injection as hackers refocus on the much more interesing but almost-forgotten buffer overflow vulnerabilities.
Oh joy!
C++: A language for next generation web apps
71–80 of 99 posts
Re: C++: A language for next generation web apps
#72To be fair, after coming back to C++ after years in the world of Python and Haskell, it's not as bad as I remembered. C++ is actually a moderately effective functional programming language. With reasonable knowledge of the standard data structures, and using BOOST, one can actually write fairly expressive and effective C++ code. Most of the time, I feel like all I'm doing is writing a much more verbose version of Pyt…
Your experience with Python and Haskell has most likely made you a far better C++ programmer than you were before.
Re: C++: A language for next generation web apps
#73If this guy is really running his web server on an Acer Aspire One 512, as he says at http://stevehanov.ca/blog/index.php?id=71 C++ sounds like an excellent choice.
Re: C++: A language for next generation web apps
#74He does have a point about efficiency, or about delivering a single app ... but you also get those advantages with a Java, or a .NET, or even an Erlang or Haskell app which are reasonably efficient ... and still, you won't have to deal with segfaults.
Also, if you want extreme scalability, like being able to serve 10000 requests/sec on a single server ... sorry, but raw performance doesn't cut it ... see this article for instance ... http://www.kegel.com/c10k.html.
Not to mention that the most usual bottleneck is the database (how many apps can you build that doesn't use one?). So even if you build the fastest web server in the world, if you're using a RDBMS you're going to end up with 100 reqs/sec, unless you're sharding or caching that data.
The bottom line is ... if you want extreme scalability, I don't think C++ is going to cut it, and you're going to invest a whole lot more in optimizations that are already done in more mature web frameworks.
Well, unless you have Google's resources and skill.
Re: C++: A language for next generation web apps
#75Earlier quoted context omitted.
RubyOnRails is very test gunghu, but to run a hello world test takes seconds , anyone know why? This seems very odd. Is this one of those do what I preach, not what I do things?
Because if "performance doesn't matter" is repeated often enough people actually start to believe it, and if enough people believe it, it becomes false. Is there a name for this logic? :-)
Confirmational Bias followed by a Self-fulfilling Prophecy. But you knew that and I think your question was purely rhetorical ;-)
Re: C++: A language for next generation web apps
#76To be fair, after coming back to C++ after years in the world of Python and Haskell, it's not as bad as I remembered. C++ is actually a moderately effective functional programming language. With reasonable knowledge of the standard data structures, and using BOOST, one can actually write fairly expressive and effective C++ code. Most of the time, I feel like all I'm doing is writing a much more verbose version of Pyt…
So, what is great, modern C++ code to read?
Re: C++: A language for next generation web apps
#77"MySql is GPL'd, so you can't even link to its client library in a closed source app." AFAIK it's GPLv2 (and not AGPL) so this is only true if you intend to distribute your application itself, not just host it yourself.
I believe it does however mean that your application code has to be GPLv2, and thus can't be linked to code using some popular licenses, for example Apache 2.0.
Re: C++: A language for next generation web apps
#78Earlier quoted context omitted.
I had to read that a few times. What is he talking about?
1 wchar_t * 2 utf2wide(const char *utf) 3 { 4 size_t len; 5 wchar_t *wide; 6 len = mbstowcs(NULL, utf, 0); 7 wide = malloc(sizeof(*wide) * (len + 1)); 8 mbstowcs(wide, utf, len); 9 return wide; 10 }
Because the result of malloc is not checked, it can take the whole web server down if it returns NULL. Which can happen.
Re: C++: A language for next generation web apps
#79The reason why dynamic scripting languages are more appropriate for web applications than C++ is simply that the bottleneck is somewhere else - namely, the Internet is slow enough to make the performance of the server-side code irrelevant. That can very easily change in the future.
Roundtrip latency is certainly going to add up to a substantial chunk of time, but that's not much excuse to discard performance considerations. Requests that take say 50ms of processing will take even longer if the box is busy; it doesn't take much to add up and becomes noticeable. And if your implementation on the server side is very fast, you can do more.
My point was indeed that performance can matter, and will matter even more in the future, since no apparent technological limit on network speed has been reached so far.
Re: C++: A language for next generation web apps
#80Earlier quoted context omitted.
Chances are that the majority of developers won't find the most efficient algorithm to solve the problem. (vs. the most efficient implementation of that algorithm... which is clearly going to be in a combination of C and assembly anyway). Anyway, the guy using the good algorithm ends up with the fastest code. Different compilers will produce different quality of code. Question is, if I am using C++ vs. a guy using Pe…
"Chances are that the majority of developers won't find the most efficient algorithm to solve the problem." If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language. Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.
I guess my point was that the fast languages are generally not the ones that are good for developing the fast algorithms. It is harder to experiment in a language like C than it is in a language like lisp or perl.
The other thing to point out is that there is no reason for memory usage, concurrency or speed to be problems in dynamic languages. These are all issues with the implementations of compilers/interpreters that we are using.
It just so happens that dynamic languages have only recently come back into vogue, and we have forgotten (at least in ruby and python) all of the work that was done to create efficient implementations of dynamic languages.
Examples being how well Lisp stacked up against C as early as the 80-90s, projects like StrongTalk, stack based languages like forth... the multitude of papers on efficient scheme implementations.
Dynamic languages were declared 'slow' and therefore were dumped in favor of C by most programmers. This has caused a gap in the knowledge that we have about implementing dynamic languages. Which is a shame, because there is a lot out there for us to relearn.