Re: Introducing vibe.d!
Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote: During the last few months, we have been working on a new framework for general I/O and especially for building extremely fast web apps. It combines asynchronous I/O with core.thread's great fibers to build a convenient, blocking API which can handle insane amounts of connections due to the low memory and computational overhead. Some of its key fatures are: - Very fast but no endless callback chains as in node.js and similar frameworks - Concise API that tries to be as efficient and intuitive as possible - Built-in HTTP server and client with support for HTTPS, chunked and compressed transfers, keep-alive connections, Apache-style logging, a reverse-proxy, url routing and more - Jade based HTML/XML template system with compile-time code generation for the fastest dynamic page generation times possible - Built-in support for MongoDB and Redis databases - WebSocket support - Natural Json and Bson handling - A package manager for seemless use of extension libraries See http://vibed.org/ for more information and some example applications (there are some things in the works such as an etherpad clone and an NNTP server). vibe.d is in a working state and enters its first beta-phase now to stabilize the current feature set. After that, a small list of additional features is planned before the 1.0 release. The framework can be downloaded or GIT cloned from http://vibed.org/ and is distributed under the terms of the MIT license. Note that the website including the blog is fully written in vibe and provides the first stress test for the implementation. Regards, Sönke
Re: Introducing vibe.d!
Hi Sönke, My concern is actually in development time. Compilation, debugging, etc.. Ruby on rails applications had their reload classes optimized effecting only reload the classes changed instead of the entire environment. Today we have the application of ERP type integrated e-commerce with 342 models, reload wait around this set can be a really time consuming process for development. I appreciate your work, appreciate languagem d, successful community On Tuesday, 5 November 2013 at 15:35:19 UTC, Sönke Ludwig wrote: Am 04.11.2013 18:35, schrieb Dicebot: On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira wrote: Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira I might recommend to wait a bit before trying it in production until CI suite is figured out (it is work in progress), there are some concerns with stability/regressions right now because it grows just too fast. Seconded, some parts are still moving fast and some parts still don't have good enough test coverage. And while it can already be used for many production tasks when used with some care, I wouldn't suggest to start a million+ user service in the next 6 months or so, before a rigorous regression free stabilization process is in effect.
