In my experience, Ruby starts fast and does everything fast. But you can make a case against Ruby if you want, by making it do a lot of CPU work for a long time. Java may take some time to warm up and then it will destroy Ruby.
But why not simply write the code that needs to be fast in C and then use call it from Ruby?
In the unix world, the usual philosphy is tko start with a script (bash, awk, perl,…), then move to C and the like when the usecase is understood enough. So it’s more like a switch from programs and ipc to libraries and function calls.
But there are stuff, you immediately know you want a program, but they’re likely to be related to stuff like pure algorithms, protocols and binary file formats
> But why not simply write the code that needs to be fast in C and then use call it from Ruby?
Because often that's a can of worms and because people are not as good with C as they think they are, as evidenced by plenty of CVEs and the famous example of quadratic performance degradation in parsing a JSON file when the GTA V game starts -- something that a fan had to decompile and fix themselves.
For scripting these days I tend to author small Golang programs if bash gets unwieldy (which it quickly does; get to 100+ lines of script and you start hitting plenty of annoyances). Seems to work really well, plus Golang has community libraries that emulate various UNIX tools and I found them quite adequate.
But back to the previous comments, IMO both bash and Ruby are quite fine for basic scripting... if you don't care about startup time. I do care in some of my workflows, hence I made scripts that pipe various Golang / Rust programs to empower my flow. But again, for many tasks this is not needed.
> the famous example of quadratic performance degradation in parsing a JSON file when the GTA V game starts -- something that a fan had to decompile and fix themselves.
I actually hadn't heard this story. Is the gamedev world still averse to using proper modern C++ with basic tools like std::map and std::vector (never mind whatever else they've added since C++11 or so when I stopped paying attention)? Or else how exactly did they manage to mess it up? (And how big are the JSON files that this really matters, anyway?)
> IMO both bash and Ruby are quite fine for basic scripting... if you don't care about startup time.
`time bash -c ''` is only a couple of milliseconds on my system. The slow thing about a bash script, usually, is how much of the work you do by shelling out to other commands.
Amazing. The hashing thing is definitely on R*, but I wouldn't have expected an sscanf implementation to call strlen either. ("Ah, but of course they expect this kind of incremental parsing/tokenization to be done using the totally legit and un-problematic strtok instead!")
Well I gave up trying to understand C and C++ ages ago; they always felt like they sabotaged me for trying to get better at them. Moved on to many other programming languages.
In this case I believe they should have just vendored a small JSON parser in the game. It's a big blob of .exe and .dll files, why not? Found it weird but then again, we have all made mistakes that we later cringed at.
They could have just as easily vendored something with the same problem, and still not noticed. And if they cared on that level, they could also have switched to BSON, msgpack etc.
Yeah true, I don't deny it. My bigger point was that it was basically negligence. And it was in a very high-profile product making likely hundreds of millions (the shark cards).
Meanwhile I got fired because I could not keep up with impossible demands (which has been acknowledged by multiple people in the company but they did not want to burn political capital by going against the decision maker who was a petty tyrant who could not handle disagreement and fired me the first time I said what he was doing was not okay).
> But why not simply write the code that needs to be fast in C and then use call it from Ruby?
From the things that have been coming out since YJIT has been in development and the core team members have been showing, that's not necessary. Methods that are written in pure ruby outperform C libraries called from Ruby due a variety of factors.
But why not simply write the code that needs to be fast in C and then use call it from Ruby?