I agree with giving users control, but unfortunately I cannot agree with the move to c-ts-mode. And I cannot disagree more with associating CC mode with "legacy" when it's objectively better than the other alternative, at least currently. I don't think Emacs developers are doing users a favor in this specific case.
CC Mode is extremely capable. Over the years it has developed to such a maturity that almost all needs can be satisfied, and performance has never been a problem for me. It contains very few, if any, bugs, that affect my use.
On the other hand, the tree-sitter major modes are not at al production-ready to be considered as default. For one thing, the whole highlighting can break for complex macros and ifdefs. (I'd be glad to be enlightened whether it's theoretically possible to fix at all -- can you correctly highlight ifdefs without doing semantic analysis with the help of a compiler?) For another, CC mode has a feature called c-guess that can quickly analyze an existing source buffer and generate a format definition which proves extremely valuable. Alas, c-ts-mode has zero support for it.
I had high hopes for tree-sitter. I turned on tree-sitter modes for all my coding when it was out, and now I have zero enabled. They still have a long way to go and I don't want to spend time debugging emacs code at work. :-)
Tree-sitter is not a panacea. Fast parsing alone is not what makes a good major mode.
As someone whose pronouns are C-programmer/vim, I feel unsafe.
My living nightmare would be to develop highly verbose Java programs in an editor with 999 gorillion different "modes" with seemingly random names.
"oh, you're making an singletonfactoryfacade in Treesat-19 mode, you'll need to be using CCC-mode, treesat-19 mode is for factoryencapsulationfactory patterns"
Keep in mind that there are, unfortunately, at least two packages called “python-mode”.
There’s one that is shipped with Emacs, which is maintained by the Emacs maintainers. That’s the one I use and I agree with you that it works very well.
Then there’s a third-party one maintained by some Python project maintainers. Probably, that might be the one “apt install python-mode” will get you.
There is also a “python-ts-mode”. That’s just the built-in Emacs python-mode where the syntax highlighting is replaced with TreeSitter, which provides similar highlighting to other editors like Atom and NeoVim.
In addition, there are some heavier alternatives like elpy and anaconda-mode. But I think most people these days use one of the python-modes with LSP.
Unless you have a good reason to use one of the others, I’d start with the built-in python-mode. It doesn’t really require any setup in itself, just open a *.py file and it’s active without any use-package statement required.
It is however quite bare bones, so you probably want to couple it with e.g. Eglot, Company, Comint-Mime, Code-Cells.el, etc. to get more of a VSCode-like experience in Emacs.
It seems that one is on MELPA under the name “python-mode”. It’s a third-party project that replaces the built-in “python-mode”, also actively maintained (last updated last week).
I think I'm for Turing-completeness. Let me try to give my reasons...
1. No, using Turing-complete scripts does not prevent information extraction and meaningful automation. You can ask the program to dump useful information, e.g. targets, compiler flags, etc. That's what rizsotto/Bear does for Makefile. CMAKE_EXPORT_COMPILE_COMMANDS is another example.
2. I don't really think you can do anything further with declarative build languages, unless it is a really limited one like JSON or XML. Meson (a relatively advanced one in the space) advocates for non-Turing-completeness, but you still cannot, for example, modify meson build files reliably using an external tool other than a text editor.
3. Complex build configuration usually requires non-trivial computation and/or dynamic dependency graph building. Turing-completeness gives you a possibility and you don't need to wait for build tool upgrades.
Comparing Meson to CMake, I find the niceties of Meson are usually not inherently non-TC. That is, you can theoretically reimplement a nicer CMake with all the niceties of Meson, while still being TC.
It seems you are very ideology-driven, but no, corporations are not moving production out of China because "China bad". It's just because labor costs in China have risen due to its fast development.
The author isn't wrong. Europe is falling behind, and people should not pretend it's a good thing: the current European life style ("more to life than work") depends on excessive interests gained from technological advancements that are not yet replicated elsewhere. The life would be much worse if Europe couldn't keep up.
I kind of agree with you, and (as a hobbyist linguist) I believe a diversity of languages is a beautiful thing, but it creates unnecessary friction for business and about everything. Europe really needs a unified language -- it could be English, French, German, or even Interlingua or Esperanto.
Lingua franca really matters. China, for example, didn't have a unified spoken language until about 100 years ago. However, Mandarin is today universally understood and spoken in the country. And the result? You only to know one language, and you can have access to one of the largest markets in the world. Alas, the same could not be said for Europe.
(In fact, Europe needs a unified language if people are serious about getting rid of English and the Anglo-American hegemony, because each smaller language really cannot fight English now.)
Personally though I've been running the igc branch... ;-)