Live data from Hacker News

C++: A language for next generation web apps

stevehanov.ca

51–60 of 99 posts

Re: C++: A language for next generation web apps

#52

Earlier quoted context omitted.

"because we all know it can work and that it will be faster" Speed of execution depends more on the programmer's expertise than the language used.

Not really true. I can write the same algorithm in Perl as in Haskell, and the Haskell always runs faster.

But then your expertise is not that different from your expertise. Your perl will probably still be faster overall than a beginner's haskell, not for the same algorithm, but for solutions to the same problem. Knowing which algorithms perform well for a given problem solved in perl is the most relevant part of expertise.

Re: C++: A language for next generation web apps

#53

Earlier quoted context omitted.

"because we all know it can work and that it will be faster" Speed of execution depends more on the programmer's expertise than the language used.

Not really true. I can write the same algorithm in Perl as in Haskell, and the Haskell always runs faster.

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 Perl, will I ever reach the efficient algorithm? I might call it quits when I finally get something to compile and not segfault.

(Of course even this is kind of a strawman, because the perl guy can just reimplement in C++ when he figures out that he wants more speed out of his good algorithm).

Re: C++: A language for next generation web apps

#54
post #22

The 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.

Re: C++: A language for next generation web apps

#55

Earlier quoted context omitted.

Oddly enough I'm back to C++ too, after Ruby. One nice thing is; in a fast language, tests run quickly too. Also, Python and Ruby don't have the equivalent of an ASSERT (you could roll your own but it's not standard practice ). Also, C++ has standard hash lists and complicated data structure are actually going to run quickly. And while memory management can be a pain, you are doing it yourself so you can track down m…

Also, Python and Ruby don't have the equivalent of an ASSERT (you could roll your own but it's not standard practice). Ahem: http://docs.python.org/reference/simple_stmts.html#the-asser...

[deleted]

Re: C++: A language for next generation web apps

#57
For a two to three years i was running in a VPS server in VPSLink which had about 64MB of RAM - for everything and without swap space. The target use of this VPS was probably as an email server or something as most people recommended the more expensive 128MB and 256MB plans for serving (static) pages. And actually there were only about 40MB left since the OS needed some memory for itself too.

Personally i thought that with better resources management i could do much more, so i wrote a custom HTTP server in that could fit in less than one MB of RAM. Most of my pages were generated offline using a custom program in FreePascal.

The server could also execute CGI scripts, so i also wrote a forum in FreePascal.

According to my logs, the whole system ran out of memory only once :-). Until the day i decided to give myself a little more features (when i got a much better VPS from Linode) i had about 5-6 sites running (different domains), a Subversion server and a few "dynamic" apps.

The forum can be found here. I still run it in my new VPS, although it got some spam. The a + b = ? anti-spam feature was new when i wrote the forum but seems that bots got better :-P.

http://www.badsectoracula.com/projects/mforum/

Re: C++: A language for next generation web apps

#58
Way back in 2000, when we launched Planetarion (http://en.wikipedia.org/wiki/Planetarion), we used C++ with a custom webframework, and CORBA for communicating with the database.

At our peak late in 2002, we served about 320 million dynamic webpages a month using three desktop Pentium 3's for webservers, and a dual CPU P3 for the database. No caching, as that wasn't needed.

Blazing fast, and not all that difficult to work with once the basic framework was solid and in place.

Re: C++: A language for next generation web apps

#59
post #29

Earlier 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?

I doubt it takes seconds to test a hello world program in Ruby. However, to test a hello world Rails application is a different story, as you have to start up the web server, which takes seconds (even though it eventually just serves a simple page).

Not necessarily the web server.

Standard `rake test:units` (or even `ruby test/units/model_test.rb`) takes the whole Rails stack so it adds up.

Re: C++: A language for next generation web apps

#60
post #9

if you're on an embedded device, this is actually not a satire

So, serving web pages from an embedded device? Have we finally got to the "your washing machine is on the Internet" era? :)

I can't wait for the RESTful API for my alarm clock, and washer. ;-)
Post reply on HN