great! could you explain in detail why you want to replace MOC:
"The redesign allowed us to completely remove the Qt Meta-Object Compiler (moc) system. Moc is a code generator and did not support many aspects of C++ including templates, complex data types, static type checking, and relies heavily on string comparisons. Removing moc improves run time performance, reduces the complexity of the build process, and allows more issues to be detected at compile time."
Just as someone who uses Qt every day... because its kind of a mess? You already have your compiler preprocessor and the moc is an extra step ahead of that. When the language didn't support templating that made the moc necessary, but nowadays you can do signal / slots the Boost way with templates and without a framework-specific preprocessor to mangle the source files into a string comparison nightmare.
Maybe in the purest sense the fact you cannot just do g++ <qt-program.cpp> -o <binary> kind of sucks. It just makes the whole build process implicitly complicated, and I haven't manually messed with the moc in five years so I've pretty much forgotten the syntax of baking it into homebrew makefiles.
New languages always are trap.
Programmers always waste too much time on new languages or some tricky language syntax. They should focus on the business.
Well, we first spent six months on 'cannot call function undefined of undefined'. We could have spent the last three on 'segfault' instead. Rust let us spend that time on actually experimenting instead of just fighting the computer all the time.
Spending 3 months on a segfault? In any language even a mediocre programmer you can usually resolve a null reference exception / segfault in a couple of hours at the most. With a complex program and a debugger it could be a minute or so. Maybe if it only happens in production and you don't capture stack traces or core dump files... but this happens once and then you learn your lesson.
Rust isn't what you seem to think it is. It targets a very specific area that's been dominated by C/C++ only because there wasn't anything better out there.
Rust still has a long way to go, but it's making progress and I would personally like to see a world where Rust is the go-to language for systems software.
I agree there is some truth in what you're saying. However, without programmer's curiosity and desire to create new interesting and beautiful languages, we would still be "focused on business" and writing code in COBOL, Fortran, C, Pascal...
I don't think that was the case for me at least. I felt like (using your own analogy) the more I studied Rust, the better I learned how to use every other hammer. Learning a new programming language helped me learn c++ better since I was constantly on the lookout for potential memory leaks and other common pitfalls that Rust prevents. Now when I code in c++, I always try to write the code with safety in mind.
I actually agree with you in general, but in this case we spent six months hammering in nails with a wet sandwich because the only available hammer has a chainsaw for a handle ("it's perfectly safe, just don't ever press the on-switch"). This blog post is me seeing something that looks like an actual hammer and suspiciously looking for a trap.
I agree with you generally -for me, given that I already know java well, it's clearly not worth the effort to spend much time on (say) Go. I make an exception here, because I think Rust has genuinely useful new ideas brought to the table.
This is the stone-age of computer science. Things aren't really going to get better at the behest of programming language luddites who think their 40-odd years of experience constitutes the whole future of technological progress.
