Any decent modern general-purpose languages?

Assembly: Unportable. No standardised syntax.
Classical Visual Basic: Some good parts. Shit overall.
C: Shitty standard library. Deficient type system. Can't into Unicode. ``Unportable assembly.''
D and C++: Obfuscated boilerplate languages.
Java and C#: Forced OOP.
Common Lisp: Archaic cons-based library. Writing complex macros is a PitA due to the unlispy quotation syntaxes.
Scheme: CL without namespaces.
Clojure and Erlang: Concurrency is unneeded outside of a few very specific applications. Parallelism is where it's at.
OCaml: Great language, only one, deficient, implementation.
Haskell: Academic sex toy.
Forth: Reinventing the wheel over and over.
Ruby: Implicit declarations. Slow as fuck.
Python: Implicit declarations. FioC.
Perl: Brain damage.
PHP: Pretty much shit.
JavaScript: "" == false

It's impossible to list them all but, please, what decent modern general-purpose languages exist?

>>72,73,82
Clearly none of you are experienced with Asm, or looked at compiler output (or you have, but can't understand/see a way to do it better, because of the first point). Compilers are a good way to generate code quickly; even at the highest optimisation level none of them can reason about things like register allocation in the same way that a knowledgeable programmer can. People have been saying compilers are better at generating code than programmers, but that's only if you compare to average or below-average Asm programmers.

Go learn Asm and compile any program you want, then look at the Asm output. Find a function and see if you can do it better. Unless you have some ultra-powerful compiler I haven't seen before, chances are you can beat the compiler in size, speed, or both. Perhaps because of the source language semantics the compiler can't do something, but YOU (should) know how your program operates and can easily take advantage of things like cross-function register allocation, convenient invariants (you can prove a register will always have e.g. 0, and use it appropriately; the compiler can't), and advanced stack manipulation.

>>82
Saying a language is "terribly designed" when it has the capabilities I need (and then some) is simply opinion. And it's not "write a few lines of code required to use the FFI", it's having to do that plus all the other "administrative" cruft surrounding it. In other words the integration is not as seamless as it could be. You said it yourself -- "FFI". Not "embed code directly in the compiler/JIT's output".

>>83
This is interesting, but note that it's not a core language feature. Someone clearly had the need to do that.

>>88
True portability is a myth. You can never get that in a compiled language, no matter how hard the standards bodies try. The closest thing to it is Java, and everyone should be familiar with its characteristics. If portability is ALL I care about for an application, then that's what I'd choose. My definition of "general purpose language" is one that allows the programmer to use whatever level of abstraction he/she finds appropriate, and switch between them effortlessly. How many architectures out there, in active use, have 37-bit integers, 11-bit bytes, or other oddities that the portability advocates keep using as examples? If you were working on such an uncommon system, portability is going to be the least of your worries. Right now, if you're targeting regular desktops, there's basically two ISAs and two OSs: x86-32/x86-64, Windows/*nix.

>>89
This is the sort of stuff I was talking about.

For instance, a compiler could schedule the evaluation of a procedure's arguments in parallel.
Unless those arguments require extensive computation, chances are that the overhead of preparing to get that done would outweigh the cost of just running them all in 1 thread serially. Modern processors are now quite good at parallel instruction execution, IIRC these 3 instructions

add b[edx], 5
sub eax, ecx
sub ebx, ecx

are executed in parallel since ~Core 2, with the second two running while the first is waiting on two memory accesses.