kzinti wrote:No, the C language doesn't have an ABI.
Say that again.
kzinti wrote:I don't think you understand what that expression means.
Oh, but I do. It means just like COBOL, Rust will loose it's developers. Actually according to the latest StackOverflow survey, this has already begun.
Developers Reveal Why Rust Programming Language Is Losing Popularity
Not to mention that it turned out that SO devs who voted Rust as the most liked language
actually aren't using Rust in their everyday projects:
This issue of slow adoption of Rust programming language was first noticed in Stack Overflow’s 2019 survey. There we saw that majority of developers had a positive outlook towards Rust, but 97% of them had never actually used it.
Huh, that's pretty harsh!
Losing developers is phase one. Then comes phase two, when the number of new projects written in Rust starts to decline, and after that there's no turning back. Finally comes phase three (where COBOL is at right now) when there will be simply no-one who could maintain the code base any more.
kzinti wrote:COBOL would mean that it will outlast almost every other programming language that ever existed.
You don't know what "outlast" mean. Despite how old C is (lot older than COBOL, let me tell you), there are countless new projects started in C. When was the last time that a new project was started in COBOL?
Now you're suggesting that a language, which
1. doesn't have a stable ABI,
2. doesn't even have a formal specification at all,
3. incapable of describing something simple like a directed graph
4. after the first hype already started to lose popularity
will be really successful, now that's just a fool's errand.
Read this:
Why I'm dropping Rust, a guy who tried to port nanogui to Rust and gave it up. His conclusion summarize perfectly well my opinion on Rust:
For nanogui, and CEGUI uses this concept as well, each widget has a pointer to a parent and a vector of pointers to its children. How does this concept map to Rust? There are several answers:
1. Use a naive Vec<T> implementation
2. Use Vec<*mut T>
3. Use Vec<Rc<RefCell<T>>>
4. Use C bindings
[...]
The problems I've encountered in option 1 through 3 leave me to believe that option 4, making bindings to C, would be the only working alternative for the library I'm trying to write. And now that I'm at this stage, I'm thinking, why write bindings to C when I could just as well be writing in C? Or C++?
Cheers,
bzt