Hacker News Reader

Comment by shevy-java | Hacker News Reader

> A software engineer may be slicing and dicing nanoseconds

People typically live only once, so I want to make the best use out of my time. Thus I would prefer to write (prototype) in ruby or python, before considering moving to a faster language (but often it is not worth it; at home, if a java executable takes 0.2 seconds to delete 1000 files and the ruby script takes 2.3 seconds, I really don't care, even more so as I may be multitasking and having tons of tabs open in KDE konsole anyway, but for a company doing business, speed may matter much more).

It is a great skill to be able to maximize for speed. Ideally I'd love to have that in the same language. I haven't found one that really manages to bridge the "scripting" world with the compiled world. Every time someone tries it, the language is just awful in its design. I am beginning to think it is just not possible.

View on HN

I've found Julia to work quite well for this if you're focused on data/numeric code, though admittedly that's a bit of a niche.

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.

Feast your eyes: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

There were HN discussions at the time as well.

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).

Anyway, I got a bit bitter. :)

But in general, to me that story is embarrassing.

Also oof, I have no idea why I included bash here. I meant Python and Ruby. Thanks for calling me out.

> 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.

>Ruby starts fast and does everything fast. you can make a case against Ruby if you want, by making it do a lot of CPU work for a long time

What is your definition of "everything"? It seems to not include computation on a thing known as a computer.

Reply on news.ycombinator.com