I think it is fine for C and C++ to be relegated for use caches where they make the most sense. I don't see the point of comparing them to niches, markets or cases where for instance garbage collection is fine.
And, I already mentioned Go, Swift and Ada.
Objective-C is not really on my radar, it's specific to Apple, and it doesn't seem like Apple is betting on it for the future.
D and Nim are languages with low momentum relative to others.
I am not sure the AOT approach will work. Maybe, maybe not. There are direct and indirect obstacles, I believe. D is probably interesting here; as I understand it, it supported both GC and no-GC. But, that meant that a lot of libraries used GC, and thus were not necessarily good options for applications that required no-GC. In some ways, a programming language can also be what people build with it and what its ecosystems are like.
That seems more an argument against Rust than one for, sorry. Library assistance, not part of the standard library, does not seem to be used much, not many examples.
> Use at your own risks[sic]!
>This is very much an Alpha quality release, at best.
> Doubly linked lists aren’t that important today.
I guess Rust is just not a viable or good language if one cannot even implement easily something as basic as a doubly linked list. Doubly linked list is the bare minimum; if that is not easy to implement, more complex data structures will often be even worse.
Rust, contrary to public claims, often does worse on memory safety than C++, which is a sad state of affairs.
I fear my arguments are way stronger than yours, sorry. Please make it easier to implement data structures in Rust.
On memory unsafe Rust: It tends to come crashing down when unsafe is necessary, for both reasoning about unsafe is harder than in C++, and the rules for unsafe in Rust is an active area of research. Do you know all the intricate rules of unsafe (not all which have been defined), can you reliably predict what is safe and what is not without using Miri? Miri that cannot test all? Are you an expert on aliasing and pinning? Can you describe what tree borrows are?
On doubly linked lists: Sorry, but to implement a doubly linked list in Rust well, you have to go through trials and tribulations. A whole book was written about an epic of implementing doubly linked lists in Rust: https://rust-unofficial.github.io/too-many-lists/ . And if all that is required for a data structure as simple as a doubly linked list, what will then be required for some of the more complex data structures?
Well said, the point of doubly linked lists is not that it is the be all and end all of all data structures. You can possibly workaround that. The real issue is a real program has much more complex data structures, how can you possibly make it work or refactor easily when a simple thing like DLL's are causing so much grief. So, yeah Rust really is unproductive in a massive way. Just useful in small parts where you might really need memory safety (that too, not sure why you wouldn't chose another language).
It was indeed the SPARK dialect I am referring to.
I find the Ada community difficult to navigate, the existence of multiple dialects does not make it easier. Please do correct me if I am wrong, and I apologize for any mistakes that I might have made.
If it is not the case that the SPARK language or its proprietary compiler is ahead of what is available publicly, why does this page say that pattern matching is in production:
While as far as I can tell, it is not part of normal, not-SPARK Ada, and either is not available in open source compilers, or might require enabling an extension?
My apologies for getting frustrated. I shouldn’t have done that.
This is bit on info-dump. I’m not the best at expressing myself and so some parts may not be clear. Please feel free to ask for clarification or any further questions.
Pattern matching is available as a language extension (currently) exclusive to GNAT GCC. It’s not in the reference manual, which means it’s not part of standardised Ada (yet). It’s intended to be an experiment or prototype for what will eventually become a standardised language feature (the standardised feature may be different, or it could be rejected, as the standardisation committee is composed of multiple compiler vendors).
You are not alone in finding the Ada community difficult to navigate. The “ada-spark-rfcs” repository you linked is a community outreach program of AdaCore to solicit feedback from programmers in venues they’re more likely to use. Those RFCs are then forwarded to the Ada Rapporteurs Group (ARG) who focus on the development of standardised Ada. Their issues, mailing list and meeting minutes can be found at: http://www.ada-auth.org/arg.html
SPARK doesn’t add features to Ada; instead, it’s a subset of features that can be easily proven by SMTs for formal verification. The special things in SPARK (extra attributes and pragmas, which Ada implementations are allowed to define) are only to aid formal verification. When language features are added, they’re added to Ada first and subsequently potentially enabled in SPARK.
I admit that calling it “ada-spark-rfcs” is kinda confusing - it’s just dumping ground for ideas for Ada and SPARK. For example, the multiple ghost levels RFC really only applies to SPARK, as ghost code only exists to improve verifiability. The final modifier RFC is for Ada proper, and it’ll probably apply to SPARK as it allows OOP.
The situation regarding compiler available is confusing and it made me nervous when I was first learning about the language.
GNAT GCC has two versions: FSF and PRO. The FSF (as in the Free Software Foundation) version is the publicly available version that’s in mainline GCC. PRO is for paying customers of AdaCore. From what I can tell, it’s built against an older version of the GCC backend. It tends to get those newest experimental features sooner, but they do trickle into FSF GCC. There have been points in time where I haven’t noticed any difference in feature set between GNAT PRO (according to the release notes) and those in FSF.
SPARK code works with both GNAT FSF and GNAT PRO. The formal verification tool for SPARK, GNATprove, is open source. https://github.com/AdaCore/spark2014
Have a great day. :)
Edit:
I’m not affiliated with AdaCore. I’ve never even spoken to one of their employees on the forums. I do use Ada, but only in my “side-business” (not making any money yet lol).
And, I already mentioned Go, Swift and Ada.
Objective-C is not really on my radar, it's specific to Apple, and it doesn't seem like Apple is betting on it for the future.
D and Nim are languages with low momentum relative to others.
I am not sure the AOT approach will work. Maybe, maybe not. There are direct and indirect obstacles, I believe. D is probably interesting here; as I understand it, it supported both GC and no-GC. But, that meant that a lot of libraries used GC, and thus were not necessarily good options for applications that required no-GC. In some ways, a programming language can also be what people build with it and what its ecosystems are like.