Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I tried truffleruby for the adventofcode challenges. Almost everything ran faster with normal ruby. I got a stack too deep error in truffleruby that I didn't get in normal ruby. I don't recall having more problems with memory with one or the other. There was one case where truffleruby was really useful though.

Thus I'm with you that it's not a systems programming language. It seems good for processes that stay ON, like servers.

But then when compared with PHP, during development you don't need to worry about the server, it just takes the most recent version of your code. Surely hot-reload can be a solution with java, but in practice it's a complication, especially if you're part of a team/project where there is no hot-reload support.



The JVM doesn't attempt to compile a method until a method has reached 10,000 executions. So it's extremely likely your code ran the entire time in interpreted mode. Even if a method did get flagged as hot, you've then got the time taken to do the actual compilation to native code to contend with.

If you're trying to write systems code and want to use the JVM, GraalVM can do full ahead-of-time compilation and will get you almost instant start up with all methods natively compiled.


I don't follow. Seems like the issues you had were due to truffleruby and how it implements ruby's internals on the JVM.

That's not a Java/Kotlin/JVM issue.


Why would you expect any speedup for programs that run for a split of a second?


Indeed, nothing really surprising. truffleruby+graalvm started to be useful for programs that took roughtly 15s or more to run.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: