Hacker News Reader

Comment by fat0wl | Hacker News Reader

yea this attitude is a BIG part of the reason i switched to Java. If you learn some common Java design patterns (ahem... program to interfaces) then all of a sudden the magic of Ruby doesn't seem to add that much (in fact the data-binding in Java usually simplifies form validation). So then with a huge boost in performance for free, all of a sudden hosting costs are far lower and less billable hours are put to testing cache expiration.

That said, I will still probably end up migrating toward Clojure/cljs and js-focused apps...

EDIT: It's a waste to bleed a client if all your blood-money is going to Heroku! XD

View on HN

This is a serious question, though a tad off-topic: what tools do you use in the Java world?

I've tried to get into the Java web world, but it's always felt like the tools weren't what I was looking for. Partly, it always feels like the Java world builds so many ways to do things that it's hard to get a feeling on what is canonical. Even with something like Play, should I use Java or Scala? If I use Java, should I use Ebean or Hibernate? If I use Hibernate, should I use XML or. . .

In some ways, it feels like Java advocacy is focused on non-coding managers. Or maybe I just don't know where to look for developer-focused advocacy.

For example, in the C# world, Microsoft has done a decent job telling developers how to get started and why they should care about .NET MVC. In the Java world, it's hard to know where to get started: Spring, Play, Ninja, Wicket, Dropwizard, Tapestry, Wicket, etc.

I guess I'd love to hear your recommendations and experience in moving to Java.

Seconded!

I think it really depends on your goals. You can look at JEE for enterprise standards , JSF, JAX-RS, EJB, JPA or look to the spring stack which may be a easier to work with such as spring mvc, spring and some mix of spring jdbc or spring data. I think in general you can look at how a project like Play integrates these various frameworks and start from there.

it's funny i probably won't give that much actual tech advice here but will relate a little anecdote. I was once asking in a forum about moving from RoR to Clojure, trying to calm my nerves, and some Clojure dev straight up asked me "Out of curiosity.... why is it that a lot of web developers think that Clojure isn't an adequate solution for lightweight apps?" and I remember saying something like "Well.... I think because it's not like a full-fledged framework with built-in ORM and a prescribed workflow" etc. etc. and as I was saying it I had this epiphany -- a lot of the JVM guys are so used to figuring out tooling and library integration that while the rest of the world is looking in and saying "How do you start from scratch like that?" a lot of them are looking out and saying "How come you guys are trying to solve a variety of problems all using a single tool?". Code is code, and a lot of web programming is just accumulating strings.

So yeah I'd say I'm pretty early in my endeavors (I mean I code using a Java tool for a corporation but there is a pretty strict workflow for that) but as far as open source & my actual education is concerned, ok I'll give you tech advice --

short answer: https://spring.io/guides

1. Java has a number of MVC solutions. Pick one & study it, probably with a tutorial/guide. Don't focus on the amount of configuration available (the cruft), just follow a tutorial to get a few hello world kindof pages. You'll see that it's not nearly as difficult as one might imagine. I first studied JSF, then Spring MVC (in retrospect, Spring MVC is probably a better starting point. I think it is also really hot in the job market.)

2. Pay attention to the terminology (research every unknown acronym) and see how it is an analogue to something you're familiar with.

3. Make note of the features/points that are not available in the language/framework you currently use. For me, data-binding to a form was the first thing where I thought "woah thats so much simpler...". Look up PrimeFaces or something like that if you want to see an explicit/obvious example of this, though personally I'm not sure I'd use it in practice (Spring itself offers data-binding stuff).

4. Research some JVM framework that is similar to one you are already familiar with (Play is a good start here or again Spring MVC if you're not afraid of Java syntax) and figure out how to make some basic pages, then add some logic.

5. Study the relationships between servlets/classes/beans/etc, figure out how they are scoped. A lot of it is pretty much free-form code and frameworks like Spring will let you do pretty transparent things before you get deeper into more nuanced app-flows.

6. Protocol is usually pretty easily determined by app needs. I like to default to json since I do a lot of javascript and it seems to fit better with REST, but internally lots of java apps & web services use XML. This hasn't really hurt my brain at any point yet.

7. And finally, when in doubt, try a pure Java solution until you realize that you need a tool. I think this has really been key for me. I could build apps on a similar level to what I was doing in RoR without many fancy libraries, and now I'm learning enough of each that I can make a more educated decision when the application actually demands it. I think all the choices can be daunting but the power of the minimal tools is enough that the entire chain isn't necessary for every application.

8. Oh, plus one more! If you like some other language (for me it's Clojure) study the language in it's pure form plus throw in a little study of Java interoperability in case you'd like to use it sparsely within one of the tried & true Java frameworks. This may not be possible without some meditation on it...

There are lots of templating languages available so as always you'll often just be injecting stuff into html. Many frameworks are just turning into a home base to shove fancy javascript frameworks into so depending on your app, you may not even need much server-side code (in fact I think this is why some of the simplistic monolith frameworks are surviving so long).

And of course, I don't know everything.... so maybe the JVM isn't the answer. I'm just having a lot of fun learning it, and I was once a Rails guy.

The problem being, of course, that you're then writing Java. :)

I still really like Ruby for its expressiveness and malleability, and don't plan to move away from it any time soon, but a lot of that means digging into these libraries, finding problems, and fixing them. I really enjoy that process, but it's rather inefficient for me to be responsible for the performance of every library in my stack.

Ruby has a reputation for being slow, and while it's true that you're not likely to ever reach statically-typed language speeds, it can be pretty decently fast. The danger with tons of abstraction is that a performance hotspot buried three libraries down can turn your otherwise-fast application into a tarpit. If Ruby library developers made performance analysis and optimization a goal alongside "beautiful code" and "DRY", Rails applications across the board would get substantially faster without changes to the underlying VM.

For example, Sprockets uses Pathname heavily. Ruby's stdlib Pathname is extremely robust and extremely slow. This slows down path resolution for every single asset quite a bit. My custom-patched Sprockets does asset resolution and compilation around 43% faster than stock Sprockets. As you can imagine, this has tangible benefits in the speed of my development cycle, and substantially increases my happiness. I opened an issue on the Sprockets project, but it was closed as requiring too-substantial a refactor. Imagine how many developer-hours would be saved if the Sprockets maintainers were to fix that hotspot?

you're right on about this stuff. someone once told me "yeah rails is great except the libraries have fugly internals"

but it's trueeee I prefer scripting languages to Java but there are a few of them available on the JVM. To be honest, I think the right balance is in the dynamic-OPTIONALLY-static typed languages.

Java interoperability solves this in a way... I've been taking a look at Dart for similar reasons. I just don't think the answer for me is RoR. Once I learned a Lisp (Clojure) and a lot of javascript I realized a lot of the syntax features I like about Ruby exist in many other places

What RoR really has going for it is the gem community, but if they're hard to trust and come with a slew of other problems...? Tough choices

I'm on the Dart team, and we've heard a lot of positive feedback from Rubyists. Come join us on #dartlang or misc@dartlang.org if you have questions. We'd love to hear what someone thinking of migrating from RoR needs.

I was really curious to see the pull request, so I hunted it down: https://github.com/sstephenson/sprockets/issues/506

Edit: if you just want to install a gem and skip the why, the parent has this blog post: https://www.coffeepowered.net/2014/02/09/faster-pathname/

It's worth noting that I don't really like faster_pathname as a solution. It's a cudgel that monkeypatches the stdlib Pathname. A proper solution would be a Pathname subclass that Sprockets uses directly, allowing for customized behavior without potential side-effects in other systems.

"Ruby has a reputation for being slow"

Web services that DO use Ruby today are almost always IO bound. For web services that don't require data crunching CPU bound processes, Ruby as a language is hardly the bottleneck.

Don't confuse being IO bound for not having CPU overhead. Being IO bound just means that your app is going to hit a concurrency ceiling due to IO before you hit full saturation on all your cores. It does not mean that a given request can't be faster. Despite the fact that our apps aren't CPU-bound, a few years ago, I patched some performance problems out of Haml and shaved multiple dozens of milliseconds off of each of our requests. That translates into faster page renders, snappier responses, and happier users.

While faster view renders might not improve your theoretical maximum throughput, it will certainly have a positive impact on your users' experience.

Very strange to have a programmer culture that is afraid of thinking about performance.

It's treated like a hobgoblin.

Reply on news.ycombinator.com