Comment by curious9999

Comment by curious9999 a day ago

12 replies

> Most likely the raise of AOT compiled alternatives, for scenarios where C and C++ were only being used due to being compiled languages, big names in C++ compiler world rather put money on their own alternatives, are the two main reasons of the slow down.

What alternatives?

Rust claws at market share but has problems with basic stuff like doubly linked lists, WIP gccrs and memory unsafety, Carbon looks like a meme with too few people working on it, Ada has a neglected dialect and a proprietary dialect, Go has garbage collection, Zig has not even reached 1.0, Swift is more of an application language than a systems language, Circle is dead.

What else is there?

Not that C++ doesn't have challenges.

ogoffart a day ago

> Rust claws at market share but has problems with basic stuff like doubly linked lists, WIP gccrs and memory unsafety,

Doubly linked lists aren’t that important today. Rust doesn’t need gccrs to be useful, and it gives much better memory safety than C++ without needing a GC. So I find your criticism of Rust seems a bit weak. Rust is a strong alternative to C++.

  • curious9999_2 14 hours ago

    > 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.

    • ogoffart 10 hours ago

      > Rust, contrary to public claims, often does worse on memory safety than C++, which is a sad state of affairs.

      Nonsense! Where do you get that from?

      Aslo, you can make easily make linked list, it's just not a recommended data structure.

      • curious9999_2 6 hours ago

        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?

        • npalli 4 hours ago

          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).

pjmlp a day ago

Go, Java (GraalVM/OpenJ9), .NET (Native AOT, .NET Native, IL2CPP, Mono AOT), Swift, Objective-C, D, Nim, Ada.

Many people that use C and C++, do it out of habit, any compiled language, even with AOT is capable to deliver for most scenarios in userspace code.

99% of user software written in compiled languages isn't systems programming juggling pointers and type casts.

Even when that is the case, all above languages have FFI features, no need to rewrite the whole thing.

You might have noticed that C and C++ are minority languages in the mobile OS duopoly, for starters, being used only for low level OS services, and game engines.

  • curious9999_2 14 hours ago

    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.

0dyl 21 hours ago

>Ada has a neglected dialect and a proprietary dialect

What on earth are you on about? That’s not the case.

Ada 2022 has been released and Ada 202x is getting improvements. Those features are trickling into FSF GNAT (GCC).

Are you talking about the SPARK dialect, where GNATprove is open source?

  • curious9999_2 14 hours ago

    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:

    https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...

    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?

dlahoda a day ago
  • curious9999_2 14 hours ago

    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.

    Last update 1 year ago.

    Unsafety.

    Interesting research, however.

michaelsbradley a day ago

> What else is there?

There’s Nim, which is getting a major overhaul for v3 (cf. Nimony).