4 ms·
yes I don't want to get into a flamewar either, but I am an ex-RoR dev and since switching to enterprise Java I hear almost nothing about it largely due to enor
by fat0wl 12y ago
yes I don't want to get into a flamewar either, but I am an ex-RoR dev and since switching to enterprise Java I hear almost nothing about it largely due to enormously widespread acceptance of Spring (JavaEE is even re-gaining some traction).
Long story short (and hope my facts are right! not swearing by this, was just some googling...), I had to optimize some old code for an RoR client I freelance for and wanted to add in some more advanced ORM (still fairly simple though, mapping entity results from a stored procedure query). All the solutions I saw for this involved kindof hacking the db connector to execute some raw queries. I was curious as to why such a basic feature wouldn't be natively supported, so eventually I found some forum posts asking why it isnt (it may be by now) and all the responses were in the vein of: "That is not the Rails way and therefore the core team chooses not to support those types of features".
I know people think Java is too bulky & sprawling but after 6 months with JPA, SpringData, Spring JDBC etc. I was kindof left with the feeling "Man, there is a bit of a learning curve to pick up the overarching concepts of the Java ecosystem and its design paradigms at first, but once you are over that hump you can do more, easier with any ORM lib than with ActiveRecord". I know there is another Ruby ORM gaining traction (DataMapper) but it just seems that the opinionated nature of Ruby/Rails core dev teams makes it doomed & dangerous for enterprise use (and indeed maybe its not even their goal).
The Java approach is bulky and design-by-committee for sure but their userbase seems to demand that the fullest possible spectrum of features be supported, and then the library developers try to provide their recommended approach for new projects. Also the specs expand pretty quickly... had to use JPA 2.0 for some projects and found myself constantly frustrated because in the advancement to 2.1 there seemed to be a landslide of awesomeness added to support missing advanced database features.
I guess its one of those things where now it feels like a breath of fresh air thinking "I have more power in my pinky than....". It's a shame too cuz I still get calls from companies in a lurch desperate for RoR devs but philosophically I just can't bring myself to go back in that direction after seeing how unscary & mind-bogglingly powerful the enterprise langs have become. In part thanks to RoR, I'm sure! Wouldn't mind using it for front-end but all that stuff is so interchangeable, the syntax diffs are barely noticed in the development process. I think really the only front-end techs with noticeable differences in feel are the ones with advanced data-binding/component libraries.
Maybe there are some mind-blowing gems out there now though? Who knows....
- Doctor_Fegg 12y agoDataMapper isn't gaining traction, sadly. v1 is abandonware, v2 forked off to become a different project called ROM (which explicitly "isn't an ORM"). I still use DataMapper v1 because I find it a thousand times nicer than ActiveRecord, but it's a minority taste.
- MBCook 12y agoThat sounds like a philosophy of RoR, not Ruby. How would adopting RubySpec help with that?
- atmosx 12y agoThe author claims that he is a professional developer, while bashing at a programming language (Ruby) because he wanted more abilities from an ORM (AR) of a web framework (Rails). He thinks that DattaMapper is trending, when it's clearly not(!!) and doesn't know Sequel (another popular actively developed ruby ORM). Hence it's easy to deduce that he doesn't have a clue about the landscape he is talking about. Yet he is bashing Ruby as if it's hard to write a module with a couple of complex, custom-made raw SQL queries. ... blah! ...
- dankohn1 12y agoYou are ignoring a decade of history in declaring Rails to be "dangerous for enterprise use". The reality is that Rails apps are used in thousands of enterprises around the world, as well as in "web-scale" businesses like Github, Airbnb, and Groupon. However, Rails (and specifically ActiveRecord) has a very specific design philosophy (see http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... ) which does not include support for stored procedures (because business logic belongs in the app, not the database). Of course, there are ways to make stored procedures work with Rails (see https://github.com/leopoldodonnell/uses-stored-procedures https://github.com/leopoldodonnell/uses-stored-procedures ) but they are likely to end in tears, since you are working against the grain of the framework. The basic argument for Rails is not about support for or against any specific underlying technology (if you can reach Facebook-scale on PHP, then you can make anything work), it is that using a mature and well-crafted framework maximizes developer productivity. For most startups, as well as most enterprises, that is the critical resource.