This perceived simplicity of only having a single non-scalar datatype comes at the cost of increased complexity when you have to stuff a square peg into a round hole, i.e., when you approximate other data structures with tables.

My favorite example are arrays in Lua: They are hashtables, but not quite (in the implementation, every hashtable has a separate array region). They look like hashtables, but not quite (there's syntactic sugar to help dealing with them). You can use hashtable-functions on them, but they don't quite work (which is why there are special functions for when you want to treat a hashtable as an array). Hashtables are great for unordered maps and sets, but they're a crappy replacement for ordered sequences.

> Python is the classic example here, where you have tuples using parens, arrays using square brackets, and dictionaries using curly brackets. At some level that is clever, but at another level it is a cause of confusion.

If that confuses you, then the source of the confusion is you not having a clear understanding of the intended semantics of your code or datastructure. Mixing all of that into a single type won't help here.

Yeah, came here to say the same thing.

Tables + metatables mean that pretty much any structure you want is available. Single Inheritance + Interfaces, Multiple Inheritance, Component Based Design are all things I've seen in the wild on shipped products with Lua.

It's a fantastic 'orchestration' language. Coroutines were also invaluable. We used them extensively to script AI behaviors. Our designers(yes, not developers) would write them with "go to X location", yield, "search for players", yield, etc. Was a really compact way to build a FSM that they could understand.

Sorry, but tables are awful in practice. I have to iterate all the elements to get a count? This is especially egregious when I’m using one like a list/array and need to know how far to iterate. Maybe there’s a better way I don’t know?

If you need something quick-and-dirty, you can maintain an extra `["length"]` field on your table to cache that information. If you want something more polished, use a proxy table with custom methods/metamethods mediating access to your array so that the length is properly kept up to date. This isn't terribly different from the situation in C with arrays.

Tables are a basic mechanism for implementing any data structure. That is a qualitatively different statement from saying that tables can replace any data structure. If you need semantics different from what tables immediately provide, you'll need to implement the desired data structure yourself -- but Lua gives you good tools to do that.

> Maybe there’s a better way I don’t know?

You can use `for i, v in ipairs(arr) do ... end` to iterate over an array without worrying about "how far" to iterate. The `ipairs` iterator will determine when it hits the end of the array.

Yeah, this is fine until I want the last element of an array. Then I have to iterate it to find it. And writing a loop to get the last element of an array is crazy-town.

Have you actually used Lua? You don't need to iterate to get the last element of an array.

I have! I’m not an expert at it, though.

There's the length operator (https://www.lua.org/manual/5.3/manual.html#3.4.7): #sometable returns the length of the sometable if it is a sequence, and has an upper bound of O(log(N)).