Ruby, being a Perl-inspired language, has `.to_json` built in. You can do

```rb

   # hashes
   { foo: 'bar' }.to_json
   
   # numbers
   28.to_json

   # anything really
   ['hello', 42, { lorem: "ipsum" }].to_json

```

That’s simply not true. This method is monkeypatched by json gem

JSON has been in Ruby stdlib since at least 2.6 (2018)

You're both right, I think.

You might really like Ruby! It's part descended from Perl and maintains a lot of the nice things about perl such as json, and the amazing string functions.

I tried very hard to like Ruby. "On paper" it looks great, but I had a lot of trouble getting used to the syntax.

I ended up going deep on the D programming language for my "new language". As a statically typed language it's not as expressive as the Python/Ruby/Perl contingent, but it's a lot more expressive than most static languages, and its C-like syntax "clicked" with me in a way Ruby never did.

It also can approach C-like run-time performance and memory footprint at times, which I appreciate. As much as I like developing in Python and Perl, I frequently wish they had better run-time performance and a smaller memory footprint. D gives me that, at the cost of a little expressiveness.

> universal API for all databases

Go has this too, very handy:

https://godocs.io/database/sql

> Compare to Python, where you need to import a different module and use a different API for every different kind of database.

You... don't. Python has a unified DB api (DBAPI 2.0) which drivers usually support. They often also provide a lower-level API specific to the DB.

Omg the python stdlib json / simplejson both refuse to support custom serializers for keys only, as an explicit design decision. It is justified as "JSON keys must be strings", but JSON values can only be string/float/book/null so it seems a bit arbitrary. Leads to annoying gymnastics if you want to enforce "strong typing" of keys with Enum/pydantic/etc.

Funny enough, but I've come across some really nice Perl code in the wild at work. I was used to the vendor providing some 40 class Java monstrosity to do something that should take like a page of code, so I was pleasantly pleased to find a contractor who provides an extremely well commented page of code to do something simple, yet critical to operations. The way Perl calls the OS to do something and glue everything together was pretty elegant.

The only thing about the JSON package though, when things go wrong, it is very unhelpful about where it goes wrong.

I usually end up always wrapping the json_decode in an eval to catch the error and handle it in an easier to understand fashion.

But I agree though, its nice how json and perl data objects pretty much map to each other. It's great.

> In Perl, everything serializes to JSON without fuss. It can be "lossy"; objects without an explicit JSON serialization method and coderefs can't be deserialized, but serializations at least have placeholders for them.

> Compare to Python's json module, which doesn't try very hard to serialize things and throws exceptions every time it runs across something new. It's very frustrating to use.

Sounds kinda backwards to me. I thought the fact that throwing exceptions (or "making a fuss," if you will) is better than silently producing incorrect (or "kinda lossy," if you will) results wasn't controversial anymore in 2023.