Comments for Jeff Vroom's Blog

Comment on Debugging Hard Problems by jeffvroom

jeffvroom — Thu, 09 Feb 2012 04:14:55 +0000

Great point John O’. Good luck with that bug. Maybe someone needs to build some nice tools to help track down Python/C++ memory problems. In the old days, Java memory leaks were a real challenge. You’d think they’d be easy cause the leak is actually a big pussball of objects in some reference chain. Just find the chain. Once the dump analyzers were written, they became easier as long as the leak was a really big fast leak. One hack I used before the heap analyzers was to patch in a modified version of the major container classes: Vector, HashMap, etc. to dump a stack trace when the size reached a threshold like (size % 1,000) == 9999. This would often find the allocation at fault without routing around in the dump even. You’d at least get an idea of the code paths involved in building the large data structures, assuming any one data structure grows large. Finding the missing “release reference” is harder though in mixed language environments. Code inspection seems like the place I’d start with that. Make an exhaustive list of all code paths that touch the leaked data object. Then follow each one methodically.

Comment on Debugging Hard Problems by JohnOS

JohnOS — Wed, 08 Feb 2012 04:55:04 +0000

Jeff: great post on a topic that deserves much more coverage. Especially salient for me right now as I;m working on a tough Python memory leak problem that is necessitating custom tooling in C++. On point 5, about theories, I find my own theories or preconceptions can sometimes blind me to the real nature of the underlying problem. I agree it’s important to keep an open mind. One little “meditational mantra” I chant to myself when debugging is “listen to the system”, Read all those stack traces, logs and err msgs again, with an open mind, and try not to force them into whatever hypothesis you favour at any given time.

Comment on Choosing Your Programming Language – The Inside Scoop by Frank Kim

Frank Kim — Mon, 30 Jan 2012 21:42:58 +0000

Heroku prefers Jetty too.
Great discussion Jeff!

Comment on Choosing Your Programming Language – The Inside Scoop by jeffvroom

jeffvroom — Mon, 30 Jan 2012 21:22:42 +0000

Oops… I’m embarrassed. I thought Node.js was just JQuery, not server side Javascript. JQuery is what I was talking about Node.js seems like a bad idea though I have not looked at it at all.

For simple things I use Jetty. I like Resin for performance/scalability/support.

I have heard Coffeescript is hard to debug and find the code hard to read. I think DART maybe a better alternative down the road.

Comment on Choosing Your Programming Language – The Inside Scoop by Frank Kim

Frank Kim — Mon, 30 Jan 2012 20:59:44 +0000

Jeff, good points about VPS. Which Java servers do you prefer using?

Jeff and Will, thanks for the feedback of Node.js. I found Node. js interesting because of how fast it ran. Seemed like a good solution for a server for mobile apps. But your feedback is deterring me.

Comment on Choosing Your Programming Language – The Inside Scoop by wsargent

wsargent — Mon, 30 Jan 2012 20:46:29 +0000

I don’t trust Node.js — it seems to me as if the rapid adoption is directly from JS engineers who see a chance to break out of client side apps into server side code. For me, the time to start using a new framework is when people start complaining about it and proposing workarounds.

Honestly, I don’t think anything will replace Javascript on the client side; it’s “good enough” for what it does and it is possible to use Coffeescript (or Uberscript if you really want types) to abstract the worst parts of Javascript into something usable.

Comment on Choosing Your Programming Language – The Inside Scoop by jeffvroom

jeffvroom — Mon, 30 Jan 2012 20:37:33 +0000

On the hosting question, I guess with VPS prices being so cheap these days, particularly if you can run with a low-memory footprint that hosting is not a big deal. As one data point, I have two Java servers running on a 256MB VPS for $15/month. I recently setup a VPS for a client and needed 512MB for Apache/PHP at $30/month and already had to reconfigure because we ran out of memory when a bit of load came in (apache was spawning too many processes I think).

I haven’t coded with Node.js but haven’t seen a technology achieve such rapid adoption in a long time. Javascript as a language I’d say suffers both the brittleness of typeless languages without any advantages in productivity like you get with PHP or Ruby. I played around with GWT but feel like it may be to heavyweight a solution… compile times are forever and debugging is challenging. I’d rather see a simpler, faster, more direct translation of Java to Javascript and where it wraps Node.js instead of implementing a new toolkit.

Go seems like a solid candidate to replace C for systems programming but who would want to replace C? I love C!

Comment on Choosing Your Programming Language – The Inside Scoop by Frank Kim

Frank Kim — Mon, 30 Jan 2012 11:39:45 +0000

Also what do you think of Go, http://golang.org/? Sounds like the designers were thinking about the same things as you did when they created the language. Google is supporting it in its app engine.

Comment on Choosing Your Programming Language – The Inside Scoop by wsargent

wsargent — Sun, 29 Jan 2012 21:49:04 +0000

If you have stateful features in your app, you typically rely on some sort of state caching — people started off with memcached, but I think NoSQL systems like Redis, Cassandra and MongoDB are more in use these days — they’re fast enough to provide run-time state to systems that expect to see a session.

If you’re using a stateful library that expects to have access to java.servlet.HttpSession (or even HttpServletRequest) then you have a problem in Play, because they’re just flat out not available. I had to fake one for Shiro: https://github.com/wsargent/play-shiro

More than that, many of the older Java libraries expect there to be a “session” of some kind available to the app — Hibernate uses one, Shiro uses one, and under the newer models with async callback you may not be guaranteed to end up in the same thread, or even the same VM. As in most architectures, the implicit assumptions are worse to deal with than the explicit compile time issues.

Regarding the source generation… yeah, compiled code is still faster than interpreted. Play 1.2.4 has templates based on Groovy — compare to Play Scala 0.9.1: http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

Comment on Choosing Your Programming Language – The Inside Scoop by Frank Kim

Frank Kim — Sun, 29 Jan 2012 20:22:02 +0000

Great post Jeff. I still am attracted to how quickly I can get a website up and running on RoR versus using Java. But I do agree that as the project gets bigger the benefits of RoR decrease quickly.

I think one other issue for the small developer is hosting. Though Java hosting is becoming more available the ease and number of choices for hosting typeless apps is far larger.

Any thoughts on Node.js?