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

Reply via email to