People don't realize how much performance they're leaving on the table by not using C/C++/Rust. Get uWebSockets and set up a demo server, it's going to be 10-50x faster than a Node.js server. Quite literally the performance delta is that drastic.
It can get you most of the Smalltalk (Python/Ruby) conveniences with most of C's speed. In fact, if you do it really well you can leverage them together to get better than both. Simultaenously.
Doesn't mean that people don't manage to wield it in such a way as to get all the convenience of C combined with the performance of Python/Ruby. Which always baffles me. You .... did .... WAT?
To me the Right Thing™ here always seemed the obvious and simple thing to do, as in: just don't spend extra effort to mess it up and you'll be fine. YMMV.
Plug: my book gives fairly detailed instructions on how to achieve the positive combination. [1]
Other plug: Making it easier to get this right is the 2nd of the four stages of Objective-Smalltalk. [2][3]
[1] https://www.amazon.com/Cocoa-Objective-C-Performance-Tuning-...
[2] https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...
On a very-few/very-skilled developer project, this might work. But on projects with large or changing teams, that downside bites hard.
Fortunately, the run-time does this for you: it ignores messages to nil.
And the framework provides container objects for "bags of bytes": NSData.
So it is actually surprisingly hard to dereference a null pointer, and surprisingly easy to avoid mechanically without being perfect.
Just make sure that you delegate any manipulation of raw data to methods of the object holding the data.
https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoi...
While it is certainly possible to circumvent this if you put your mind to it, it is remarkably safe in practice.
Just like in C++, while there are high level abstractions that avoid traditional C memory corruption issues, there are always those that insist in sticking to the C subset.
As I wrote, you wrap those in an Objective-C container that manages that pointer, and delegate the C access to that container.
So not:
c_pointer = [container getPointer]
<munge on pointer>
[container doSomeMungingOnYourCData];
But yes, some people do insist on doing things the hard, slow, nasty way. They get punished.
* Most sites/projects are internal to an organization
* Most public facing websites/apps/projects won't be successful