I want to write a good imageboard engine with clean code, to be the preferred choice instead of 4chan's shitty codebase (admit it, it's true) and derivatives. What I am having trouble with, is what language/environment to do it in. Every one has ups and downs. Here are some I can program in:
* C with CGI is very fast (except for fork overheads), but development times are going to be absolute shit.
* C with FastCGI runs even faster than CGI, but the development times are the same as above, and I don't like the added complexity compared to plain old CGI.
* Python is just shit. Period.
* node.js is a cool concept, but I am worried about performance/scalability, as well as the fact that it doesn't seem like a solid platform to bank on; I always feel that in ten years, no one will care about it, and my imageboard will be dead.
There are other options, like perl, but I don't know them yet, so learning overhead must be taken into account.
What should I do, /prog/?
Name:
Anonymous2011-12-04 7:52
C with FastCGI if you have time to lose, Common Lisp with FastCGI otherwise.
Name:
Anonymous2011-12-04 7:53
>>2
Are the performance benefits of less forking really that great compared to CGI that it's worth it?
Use Python or Ruby with a micro framework.
Sinatra + Thin + nginx has a good balance between easyness and bloatness.
And you don't have to worry about ``speed'' for this kind of web software if you have a good caching mechanism.
Name:
Anonymous2011-12-04 8:58
but development times are going to be absolute shit.
Ask yourself how much time will be saved by all the users that will ever use your software over how much additional development time you'll need.
Name:
Anonymous2011-12-04 9:25
3-4 peak concurrent users
3-4 years of dev time
Sounds perfectly reasonable
C all the way.
Name:
Anonymous2011-12-04 9:39
Don't write an HTTP imageboard engine, it's a waste of time. Instead, make a specialized BBS protocol and implement it. It will be more fun, more efficient, and faster to develop.
The fact that 4chan/Wikipedia/other high profile sites use shitty languages like PHP should indicate that the speed of a programming language isn't very important for websites.
It's other factors which make a website seem slow.
>>15
They're cached in several layers, raw PHP is x100 slower than JavaScript.
It takes ungodly amount of cludges to make PHP fast,secure and "scalable":
The once-generated PHP content (a single puny HTML page) doesn't scale when everyone(>5k concurrent) reloads the same page like on 300mget and the php Script has to regen new content.
Compared to C servers which have them the functionality in native code(compiled modules), such stuff takes nanoseconds to generate.
Name:
Anonymous2011-12-04 11:41
Either way take apart open-source C server and remodel it, would be 1 month max.
And you get all the free functionality+optimizations+custom code running your board without effort.
>>15
PHP is the bane of Facebook's existence, they spend ridiculous amounts of resources to make it go fast.
I bet they could throw ⅓ of their servers if they could rid themselves of that ungodly abomination.
Name:
Anonymous2011-12-04 11:51
>>19
PHP is made by jews.
Facebook is made by jews.
Are implying that jews make problems for themselves?
>>27
That's another thing. I'm very interested in implementing an AJAX-based interface which will run faster and be more useful than a static HTML interface. However, I know that many people don't like anything that ain't static, so I'll make it modular, and implement two interfaces that you can choose from.
Name:
Anonymous2011-12-05 8:56
>>28
Implement a static only interface and let others write userscripts and extensions for you.
Name:
Anonymous2011-12-05 21:40
>>29
No. Because I, as the developer, like AJAX interfaces, there will be at least one user of that interface, and therefore, it is needed. Fuck userscripts and extensions, by the way; they act on the hackish premise of parsing the source/DOM which is volatile and breaks.
>>30
Sure, JavaScript aided interfaces are perfectly fine.
AJAX however, is shit, and is only useful for real web applications, as in, desktop applications ported to run in a browser, like email clients, calendars, etc...
>>25
CGI is slow as shit probably acceptable for low-traffic sites. Implementing a simple but robust web server is probably a better approach since you can (A) give all your friends COOL FREE IMAGEBOARDS and (B) use nginx as a reverse proxy and/or load balancer
Name:
Anonymous2011-12-06 6:05
If all jews are to be killed, the world would become a better place for all. And there wont be PHP and Python anymore, because both language owe their existence to jews. Just imagine a world without jew! A world without evil and ugly!
corporations default to php (for web programming) because php programmers are cheap and plentiful. most OSS is written in php for the same reason and also because php hosts are cheap and plentiful.
>>47
Supporting dynamic typing and/or numeric tower would require more transistors for every basic operation, wich arent required for C/C++. Hardware assisted JIT and garbage collection would require global changes to MMU and stuff like write barrier isn't cheap.
>>47-48
Lispers are such bad coders, they can't adapt their shitty language to better non-obsolete CPUs. They should've died along with the lisp machines.
Name:
Anonymous2011-12-06 19:44
>>49
Enjoy your declare unsafe pointer segmentation fault stackoverflow.
Name:
Anonymous2011-12-06 21:19
>>50
Writing 99% my code in a fast and safe language, fagstorm.
Name:
Anonymous2011-12-06 21:36
Only shitty programmers worry about what language to use. Programmers who actually get shit done (like moot, Mark Zuckerburg, Jimmy Wales, etc) use PHP.
Don't worry about speed optimization when you haven't even wrote a single line of code!
Name:
Anonymous2011-12-06 22:09
>>52
moot? Getting shit done? Look at this piece of shit imageboard software. IHBT
Programmers [...] like moot, Mark Zuckerburg, Jimmy Wales
Mommy, am I not a programmer anymore?
Name:
Anonymous2012-11-30 13:25
Racket
Erlang
Objective BBCode
Name:
Anonymous2012-11-30 13:41
Aim high and go for C directly and don't kid yourself with small 10K tests, that's just going to set you on the wrong path from the start. Go for some serious numbers, like 10 million concurrent connections and design everything between your production environment to your test suit around that.
Speed doesn't mean jackshit for ``web apps'', it's all about IO. As >>40 suggests, go try Heroku or one of those free cloud enterprise bullshites for the hosting.