Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 46

Thread: Mozilla Updates To Rust 0.9 Programming Language

  1. #11
    Join Date
    Dec 2012
    Posts
    38

    Default

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

  2. #12
    Join Date
    Dec 2012
    Posts
    38

    Default

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

  3. #13
    Join Date
    Oct 2013
    Posts
    65

    Default

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

  4. #14
    Join Date
    Oct 2013
    Posts
    65

    Default

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

  5. #15
    Join Date
    Oct 2013
    Posts
    65

    Default

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

  6. #16
    Join Date
    Jan 2011
    Posts
    1,287

    Default

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

    Quote 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?

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

    Quote 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?

  7. #17
    Join Date
    Oct 2013
    Location
    Canada
    Posts
    315

    Default

    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?

  8. #18
    Join Date
    Oct 2013
    Posts
    65

    Default

    [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 at 12:04 PM. Reason: correct gramatical error

  9. #19
    Join Date
    Jan 2011
    Posts
    1,287

    Default

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

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

  10. #20
    Join Date
    Jul 2013
    Posts
    346

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •