| Fair enough; thanks for taking the time to chat about this. I'm not sure I agree, but I appreciate your perspective and experience. For all that you've said, I still strongly suspect that a standalone rust / swift compiler designed for speed above all else could achieve many times the performance of the current LLVM based designs. The resulting binaries might need to lean heavily on dynamic dispatch over monomorphization to achieve that - but during development thats a tradeoff I'd take just about every time. The common factor in swift and rust is llvm - both using it for codegen and having the compiler think about the program in terms of llvm constructs. The fastest compilers I know about - V8, LuaJIT, Go, Jai(?) are designed with both performance and the target language in mind, and (I assume) don't translate the code through a series of complex intermediate representations internally. And you're right - none of those languages do complex template specialization. Also its probably no coincidence that maybe except for V8 all of those compilers were designed by a single expert mind, not a huge team spanning multiple companies. As you point out, large scale refactoring (required for top tier performance) gets increasingly difficult as team & code size increases. The reasons are partially political ("your commit conflicts with how much??"), and partially because it gets super difficult for any one mind to conceive of the whole program at once when it has so much code and so many authors. Let alone do large scale refactoring. I don't know if its true but I heard the chrome team started with just a dozen or so very senior engineers who all had experience with webkit. Before they brought anyone else onto the team, they spent months iterating together on the internal design of the browser engine until they were happy with it. They did it that way because they figured it would be basically impossible to change the core down the road once they had a larger team hacking on it. > Why are these languages using features such as type inference, stricter and more complicated type systems along with heavy templating? It's because now ... these features become viable in the compilers of today vs. the compilers of yesterday. Maybe. I think we also just got better at designing languages. Rust's trait system seems both simpler and better than C++'s classes + templates. Traits would have been just as viable in a compiler decades ago, but OO was trendy and we didn't know any better. > just because you like something, it doesn't mean most people like it Oh, I know! I've spent enough time working on teams building websites to know I'm not the average bear. But I don't think its because performance work is fundamentally uninteresting. I think its because most engineers working on websites don't have enough raw CS skill to comfortably step into the performance arena. |