For me it's the other way around, I can skim a program written in Ada and figure out what it's doing almost the immediately because it is highly structured and enforces correctness with no ambiguity through its syntax.
I can't really do the same for rust which tends to lend itself into a more confusing format.
About two years ago, I was able to dive into the Ada reference manual formatter which has initial commit of March 2000 and is about 45k lines of code, and add MDX output pretty easily.
Other languages focus on terseness and expressiveness. Ada expresses a bunch of constraints directly and forces you to do things in organized ways (e.g. use namespaces appropriately).
I think that since a significant portion of Rust developers come from a C++ background, and C++ uses basically the same set of symbols, it's not a huge barrier to adoption
There's really only one sigil in there that isn't in C++ (the ' single-quote to name lifetimes and labels). And it's missing several ambiguities that plague older C++ grammars (i.e. is >> a greater than, or closing two template expressions?)
I like Ada, but I tend to agree. "End Something_Somethig_Something" is really a mouthful (compared to "}"). And programmers are superficial like that. Ada wouldn't be the first decent language being dismissed for inconsequential aspects like this one.
However I’d add that this job could easily be done by the IDE. For a reason that I fail to grasp, after being around for multiple decades, IDEs are still incredibly bad at presenting useful information on the code. Apart from coloration and more recently type hints, there never have been any real innovation in just helping reading code structure. For some reason we are still stuck with a tree of files besides some glorified text editor.
Interestingly, we have made incredible progress into code comprehension. We have incredibly mature ast parsers, lsp servers, … our IDEs know everything about our code structure but we still fail to make anything else with that data than autocompletion and doc popups.
It’s called “sticky scroll” in VSCode and Visual Studio [1]. It pins the opening line of a scope to the top when it scrolls out of view and it does it multiple levels deep so you can see the class, function definition, conditionals, etc at the top of the source file when browsing deeply nested code.
There is some great work being done here - I'm watching GToolkit advances, and while I don't fully buy the "moldable" hype, the UX of reading and writing code in GT feels like sci-fi sometimes.
So, this is a problem with using good editors. I don't know if VSCode or any similar editors have the way to select current block / current function, but in Emacs (and mostly likely Vi(m)) world this is just part of knowing the ropes. So, giving extra emphasis to the end of the function (or block) is completely unnecessary, it just reduces entropy.
Other problems with this: one of the ways to navigate the code is by searching for the function (procedure) name. Now you have double the number of matches.
Also, when I find code with comments that add labels like "end of xxx", I automatically delete all of these. It doesn't help me at all, and only makes searches in the code more difficult. Even the bad editors like VSCode probably have the functionality to jump to matching delimiter, which would easily reveal the name of the block you are working with.
And your company guidelines... oh, it should be fun when someone renames a namespace, but forgets to update the comments. At least, in Ada it's guaranteed that the end and the beginning will match. Also, sometimes I prefer not to invoke any kind of automatic refactoring, but rather rename a function and see what other code breaks, to quickly find dependencies. It's really annoying that this renaming must happen twice.
Extracting sequences of statements into a function sometimes improves readability, when those sequences do together some recognizable operation, but other times such an extraction worsens a lot the readability, because now you need to also open other pages to see what the program really does, when the statements in a sequence are not really related.
Even in programs optimally written for readability it is frequent to have iterations or selection statements much bigger than a page, especially where the coding rules enforce a small length for program lines, e.g. 80 characters.
In languages that follow Algol 60, like Pascal, C, C++ and so on, which have a single kind of statement brackets, it is frequently needed to add comments on the final braces or "end", to avoid confusions when reading the program.
This is much more cumbersome than in the languages that follow Algol 68, e.g. Ada and bash, where there are several distinct pairs of statement brackets.
I do occasionally have a long switch statement that doesn't lend itself to be broken up. If all the branches are simple and operate on the same conceptual level, breaking them out into separate functions that wouldn't be useful anywhere else doesn't make sense to me.
But it's definitely not a frequent enough occurrance to merit replacing closing braces with lengthy names that need to be kept in sync with their opening counterpart.
End names are optional in Ada, so "fixing" that is just a style guide away. Meanwhile, Scala 3 added named `end` to help with long blocks on its indentation syntax.
Like in all such discussions: the problem isn't with what you write, but with what you read. There are tons of Ada code that's already written like that. So, future changes to the style guide aren't going to do much. Also, nobody's changing that anyways.
Philosophically this is a fair point but practically it is not. Eventually any programmer will start relying more and more on tools to help with skim/read/comprehend code bases, no matter the language. There's a reason that every text editor and IDE used for programming includes helpers to find subroutine calls, jump to matching symbol (curly braces, closing parenthesis, end statement, or tab-depth indicator), etc, etc. No language is so "easy to skim/read and comprehend" that you'd be happy with a realistically significant code base and only the navigation keys on your keyboard.
There's a very fine line between nice language syntax and ease of use via tools you use to interact with the language (with APL-influenced languages being the only exception I can think of, but even there I've heard of programmers having physical key map symbols overlaid on keyboards).
