Am 03.01.2013 11:54, schrieb Russel Winder:
> May I suggest you need to do some marketing against:
> 
> 	node.js
> 	vert.x
> 	goweb
> 	revel
> 	Play!
> 	Django
> 	Grails
> 	Ruby on Rails
> 	Flask
> 	Sinatra
> 	Ratpack
> 
> Why would anyone want to use vibe.d in preference to any of the above? Is there a lightning talk I can do at ACCU, PyCon UK, Gr8Conf, GGX, EuroPython, etc. to show that the pet Web framework/Web toolkit of the language of the conference is rubbish in comparison to that of D?
> 

I'd say what mist said earlier is the main list of fundamental goodies. It surely can't beat some of the really popular frameworks in terms of pure feature richness (be it through extension libraries or not), but for me it provides a very appealing combination of the individual choices plus the great advantage of being in D.

...D arguably being an advantage in itself compared to many of the other languages, but also because I'm using vibe.d in a larger context - for example in GUI applications(*) - where switching languages for certain operations would not really be practical.

I think for almost all of the frameworks you mentioned it is possible to find some compelling advantages of vibe.d/D (of course also disadvantages, be it just missing features). It also depends a lot on the language that is used.

Having a nice comparison in terms of architecture/design, performance and features would definitely be nice to have and I'd really /like/ to spend more time trying to convince people coming from other languages and all. But during the last months my workload was (and will stay for a while) far too high to be able to spend adequate time on things like these. Priorities unfortunately just don't permit this right now.


(*) GUI event loop integration is (currently limited to Windows) AFAIK a quite unique property of
the framework.

Great news, keep up the good work!

Last month I used previous version to make a simple online app for one contest. I developed in Windows and deployed in Linux (a small VPS, installed dmd from some package and vibe.d from the zip archive). I had only a few hours to make that app and everything worked very smoothly. The app is still running and after a few weeks of work its memory usage is still just a few MBs, and CPU load was always close to 0% (I don't have much traffic there though). Thank you for a great product!

My only nuisance was a clash of some DLLs in the path between vibe.d and Visual-D. After adding vibe.d dir to system path Visual-D started to crash. Have to keep them separated.

Am 03.01.2013 19:37, schrieb thedeemon:
> Great news, keep up the good work!
> 
> Last month I used previous version to make a simple online app for one contest. I developed in Windows and deployed in Linux (a small VPS, installed dmd from some package and vibe.d from the zip archive). I had only a few hours to make that app and everything worked very smoothly. The app is still running and after a few weeks of work its memory usage is still just a few MBs, and CPU load was always close to 0% (I don't have much traffic there though). Thank you for a great product!

Sounds great! My experience is also quite trouble-free by now (except for one project that has some kind of memory leak, but I'm not sure who is at fault there). It needs some serious stress testing though, before I'd declare it actually "stable" (version 0.8.0 an on will be the first stable branch).

> 
> My only nuisance was a clash of some DLLs in the path between vibe.d and Visual-D. After adding vibe.d dir to system path Visual-D started to crash. Have to keep them separated.

That's interesting. I do have occasional crashes in VisualD, but never attributed it to that combination. Do you know any specifics about which DLL might be in conflict? I checked with dependency walker and couldn't see anything suspicious.

>
> Pretty cool stuff, congratulations.
>
+1)

On Thu, 03 Jan 2013 12:11:23 +0100
"mist" <none@none.none> wrote:

> Last time I was performance testing vibe it was almost 4x faster than node.js and 1.5 faster than similar Erlang framework (can't remember its name now). Plus all static typing and sane async syntax goodies as a cherry on top. Was enough to convince me, but other language lovers will probably need more arguments :)
> 

Another big advantage of Vibe.d (aside from being able to use a sane language: D.) is the way that the event-loop/fibers/async-IO works. Doing IO in Vibe.d (or at least just network IO at the moment, AIUI) looks like synchronous code, and is written just like synchronous code, but *behind the scenes* it will do it asynchronously and yield to another fiber (ie another request) while it waits. (In other words, it's like Node.js, except it's actually fast and easy, instead of awkward and slow-by-default.) Sooo fucking awesome!!!

That and being able to write everything in D are Vibe.d's two killer features for me.

Can someone point me at URLs I can use as examples of code and result to do a 5 min talk at Greach 2013 on "Why even think of Node.js or Vert.x when you have Vibe.d"?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday, 3 January 2013 at 09:19:57 UTC, Sönke Ludwig wrote:
> Changes:
>
>  - Compiles on DMD 2.061 (and Win64)
>
>  - The Win32 back end supports TCP sockets
>
>  - Form and REST interface generators have been improved and can handle more types
>
>  - Diet templates support arbitrary D expressions instead of just static strings for HTML
>    attributes now. Boolean values are also supported and do the right thing (i.e. omitting
>    the attribute in the output if it evaluates to false).
>
>
> Full change log: http://vibed.org/blog/posts/vibe-release-0.7.10
>
> Download*: http://vibed.org/download?file=vibed-0.7.10.zip
>
> GitHub: https://github.com/rejectedsoftware/vibe.d
>
>
> * Due to the removal of GitHub's download feature, the zip file is now unfortunately hosted on the
> same slow virtual server as the site.

Congratulations!
vibed is a perl among D projects. Respect. I do not use it for anything useful, the moment someone asks me to do some web-stuff vibe.d will be my first choice.
Once I finish my Ingres/VectorWise database connector vibed will probably be used in my company...

Am 04.01.2013 10:19, schrieb Russel Winder:
> Can someone point me at URLs I can use as examples of code and result to do a 5 min talk at Greach 2013 on "Why even think of Node.js or Vert.x when you have Vibe.d"?
> 

I don't know the Vert.x API enough to be sure, but I think that they both use the same callback based asynchronous I/O approach. Any request handler that for example has to talk to a database gets deeply nested in asynchronous callbacks.

If you don't care about error handling, they will usually be silently ignored, because the programming model doesn't fit exceptions or other loud forms of errors. Control flow also gets complicated and error prone and the code becomes badly readable.

To limit this issue, node.js frequently buffers data in the background before issuing a user callback and Vert.x falls back to synchronous I/O+threads (AFAIR, correct me if I'm wrong), destroying all the benefits of async. I/O as soon as you have to heavily rely on that.

A simple example for node.js:
[Will probably not compile, just from the top of my head. Well, the JS version /will/ probably
compile, but fail at runtime ;)]

node.js:
---
requestHandler = function(req, res)
{
	var json = req.body;

	// trade memory for better code readability by reading
	// everything into an array
	db.items.find({kind: json.kind}).toArray(function(err, objects){
		if( err ){
			// really easy to forget to check this and also
			// cumbersome if multiple error sources shall be handled
			// the same spot
			res.json({status: "error", message: "Failed to query DB"}, 500);
			return;
		}

		if( objects.length < 0 ){
			res.json({status: "error", message: "No items found for category"});
			return;
		}

		var ids = [];
		for( i in objects )
			ids.push(objects[i]._id);

		db.orders.insert({items: ids}, {safe: true}, function(err, objects){
			if( err ){
				res.json({status: "ok", message: "Failed to insert order to DB."}, 500);
				return;
			}

			res.json({status: "error", message: "Created order"});
		});
	});
}
---

vibe.d:
---
void requestHandler(HttpServerRequest req, HttpServerResponse res)
{
	auto json = req.json;

	try { // exception handling is fully working
		Bson[] ids; // simple linear control flow with normal loops
		// iterate over the DB cursor as the data comes in
		foreach( itm; db.items.find(["kind": json.kind]) )
			ids ~= itm._id;
		enforce(ids.length > 0, "No items found for category");

		// no callbacks, no explicit error checking necessary
		db.orders.insert([items: ids], UpdateFlags.Safe);

		res.writeJsonBody(["status": "ok", "message": "Created order"]);
	} catch( Exception e ){
		// a single point for error handling is possible
		res.writeJsonBody(["status": "error", "message": e.msg], HttpStatus.InternalServerError);
	}
}
---

Already for this simple example it's 24 lines vs. 14 lines of code and a lot of nesting. It gets a lot worse if two DB queries would have to be done here to get the end result, but I can't be bothered to write the necessary code now ;). But a really important point for server software IMO is that you should be _required_ to handle errors instead of that being an opt-in or forget thing, a mere 'error' parameter just cries for bugs and possibly security holes.

The rest of the argument, I think, is mostly generally about D vs JS/Java/Ruby (which arguably has a lot of weight by itself) and about specific API details.