-
Notifications
You must be signed in to change notification settings - Fork 0
Ruby On Rails
This is a short guide to help current Ruby On Rails developers migrate to ChicagoBoss.
- In Short: “Performance, Scalability, & Robustness”
Ruby On Rails has been a very popular web development framework for years, and developers that use it benefit from allot of documentation, a huge number of libraries, and a strong community. However, the main strength and weakness of “Rails” is that it’s written it Ruby. Ruby is a fun and productive programming language, but suffers from the lack of a scale-able concurrency model. Ruby does offer a threading model to help provide some concurrency, but depending on the Ruby implementation you will have varying degrees of success. Many developers and organizations opt to use the JRuby implementation because the Java run-time provides strong support for threading without a Global Interpreter Lock (GIL) like the native C based MRI implementation.
The concurrency story doesn’t just stop with Ruby, but “Rails” itself did’t run in a concurrent fashion by default until version 4. Unfortunately, it relies on a real thread safe environment like JRUBY/JVM, and requires your code to be thread safe as well. Writing good thread safe code has always been tricky, and often leads to deadlocks and excessive context switching overhead. Yes it can be done successfully, it’s just more prone to error, especially when iterating code that changes dramatically over time. Additionally, it uses native threads, which are fairly heavy weight, and are fairly limited resources on most operating systems and hardware today.
The ChicagoBoss framework is implemented in the Erlang programming language, and runs on the EVM. Like Ruby On Rails, ChicagoBoss inherits the strengths and weaknesses of the programming language it’s built upon. Like all programming languages, Erlang has it’s own set of weaknesses, but it’s strengths are very well suited for distributed applications that are typically found on the Internet, and Intranets. One of the main benefits that Erlang, and the EVM, offer developers over Ruby and Rails is it’s excellent concurrency model. In Erlang, developers generally create a “Process” rather than a native OS thread. These processes consume very little resources and are managed by the EVM. In fact, a million processes could be easily created and utilized on a modern mid-grade PC, where a million native threads would be impossible. This level of scalability is possible because the EVM multiplex’s these processes on top of native OS threads automatically, and can do this on multiple CPU’s with multiple cores. This system allows the developer to utilize more of the underlying hardware with less effort, and generally fewer errors. There are a number of other benefits over Ruby and Rails that Erlang and the EVM offer web application developers that you can read about after a quick Internet search.
ChicagoBoss was highly influenced by Ruby On Rails, and resembles it in many ways. This makes the transition from Rails, easier because many concepts will move with you. In practice it will feel allot like using Rails, which is a good thing! Unfortunately, for current Ruby developers, Erlang and Ruby are very different. This isn’t to say that Erlang is hard to learn, it’s just different, and will take some time to learn. Additionally, the tools and libraries will generally have a different look and feel. For this effort, you will be rewarded with a tool that will allow you to build highly scaleable and robust application that require fewer resources than a comparable Rails application would require.
A key difference that current Rails developers will notice between ChicagoBoss and Rails, is a major reduction in “Magic”. This can be good or bad depending on your perspective. The fact that ChicagoBoss doesn’t have generators for everything means that you will have to create the models, controllers, and views manually. On the plus side, you are only creating what is necessary, and have a clear picture from the beginning of what going on in the application.
- Currently there is no notion of a central application controller. See:
Rails Like Application Controller?
And
Django Like Middleware?
More to come…