You can't see all 50-70 tabs on a normal 27" monitor; Chrome will squish them almost indefinitely, and Firefox forces a large minimum tab width that makes the tab bar scroll forever and then you forget half the tabs you have going and everything's bad. I tried to switch and stopped because of this. I'll hang on until ubo really stops working, I guess, and then try to figure something else out.
You might be unfair to yourself in the sense that not all hours are created equal; some hours were never going to be productive hours, and so if you can immerse yourself in a subject with some easy-to-watch videos, that might be better than trying to force productivity where none is available.
I can only speak to the comparison with hg, but for large repos, git's performance is literally 10x better in our case (we have two parallel copies, one in hg and one in git, so as to smooth the transition to git). hg seems more usable, but certain decisions are poor (e.g. baking the branch name into each commit); overall I have no strong preference between the two except for the speed.
But the speed pretty much drowns out any other signal.
True, but it's easy to find games that don't use that model (especially on desktop or console), whereas it's hard to find a way to consume thoughts from interesting people outside of twitter.
We're working on those things, but we agree the debugging, performance, and iteration time are not in a great place for web today. We have plans for how to fix them, though, and are working on several of them currently. These are mostly under the umbrella of Project Tiny (the team I'm on), whose forum you can find here: https://forum.unity.com/forums/project-tiny.151/
It's very experimental still, and iteration times for web are still not amazing, but we do think we have a way to get them to be actually good, while still letting you write and debug C# as you would expect.
Moreover, Unity has invested heavily in the c#/.net/mono ecosystem; the editor runs on mono, and the runtimes are all either IL2CPP (an in-house translation from .NET bytecode to C++) or mono as well. It would be a truly crazy amount of work to switch, for little or no clear benefit. If one were picking a language today to write an engine in, Rust might be a reasonable competitor, but it's also fairly new and is arguably less noob-friendly. C# offers a nice ramp from new programmer to performance-critical AAA with burst.
So, in @rygorous's excellent Twitch streams about CPU architecture (first one here: https://www.youtube.com/watch?v=oDrorJar0kM), he said that it was basically a myth that x86 architectures dynamically decoded into internal RISC instructions. I am thus a little skeptical of the article in general, since I don't know enough myself to verify each thing.
I just went through the process of making a reliable and portable PCH build process, and it's a lot of code to get right, because clang, gcc, and cl.exe all have quite different models for how a pch should work.
cl.exe in particular has an insane set of requirements:
- you can't compile the pch by itself, you have to have a cpp that #include's it and compile that;
- then you have to link the resulting .obj file into the final binary;
- if you use /Zi and you compile different versions of the pch for different headers, you have to have exactly one separate .pdb file for each compiled version of the pch;
- if you have more, it will complain that some (pch, cpp) tuple do not share a .pdb;
- if you have less, it will stochastically fail to open the global pdb file (because the pch writing process expects not to have contention for the pdb, even though it's using mspdbsrv and /FS for contention)