A lot of people who don't like Lua list "only having tables" as some sort of negative, but honestly I don't see how that is bad in any way.

1. Having only 1 data structure makes for a simpler, more elegant language. Once you understand tables, you understand everything you need to know about lua.

2. You could implement any other data structure with a table.

* A table is basically a dictionary / map already

* A table can be an array if you use numbers as keys. They don't even have to start at 1.

* A table can easily be made into a set if you use the elements of the set as keys and 'true' as the values.

* A table can be made into a proper OOP class with metatables

* A table can use prototypical inheritance too

* A table can act as a basic data record object

Those using the language don't really miss having the more specific data structures.

In my experience, it took a bit of conceptual work to get used to the "Lua way", and that impedance mismatch would have been reduced if it shared more similarities with the other languages we were working with.

Context is important IMO; if you're going to using a language as your primary development tool, then you'll get over that hump fairly quickly, and my objection is less relevant. But for our use-case (embedding Lua in a C application to have user-provided scripts drive our C library's callback hooks), the developers were primarily working in C and Python, and so most of us didn't use Lua often enough to really click with it.

For our use-case, something a bit closer to Python or Java would have been much easier to grok, and therefore would have made our development easier and more productive. "Easy and more productive" is all I'm really looking for in a language, always within the context of the specific usecase of course.

I'd be fine with dropping most of the sugar in Python or Java, but I'd be surprised if there were no "zero-cost abstractions" that could be added to Lua without making it too heavyweight for embedding.