Hacker News Reader

Comment by fleitz | Hacker News Reader

"That along with the news that Twitter has hired 25 more employees kinda tells that Java's code base is practically more maintainable than equivalent Ruby code"

Uhh if you need 25 more people that tells me that your code is less maintainable and you're writing much more of it. No one has ever debated that in raw execution speed Java is faster, the problem is that most startups have plenty of CPU and few devs.

Twitter really did things ideally, start on a rapid dev platform and then port to a faster platform after acquiring the userbase and capital infrastructure that makes such a decision make sense. I'm not sure that if I was working on the JVM that Java would be my language choice, I'd probably use Mirah/Clojure/Scala.

The extra 25 devs are probably to ensure T2EE (Twitter 2 Enterprise Edition) compliance and refactor their POROs (Plain old ruby objects) to work with their ETB middleware. /snark

View on HN

I like my Python options - to start with Python, pinpoint the hot parts and going from hand-tuning Python code, Cython and then C - is a better option. They started with Ruby and Rails and, possibly, their optimal path was this one: Ruby, then Scala and then Java.

But that's one path I would rather not go down. Not unless I could use another non-Java JVM-friendly language. Java is very low-level compared to Ruby, Python or Scala. C++ is lower still, but the extra performance and control it gives you, as well as a free LLL-to-HLL boundary, are worth it.

I think you nailed it there.

Most startups fail anyway, so devoting a single day more than needed on development is a waste of very valuable time and money. How many extra VPS' is a month of saved development time worth?

All skill being equal, choosing Java over Ruby for a new project is one of the worst cases of optimize early I can imagine.

I also thought that was a weird comment. But In my experience a big team benefits from a compiled, statically typed language like Java (better yet, Scala). Perhaps that's what the author meant.

> But In my experience a big team benefits from a compiled, statically typed language like Java

My experiences with Java have never been very impressive. Why do you think a bigger team benefits from static typing?

Because you don't end up breaking code in trivial ways, eg if you have a method that takes a string and change it to take an int it's fairly easy in a statically typed language to figure out all the places you broke the code.

Large teams should be hunted down and broken into smaller teams, it's a stupid idea to have such a large team anyway.

The biggest problems in Java are not static typing (although inferred typing is much better). They are the lack of first class constructors, functions, unsigned types, operator definition and overloading and closures. The one actual feature Java has that no one else has is ironically one that is also one of the worst things about Java: checked exceptions.

When java lets me write something like: let (|>) x y = y x is the day I'll consider using it again, btw the above code is the pipe operator which lets you do things like this.

  "Hello World!" |> puts

Ruby has a little different mentality (duck typing), for example both of the following work:

  "10".to_i #=> 10
  10.to_i   #=> 10

I can see how dynamic typing, lack of interfaces, etc. can seem to cause a bunch of confusing to someone who's used to static typing, but in my experience lack of code readability is far more troublesome.

I've worked in ruby, python, java, and most recently, scala -- on both small and large projects. Tangled hairballs and hidden runtime exceptions can happen anywhere. I've just seen less of it with Java. I think this is partly because the compiler catches things that one would need to write tests to catch in ruby. For me the compiler is another layer of defense keeping bad code out of production.

Another advantage of statically typed OOP code for big teams is it allows a verbose yet formal way to define interfaces as a team, and then break up the work into smaller chunks. The formality can certainly slow an individual programmer down, but in a big team I've found it makes breaking up the work easier.

I wouldn't argue against the notion that ruby's expressiveness and use of functional paradigms might make up for it's lack of static typing, and ruby in the hands of a great programmer is pure pleasure, but most teams don't have just great programmers.

Finally, I absolutely love Scala and I think it's worth mentioning in any discussion of ruby and java. It, sorta, bridges the gap between the two languages and I'd recommend it as a good choice for a team of any size.

Sounds like someone isn't testing their code. "one would need to write tests to catch in ruby". You're damn right you need to write tests to catch problems in Ruby, as you should probably be doing anyways - in any language - in which case confidence gained from your test suite is almost entirely redundant to the confidence gained from successful compilation in a static language.

But if you're not testing your code, then the compiler is indeed a great dose of confidence.

I do, though, firmly agree with this: "I wouldn't argue against the notion that ruby's expressiveness and use of functional paradigms might make up for it's lack of static typing, and ruby in the hands of a great programmer is pure pleasure, but most teams don't have just great programmers."

Ultimately things do depend quite a bit on the developer resources you have.

I also love Scala, but how do you do your web frontend? Using Lift? Play Framework? I'm currently developing a side project with Lift and lets say I like the Scala-part of Lift.... The web part doesn't feel nice (also I don't like the last decisions made by the Lift Team). Currently I'm looking into RoR and I like what I see.

So, what I would love to see is a Web Framework similar to RoR written in Scala ...

I've heard good things about Play, but we've chosen to go with Spring MVC because we didn't need the full stack -- we have a lot of existing Java ORM-ish code and a bunch of existing JSP functionality which we wanted to re-use. JSP is actually our biggest pain point at the moment (aside from generally suckiness, it doesn't work with scala collections), so we're looking into using SSP via Scalate, but we've yet to make that move.

Aside from JSP, we're really happy w/ Spring MVC. We've managed to avoid the crazy amounts of XML that Spring is known for in favor of its more modern annotation-based way of doing things.

I actually don't see what the two have to do with each other. It wasn't even implied that the new employees were hired specifically for that team, which they probably weren't. Twitter is doing a lot of new hiring now and I doubt it has anything to do with switching parts of their site from Ruby to Java.

Reply on news.ycombinator.com