The Elephant: Why is JRuby such a polarizing issue? | Hacker News Reader

The Elephant: Why is JRuby such a polarizing issue?

blog.headius.com

25 pointsnickb27 comments

With Python, there is no real pain that alternative implementations can address. The canonical implementation is good enough, and it will remain a monopoly.

With Ruby, providing significantly better performance and reliability may very well unseat the monopoly of MRI, certainly for commercial applications. Since, JRuby actually looks like it may be able to pull that off in the foreseeable future, it's a much bigger deal than alternative Python implementations.

"With Python, there is no real pain that alternative implementations can address. "

No Java libraries seem useful enough to matter? Deployment tools? App servers? GUIs?

No, no, no and no. I've been able to work just fine with C/C++ libraries. I would use Jython only when trying to extend an existing Java application or when trying to sneak Python into a primarily Java corporate environment.

You will find that a lot of stuff in Java is done only because it has to be (elaborate J2EE app servers being an excellent example). If you just need to grab some records from a database and format them, you don't need all that scaffolding.

I have recently heard people saying Python is too slow and Java is preferred for some thing. Since I'm a bit of a newbie in the python world I'm not sure what to suggest.

Do y'all have an opinion on this?

The main thing that Python users complain about in CPython is the global interpreter lock, which restricts all the threads in a Python process to one CPU. (Ruby has this too.) So concurrency over multiple CPUs has steadily become more of a concern over the years.

Stackless came up with a solution, but Guido shot it down, and it appears be surviving somewhat in parallel. (No pun intended.) Jython gets rid of the GIL and uses native threads like Java, and is scheduled to come out of its half-decade coma sometime this year. The mainline CPython implementors insist that getting rid of the GIL would cause infinite headache, but they're offering a reasonable substitute in Python 2.6: the multiprocessing module, which has a thread-like API but uses separate OS processes behind the scenes. So, I don't think there will be a mutiny over this.

I watch the python-ideas mailing list and there has been some talk recently of bringing some of the micro-threading ideas from Twisted into the CPython implementation itself. I don't have much knowledge of micro-threads or Twisted so I haven't been following the conversation very closely, but at least that's another data point in the state of parallelism in Python.

Kudos for all the hard work he's put into JRuby. He's very passionate and has obviously put in a tremendous amount of effort into this project. Definitely the spirit of a true hacker!

I avoid JRuby just because I'm never very confident on a non-standard platform. I'm not a bleeding-edger, especially with things that I don't like debugging the hell out of.

Just like I don't swap out OS libraries for fun, I don't replace the underlying bedrock of a language for a giggle either. If I had a compelling reason to use JRuby (for example, to get access to all the great Java code that's been written), then it would be more compelling. Until then...if it ain't broke...

What's non-standard about JRuby? There's a language specification and there are various implementations. The only "standard" is the specification.

FTFA: "Some of them have been Rubyists longer than anything else (or maybe just longer than anyone else), and see themselves as the purists, the elite, the Ivory Tower, keepers of all that's good in the Ruby world and judge, jury, and executioner for all that's bad. In the end, however, there's one thing these folks share in common.

They think JRuby is a terrible idea."

I've been a Rubyist for about 8 years; I love JRuby!

And Headius rules. (As does Tom and the rest of the JRuby team. #jruby on freenode rocks.)

I liked the line: _We build a layer on top of that shim that better exercises Ruby's potential, or we help build a new wrapper to replace the old._

I think this is a great idea - it's the ultimate technical jujitsu. Take the weight behind Java and use it to give you a leg up.

The org I'm at is attempting something similar at the moment.

Course. Getting the wrapper/interface right becomes pretty important, but this is always the case.

Agreed. Writing such a wrapper also introduces the possibility of someone later implementing the same library for Ruby itself. As long as the wrapper's interface makes sense and the library is worthwhile, there is no compelling reason that the Java bits underneath couldn't be replaced by a C library and some glue code.

I used JRuby on a few projects and was able to sneak it in the door in corporate america cause it was still java.

Like I've said before and I'll say again because it's important to realize:

Computer languages are just as much social/cultural/psychological constructs as they are technologies.

Without knowledge of JRuby, IronPython or Jython, I'm curious how Python's low tolerance for code formatting flexibility has helped here.

Anyone?

Python is intentionally simple to parse. The whitespace thing (if that's what you're referring to) goes like this: if a line is indented one more level than the previous line, that span of indentation becomes an <indent> token, applied for the rest of the indented block. So to figure out scope level for a given line, look at the number of leading <indent> tokens. That's it. Google knows more.

If I've said it once I've said it a thousand times: Python cares about indentation not whitespace. You can format your code any way you please, but it turns out that arguments about where to place curly braces don't actually contribute to getting real work done, and Python people don't miss them.

In perl you can write 'if(!bool) { ... }', 'unless(bool) { ... }', or even '... if(!bool)'

As I said, I'm not an expert in the languages in question, but the scope of code formatting flexibility is larger than just whitespace.

In Python you can do the same: 'if not bool: ...', 'while bool: ...', '[for ... if not bool]'. Crazy one-liners are also possible.

We have just enough formatting flexibility and we prefer readability.

It makes me feel dirty having a script interpreter running on top of a virtual machine.

What makes Java programs not "scripts"?

Java, Ruby, and everything else are all the same at some level. They let you type in instructions for the computer to execute. A VM is an execution strategy. Why does the front-end to that strategy make a difference to you? (Or rather, why do certain front-ends make you feel "dirty"? I think it's because you have no idea what you're talking about.)

I think the OP is trying to say that all dynamically typed, interpreted languages are implemented in statically typed, compiled or JIT languages. If you like the discipline of the latter, you might resent the former.

Hasn't Java had a JIT compiling VM for a while now? And in the times I've used it, it has certainly seemed statically typed and compiled (to Java bytecode) to me.

If that's the kind of thing that makes you feel dirty, I might suggest turning your computer off, and going out drinking...

Actually, I'm going to take you up on that offer. A beer sounds really good right about now.

JRuby isn't polarizing; Ruby attracts already polarized people (present company excepted.)

I can't think of another language that has attracted as many idiots. Visual Basic comes close, with alarming parallels.

Reply on news.ycombinator.com