No developer is an island. By using an extremely unpopular VSC they increase the barrier to contribution for all external developers, miss out on support in tools and projects that only support Git, and they don't get to benefit from the increased development effort that goes into more popular solutions.
Dead as in essentially nobody uses it. Apparently it's used even less than SVN, which sounds kind of crazy. Doesn't stop them developing it if they want I guess.
Facebook is relevant because they were one of the last major users of Mercurial and were big contributors to it. They've moved to their own VCS Sapling now though.
Interesting. I guess as long as it doesn't have any false positives this seems like an ok idea.
Still, it would be definitely better if it could use tsc. They mention this... but don't really say if the Go version of tsc will allow it. IMO the slowness of tsc is largely overblown.
Games might be an area where it isn't too bad since you can disable the GC while doing all your physics and graphics, and then just after you've dispatched a frame trigger a GC with a hard time limit.
I don't know if Unity works like that but it should.
Nah AI can be extremely useful for learning technologies. You just need to be careful to verify they aren't bullshitting you.
For example find an explanation of PPM compression that is concrete and simple. As far as I can tell it doesn't exist.
But I could ask ChatGPT and it told me how it works (probably) in just a few seconds. I haven't verified yet (at a BBQ) whether it is the correct algorithm but it's certainly a plausible one that would work.
It told me that you use a trie (typically) of symbol prefixes to record the probability of the following symbols, so for example you know that for the prefix "Th" the probability of "e" is 90%. Then you encode the symbol with arithmetic coding using the modelled probabilities. Apparently the typical max context length is 4-6.
That would have taken me hours to find by reading code and ancient papers but I can verify it a lot quicker.
It doesn't matter though because the Clangd & CodeLLDB extensions completely replace it and are actually waaaaaaay better.
With Microsoft's C++ extension it always rinsed the CPU - there were files I had to avoid opening because then it would analyse them and I'd have to kill it. The code intelligence also seemed very "heuristic" and was quite slow.
Clangd fixes all of that. It's fast, doesn't choke on huge files, and if you have compile_commands.json it's actually the first properly fast and robust C++ IDE I've ever used. You know if you've used a Java IDE the code intelligence just works and is fast and reliable. It's like that.
That's a fair point. I don't think that's the case here because he talks about all the bad ways he prefers to receive contributions (email, patch files, git bundle etc.).
No developer is an island. By using an extremely unpopular VSC they increase the barrier to contribution for all external developers, miss out on support in tools and projects that only support Git, and they don't get to benefit from the increased development effort that goes into more popular solutions.