digitalmars.D - Crazy, sad but ... would you use D for your own facebook or pinterest?
- aberba (6/6) Jan 02 2017 I'm not building Facebook/pinterest but I'm trying to work on a
- Adam D. Ruppe (5/7) Jan 02 2017 I did something similar for work about five or six years ago.
- aberba (5/12) Jan 03 2017 Nice. How fast were you able to get it to a mature state?
- Adam D. Ruppe (9/13) Jan 03 2017 About six months to get everything we wanted working well. The
- aberba (3/8) Jan 03 2017 Did you implement some form of clustering (session, storage,
- Adam D. Ruppe (15/17) Jan 04 2017 I cheated (well, some would say "made a reasonable decision not
- Andrei Alexandrescu (2/4) Jan 04 2017 How large was the codebase? Thx! -- Andrei
- Adam D. Ruppe (41/42) Jan 04 2017 wc reports about 80,000 lines. But it isn't line count that
- Jacob Carlborg (6/8) Jan 04 2017 Yeah, for projects like DWT and Tango where very few compile time
- Chris Wright (21/27) Jan 02 2017 I'd consider what languages future employees are likely to know and how
- aberba (13/41) Jan 03 2017 That's my fear. I'm much into using already baked stuff.
- Chris Wright (6/7) Jan 03 2017 http://vibed.org/ is the framework you'll probably be using. It has mysq...
- aberba (4/13) Jan 05 2017 After thinking through things, I might go for Heroku with addons
- Mengu (5/12) Jan 03 2017 i'd suggest the language that you know the best, the language
I'm not building Facebook/pinterest but I'm trying to work on a platform like "pinterest-like" but on a small scale. I want it to be easy to write, fast, ... you know. D is obviously that (IMO). About scalability, would you recommend D(vibe.d initially) for long run (techically, generally, currently)? Why? (Brutal honesty).
Jan 02 2017
On Monday, 2 January 2017 at 21:49:03 UTC, aberba wrote:I'm trying to work on a platform like "pinterest-like" but on a small scale.I did something similar for work about five or six years ago. Used D, went well. The company changed direction though while it was still small, so I'll never know if it would have scaled or not.
Jan 02 2017
On Tuesday, 3 January 2017 at 00:04:33 UTC, Adam D. Ruppe wrote:On Monday, 2 January 2017 at 21:49:03 UTC, aberba wrote:Nice. How fast were you able to get it to a mature state? I have been prototyping with vibe.d (dub) for sometime now. This might be obvious but ... compilation and linking slows the process... its not much problem though.I'm trying to work on a platform like "pinterest-like" but on a small scale.I did something similar for work about five or six years ago. Used D, went well. The company changed direction though while it was still small, so I'll never know if it would have scaled or not.
Jan 03 2017
On Tuesday, 3 January 2017 at 11:59:46 UTC, aberba wrote:Nice. How fast were you able to get it to a mature state?About six months to get everything we wanted working well. The initial core was done in about two (including me writing necessary D libraries to support it, this was done before vibe.d was out so I wrote all my own), then we had to add features, styles, polish, etc. over the next several months.I have been prototyping with vibe.d (dub) for sometime now. This might be obvious but ... compilation and linking slows the process... its not much problem though.My compile+link time at one point hit 15 seconds so I optimized some templates and got it down to 7. Still kinda slow but not *that* bad.
Jan 03 2017
On Wednesday, 4 January 2017 at 04:10:30 UTC, Adam D. Ruppe wrote:About six months to get everything we wanted working well. The initial core was done in about two (including me writing necessary D libraries to support it, this was done before vibe.d was out so I wrote all my own), then we had to add features, styles, polish, etc. over the next several months.Did you implement some form of clustering (session, storage, caching)?
Jan 03 2017
On Wednesday, 4 January 2017 at 07:08:25 UTC, aberba wrote:Did you implement some form of clustering (session, storage, caching)?I cheated (well, some would say "made a reasonable decision not to reinvent the wheel"): I ran two copies of the application and both talked to the same database (which itself has a replication feature for failover, so any one server could go down at a time without breaking things, but two down at once would most likely have been a problem). Session storage was done as a special case of database setup. The application itself didn't know and didn't need to know about the server setup. We never hit a point where this was problematic. If it took off to millions of users, perhaps things would need to change, but it worked fine with our actual scale (we made a modest profit for the years it stayed up, so I don't consider it a failure per se, but as I said, the company eventually pivoted).
Jan 04 2017
On 1/3/17 11:10 PM, Adam D. Ruppe wrote:My compile+link time at one point hit 15 seconds so I optimized some templates and got it down to 7. Still kinda slow but not *that* bad.How large was the codebase? Thx! -- Andrei
Jan 04 2017
On Wednesday, 4 January 2017 at 12:44:08 UTC, Andrei Alexandrescu wrote:How large was the codebase? Thx! -- Andreiwc reports about 80,000 lines. But it isn't line count that affects build speed in D: it is the content of those lines. When I optimized it, the source code actually got *bigger*, but I simplified templates and moved some stuff to runtime functions which build much, much faster than complicated template+CTFE instantiations. See, the program used a lot of code generation so I'd just add a function to the class and all the web API and most the HTML components would be auto-generated from the function signature. By the time the D program was up to 10,000 lines, we already had more relevant functionality than the 100,000 line PHP program we were migrating away from, mostly thanks to the more efficient abstractions and generating boilerplate automatically. (Though, granted, the php did some stuff we didn't care about too, the feature sets were mostly comparable.) However, adding a one line function to the source could result in a dozen templates being instantiated, which slows compile and makes for some huge binaries. When I changed it, it would do some metadata generation in the template, then pass off to as many reused instantiations as possible (so instead of generateFunction!foo doing everything, it would forward to generateFunctionArgumentCode!(ParameterType!foo) (well, we didn't have ParameterType back then, std.traits wasn't even around IIRC until after like 2012 and I did the bulk of this in 2010, but my homemade code did the same thing). Then, the compiler can reuse the same thing for common types like int and string. Also, these would generate data tables that a runtime function could load instead of *being* the whole function, cutting the generated code down significantly.) Actually, I started all templated, then moved to a hybrid template + TypeInfo-like setup for various reasons... something to keep in mind as we talk about heavily templating druntime... (The performance difference at runtime was negligible, though I didn't dive into it much, since the performance of most the code was never under pressure; when things got slow, it was because of a few specific functions. My CSS thing was slow, so I cached it, problem solved. A few database queries were slow, so I fixed the SQL, problem solved. The gains from fixing those 10-line hotspots were always the major fixes we needed.)
Jan 04 2017
On 2017-01-04 15:04, Adam D. Ruppe wrote:wc reports about 80,000 lines. But it isn't line count that affects build speed in D: it is the content of those lines.Yeah, for projects like DWT and Tango where very few compile time features are used it's really quick to compile. DWT takes around 6 seconds for me to compile, just below 200 000 lines. -- /Jacob Carlborg
Jan 04 2017
On Mon, 02 Jan 2017 21:49:03 +0000, aberba wrote:I'm not building Facebook/pinterest but I'm trying to work on a platform like "pinterest-like" but on a small scale. I want it to be easy to write, fast, ... you know. D is obviously that (IMO). About scalability, would you recommend D(vibe.d initially) for long run (techically, generally, currently)? Why? (Brutal honesty).I'd consider what languages future employees are likely to know and how much time it would take them to become proficient with D. I'd consider what dependencies I will likely have and whether there are existing D libraries for them. Then I'd put together a demo and see how it works. Use ab(1) (the Apache benchmark tool) to estimate scaling naively, and then implement a more application-specific benchmarking tool to see in more depth. I'd do that iteratively, so I'm not spending weeks on a demo that can't handle two simultaneous database connections or falls over if you look at it funny. I'm likely to want investors, so a functional demo is useful, even if I scrap it after seed funding or Series A. I'd do the same with any toolkit or language at that stage. For instance, I'm at an early-stage startup right now, and I spent a bit of effort comparing several different frameworks we could use for services and RPCs. This isn't so much an answer, but then, I don't know your usecase well enough, and I don't know what technologies you plan to use. For instance, you might want to use Hadoop for file storage. Or MongoDB + GridFS. Or MySQL with a limit on file sizes. Or a scale-out filesystem like Qumulo. These are quite different options with different levels of support in D.
Jan 02 2017
On Tuesday, 3 January 2017 at 00:51:04 UTC, Chris Wright wrote:On Mon, 02 Jan 2017 21:49:03 +0000, aberba wrote:Ha ha. That is a potential problem. But I will figure things out.I'm not building Facebook/pinterest but I'm trying to work on a platform like "pinterest-like" but on a small scale. I want it to be easy to write, fast, ... you know. D is obviously that (IMO). About scalability, would you recommend D(vibe.d initially) for long run (techically, generally, currently)? Why? (Brutal honesty).I'd consider what languages future employees are likely to know and how much time it would take them to become proficient with D.I'd consider what dependencies I will likely have and whether there are existing D libraries for them.That's my fear. I'm much into using already baked stuff.a more application-specific benchmarking tool to see in more depth.Will look into that.I'm likely to want investors, so a functional demo is useful, even if I scrap it after seed funding or Series A. I'd do the same with any toolkit or language at that stage. For instance, I'm at an early-stage startup right now, and I spent a bit of effort comparing several different frameworks we could use for services and RPCs.I'm currently planning on funding initially myself. And support in future with content promotion fees... mini mini ads :) I feel getting investors will limit my ability to craft it ATM.This isn't so much an answer, but then, I don't know your usecase well enough, and I don't know what technologies you plan to use. For instance, you might want to use Hadoop for file storage. Or MongoDB + GridFS. Or MySQL with a limit on file sizes. Or a scale-out filesystem like Qumulo. These are quite different options with different levels of support in D.Planning to use mysql and mongoDB(for the flexible part). I haven't research much about File Systems but I planning to use amazon s3. Basically I want to handle few burden as possible. Could use some advice though. It will be based my my country alone (local audience). But local hosting services are not reliable (down time issues).
Jan 03 2017
On Tue, 03 Jan 2017 11:47:54 +0000, aberba wrote:Could use some advice though.http://vibed.org/ is the framework you'll probably be using. It has mysql and mongodb support. http://code.dlang.org/ says there's an s3 client that works with vibe: http://code.dlang.org/packages/vibe-s3 It's got some scary warnings about its alpha status, so try it out before committing.
Jan 03 2017
On Tuesday, 3 January 2017 at 11:47:54 UTC, aberba wrote:On Tuesday, 3 January 2017 at 00:51:04 UTC, Chris Wright wrote:On Mon, 02 Jan 2017 21:49:03 +0000, aberba wrote:Planning to use mysql and mongoDB(for the flexible part). I haven't research much about File Systems but I planning to use amazon s3. Basically I want to handle few burden as possible. Could use some advice though. It will be based my my country alone (local audience). But local hosting services are not reliable (down time issues).After thinking through things, I might go for Heroku with addons for various DBs to abstract load balancing and scalability. I way to administrate as few areas as possible.
Jan 05 2017
On Monday, 2 January 2017 at 21:49:03 UTC, aberba wrote:I'm not building Facebook/pinterest but I'm trying to work on a platform like "pinterest-like" but on a small scale. I want it to be easy to write, fast, ... you know. D is obviously that (IMO). About scalability, would you recommend D(vibe.d initially) for long run (techically, generally, currently)? Why? (Brutal honesty).i'd suggest the language that you know the best, the language that will not block your way and build barriers so you can focus on building your product. maybe later you can port it to D or build some new services in D.
Jan 03 2017