tetrislife

Just like Europe doesn't have much choice in natural gas supply from Russia, India too doesn't. The US has always propped up Pakistan, their misadventure in Afghanistan ended with pushing them into China's arms which already has Pakistan, Myanmar etc. in its pocket, and Ukraine supplies Pakistan with modern weaponry.

"Europe stays silent on continuing to buy natural gas from Russia".

By the vague looks of it, he has tried Rust for something he would use C for. His impression of Rust's utility in that domain seems unsurprising.

Beyond that

I used to not question why we build anything other than "system software" in C/C++. Once I questioned that, I quickly got past the "Why not Ada/D/etc." stage and reached the "why is so much of large software written in mid-level languages" stage. For anything bigger than, say, a Unix CLI tool, it probably is, and has always been, wrong to use anything at the level of C (C++, Ada, D, Nim, Rust, Zig, etc.).

This choice of language level for "application software" seems to be a commercial choice. The software commons is using such languages probably because contributors want to hone their job-oriented skills. It got better with Python and Ruby uptake in open projects. But, efficient, safe but simple languages, say, OCaml and Erlang, have been available for decades. Crystal is also looking good right now.

Thanks gor the numbers. They don't make Emacs look unusable, so we could blame these darn cloud-provisioned VMs!

Thanks. True, verilog-mode is maybe 6 times slower than c++-mode. I should add some treesitter grammars and try c++-ts-mode etc.

File opening being slow must be a different aspect.

I don't configure at all, Emacs is quite capable out of the box. But you are right that I should try with -Q. I tried and found things like, terminal versus GUI doesn't make a difference, and disabling font-lock-mode makes it almost twice as fast (but I wouldn't use Emacs that way).

I need a fast setup on the same hardware to compare against, but I don't have it. This is the experience on VMs. I don't know what is fast for people. I stated one of my observations that indenting a couple of thousand lines is slow. How fast is that for you, in a VM or on hardware?

I did some comparisions. The installation built without treesitter support is noticeably faster than the one built with treesitter support; even in the latter, I don't have any treesitter grammars at all and no -ts-mode in use.

What hardware/VM and OS are you running on? What kind of development do you do in Emacs?

And, are you normalizing having to read the docs to have, for example, indent-region not be too slow?

I agree native-comp shouldn't be necessary, since Emacs wasn't this slow until maybe Emacs 25 and they keep improving the Elisp interpreter. And we probably can't expect the speed from before the CPU vulnerability mitigations and from running on hardware from any software running in VMs nowadays.

What I see is much worse than that.

To be fair, Emacs handles large files better than Vim. But yes, Emacs is slower on typical tasks, to the extent that an Electron app like VSCode can feel more responsive. Some slowness could be acceptable due to Emacs' flexibility, but getting slower over time messes up the experience.

Yep. And a cheatsheet of useful features you may discover very late otherwise https://web.psung.name/emacstips/essential.html

Ruby/Crystal seem to have P .. Q for inclusive ranges and P ... Q for right-exclusive ranges.