Show HN: God mode in production code – a new way to debug in Scala (opens in new tab)

Closest I know of is IntelliTrace: http://msdn.microsoft.com/en-us/library/vstudio/dd264915.asp...

IntelliTrace is far more powerful: http://msdn.microsoft.com/en-us/library/dd264915%28v=vs.110%... .

There's Windbg/SoS for the times you would need something like this.

Decidedly not as pretty, but pretty effective if you know how. Channel9 has a series of videos on WinDbg for .NET developers.

I have used Chronon for several weeks during a very strange project. The project was about integrating a highly complex financial system in our own infrastructure. The challenging part about this financial system was that it was written in a multitude of languages (Java, Perl, C, C++, ...) and that it had to communicate with external services and it had hard timeouts built in which were enforced externally. So if something went wrong and I wanted to find out I had only 20 seconds in the debugger to find out because then the timeouts would kick in and there was nothing I could do about it. With Chronon I was able to step through the code after it had already run with no time constraints. Saved me weeks...

Chronon is also useful to find all thrown exceptions - even the ones who are catched properly.

I am not an employee of Chronon Systems and I only used their tool once but it helped a lot.

Unlike Chronon, Takipi is built for monitoring your JVM in production, imposing minimal and predictable overhead.

Or by using a better type system. Or by using the type system that's available in the language. Because it's all too easy to ignore the types and for example call `get` on a Scala Option value, or `fromJust` on a Haskell Maybe. Both will throw an exception at runtime if the Option/Maybe is empty.

Passenger Enterprise supports a live irb and debugger: https://www.phusionpassenger.com/enterprise#debugger_support

The product consists of a slim JVM agent which connects and offloads the heavy crunching to Takipi's backend.

The agent only requires outbound HTTPS over port 443, and fully supports proxies.

Ditto, just sent an email asking about this. There's a number of industries which frown upon allowing any sort of code or production data to be sent to a 3rd party host.

No they don't. They just allow for fix and continue; they give you no insight into why a problem occurred because they provide no history.

Takipi may be installed locally; the same installation process will work. However, it does not provide live debugging like in your IDE, but rather a post-event drill-down (a "time travelling debugger"), as it is designed for testing/staging/deployment environments.

From the FAQ:

  Which languages do you support?

  Takipi works at the JVM level. This means we support all languages running on the Java Virtual Machine. These include - Java, Scala, Groovy, Clojure, etc.. Click here to learn more about viewing Scala code in Takipi.
  We plan to support more software VMs such as CPython and Ruby MRI in the future.

Just FYI, most of this is a lot easier in python. You can get the full stack trace and all of the values of all of the variables when there is an exception, something that is orders of magnitude more difficult to do with Java/Scala.

You'd have to be a bit creative to get the "full variable value history" stuff working, but it would probably be possible with some hacking on the setattr methods for your objects (assuming you have full control over the system)

I had a bunch of code like that for my previous (python) projects. I've really missed it now that I've moved to scala/java, so I'm pretty excited for this project.

Thanks, you're welcome to take Takipi for a test drive and let us know what you think :)

You know, preferably it should actually make your servers run 5% faster :)

Seriously though. Did you really expect a tool that continuously monitors your app and can produce stunning and relevant information about states leading up to a crash to have no effect on performance?

This is just an observation and not meant to be an insult. I am just using your comment as an example of why I believe you are incorrect in your final statement.

In your post you have several misspelled words (smalles, programms,abbilities). In only a small number of lines of text you have many errors. A spellchecker is a wonderful tool too and you would have benefited from it. Imagine this now being hundreds, thousands, even millions of lines of code. A simple misspelling in code may lead to a compile error. It may actually be a call to a different function or perhaps just the wrong seed value was set. Saying that only thinking about something rather than using a tool that can help you is just a strange and dangerous advice. Not to mention quite expensive. I don't believe the point of this tool is to "debug your way into a new application".

Again, this I just my opinion and I used your comment as my example of how tooling is important. Your misspellings could have caused confusion or a complete misunderstanding of what you were trying to convey. The same problem exists in the programming world. If you say the wrong thing it's very difficult to find out what happened without digging in. Any tool that can help you achieve the answer faster than yourself is a good tool.

As for the actual Scala tool, I like the monster graphics. I think I need to ask them for a shirt.

So you don't need any tools. Good for you.

For the rest of us, having a tool to step through complex things like threaded recursion is really convenient (not that I would ever consider threaded recursion in any situation).

Tesla was a genius; he often bemoaned the way Edison would perform a hundred experiments to discover something which was (to him) obvious if he just thought about it for a bit. But you know what? Edison succeeded where Tesla failed, and a good part of that can be attributed to reducing the art of inventing to an almost mechanical process, leaving his intellect free to concentrate on more important matters.

It's the same with debugging. I've worked with many programmers who took your attitude; some of them were more talented than I. But I fixed bugs faster than them, and got more done, because I let the tools take care of figuring out what was happening in a program to cause a bug, leaving me more time to think about other things.

Of course, everyone would prefer to know the answer to their issues without any tools. As your code base becomes contributed to by more people, grows in size and leverages libraries you don't write, it becomes less feasible to always divine the state of the entire program. As component of a programmers skill set as a whole, better tools produce better results.

you haven't seen aged code base with 3000+ JSP with many ways of accessing different data sources and no coherent paradigm in general.

Wow, I didn't know about the down votes. Nice lesson.

I guess I could have formulated this differently. Attempt 2:

"Sure more powerful debugging tools is a great thing but the best ones are those you never use".

I can see you've never had to debug multi-threaded code or use 3rd party software ever or a project too large for one person to understand or a misconfigured webserver on the other end.

Why require me to think like a computer when the computer is right there and can think for me? Just because I can do math in my head doesn't mean I should.

Tesla was also nuts. So, there is that.