Hacker News Reader

> you get direct access to all these rock-solid libraries

> in C that everything is built on -- zlib, libcurl, etc.

> So instead of dealing with a tower of wrappers in a

> high-level language

That's what I love about Objective-C: you get that, the direct access, and at the same time transparent, non-wrappered access to a high-level, dynamic object-oriented language.

Don't forget about Objective-C++! That's where the true powers of the dark side are.

Side Note: Objective-C is such a criminally underrated language. I often see people complaining about the syntax, but it's just syntax. Once you get over it, I find that the language makes the OOP paradigm a joy to work with.

Honestly, I never seriously considered it. I thought it was more-or-less an "Apple thing". OFC it is supported on other platforms, but seemingly not widely used (I write scientific code that really only has to work on Linux).

But after looking at its feature set, I wonder how easy it is to get by without templates? It seemingly uses weak typing instead like Go for scenarios that would normally require generics/templates. My attitude towards templates/generics is that they are absolutely necessary for a good standard library and core containers, but implementation of new templates in your own code should be rare.

Also, I do like namespaces in general, although not necessarily C++'s implementation of them.

I'll be a contrarian here and say that Objective-C is an ugly mess, and not even "because brackets". It's the language full of terrible hacks, historic baggage, and bolted-on features. Objective-C++ is basically the worst of both worlds. :)

Programming languages have advanced a fair bit since the 80s, it's time for Objective-C to die peacefully.

Have you ever tried Cython? It's always seemed cool to me, so I've always planned on using that if I ran into a case where I needed (relatively) direct C library access or wanted to speed things up beyond what straight Python is capable of.

Sure. I use it for some things and straight C++ for others. Cython is good for simple things, like small tight loops.

One thing that is much more reliable in pure C++ is any kind of threading or OpenMP etc. Theoretically Cython has it, in practice it can cause very weird problems. Also if you want to use C (or C++) libs in Cython, you have to manually declare all the function prototypes before using them.

Also Cython has a tendency to make minor breaking changes to syntax every version, breaking my code and/or making it version-dependent. Since I distribute to others, the best method for linking performance intensive-code to Python I have found is:

1. Write the core in C++

2. extern "C" a simple C API for it

3. Compile both to a SO

4. Access the SO from ctypes

It is more robust than Cython IME. Another advantage of this approach is that you have now have a generic C library you can use anywhere else if you want, not just Python. And you don't have to link -lpython so the C lib can be used in places where Python isn't installed. Finally, it can be nice to have some C++ binaries for startup time, and AFAIK you can't compile binaries with setuptools.

Thank you for your very informative answer!

If you're into both C++ and Python, I recommend pybind11 [1] - Cython is a crutch and moreover C++ is not a first class citizen in it. For reasonably large codebases Cython just doesn't scale and debugging is a total nightmare.

Disclaimer: I'm a contributor to pybind11.

[1] https://github.com/pybind/pybind11

Please note that I specifically singled out C++ here, not C. C is not C++ (not even technically a subset of C++). It is a very different and a much smaller language.

Yes, I know they are different, but I was talking about C++. I heavily use the STL and greatly prefer it to C idioms. I also like namespaces. Templates can be very hairy but void pointers are not great either.

In short, I simply think C++ can be used responsibly if you limit yourself to the subset of features that you (or your team) can understand.

For example, there are people who go crazy with Python metaclasses and such. A statement about interacting language features being dangerous could apply to anyone in any language who is trying to be unnecessarily clever.

C'mon over to the Go side instead ;-)