Announcement

Collapse
No announcement yet.

Mozilla Updates To Rust 0.9 Programming Language

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

  • #11
    Originally posted by Daktyl198 View Post
    See, that's the thing, I don't see Rust and Go as system-level languages. To me, it seems like this:
    D is designed to replace System-Level C code (Kernels, Drivers that aren't written in ASM, etc)
    Go is designed to replace Application-Level C code (Browsers, music players, etc)
    Rust is designed to supersede C++ code in most areas, but seems to focus quite a bit on the Application-Level over System-Level

    At least that's what I've seen so far. This is why I don't get it when people are arguing about D vs Go vs Rust; they're not designed for the same thing (even Go and Rust, as they do things in very different ways internally)
    We are a systems language with a focus on systems. We're even working on getting our standard library working in kernel space. You would never be able to write a browser in Go because of the garbage collector, lack of inheritance, etc. The performance would just be plain terrible. Writing kernels in D is possible but the language's safety depends on a garbage collector. It's a cool project though!

    Rust is the only language in its space. Compiler-guaranteed zero-overhead memory safety. Someone in IRC is porting their multitasking kernel to Rust and has only had a single triple fault so far.

    Comment


    • #12
      Originally posted by Pajn View Post
      I really like this initiative. If we could replace all C and C++ with Rust some common security problems would go away.
      We're not a valid C++ replacement for certain uses of it. We lack templates, and templates are extremely powerful as an abstraction mechanism. Eigen or Boost could never exist for Rust, we simply don't have the expressive power. Of course, our type system makes up for it in other ways, but it rules us out in some categories of usage.

      Comment


      • #13
        Originally posted by Pajn View Post
        I really like this initiative. If we could replace all C and C++ with Rust some common security problems would go away.
        Replacing "all C and C++" is right behind "world peace" in terms of scope. :-)

        Comment


        • #14
          Originally posted by cmr~ View Post
          That's uninteresting because of the memory safety problems inherent in the languages. What purpose would there be for a language exactly like C except for ... what? What would you change? The syntax? That's not a compelling reason to switch languages, even if it's a mechanical transformation. C++ is far too complex to even possibly recreate.
          I know one thing I would change: the grammar. For example, production 4 in the K&R grammar looks like

          declaration:
          declaration-specifiers init-declarator-list SEMICOLON
          declaration-specifiers SEMICOLON

          This allows things like

          int;

          which compiles with a warning. It can't be an error (for historic reasons), even though it's a useless declaration, because the grammar allows it.

          Another example is the declaration-specifiers production, which allows all of the following declarations:

          static const int n = 42;

          const static int n = 42;

          int static const n = 42;

          and others.

          The grammar is simple, which makes it easy to port, but it adds unnecessary complication to the language. Moving the complexity from the language to the parser would be an improvement, since the parser is only written once, but is used to produce countless other programs.

          Comment


          • #15
            Originally posted by mark45 View Post
            If you wanna replace C or C++ create exactly these langs but without their historical burden. If you settle for more you're in the alley of failed langs like Vala, D etc who're never gonna replace C/C++ or attract critical mass.
            Yes, historical burden. My favorite example is C's use of the break keyword to end a case statement, which means that one can't break from a loop from an enclosed switch statement without a lot of horsing around. The creators of BCPL recognized and fixed this problem in the late sixties. C is based on an earlier version of BCPL, so it didn't fix this problem. Unfortunate, but understandable. But there's no excuse for Java and later languages that adopted C switch statement syntax some two decades (or more) later.

            Comment


            • #16
              Originally posted by cmr~ View Post
              I don't think Linux will ever use a different implementation language. Too much inertia.
              Well, rewriting the whole kernel just to switch language is a considerable task, for no short term benefit.

              Originally posted by cmr~ View Post
              Rust is the only language in its space. Compiler-guaranteed zero-overhead memory safety. Someone in IRC is porting their multitasking kernel to Rust and has only had a single triple fault so far.
              I don't understand, didn't you just said it's memory safe, but still he got a triple fault? Are they unrelated? Or is just the port still uses some C and that was the origin of the fault?

              Originally posted by bison View Post
              I know one thing I would change: the grammar. For example, production 4 in the K&R grammar looks like

              declaration:
              declaration-specifiers init-declarator-list SEMICOLON
              declaration-specifiers SEMICOLON

              This allows things like

              int;

              which compiles with a warning. It can't be an error (for historic reasons), even though it's a useless declaration, because the grammar allows it.

              Another example is the declaration-specifiers production, which allows all of the following declarations:

              static const int n = 42;

              const static int n = 42;

              int static const n = 42;

              and others.

              The grammar is simple, which makes it easy to port, but it adds unnecessary complication to the language. Moving the complexity from the language to the parser would be an improvement, since the parser is only written once, but is used to produce countless other programs.
              I don't see any problem in your examples. What's wrong in having options in the ordering? The only piece I see that actually makes no sense is the "int;" declaration, but still, I don't see how it could happen except for doing it on purpose.

              Originally posted by bison View Post
              Yes, historical burden. My favorite example is C's use of the break keyword to end a case statement, which means that one can't break from a loop from an enclosed switch statement without a lot of horsing around. The creators of BCPL recognized and fixed this problem in the late sixties. C is based on an earlier version of BCPL, so it didn't fix this problem. Unfortunate, but understandable. But there's no excuse for Java and later languages that adopted C switch statement syntax some two decades (or more) later.
              How did they fix it? Did they just make it so a label stops execution when it came to a new label?

              Comment


              • #17
                I thought the point of D was to be a drop-in replacement for C, while at the same time being easier to code in. So all existing C code can just be compiled in D and all new code should be easier to maintain and develop.

                Am I right?

                Comment


                • #18
                  [snip]

                  I don't see any problem in your examples. What's wrong in having options in the ordering? The only piece I see that actually makes no sense is the "int;" declaration, but still, I don't see how it could happen except for doing it on purpose.
                  The examples I site are only two of many. Individually they are not significant, but the sum total may be. Image a C-like programming language without much possibility of an obfuscated code contest.

                  How did they fix it? Did they just make it so a label stops execution when it came to a new label?
                  They added an endcase (or maybe end_case) keyword.
                  Last edited by bison; 01-10-2014, 12:04 PM. Reason: correct gramatical error

                  Comment


                  • #19
                    Originally posted by bison View Post
                    The examples I site are only two of many. Individually they are not significant, but the sum total may be. Image a C-like programming language without much possibility of an obfuscated code contest.
                    You could obfuscate code in any language, AFAIK. IMO, we are at times relying too much in the compiler to "think" for us, when all it should be doing is translate programs.

                    They added an endcase (or maybe end_case) keyword.
                    That's useful, certainly.

                    Originally posted by profoundWHALE View Post
                    I thought the point of D was to be a drop-in replacement for C, while at the same time being easier to code in. So all existing C code can just be compiled in D and all new code should be easier to maintain and develop.

                    Am I right?
                    I don't know, I never heard that statement before. If that's so, then porting a kernel to D is less of an issue than I thought, but at the same time it means that D still takes that legacy cruft some say should be removed, and it's still liable to compile unsafe programs.

                    Comment


                    • #20
                      Originally posted by cmr~ View Post
                      We are a systems language with a focus on systems. We're even working on getting our standard library working in kernel space. You would never be able to write a browser in Go because of the garbage collector, lack of inheritance, etc. The performance would just be plain terrible. Writing kernels in D is possible but the language's safety depends on a garbage collector. It's a cool project though!

                      Rust is the only language in its space. Compiler-guaranteed zero-overhead memory safety. Someone in IRC is porting their multitasking kernel to Rust and has only had a single triple fault so far.
                      Consider myself re-educated!

                      Hey, at least I never thought Rust was a language to replace JavaScript like some people...

                      Comment

                      Working...
                      X