4 ms·

Memory Safe C/C++... Sounds like Go :)- http://golang.org/ http://golang.org/ The future is now!

lholden 14y ago
Rust I think has more potential to eventually replace C/C++. Besides having modern language features, it still allows the programmer to get down into the nuts and bolts of how memory is being used. (Not that I feel Rust is perfect either...) Go has some cool features... but I have yet to find a really compelling reason to use it over anything else. I also find it to be kinda gross looking. (But maybe I am just weird in that respect?)
- lholden 14y ago
  From an InfoQ interview: "InfoQ: How does it compare with Google Go? GH: Go's a good language. It's less complex than Rust, but also less ambitious. So you can pick your poison. Go's memory model, for example, has no concept of isolating memory between co-routines or threads, nor of controlling mutability. Everything can always race on the same global mutable heap. Similarly it has only one kind of pointer, which can always be null, and all pointers in all co-routines are subject to a single, global garbage collector. Rust statically differentiates all these cases, divides memory and pointers up into different types, which means we can control safety and performance much better, but at the cost of the programmer having to think more. Rust also provides a few extra "modern bits" that Go lacks: generic types, destructors, disjoint unions, that sort of thing. But to its credit, Go gets a lot of mileage out of the stuff it included, and I'm glad it's making headway." http://www.infoq.com/news/2012/08/Interview-Rust http://www.infoq.com/news/2012/08/Interview-Rust
  - voidlogic 13y ago
    The counter argument is Rust is going to end up an even more bloated ugly language than C++. Go is going to add some of those features, but they are committed to a slow "do it right approach" as opposed to "bolt it on". >>which means we can control safety and performance much better, but at the cost of the programmer having to think more Outside of systems software, there is no room for this. If the top 5% of programmers wrote all the software in the world Rust would be great, but that is just not the case.
    - lholden 13y ago
      I'm guessing you have not really looked into Rust. The idea is to also take a "do it right" approach rather then "à la carte". Keep in mind, the focus in in a different domain. Not really sure what basis you have for the "even more bloated" comment. There has been a lot of movement this past year around features and syntax in Rust... but the language is very much still in development. The main difference with Rust is the focus is on trying to make memory management safe yet applicable to lower level and performance critical programming. (A domain a lot of people are currently using (and getting bitten by) C++ for, hence why Rust is aimed at replacing it.) In regards to 'thinking more', this is in comparison to higher level languages. Things are way better compared to C++ on the other hand. Don't forget that replacing C++ is the target market for the language, not Java/Go/Etc. Anyhow, no reason to have a flame war on the subject. Rust isn't a hammer and neither is Go. :)
      - voidlogic 13y ago
        >>I'm guessing you have not really looked into Rust. The idea is to also take a "do it right" approach rather then "à la carte". Keep in mind, the focus in in a different domain. Not really sure what basis you have for the "even more bloated" comment. C++ is too complex of a language IMHO. Complexity is bad for new people as it takes a long time to know the entire language. And its bad for existing people as it provides too many ways to do the same thing. Rusts features look to be a superset of C++... You could substitute "too complex" with "too big". >>Anyhow, no reason to have a flame war on the subject. Rust isn't a hammer and neither is Go. :) I thought this was an interesting and friendly conversion, not a flame war. I do think everyone involved in this conversion probably agrees with each other in general, just maybe not particulars. And yes everyone has their favorite hammer, that doesn't mean its not worth discussing which hammers are best for which tasks.
        lholden 13y ago
        >> Rusts features look to be a superset of C++... You could substitute "too complex" with "too big". Feature wise I'd say Rust has more in common with a functional language. * Consistent type system. (base types like int are objects) * Emphasis on type safety. * First class functions and Lambdas. * Pattern matching. * All memory is somehow managed or owned. (#1) * Isolated concurrent memory. (No need for semaphores/mutexes) * 'variables' are immutable by default. * Types with traits instead of a "class" system. (#2) * No exception catching (#3) * Generics (#4) * No direct null/nil (Options are used instead.) * Concurrency is built in. * Can allocate on the stack, or via a managed 'box' on the heap. (#5) * Has the ability to link to and call C code. * Has the ability to break out into inline assembly. * Macros. (#6) The manual is reasonably decent: http://static.rust-lang.org/doc/rust.html http://static.rust-lang.org/doc/rust.html #1) Technically you can break out into unsafe memory operations or assembly. You have to specifically mark your code as 'unsafe' when doing so however. #2) Similar to Haskell type classes and way simpler then C++ classes. #3) There is a kind of error/exception but they are way simpler and not meant to be managed like in C++/Java #4) Don't confuse generics with C++ templates. (C++ templates can be used for the same purpose, but is WAY more complex and interesting.) #5) Perhaps the most complex part of the language... Boxes are a bit like smart pointers but with way less code involved. #6) I have not gotten into this very deeply yet but it looks more like Lisp macros instead of C/C++ macros/preprocessing. For perspective... C++ has about 84 keywords. Go has 25 keywords plus several predeclared identifiers (true and false for example). Rust currently has 32 keywords. (Some of which are just syntactic sugar). >> I thought this was an interesting and friendly conversion, not a flame war. (Was trying to show that she saw the subject light heartedly.) It was meant more as a tease then an accusation :)
- voidlogic 13y ago
  >>Rust I think has more potential to eventually replace C/C++ I think Go could replace Java/C++ for server applications and Rust could replace C/C++ for systems applications. I think each is better suited for those domains. >>Go has some cool features... but I have yet to find a really compelling reason to use it over anything else. To me its all the good parts of C/Java with all the bad stuff left out + easy concurrency, uber fast compile times, duck/structural typing and a minimalistic ideal. >>I also find it to be kinda gross looking. (But maybe I am just weird in that respect?) I think it is the most beautiful language I have ever seen- It reminds me a really really clean clear C, only better. (But maybe I am just weird in that respect?)
  - lholden 13y ago
    Personally I've been using Ruby for expressive stuff... and Haskell and Scala for crunchy performance and type correct code. On clean clear C... I can't say I've ever found C to be very beautiful. Even the really well written C :)

Rust I think has more potential to eventually replace C/C++. Besides having modern language features, it still allows the programmer to get down into the nuts and bolts of how memory is being used. (Not that I feel Rust is perfect either...) Go has some cool features... but I have yet to find a really compelling reason to use it over anything else. I also find it to be kinda gross looking. (But maybe I am just weird in that respect?)

lholden 14y ago
From an InfoQ interview: "InfoQ: How does it compare with Google Go? GH: Go's a good language. It's less complex than Rust, but also less ambitious. So you can pick your poison. Go's memory model, for example, has no concept of isolating memory between co-routines or threads, nor of controlling mutability. Everything can always race on the same global mutable heap. Similarly it has only one kind of pointer, which can always be null, and all pointers in all co-routines are subject to a single, global garbage collector. Rust statically differentiates all these cases, divides memory and pointers up into different types, which means we can control safety and performance much better, but at the cost of the programmer having to think more. Rust also provides a few extra "modern bits" that Go lacks: generic types, destructors, disjoint unions, that sort of thing. But to its credit, Go gets a lot of mileage out of the stuff it included, and I'm glad it's making headway." http://www.infoq.com/news/2012/08/Interview-Rust http://www.infoq.com/news/2012/08/Interview-Rust
- voidlogic 13y ago
  The counter argument is Rust is going to end up an even more bloated ugly language than C++. Go is going to add some of those features, but they are committed to a slow "do it right approach" as opposed to "bolt it on". >>which means we can control safety and performance much better, but at the cost of the programmer having to think more Outside of systems software, there is no room for this. If the top 5% of programmers wrote all the software in the world Rust would be great, but that is just not the case.
  - lholden 13y ago
    I'm guessing you have not really looked into Rust. The idea is to also take a "do it right" approach rather then "à la carte". Keep in mind, the focus in in a different domain. Not really sure what basis you have for the "even more bloated" comment. There has been a lot of movement this past year around features and syntax in Rust... but the language is very much still in development. The main difference with Rust is the focus is on trying to make memory management safe yet applicable to lower level and performance critical programming. (A domain a lot of people are currently using (and getting bitten by) C++ for, hence why Rust is aimed at replacing it.) In regards to 'thinking more', this is in comparison to higher level languages. Things are way better compared to C++ on the other hand. Don't forget that replacing C++ is the target market for the language, not Java/Go/Etc. Anyhow, no reason to have a flame war on the subject. Rust isn't a hammer and neither is Go. :)
    - voidlogic 13y ago
      >>I'm guessing you have not really looked into Rust. The idea is to also take a "do it right" approach rather then "à la carte". Keep in mind, the focus in in a different domain. Not really sure what basis you have for the "even more bloated" comment. C++ is too complex of a language IMHO. Complexity is bad for new people as it takes a long time to know the entire language. And its bad for existing people as it provides too many ways to do the same thing. Rusts features look to be a superset of C++... You could substitute "too complex" with "too big". >>Anyhow, no reason to have a flame war on the subject. Rust isn't a hammer and neither is Go. :) I thought this was an interesting and friendly conversion, not a flame war. I do think everyone involved in this conversion probably agrees with each other in general, just maybe not particulars. And yes everyone has their favorite hammer, that doesn't mean its not worth discussing which hammers are best for which tasks.
      - lholden 13y ago
        >> Rusts features look to be a superset of C++... You could substitute "too complex" with "too big". Feature wise I'd say Rust has more in common with a functional language. * Consistent type system. (base types like int are objects) * Emphasis on type safety. * First class functions and Lambdas. * Pattern matching. * All memory is somehow managed or owned. (#1) * Isolated concurrent memory. (No need for semaphores/mutexes) * 'variables' are immutable by default. * Types with traits instead of a "class" system. (#2) * No exception catching (#3) * Generics (#4) * No direct null/nil (Options are used instead.) * Concurrency is built in. * Can allocate on the stack, or via a managed 'box' on the heap. (#5) * Has the ability to link to and call C code. * Has the ability to break out into inline assembly. * Macros. (#6) The manual is reasonably decent: http://static.rust-lang.org/doc/rust.html http://static.rust-lang.org/doc/rust.html #1) Technically you can break out into unsafe memory operations or assembly. You have to specifically mark your code as 'unsafe' when doing so however. #2) Similar to Haskell type classes and way simpler then C++ classes. #3) There is a kind of error/exception but they are way simpler and not meant to be managed like in C++/Java #4) Don't confuse generics with C++ templates. (C++ templates can be used for the same purpose, but is WAY more complex and interesting.) #5) Perhaps the most complex part of the language... Boxes are a bit like smart pointers but with way less code involved. #6) I have not gotten into this very deeply yet but it looks more like Lisp macros instead of C/C++ macros/preprocessing. For perspective... C++ has about 84 keywords. Go has 25 keywords plus several predeclared identifiers (true and false for example). Rust currently has 32 keywords. (Some of which are just syntactic sugar). >> I thought this was an interesting and friendly conversion, not a flame war. (Was trying to show that she saw the subject light heartedly.) It was meant more as a tease then an accusation :)
voidlogic 13y ago
>>Rust I think has more potential to eventually replace C/C++ I think Go could replace Java/C++ for server applications and Rust could replace C/C++ for systems applications. I think each is better suited for those domains. >>Go has some cool features... but I have yet to find a really compelling reason to use it over anything else. To me its all the good parts of C/Java with all the bad stuff left out + easy concurrency, uber fast compile times, duck/structural typing and a minimalistic ideal. >>I also find it to be kinda gross looking. (But maybe I am just weird in that respect?) I think it is the most beautiful language I have ever seen- It reminds me a really really clean clear C, only better. (But maybe I am just weird in that respect?)
- lholden 13y ago
  Personally I've been using Ruby for expressive stuff... and Haskell and Scala for crunchy performance and type correct code. On clean clear C... I can't say I've ever found C to be very beautiful. Even the really well written C :)