On Wednesday, 30 April 2014 at 04:42:09 UTC, Dicebot wrote:
> I have a friend who has switched to vibe.d after being Erlang Cowboy devoted user for years. Trying to convince him to write an article about it but no luck so far :( Reason to switch in two words : "static typing".

Yes, static typing is a main selling point. I would also consider switching to D or Go for webstuff if it was production ready/supported. But they will need to reach Java maturity to gain traction in a wider audience...

On Wed, 2014-04-30 at 04:52 +0000, Rikki Cattermole via Digitalmars-d
wrote:
[…]
> I've been working on Cmsed/Dvorm/Dakka specifically in the mind
> of a rather (major) web service. Haven't started it yet, but
> possibly next semester.
> I'm of the opinion that we all need to work together to get a
> damn nice web service framework together.

I would say from anecdotal observation, so no real significance, that most languages end up with a number of frameworks:

1A. Full stack Web framework.
1B. Lightweight HTTP framework.
2A. Full feature networking framework.
2B. Lightweight networking framework.

In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B we have Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted and 2B asyncio (showing my Python bias here :-)

> I split up my ORM for this purpose so even if you don't want to use Cmsed you can use it at least. Won't be very nice for normal Vibe users though.

Grails is doing this at last (necessitated by supporting NoSQL as well as SQL in the full stack). This is a positive aspect of "componentizing" such large frameworks.

> I really do want help, Dakka (Actor framework) needs somebody who knows threading/networking communication. I'll eventually get it communicating with other nodes but.. Will opensource if there is interest.

I would love to help here, and indeed on a review of std.parallelism, but I have committed my time to a revamp of GPars for Groovy 2.3 and Java 8, so cannot take on another big task in the short term.

> Dvorm needs work to make it be usable with relational databases.
> At worse that means I need OpenDBX dlls for 32/64bit (wasn't as
> easy to compile as I thought).
> The hardest part really is how to handle indexes.

Pass I'm afraid, I cannot contribute on this front at all.

> Cmsed needs documentation by the bucket load. Its also blocked at the moment on dub to make it sensible to do reloading of templates/routes/models. Which will change the way you structure it.

Is it viable for Dub to support this? Is someone working on it to create a pull request? Can SCons be an alternative here?

> Cmsed is already at the point of comparable to other web service frameworks in most other languages.

So why would I use it rather than RoR, Grails, Django, Java EE, Spring? Not entirely a rhetorical question. It is good to know early in development why it is worth doing the development rather than using pre-existing tools.

-- 
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 Wednesday, 30 April 2014 at 05:25:15 UTC, Russel Winder via Digitalmars-d wrote:
> On Wed, 2014-04-30 at 04:52 +0000, Rikki Cattermole via Digitalmars-d
> wrote:
> […]
>> I've been working on Cmsed/Dvorm/Dakka specifically in the mind of a rather (major) web service. Haven't started it yet, but possibly next semester.
>> I'm of the opinion that we all need to work together to get a damn nice web service framework together.
>
> I would say from anecdotal observation, so no real significance, that
> most languages end up with a number of frameworks:
>
> 1A. Full stack Web framework.
> 1B. Lightweight HTTP framework.
> 2A. Full feature networking framework.
> 2B. Lightweight networking framework.
>
> In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B we have
> Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted and 2B
> asyncio (showing my Python bias here :-)
>
>> I split up my ORM for this purpose so even if you don't want to use Cmsed you can use it at least. Won't be very nice for normal Vibe users though.
>
> Grails is doing this at last (necessitated by supporting NoSQL as well
> as SQL in the full stack). This is a positive aspect of "componentizing"
> such large frameworks.
>
>> I really do want help, Dakka (Actor framework) needs somebody who knows threading/networking communication. I'll eventually get it communicating with other nodes but.. Will opensource if there is interest.
>
> I would love to help here, and indeed on a review of std.parallelism,
> but I have committed my time to a revamp of GPars for Groovy 2.3 and
> Java 8, so cannot take on another big task in the short term.
>
>> Dvorm needs work to make it be usable with relational databases. At worse that means I need OpenDBX dlls for 32/64bit (wasn't as easy to compile as I thought).
>> The hardest part really is how to handle indexes.
>
> Pass I'm afraid, I cannot contribute on this front at all.
>
>> Cmsed needs documentation by the bucket load. Its also blocked at the moment on dub to make it sensible to do reloading of templates/routes/models. Which will change the way you structure it.
>
> Is it viable for Dub to support this? Is someone working on it to create
> a pull request? Can SCons be an alternative here?

I have already posted on the dub forum about this, Sonke Ludwig said he would be working on variables which will at least allow for copying libraries templates ext.

>> Cmsed is already at the point of comparable to other web service frameworks in most other languages.
>
> So why would I use it rather than RoR, Grails, Django, Java EE, Spring?
> Not entirely a rhetorical question. It is good to know early in
> development why it is worth doing the development rather than using
> pre-existing tools.

Because Vibe already supports a good amount of functionality I am already a step up (like file uploading and templates).
I have a wiki page to what I currently have done vs what I want to do [0].

I really need to do another release of it and Dvorm and give a better indication of what it can do.
I posted somewhere else some of the more advanced functionality being ajax generation from routes/models [1]. But I really need some sort of time cost research to reference with regards to how much time it could save (I also need this for a research paper).

I basically had to make my own web service framework primarily because from my experience and knowledge of what currently is available, nothing meet my requirements. It would be more work creating it in other languages than to just do it in D from the start.

Not to mention I can get pretty good performance out of D in both memory and requests/second. Now if only I could get the ram requirement to compile Cmsed below half a gig I'd be alright (a long shot given my CTFE usage).

[0] https://github.com/rikkimax/Cmsed/wiki/Road-map
[1] https://gist.github.com/rikkimax/11043210

On 30/04/14 00:09, Adam D. Ruppe wrote:

> A lot of things, mostly focusing around having the compiler to help
> refactor with confidence (the importance of this really can't be
> understated) and having libraries that fit better.

I think one of the great things about Rails and Ruby is all the libraries and plugins that are available. If I want to do something, in RoR there's a big chance there's already a library for that. In D, there's a big chance I need to implement it myself.

> The speed is a nice
> bonus too, having to spend half a minute just waiting for the tests to
> run really grates me.

Yeah, it's sucks that Rails is so slow to boot. But unit tests in D suck as well. I mean, how do I run a single unit test in D? Also, my text editor (TextMate) already has support for the unit tests frameworks used in Ruby.

> But wrt libraries, ActiveRecord is unbelievably awful, for example. It
> is a bad idea from the ground up: why, oh why are we reinventing the
> database?

How do you mean? It just adds an object oriented layer on top of it. BTW, what should I use in D. I need a library that is database independent and I don't want to write SQL for the common use cases?

> erb templates are painful to use too

I prefer HAML (similar to Jade in vibe.d) but I don't think it's that bad. What do you use?

> , and so is the routing. I
> don't understand why routing isn't done automatically for the common case.

I don't know how you do you're routing but the first thing I do when generating a new Rails application is to remove the default routing. The default routing opens every public method in a controller to be a routing end point. It's a complete mess.

> The scaffolding is a pain too. Contrast to what web.d does: given a
> function signature, it automatically generates a form for it (using type
> information to select correct widgets) and can format the response in
> several forms automatically including plain text, html list, html table,
> json, xml, csv, and a custom template.

There's a plugin [1] for Rails for generating a form based on a type. I don't understand how anyone can manage without that. It can automatically respond in a couple of formats as well. By default JSON, XML and Erb template. The most basic example will look something like this:

class FoosController < ApplicationController
  respond_to :json, :xml

  def index
    respond_with Foo.all
  end
end

> Maybe Rails can do this stuff and I'm too much of a n00b, but the other
> experienced team members say the way we're doing it is pretty standard
> and I'm just not impressed.

Sure, it depends on what's "standard". Only using what's installed by default. Then yes, perhaps that's standard. But it's not always the best idea. At my previous work I did quite a lot different compared to the "experienced" team members.

> I can just get stuff done in D in a fraction of a time it takes to do
> even less in RoR.

You don't think that's because you're used D for quite a while and developed your own web framework. Compared to Rails where you're completely new.

The biggest problem I have with D is have to do everything myself. I'm getting a bit tired of that.

[1] https://github.com/plataformatec/simple_form

-- 
/Jacob Carlborg

On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim Grøstad
wrote:
> On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote:
>> Go has gained much of it's traction from provably and consistently
>> producing simpler, faster and more reliable systems that C, C++, Python,
>> etc. and getting articles about the success out there.
>
> Python is simpler than Go for web. There is a reason for why Go is still not in production on App Engine, you end up with more convoluted code as far as I can tell. Faster, yep.

Only because developers don't reach for PyPy and Cython as much
as they should, rather re-writing everything from scratch and
they stating how they are impressed by Go.

On Wednesday, 30 April 2014 at 04:42:09 UTC, Dicebot wrote:
> On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote:
>> On Tue, 2014-04-29 at 22:09 +0000, Adam D. Ruppe via Digitalmars-d
>> wrote:
>> […]
>>> I can just get stuff done in D in a fraction of a time it takes to do even less in RoR.
>>
>> This is the stuff marketing campaigns are made from. As well as
>> informing the cabal that is this mailing list, there needs to be tweets,
>> Facebook, G+, and proper publishing articles of people switching from
>> RoR, Grails, Django to web.d and vibe.d and discovering (measured and
>> guaranteed) significant performance benefits in both time to market and
>> run time.
>
> I have a friend who has switched to vibe.d after being Erlang Cowboy devoted user for years. Trying to convince him to write an article about it but no luck so far :( Reason to switch in two words : "static typing".

I do like dynamic typed languages, but mostly for prototyping, scripting and tiny scale projects.

The type of code that we get to write at enterprise level, static typing is very valuable, specially given how management tends to enforce "write code not tests" and the skillset of certain developers across regions.

Code bases being worked on with 30+ developers across multiple sites get fragile very easily.

--
Paulo

On Wednesday, 30 April 2014 at 07:18:49 UTC, Paulo Pinto wrote:
> On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim Grøstad
> wrote:
>> On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote:
>>> Go has gained much of it's traction from provably and consistently
>>> producing simpler, faster and more reliable systems that C, C++, Python,
>>> etc. and getting articles about the success out there.
>>
>> Python is simpler than Go for web. There is a reason for why Go is still not in production on App Engine, you end up with more convoluted code as far as I can tell. Faster, yep.
>
> Only because developers don't reach for PyPy and Cython as much
> as they should, rather re-writing everything from scratch and
> they stating how they are impressed by Go.

thank god i'm not the only one who thinks like that. rob pike mentioned that there are much more conversion of python / ruby developers than c / c++ developers. and as we all know the  reason is the speed and there's a trade off. they're trading beauty, elegance, simplicity with ugly speed. i also think many go users are caught NIH syndrome. they are re-inventing everything. heck, they are even re-inventing nginx, redis, etc. because they are _not written_ in go.

on ruby on rails side, it is fairly very easy. i've built apps with rails and i've always been happy with it. some apps used rails defaults, some apps were very customised. the thing with ror is that it is never getting in your way when you open up your editor and start building your application and that's what i look for in a web framework.

On Tuesday, 29 April 2014 at 17:09:53 UTC, Adam D. Ruppe wrote:
> On Tuesday, 29 April 2014 at 15:55:13 UTC, Etienne wrote:
>> That's funny b/c most people say RoR made them love web development.
>
> That's probably because they went into it with very little experience with the alternatives. I was spoiled by my web.d and friends, as well as knowing how to use a real relational database, so getting on the Rails to me is like going back into the stone age.
>
> But if you came from mysql 3 and PHP 4 or some other primitive trash, RoR might seem like the best thing ever.
>
> I do kinda like the rails console repl tho. Of course, I kinda have that with cgi.d too, you can call its methods on the regular command line pretty easily, but that doesn't let you build up state as easily for quick changes and I do like that. (Maybe I'll offer such with my script.d, should be easy to add :P)
>
> the rest of it tho is just awful.

Is there any documentation for web.d, including example apps?
I'm using vibe.d at the moment and rolled my own customized DOM tree stuff (that was before I knew dom.d existed). I basically implemented the most important JS features for DOM manipulation and added stuff I'd always wanted in JS.

On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole wrote:
>> Having a quick look at Cmsed I must admit I like plain vibe.d much more despite the added features :( Forced module coupling and OO-heavy design is big loss compared to design simplicity and independence of base vibe.d modules.
>>
>> For example I can't imagine a single case when I'd prefer class-based route definition to stock delegate-based.
>
> The classes are unfortunately just a container for routes. So if you got a better way, that can provide the same functionality, I'd love for a plan on how to do it!
>
> Basically my idea is that you register as little as possible. That was why I went with a class for routes.
>
> I'm really gunning for less, simpler = more. And for medium-large sites thats kinda important.

Why can't stand-alone annotated function be a valid route? Route is pretty much method + url + handler and first two can be inferred by convention in many cases (as done in vibe.web.rest & Co).

Right now your approach actually results in more code than stock vibe.d (stand-alone function + explicit route registration).

On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
> But unit tests in D suck as well. I mean, how do I run a single unit test in D?

This is common complaint I still fail to understand. I have never ever wanted to run a single unit test, why would one need it? If running all module tests at once creates problems than either module is too big or unit tests are not really unit tests.