So, you do a crappy, unfair summarization of an article that, admittedly, isn't a great "intro to Rails," and this somehow gets to the front page of Hacker News?
To get Rails running on a Mac, you simply have to install XCode, run "sudo gem install rails && rails new blog." The included system Ruby will work OK for Rails dev (it's what I use 99% of the time just for convenience). If installing XCode and editing things freaks you out, then you may not be cut out for the level of coding required to actually use Rails. Things like Try Ruby, Shoes, Scratch, etc. exist for a reason; trying to shoehorn people into Rails too early is a Bad Thing™.
If you don't have a Mac, you can get running on Windows using RailsInstaller. If you're on Linux, I think it's fair to assume you know enough to install Ruby and friends with your package manager.
TL;DR: It's not crazy to get started with Rails; it's probably far less painless than most frameworks these days. And pointing to a fairly poorly written, overly verbose getting started guide and saying "ZOMG STARTING WITH RAILS IS KARAZEEEE!" is just stupid.
I'm not trying to pick on the original tutorial. There's a deeper problem here.
Yes, you can `sudo gem install rails && rails new blog`.
But that's not going to get you a suitable environment for any standard Rails project today. Especially not if it involves other people.
Installing things from gists using cURL, RVM, 1.9 (Lion still comes with 1.8), juggling gem updates, bundler, cloning git repos (submodules for plugins, etc.), etc., are all totally par for the course.
Unfortunately, I can't offer a better way to do it for Ruby. However, I fully intend to illustrate a better way to manage this sort of thing in other languages; specifically Clojure.
I'm not saying the Ruby ecosystem is perfect, but a lot of the problems are engrained in Ruby culture. Losing the problems will likely mean losing some of benefits of that culture along the way.
I've done a large project in clojure. It isn't any different with the exception that leiningen is also used to manage the version of clojure used for a project.
You have to install java first before you can create hello world in your text editor. That's the same as installing xcode. The point is to get a compiler, either the java compiler or the c compiler.
I'm not sure what your saying here. The fact that apple decided to bundle gcc with Xcode doesn't have anything to do with ruby or rails. On linux you are fine as long as you have gcc.
Bzzt wrong. Installing Java is the same as installing Ruby. The JDK doesn't include an IDE.
And why do I need a C compiler to work in Ruby, anyway? I assume it's to compile your own version of Ruby. (Which is another way the Java comparison doesn't work -- you need the Java tools to compile your own code, not to compile Java.) But why on earth would a newbie want/need to do that?
You're probably right. But at least in the Pythonverse that's something you don't run into right off the bat. The first step to getting started with, say, Django isn't "get a C compiler."
nor is that the first step for rails. But for anything non trivial app you will likely need a C compiler in the end. I'm guessing this is the same for python.
It's fairly uncommon in Python, at least in my limited experience. Libraries commonly advertise themselves as "Pure Python" to make it clear that they don't require compiling things in C.
If your project gets up to very large scale things are probably different, but there's no need to deal with that in a "Hello World"-type tutorial.
I'm talking about very common things. How do you talk to a mysql database, i'll bet it's C code. how do you parse html, i'll bet it's C. python has a json lib as part of it's standard library, ruby does not so you install it as a gem. Both are C.
Actually, django is worse if this tutorial is correct.
They are telling you to install a binary precompiled library. I much prefer having my dependencies managed as they are in bundler than downloading libraries manually and installing them.
Or you can just let your distribution's repositories deal with all that for you. On Debian/Ubuntu/etc. Django and mysql-python are both installable via apt. That manages all your dependencies nicely. The versions you get may be a little older than you'd get if you grabbed them from elsewhere, but usually not so much that you'd notice.
I know there's been some bad blood between the Ruby and Debian communities about Debian package maintainers not accepting bleeding-edge versions of Ruby software into the Debian repos; that may have been why Ruby went off and built its own set of package managers.
the ruby world moved away from this for a few reasons.
1. I develop on a mac and deploy on different linux distros. It makes more sense for me to have a single system for managing ruby dependencies than to do it with 3 or 4 different systems that work differently and may not be fully compatible. Plus, with bundler and rubygems I'm not stuck on whatever version the distro decides to support.
2. If I install something like the mysql driver manually or with apt-get, and then a year from now I'm no longer around and some other developer checks out the code ... how do they know which versions of the libraries were used? With bundler all versions of all gems are checked into version control. This is a big win, and they can get a system with exactly the same versions of everything with a simple 'bundle install' after a clean checkout!
Edit:
3. Also, there are likely to be C based python libraries you want to use that aren't maintained by your distro. Now you're in a situation where you are mixing multiple dependency management systems which gets ugly fast.
No, you can do hello world without a C compiler assuming you installed ruby from somewhere. If you want to use JRuby you will need a jvm for it to run on, this is the same as any JVM language.
You don't need Xcode to develop with Rails on a Mac. You just need to install Xcode to get GCC and various other tools that the Rails install process requires.
Yeah, those steps are pretty crazy. They also aren't official, and most of the work is in setting up RVM, which you don't actually need to use for Rails. Just about any non-ancient environment that has Ruby provides 1.8.7, which is the minimum you actually need to use Rails.
It's still pretty long, but most of that is introducing important Rails concepts and walking through a hello world.
There seems to be a tendency in the Rails community to go nuts with packages and blindly follow quickstarts. I've never appreciated it, but it seems like the Rails developers have been rather careful to avoid falling into that trap.
Whether or not you install XCode is specific to Mac, and always will be an issue due to lack of gcc by default. If you're on Ubuntu, it should be pretty easy to roll:
apt-get install ruby rubygems (or something to that effect)
IIRC, you don't even need a database created/migrated until you decide you need one.
I definitely think that Rails is harder to jump into now as a beginner due to the framework's evolution. However, these startup steps the author rants are all mostly "best practices" and not really necessary to jump in and start coding.
I tried getting into Rails using a tutorial similar to the one referenced in the posted article, and I feel the same way.
For me there was too much too fast. Something that was supposed to be easy was complicated. "Just run these commands" and it all works itself out.
I got as far as creating static pages, and a basic user authentication page, and quit. There was just too much to remember at first, and I didn't know what anything was actually doing. I was just mimicking the actions of someone else who did.
I've been writing with Ruby on Rails for about a year now. When I first started I had not coded much for a while so I was very rusty at coding in general. In my opinion, rails had an extremely high learning curve. It took me a long time just to get the environment up and running since I ran into a bunch of installation problems on a pretty standard setup.
That being said, I love RoR now. Now that I understand how gems and bundler work it is easy to add new features to my apps within minutes. I installed an entire admin panel in about 15 minutes. For someone with no coding background, I just don't know how they would get past the learning curve. I'm not saying it's not possible, but it would be extremely difficult.
This is mostly just picking on someone else's somewhat clumsy screenshot-based tutorial on how to get started with rails.
But the broader point is, I think, pretty valid. Modern web development is a huge mess. Tool upon tool upon tool buries the core protocols, to the extent that newbies never even get a hint about how simple this all really is. It looks like voodoo.
I beg to differ. I started doing rails before things like bundler and rvm. It was easier to get started back then, but without these tools most people found themselves in a pile of shit really fast.
I think the mistake people are making is assuming that what is best practice for a trained professional should also be the starting point for someone that is just learning to do web dev.
It's like saying, "building skyscrapers is too hard, there's all this stuff you have to know. Why can't I just do it like I did when I was a kid and stack bricks on top of each other?".
To extend your analogy, it's more like: here's how you build a house. Skyscrapers apply all of the same principles in a more complicated way, but this house here solves a very clear real world problem in a way you can understand and emulate for yourself.
Now, picture a world where all the "serious" people with "mindshare" spent all their time explaining why skyscrapers were the best thing in the world, and how only PHP-using dinosaurs would every build "houses" any more. And fast forward to the inevitable attempt to explain to construction newbies how to build skyscrapers from scratch.
So I ask you: where are the houses of modern web development? I don't see any. More to the point: I see some, but they're "old" technologies the cool kids don't use any more. Everyone freaked out about Rails not scaling up, but it also fails to scale down to the level of a new developer.
You'll never be able to equate Rails development to dead-simple, single-page PHP scripts, because they're not even remotely similar.
You want dead-simple, single-page web development in Ruby? Check out CGI [1]. Once you get in to Rails, all examples are completely incongruent, because you're dealing with a large(ish) framework. When you compare Rails to a framework like Symphony or CodeIgniter, the learning curves and tool stacks begin to compare a little better. I don't know what version of PHP ships with OS X, but I know the web is full of HOWTO articles explaining how to get a more sensible stack of PHP version x.x.x on OS X. Many PHP devs are how using Nginx with PHP-FPM, which isn't there by default. Then there's the question of versions. Does a version manager for PHP even exist? What happens if you need to run an old PHP 4 application?
Those questions are rhetorical. I'm sure they all have answers, but that's not my point. My point is: you end up with the same problems on a different stack once you move past trivial examples or start dealing with other people's code.
IMO, Rails scales downward just fine. A new developer shouldn't jump right in to Rails development. MVC is too complicated for someone who can't handle basic tools If you're uncomfortable with tool chains like XCode, Terminal, RVM, and Bundler, then you have some learning to do. You don't get to be a doctor without understanding anatomy, and you don't get to be a programmer without understanding the fundamentals.
Which sounds like you're agreeing with me. Rails (I'd extend the argument to most web frameworks, honestly) is simply too complicated for newbies. They should use something else.
So I ask you: if a platform is so complicated that it simply doesn't support new developers, can it survive? By analogy, is Rails turning into the C++ of web development?
I think the notion that a framework should simultaneously be suitable for someone who can't use a bash shell and able to host some of the worlds largest web applications is a little silly. You have to know what problem you're trying to solve. MVC alone is a bit much for a beginner.
Beginning programmers should not start with large frameworks. Period.
"So I ask you: if a platform is so complicated that it simply doesn't support new developers, can it survive? By analogy, is Rails turning into the C++ of web development?"
This is so tough to answer. From my perspective, the question is completely absurd. It's like asking "if a semi-tractor-trailer is so complicated that a new driver simply can't drive it, can it survive?"
Programming is conceptually difficult. Even with the best tools we have today, and probably the best tools we have tomorrow, programming will remain a challenging task. As the problems become bigger and more complicated, so do the tools. Rails is large, so there is a lot to learn. The notion of a framework is that we should avoid solving the same problems over and over again. People are often frustrated that it can take a year or more to really learn the Rails framework, but it would take orders of magnitude more time to solve all the same problems Rails solves if writing from scratch.
The more relevant question is, "What problem are you trying to solve, and does the Rails framework help you do that?"
A garden spade is fine if I want to plant a few daisies, but if I want to build an inter-continental pipeline, I'm going to need something a little more robust. I'm also not going to stick a 16-year-old driving permit holder at the helm of a multi-billion dollar tunnel boring machine.
This goes beyond "can't use a bash shell". I've written chunks of IP stacks, multiple implementations of HTTP as both clients and servers, and done a ton of server-side socket level code. I'm reasonably confident that I meet the requirements.
Yet every time I need to look at Rails, I run screaming because of the huge, steaming mess that learning it has become.
The point about C++ was real. It's exactly the same feeling I get when I bump into boost nerds who honestly think template metaprogramming is the path to the future.
I've come to the conclusion that large frameworks like this are meant for people that use the framework on a regular basis and can therefore keep it in their head.
I do web dev daily, so rails is great for me, but whenever I have to deal with someone's chef deployment setup my head starts to hurt. But they do devops everyday and chef makes their life easier so they get a lot of value out of it.
Calling Rails a "huge, steaming mess" could hardly be considered objective. Rails has a well organized module and class structure, and solves many common problems. It's a large framework, and when frameworks get large, they take a lot to learn.
I haven't seen anyone here say that rails is the right solution to everything. However, I have found that it is the right choice for the vast majority of web apps I've built. For most things you will want a testing framework, a model layer, dependency management, form helpers, routing and linking apis, etc, etc, etc.
And if you're doing a medium to large size, consumer facing web site, you'll want an asset pipeline.
If you want to learn the core protocols, couldn't you just start off with basics? Static HTML pages, maybe a bit of PHP for a server-side intro? JavaScript on your simple HTML pages? Sinatra if you want to jump into a simple Ruby web-app DSL?
Pretty much all frameworks seem complicated to me next to the core protocols. However, that's why I use them: they abstract the core protocols that I already know how to use, and make me more productive. If you're just getting your feet wet, don't jump into abstractions, and get down to the basics.
Not only did you write this article in an unreasonably sarcastic tone in response to a blog post that isn't the best "intro to Rails", but it's also clear that you clearly lack the programming experience to say that installing Rails is "insane".
> If you want to use Linux, sorry, you’re kind of on your own.
Rails does run best on a Mac, and there are reasons for that. However, it can also run on Linux or Windows with cygwin.
> Open the Terminal. Don’t worry about what it is or where it resides on your computer.
This is where I seriously doubt your ability to have a professional opinion on that. If you've never used the terminal and you're so unfamiliar with it then you're scared the author might be using an unfamiliar program, then how are you expecting to get started with a web framework that works exclusively out of a command line?
> Install a package manager. What’s that, you ask? Don’t worry about it!
Once again, if you don't know what a package manager is, maybe you should learn about things like this first- RVM works wonderfully with Rails gems, but you don't appear to have anywhere near the amount of technical knowledge to know that.
> Now quit the Terminal and re-open it for some reason.
Yes- you have to restart Terminal before using newly installed frameworks. This is basic terminal knowledge.
> I want to see people programming, and learning to program.
Excellent! Yes, the article you responded to isn't great, especially if the reader has little programming knowledge. But slamming Rails because it requires some basic skills around Terminal is inappropriate and reflects upon poor technical awareness.
"Rails does run best on a Mac" is an inaccurate statement. Rails runs best in a Unix-like environment, as opposed to Windows. Rails development on Linux is just dandy, and IMO, a step better because you don't have to go out and pick a package manager for all your core libraries. You still face the issue with compiling your own Ruby though. There's some sort of deep seated issue between the Ruby community and distribution packagers that I've never figured out. The version of Ruby that you can install with your distro's package manager is rarely the one everyone uses for development. I think part of this has to do with the break-neck development pace of Ruby in general.
I think you misunderstood my intent. I understand Terminal.app, package managers, environment variables and .bashrc, etc..
What I'm saying is that a "first steps to Rails development" tutorial requires you to gloss over things like the terminal and commands, all in the name of expediting the process of getting to the framework (the supposed goal).
Yes, it should gloss over those things. If you're getting into Rails, there's an understanding that you know what the terminal is. That's like complaining that a tutorial on how to make a good sandwich doesn't explain how to open a refrigerator.
Although this is a somewhat sensationalist blog post, I agree that web development should be easier. Web IDEs like Cloud9, Akshell (www.akshell.com) etc. and platforms with built in dependency management features should make it possible in the not so distant future.
Yes Rails was hard for me to learn at first, and even a few years into the framework I am still learning things all the time. Just like anything significantly complex.
And criticizing the XCode installation is completely missing the point.
To get Rails running on a Mac, you simply have to install XCode, run "sudo gem install rails && rails new blog." The included system Ruby will work OK for Rails dev (it's what I use 99% of the time just for convenience). If installing XCode and editing things freaks you out, then you may not be cut out for the level of coding required to actually use Rails. Things like Try Ruby, Shoes, Scratch, etc. exist for a reason; trying to shoehorn people into Rails too early is a Bad Thing™.
If you don't have a Mac, you can get running on Windows using RailsInstaller. If you're on Linux, I think it's fair to assume you know enough to install Ruby and friends with your package manager.
TL;DR: It's not crazy to get started with Rails; it's probably far less painless than most frameworks these days. And pointing to a fairly poorly written, overly verbose getting started guide and saying "ZOMG STARTING WITH RAILS IS KARAZEEEE!" is just stupid.