Announcement

Collapse
No announcement yet.

Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++

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

  • #61
    >https://www.tiobe.com/tiobe-index
    I was suprised that Smalltalk didn't get a mention at all.
    I thought it had been used for some fairly serious expert systems
    at one time.
    Snobol (IV?) was mentioned and even Icon (they are related.)
    Simula-67 doesn't rate a mention either.

    Probably deficient methodology as another post suggested.

    I wonder how many truly obscure languages are still in use
    to support extremely niche applications.
    About 30+ya I saw a textile design application built using the Whitewater Group's
    Actor language and I wonder whether the application is still in use


    Comment


    • #62
      Originally posted by JMB9 View Post

      Well, reason for Go was to be similar to Java ... which always was extremely slow ... or do I miss something?
      I don't think concurrency is that uncommon ... even with C or C++ - even though not natively.
      So that's the reason everyone uses Go right now ...
      yes, you're missing a thing or two

      Firstable, Java is not slow. It is as fast as C++ and Go (when not even faster);

      Second, Go approach to almost everything is the opposite of the one used in Java..
      They're so different that Java is often used as an example on how NOT to do thing is Go.

      The reasons why Go was created are well illustrated by several talks by Rob Pike (one of its creator) that you can find on YT if really interested, but some key points are:

      * simple to write / simple to read (to enable new Google employees to be able to work on big projects from day 1... or almost!)
      * simple to deploy
      * fast at compile time / fast at runtime
      * concurrency made easy: while it's true that every programming language allows some kind of concurrency, the Go model for concurrency is awesome.

      Last edited by cynic; 21 July 2022, 01:25 AM.

      Comment


      • #63
        Originally posted by uxmkt View Post
        Golang: failed
        Where exactly did Go fail? It happily drives lots of backend, microservices and userspace network daemons...

        Comment


        • #64
          Uhm ... you know, I wouldn't call it Carbon, I would call it Pascal++ ... seriously, I really get the urge to do some Pascal/Ada coding if I see this "new" language. Heck, even calling it ModulaNG would be fine ... but Carbon? You know, the stuff that gets an increasingly bad reputation with every passing year. Why not use the next letter. Yeah okay, there is D. So how about E. Uuuh no, there was/is E on the Amiga, and surprise, a mixture of Pascal and C++. And its compiler is written in Assembly, actually a single 500KiB file. Works with 1 MiB RAM and 7 MHz, and is actually a well designed language and powerful ... and by a single guy who actually knows how to use computer resources properly. But this Google thing is another example of how the "modern" western societies run out of ideas, just like Hollywood.

          Comment


          • #65
            Originally posted by Akiko View Post
            Uhm ... you know, I wouldn't call it Carbon, I would call it Pascal++ ... seriously, I really get the urge to do some Pascal/Ada coding if I see this "new" language. Heck, even calling it ModulaNG would be fine ... but Carbon? You know, the stuff that gets an increasingly bad reputation with every passing year. Why not use the next letter. Yeah okay, there is D. So how about E. Uuuh no, there was/is E on the Amiga, and surprise, a mixture of Pascal and C++. And its compiler is written in Assembly, actually a single 500KiB file. Works with 1 MiB RAM and 7 MHz, and is actually a well designed language and powerful ... and by a single guy who actually knows how to use computer resources properly. But this Google thing is another example of how the "modern" western societies run out of ideas, just like Hollywood.
            what's wrong with calling it systemd_carbon ?

            Comment


            • #66
              They should do converter which should made C++ obsolete shit, also C++ pointers should be gone(but to make possible to enable them when needed(but absolutely necessary)) and also make programming easy(not like monkey wanted to program some advanced shit when not needed via another friendly lang) and performance should be bonus by lang design, not by effort of huge team when it is possible to do by a few programmers...

              Comment


              • #67
                Originally posted by onlyLinuxLuvUBack View Post

                what's wrong with calling it systemd_carbon ?
                Ouch ... though, that nails it ...

                Comment


                • #68
                  Originally posted by binarybanana View Post
                  But I guess if you're stuck with C++ it could be nice, like for writing UIs using Qt.
                  As much as I'd like this I'm very doubtful as Qt uses heavy metaprogramming with C++ macros. However, if there is a need I'm sure there is a way to make this happen.

                  Comment


                  • #69
                    Originally posted by uxmkt View Post
                    Dart: failed. Golang: failed (since now there's Carbon). Carbon: failure to be shown, but I'm sure it'll come.
                    That is definitely not true.
                    Flutter is quite popular and thus Dart as well.
                    Go is very popular as well, potentially as popular as Rust or even more popular.

                    Comment


                    • #70
                      While I do see why this language might be a kind of "better, but compatible C++" in some respects (e.g. type-checked generics, and not insisting on ABI stability at any cost, and these are not even mentioned in the header), I don't really understand why this is touted as a safer replacement. Let's look at the presented "memory safety measures":
                      • "tracking uninitialized states better": opt-in, and already available in C++ (in the form of default initialization)
                      • "design fundamental ABIs and idioms to support dynamic bounds checks": opt-in, already available in C++ ("at" member function of containers)
                      • "having a default debug build modeā€¦": incredibly vague, so I can't really comment on that
                      • "infrastructure like generics to support safe design patterns": opt-in, and already available in C++
                      • "Rust-inspired lifetime annotations": as far as I understand, this is a plan for the future, after the feature has already made a detour via C++
                      So more convenient than C++ I could see, but I can't see it being any safer.

                      Comment

                      Working...
                      X