www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - vibe.d 0.7.10 released

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
Jan 03 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
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.
Pretty cool stuff, congratulations. I've had a look at it and as I am always looking for alternatives to generally (and sheepishly) accepted "will do" technologies like PHP, JS etc. I would like to test and possibly use it for my own web projects. Only, it's not 100% clear to me how vibe.d can be integrated into existing frameworks / technologies, as when you rent server space somewhere. Can vibe.d exist as a standalone framework (i.e. as a replacement for PHP) within my own rented space or does it need to be installed as a system wide service, in which case it is up to the host whether or not to make it available?
Jan 03 2013
parent reply "simendsjo" <simendsjo gmail.com> writes:
On Thursday, 3 January 2013 at 10:40:40 UTC, Chris wrote:
 Pretty cool stuff, congratulations. I've had a look at it and 
 as I am always looking for alternatives to generally (and 
 sheepishly) accepted "will do" technologies like PHP, JS etc. I 
 would like to test and possibly use it for my own web projects. 
 Only, it's not 100% clear to me how vibe.d can be integrated 
 into existing frameworks / technologies, as when you rent 
 server space somewhere. Can vibe.d exist as a standalone 
 framework (i.e. as a replacement for PHP) within my own rented 
 space or does it need to be installed as a system wide service, 
 in which case it is up to the host whether or not to make it 
 available?
I'm using dmd and vibe on a Linode server without installing them. Haven't had a single problem with it.
Jan 03 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 3 January 2013 at 10:57:06 UTC, simendsjo wrote:
 On Thursday, 3 January 2013 at 10:40:40 UTC, Chris wrote:

 I'm using dmd and vibe on a Linode server without installing 
 them.
 Haven't had a single problem with it.
Good news, but in this case there may be restrictions depending on the provider (i.e. restrictions as to installing your own software). What are your experiences with vibe.d?
Jan 03 2013
parent reply "simendsjo" <simendsjo gmail.com> writes:
On Thursday, 3 January 2013 at 11:53:01 UTC, Chris wrote:
 On Thursday, 3 January 2013 at 10:57:06 UTC, simendsjo wrote:
 On Thursday, 3 January 2013 at 10:40:40 UTC, Chris wrote:

 I'm using dmd and vibe on a Linode server without installing 
 them.
 Haven't had a single problem with it.
Good news, but in this case there may be restrictions depending on the provider (i.e. restrictions as to installing your own software). What are your experiences with vibe.d?
You only have to download the vibe and dmd zips. As long as you can run executables you download you should be fine. I haven't installed them myself, just added some symlinks to the executables. I've only created a small vibe site, so I don't have a lot of experience with it, but it seems very fast and nice. Doesn't force you into a particular way of structuring your site.
Jan 03 2013
parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 3 January 2013 at 12:22:33 UTC, simendsjo
 You only have to download the vibe and dmd zips. As long as you 
 can run executables you download you should be fine. I haven't 
 installed them myself, just added some symlinks to the 
 executables.

 I've only created a small vibe site, so I don't have a lot of 
 experience with it, but it seems very fast and nice. Doesn't 
 force you into a particular way of structuring your site.
That's good news. From what I have seen on the vibe.d homepage I think it comes pretty close to what I want, a skeleton I can flesh out myself and - as you pointed out - without being forced to adhere to a certain way of arranging things, plus it is written in D and thus all the language's features can be used for web development.
Jan 03 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
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=20

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?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jan 03 2013
next sibling parent reply "mist" <none none.none> writes:
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 :)

On Thursday, 3 January 2013 at 10:55:06 UTC, Russel Winder wrote:
 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?
Jan 03 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Jan 03 2013
parent reply Russel Winder <russel winder.org.uk> writes:
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"?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jan 04 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.
Jan 04 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-03 11:54, Russel Winder wrote:
 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?
One of the great things about Ruby on Rails is that it's got a plugin for everything (and a bit more). Oh, and I really like the assets pipeline. It compiles SASS, CoffeeScript and similar languages to CSS and JavaScript. It's also possible to pipe it through Ruby first. In production environment it merges all separate CSS/JavaScript files into one and minifies it. It also adds a unique hash to the end of the filename to avoid conflicts with cached files. -- /Jacob Carlborg
Jan 03 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 3 January 2013 at 10:55:06 UTC, Russel Winder wrote:
 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 would have to test vibe.d first and I do like to try new things, especially because I have had bad experiences with JS, PHP, Pyhton and Java based stuff (workwise I have to deal with PHP/JS a lot which can be pretty annoying). Every few years there's a new "definite" framework based on one popular language or another, a new CMS and what not. But popular does not necessarily mean good or flexible. In fact, the bigger a system or framework gets, the less flexible it becomes, IMO.
Jan 03 2013
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.
Jan 03 2013
prev sibling next sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
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.
Jan 03 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.
Jan 03 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
 Pretty cool stuff, congratulations.
+1)
Jan 03 2013
prev sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
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...
Jan 04 2013