Not knowing what you consider a hard problem, I think most of them are not of the kind that a language can do much about. It can easily be a drag though, for example by being too high-level and taking control away from the programmer when it's needed.
I'm not saying it's necessarily a bad tool (lisp or GA). They are just tools, not magic, and tools don't solve hard problems.
Or perhaps, choosing the right tool can reveal that certain, select problems are not actually that hard.
And perhaps, certain other problems, like computational geometry, are in fact just really fucking hard, no matter how you express them. Having some familiarity with the space, where the only really quality implementations are a massive GPL research code base in C++ (CGAL) and commercial C Libraries (Parasolid, SMLib), I lean towards this view.
I have some familiarity with computational geometry myself. I've built myself the tools I need for it in pure Apple Metal, and it beats anything you can buy or get for free (for my particular needs).
Do you mean computational geometry for graphics applications (your mention of Metal suggests this)?
I'm referring to computational geometry for manufacturing and engineering simulation applications, which is an entirely different beast (in particular, accurately tracking topology is much more important, and generally requires arbitrary-precision floats for degenerate cases).
No, manufacturing and engineering, for example, computing the offset of a 3D-body represented by a surface. This benefited heavily from massive parallel computation via Metal.
I also implemented other algorithms from scratch for solid body operations, and here indeed arbitrary precision rationals were needed first, but then I could get it working with normal double arithmetic in a lot of cases later on; I didn't use Metal here though.
I find that libraries like CGAL etc. are just either too slow or not general enough for my purposes. The whole sector seems ripe for disruption via proper algorithms implemented on graphics cards.
