< rant>

so what do you do if you actually DO fail to allocate? you pass an exception through whatever means. Let's now talk about how your cyclomatic complexity affects your ability to reason about correctness of your program.

If you never learnt to code in imperative programming languages (such as C/C++), it doesn't exactly mean that those that did learn are stupid or something.

< /rant>

Yes, it's dome more C legacy. But we do need a handle, just a better abstraction than a number.

>passing around numerical ids of entities instead of entity references
Numerical ids are much better.

>It's like 'error code'.
No it’s not.

You can store them in a CPU register.
You can save them using only 8 bytes of storage.
You can compare them with a single cmp CPU instruction.
You can design your system so the IDs are unique even if your system will scale out to thousands of servers.

I think C programming has nothing (or little) to do with it. Access to (relational) databases via lazy objects references is very harmful to performance.

Databases are designed to get mass quantities of records in one shot. E.g. retrieving 10,000 records via some simple query (SELECT * FROM Users WHERE OrganizationId=125) is virtually instantaneous. Lazy entity references are designed to get one object at a time. Retrieving 10,000 records via 10,000 queries (SELECT * FROM Users WHERE UserId=n x10,000 times) will take forever.

ORMs like Hibernate do provide lazy references, and make things look easy on toy databases. However, this ease is deceiving. Later on you find yourself rewriting half of the program getting rid of the lazy references, because it just does not work fast enough in production.

You actually never pass real string to the function. Instead what is happening, you are creating new string object in a heap and pass its pointer to the function through the stack. So in a way there is no much difference, but will be less work for a garbage collector.

If all your strings are static and already loaded in some array, the ID will save you trouble to load them each time. Or, if you have some resource provider, like Android does, it will let you to have multi-language support with no cost at all.

Разумеется, это самоочевидная истина. У явных id есть очень немного разумных применений, одно из них такое: звонит, допустим, клиент в саппорт и спрашивает, а что у меня ордер выполнился на два пункта дороже чем надо? А ему в ответ: ща посмотрим, а скажите-ка ID?

(из чего следует, что id для этих целей должен быть красивым и человекочитаемым, например, 137-234-987-202. И вообще генерироваться отдельно, не совпадать с внутренним id, который, как правило, UUIDv4, коих should be enough for everyone).

Ну и ещё из джаваскрипта в скалу приходится id явно гонять, референс же полностью не воссоздать. А так, внутри скального кода, конечно, никаких явных id, кашрут не велит.