Hacker News new | past | comments | ask | show | jobs | submit login

Python has a roughly equivalent MVC web framework called Django.

Ruby and Python as languages are not radically different in kind, but their respective developer communities have had different focuses, and as a consequence the library of tools are not identical.

Ruby on Rails became popular because people were dissatisfied with the way that web development was being done, and DHH is very good at marketing/propaganda. Ruby on Rails has had a substantive effect on the way that web development is done, and there have been numerous attempts in other languages (that didn't already have a framework like Django) to recreate the things that Ruby programmers enjoy with Rails (CakePHP and Grails come to mind immediately).




This is spot on.

To elaborate a bit, Rails tended to have a lot more generated code (the fabled "magic") that really sped up development of your standard CRUD apps. As far as I can tell, this was fairly novel in web development. Django didn't really have a focus on that, you spent a little (lot?) more time configuring. It's better now though.

Of course, at the complete opposite of the spectrum, you have very minimalist stuff like Flask (Python) or Sinatra (Ruby) which is doesn't include a lot of bells and whistles. You'll have to import your own ORM, templating, etc...


I'll throw out another factor:

When Rails was introduced, there were no other substantive Ruby web frameworks - Ruby itself was relatively obscure compared to every other web-capable tech. As such, it (Rails) had no competition in the framework space. PHP, Java, Python and other languages all had competing web frameworks to choose from.


Ruby has nothing to do with Python. Python is strongely typed and compiled into bytecode, just like java. It is just not the bloated and verbose language java is , which allows fast and pragmatic development.


> Python is strongely typed

Like Ruby.

> and compiled into bytecode

Like JRuby.

Python and Ruby are comparable languages. They are both high-level dynamic languages, with the same sort of tradeoffs (eg, you can do more with less characters than in most statically typed languages, at the expense of safety and performance). There are however significant differences in terms of philosophy, ecosystem and community between the two.


As far as I know, Ruby has proper support for higher-order functions and lexical closures (aka code blocks).

http://stackoverflow.com/questions/4769004/learning-python-f...


Except you dont need a JVM to get performances in python. Using a JVM destroys any perspective of cheap and easy deveployement. If i have to use a JVM , i'd certainly not use JRuby when i can get scala.


> Except you dont need a JVM to get performances in python.

Python's performance is only slightly ahead of Ruby's. Both Python and Ruby are a bad match for CPU intensive tasks(provided we are talking pure python/ruby and not native extensions). Network and IO in general is salvaged by using evented io(or some high level evented framework).


Exactly. You have the same sort of solutions for squeezing additional performance out of Python and Ruby: - using evented framework (network/IO bottleneck) - using native code (CPU bottleneck) - using a different implementation (Python has an edge here with PyPy, as long as your dependencies run on it)


Because numerical processing is a major use case, Python has a number of techniques to easily speed up critical sections of code (numpy, cython, pypy).

I am not aware of comparable features in Ruby.


Numpy is a dedicated library where the critical code is in C, but that's a library, hardly a language feature. I don't know if there is any numerical processing library in Ruby.

Cython is not intrinsic to Python either. I see there is a ruby2c gem, but I have no idea how it compares to Cython.

As for pypy, that's about switching to a different runtime, the same way Ruby people would go to JRuby.

None of this turns Ruby into apples and Python into oranges, I'm afraid.


> Using a JVM destroys any perspective of cheap and easy deveployement.

I doubt that. The fact that jruby is close to bug-by-bug compatibility means that for most projects you can go and develop on mri or rubinius for fast development and use jenkins/travis/... to run your testsuite against jruby. You can then do integration tests as well as staging on jruby to catch anything your testsuite didn't catch. I've seen more than one large project take that course of action and do just fine.

Deployment on jruby isn't any harder than deployment on any other ruby. It's still "puma start" or whichever server you chose. You can however package your app in a war use a standard servlet container such as tomcat or jetty to deploy, but that's strictly optional.


I deploy SpringMVC apps, using an embedded Jetty instance into much the same environments as I do Python apps based on Tornado or Twisted.

The biggest win for me is dependency management. One my maven file is setup right, I only need a JRE on the host.. Dependency management is a bit trickier with Python, perhaps for Ruby as well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: