Announcement

Collapse
No announcement yet.

Experimental Support For C++20 Coroutines Has Landed In GCC 10

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by bug77 View Post
    Universal dependency managers have been with us since forever. Ivy, for example, is over 10 years old. Guess why they still haven't taken off?
    • because they are overly complex (Nix is guilty of this, too)
    • because they do not solve actual industrial problems (versioning/dependency hell)
    • because people are stupid and follow marketing/propaganda/path of least resistance instead of pursuing technical correctness
    I still maintain that the solution is to develop better universal package managers — and not just "develop", but make them feature-complete, easily accessible and easy to use — rather than to continue increasing ecosystem fragmentation.
    Last edited by intelfx; 01-18-2020, 03:45 PM.

    Comment


    • #12
      Originally posted by intelfx View Post
      • because they are overly complex (Nix is guilty of this, too)
      • because they do not solve actual industrial problems (versioning/dependency hell)
      • because people are stupid and follow marketing/propaganda/path of least resistance instead of pursuing technical correctness
      I still maintain that the solution is to develop better universal package managers — and not just "develop", but make them feature-complete, easily accessible and easy to use — rather than to continue increasing ecosystem fragmentation.
      Following the same train of thought, a teacher told us in college it is mathematically proven that any program can be generated starting from proper specifications. So let's stop this ecosystem fragmentation where we use different languages and just work on this language that can generate everything for us.

      As much as logic tells you one system to rule them all is the way forward, you have to be pragmatic about it: so far it hasn't come even close to working as well as language-dedicated solutions.

      And let's be pragmatic for a bit. How do you build such a system? For example, C/C++ artifacts need to be made available for Windows, Linux, macOS running on x86, several variants of ARM and whatnot. Probably with 32 and 64 bit variants. Java/JS/Python artifacts have no use for these distinctions. So how do you handle them? Do you go for the least common denominator and add the OS and architecture only for some languages, making your product hard to approach (i.e. you have to learn something new for each additional language) or do you add everything and the kitchen sink for every language and let it go unused mist of the time (again increasing the learning curve, because now you have to read about aspects irrelevant to the language you're using).

      I'm not saying this will never be figured out (I'm sure there are already PhD theses written about it). I'm just saying, this is not easy and whatever we tried so far hasn't gained traction.

      Comment


      • #13
        Originally posted by uid313 View Post

        Why?
        Package managers are awesome. If something isn't supported by the standard library, how else am I going to get that functionality? Go on some random website and download a ZIP file that then gets outdated?
        Package managers are definitely life saviors for developers, but I'm hesitate to use a package manager that's baked into the language.
        I would rather have a few different package manager evolving independently and fits different scenarios (like pip and conda)

        Comment


        • #14
          Originally posted by bachchain View Post
          Maybe I missed something, but the spec doesn't really say anything about the executor. Is it implicit, like with JavaScript?
          No, it isn't needed with the current implementation. But it means there are some limitations and it won't have its full potential until the executor spec gets in in c++23 or c++26.

          Comment


          • #15
            Originally posted by uid313 View Post
            I wonder how Rust compares to C++. I think Rust have better type safety, better null handling, and a head start on coroutines, it also have package management via Cargo.
            Being a rustacean is like being a vegan in that you're thinking that Rust is saving you from leaking memory and whatnot but your whole life will revolve around pleasing the borrow checker and its ridiculous rules that make almost everything harder i.e. creating a dynamic mutable tree is an impossible journey to hell, while C++ devs just make such one in a tiny fraction of time and go on about their lives.

            Comment


            • #16
              Using coroutines will still require relying on external libraries such as cppcoro, right? There are no STL class for generators, awaitable objects etc.

              Comment


              • #17
                Originally posted by uid313 View Post
                Or maybe this is an evolution in the design of C++ which has allowed it to catch up with Rust, or at least be improved to the point that it is "good enough" and that even if Rust is better, it is not enough better.
                rust never was better than c++ in the first place. "has some random feature" doesn't equal to "is better". c++ has may important features which rust lacks. and yes c++ is always evolving
                Originally posted by uid313 View Post
                I wonder how Rust compares to C++. I think Rust have better type safety, better null handling, and a head start on coroutines, it also have package management via Cargo.
                i know little of rust, but i afaik it touts treads, not stackless coroutines (subj is stackless coroutines and they are completely orthogonal to threads, they are callbacks with inverted control flow). and i'm a bit skeptical about better types safety and null handling. c++ has package management. c++ has multiple package managers which rust lacks. though people can disagree on whether this is advantage
                Last edited by pal666; 01-19-2020, 08:15 AM.

                Comment


                • #18
                  Originally posted by Almindor View Post
                  I don't think C++ can get to Rust's position without removing support for ... C++.
                  c'mon, try to combine your knowledge of unsafe keyword with some creativity
                  Originally posted by Almindor View Post
                  Rust also provides the compiler with more optimization options because of immutability by default
                  better default provides developer with less typing, that's all. and with more typing in other places
                  Last edited by pal666; 01-19-2020, 08:52 AM.

                  Comment


                  • #19
                    Originally posted by intelfx View Post
                    Package managers are awesome, but having 20 independent package managers stepping onto each other's toes is anything but awesome.
                    this is a real issue. but "i'll switch to rust because it will limit myself to one package manager" is very stupid solution. because it is strictly worse than "i'll limit myself to one package manager X"

                    Comment


                    • #20
                      Originally posted by bug77 View Post
                      That's not proof some projects don't care about these features. That's just proof that it's hard for C++ to demonstrate correctness.
                      of course they do care about features. they just do not have manpower to rewrite their code to make use of them. and obviously rewriting code in different language requires even more manpower. i'm not sure what kind of demonstration of correctness you are craving from c++

                      Comment

                      Working...
                      X