> In general, the fact that objects and mappings are the same thing,

What do you mean? What would you like to see in an object? ES6 has classes (syntactic sugar over prototypes, but does it really matter?) if that's what you are after.

> and that keys have to be strings

ES6 has a Map constructor[0] that can have any type of value as key. Usually, though, having keys as strings is quite sufficient.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

"Any type of value as key" is quite misleading since anything other than primitive types (number, bool, string) is compared by reference. Observe:

  > const m = new Map();
  undefined
  > m.set([1], "one");
  Map(1) {Array(1) => "one"}
  >m.get([1])
  undefined

C++ and Rust don't stand for this nonsense. You can't even define a custom hashing function, which means if you want a useful map for anything other than numbers and strings you have to write a wrapper around `Map` that hashes the objects to numbers or strings, and then you're more or less back to raw objects.

It's definitely better than raw objects because it doesn't mix up data and methods, but it's not much better.

I was quite surprised to read that you can't set a custom hasher in C++/Rust, and I even went and made sure that it's possible.

But then I re-read your comment and realized you've meant that you can't do this in JS.

Oh you can, just implement toString and js will use it for hashing

No it won't.

Map, no. Plain object, yes.

It doesn't "use `toString` for hashing", it just converts the key to a string. That is not the same (e.g. you can't recover the original key).

> ES6 has classes

To clarify, I miss having an object model that allows customisation of hashing, equality etc

> ES6 has a Map

Thanks for this; I'll check it out. One simple example of a key that is hard to use strings with is a composite key of 2 strings. OK, you could concatenate them using a character you know won't be used in either string, but what if it's user input? The code is then littered with in/out concatenation/splitting my this extra character etc. (And that's the simple case without other types etc.) It's much easier to have a clear way to customise the hash function IMHO.

Most programming languages have a nice delineation between a dictionary and an object but they are one and the same in JS and that'll throw plenty of traditional programmers for a loop.

To be fair Python has the concept of "everything is a dictionary" running pretty deep in its DNA. To a certain extent everything in Python is syntactic sugar over dictionaries.

Yeah, but that's implementation. Top level syntax, an object and dictionary are distinct.

I’m a professional Python developer as well and JS objects are one of the things I envy. Python objects are still opaque to me after more than a decade. I couldn’t tell you all of the magic methods nor could I describe the functions of those that I do know. Many of the things that Python objects support, such as inheritance, strike me as overtly undesirable (it would be much better to use composition in all cases, IMO), and the meta type system seems far more complicated than it needs to be (partly because inheritance confounds things)—although I was relieved to discover that you can call type() to generate new types instead of using the meta type class syntax.

On the other hand, as far as I am aware, JS objects are just bags of attributes with relatively few special magic attributes. There also seems to be less of an obsession with inheritance in JS, probably because the syntax makes a functional style more ergonomic although perhaps also because prototype inheritance is relatively cumbersome.

In general, JS’s object system feels more transparent to me, although I wish they would go further and preclude the special syntaxes for creating types. There’s nothing wrong with a function that returns types (which are either objects or closures depending on your religion). But I suppose I’m well on my way to reinventing lisp at that point.

> In general, the fact that objects and mappings are the same thing, and that keys have to be strings, is tough for me to understand.

JavaScript takes object.__dict__ literally.