You can typically predict performance behaviors across a whole language based on memory allocation patterns and the type system. If automatic memory management

You can typically predict performance behaviors across a whole language based on memory allocation patterns and the type system. If automatic memory management is built in, that adds some overhead to most allocation situations(and encourages an architecture that exploits easy allocation - e.g. Java libraries where everything you do involves a new()). There are differences between garbage collection(mark-and-sweep) and reference counting as well; an RC system is "pay for what you allocate" with predictable scaling, making it more appropriate to employ for hitting real-time deadlines, however, the state-of-the-art in generational mark-and-sweep GC does better for average case throughput. Or to put it another way, if you have a single batch process that everything goes through, you can usually count on a GC system doing it faster than a RC equivalent. But if you want to run several things concurrently and tally results, or you are running an interactive app and care about getting your latency numbers down, the pauses involved in GC may be more problematic to you. (The semantic downside of RC, which has also made a lot of languages avoid it, is its inability to deal with circular data references.) Of course, manually managed memory lets you design any allocation strategy you want, and so it can let you blow away automatically managed systems on microbenchmarks like these - stuff that starts mattering in the real world only after you've scaled up near to the constraints of the target hardware and any overhead is a Really Big Problem. There's definitely some more experimental automatic technology out there that "breaks the rules," but in terms of what you see in today's production environments, you can start estimating performance characteristics just by knowing what type of allocation is being done. The other big issue, of course, is the type system. The design of the type system determines the constraints and difficulty of automated optimizations; classically, Fortran was one of the best languages for low-level optimization because it made things very easy for the compiler, and offloaded many considerations on the programmer. Today C has grown into a roughly equivalent space(pointer aliasing, the last big issue, was tackled in C99). Rust can do everything C does, but it also has a much smarter type system backing it up and enforcing memory safety. Dynamically typed languages like Python, Ruby, Lua etc. are essentially always slower and more memory-hungry because of their intentional flexibility - to do as much as they do at runtime, they end up retaining more stuff per piece of data and paying a bigger cost to manipulate it. Luajit is an example of best-in-class technology for dynamic languages, and it's still not as fast as Go on most of the benchmark game. [0] Where Go stands in these two concerns is roughly comparable to Java or C#: it uses GC, and it has an intentionally simplistic static type system which points you towards built-in data structures, which makes it easy to work with for average-case situations, but hard or impossible to "tune up" as needs grow more complex. And if you check the benchmark game, all three are in the same window of performance, with some variance that could mostly come down to implementation detail. [0] http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=go&lang2=lua http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...