Python.

What's bad about Python?

>>27,28,30
Okay, lemme elaborate.

If you're considering Python, it's safe to assume it's not totally unsuited for the project you're working on, meaning (among other things) you're not doing anything where GC is a bad idea. You're probably choosing it for its community, documentation, readability, and/or rich library ecosystem. You'll likely do some exploratory programming to iterate on your design, and use a testing regimen to keep your program on spec and hunt down errors. And if the situation calls for it, you're prepared to rewrite parts of your code as native extensions once you've identified performance bottlenecks or memory consumption issues.

(I hope it's obvious that much of this applies to Lisp, particularly Clojure. However, if you're considering Python and you don't know what else you should be using, I doubt you'd take that as a serious suggestion.)

Anyway, for all its good points, Python is fatally flawed (for the reasons already discussed) and I don't see much of a future for it outside of education and system administration.

Now, I mentioned Google Go as the main alternative. Something like 70% of the time, Go is workable as a drop-in replacement for an entire Python+C codebase (modulo the obvious cost of rewriting all your shit). It's slightly more verbose, and it still has all the pain points of old world control flow (especially the error handling idioms) but there are no particular speedbumps to speak of in the transition from Python. It has fast compile times, good tooling, a rich standard library, and built-in data structures sufficient for writing a million pounds of glue. Basically, if you know Python is fucked up but you don't know how to choose between the alternatives, just pick up Go and everything will more or less sort itself out. Trust me.

There's a smallish class of uses for which Python is still better suited than Go, but not by design, and this is where Lua shines because it is designed for that problem space. If you need an extension language for your C application, or you need to be able to patch and reload your code without a compilation step, or you just don't know what you're actually doing with your libraries, then you will want a so-called dynamic language, but you won't want a slow, heavyweight interpreter that's hard to integrate into your existing C code. That's Lua. The warts, like indexing from 1, are pretty superficial, and you'll get used to them. In my opinion the best part is that you can replace the standard implementation with LuaJIT for speeds that Python can only dream of, and the C interop doesn't turn into a federal fucking issue in the process.

The caveat to using Lua is that you have to do some lifting at the beginning to get your C APIs exposed to its interpreter. If you really need to hit the ground running and start coding right away, obviously there's another popular alternative called Node.js. I don't think I need to explain to /prog/ why this is terrible, and I mention it only with the reluctance of an air traffic controller walking a couple of teenagers through landing a 747 after everyone else on board has vanished in the Rapture. Like, if that's where you end up, you've already got lots of other problems I can never help you with, and you just need to bite the bullet and fucking deal with them in whatever way you can.

As for writing everything in C, that qualifies as a "real language" insofar as there's not yet a viable alternative for writing that kind of low-level code. In some cases you can generate fast C from a Haskell program using certain DSLs, like Atom (https://hackage.haskell.org/package/atom), and this is way saner than writing C by hand and introducing bugs that destroy your hardware or whatever. In other cases, like if you're writing an AAA game, you'll be up to your eyeballs in so many weird performance hacks that whatever you use ends up as a glorified assembly language macro package and you're gonna die no matter what. There was also a long period of time when C was the only usable applications language for every major desktop OS, but all the vendors are moving away from that if they haven't already, so there's C# and Vala right now and Swift is coming soon. C++ will live alongside them for quite some time, perhaps longer than Python sticks around, thanks to Qt and LLVM and some other stuff.

If your problem domain involves a lot of non-interactive data crunching and you don't have your hands and feet nailed to the JVM like some tragic chump, then you're in the nirvana-like realm where you get to use Any Language, So Long As It's Fast Enough™. This is where D actually gets used, and where most of the Haskell action is going on, and where you can get away with doing your whole thing in Common Lisp because a single programmer can write the entire system and nobody will need it in six more months. This is also where people still use Perl, and are starting to play with Julia, and even do dumb stuff like put everything in a Foxpro database and use AutoHotkey macros to communicate between that and Excel. (I have seen this happen.)

And this kind of turned into a much longer rant than I intended so I'll just stop talking.